Hi,
I’ve currently some problems interpreting the documentation for signal events. Especially this part isn’t clear to me:
Contrary to other events, such error events, a signal is not consumed if it is caught. If you have two active signal boundary events catching the same signal event, both boundary events are triggered, even if they are part of different process instances.
For me this sounds as it’s also possible to define two signal boundary events in scope(e.g sub process). But if I try to deploy such a process I get an exception from the process machine.
Cannot have more than one signal event subscription with name 'test' for scope 'SubProcess_00drne1'
Also, I cannot find a documentation point that disallows such a definition, as for the error event as example.
Maybe someone can bring some light tho this!
Best regards,
Christian
Hi @christian.kaps,
do I understand correctly that you want to have 2 catching boundry signal events on one embedded subprocess? Is there a specific reason to do that and not to use parallel gateway with a single catching signal?
Cheers,
Askar.
Hi,
No there is no special reason. I just try to evaluate the process engine and try understand how it works.
Cheers,
Christian
Hi @christian.kaps,
The docs and the parser reflect what is defined by the BPMN specification. The docs you quote mostly refer to the case in which you have one process model with one signal boundary event, but more than one process instance that can receive that signal. When you trigger the signal, all instances are going to receive it (as opposed to messages that must have a single receiver according to the specification).
The same holds for one process model with two boundary events: Both are going to be triggered. However, there is a restriction in that you cannot have two interrupting signal boundary events attached to the same scope that listen for the same event (i.e. the parser error you posted). The reason is that not both handlers can be triggered as they cancel each other. I am not 100% sure if this is covered by the BPMN specification.
I hope that makes sense.
Cheers,
Thorben
Hi @thorben,
Thanks for your explanation! It’s more clear now. But, do you say that the restriction is valid only for interrupting events? I ask, because if I test it with non-interrupting events, then I get the same exception. The same issue also occurs if I have a signal start event in a event sub process and a signal boundary event, both in the same scope.
Cheers,
Christian
Hi Christian,
Yes, I guess the restriction could be relaxed in cases where there are only non-interrupting events.
Cheers,
Thorben