This document provides a number of BPMN 2.0 examples<\/a>, which are non-executable BPMN 2.0 models conforming to the Process Modeling Conformance class as defined in the the OMG specification Business Process Model and Notation (BPMN) Version 2.0<\/a>. It is a non-normative document and its main goal is to assist in interpreting and implementing various aspects of the BPMN 2.0 specification. The examples are provided in form of Collaboration diagrams, Process diagrams, and Choreography diagrams as well as machine-readable files using the Extensible Markup Language (XML)<\/a>.<\/p>\n This chapter introduces the core concepts of process modeling with BPMN. We will not explain every single symbol you can find in the diagrams, but show how process modeling in BPMN is basically done, how we can use pools and message flows for explicitly modeling collaborations between participants, and how we can (de-)compose process models with sub-processes and call activities. Those examples do not contain executable process models, but represent process models focusing on organizational aspects of business processes.<\/p>\n In Figure 5.1 you can find the preparing steps a hardware retailer has to fulfill before the ordered goods can actually be shipped to the customer.<\/p>\n In this example, we used only one pool and different lanes for the people involved in this process, which automatically means that we blank out the communication between those people: We just assume that they are communicating with each other somehow. If we had a process engine driving this process, that engine would assign user tasks and therefore be responsible for the communication between those people. If we do not have such a process engine, but want to model the communication between the people involved explicitly, we would have to use a collaboration diagram as in the next chapter.<\/p>\n The plain start event \u201cgoods to ship\u201d indicates that this preparation should be done now. Right after the instantiation of the process, there are two things done in parallel, as the parallel gateway indicates: While the clerk has to decide whether this is a normal postal or a special shipment (we do not define the criteria how to decide this inside the process model), the warehouse worker can already start packaging the goods. This clerk’s task, which is followed by the exclusive gateway \u201cmode of delivery\u201d, is a good example for clarifying the recommended usage of a gateway: The gateway is not responsible for the decision whether this is a special or a postal shipment. Instead, this decision is undertaken in the activity before. The gateway only works as a router, which is based on the result of the previous task, and provides alternative paths. A task represents an actual unit of work, while a gateway is only routing the sequence flow.<\/p>\n This gateway is called \u201cexclusive\u201d, because only one of the following two branches can be traversed: If we need a special shipment, the clerk requests quotes from different carriers, then assigns a carrier and prepares the paperwork. But if a normal post shipment is fine, the clerk needs to check if an extra insurance is necessary. If that extra insurance is required, the logistics manager has to take out that insurance. In any case, the clerk has to fill in a postal label for theshipment. For this scenario, the shown inclusive gateway is helpful, because we can show that one branch is always taken, while the other one only if the extra insurance is required, but IF it is taken, this can happen in parallel to the first branch. Because of this parallelism, we need the synchronizing inclusive gateway right behind \u201cFill in a Post label\u201d and \u201cTake out extra insurance\u201d. In this scenario, the inclusive gateway will always wait for \u201cFill in a Post label\u201d to be completed, because that is always started. If an extra insurance was required, the inclusive gateway will also wait for \u201cTake out extra insurance\u201d to be finished. Furthermore, we also need the synchronizing parallel gateway before the last task \u201cadd paperwork and move package to pick area\u201d, because we want to make sure that everything has been fulfilled before the last task is executed.<\/p>\n (Read the guide for the remaining content)<\/p>\n","protected":false},"excerpt":{"rendered":"Small Examples introducing Core Concepts<\/h2>\n