Best Practice: Graceful shutdown for process instances with subprocess?

Hi Everyone,

I am currently facing the following challenge: I have a Camunda Service with an embedded process engine. This Service is known to an external, non Camunda, process management entity. This entity has the capability of sending a signal to abort a process instance to my Camunda Service.

Now, whenever I receive an abortion signal, i need to shut down my process in a “graceful” way, meaning that some database entries maybe need to be created or deleted and other actions must be executed to clean up my process instance.

My Process in question contains a set of Subprocesses that are integrated through call activities and waits on some events; imagine something like in the figure below:

My question now would be:
What is the best practice to use in Camunda to, for example, redo everything that was done by “Do Stuff” and “Do more Stuff” upon aborting my process instance?
Would I need to add some roll back instructions to the processes in my call activities?
Would I need to add my rollback instructions to my “Root Process”?
Would I need to make sure that at first the process instances in the call activities are aborted, and at last my root process instance?

I am quite unsure on how to solve this challenge in an efficient way, so I would be very happy for any help! :slight_smile:

Undoing changes is not an easy task. Read up about the eventual integrity. To technically interrupt the process flow you could use an event based subprocess with an interrupting start message event. Then you’d have to analyze what has already been done and carefully undo it (I assume the “redo” in your post should be an “undo”).

2 Likes

Thanks for your response! Indeed i meant undo instead of redo.
Would this event based subprocess also be triggered if my execution is currently in one of the subprocesses rather than the “root process”?

Yes, an event based subprocess is always startable.

1 Like

Hi…
Read about “Compensation events”

image

2 Likes

Hi @asalhani
Thanks for your input!
I indeed already considered Compensation events. However, in my opinion this concept is not applicable to my case:

Consider B being a Call Activity rather than a single delegate call. Hence, at the time my abortions signal arises, B could have done at least one step, that needs to be compensated.

Since compensation Events only (from what I know so far) work on the root level of my process, I have no chance to conveniently compensate the first step of B as there is no way to cascade the event to call activities.

I start to feel that Camunda is not quite the fit to be used in my scenario; or I need to adjust the scope of my call activities.