General semantics of rule loading and rule execution

The set of rules in the engine are called the current rule base. These rules are indexed and organized depending on which events activate them. An event that can trigger several rules triggers them in an order unknown by the user. In other words, do not assume that rules will be executed in the same order as the order in which they are written in a module. When an event triggers two rules, you do not know which one will be triggered first. The only way to enforce the execution order of two rules R1 and R2 when processing an event E, is to chain these rules explicitly, using an internally generated event. Assuming R1 activates before R2, then only R1 should be activated by E. R1 then generates an event E which carries over information from E, and triggers R2.

Principle 2: The sequencing of module loading and unloading

When a module of rules loads into the rule engine, if this module imports other modules, then these modules are loaded first. This means that their initialize{} section is executed before the initialize{} section of the importing module. Conversely, when a module unloads, it unloads before unloading its imported modules. This means its finalize{} section is executed first, before the finalize{} section of the imported modules.

Principle 3: The ordering of events is based on their notification time

Incoming events execute in the order of their notification and are based on the time they are notified to the engine or to the queuing system, which may be different from their origination time as it appears in their date attribute.

Principle 4: The processing of external events is serialized

The processing of an external event (see Event management section) includes the evaluation of all the rules this event can trigger. In turn, this includes the execution of corresponding actions, as well as the evaluation of the rules triggered by internal events generated by these actions (closure of rule chaining). We call the set of all these cascading actions the action closure of the event. This principle states that the processing of the next external event does not start before the action closure of the current event is completely processed.

Principle 5: The rule engine is forward chaining only, breadth-first

Rules trigger each other through internal event generation. On reception of an event, either external or internal, rules first execute their condition part (if clause), then their action part (then clause). The rule engine is then doing forward chaining, breadth-first. It is, however, possible to write rules so that they emulate backward-like reasoning, like starting from hypothesis in diagnostic systems.

Principle 6: The execution order of actions in a rule is sequential

The action part of a rule is a sequence of actions, executed in the same order. The effects of an action (that is, infopad modification) is visible to the next action in the same rule.

Principle 7: When rules trigger other rules, the action tree is executed breadth-first

When an action in a rule R generates other actions (by generating an event that trigger other rules), these actions are executed after all remaining actions in R. Assume the sequence of actions of a rule is: A1, A2, A3. When A2 executes, and if it generates an internal event, then the processing of this internal event is likely to trigger rules: the actions entailed by these rules are executed after A3. More generally, the chaining of rules execution defines an action tree. This action tree is executed breadth-first, not depth-first. This principle is a corollary of (5) and (6).

Principle 8: The event correlation tries all possible event combinations, using events older than the triggering event

When an event E triggers a rule R that does event correlation (a rule using event variables E1, E2), then the processing of R on reception of E tries all possible combinations. If E matches with E1, it tries all possible pairs (E, E2) by searching previous events in the event cache that match the rule conditions on E2. Then the search is done for (E1, E) pairs if E also matches E2 type.

In any case, the triggering event is always correlated with earlier events (that is, events with an earlier reception date) that are already in store.

Note: Events received before the triggering event in turn trigger the rule later, so no event combination is forgotten. This is the case for correlated events with an earlier origination date than the triggering event (date attribute), but were received after due to some latency problem.

Principle 9: Event discarding that occurs during the processing of an event e has no side effect on the entire processing of e

If an action of the action closure of E is an event discard (of E or of any other correlated event), then this does not affect the set of actions generated in the action closure. In other words, the order in which rules are triggered by an event does not matter with regard to event discarding actions. When an event E1 triggers several rules, the action of discarding an event E2 is delayed until all rules triggered by E1—and possibly correlating E2—have been triggered (E2 can be same as E1).

Principle 10: Actions other than discard may have a side effect on the evaluation of the next event combination, in a rule doing event correlation

When an event E1 triggers an event-correlating rule that is then evaluated several times (for each possible combination of events), the effects of any action (that is, infopad modification) are visible to the next evaluation of the condition part for the same rule. Therefore it is recommended that you do NOT write correlating rules that contain actions potentially affecting the outcome of their conditions.