Show
all
Rule resolution is the search algorithm that
the system uses to find the best or most appropriate rule instance to
apply in a situation.
Rule resolution applies to all but a few rule types — classes that
inherit from the Rule- base
class. Rule resolution does not apply to instances of classes derived
from the Work-, Data-, or any other base
class.
While the rule resolution algorithm is fast and invisible, it is
important to understand how it operates. As you create applications, make
your choices of values for key parts based on how you want rules to be
found by rule resolution.
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, it accepts what is in the cache as the candidate rules and skips many steps in the resolution process (see below).
Benefits
The benefits of rule resolution include:
- Rules can be shared across applications and
organizations. Sharing and reuse are major benefits of object
oriented software development.
- Rules defined at a higher level can be overridden by
more specific rules defined at a lower level. While this dilutes
the sharing benefit, it provides often needed flexibility while
bringing visibility to exceptions.
- Rules can have multiple versions, even within one RuleSet, and
security rules control which users see and execute which versions.
This facilitates application evolution, testing, and
patching.
- One Process Commander system can host multiple applications,
multiple organizations, and multiple versions of one application
with minimal concern for conflicts and interference.
- Applications can be developed independently from other
applications, yet all can depend on common rules that are locked
(and so won't change).
Overview
The inputs to the rule resolution process are:
- The key parts of a rule instance being sought, such as its
Applies To class and name
- The user's RuleSet list, assembled when the user logs in
- The class hierarchy — The structure of parent classes and
subclasses below the ultimate base class
- The user's access roles and privileges held, determined by
the access group
- Security and access control rules such as Access of
Role to Object rules and Privileges
- Rule availability — Which rules are available, blocked,
final, withdrawn or not available
- Whether time and date limitations affect which rules are available for this session
- In some cases, the value of a circumstance property
The output of the resolution process is the first rule found
that matches all the criteria. (Sometimes no rule instance is found,
and execution stops.) The system then executes the selected rule. Often this
causes one or more additional rules to become needed. These
too are found by rule resolution.
The steps in the rule resolution process are:
Step 1: Check the Cache. If the rule is there, go to Step 8.
Using rules already in the cache avoids additional database lookups.
Step 2: Choose instances with the correct purpose.
The purpose, or "family name" combines all the key properties of a rule, excluding the "defined on" class.
For an activity rule, the key properties include:
- the Applies To class that the activity is defined on
- the activity name
The purpose in this case is the activity name.
For a Field Value, the key properties include:
- the Applies To class, as above
- the Field Name
- the Field Value
The purpose in this case is the Field Name plus the Field Value, for example "pyActionPrompt.ViewHistory".
The system chooses all items of the appropriate purpose and puts them in a temporary list.
Step 3: Discard rules where Availability = No.
The system drops unavailable rules from the temporary list.
Step 4: Discard inapplicable RuleSets and Versions.
The system drops from the list rules that belong to RuleSets and Versions that are not enabled for the current requestor. For instance, if the user's profile includes the RuleSet version ThisRuleSet: 05-01, rules belonging to ThisRuleSet: 04- or ThisRuleSet: 06- are dropped.
Step 5: Discard all candidates not defined in a class in the 'ancestor tree'.
Only rules found in classes from which the current class descends by either pattern or direct inheritance will be retained in the list.
This step is not used for rules which do not have the Use class-based inheritance to arrive at the correct rule to execute box checked in their class definition.
Step 6: Rank remaining candidates.
The system ranks the remaining rules on the list in order of
- Override (rules stored in an override RuleSet. These rules always move to the top of the ranking.)
- Class
- RuleSet
- Version
- Circumstance
- Circumstance Date
- Date/Time Range
Note that
- The RuleSet and Version rankings are based on the ordered list in the user's profile.
- A rule with a specific qualifier ranks higher than one with no qualifier.
- Circumstanced rules rank alphabetically by Circumstance value.
- Circumstance Dates rank in descending value.
- Date/Time ranges rank first by their end-date (in ascending order) and then by their start-date (in descending order).
- Rules which do not have the "Use class-based inheritance to arrive at the correct rule to execute" box checked in their class definition will not be ranked by class.
Step 6a: Discard choices that occur after the first "default" rule
A default rule (with no qualifiers defined) is considered a match for any Circumstance, Circumstance Date, or Date/Time range. Therefore, the process discards any rules lower in the list than the first default rule it finds.
Step 7: Set the cache.
The process adds the rules that remain on the list to the cache as being selectable for use.
Step 8: Find the best instance and check for duplicates.
The process searches down the list for the first rule that:
- exactly matches a Circumstanced Rule
- has the correct Circumstanced Date
- is in the correct Date/Time Range
- or is the default Rule, with no qualifiers
When it finds a rule that matches these conditions, the process checks whether the next rule in the list is equally correct. If it is, the process sends a message that there are duplicate rules in the system and stops processing.
If no duplicates are found, the system prepares to use the rule that matched the listed conditions.
Step 9: Check Availability is not Blocked.
The process checks Availability again, to see whether it is set to Blocked for this rule. If it is, the system sends a message that it could not find an appropriate rule to use.
Step 10: Verify requestor is authorized to see the rule.
The process finally verifies that the requestor has authorization to access the selected rule. If so, the system uses it. If not, is sends a message that it could not find an appropriate rule to use.
Example
Your use of an application can cause Process Commander
to search for a flow rule named Repair in the class
Work-Contract-Application-Complete. The system first examines in the
Work-Contract-Application-Complete class, and then (if no match is found)
searches higher classes in the class hierarchy. Only flow rules
belonging to RuleSets and versions that are present on your RuleSet
list are candidates.
Exceptions
A few rule types have instances that are not associated with a
RuleSet and version and no rule resolution processing occurs when an
instance of these classes is needed. For example, access roles
(Rule-Access-Role-Name rule type) must have names that
are unique system-wide.
Some other rule types do not support circumstance-qualified or
time-qualified processing.
Consult the help topic Completing the New dialog box for
each rule type for specific details.
Concepts