|
|
How the system assembles and uses your RuleSet list 
When managing access control, it is important to understand how the system develops and uses a user's 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. PRPC 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.
The primary source of information for your RuleSet list is the application rule referenced in your access group. That application rule, in turn, usually references a second, "built-upon" application rule, which itself can reference a built-upon application.
Because there are multiple levels and sources of the RuleSets in a RuleSet list, your requestor session can access the "best" or "most appropriate" rule for your exact, current situation. If there are rules that only apply to your organization unit, they are included somewhere in the list. If there are — through localization — rules that cause a user screen to be presented with German-language labels and European formats for dates and currency amounts, these also are on your RuleSet list. If there are rules that only apply on Fridays, or that only apply in Massachusetts, or only apply in other circumstances, these are on your list. This power and flexibility are the reasons that the RuleSet list is sometimes called the situational layer cake.
To see your current RuleSet list:
- From the Designer Studio, choose Profile from the profile menu — the menu accessed from the down-arrow at the right of your name.
- From the Case Manager portal, choose Profile from the profile menu — the menu accessed from the down-arrow at the right of your name.
- 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.
Your RuleSet list is assembled bottom-up
For authenticated users, the RuleSet list is assembled during log in, from partial lists contained in several sources. The order of RuleSets and versions in the RuleSet list is 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) that 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 General tab of an application rule, then Mortgage is directly above AllLoans in the assembled RuleSet.
Some of the sources of your RuleSet list may identify specific versions, down to the patch level, such as Mortgage:04-02-15. Others may provide only the major and minor versions, such as Mortgage:04-02. As in other contexts, this means that all patch levels of Mortgage:04-02 that are found in the system are available to rule resolution for this user.
Your RuleSet list order depends on the ABA setting
The prconfig setting fua/assemblyCacheMode and the Revert to previous generation caching checkbox on the Settings tab of your access group affects the order of RuleSet versions in your RuleSet list. The prconfig setting has three values:
- AC — Force Application-Based Assembly (ABA )operation for all requestors on this node
- Mixed — Application-Based Assembly operation is used unless the Access Group of the Requestor has the Revert to previous generation caching checkbox selected.
- RA — Force rules assembly operation for all requestors on this node
The default value is Mixed.
As a best practice for applications developed in V6.3+, do not select the Revert to previous generation caching checkbox, to use Application-Based Assembly mode.
The RuleSet list has multiple sub-lists
A completed RuleSet list contains sublists of RuleSet versions, arranged in two layers. Order is significant at the layer, sublist level, and within each sublist:
The following table presents the order (in ABA mode):
Layer |
Which RuleSets |
Notes |
| 1 | Personal |
For operators who have the Allow Rule Checkout checkbox selected on the Advanced tab of the Operator ID instance. The name of the RuleSet matches the Operator ID. This RuleSet, at the top of the RuleSet list, holds rules checked out by the operator. Such rules are not visible to any requestor except those of this operator. This single RuleSet has no version.This RuleSet is included implicitly when the system assembles the RuleSet list at log-on; you do not need to reference the personal RuleSet on the Access Group form or any other form. |
| 2 | Localized |
If the application has been localized, RuleSets with names ending in a locale suffix (such as _it_IT for Italian as spoken in Italy, or _fr_CA for French Canadian) appear here. Typically, these RuleSets contain only field values. See Internationalization and localization - Concepts and terms. If the application has not been localized, this layer is empty. |
| 3 | Mobilized |
If the application has been extended to support mobile devices, RuleSets with names ending in the special suffix _mobile appear in this layer. Typically, such RuleSets contain portals, sections, flow actions, navigation rules, and controls that are selected by rule resolution when the HTTP User-Agent value indicates that an HTTP request is from a mobile device. See Understanding Pega-Mobile. If the application has not been mobilized, this layer is empty. |
| 4 | Production |
RuleSet versions listed in the Production RuleSets array on the Layout tab of the Access Group form, if any. |
| 5 | Application (current) |
RuleSet versions listed in the Application RuleSets array on the General tab of the Application rule form for the current application. A branch RuleSet (if any) appears immediately above the RuleSet from which it branched. Any shared or component RuleSet versions, listed the Component and Shared RuleSets array on the General tab of the Application rule form for the current application, in the order they appear on the tab. The system assembles layers 5 and 6 from RuleSet Versions listed in the Application RuleSets area of the General tab of any Application rule it encounters during log-on when it processes the five data instances described in the next section of this help topic |
| 6 (multiple) | Application (built-upon) |
RuleSet versions for the built-upon application referenced in the current application rule. If in turn this application references a lower built-upon application, there is a layer for each, in the same relationship as the application rules. (The contents of the Component and Shared RuleSets area of application rules referenced through the Built on Application field are ignored.) |
| 7 | PegaRULES |
RuleSets and versions as listed in the PegaRULES (or PegaDM) application rule that the application is ultimately built-upon, excluding: the Pega-RULES RuleSet version. |
| 8 | Pega-RULES:NN-NN |
A version of the foundation RuleSet. |
Five data instances contribute to the RuleSet list
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 access group that references an application rule (such as PegaRULES.06.03) that adds the various PRPC product RuleSets with 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 a prerequisite, having its own RuleSets and versions.
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.
Contributions from the access group and the application rule
The RuleSets to which the operator has access are assembled from two sources:
- The Production RuleSets list on the Layout tab of the user's current Access Group.
- These lists on the General tab of the Application rule:
- Branch
- Application RuleSets
- Component and Shared RuleSets
While normally the RuleSets listed in the Production RuleSets (Customization) list on the Application rule are a one-to-one match of those listed in the Production RuleSets in the Access Group form, the lists can be different. The RuleSet list is assembled using the RuleSets listed in the user's current Access Group's Production RuleSets list, and not the specific list on the Application rule.
When processing an application rule, the approach is depth-first. That is, if the Application rule contains a prerequisite application rule (in the Built on Application field), RuleSet versions in the prerequisite application rule (or its prerequisites) are added first. Then the RuleSet versions in the lists on the Application rule are added, bottom-up according to the sub-list order (component and shared RuleSets, Application RuleSets, branch RuleSets, then the production RuleSets listed in the Access Group form).
This processing may result in duplicate entries in the RuleSet list. For each set of duplicates, all matches are dropped except the highest one.
How the system uses the RuleSet list
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 uses the RuleSet list as it:
- Searches the rules in the PegaRULES database repeatedly, first using the topmost ap[plication on the list, then the next, and so on. the Pega-RULES application is searched last.
- Ignores any rule instances that are contained in a RuleSet on the list but in versions higher than the version specified in the list.
- Treats any partial version number (such as 02-) as a wildcard or mask. For example, matching any rule instances containing a version that starts with 02-.
Many other factors influence this process, such as:
- Unavailable, final, or blocked rules
- Time-based rules
- Circumstances
- Access control (whether the user has authorization to access the rule)
Differences between Application-Based Assembly and Rules Assembly
If your requestor operates in rules assembly mode rather than Application-Based Assembly mode, the RuleSet list differs slightly from the description provided above.
- Branch RuleSets are higher, near the top
- Localized RuleSet versions are just above the corresponding non-localized RuleSets
- Shared and Component RuleSet versions appear lower
In theory, this can mean that runtime results for a specific user could differ depending on the mode. However, because the specialized RuleSets that differ typically contain only specific rule types, such differences should be rare. If your application uses such RuleSets and was developed in a PRPC version before V6.3, testing is advisable if you want to use ABA mode. See Understanding Application-Based Assembly mode.
