Sometimes we can’t undo our actions. Water under the bridge. But we can make it right by doing something else to compensate. BPMN allows us to use intermediate events to compensate for mistakes in the past. A classic example is cancellation of a purchase. Our example is a little more fun.
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.
This Sounds Familiar
In our article on end compensation events, we demonstrated how intermediate compensation events attached to the boundary of an activity can be used to compensate for an activity or set of activites. The intermediate compensation event is triggered by a business process reaching an end compensation event. Here’s the diagram from that article for a quick review.
In the business process modeling example above, when an invalid card is discovered within the subprocess flow, it triggers the compensation of the “Process Credit Card” task, with the “Record Possible CC Fraud” task. Since this end event terminates the flow within the subprocess, the parent process then continues to the “Record Transaction” step.
Intermediate compensation events are handy because they allow us to compensate for transactions that can not (or should not) be undone. We can use cancel events to truly undo steps within transactional subprocesses. Compensation events are used when we don’t want to undo a step, but do want to record both that step and a future activity (task or subprocess) that compensates for the original activity.
[Update 20060918]
The example above shows a process with two misinterpretations of compensation event semantics. A detailed explanation of the mistakes has been published. First, the compensating task above does not really compensate for (undo) the associated activity. Second, there are no additional activities between the task being compensated and the compensation end event.
The following example also suffers from the second of those two mistakes.
[End Update]
In the following example, our morning diner eats a breakfast burritto. This is a step that can not be undone. If our diner gets heartburn, he will take an antacid, which will make him feel better. He finishes up the process by enjoying the day – either because he didn’t get heartburn, or because he did, but taking the antacid compensated for his folly.
Summary
The key point to take from this is that compensation is used when we can’t undo a step in a process, but we can perform another action designed to neutralize the effect of the former step. [Update 20060918: Please review this correction to avoid the mistakes in this article]
Latest Articles
Comments on all Articles
