How the rules cache is populated

Pega uses a caching mechanism called the Rules Cache to help ensure rule resolution operates efficiently.

When your application references a rule, Pega checks the rules cache for the referenced rule. If the referenced rule is not available in the rules cache, Pega uses a multiple-step process to populate the rules cache.

The rule resolution algorithm first creates a list of all rules that match the purpose of the rule in question to populate the rules cache. Next, rule candidates marked as Not Available are removed from the list. Then the rule resolution algorithm uses the operator's Ruleset list to determine which rule candidates the operator can access. The rule resolution algorithm then removes all rule candidates not defined in a class in the ancestor tree. The rule resolution algorithm then ranks the remaining rule candidates. Finally, the rule resolution algorithm adds the remaining rule candidates to the Rules Cache.

The referenced rule used in the following examples is a section rule named CreateRequest for a Purchase Request case. This example helps to illustrate the rule resolution process.

In this step, the rule resolution algorithm creates a list of all rules that match the purpose of the referenced rule.

In the example, all HTML section rules named CreateRequest are collected into a list. There can be many instances of the rule in the initial list of rule candidates.

In this step, the rule resolution algorithm filters the list of rule candidates and removes any rules where the Availability of a rule is set to Not Available.

In the example, the rule resolution algorithm finds three rules (noted in bolded text) where the Availability of a rule is set to Not Available. The rules are removed from the list of rule candidates.

In this step, the rule resolution algorithm uses the operator's Ruleset list to determine which candidate rules the operator can access.

To be included in the results, each rule candidate must belong to a ruleset listed in the operator's ruleset list. Each rule must have the same Major version number, and a Minor version number less than or equal to the specified Minor version number listed in the operator's ruleset list.

In the example, assume the operator's ruleset list includes Purchasing:02-01 and TGB:03-01.

The three rules in the Purchasing:01-01-01 ruleset (noted in bolded text) are eliminated because they do not match the major version as defined in the operator's ruleset list (Purchasing:02-01).

The rule in the Purchasing:02-02-01 ruleset (noted in bolded text) is also eliminated because the minor version number (Purchasing:02-02) is higher than the minor version number defined in the operator's ruleset list (Purchasing:02-01).

Of the rules listed in the TGB rulesets, only one rule matches the current major version listed in the operator's ruleset list (TGB:03-01). All other rules in the TGB rulesets (noted in bolded text) are eliminated.

The rules listed in the Quoting and SAE rulesets (noted in bolded text) are eliminated because the rulesets are not listed in the operator's ruleset list.

In this step, the rule resolution algorithm examines the Apply to: class in the list of candidate rules to determine if the remaining candidate rules are in the inheritance hierarchy of the referenced rule.

To be included in the results, the Apply to: class of the remaining candidate rules must match the ancestor tree of the referenced rule. Only rules found in the ancestor tree of the referenced rule — by either pattern or direct inheritance — will be retained in the list.

In the example, the referenced rule has an Apply to: class of TGB-Purchasing-Work-PurchaseRequest. There is one candidate rule not in the ancestor tree (noted in bolded text), so it is removed from the list.

In this step, the rule resolution algorithm uses a three-step sub-process to rank the remaining candidate rules. First, the list of rule candidates is sorted. Then, all rule candidates marked as Withdrawn are removed from the list. Finally, a default rule candidate is defined.

The rule resolution algorithm sorts the remaining rule candidates according to this specific order: Class, Ruleset, Circumstance, Circumstance Date, Date/Time Range, then Version.

The first two criteria — Class and Ruleset — provide the basics of rule resolution. The closer a rule candidate is to the Apply to: class of the referenced rule, the higher the rule candidate is ranked. Within each class, the rule candidates are sorted according to the operators' ruleset list.

The next three criteria — Circumstance (Property or Template), Circumstance Date, and Date/Time Range — are used as qualifiers to the basics of rule resolution, and are used to further refine, or specialize, rule candidates.

The last criteria — Version — ranks the remaining candidate rules by the ruleset version that contains them. This ensures that circumstanced rules are not automatically overridden if the base rule is updated in a more recent ruleset version.

In the example, the list of rule candidates is ranked according to class and ruleset order, including any circumstanced rules, so no rules are removed from the list of rule candidates.

After the rule candidates are ranked, the rule resolution algorithm removes any rule candidates where the Availability of the rule is set to Withdrawn.

When the Availability of a rule is set to Withdrawn, the rule is removed from the list of rule candidates. Finally, all other rule candidates that match the Apply to: class, the ruleset name and major version number, the rule purpose, and any qualifiers of the rule set to Withdrawn are removed from the list as well.

Notice all rules in the same Apply to class as the rule with the Availability set to Withdrawn are removed from the list of candidate rules.

In this sub-step, three rules are removed from the list of candidate rules.

The rule candidate in TGB-Purchasing-Work-PurchaseRequest with the Availability set to Withdrawn (noted in bolded text) is removed. There are two rule candidates that match the Apply to: class, the ruleset name and major version number, and the rule purpose of the Withdrawn rule (noted in bolded text), so they are also removed.

The last sub-step in the ranking phase of the rule resolution algorithm determines the default rule candidate.

A default rule candidate is the first rule candidate (highest ranked) that has no qualifiers. This default rule candidate is the last possible rule to be executed as it always matches any additional requests for this rule.

Additional rule candidates ranked below the default rule candidate are discarded.

In the example, the default rule candidate (noted in italicized text) is TGB-Purchasing-Work-CreateRequest in the Purchasing:02-01-05 ruleset.

The two rules below the default rule candidate (noted in bolded text) are removed from the list of rule candidates.

The rule resolution algorithm adds the remaining rule candidates to the rules cache.