Benefits of rule resolution

The benefits of rule resolution include the following advantages:

• Multiple applications and organizations can share rules. Sharing and reuse are major benefits of goal-oriented and efficient software development.
• More specific rules that are defined at a higher level can override more general rules that are defined at a lower level that is closer to the base class. Overriding rules makes reuse of resources less applicable, but provides flexibility and visibility to exceptions.
• For greater flexibility, rules can have multiple versions. Rule resolution automatically determines the most appropriate rule in a given scenario. You do not need to spend time to manually select a rule.
• One Pega Platform system can host multiple applications, organizations, and versions of one application with less concern for conflicts or interference.
• If multiple applications depend on a common set of rules, developers can work on the applications independently without interference if the common rules are locked.

Classes in rule resolution

Pega Platform defines data in a class hierarchy that follows the object-oriented paradigm. The hierarchy starts with an ultimate class called @baseclass. Classes are subdivided into more specialized types of classes. For example, the Requests- class can include specialized Requests-Loan- and Requests-Mortgage- classes. Classes can contain rules that descend from the Rule- base class. Rules can inherit properties from other rules through class hierarchy. In search for a rule that is defined in a particular class, the system checks rules that are defined in the class, as well as rules defined in the ancestors of the class. The system can hold multiple copies of rules, which are different, and any one of these copies might be useful at run time, depending upon the situation. Rule resolution is a process by which Pega Platform determines which rule to apply from the set of candidate rules. Many different rules can apply, so rule resolution checks all the candidate rules to determine the most accurate way to perform processing.

The following figure shows a sample class hierarchy that starts with a @baseclass and then goes from more general to more specialized classes:

For example, in a scenario in which you work with an instance of the UPlusTelco-Auto-ClaimsEntry class, and the processing requires a Display flow, if the system finds the Display flow both in UPlusTelco- and UPlusTelco-Auto- classes, it chooses the latter instance, which is closest to the definition of the class structure of the UPlusTelco-Auto-ClaimsEntry instance.

Rule resolution begins by selecting all the possible rules with a particular name of a particular type, such as activities or when rules. For example, at run time, a sample scenario requires the Approval service-level agreement (SLA) on the UPlusTelco-Process-Loan class. The system chooses all the Approval SLAs in the UPlusTelco-Process-Loan class, or the ancestors of the UPlusTelco-Process-Loan class, including rules in different rulesets, different versions, and different circumstances. The SLA rule in question can have different definitions in all these places, or the system might find duplicate definitions in different classes or rulesets. The goal of rule resolution is to select just one rule that is the most accurate to apply to a given situation.

Rule resolution applies to rule types in classes that inherit from the abstract Rule- base class. The following list includes examples of instances of rules that derive from the abstract Rule- base class:

• Case types that belong to the Rule-Obj-CaseType class
• Properties that belong to the Rule-Obj-Property class
• Data pages that belong to the Rule-Declare-Pages class

Rule resolution does not apply to instances of classes that derive from the Work-, Data-, or any other base class. Those classes typically contain objects to which Pega Platform refers as records. The following list includes examples of records that derive from these abstract base classes:

• Operator IDs that belong to the Data-Admin-Operator-ID class
• Email listeners that belong to the Data-Admin-Connect-EmailListener class
• The rule check-in process that belongs to the Work-RuleCheckIn class

An in-memory rule cache helps the rule resolution process operate faster. If the system finds an instance, or instances, of the rule in question in the cache, the system accepts the rule instances in the cache as the candidate rules and skips multiple steps in the resolution process.

Rule resolution inputs and output

The following list includes the inputs to the rule resolution process:

• The key parts of a rule instance that the rule resolution process targets, such as the Applies to class and the name of the rule.
• The ruleset list for the user that the system assembles when the user logs in.
• The class hierarchy, which is the structure of classes.

  For more information, see Understanding class hierarchy and inheritance.

• The access roles and privileges of the user, determined by the access group that the user has.
• Security and access control rules, such role access to object rules and privileges.
• Rule availability that determines which rules are available, blocked, final, withdrawn, or not available.

  For more information, see Setting rule status and availability.

