What class/method is called in an event catching node that is standing after an event based gateway?

[fedd]

I need to hook into the message event catching behaviour even if the execution is currently waiting on a preceding event based gateway.

Exploring the sources didn’t help to understand the magic behind this. The “behavior” class of the respective gateway type says it’s in a wait state…

Which listener or behavior class/method is called regarding a message event, when a) we are beginning to wait at the gateway for one of the events to occur b) the message event occurs c) another event occurs and the message event is no longer expected?

[thorben]

Hi @fedd,

@fedd

a) we are beginning to wait at the gateway for one of the events to occur

You can add a start execution listener to the gateway.

@fedd

b) the message event occurs

You can add an end execution listener to the event

@fedd

c) another event occurs and the message event is no longer expected?

There is no direct way for that. In the listener on the event that is triggered, you can deduct that the other events did not trigger by inspecting the BPMN model.

Cheers,
Thorben

[fedd]

Additional small question just to be sure about a regular message catch event. Will it normally invoke a start execution listener upon arrival and before it starts to wait for a message ----- and after the message arrives, invoke the end listener before moving on? (With the only exception for the catch message after the event based gateway)

And one completely lame offtopic question exploiting your kindness… the non-interrupting boundary message catch event: does it disappear from process once invoked, or continues to “listen” to the named events? as per bpmn standards and per Camunda implementation. The docs seem ambiguous, I understand that the activity to which the boundary event is attached stays active, but what about the catching event. Sorry, thanks. (I know it doesn’t actually listen, I have to invoke it by name and execution)

[thorben]

@fedd

Will it normally invoke a start execution listener upon arrival and before it starts to wait for a message ----- and after the message arrives, invoke the end listener before moving on?

An event-based gateway works internally like an activity with interrupting boundary events. I expect the start listener to be invoked when the event triggers.

@fedd

And one completely lame offtopic question exploiting your kindness… the non-interrupting boundary message catch event: does it disappear from process once invoked, or continues to “listen” to the named events?

The Camunda implementation is spec-compliant here, i.e. a non-interrupting boundary event can be triggered more than once.

[fedd]

Thanks!

An event-based gateway works internally like an activity with interrupting boundary events. I expect the start listener to be invoked when the event triggers.

Will at least the Behaviour be called when an event is reached and entered a wait state? Weil, to make it enter a wait state. Not speaking about when it’s after an event gateway, but all other cases

[thorben]

For intermediate events, the start listener and activity behavior are invoked when the token flow arrives at the event.

[fedd]

Aaa, sorry, was confused. So the start listener will trigger in an intermediate message event when it starts “listening”, except it won’t when it’s after an event gateway. Seems logical and clear. Thanks for your patience!