BPM Events tutorial : Using rules to control Business Process Server processes
Using rules to control Business Process Server processes
To illustrate the advantages of using rules to control business processes, consider the following purchase order business process. A new business policy decides to give a rebate of 10 percent to all customers who submit an order for a total amount greater than $500. We could hardcode this policy in the definition of the purchase order process, but it would not be easy to update later. Instead, we will use a rule to express this policy. Rules can easily be modified and activated dynamically, while the application is published and running.
The rule has the following behavior:
It triggers each time an order is submitted, on reception of an event generated by the process automation component of Business Process Server.
It checks the total amount of the order, as reported by the notification event.
If the amount is greater than $500, then it updates the discount attribute associated with this order process, to 10 percent. If not, it leaves this attribute at whatever value it was set initially.
The process automation component of Business Process Server is called BP Server, and it starts a new instance of the PurchaseOrder process each time a new order is submitted. When doing so, it generates an event named "PI_ACTIVATED" that BPM Events receives. The rule that captures this event, and decides if the discount is implemented, is written as follows:
rule bold_discount
activated by event1 of BP Server::PI_ACTIVATED {PROCESSTEMPLATE NAME :
"PurchaseOrder"}
if (event1.totalamount >= 500)
then {
val order = BLsession().getPI(event1);
order.setDataslotValue("Discount", 10);
}
The plain English version of the above rule is:
"On reception of an event of type BP Server and value PI_ACTIVATED of PurchaseOrder business process, and if the total amount attribute of this event (event1.totalamount) has a value greater or equal to 500 (>= 500), then identify the corresponding order instance, and set its Discount attribute to 10."
If you generate this rule using the Rule Editor, then notice that there is a single action statement generated, contracting the two statements in the previous then{} block:
then {
BLsession().getPI(event1).setDataslotValue("Discount", 10);
}
More generally, a rule has the following form:
rule <Rulename> activated by <event list> if <conditions> then {<actions>}
In the above example:
the rule name is: bold_discount,
the condition is: (event1.totalamount >= 500).
the main action is: order.setDataslotValue("Discount", 10);
This rule is typically an Event - Condition - Action (ECA) rule: that is, on the reception of one or more event(s), if these events satisfy the condition, then execute the actions.
As mentioned earlier, rules are very well suited for implementing business policies that may change over time, or have a temporary effect. Let us assume that the discount policy above is only effective for all orders submitted after December 31st, 2002 and before January 31st, 2003. We will use the following rule, called newyear_discount:
rule newyear_discount
activated by event1 of BP Server::PI_ACTIVATED {PROCESSTEMPLATE NAME :
"PurchaseOrder"}
if (event1.totalamount >= 500)
and (event1.date > YEAR:2002/MONTH:12/DAY:31)
and (event1.date < YEAR:2003/MONTH:1/DAY:31)
then {
val order = BLsession().getPI(event1);
order.setDataslotValue("Discount", 10);
}
The rule does exactly the same actions as bold_discount, only it is more restrictive: that is, the actions are executed only if the amount is greater than $500 AND if the date of the order is within the month of January 2003.
It triggers each time an order is submitted, on reception of an event generated by the process automation component of Business Process Server.