Gracefully Cancelling a Process Instance

DELETE /process-instance/{id}

or, using Java API:

RuntimeService.deleteProcessInstance(String, String)

this will simply delete the process instance and remove it from the database. Sometimes this is exactly what you need.

However: what if you want to cancel the process instance gracefully? Gracefully in the sense that the effects it has had on the outside world are undone? The answer to this is compensation. In this post I discuss two ways to implement compensation.

Internal Compensation

Modeling compensation inside the process itself:

The compensation undoes the effects of the process so far. This is usually modeled in a way where you attach a compensation handler to those service tasks which have effects on “the outside world” and implement logic which undoes the effects of those service tasks. Then, top level inside the process you can have an interrupting event subprocess with a message start event followed by an intermediate compensation throw event.

When you send the message it will

1. interrupt (effectively cancel) everything currently happening inside the process instance.
2. throw compensation which will propagate to all compensation handlers which have been activated so far.

Advantage

• everything self-contained inside the same process model
• compensation handlers can directly access variables of the process instance
• the process engine “knows” which service tasks have already been executed (effectively how far the process instance made progress) and handles triggering of the right compensation handlers for you

Downside

• you cannot implement it “retro actively” in the sense that it already has to be modeled inside the process before you deploy the process.
• if every service task has a compensation handler, the model may become “cluttered”.

External Compensation

Modeling a second process which undoes the effects of the first process.

First, you model a regular process (lets call it the “main process”) without any compensation logic:

Then you can model a second process (lets call it “compensation process”) which undoes the effects of the main process:

The compensation process can load the variables of the main process from history and may also check history to see how far the main process has made progress (because it does not know which services in the main process were executed and which services were not).

Or Better: you provide the necessary variables as input of the compensation process and make the compensation services idempotent. Meaning, the Cancel Flight service does nothing if no flight has been booked. That way you can just call them all.

Advantage

• can be done retro-actively after the “main process” has been deployed into production
• cancellation and compendation logic do not “clutter” main process model

Downside

• if you change the main process you may have to change the compensation process. People tend to forget to do this 🙂 If you have everything inside a single model, this is simpler.
• You either need to load the progress of the main process from history or make the compensation services idempotent