To identify Compensation Execution ID corresponding to Parent Execution Instance

Camunda 7 Topics Discussion & Questions
1

userTaskProcess.bpmn (10.6 KB)

What we are trying to find out is → if there is a way to uniquely identify the ID/Activity Instance ID of the execution which has registered a compensation Event which in turn will create Compensation executions.
What we are trying to do is that during the main service/user task execution tag the records in my Database that got updated by this task with it’s unique ID that engine generates. If the corresponding compensation event happens, we want to find out what was the corresponding execution task’s ID so that we can find exactly those records in our database and revert them

Use Case details:

  1. Attached Bpmn process has one Compensation Task(Delete Simple Task) corresponding to a Service Task(Simple Task) and another Compensation Task (Delete User Task) corresponding to User Task(User Input Task) respectively.
  2. When any error occurs after the User Input Task, both Compensation Task(Delete User Task and Delete Simple Task) gets called in the sequence it got registered
  3. In any of the Compensation task we wanted to get the Execution Id or Activity Instance Id of the corresponding Task for which the Boundary Event was registered.

Reason : Each of these Task has a specific operation which we wanted to bind using the execution Id or Activity Instance Id so that during the compensation we can make use of this ID to revert the changes exactly done corresponding to this Activity Instance Id

2

Hi @jagatramkhanna,

I’m not sure if you can use the execution or activity instance id for this. I think the ids are different when the compensation is triggered.

Can you use the process instance id to revert the changes in the database?

Best regards,
Philipp

3

Hey Philipp,

I doubt we can use process instance ID to revert.
Consider scenario where I have 4 service tasks in my flow. Task 1 updates some records (lets say record R1, R2, R3, R4). Task 2 updates some records (lets say record R5, R6, R7, R8). Task 3 updates records (lets say R2, R3, R4). Task 4 fails.

In this whole scenario what we intended is that compensation for Task 3 gets triggered rolling back it’s own updated records (R2, R3, R4), then compensation for task 2 getting triggered rolling back it’s records (R5, R6, R7, R8). Then compensation for Task 1 getting triggered and rolling back it’s records (R1, R2, R3, R4). Thus in the end all records will be back to their original state.

In this whole process all the tasks will have the same process instance ID. Thereby no compensation will be able to uniquely identify the records to pick that it needs to roll back

How do we overcome this?

I have one more complexity though which I originally left out. what if Task 4 failed at the point after it has updated some records. Since the task has not completed and registered it’s compensation those records won’t be called for roll back. How does one even identify at what stage the Task failed and the logic for compensation needs to be called or not

Highly appreciate your help with this design conundrum.

Regards,
JRK

4

Hi @jagatramkhanna,

so the problem is how to identify the records which should be reverted by each compensation handler (i.e. task). The solution depends on your use case and the services you invoke. It could be that the service returns an id or key which can be used.

This is not in the scope of the process. From the process view, Task 4 is something atomically. So the service should handle it, for example write the changes within a transaction.

Best regards,
Philipp

5