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.
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 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.
The prconfig setting fua/assemblyCacheMode and the Revert to previous generation caching check box on the Settings tab of your access group affects the order of RuleSet versions in your RuleSet list. The prconfig setting has three values:
The default value is Mixed.
As a best practice for applications developed in V6.3 to 7.1, do not select the Revert to previous generation caching check box, to use Application-Based Assembly mode. In V7.1 and after, VTable is the default and recommended replacement for ABA.
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 check box selected on the Security 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. |
During log in, the system starts with an empty list and retrieves information from five data instances, in the order listed.
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.
The RuleSets to which the operator has access are assembled from two sources:
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.
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:
Many other factors influence this process, such as:
If your requestor operates in rules assembly mode rather than Application-Based Assembly mode, the RuleSet list differs slightly from the description provided above.
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.
VTable sets up the RuleSet list in the same way as ABA and is the recommended replacement for ABA starting in V7.1 environments. See Understanding Virtual Rules Table.
