BPMN Compensation Event Correction

One of our readers (thank you!) pointed out that another blogger was critiquing one of our earlier business process modeling notation (BPMN) diagrams. Turns out we made a couple mistakes. Here’s a more detailed look at the compensation end event.

The Web-Publishing Process

One of the great things about writing and publishing on the Tyner Blain blog is the feedback loop. In BPMN, it looks a little like this:

Usually, when a critic finds a mistake he will point it out to me directly, or traffic will come from the critic’s site, and we’ll find out via our analytics.

It turns out that we did make a couple mistakes, so thanks Bruce for pointing them out.

First, The Mistakes

In one of our articles on end events, we created an example to demonstrate compensation end events, and we had a couple mistakes in the diagram – not too good for a tutorial. Here’s the offending diagram, with a couple annotations in red showing the problems.

These two mistakes (circled in red) indicate a mis-application of the compensation end event.

The compensating activity, “Record Possible CC Fraud” is a mis-application of the compensation intermediate event, because that task doesn’t actually undo, or compensate for the task to which it is associated (Process Credit Card).

The second mistake is that there are two gateways (a fork and an exclusive OR) that can be reached before the compensation end event, but no other activities. The compensation events, when triggering compensation, are designed to allow you to “go backwards” in the process, and as such, expect that at least one activity is processed before deciding to compensate. The presumption is that if compensation can be initiated without performing any other tasks, then it could happen immediately from within the task that has a compensation intermediate event on its boundary. The gateways don’t count as activities, because they only analyze existing data.

The Corrections

Here’s a new example diagram, without those two errors.

The first correction shows that the compensating task, “Record Transaction Recision”, is truly something that is done to compensate for recording the transaction. The second change is that there are two distinct tasks between the activity being compensated and the compensation end event. The first task, “Request Credit Card Charge”, sends and receives messages from the bank. This is the task that could cause a compensation (controlled by the gateway’s analysis of the results of that request). The second task, “Notify Customer of Failure” will also occur, but only if the bank denied the charge to the credit card.

Summary

Compensation events require that tasks be processed between the task being compensated and the triggering of that compensation. Compensating tasks must compensate for the task to which they are associated.

For the Truly Pedantic

There is also a semantic concern with the original diagram – the original diagram shows that the product would be delivered, even if the credit card charge failed to go through. This could indeed happen – when a vendor is unable to contact the bank, but unwilling to lose a sale. Think about the old “paper charge” handheld machines – they would create a slip that records the transaction in exchange for goods or services – and only later process that transaction, which could fail. But this is a concern, since it is very uncommon these days (only us old folks remember).

There is also another problem, although it may be more of a problem with the BPMN spec than the original diagram. We’ll talk about that in a future article. [Update – it is definitely a problem with the diagram, and not the spec. – Discussion to appear in 20 Sep article]