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.
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.
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.
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:
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.
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.
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