Rollback for custom Transactions

[cnfg]

Hi,

we have created several External Tasks which we intent to use frequently and in different combinations.
e.g.:

• Recive data from a third system
• Validate the recived data

this could be arranged like this:

With the group I did draw around the two tasks I want to mark the technical transaction I want to create.
If the Validatation Task fails I want to roll back to the task bevore the data was collected, since the data might be corrupted. Also there may be more tasks in this group than just the two.

Basically what I want to do is, treat the different calls to the external tasks as one and start at the beginning of the Transaction, without Modelling alle the required steps.

This article indicates that this is possible:

Dealing with problems and exceptions | Camunda 8 Docs

I have read some Information about this topic:

Transaction Subprocess | docs.camunda.org

Transactions in Processes | docs.camunda.org

and more …

In the forum the following comment indicates that my plan is not possible:

How to return to the specified node？

Ah, task escalation and error boundaries are not supported at the moment. For now, the way to do this would be to use an interrupting message boundary event on the task and route the flow back to the first task. Technically speaking you can’t rollback to something that’s already completed and was performed in another transaction (which is the case if these are user tasks; for service tasks by default, Camunda will attempt to perform as much as possible in the same transaction unless you demarca…

Is it possible to do this in Camunda or do I have to a Bpmn-Transaction and handle the this with an appropriate error boundry event?

We are using Camunda Version 7.11 vanilla

[tiesebarrell]

The post you reference was about using escalation error boundary events on user tasks, not on subprocesses. In the latest release of Camunda, these options were also added.

You added a group instead of a subprocess. Groups are only used for visual marking and don’t have any execution semantics AFAIK.

With validation tasks, I’d typically opt to follow them by an exclusive gateway, that deals with either success or failure (both normal outcomes of the validation itself). For the validation failed scenario, go to an error end event, catch it on the subprocess boundary and restart the subprocess. This is fully supported.