Friday, 12 September 2008

Modelling Timer Interrupt in BPMN

Modelling Timer Interrupt in BPMN

Real-life processes are often limited by time and exception paths are taken when "Time's Up". The rich notation of BPMN provides for this. The BPMN 1.1 specification provides an example from Voting operations.

The normal sequence flow and error flow from "Moderate E-mail Discussion" in this case are merged into the subsequent activities but it is easy to imagine circumstances where the subsequent activities were  not identical.

Modelling this in BPMN using Intalio immediately presents a problem because error flows are not permitted to go anywhere beyond the error handler activity which may be a Sub-Process. (This is a compliance issue in Intalio v BPMN 1.1 specification ).

A further issue is that, in Intalio, the timer itself does not interrupt the activity within the sub-process. That is when the timer event is triggered, the error flow is executed and  the activities within the subprocess continue.
This is counter-intuitive and inconsistent with the implementation of the intermediate error event so is probably a bug. The BPMN 1.1 specification (10.2.2) only requires the error flow to be started, there is no clear direction as to the operation of the normal sequence flow. As a workaround in Intalio, to interrupt the flow within a subprocess by a timer, a fault has to be raised in the error-flow. To avoid that fault stopping the whole process, it has to be trapped and handled within the process (at an outer scope or subprocess boundary). How do other BPMN products treat the timer?

An explicit example of this is shown below. If the timer expires for the sub-process timed exec then execution is halted by the error end event in the error flow handler. This error end event is processed by the error handler activity fault in the outer subprocess.


Arnaud said...

Thanks David for highlighting a possible trap when trying to mix BPMN timer and execution. You pointed some behavior that might lead to confusion - even thought the executable version of the process follows the BPEL principles.

I am happy to report that we have decided to enable both behaviors in 5.3 and we will follow the BPMN specification as the default behavior.

Thanks for your support!


David French said...

That is good news Arnaud. I suggest that BPEL is submerged into the dark world of Intalio developers and that you concentrate on BPMN and its future. What I want is a business process that can be made executable without restructuring it rather than a really neat way to write BPEL. Neither BPMN nor BPEL are the ultimate in expression but BPMN is likely to be best in the hands of your target audience.

Phil Gilbert said...

Hi David,

First-time reader, first-time poster. There is such a product that executes BPMN: Lombardi Teamworks. Bruce points this out here -->

and I've blogged about this several times, including here -->

BPEL isn't BPM... it's anti-BPM. BPM is in large part about the empowerment of a new class of people in the design, development and deployment of their process applications. BPEL is JAWL. BPMN is the basis for an advance in the state of process ownership and process _management_.


David French said...

Thank you, Phil. I agree wholeheartedly and support the view that BPMN is what we should be concentrating on. From an architectural viewpoint I would like to see a way of moving business process models and executables around as organisations expand, takeover or are taken over.

Ghalimi said...


Sorry, but I have to disagree. You're misleading the market here. BPMN does not offer strong-enough semantics to support the execution of processes on their own, and you know it as well as I do. As a result, a BPMN-only product requires the extensive use of custom coding to turn the pretty picture into a running process. So, unless customers don't mind paying $250,000 for the software and twice or three times as much for professional services, they should look for a product that uses BPMN for designing the process at a high level, and BPEL for executing it. And yes, such a tool will require a fair amount of technical expertise to be put to good use.

Sorry, there is no magic nor silver bullet, and the longer BPM vendors keep telling fallacious story claiming otherwise, the longer customers will remain confused.