OMG veröffentlicht BPMN 1.1 ‑ Was hat sich geändert?

OMG releases BPMN 1.1 - What's changed? (revised version as of April 2008) Gero Decker1 and Torben Schreiter2 1 Hasso Plattner Institute, Potsdam, Germany 2 inubit AG, Berlin, Germany Abstract The Business Process Modeling Notation (BPMN) is today's most important process modeling language. It enjoys broad acceptance among practitioners and many vendors are supporting it. The Object Management Group (OMG), the standardization body behind BPMN, released an updated version February this year. We identified the most important changes for you and outlined them in this document. Not much has changed in BPMN 1.1 and if you were already familiar with version 1.0, we enable you to use version 1.1 right away. 1. Introduction The Business Process Modeling Notation (BPMN) is a powerful tool for documenting your business processes. It is a standardized language for capturing what you currently do in your organization and where you want to change. And you are not the only one to use BPMN. There has been a major uptake and many vendors are supporting BPMN. As every language, BPMN keeps on evolving over time. The Object Management Group (OMG) finalized version 1.0 in 2006. It was high time for an update and at the beginning of this year OMG released version 1.1. Now it is up to us to get you up-to-date. In this document we will give you a brief overview of what has changed from BPMN 1.0 to BPMN 1.1. We will start with the new constructs available in BPMN 1.1. There are a number of new features you should be aware of. You should definitely have a look at signal events and at the refined notation for distinguishing catching and throwing events. We will also point you to other notational changes and changes in element attributes. On the other hand, we do not want to bother you with specifics that do not affect your modeling at all. Therefore, we keep this document short. Before you read on and familiarize yourself with the changes in BPMN 1.1, let us put you at ease: You will not require additional training to cope with 1.1. You do not need to remodel your entire model repository. There is just a small delta you should be aware of. ___________________________________________________________________________________________________________ inubit AG: OMG releases BPMN 1.1 - What's changed? Page 1 of 9 2. Catching and Throwing Events The semantical inconsistency between different types of events in BPMN has always been quite confusing for BPMN beginners. For example, the intermediate timer event is always triggered externally and blocks the flow until the particular trigger is fired (e.g. 11am on Sundays). The intermediate message event, on the other hand, can act as activity sending out a message to one of your favorite business partners. That is, it does not block the flow while waiting for a trigger, but rather throws an event and immediately continues the flow. This difference in behavior amongst the event types is addressed in BPMN 1.1. The new specification introduces a categorization of event triggers into “catching” and “throwing” events. I.e. there are two kinds of intermediate message events now - one kind responsible for reception of messages (“catching”) and one kind responsible for sending messages (“throwing”). Clearly, each kind comes with its own graphical representation (inverted colors). Start End Intermediate Catching Throwing Plain Message Timer Error = Sequence Flow Event only Cancel = Boundary and Sequence Flow Event Compensation = Boundary Event only Conditional Signal Multiple Link Terminate Flow Figure 1. Distinction between throwing and catching events Of course, start events are always of catching nature. For instance, take a BPEL process and visualize it using BPMN. The BPEL engine will wait for incoming messages, e.g. from one of your suppliers, and create new instances of the process. ___________________________________________________________________________________________________________ inubit AG: OMG releases BPMN 1.1 - What's changed? Page 2 of 9 Likewise, intermediate events attached to the border of activities always symbolize catching events. The occurrence of that event, e.g. a timeout, triggers the cancellation of the activity. In contrast to that, end events always represent throwing events. With those intermediate events that are not attached to activities, it becomes a little trickier: Here, either catching or throwing events applies. BPMN 1.1 really helps in this context, as catching and throwing are now clearly distinguished through their visual appearance. You already know the large number of different event types from BPMN 1.0. This has not changed much in version 1.1. You are still confronted with a zoo of types. The new version even worsens this situation: In addition to the old types, it introduces a new type, the signal event. This is a powerful new mechanism that might affect you in your daily modeling. That is why we devoted an entire section to it (section 4). The link event's description has undergone a major revision. Most likely, link events were one of the most misinterpreted constructs in the 300+ pages of BPMN 1.0's specification. 1.1 clears things up by stating that link events are solely meant to establish a point-to-point connection within a single process contained in a single pool. Link events can be used whenever a sequence flow does not fit into your layout. That is, two intermediate link events (throwing and catching) establish a sort of “wormhole” within the same process. Most often, link events are used as off- page connectors linking different diagrams together, jointly describing one process. Start and end link events do not exist any longer in BPMN 1.1. Too many people misinterpreted a pair of end and start link events as the call of a different process. For removing this confusion, there are only intermediate link events left. For avoiding faulty or ambiguous models, please think of pairs of link events as simple sequence flows: They must be contained in the same pool. When used as off-page connectors, they still need to reside in pools with the same name. You are allowed to use multiple source link events, but do not use more than one target link event. The semantics for multiple source links can be thought of as multiple sequence flows merged in an XOR-gateway. Figure 1 gives you an overview of all events present in BPMN 1.1. For your convenience we marked those intermediate events that only appear as boundary events or only in the regular sequence flow or in both ways. The overview also shows you that the old “rule events” where renamed to “conditional events”. The semantics and appearance have not changed though. ___________________________________________________________________________________________________________ inubit AG: OMG releases BPMN 1.1 - What's changed? Page 3 of 9 3. Signal Events The only completely new construct in BPMN 1.1 is the signal event. It can be used as start, intermediate or end event and is denoted as a triangle in the well-known event shape. Its semantics is described quite nicely in the specification through a metaphor: “A signal in BPMN is to be seen as a signal flare broadcasting the occurrence of an event. Anyone seeing this flare is now aware of the signal and can react on it.” Signal events give you an easy way for modeling certain control flow situations that were not possible in BPMN 1.0. Imagine you have two sub-processes that need to synchronize. BPMN is very strict with sub-processes: They have exactly one entry point and one exit point (or multiple exit points in the case of attached intermediate events). However, while the individual sub- processes have not been completed or canceled, no synchronization was possible in BPMN 1.0. Some modelers resorted to message flow within the same pool -- a workaround that was and still is not allowed. Signal events are a nice solution for this case. But signal events can do more. They have a broadcasting nature, i.e. an event that is thrown once can be caught multiple times. Now, some readers might say to themselves: "Great, I do not need message events any longer -- they did not work for broadcasting scenarios, anyway. I will only use signal events from now on." Be careful! Please, stick to message events as much as possible and only use signal events sparingly. This will keep up the precision of your models. By the way, on an execution level, signal events assume a certain signaling infrastructure. Signals need to be published and subscribed for. Many process engines do not support this. And even worse: If you model throwing and catching signals across pool boundaries you assume that the different organizations share such a signaling infrastructure. This is quite unrealistic. Figure 2. Signal events On a business level, signal events might be an option for you as alternative to non-typed events.