In Business Process Modeling Notation (BPMN), an attached intermediate event is modeled as shown below. It means that the event could occur any time while the task is executing. In the example below, a Timer (or Message or Error etc.) intermediate event could go off while activity Task X is going on. If the event occurs, the process would follow its path and execute Task 2, otherwise it would execute Task 1. 

 

But I wouldn't be writing this blog if the life was so simple. While the BPMN specification isn't explicit, it does indicate that such an intermediate event results in an exception flow (see section 10.2.2 of the specification), which interrupts the normal flow. English translation of this means if the timer goes off, Task 2 will execute, Task X will terminate and Task 1 will not execute. Since the exception flow 'merges' back into the normal flow, Task 3 will execute and so on. Below, I have shown two examples with intermediate events. In the first case the behavior described above would be acceptable but in the second case it wouldn't.  

 

In the first diagram (left) if order cancellation Message is received, the Process Order task should terminate, the normal flow should terminate (Ship Order should never execute) and control should be turned over to the exception flow to execute Cancel Order task - just like it's described in the specification. 

In the second diagram (right) however, we don't want to terminate the normal flow. If the Underwrite Application task takes too long and hence interrupted by the timer intermediate event, we would like to Notify Manager but we would also like to continue to underwrite the application and eventually record the decision. If you strictly go by the specification, it doesn't support modeling the second scenario. Industry experts have been asking for non-aborting attached intermediate events.  

This strict definition of an attached intermediate event turning the normal flow into an exception flow has never been a problem for me because I chose convention over configuration. Here are some of my recommendations about attached intermediate events:

• Most of the business scenarios at my client require non-aborting attached intermediate events. So, I recommend that by default, attached intermediate events be treated as non-aborting event (I will explain the rationale in a minute)

• If we need an aborting attached intermediate event then we put a note in the model

• An attached intermediate event of type error be treated as aborting intermediate event

These recommendations work well for me because they make the models look consistent. While there is a work around in BPMN to model non-aborting intermediate events, it makes the model complex. Using convention over modeling, I keep the models simple. In most cases (at least for me) the implementation language for business models created in BPMN is BPEL, which does NOT terminate the task or normal flow when attached intermediate event occurs. Only in case of an Error event does BPEL terminates the current task and normal flow (hence the convention described in the bullet points above). So, from the implementation perspective this convention makes sense. While only a few tools generate correct BPEL out of BPMN, I have not seen any tool that generates BPEL that would terminate the normal flow in case of an intermediate event. In a nut shell, while there is a discrepancy between BPMN and BPEL specification, it's not been a problem for me so far.  

Now, about updating the specification to allow non-aborting intermediate events. The solution is simple (I hope OMG is listening). BPMN specification defines an attribute called Target for an intermediate event. Specifying a sub-process or a task as a target of an intermediate event means the event is attached to that sub-process or task. I recommend that we introduce another attribute called Abort, which would take the value True or False. The specification could force Abort attribute to be specified every time Target attribute is specified OR it could provide a default value of False for Abort attribute . The specification does do something like that today: When Trigger attribute has value of Timer, Timedate or TimeCycle attribute is required.

If you are using a tool that can generate implementation code with a terminating intermediate event, let me know. In the mean time feel free to use convention until the specification is updated.