In have a process which has an event subprocess in the process scope to trigger compensation throw event.
The compensation throw event is triggering only the compensation activities of the parent process but not the sub process. There is also a subprocess (callActivity) with compensation boundary events for each step but they are not being triggered.
Documentation seems to suggest using a whole new undo subprocess. How will that undo subprocess track the state of original subprocess? What is the recommended way to preserve the selective-compensation semantics of the called process when compensation does not cross a Call Activity boundary? How is the undo process expected to know which child activities were actually completed?
This is expected behavior: compensation propagation stops at the call activity boundary, so you need to attach a compensation boundary event directly on the call activity itself (with its own compensation handler) for its internal compensation logic to be triggered. I found the following relevant resources:
The documentation suggests attaching a compensation handler to the Call Activity itself and invoking a separate “undo” process. However, that undo process has no built-in knowledge of which activities in the called process actually completed.
If only Reserve Stock and Charge Card completed before cancellation, the child process’ compensation model contains the necessary state to compensate only those activities.
If compensation is instead delegated to a separate “Undo Fulfillment” process attached to the Call Activity, how is that process expected to determine which activities completed in the original called process? Does Camunda expose compensation state from the called process, or is the recommended approach to explicitly maintain state/flags and implement a custom saga-style undo process?
When a compensation event is triggered, the engine invokes all compensation handlers for completed activities. Not for active or terminated activities.
In our example, the call activity is active when the compensation event is triggered. As a result, the engine doesn’t invoke the attached compensation handler.
The engine handles the compensation event only within the process boundary and doesn’t propagate it to the child process.
You would need to embed the fulfillment process in the parent process without using a call activity. Alternatively, you could trigger a message (or other) event in the child process from the parent process to communicate the compensation information to the child process.
“you could trigger a message (or other) event in the child process from the parent process to communicate the compensation information to the child process”
Is there any example in Camunda docs or can you share a bpmn if possible. The callactivity in my case is a multi-instance process so each instance should get its respective message correlation. This is the approach I was also trying out. But if it turns out to be too cumbersome then it will be difficult to advise the use of compensation event to any team in a corporate company. Just creating a whole new cancellation process will be the only option but compensation event is such a nice feature (but it is essential for it to work with callactivity)
The BPMN specification doesn’t cover this case. But I see that it would be useful for your use case.
Camunda doesn’t support this compensation behavior for call activities. You would need to build a custom solution that fits your needs.
This is a challenge, especially with a multi-instance call activity. I assume that the call activities are active when the process triggers the compensation, right?
Please share a BPMN of the child and parent processes.
When the cancellation message comes, since this is an interrupting message the active token of subprocesses and main process stops and the main process related compensation activities is triggered. This is good. The subprocess compensation activities are not triggered which is the pain point.
Tricky. From the BPMN specification, the compensation should trigger only completed activities. For the multi-instance call activity, all call activities must be completed to trigger the compensation handler.
In our example, the multi-instance call activity is terminated when the cancel message is received. So, it doesn’t trigger the compensation handler of the call activity.
With the current structure, one option is to store the shipments and their state in a variable of the parent order process. When the cancel message is received, you call an undo process for the collected shipments.
I see no easy way to utilize the compensation handler inside the child track process.
FYI, even if all the call activity processes have completed and the active token has returned to the parent process, which is then waiting for something, the undo step in the subprocess will still not be executed if a cancel message arrives. This is because the call activity runs in a different process scope.
Hints: Use the Ask AI feature in 