Try OpenEdge Now
skip to main content
BPM Events User's Guide
BPM Events tutorial : Using rules to populate infopads
 

Using rules to populate infopads

Once the infopad has been created in BPM Events, it is ready for use in a real-time environment. In order to populate the infopad previously described, BPM Events requires:
*Notification each time a new request comes in. The server (or the business process engine) posts a notification event to BPM Events. Such an event is expected to contain the following data: request type, request region.
*Execute a rule that reacts to the events above, and populate the infopad previously created. The rule below is executed each time a BP Server event of type PI_ACTIVATED is generated and BPM Events is notified.
rule monitor_startReq
activated by evt1 of BP Server::PI_ACTIVATED
then
{ ReqStats [evt1.reqtype][ evt1.region].count++ ;}
The plain English version of the rule above is:
"On reception of an event of type PI_ACTIVATED, add 1 to the count attribute of the element of the infopad ReqStats that corresponds to the request type and to the request region, as specified in the event."
Note: The rule does not have an if clause here: it is always successfully triggered when any event of type PI_ACTIVATED is notified. The rule then triggers when any instance of any process is activated. This works well if no other process than the customer request handling process is running. Assume, however, that we have two process types running: (1) the previous process named CustomerRequest, and (2) another process named AccountTermination. Both processes generate events of type BP Server::PI_ACTIVATED, but we do not want AccountTermination to trigger the rule. It is then safer to add a restrictive if clause to filter out AccountTermination events. Assume that the process is named "CustomerRequest".
A version of the monitoring rule that provides for two concurrently running processes follows:
rule monitor_startReq
activated by evt1 of BP Server::PI_ACTIVATED {PROCESSTEMPLATE NAME :
"CustomerRequest"}
then { ReqStats [evt1.reqtype][ evt1.region].count++ ;}
In case each of the four request types described in Table 3 is associated with a different business process, we can either use four rules like the one above or use an if clause of the form:
if (evt1.PROCESSTEMPLATENAME = "ProductOrder")or
evt1.PROCESSTEMPLATENAME = "Support")or
(evt1.PROCESSTEMPLATENAME = "ServiceOrder")or
(evt1.PROCESSTEMPLATENAME = "Training")