BPMN Compensation Events and handlers

Value Proposition Statement

Support for BPMN Compensation Events + Activities to rollback successful operations.

User Problem

We execute tasks in our processes that sometimes have to be canceled later under certain circumstances. Compensation Events+Activities is a very powerful construct for handling such situations. Without these BPMN symbols, users would have to add a lot of additional complexity to their models. Today these symbols are not supported by Camunda 8, whereas we support them in Camunda 7.

Release notes

In process orchestration, executed tasks may need to be canceled later under certain circumstances. BPMN compensation events and handlers allow you to undo or reverse the effects of activities in case of errors, exceptions, or cancellations, ensuring consistency, reliability, and compliance in complex business scenarios. Compensation supports the Saga pattern, and Zeebe as Saga Coordinator helps to solve transactions without two-phase-commit in distributed systems.

User Stories

As a Developer, I can model and execute an "Intermediate Throwing Compensation Event"
As a Developer, I can model and execute Compensation Boundry Events
As a Developer, I can model and execute Compensation End Events
As a Developer, I can trust that this will execute all defined compensation handlers according to BPMN specification (support for BPMN Compensation activity + Compensation Boundary Event)

General:

As the product manager, I can track the usage of the compensation events and activities in mixpanel

Implementation Notes

^{:robot: This issue is automatically synced from: source}

Hi.

I have an issue with Camunda 8 and long running processes. By long running process I mean:

process has an subprocess
subprocess has an overall timer boundary event set to 10-30 min duration

For example:

With hundreds of thousands PIs being deployed there are plenty of catch timer events could be fired in small time period. With 1 million PI being deployed it may look like this:

And it's make me frustrated. I've just want to cancel execution. Instead stream processors are flooded by internal generated events and my brokers are killed by OOM.

The batch processing could help me with this, but to be combined in batch - commands should be generated from one PI, not from multiple ones.

The backpressure mechanism also could be useful - but it limits only commands from client, not internal ones.

There is some feature https://github.com/camunda/zeebe/issues/12560 to present internal stream processor rate limiter, but it's blocked by some mystical https://github.com/camunda/product-hub/issues/1426.

These separate and special compensation events presented by this feature, will they have a separate and special handling or a more controllable handling to prevent event flooding?

PS: I've tested on 8.3.0-alpha6. PPS: I've just found https://github.com/camunda/zeebe/issues/5134, maybe it's more appropriate place to ask.

camunda / issues