• In some cases, the value of a circumstance property.

  For more information about circumstancing rules, see Creating a rule specialized by circumstance.

The output of the resolution process is the first rule that matches all the criteria. In some scenarios, the system fails to find a rule and the process stops. Then, the system can start an exception flow, for example for a case type, or return a message about a failure.

Rule resolution process

The following list describes the consecutive steps that the system performs in the rule resolution process:

1. The system checks the rules cache.

   By using rules that are already in the rules cache, the system avoids additional database lookups.

   For more information about the rules cache, see the How the rules cache is populated module on Pega Academy.

   If the system finds the rule in the cache, the rule resolution process moves to step 8.

2. The system chooses instances with the correct purpose and puts them in a temporary list.

   The purpose combines all the key parts of a rule.

   For example, for an activity rule, the key parts include:

   • The Applies to class that defines the activity.
   • The activity name.

   In another example, for a field value, the key parts include:

   • The Applies to class, as above.
   • The field name, such as pyActionPrompt.
   • The field value, such as ViewHistory.
3. The system discards all unavailable rules and removes them from the temporary list.
4. The system discards inapplicable rulesets and versions.

   The system removes from the list rules that belong to rulesets and versions that are not available for the current requestor, which can be a user who is currently logged in, a REST API call, or any factor that triggers rule processing. For example, if the current user can access the SampleRuleset:05-01-01 ruleset version, the system removes rules that belong to SampleRuleset:04 or SampleRuleset:06.

5. The system discards all candidates that are outside of class inheritance of the current class.

   In the temporary list for rule resolution, the system only maintains rules in classes from which the current class descends either by pattern or direct inheritance. For more information about class inheritance, see Understanding class hierarchy and inheritance.

   Note: This step is not applicable to rules that do not have the Use class-based inheritance to arrive at the correct rule to execute check box selected in their class definition.
6. The system ranks the remaining rules in the list by analyzing the following aspects, in the following order:
   1. Class
   2. Ruleset
      Note: Default rules that you save to a branch or privately check out are in their own ruleset.
   3. Circumstance
   4. Circumstance date
   5. Version
7. The system adds the rules that remain in the list to the cache as selectable for use.
8. The system finds the best rule instance and checks for duplicates.

   The process searches down the list for the first rule that matches the following criteria:

   • The rule exactly matches a circumstanced rule.
   • The rule has the correct circumstanced date.
   • The rule is in the correct date/time range.

   When the system finds a rule that matches these conditions, the process checks whether the next rule in the list is equally correct. If the next rule is correct, the process sends a message about duplicate rules in the system and stops processing. If the rule resolution process finds no duplicates, the system prepares to use the rule that matches the listed conditions.

9. The system checks whether rule availability is not Blocked. If the rule is blocked, the system sends a message that it cannot find an appropriate rule to use.
10. The system verifies that the requestor is authorized to view the rule. If the requestor can view the rule, the system uses the rule as the output of the rule resolution process. If not, the system sends a message that it cannot find an appropriate rule to use.

The following figure shows a diagram that describes consecutive actions that the system performs during rule resolution. In the figure the rule resolution process is successful and the system applies a selected rule at run time:

Rule resolution exceptions

Some rule types have instances that are not associated with a ruleset and version, and no rule resolution occurs when processing requires an instance of these rules. Additionally, some rule types do not support circumstanced processing.

Rule resolution in branches and withdrawn rules

When you work in branches, each branch has its own rulesets that the system uses for rule resolution. However, withdrawn rules are an exception to this general behavior.

Rules marked as withdrawn in branch rulesets, such as deleted UI views, are not withdrawn from the main ruleset during development. They are withdrawn in the branch ruleset. Because the system skips over withdrawn rules when in different rulesets, the withdrawn (deleted) rule can still be resolved in the main ruleset. When you move the changed rule to the origin ruleset by merging the branch, the system honors the withdrawn rule and does not resolve it.

In the next example, rule resolution logic might return some rules even though they are withdrawn in a branch because the rules are available in the origin ruleset.