I am a newbie to the Camunda platform so my apologies if I have not found my answer somewhere in the documentation. I was just wondering what exactly happens when I do process modifications while the process is running.
For example, there is a process with tasks A -> B -> C -> D. Task B is in a waiting state, could be either a user task or a service task. I want to do a modification saying that I want to cancel the execution at B. However, in the time my modification is submitted/executed, B already finished and the execution continues.
My modification instruction cancels B but there isn’t anything to cancel anymore.
Camunda implements optimistic locking. When two transaction modify the same database entity in parallel, the first transaction committing its changes wins and the second loses and rolls back. The caller that triggered the second transaction receives an instance of OptimisticLockingException and can retry the modification. In the context of job execution, this is done automatically by the process engine. In your example, your API call cancelling B would fail with such an exception.
We do have options - assuming that you may have overlapped the boundaries between process and service data domains.
It’s true that you simply cannot unwind the process state information (well… you could, but then you would effectively erase the process execution history - and/or simply receive an XA error from the system DB). The Camunda system DB needs to keep track, at the system level, where the process is in context to process task execution (i.e. token movement through the process instance).
However, when you segment out the business data, in-other-words address the business data in its own domain with associated transaction management, you now have have options for both modeling and managing extended transaction requirements and services.
Given A->B->C->D, where B is in a “waiting state” but none-the-less completes prior to cancellation. This is your classic “transacted sub-process” requirement.
We then move the above process into a transacted sub-process:
And we now have options.
The transacted sub-process “cancellation” event wouldn’t necessarily cancel, and roll-back, Camunda’s system-level database activities relating to token-context (task “B” state). Instead, you model “Cancel B” as a new “compensating” task responsible for managing, and compensating, associated changes made within business-data services (i.e. SOA). Again, we’re not rolling back Camunda system data. Instead, we’re keeping track of task B’s activities against business data (i.e. within the “business domain” - at its service layer) so that your “compensating transaction” task then issues a new set of requests that compensate (undo) the effects of task B. This compensating task is marked with the BPMN “Compensation Marker” and reacts to compensation events issued from within the transacted sub-process.