Event gateway & incoming flows do not join

[jackgeraats]

Hi,

I have the following flow where an activity is started asynchronously by executing a REST-API method and subsequently waiting for a certain kafka event to occur that indicates the activity was completed.

Now, it takes to long (e.g. more than 1 day) I would like to sent reminder (only once)
Initially I thought about modeling it like this

But that won’t work as the Rest API call completes straight away the boundary timer will never be triggered.

Hence I moved to using an event gateway like this:

This gives an warning “Incoming flows do not join” on the completed event listener step. Normally one would join the flows using a parallel gateway but as the event gateway expects an exclusive gateway but I cannot put that in between the event gateway and the completed listener.

I thought about routing it back and put the exclusive gateway before the event gateway but that might trigger the timer again (which is not desired as the reminder should only be sent once). Of course I could keep track in some process instance variable if the timer was already executed and check that in the flow but that seems a very cumbersome way to do it.

Any ideas how to do this nicely or should I simple ignore the "“Incoming flows do not join” warning in this case ?

[Niall]

Good question.
I guess it depends - are you intending to send the reminder exacly once or do you want to loop it?

[jackgeraats]

To loop it, the routing back solution would work. I was looking for a clean and simple solution to only send the reminder once if needed.

[hassang]

A model similar to the one below should meet your requirements. You can use the Result variable from the output mapping of the Kafka intermediate catch event to determine whether the event was received, and based on that, decide whether to send a reminder.

[GotnOGuts]

You could wrap the section you want in a sub-process, and put a non-interrupting boundary event on that.

[claudio_rio]

Ideally, if we had a Kafka Event Receiver task, it could be as simple as the top diagram in the image.

But the second best option, as @GotnOGuts suggested, is not that bad.

[Niall]

So I can think of 3 pretty good options here - but it depends a lot on what you want to prioritize as part of you’re modeling. I’ve added them all here if you want to see them in a more readable way. https://modeler.camunda.io/share/0c8ea67c-d076-46bf-bbe5-e459d03f9c09.

@hassang had a pretty good suggestion, that I would say is more verbose but the easiest to read and understand for non-BPMN folk:

@GotnOGuts’s suggestion is pretty good because it really clearly indicates the happy path but might confuse some readers new to BPMN since it has both a non-interrupting boundary event AND a sub process.

One of the really nice things about this option is that i can be compressed further if you want to hid the kafka stuff and it won’t take away from exectuion.

I also decided to create a combination of both patterns. This uses a terminate event to end the sub process as soon as the message from Kafka arrives.

If you want to hide all the detail from the viewer of the model it also compresses down to just one task.

[claudio_rio]

Oops. Forgot to change the events to non-interrupt but @Niall came for the rescue.

[jackgeraats]

Thanks all for your help, think this summarizes the different options quite well.