Show
all
When managing access control, it is important to understand how the
system develops and uses a user's RuleSet list. PROJ-1318 C-1852
Overview
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 Designer Studio, 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.
The RuleSet list
has file sub-lists in two layers
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. CHECKED AT
RUNTIME?
- 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.
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 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.
C-1818 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 took effect only for those users who
logged in after the change.
The access group and the application rule contribute
The RuleSets to which the operator has access are assembled from two sources:
- Three lists on the General tab of the Application rule:
- Application RuleSets
- Production RuleSets (Customization)
- Component and Shared RuleSets
- The Production RuleSets list on the Layout tab of the user's current Access Group.
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 Application RuleSets list are added, followed by those in the other lists.
This processing may result in duplicate entries in the RuleSet
list. For each set of duplicates, all matches are dropped except the
highest one. GAGNJ 11/20/06
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:
- 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.
|
access group,
application
rule, available
rule, circumstance, component RuleSet,
override
RuleSet, private RuleSet,
profile, rule check-out
facility, rule
resolution, shared RuleSet |
|
How the system finds rules
through rule resolution
|
Concepts