I’d like to be able to easily navigate back to the last step in a prior expanded subprocess, but cannot find a way to model this using the various event types.
In essence I want the Link Event but with support across subprocesses, which sadly isn’t possible - to be clear, the BPMN shown below doesn’t work and in fact cannot be deployed as the Link Events are invalid, it is only to show what I would like, not what I can achieve currently.
In the example here assuming that I am at step “Zone 2 A” I want to be able to send a message “Message_Go_Back” and arrive back at the step “Zone 1 B”.
I am pretty sure I could probably use a scripting task and set a variable, and then route out of each expanded subprocess but this seems to be a bit of a fudge and may be complex to maintain going forwards.
Is there a way using any of the catch/throw semantics within Camunda to achieve this is a concise way (I’ve tried most such as Signals, Messages etc and I couldn’t get them to work).
Just to further explain why I want to use expanded subprocesses, it’s because I want to put timer boundary events on each expanded subprocess in order to track time spent in each zone for analytics purposes.
So, once the boundary message event is triggered on zone 2, then the process will continue by the sequence flow emanating from the message interruptin event. This means that the end escalation event (“Go to zone 1”) will be triggered and subsequently catched by the catch escalation event that will direct the process back to zone 1. (I guess in the escalation end event of zone 2 you need to create a variable for example: triggered=true).
Afterwards, with a gateway that checks the previously created variable (triggered=true), the process either continues to zone1a or to zone1b.
Thanks for the quick reply; after I posted my original question I did tinker with the use of a variable and routing, but your example of using an escalation has certainly helped tidy up the use of Gateways…
As you mentioned, I have had to set a variable (“GO_BACK”) that allows me to route once back to the prior expanded subprocess.
The use the following routing condition has meant that I don’t need to have the variable around prior to the evaluation of the “go to step” router though, so that is a positive.
.
