Compensation and Boundary Events in Order Fulfillment
An online retailer modeled order fulfillment with a subprocess 'Reserve and charge' containing 'Reserve inventory' then 'Charge card'. Each task has a compensation boundary event: 'Reserve inventory' is linked to 'Release stock', and 'Charge card' to 'Refund card'. The subprocess has a non-interrupting boundary timer of 20 minutes and an interrupting boundary error event for payment rejection. A compensation intermediate throw event was placed after the subprocess, but the modeler ended the subprocess path with a terminate end event so the throw event is never reached when payment fails. In a pilot of 2,000 orders, 74 cards were declined; stock was released by an error handler, but no refunds were issued for 22 orders where authorization had succeeded before a later decline. Also, 18 orders exceeded 20 minutes but continued to shipping because the timer did not interrupt. Finance requires that either the order completes or all reservations and charges are reversed.
1. Explain why compensation did not execute for the 22 orders and how the subprocess should be modeled so that refunds and stock release occur reliably.
Read the worked answer
Compensation is not automatic error handling. A compensation boundary event declares a handler that runs only when a compensation throw event is reached, or when a transaction subprocess is canceled and its compensation is triggered. Here the modeler put an intermediate compensation throw after the subprocess, but the subprocess path ended in a terminate end event. A terminate end event ends the entire process immediately and skips the remaining flow, so the throw event was never reached. The 22 orders had successful card authorization before the later decline; the error boundary event released stock, but no compensation handler was invoked for the card charge.
To make reversal reliable, model 'Reserve and charge' as a transaction subprocess with a cancel end event. Attach compensation boundary events to 'Reserve inventory' and 'Charge card', with handlers 'Release stock' and 'Refund card'. When payment is declined, route to the cancel end event; the transaction rollback triggers compensation for completed activities in reverse order. Do not use a terminate end event inside the subprocess. Make the compensation handlers idempotent, because a retry may invoke them more than once, and log compensation completion so finance can reconcile.
2. Evaluate the boundary timer: should it be interrupting or non-interrupting, and what should happen on timeout? Include transaction subprocess considerations.
Read the worked answer
The timer's purpose determines its interruptibility. If the 20-minute limit is a service-level deadline for completing reservation and charge, the timer must be interrupting. A non-interrupting timer only creates an additional path; it does not stop the subprocess, which is exactly why 18 orders continued to shipping. An interrupting boundary timer cancels the subprocess and routes to a timeout path: release stock, void or refund any authorization, notify the customer, and offer retry. Because the subprocess is a transaction, cancellation should trigger compensation for completed activities; the timeout path should wait for compensation to finish before closing the order.
If the business instead wants a reminder while allowing work to continue, use a non-interrupting timer on a separate escalation path, but do not rely on it to enforce the deadline. Also define what '20 minutes' measures - elapsed time or working hours - because boundary timer events use the process engine's calendar. Test both paths with simulated delays and declined authorizations.