Overview of rule resolution

Article ID PRKB-25168 Rate This Article

Category Reuse and Version Management
Applies from PRPCV504 • Currently 3.7/5 Stars.
Last Updated March 24, 2008 • 1
• 2
• 3
• 4
• 5
Rated 3.7/5 stars

Summary

Rule resolution is the internal process by which Process Commander

decides at runtime which rule (of a set of candidate rules) to execute.

Suggested Approach

Process Commander models data by defining it in a class hierarchy, following an object-

oriented paradigm (much like Java). Classes are subdivided into Rules and other types of
classes (such as Data, Work, Code, etc.).

Rules are all instances of classes which descend from the Rule- base class, including activities
(Rule-Obj-Activity), streams (Rule-Stream), models (Rule-Obj-Model), properties (Rule-Obj-
Property), and others. Many rules are defined as aspects of Process Commander Classes,
much like Java methods and member variables are aspects of a Java class. Just as Java
methods can be inherited from the Java class’s parents, rules in Process Commander such as
activities can be inherited from the defined class hierarchy.

Classes are defined in a hierarchy of parents and children, starting with a special class called
@baseclass. When looking for a rule defined on a particular class, rules defined on that class
are checked, as well as rules defined on the class’s ancestors. It is possible to have multiple
copies of activities, streams, or other aspects of a class, all of which are different, and any one
of which may be used, depending upon the situation present when the object is called.

Rule resolution is the process by which Process Commander decides which rule (of a set of
candidate rules) to execute.

Rule resolution occurs whenever you need to use a rule to accomplish processing. Since
many different rules could be applied, rule resolution winnows all the candidate rules down
to calculate the most accurate way to do the processing. The rule selected is the one most
appropriate for the situation .
For example, you may be working with an instance of the class Acme-Auto-ClaimsEntry, and
may execute an activity named Display. If the system finds that there is an activity Display
that is defined both on Acme-Auto and on Acme-Auto-ClaimsEntry, it chooses the latter
instance, as that is closest to the definition of the class structure of the instance.

Rule resolution begins by selecting all the possible rules with a particular name of a
particular type (activities, when rules, etc.). (In other words, if the system is looking for the
activity Display, then it would not select any flows or properties that were named Display – it
would only choose rules that were activities.) Each rule is named by using one or more key
properties which describe that rule’s purpose or behavior; all the rules with matching name
values are chosen.

For example, the activity Display could be called on the class Acme-Auto-ClaimsEntry. At
runtime, all the activities called Display that are defined on Acme-Auto-ClaimsEntry or
ancestors of Acme-Auto-ClaimsEntry are chosen, including rules in different RuleSets,
different versions, different date/time ranges, and different circumstances. The object in
question may be defined differently in all these places, or there may be duplicate definitions
in different classes or RuleSets.

The goal of rule resolution is to select just one rule that is the most accurate to be applied in
the situation. If rule resolution completes and finds s no valid rule, then the system reports a
“Rule Not Found” error. If instead it finds more than one valid rule, it returns a “Multiple
Rule Version Exception” error.

Rule resolution follows multiple steps or stages to determine which one rule is the result to
execute. Beginning with a large set of possible rules for the situation, the rule resolution
process selects the best available rule, using the following process.

1. Check the rule cache. If the rule is present in the cache, go to Step 8.

2. Choose all instances with correct purpose

3. Discard rules where Availability = No/Draft

4. Discard inapplicable RuleSets and Versions

5. Discard all candidates not defined on a class in the “ancestor tree”

6. Rank remaining candidates by: Class, RuleSet, Circumstance, Circumstance Date,

date/time; remove all that are withdrawn or hidden by other withdrawn candidates

6a. Discard all choices that occur in the ranked list after the first “default” rule

7. Set the cache

8. Find best instance (and check to make sure there is not a duplicate)

9. Check that Availability does not show BLOCKED

10. Security – Verify that the user is authorized to see the rule
NOTES:

• These steps occur in the order listed above. Thus, if there is a rule which has a
particular circumstance defined, but it is discarded due to its RuleSet and Version, the
circumstance is never checked.

• In Version 4.2, one of the steps in rule resolution limits the possible rules to those in
the best class. Beginning in Version 5.1, rule resolution functionality is enhanced so
that not only that class, but other classes in the ancestor tree of that class, are
considered and ranked.

• Also in Version 4.2, the system assembles a user’s RuleSet list from RuleSet Lists
contained in various instances: Requestor Type, Organization, Division, and Operator
ID. Beginning in Version 5.1, the user's RuleSet list is assembled from application
rules specified in access groups in those instances.

• Not all rule types support rule resolution, and not all the qualifiers for rule resolution
are valid for rules which use rule resolution. In releases prior to Version 5.4,
Circumstances and Date/Time ranges are not supported for declarative rules,
including:

• Rule-Declare-Expressions
• Rule-Declare-Constraints
• Rule-Declare-OnChange
• Rule-Declare-Trigger
• Rule-Declare-Index
• Rule-Declare-Pages

• Beginning in Version 5.4, Circumstances and Date/Time ranges are supported for
Declare Expression rules, Constraints rules, and OnChange rules