Comments on: BPMN and Business Rules

By: VernonS

VernonS — Sun, 22 Oct 2006 11:24:21 +0000

Agreed that the first case (reminder) is a timer event, however while the second event can be implemented as a timer event expressing it as a rule event seems more consistent. Escalation occurs if the reminder has triggered some number of times. Implementing as a rule allows the time event to be changed without having to worry about making any change to the escalation rule: the escalation logic is independent of the timer value. Personally I think this is a better approach. Easier to communication with a client, and clear in purpose. Decoupling unique requirements is a good thing.

I also still see both of these cases, timeout and escalation (based on a rule) as good examples of intermediate events, and BPMN supports modeling them quite well. I was focusing on this more from the modeling/BPMN perspective instead of a BPMS perspective.

From the BPMS perspective, BEPL of course supports timer events but doesn’t provide direct support for rule events (as I understand the specification). Of course you can implement these using service invocation constructs, but personally I prefer the conceptual approach provided by BPMN and see the lack of support for rule events more as a weakness of BPEL, but that’s just my opinion.

By: bruce

bruce — Sat, 21 Oct 2006 17:41:14 +0000

Vernon,
I’m in total agreement with you about the use case, but still the rule event seems superfluous and mismatched to the way BPMSs work. In your approval reminder example, the first reminder would be a timer event where the exception flow sends the reminder and loops back to the original activity. The escalation “rule” is just a second timer. According to Steve White, this should be modeled as a “multiple” event – I’m no fan of the multiple trigger because it hides the semantics from the diagram, but even if you attached 2 intermediate events to the activity (Steve says no), the second one could just as easily be another timer as a rule.

My frame of reference is usually the way BPMSs work. You are correct that there are 3 types of rules involved. Routing rules are gateways in BPMN. Decisions are tasks in BPMN, e.g. invoke a decision service on a rule engine, or perhaps a scrpt in the process engine. Where do you see event-triggered rules in BPMS? The one place I can think of is BAM. To have relevance to BPMN, the BAM event action has to affect the process flow. The BPMSs I know can do this in one of 2 ways: start a process (ok that’s a rule start event) or invoke a web service. I suppose you could twist the latter into an intermediate rule event by saying the web service sends an event to a process activity. But then why not call that a message event? I could agree that if that’s what you mean, a rule intermediate event is appropriate. But I think that implementation is pretty rare.

There are some BPMSs that use event rules more generally than in BAM, for instance Cordys and Savvion. See my reports on those products in the 2006 BPMS Report series for details.

By: VernonS

VernonS — Sat, 21 Oct 2006 12:01:47 +0000

I think there are some good uses for ‘rule’ in the Intermediate Boundary Event context. As a specific example consider an activity such as an approval. One might attach a timer to an such an activity to remind the approver to act on the activity on a timely basis. If after some number of notifications (let’s say 2) the approver still has not acted on the activity, a rule (as an Intermediate Boundary Event) could be invoked to escalate the activity to an alternative approver or supervisor.

Actually I perceive this type of ‘rule’ to be a fairly common event condition, and the rule as an Intermediate Boundary Event models this well. It’s also consistent with the BPMN definition of a Event, which is to the effect of “An event is something that “happens” during the course of a business process.”

Part of the confusion between this approach vs. what’s referenced as a rule in the context of ‘“Customer is New/Not New” and complex “Customer’s credit is good/bad”? One of these is about routing rules, one is about decision rules’. While we may refer to these as Business Rules, I wouldn’t necessairly consider it a rule in the context of an ‘Event’ which is the general way I understand rules to be intended within the context of BPMN (as quoted in the paragraph above). Instead, I would consider these to be business logic. This logic could be implemented by invoking a rules engine or through the Gateway constructs, but trying to implement it using the an Event rule seems inappropriate.

I think the key here is making sure we don’t confuse business rules with a BPMN event rule. While they share a word in common in their general definition, their intent is quite different.