Receive Message Task with Timeout
I can't help feeling that I'm missing something really obvious here but I can't see how to do something I would have thought would be simple.
Bonita version 724 Community
I need a process to receive a message and to timeout if that message isn't received within a certain duration.
A receive message task with a boundary timer event would seem to be the totally obvious way of doing this, but that's not an option. Receive task can only have error boundary events (which I will use for the time being).
How do you express 'wait for message with timeout' in Bonitasoft?
Thanks for taking the time for such an in-depth answer. After years of writing java s/w where having a timeout is so simple it seems odd to me that it isn't here =)
If you look for this issue on the Googles you find pictures of BPMN processes where Receive Message tasks do have Timer boundary events.
Two Step Escalation: Solution 2 has a timer boundary event
Also shows this.
I guess you could describe it as "Process 1 fails to send a message and throws a 'Fails To Send' error" 'Process 2 catches a 'Fails To Send' error, but everyone will look at me strangely =)
The message exchange occurs halfway through a process so it's not a question of invocation.
I would raise a bug here against Bonitasoft's implementation of the BPMN standard which allows timer events to be placed on a Receive Task.
The actual reference in https://camunda.org/bpmn/examples/ is Solution 2: Receive Task with timers attached
This way either Bonitasoft will address the issue and allow it in a future version of the software, or explain how to do it within the product itself, as you're right, it should be possible.
Make reference to this thread so I can follow as well.
thanks and regards
Yeah I see your problem, it's the good old * Chicken before the Egg * issue, and it's not that obvious on how to fix.
Here are two methods we use, which one is best is up to you though (and where the message is coming from in the first place):
The first thing is to remember Catch Message is used to Start a process or Restart a existing process.
Your thinking the message will always be sent and if not received in time then flag the error. Why not think about why the message was NOT sent and then raise that error first.
You have to start the receiving process which will then wait for the message and then error out.
Method 1 is best in nearly ALL cases because it identifies the root of the issue, that the preceding task failed. It is not the second process that failed but the first. Method 1 also means you can start process 2 through the message rather than when using method 2 when you could have 10s, 100s, or even 1,000s of processes waiting for messages which may or may not arrive causing big problems for all other resources.
So to fix your problem use Method 1 and change the SENDING process to flag the error I've not been able to send the message which is more true than the receiving process saying Nobody told me
The later is the human side of processes, the former is the automation side of processes. Your're thinking like a human whereas you should be using automation :)
PS: As this reply offers an answer your question, and if you like it, please Mark UP and/or as Resolved.