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:

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