Chapter 9 Working With Rules and Functions : Understanding Conflict Resolution and Run to Completion Cycles

Understanding Conflict Resolution and Run to Completion Cycles
This section helps you to understand what triggers rules to execute, and why a rule may not execute, so that you can design rules more effectively.
The flowchart below illustrates one run to completion (RTC) cycle, which generally begins when an external action causes changes to working memory. One RTC cycle ends when there are no more rule actions to execute as a result of that initial change. This is also known as forward chaining, or inferencing. During one RTC no new external actions can affect the working memory. An RTC is composed of one or more conflict resolution cycles. A conflict resolution cycle begins when BusinessEvents builds (or refreshes) a rule action agenda, which is used to determine which rule action to execute, and ends when a rule action is executed (or the agenda is empty). If the rule action changes working memory, another conflict resolution cycle begins. Sections following the flow chart provide more detail.
A change in working memory initiates the first conflict resolution cycle in the RTC
Working memory changes  The first of the conflict resolution cycles is initiated by change in working memory caused by an external action such as a message arriving at a destination.
All other changes to working memory during one run to completion cycle (RTC) occur because of rule actions. When there are no remaining rule actions on the agenda, the run to completion cycle ends. The next cycle begins with another change from an external source.
BusinessEvents builds the agenda  To build the rule action agenda, BusinessEvents examines all rules that are newly true because of the change to working memory and compares them with rule dependencies. See How a Rule Becomes Newly True and How Conflict Resolution Uses Rule Dependencies for more details. The agenda’s entries are ordered according to rule priority and other criteria.
Executing a rule ends each conflict resolution cycle
BusinessEvents executes the first rule on the agenda and removes it from the agenda  As a result, one of the following occurs:
The rule action does not change working memory and BusinessEvents executes the next rule entry in the agenda (if there is one).
OR
The rule action does change working memory and BusinessEvents refreshes the rule action agenda to account for the changes.
Note that events are not sent to destinations until the entire RTC is complete.
BusinessEvents refreshes the agenda  Any of the following can occur:
Rules that were newly true at the last conflict resolution cycle and are still true remain in the agenda. (In other words, rules are newly true for the duration of the run to completion cycle unless they become false.)
As a result, either the agenda is empty and the RTC ends, or the first rule in the refreshed agenda is executed and a new cycle of conflict resolution begins.
An empty agenda marks the end of one RTC
An empty agenda ends the RTC  At some point, no more actions remain to be executed. The conflict resolution has run to completion.At the end of one RTC the following happens (depending on how the project has been configured:
How a Rule Becomes Newly True
As stated above, the rule action agenda is built by examining all rules that are newly true. A rule is newly true if it has become true due to a change in working memory.
A rule that was false and becomes true because of the changes in working memory during the RTC is newly true.
Less obviously, a rule that was already true can also become newly true. For example, a rule may already be true because a condition that specifies a range is satisfied. It becomes newly true if the property value in working memory changes but is still within the range. For example, the condition c.b<10; is true if working memory includes a c.b with value 9. It is newly true if an action at the end of a conflict resolution cycle changes the value from 9 to 8.
In the case of a rule with no conditions, it is the assertion of an object in the scope (declaration) of the rule that makes the rule newly true.
A rule remains newly true until it is executed or it is removed from the agenda, or the RTC ends.
A rule is removed from the agenda because a change in working memory during an RTC means that the facts no longer satisfy its dependency set, for example because a concept instance is deleted or a concept property changes value.
How Conflict Resolution Uses Rule Dependencies
Before any data enters the system, BusinessEvents builds the Rete network, which embodies all the rule dependencies, using the rule conditions (if any). All the dependencies in a rule are called its dependency set. A rule’s dependency set is everything needed to determine the truth of all the conditions. For example, a rule has this condition:
c.name == "Bob";
Where c is a concept of type /Customer. In this case, the dependency set of the rule contains only the name property of the concept type /Customer. As another example, suppose a rule has these conditions:
b.num<10;
hasAGoldMembership(c);
Where b is another concept type and num is one of its properties. The dependency set for that rule is b.num and c.
Testing the Truth of a Rule’s Conditions Using the Dependency Set
During a conflict resolution cycle, BusinessEvents tests each rule’s dependency set against the new set of facts. If the facts match the rule dependencies, the rule conditions are all true and the rule action is added to the rule action agenda. The structure of the Rete network enables very quick matching between facts and rule dependency sets.
If BusinessEvents cannot calculate dependencies on the properties of an entity from the rule condition, for example if you pass an entity to a function, BusinessEvents evaluates the rule every time the entity or its properties changes.
Order of Evaluation for Different Types of Rule Conditions
Using a rule’s dependency set, BusinessEvents evaluates the following kinds of rule conditions in the order shown, to perform the evaluation efficiently.
1.
2.
Equivalent join conditions, that is, conditions that compare two expressions using == or != where each expression involves one (different) object from the scope.
3.
Class filters are the least expensive operations, in terms of processing cost, and non-equivalent joins are the most expensive. To optimize performance, ensure that as much filtering as possible is done first, to reduce the number of objects for which an expensive condition must be evaluated.