Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 5 Run-time Inferencing Behavior : 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.
Run to completion cycle
A run to completion, or RTC, cycle generally begins when an external action causes changes to the Rete network. It ends when there are no more rule actions to execute as a result of that initial change (and any subsequent changes caused by rule actions). This is also known as forward chaining, or inferencing. During one RTC changes can occur in the Rete network, but no new external actions can affect it.
Figure 5 Run to Completion Cycle
Conflict resolution cycle
One RTC is composed of one or more conflict resolution cycles. A conflict resolution cycle begins when TIBCO BusinessEvents builds (or refreshes) a rule action agenda, a list of all rules that are eligible to fire. The agenda is used to determine which rule action to execute next. The agenda is built based on the following information:
One conflict resolution cycle ends when a rule action is executed (or the agenda is empty). If the rule action changes the contents of the Rete network, another conflict resolution cycle begins.
A More Detailed Look
The Rete network changes  The first of the conflict resolution cycles is initiated by change in the Rete network, caused by an external action such as a message arriving at a destination.
All subsequent changes to the Rete network during one RTC occur because of rule actions.
TIBCO BusinessEvents builds the agenda  To build the rule action agenda, TIBCO BusinessEvents examines all rules that are newly true because of the change to Rete network and compares them with rule dependencies. The agenda’s entries are ordered according to rule priority, rule rank, and other criteria.
See How the Rete Network is Built and How a Rule Becomes Newly True for more details.
TIBCO 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 the Rete network and TIBCO BusinessEvents executes the next rule entry in the agenda (if there is one).
OR
The rule action does change the Rete network and TIBCO BusinessEvents refreshes the rule action agenda (see next section).
TIBCO BusinessEvents Express  Content relating to Cache OM and backing store is not relevant to TIBCO BusinessEvents Express edition.
Next conflict resolution cycle
TIBCO BusinessEvents refreshes the rule action agenda  If a rule action changes the contents of the Rete network, the agenda is refreshed, beginning a new conflict resolution cycle. When the agenda is refreshed, 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, ending this conflict resolution cycle and beginning the next one.
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. The RTC is over. Now begins the post RTC phase. At various points during this phase the following actions happen (depending on how the project has been configured):
Berkeley DB (Persistence) OM: (This feature is deprecated.) One transaction is completed and saves changes (enabling rollback in case of failures).
How the Rete Network is Built
Before any data enters the system, TIBCO 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
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 this rule is b.num and c.
Testing the Truth of a Rule’s Conditions Using the Dependency Set
During a conflict resolution cycle, TIBCO 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 TIBCO BusinessEvents cannot calculate dependencies on the properties of an entity from the rule condition, for example if you pass an entity to a function, TIBCO BusinessEvents evaluates the rule every time the entity or its properties changes.
How a Rule Becomes Newly True
A rule is true if objects in the rule scope exist in the Rete network and if all of the rule conditions are met by objects in the Rete network. However when building the rule action agenda, TIBCO BusinessEvents examines only rules that are newly true.
A rule is newly true if it has become true due to a change in the Rete network during the current RTC.
In the case of a rule with no conditions, assertion of an object in the scope (declaration) of the rule makes the rule newly true.
A rule that was false and becomes true because of the changes in the Rete network 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 the Rete network changes but is still within the range. For example, the condition c.b<10; is true if the Rete network 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.
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 the Rete network 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.
Order of Evaluation of Rule Conditions
The order in which conditions are evaluated is determined internally by TIBCO BusinessEvents. Using a rule’s dependency set, TIBCO BusinessEvents evaluates the following kinds of rule conditions in the order shown, to perform the evaluation efficiently.
1.
Filters, that is, conditions that only involve one scope element (object). Filters are the least expensive operations, in terms of processing cost. For example:
   Customer.type = "gold";
   Customer.numOrders > 50;
2.
Equivalent join conditions, that is, conditions that compare two expressions using == where each expression involves one (different) object from the scope. Equivalent joins take more processing than filters, but less than non-equivalent joins. For example:
   Customer.accountMgr == AccountManager.id;
3.
Non-equivalent join conditions, that is, conditions involving two or more scope elements other than equivalent joins. These are done last because they are the most expensive in terms of processing cost. For example:
   Customer.numOrders < AccountManager.threshold;
   MyFunctions.match(Customer, AccountManager);
To optimize performance, do as much filtering as possible, to reduce the number of times TIBCO BusinessEvents evaluates a join condition.
Enforcing the Order of Condition Evaluation
To enforce the order of evaluation between two or more conditions, put them on the same line (that is, in one statement ending in a semicolon) joined by the logical operator &&.
Be aware of some differences in execution when you combine conditions. For example, consider the following separate conditions. A null pointer exception might be thrown if concept.containedConcept is null, if the second condition was checked before the first:
concept.containedConcept != null;
concept.containedConcept.property == "test";
You can, however, combine the conditions as follows:

 
concept.containedConcept != null && concept.containedConcept.property == "test";

 
In this case, a null pointer exception is not thrown when concept.containedConcept is null because it is always checked first.

Copyright © TIBCO Software Inc. All Rights Reserved