This is part two of a two part article. The first part is How To Use End Events (Part 1). End events describe how a process ends. Often, the end of one process can initiate other behaviors within a business process. Like death and taxes, every business process has an end. Sometimes more than one.
We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
End Events Continued
There are eight different types of end events. We coverd the first four in our previous article. In this article, we will cover the remaining four:
- Compensation end events
- Link end events
- Terminate end events
- Multiple end events
Compensation End Event
The compensation end event is an event that, when reached, triggers the processing of a compensation intermediate event. A compensation intermediate event is an event that allows a task to be “undone” with a special process. That may not make sense yet, we’ll explain better as we go.
In the following BPMN example, we again (as with the cancel end event) look at the online purchase from the perspective of the online retailer. The subprocess, “Fulfill Order”, in the flow on the left, is expanded on the right. The “Process Credit Card” has a compensation intermediate event attached to its boundary, with an association (dashed line) coming out of it. Ignore that for now and focus on the flow.
The sequence flow from the “Process Credit Card” task goes to a forking gateway, which requires both parallel branches to be processed. On one path, we ship the ordered product, and on the other path, we check to see if the card is valid. The default behavior is for valid credit cards, and once the card has been validated and the product shipped (via the join gateway), the subprocess is completed.
If, however, the card is found to be invalid, the compensation end event is reached
If the compensation end event is reached, it triggers the compensation intermediate event that we were previously ignoring. That intermediate event triggers the “Record Possible CC Fraud” task.
One thing that isn’t obvious about the diagram above – if a credit card is found to be invalid, the “Ship Ordered Product” task is not undone. The compensation end event does not trigger a rollback of the process (like a cancel event would). It only triggers the compensation behavior. To undo the steps in the subprocess, we would have to use a cancel end event, and treat the entire subprocess as a transaction.
What we might desire is that we only ship products if the card is valid, in which case we would change the flow to look like the following diagram.
In this diagram, either the credit card is invalid and the sequence flow goes to the compensation end event, or the card is valid, and the product is shipped. This would be a more appropriate diagram – the previous one diagram was shown to indicate that the flow is not “undone” when a compensation event is reached.
There are a couple mistakes in the compensation end event examples above. Please read this article on compensation events for a correction and detailed explanation
Link End Event
The link end event is used to “connect” two non-sequential subprocesses. The following example shows how a link end event could be used effectively to jump from one subprocess to another.
Everyone flows from “Start” to “C” to “End” by default. Specifically, the tasks would be processed in the order ABCDE. However, the or gateway within the start subprocess presents an alternate flow. The default path ends the subprocess normally, returning control to the parent process (and task “C”). The alternate path links the flow directly to the “End” subprocess
Terminate End Event
The terminate end event is the “STOP EVERYTHING” event. When a terminate end event is reached, the entire process is stopped, including all parallel processes. The following example is from the classic story, Charlie and the Chocolate Factory.
Veruca Salt’s father owned a factory that sold nuts. He retasked all of his workers with opening Wonkabars by the case, in search of the elusive golden ticket. If we made a business process modeling example out of his process, it might look like the following.
The employees would receive a single shipment of multiple cases of Wonkabars, and then start the “Process Shipment” subprocess. Within that subprocess, someone would distribute the cases (to multiple employees), and then those employees would process the cases in parallel subprocesses. If there are more cases remaining, those cases are also processed, until there are no more cases.
In the “Process Case” subprocess, the employee first opens the case and then opens a Wonkabar, looking for the golden ticket. If the golden ticket is found, the flow reaches the terminate end event, and everything stops. If no ticket is found, the employee either unwraps another bar (if there is one in the case), or stops the subprocess.
This example illustrates that termination is not only of the subprocess, but the entire process. The “Process Case” subprocess is a parallel subprocess – and all of them terminate once the golden ticket is found.
Multiple End Event
The multiple end event provides us with a way to simplify our diagrams when specifying that multiple events occur at the end of a process.
In this BPMN example, after dating, falling in love, and getting engaged, three events happen. Our newly betrothed calls his family, reserves a room (for the reception), and invites guests (to the wedding). We can use this event to make our diagrams easier to read.
Between the first end-event tutorial and this article, we now know how to use and interpret end events in BPMN diagrams.