Process Modeling:

Complexity is just a combination of simple things


Business Process Management (BPM):

How you manage complexity in a simple way

Highlights from BPMN 2.0: New Event Types

What’s new in BPMN 2.0: Part 5

Continuing coverage of the BPMN 2.0 specification, this post will focus on the new event types.   Prior to 2.0, BPMN had several problems when it came to escalating events and dealing with events in parallel.  Often I would end up using a pattern with multiple loops inside of loops to accomplish seemingly simple activities. Furthermore, it was difficult to distinguish between human centric and system centric activity for a mixed-mode diagram that includes both.

One goal of BPMN is to bring the SOA camp, the business analysts,  and the process modeling communities closer together.  A side effect of this has been that BPMN is very messaging intensive. For complex interactions, multiple pools are used, which requires lots of messaging lines to keep activity in sync between participants .  This is sometimes a problem for people who come from a flowchart/workflow backround using tools such as Visio, which essentially allows you to create a really bad BPMN diagram due to the lack of diagram validation.  Often I see messaging lines within a pool going between lanes, when what was really intended is to do a simple escalation.  Antoher common problem prior to BPMN 2.0 is showing enough detail without having to show the intricate patterns of looping and dealing with multiple events in parallel.

We are starting to see a shift from multiple pools and lanes to more of a style based on a single pool with no lanes, which means less explicit messaging notation. On the other hand, we are starting to see more capability in BPMN to document highly technical processes for the SOA community.

New Event Types

In this post I will cover the new BPMN escalation event and parallel multiple event.

Escalation event

The escalation event is new in the BPMN 2.0 specification.  The shape looks like the Star Trek symbol.  I’m not sure what you call it, but it somewhat resembles an upward facing arrowhead.  The full pallet of escalation events are available.  However, it’s important to note that both start (interrupting/non-interrupting) and both intermediate types can only be used with subprocesses. Only the throwing shapes can be used within normal sequence flow.   This implies that escalation can only be thrown from within a subprocess that has a catching shape.  The intermediates are used on the subprocess border, whereas the start types are used within the subprocess.  Note that you should review non-interrupting events in my previous post for more details on how non-interrupting events work.

BPMN 2.0 Escalation Events

BPMN 2.0 Escalation Events

Prior to the introduction of the escalation event, the only way to effectively accomplish the equivalent behavior was to throw an exception, or use a timer on a subprocess border. Both of these alternate patterns introduce potentially unwanted side effects.   If the exception event is used, there is no non-interrupting catching shape. Therefore the parent scope would always be cancelled, and only exceptional flow would be executed. But in the case of escalation, most often this is not the case.  For example, a participant is working on a problem which requires escalation to a manager. The original participant will continue the work, although the manager is now involved.  This is a collaborative escalation mode which requires a dynamic parallel flow, generated by the non-interrupting escalation event.  This would not be possible with an exception event.  Furthermore, a timer would not be appropriate in this case either because the event is not based on time. Instead, it’s based on a condition generated during the execution of a task, probably by the participant performing the task.

Escalation Event Example (non-interrupting)

Escalation Event Example (non-interrupting)

The example above shows the non-interrupting start event catching the intermediate throw escalation event.  Again, note that if the start escalation event were interrupting (solid), the step “do more work” would not occur.   The start and intermediate catching events can only be used within or attached to a subprocess border.  To further clarify this behavior, study the following example:

Intermediate Escalation example

Intermediate Escalation example

In this example the handler is on the subprocess border.  Technically this process will execute identically to the one above, with one easily overlooked difference.  The participant handling the escalation in example 1 can directly collaborate with the other active tasks, because they are both in the same scope.  Example 2 has an event handler that is external to the subprocess, which means that the handler does not have access to the same data and event scope as the other active tasks.  All communication between tasks would have to be handled in some other way.  Also note that external synchronization back into the main flow is required, because two parallel paths were created. Failure to synchronize would have the same consequences as explicitly using a parallel split with no merge. The inclusive merge is used because at design time we won’t know if the escalation path will occur or not.  Got it?  If not, bear with me for a few more posts and I’ll get back to these patterns.  For now I”m only covering the spec.

