Event correlation occurs for rules involving more than one event. For example, assume that we want to call on BPM Events to calculate the duration of a business process. Because the PI_COMPLETED event does not contain the actual duration, but only the completion date of the request, BPM Events needs to collect the starting date and completion date of each request. These values are respectively reported in:
The PI_ACTIVATED event which always contains the starting date of the request.
The PI_COMPLETED event which always contains the completion date of the request.
In addition to request date, request type, and request region, each of these two events also carries a request ID, which we consider the same as the process instance ID (stored in the PROCESSINSTANCEID attribute of the event). This request ID allows BPM Events to pair off the events related to the same request. The rule to calculate the event duration, named calculate_timeReq, is provided below:
rule calculate_timeReq
activated by
evt1 of BP Server::PI_ACTIVATED,
evt2 of BP Server::PI_COMPLETED
if (evt1.PROCESSINSTANCEID = evt2.PROCESSINSTANCEID)
then { val stat = ReqStats [evt1.reqtype][ evt1.region];
stat.avgtime ::= avg(duration(evt1.date, evt2.date)/60*60*1000, stat.count++, 1);}
The rule above executes the monitoring action each time a pair of related events (to the same request) is notified. The rule calculates the request duration by making the difference in hours (HOUR) between the two event dates, using the BPM Events function duration. It then recalculates the average response time. The plain English version of the rule is:
"On reception of an event of type PI_COMPLETED, find a past event of type PI_ACTIVATED, with same request ID, add 1 to the count attribute of the corresponding element of the infopad ReqStats AND calculate the time between the two event dates in hours, then update the average response time for this request type and region."
Note: The previous rule only triggers if there is a combination of two events that satisfies its condition.
When a rule does event correlation based on the process instance ID, as shown in the case above, you may write it a shorter way because it is not necessary to express the correlation condition (in the if clause). Indeed, BPM Events is preconfigured so that the BP Server events it received are indexed after their process instance ID attribute. Adding the clause correlated with INDEX to the rule, as shown in the code example below, instructs the rule engine to use this index to correlate events with the same process instance ID.
rule calculate_timeReq
activated by
evt1 of BP Server::PI_ACTIVATED, evt2 of BP Server::PI_COMPLETED
correlated with INDEX
then {
val stat = ReqStats [evt1.reqtype][ evt1.region];
stat.avgtime ::= avg(duration(evt1.date, evt2.date)/60*60*1000, stat.count++, 1);}
Note: Users can define their own message index for each message type. For example, you can create a message index for PurchaseOrder XML messages or for the customer ID field present in the XML body.
The PI_ACTIVATED event which always contains the starting date of the request.