How the system assembles and uses your RuleSet list

The RuleSet list of any requestor is an ordered list of RuleSets and optionally specific versions or initial portions of a version number for each RuleSet. Process Commander assembles the list during log in, from several sources. Thereafter, the rule resolution algorithm uses this list to determine which rules are visible and so available to be run for that requestor.

To see your current RuleSet list:

• From the Developer portal menus, choose View > My Profile or click your name in the navigation panel.
• From the WorkManager portal, enter the Dashboard workspace. Click your name in the navigation panel.

In the Profile display window, locate the list labeled RuleSets. If you have a personal RuleSet (named to match your Operator ID), it appears as the top entry on the list.

For authenticated users, the RuleSet list is assembled during log in, from partial lists contained in several sources. The order of RuleSets and version in the RuleSet list significant and is preserved as the system assembles the list.

The system adds RuleSets and Version entries it finds in these rule and data instances to the top of the list, so the entries near the bottom are those it found earliest. However, for each source of RuleSets for this list (such as an access group) contains more than one RuleSet to be added, the system adds starting at the bottom of that array.

This technique preserves the final order. For example, if the RuleSet named Mortgage appears directly above the RuleSet named AllLoans in the Definition tab of an application rule, then Mortgage is directly above AllLoans in the assembled RuleSet.

A completed RuleSet list contains up to five sub-lists of RuleSet versions, arranged in two layers. Order is significant at the layer, sub-list level, and within each sub-list:

• The top layer contains one sub-list, of override RuleSet versions (if any). This sub-list is assembled from those listed in the Override RuleSets area of the Advanced tab of an application rule that is directly referenced by an access group listed in one of the five data instances described below in this topic. (The contents of the Override area of application rules referenced through the Built on Application field are ignored.) At runtime, rules found by rule resolution among the RuleSet versions in the top layer supercede all rules located anywhere in the second layer, unless the rule found in the second layer has an availability of Final.
• The second (bottom) layer may contain four sub-lists: one private RuleSet, application RuleSet Versions, shared and component RuleSet Versions, and the locked Pega- RuleSet Versions that define Process Commander.
• Each developer or other operators who can check out rules has a private RuleSet containing the currently checked-out rules if any. This single RuleSet has no version; it forms the top sub-list of the second layer. This RuleSet is included implicitly when the system assembles the RuleSet list at log-on; you do not need to reference the private RuleSet on the Access Group form or any other form.
• Application RuleSet versions form the second sub-list of the second layer. The system assembles these from RuleSet Versions listed in the Application RuleSets area of the General tab of any Application rule it encounters during log-on when processing the five data instances described in the next section of this help topic, plus RuleSet versions listed in the Production RuleSets area of the Layout tab of any access group it encounters when processing the five data instances
• Component and shared RuleSet versions (if any) form the third sub-list of the second layer. This sub-list is assembled from those listed in the Component and Shared RuleSets area of the General tab of an application rule that is directly referenced by an access group listed in one of the five data instances. (The contents of the Component and Shared RuleSets area of application rules referenced through the Built on Application field are ignored.)
• Versions of standard Pega- RuleSets form the fourth and bottom sub-list of the second layer, in the fixed order Pega-AppDefinition, Pega-ProCom, Pega-IntSvcs, Pega-RULES.

During log in, the system starts with an empty list and retrieves information from five data instances, in the order listed.

• Requestor Type (Data-Admin-Requestor class) — By default, references an application rule PegaRULES.V5.5 that adds the five Process Commander product RuleSets: Pega-AppDefinition, Pega-RULES, Pega-WB, Pega-ProCom and Pega-IntSvcs and a version or initial portion of a version.
• Organization — As identified in the Operator ID instance. This may reference an access group, which typically references an application rule.
• Division (Data-Admin-OrgDivision class) — As identified in the Operator ID instance. This may reference an access group which typically references an application rule
• Access Group — Optionally identified in the Operator ID instance; typically references an application rule.
• Operator ID — If this user has the ability to check out rules, the personal RuleSet (named for the Operator ID identifier) is added last.

The first four of these five sources typically reference an application rule (Rule-Application rule type) that lists RuleSets and versions. That application rule may reference another application rule as prerequisites

If you update and save an application rule or access group, all the requestor sessions associated with these instances are immediately affected with an updated RuleSet list.

In Version 4, changes to RuleSet lists in an application rule or access group were affect only for those users who logged in after the change.

The three access groups referenced in the organization, division, and Operator ID contain two sources of RuleSet versions on the Layout tab that contribute to the list:

• Application rules, processed first
• The optional Production RuleSets array, processed second

When processing an application rule, the approach is depth-first. That is, if the General tab contains a prerequisite application rule (in the Built on Application field), RuleSet version in the prerequisite application rule (or its prerequisites) are added first. Then the RuleSet version in the Application RuleSets area are added.

This processing may result in duplicate entries in the RuleSet list. For each set of duplicates, all matches are dropped except the highest one.

Each requestor's use of the system continually causes the system to search for a rule instance. This sophisticated search, known as rule resolution, uses properties from many sources to find the most appropriate rule for the current need, including class inheritance, security and access control restrictions, and the RuleSet list.

During rule resolution, the system:

• Searches the rules in the PegaRULES database repeatedly, first using the topmost RuleSet name and version on the list, then the next, and so on. Override RuleSet versions (the top layer are searched first; the Pega-RULES RuleSet is searched last.
• Ignores any rule instances that match a RuleSet on the list but contain versions higher than the version on the list.
• Treats any partial version number (such as 02-) acts as a wildcard or mask, matching any rule instances containing a version that starts with 02-.

Many other factors, including unavailable, final, or blocked rules, time-based rules, circumstances, and access control influence this process.