• The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
« Build Survivable, Hardened Cloud Processes with BPMN | Main | Do you have a process for business process management? »

A BPMN Pattern that Avoids Complex Merges

Arun Pareek In a blog post (here), described a solution to a process problem where three parallel tasks are executing. When one of the tasks completes with a particular condition, he uses a complex gateway merge to halt the execution of the other tasks. He called this ‘dead path’ cleanup. The original paper on dead-path elimination is here.

For you convenience, I will show Arun’s bpmn use case here:


The use case is for a security check that verifies Citizenship, Credit and Criminal checks. The topic of the dead path was the termination of one of the tasks Citizenship or Credit, when the criminal check had passed and one of the two activities, in pink, had completed.

In the Microguide to Process Modeling in BPMN, Rick and I do not support the use of the complex merge shape because they are confusing, and hide the logic that we are trying to build with our process modeling. All the logic from a complex merge shape can be defined in a subprocess. This example is a perfect demonstration of this. The fact that the ‘criminal background check’ result will cancel the citizenship and credit is hidden in Arun’s solution. Also hidden in the solution is the fact that the 'dead-path' elimination is an Oracle specific extension.

The recommended solution, with thanks for the help to Gilles Rabaud and Thomas Allweyer, shown here in an inubit (link) process modeler:



This BPMN:

  • Places the criminal check in a subprocess and the other activities in an enclosing subprocess
  • Starts these in parallel
  • Raises an exception to the border of the outer subprocess if there is a failure in the criminal check
  • For the credit and citizen check, the first activity to return a valid check escallates the inner subproces


 escallation and errors manage the threads in the same manner. The BPMN 2.0 spec explicitly provides for thread termination with the error event plus (conditionally) the escalation event.  

In my original post on this topic, several reviewers noted that I did not cover the exact use case described by Arun's post. The point of the complex merge was to cover the case where the Criminal Check passed and either the Citizenship or the Credit check passed (activities in Pink, here). In this case, you can place the Citizen Check and the Credit Check in a subprocess and when one passes then use the raise escalate the edge of the subprocess.

This shows the power of the escalate shape and makes it very clear what is happening.

While this approach requires more canvas, it is clearer what is happening and why. This said, I understand that Arun was merely demonstrating how to use a complex merge in the Oracle Tool.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (6)

Hi Tom,

Thanks for pointing to Arun's blog entry and the discussion of an alternative solution without a complex gateway. I am not convinced that your solution denotes the same behavior as Arun's model.

Let's assume that credit check is performed before the other two activities. If the credit check has a negative result, the complete sub-process will be aborted, so that the other two checks will never be carried out. However, a clearance should also be granted if the natural citizenship check turns out positive and there is no criminal background. This case is not covered in your model.

To my understanding it is not correct to cancel the entire sub-process right after the citizenship check and after the credit check. The abortion would only be okay when both of these two checks have failed (in this case the clearance must not be granted, regardless of the criminal background), or when one of these checks is positive and the criminal background check has already been finished with a negative result (in this case the clearance is to be granted, regardless of the result of the other check).


March 24, 2012 | Unregistered CommenterThomas Allweyer


Thank you for pointing this out because it gives us a change to demonstrate the escalate shape.

Your point is correct, although the usecase is semantically difficult to follow. The solution for that is to place the Citizen and Credit check into their own subprocess, have failed checks raise a error to the subprocess edge, and have a 'pass check' raise an escalation to an outside edge where the intermediate escalation transitions to the parallel merge.

I think this could be a useful pattern for a number of use cases, but the security use case generally requires the solution shown. One application might be obtaining the fastest quote response for a supply chain order.

I will post a correction to this.


March 25, 2012 | Registered CommenterTom Debevoise

Hi Tom,

Even your proposed corrected solution doesn't address quite a few concerns.

1. As mentioned by me in my original blogpost that the using a complex gateway makes your conditional processing faster (in most cases) as the gateway merge will abort all pending instances that are in process or being completed once the forward condition is met. Imagine a situation where each of the sub processes have User tasks. With the model you have now, how do you expect to kill a forked arm intermittently.
2. Your new model raises an error when the Credit Check or Citizenship Check fails. Why do you think that should be? We are interested in a situation where either of them passes.
3. The first argument you gave against the use of Complex Gateways is that it is confusing. Well looking at the model described in this post, It looks like it is more confusing and complex than the one with a Complex gateway

Your thoughts Tom


March 26, 2012 | Unregistered CommenterArun Pareek

Hi Tom,

yes, I think putting the citizenship and credit check into another sub-process is the right approach.

However, I think the new model is still not the final solution:
- What is the meaning of the third exit of the exclusive gateways, besides yes and no?
- Each of the "no"-branches still interrupts the outer sub-process. Therefore we still have the problem that a negative credit check causes a rejection, although the other two checks could both be positive.
- The outer sub-process will get stuck at the merging parallel gateway, since there is no way that three tokens can arrive via all entrances. The inner sub-process will emit a token only via the normal sequence flow or via the escalation flow.

Best regards

March 26, 2012 | Unregistered CommenterThomas Allweyer

Hi Thomas,

Thanks, I think the solution shown above adresses the race condition.

Hi Arun
The original paper on dead-path elimination is here: The paper provides a ‘logical’ approach using BPMN; but there is no special BPMN characteristic that cancels the dead paths. The check box that you show in your post is an Oracle-specific extension to complex merging. The BPMN 2.0 spec explicitly provides for thread termination with the error event plus (conditionally) the escalation event. Where the latter terminate threads in the subprocess if the tool specifies a non-interrupting intermediate escalation. Most people consider the latter behavior to be the default. So, there is no thread management in standard BPMN gateways, nor is there any attributes in the XML s. I maintain the solution shown is a more generic approach in standard BPMN, plus thread management is also correctly performed. The spec states that threads would be terminated with the intermediate error or escallation. The implementation will be BPMS specific.

The purpose of the BPMN spec is, citing Wikipedia:

‘The objective of BPMN is to support business process management, for both technical users and business users, by providing a notation that is intuitive to business users, yet able to represent complex process semantics.’

There is simply no way to visually inspect the complex gateway and derive the written spec in your blog, using conventional understandings of BPMN.

March 26, 2012 | Registered CommenterTom Debevoise

Brilliant Tom,

I must agree now that the solution presented now exactly covers the use case I covered originally. Thanks to both you and Thomas.

March 26, 2012 | Unregistered CommenterArun Pareek

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>