Hello,
I am not sure about how I should model the following scenario.
We have an event that pauses the execution of a sub-process (hold-on status). Once the cause for the interruption has been corrected, the sub-process should resume without restarting.
How could this situation be modelled? I assume that connecting an interrupting boundary event back to the sub-process would cause a new sub-process instance to be instantiated, wouldn’t it?
Thank you.
Hello,
I have not received any comments on this. Is the question clear enough?
Thank you.
Hello my friend!
Want to model an example of what you imagine so I can try to help in some definitive way to solve your problem?
Just so I can understand better and help you in the right way.
William Robert Alves
Hi William,
Of course! This is what I mean:
The process should resume at the same point where it was interrupted.
Thank you.
Hello my friend!
See if this meets your expectation and please let me know. 
I hope this helps!
William Robert Alves
Hi William,
This is very interesting indeed once the process is implemented.
However, I would like to MODEL the interruption of the process using BPMN (in my real example, the interruption does not necessarily imply preventing the process execution programatically, but notifying the staff executing the process that performing any task is not allowed until further notice).
Regards.
Sometimes the best error handling strategy is “do nothing”. By not interrupting the process flow, you can let the engine’s default behavior take over and the tokens will remain at the last ‘save point’. Retry from the cockpit once problem is resolved.
Hello my friend @vikkee ! Excellent comment brother!!! But i believe he is wanting to treat this manually rather than as a “process error”.
Let’s imagine a scenario… imagine that an instance of a client is running, and suddenly this client calls the company requesting it to wait for the completion of the process until further notice.
In this case, it would be necessary to “lock” the process, until the client’s authorization. This is the scenario I envisioned.
William Robert Alves
The only way that I can think of to model this would be REALLY ugly.
After your Start (or on your Start), set a variable “Paused” to False.
Then between each activity, wait for Condition “Paused=False”
At any time, when you get the request to Pause, set the variable to True.
When you get the request to “Unpause” set it to False.
I don’t recommend this, but it would reflect the reality of this process. Before your worker (employee, script, etc) does anything, they check to make sure they’re allowed to do so.
My friend @hcaballero,
I believe this might make sense for what you need.
Check if this helps you, and if it makes sense, and please let me know.
You can do this through message correlation.
When sending a correlation to Camunda, you inform that something must be done for an instance (the correlated instance), and then you will execute a script task that must contain the script to suspend it, passing it as a parameter to the suspension method the “execution.processInstanceId()”.
After being suspended, the event subprocess token will wait until the next message correlation, and when received, it will release the instance again through the script.
IMPORTANT: I’m not sure if it will be possible to do it in an “event subprocess” because the token will be part of the same instance and because it is in a suspended state, I believe that it will not be possible to correlate a message with a suspended instance.
But you can create an “another process” to create a “new instance” passing as a variable in the correlation processInstanceId that you want to suspend, and then run the suspension script, and then do the same to activate the instance again.
I hope this helps!
William Robert Alves
Thank you very much for all the answers. I thought that this situation would be far more common than it appears to be! 
I will run some tests and write back if I am not able to make progress.
Regards.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
