Tutorials

These tutorials are based on our chapters in the document ‘BPMN 2.0 by example’, the BPMN tutorial by the OMG (Download als PDF).

Shipment Process of a Hardware Retailer

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.
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.
The plain start event “goods to ship” 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 “mode of delivery”, 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.
This gateway is called “exclusive”, 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 the shipment. 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 “Fill in a Post label” and “Take out extra insurance”. In this scenario, the inclusive gateway will always wait for “Fill in a Post label” to be completed, because that is always started. If an extra insurance was required, the inclusive gateway will also wait for “Take out extra insurance” to be finished. Furthermore, we also need the synchronizing parallel gateway before the last task “add paperwork and move package to pick area”, because we want to make sure that everything has been fulfilled before the last task is executed.

The Pizza Collaboration

This example is about Business-To-Business-Collaboration. Because we want to model the interaction between a pizza customer and the vendor explicitly, we have classified them as “participants”, therefore providing them with dedicated pools. Please note that there is no default semantics in this type of modeling, which means you can model collaboration diagrams to show the interaction between business partners, but also zoom into one company, modeling the interaction between different departments, teams or even single workers and software systems in collaboration diagrams. It is totally up to the purpose of the model and therefore a decision the modeler has to make, whether a collaboration diagram with different pools is useful, or whether one should stick to one pool with different lanes, as shown in the previous chapter.
If we step through the diagram, we should start with the pizza customer, who has noticed her stomach growling. The customer therefore selects a pizza and orders it. After that, the customer waits for the pizza to be delivered. The event based gateway after the task “order a pizza” indicates that the customer actually waits for two different events that could happen next: Either the pizza is delivered, as indicated with the following message event, or there is no delivery for 60 minutes, i.e., after one hour the customer skips waiting and calls the vendor, asking for the pizza. We now assume that the clerk promises the pizza to be delivered soon, and the customers waits for the pizza again, asking again after the next 60 minutes, and so on. Let’s have a closer look at the vendor process now. It is triggered by the order of the customer, as shown with the message start event and the message flow going from “order a pizza” to that event. After baking the pizza, the delivery boy will deliver the pizza and receive the payment, which includes giving a receipt to the customer.
In this example, we use message objects not only for informational objects, as the pizza order, but also for physical objects, like the pizza or the money. We can do this, because those physical objects actually act as informational objects inherently: When the pizza arrives at the customer’s door, she will recognize this arrival and therefore know that the pizza has arrived, which is exactly the purpose of the accordant message event in the customer’s pool. Of course, we can only use the model in that way because this example is not meant to be executed by a process engine.