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.
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.
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.
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.
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:
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 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):
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.
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.
Where b is another concept type and
num is one of its properties. The dependency set for this rule is
b.num and
c.
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.
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.
|
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 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.
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:
|
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 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:
In this case, a null pointer exception is not thrown when concept.containedConcept is null because it is always checked first.