Parallel Multiple Event (inclusive behavior)

As of BPMN 1.2 the multiple event had only exclusive behavior, meaning that a single qualifying event would trigger the shape.  The inner shape of the event is a pentagon.

Multiple Events: Exclusive Behavior

Multiple Events: Exclusive Behavior

Adding to this shape, you can see the new non-interrupting variety of both the start and intermediate shapes.   Refer to non-interrupting events in my previous post for details on how non-interrupting events work.

BPMN 2.0 introduces the parallel multiple event, which has inclusive behavior, meaning that all related events are required in order to trigger the shape.   There is no throwing type for this shape, because a parallel throwing multiple event would probably raise more questions than it solves.  Anyway, there are interrupting and non-interrupting varieties of the start and intermediate types.

Parallel Multiple Event (inclusive/parallel behavior)

Parallel Multiple Event shapes

Officially the specification calls this a parallel event, because it must receive all events to trigger the shape.  To help eliminate confusion I’ve also been referring to the behavior as inclusive, meaning that all events are included.  But actually, the parallel behavior is much closer to the truth of the use case.  The term ‘parallel’ is somewhat ambiguous because it might imply that all events must be received at the same time.  In reality, parallelism in BPMN does not mean that activities execute at the same time. Instead it means that multiple activities or events are enabled in parallel, and have the potential to occur at the same time.   Just because a task or event is enabled doesn’t necessarily mean that it will execute.  A parallel multiple event requires that all events in the correlation set to be triggered before the condition is satisfied.  Only then will the entire event trigger be fulfilled.

The epitome of complexity

The usefulness of this shape is debatable.  Most BPM vendors have not added support for many of the BPMN shapes because they just don’t make sense for an executable system.  In fact, about half of the BPMS vendors on the market today are using only a subset of BPMN 1.0 or 1.1.   To some, this might seem like a negative point towards the vendors.  But the reality is that most people have a hard enough time understanding the basic subset of BPMN, let alone something as complex as a “non-interrupting parallel multiple start event”.  For those of you just tuning in, this would mean that I have a generic shape acting as a filter for a bunch of specific events, and if this condition were to occur, launch an exceptional flow, in parallel, to deal with the problem.  Otherwise, keep working as normal.   Now see, that wasn’t so bad, was it?

For this shape to actually be useful in a diagram, you are doing one of two things; being purposefully vague (shorthand notation), or you are implying some sort of CEP (complex event processing) mechanism.   So, as I mentioned earlier, BPMN is getting simultaneously easier to use, and more complex at the same time.  Something as simple as a rope can be quite useful, but people somehow manage to hang themselves with it every day.

– Rick Geneva

Tags: ,

2 Responses to “Highlights from BPMN 2.0: New Event Types”

  1. Kim Scott Says:

    Hi Rick,

    Thanks for a helpful site, in as plain a language as one can get with BPMN 😉

    It’s my understanding from the BPMN 2.0 spec (page 218) that “The Escalation Start Event is only allowed for triggering an in-line Event Sub-Process.” If that’s the case, then I think in your “Escalation Event Example (non-interrupting) picture above, you need to show the handle escalation within an Event Sub-process. Or do I misunderstand the spec?

  2. Rick Geneva Says:

    Kim,
    Thanks for the comment.
    I have to confess I’m getting a bit behind on my postings. I have to balance writing in this blog with writing in my next book the Microguide to Processs Modeling in BPMN 2.0. I’m pushing hard to get it on the market by early Q2. Initially my writing partner and I thought we’d do just a quick update to the last book. But after digging deep into the BPMN 2.0 spec we realized that we are looking at a total rewrite. Much has changed in the spec, and along with this changes our recommendations and patterns are changing as well.

    I believe you are correct. I forgot to enclose the escalation path into the dashed subprocess (in-line subprocess). Thank you for pointing this out. I will correct it soon. I could have said that I was planning to do this in a later post and my diagram was deliberate, but you would have called me out on that, wouldn’t you? 😉 So maybe the next post in the series will be about subprocess, in-line subprocess, and stand-alone subprocess. This topic needs to be addressed anyway. So thanks for your contribution to my site.