Highlights from BPMN 2.0: Non-Interrupting Events

Blog: ProcessModeling.info

What’s new in BPMN 2.0, part 4.

BPMN 2.0 adds a lot of new concepts. Many of these are long overdue to be added to the spec. Others are a totally new concept. In this post we are going to take a look at one of the long-overdue fixes to the BPMN specification; the intermediate events on the subprocess border.

In previous versions of BPMN, placing an event on the subprocess border meant that when the event was triggered, the exceptional flow would become active. Also, this means that normal flow stops. In the diagram below, subprocess A ceases when the timer event is triggered. Instead, the “handle timeout” subprocess is active at that point. In other words, subprocess A has been interrupted.

Intermediate Interrupting Event

There is another use case that BPMN 1.2 did not cover. What if the timer event isn’t supposed to interrupt subprocess A? Just to clarify, in the BPMN 2.0 specification, Interrupt means that the parent subprocess will end. This is similar to a cancel, but cancellation is another concept and another shape entirely. So it’s called interruption. There is another use case for non-interrupting events that has long been a challenge prior to 2.0.

Interrupting and Non-Interrupting Events

Introduced in BPMN 2.0 is the concept of non-interrupting events. They are illustrated with a dashed line instead of a solid line.

Intermediate Events (catching)

The difference is that when the event is triggered, the exceptional flow occurs in parallel to the main flow. This means that you need to be careful how you use it. Special attention is needed to how the two paths merge. I recommend treating it just like any other parallel situation, using a gateway to merge. But which gateway? Parallel would be the obvious choice. But remember that a parallel considers all paths to be active on the merge. This would cause a process deadlock if the event was never triggered. Instead, the recommended merge shape is the inclusive gateway.

Intermediate Non-Interrupting Event

The gateway is used for flow control. Without it, a potential exists that someone could misinterpret the diagram. I never recommend using implicit merge behavior because the risk is high that it might be misinterpreted. This is especially true in this case because a small change such as a dashed line now means that we have a potential parallel situation. Most people new to BPMN won’t know this, and people not yet familiar with BPMN 2.0 might not spot this subtle, but critical difference.

Non-interrupting start event

This is where it gets complicated. I had to read this part of the specification several times to figure out how a start event could be non-interrupting. There are some small examples in the specification, but to fully understand what’s happening here we’ll have to talk about scopes of subprocess and many other concepts. For now I’ll just introduce the idea and if you have any questions, please feel free to comment and I will reply.

First, let’s talk about scope. When something occurs inside of a subprocess, the details are not available externally. For example, if I were to assign an activity to you that requires several steps, I would use a subprocess. Within that subprocess I don’t have access to the details of what you are currently doing, and I don’t have access to any data artifacts being created. The subprocess is essentially functioning independently. However, the subprocess has access to any information defined in the higher-level scope, such as a pool, or parent subprocess when subprocesses are nested.

Because of the limitations of subprocess scope, the event handler for a subprocess doesn’t actually have access to the data and activities contained within the subprocess. Because of this problem, BPMN 2.0 introduces the non-interrupting start event.

Non-Interrupting Start Event

When a subprocess starts, non-interrupting start events inside the subprocess are activated. When the subprocess completes, the evens are deactivated. So there is a scope of when they are available to be triggered that is the same as the scope of the subprocess.

Also because of the subprocess scope, there is a change in accessibility of the events and the related exceptional flow. Any activity or event on the exceptional flow can access anything from the parent scope. In this case, everything is in the same subprocess scope, so both A and B can access the timeout handler, and likewise, the timeout handler can access both A and B.

This sort of behavior is significant because of the parallel behavior. In the example above, when the timer is triggered, a parallel flow is introduced. The parallel flow is outside the scope of the original activity, which might cause synchronization issues. So you might to use additional events such as signals to keep things happening in the correct order.

Because the non-interrupting flow is in the same subprocess, a merging gateway is not needed. A subprocess has an implicit merge capability. But you still have to pay attention to details. If the timeout handler is not completed until after subprocess B, the entire subprocess will still be held back until timeout handler is completed. This is the nearly identical behavior to the interrupting pattern shown above with the merging gateway. The main difference is in the scope and visibility of data.

I asked the question why they didn’t just reuse the intermediate instead of the start. I think it would have been easier to learn. It seems that many folks at OMG are very strict about using start and end events inside every subprocess. However, the spec doesn’t explicitly say that intermediates are disallowed. I suppose that using an intermediate as a start of a flow is just as confusing. Prior to BPMN 2.0 I used to draw the entire pattern in yet another parent subprocess, and create any data artifacts in the higher-level parent scope so that both normal and exceptional flow would share a common scope. So I can see where this new feature of BPMN 2.0 will be useful. However, I recommend using text annotations so that people who read your diagrams are clear on the exact behavior you are trying to achieve.

BPMN getting complicated?

I have already received feedback based on my last few posts that BPMN is getting way too complicated. In some ways I agree, but we also have to consider every use case and have a clear way of illustrating it. Up until quite recently I was very hard-core on teaching every BPMN shape. I’m now taking a different approach to process modeling. Sometimes you need all of the shapes, and sometimes you don’t. It also very much depends on who the audience is. For the engineering crowd, use every feature of BPMN to the maximum extent. For the strictly business people, I suggest looking at the basic subset of BPMN and letting others worry about the complexity. This is yet more evidence that we need a multi-tier process design. You cannot shove everything into one process model and expect everyone to read and understand it.

I’m not making any promises of timeline yet, but I have a new book in the works that will help clarify the spec and make recommendations on which shapes to use in which situations.