How the system finds rules through rule resolution

The benefits of rule resolution include:

• Rules can be shared across applications and organizations. Sharing and reuse is a major benefit of object oriented software.
• 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)

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 class hierarchy — The structure of parent classes and subclasses below the ultimate base class
• A user's RuleSet list, assembled at log in
• The user's access roles and privileges held, determined by the access group
• Numerous 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
• The time and date and (in some cases) an as-of date
• In some cases, the value of a circumstance property

The output of the entire resolution process is the first rule found that matches all the criteria. (Sometimes no rule instance is found, and execution stops). The selected rule is then executed. Often this execution causes one or more additional rules to become needed. These too are found by rule resolution.

The search always is restricted to rules that match the rule type of the needed rule (such as Rule-Obj-Property for property rules) and a name or key part.

For most rule types that contain an Applies To class as a key part (generally, those derived from the Rule-Obj- class) the search starts at the lowest level of the class hierarchy that matches the class key part of the partially specified rule instance, and works up to the top (the ultimate base class) gathering all the matches on the name as found.

For rules that don't contain an Applies To class as a key part, such as Rule-HTML-Fragment, every rule with the supplied name (at all levels) is found.

In this phase, the meaning of "works up the hierarchy" depends on the type of inheritance defined for each class. The parent class of each class is designated in the Rule-Obj-Class instance. Process Commander uses two distinct approaches to finding parent classes — known as directed inheritance, and pattern inheritance, and both of these can be present and used in the class structure.

The set of candidate rules resulting from phase 1 that are marked as not available, blocked, or withdrawn are excluded.

For the remainder, the RuleSet and version associated with the rule instance are matched against the RuleSet list of the user. Those rule instances with RuleSet names and versions not matching the RuleSet list of the user are excluded.

A user's RuleSet list may contain full version numbers, such as 01-15-07, and partial version numbers such as 01-15. The partial version number matches any value for the omitted portions. (The first two digits, known as the major version, must match the rule version. If your RuleSet list contains ALPHA:04-17-21, none of the rules in ALPHA:03-NN-NN are available.)

Some rules, known as time-qualified rules, are in effect only during a specific time interval. If any of the candidate rule instances produced by Phase 2 above are time-qualified, the system uses the current system date and time to find those that are in force. Any others are eliminated.

If two or more time-qualified rules are both candidates at the current time and date, the system selects the ones with the nearest end date. Of these, if multiple candidates have the same end date, the system picks the candidate with the most recent start date.

This filtering corresponds to the Timing shape on the diagram.

If any of the candidate rule instances produced by Phase 3 contain a circumstance property reference, a user's clipboard value for this property reference (if defined) is compared against the property value in the rule. If a match is found, the rule instance is retained for Phase 5 (and the "unqualified" rule instance with a blank circumstance fields is dropped). If the circumstance value in the rule does not match the user's clipboard value, the qualified rule instance is dropped from the candidate set.

Phase 5 excludes rules that the user (or requestor process) cannot execute for security or access control reasons.

Every user holds one or more access roles and optionally one or more privileges. Access of Role to Object rules for these access roles determine which classes the user with that rule can operate on, and how.

Using rule resolution, the system finds an Access of Role to Object rule that is keyed by the access role and the Applies To class (or a parent of the Applies To class) using rule resolution. This rule determines whether the user can execute rules with that class.

In addition, flow rules, correspondence rules, and a few other rule types may contain an associated list of privilege requirements. The requestor process must have access to one of the privileges before execution can start.

Some rules also reference one or more when condition rules that must all evaluate to true before the rule can be executed.

These tests further reduce the collection of surviving rules.

If no rule instances survive the above five phases, the user process is notified of the "no rule found" condition. If only one rule instance survives, it selected and executes. If more than one is found, the one lowest in the class hierarchy — closest to the Applies To class — is performed.

Execution of one rule may naturally call for other rules to be found and executed. The same rule resolution search process finds each of the referenced rules.

For 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 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.

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. Rule types that don't include an Applies To class as a key part don't use the Phase 1 class hierarchy lookup described above.

Consult the help topic Completing the New dialog box for each rule type for specific details.