in our process model, we’d like to pass the control from one part of the process to a subprocess. We’re going to use the escalation event for that.
My question is: Would it be an intended usage of this event type? The control transfer does not happen because something went wrong. It’s just because we decomposed our process model in smaller parts. So it’s not really an “escalation”.
Would using the escalation event for this purpose be OK? Or is there a better solution?
My advice on escalation is do you want to transfer control somewhere else, or do you want to start an additional (concurrent) process token at a new location whilst the current one continues?
If its scenario 1, then consider a BpmnError. If its 2, use an escalation…
Escalation events are mostly used to communicate from a subprocess to an parent process and not the reverse.
An escalation event is propagated to upper scopes (e.g., from sub-process or call activity) till it is caught.
An escalation start event can only be used to trigger an event sub-process - it cannot be used to start a process instance.
When the process engine executes the throwing event, a catching event subprocess on the same level of subprocess or an event (boundary event or subprocess) on a higher BPMN scope are triggered.
Call Activity or Message Event would be appropriate if the subprocess is not an embedded subprocess or event subprocess.
If it’s embedded subprocess, Message Event would be appropriate for this use case.
@Webcyberrob BPMNError event is intended for handling business errors. How it can used for delegating the execution of certain part of process? Is it good practice?
Actually, one thread of the process ends with an escalation event and starts a subprocess. A BpmnError suits even less for that in my taste, the semantical distance from the intention is greater.
Its a good point you make…I guess it depends on what we mean by escalate. (1) I could escalate a request to a higher authority (eg transfer control), (2) i could escalate that something is not complete within an agreed SLA (eg notify but not transfer control).
Thus for (2), a non interrupting timer is useful as it can ‘notify’ without transferring control. For (1) an (interrupting) error event can transfer control
So my main point is to recognise the subtle difference between interrupting and non-interrupting situations. The escalation event is suited to non-interrupting situations…
The BPMN reference has an example which kinda models this…
If we consider creating concurrent process token in “new location (entirely different pool)”, then escalation won’t solve the problem, but non interrupting message event (for concurrent token) can. Correct?
Absolutely - message events work well for inter-process communication. I tend not to use escalation events as message event to an event driven subprocess, or interprocess communication, both interrupting and non-interrupting captures all my use-cases…
Thank you for the tip @Ingo_Richtsmeier. I have read about the conditional events and it was a useful reading. But I still think that escalation events better fit in our case. First, we don’t have any conditions to evaluate. Second, conditional events have more complicated triggering mechanism: one has to take care about when the conditions are evaluated etc. An escalation event just does exactly what we need: silently pass control (transfer the process token) to another place in the process. And that without having to write any code!