Business processes often need to be cancelled. An error condition can cause a process to terminate, or an incoming message can cause a process to be terminated. Error conditions occur within transactional subprocesses and a cancel intermediate event is used to describe any special cancellation steps.
Background
We presented an introduction to BPMN diagrams in July. 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).
Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.
Before Intermediate Error Events
With classical flowcharting describing an interruptable process involves creating a couple decision boxes and a loop. One decision box tests to see if the process is done, cycling back until it is. The other decision box looks for an interruption, so that the flow can be diverted from the normal looping behavior. It would look like the following example.
In this flow, the publisher collects stories, organizes the daily edition and then begins the printing process by printing copies. If the editor calls to interrupt the process, the publisher will stop the presses and recycle the paper that was used. If the editor does not call, the publisher keeps printing until all the copies are complete, and then distributes the paper.
The BPMN Way
With BPMN we can handle the possibility of interruption a little more gracefully. Consider the following business process modeling example of the same process using BPMN.
The editor will again collect stories and organize the daily edition. He will then begin the “Publish Paper” subprocess. When that subprocess is complete, he will distribute copies of the paper – unless the printing was cancelled. If the subprocess is cancelled, the intermediate cancel event diverts flow to the “Recycle Paper” task.
The expanded subprocess is drawn with double lines, indicating that it is a transaction. Transactional subprocesses can be cancelled, and in our example, if an intermediate message is received from the editor during the “Print Copies” task, flow is diverted to stop the presses and cancel the subprocess. The intermediate cancel event in the main diagram shows how the cancel end event in the subprocess is handled. There is another example of this behavior in our article on BPMN cancel end events.
Also note that there are no awkward gateways or looping flows required to represent this process. The BPMN representation shows that the process is either completed or diverted – without requiring an artificial looping construct.
Summary
The BPMN method provides for a cleaner diagram, as well as better encapsulation. It is clear in the BPMN diagram that the “Publish Paper” subprocess represents a distinct set of activities, where that isn’t as obvious in the classical flow chart. This clarity could be very handy when managing or optimizing a business process – for example, outsourcing of the printing process becomes an obvious topic of discussion when using the BPMN representation.
