When a rule does event correlation, it can be triggered on any of its event variables. However, because the events correlated by the rule often follow a sequential pattern, we know what should be the last event of the sequence. For example, consider the following rule:
rule my_process_completed
activated by
EVT_A of BP Server::PI_ACTIVATED{PROCESSTEMPLATENAME : "Assign_A_Task_V2"},
EVT_B of BP Server::W_ACTIVATED{WORKSTEPNAME : "DoTask", PROCESSTEMPLATENAME :
"Assign_A_Task_V2"},
EVT_C of BP Server::PI_COMPLETED{PROCESSTEMPLATENAME : "Assign_A_Task_V2"}
correlated with INDEX
if (...)
then {
perform(<some action>);
}
Clearly, the three events to correlate, EVT_A, EVT_B and EVT_C, are expected to notify BPM Events according to this same sequence. In that case, it is useless for the rule engine to activate the rule on the variable EVT_A or EVT_B, because it will not find in the event store an event of type BP Server::PI_COMPLETED to correlate with or that comes from the same process instance (same INDEX value, or PROCESSINSTANCEID). Indeed, by the time the engine receives EVT_A or EVT_B, no completion event has yet been notified for this process.
The above rule triggers successfully once the BP Server::PI_COMPLETED event is received. It should then only be triggered by events that match EVT_C. We can specify event variables that should NOT be used as triggers on the rule, by prefixing them with "*" (star). The rule my_process_completed_2 below provides the same outcome as the rule my_process_completed above, except that its execution is faster, because it is not unnecessarily triggered each time an event matching EVT_A or EVT_B is notified.
rule my_process_completed_2
activated by
EVT_C of BP Server::PI_COMPLETED{PROCESSTEMPLATENAME : "Assign_A_Task_V2"},
*EVT_A of BP Server::PI_ACTIVATED{PROCESSTEMPLATENAME : "Assign_A_Task_V2"},
*EVT_B of BP Server::W_ACTIVATED{WORKSTEPNAME : "DoTask", PROCESSTEMPLATENAME : "Assign_A_Task_V2"}
correlated with INDEX
if (...)
then {
perform(<some action>);
}
Only after receiving an event matching EVT_C, the rule looks up the event cache for past events matching EVT_A and EVT_B, attempting to correlate with them. We recommend that you put the disabled event profile at the end of the activated by clause—as shown in the rule above—since this has a positive impact on the performance of the rule evaluation.
Note: When disabling event variables as rule triggers, the rule engine ignores any sequence of event that uses these variables as the most recent event. Even if some event is normally not expected to be the most recent (the triggering event) of a combination, this may happen sometimes. Indeed, because of event channel latency—especially if events come from various sources—the actual notification order to BPM Events may not always reflect the origination order. In such cases it is prudent not to disable these event variables.
