Modeling asynchonous catch message with timeout

Q&A
1

Hello,

I have a business case in which my process is calling a backend system and then is waiting during a certain time for an asynchonous message/event coming from that system.
My concern is how do I model this timeout on the catch message task.
I first thought to a service task sending the message, then a parallel gateway with 2 branches connected to a timer for timeout, and message catch task, and then an exclusive join to process the first task to finish.
But it’s a bad design to have a parallel gateway with an exclusive join gateway, because what will happen if the catch message task finishes after the timeout ?

I imagine that it is a common pattern, but I cannot figure out how to model it.

Can you provide me with advices ?

Thanks in advance

2

Hello,

You are correct, using a parallel gateway will not solve your issue.

There is no solution using Bonita based on a Catch Message. Because in Bonita, messages do not expire. imagine you wait for a catch message, and you go out the task due to the timeout: when the sender finally sends the message, there is no more any listener, and the message will stay forever.

You should use a Human task (then you can use a timer event) and do not send a message, but search the task and execute it. If you can't find the task, that's mean the timeout was fired.

This is the way we integrate a "timeout receive message".

Hope this help,

 

3

Hello Pierre-Yves,

Thanks for the answer. I did not think of this approach. I will try it out

Regards

4

Hello Pierre-Yves,

I have implemented your first solution and it works fine, in the server that was sending the message I search for the active human task and execute it, as proposed.

Thanks a lots

5

Hello,

I was thinking about a new solution;

* create a Human Task

* add a timout on this human task

* add a Message Boundary Event on this human task

==> You wait for a message OR for the timeout. If you want to execute it by an administrator, you can

I prefer the first construction because doing that, you may generate a lot of messages in the system. A message is kept in the database until a correlation matches it. So, if you send a message, but the task is overdue to the timeout, the message will stay for ever in the database.

That why we prefer the first construction when we know the message can not fit anything.