Try OpenEdge Now
skip to main content
BPM Events User's Guide
The rule language : Controlling rule execution : Avoiding unnecessary or unwanted rule executions
 

Avoiding unnecessary or unwanted rule executions

When an event is notified to BPM Events, this event could trigger many rules, that is, it can satisfy the Condition part of these rules. Consider the situation where if a rule evaluation succeeds on an incoming event (EVT_A), then we do not want to pursue the evaluations of other rules that could be triggered by the incoming event. For example, the following set of rules {Rule_R1, Rule_R2} handle different critical situations in a similar way (each rule generates the same kind of alarm). But if both rules can apply, we do not want to generate two alarm events. In that case, one can add the clause: terminated with FIRST_SUCCESS, immediately after the event header. If the rule is triggered (that is, its condition succeeds, and its action part is executed), then this clause prevents EVT_A from triggering any other remaining rules.
rule myrule1
activated by
EVT_A of disk_problem::failure,
EVT_B of payroll_status::running
terminated with FIRST_SUCCESS
if (EVT_A.host = EVT_B.station)
then {
sendMail("paul@abc.com","critical disk failure while payroll running",EVT_A);
}rule myrule2
activated by
EVT_A of disk_problem::failure
terminated with FIRST_SUCCESS
then {
sendMail("paul@abc.com","critical disk failure",EVT_A);
}
Assume that a triggering event EVT_A of type "disk failure" comes in, and that an event which satisfies the condition on EVT_B is already logged in the event cache of BPM Events already. This means that both rules can succeed when EVT_A comes in. However, we want only one to succeed (the first one). The termination clause guarantees that no matter which rule is evaluated first and succeeds, only one alarm is generated: the other rule is not tried. So, if the payroll program was running on weekdays when the failure occurs, then only one alarm is generated. When using this mode, the order of the rules in the rule file is important.
A rule can also select events based on their type alone, not just their combinationtype::value. In the previous example, in case any event of type disk_problem must trigger the rule (not only disk_problem events reporting a failure), then the rule should be:
rule myrule1
activated by
EVT_A of disk_problem::,
EVT_B of payroll_status::running