I’ve got a question related to how webMethods 9.8 implements BPMN 2.0, specially about Intermediate Message Event (catching).
When placing an Intermediate Message Event in the normal flow for catching, the token will stop on this step, waiting for the Message to be received.
When receiving the Message, the outgoing Sequence Flow(s) will be used and the token will leave the Intermediate Message event step and continue the process.
But what happens if another Message event is received for this step, later in the process? Will the Message Event be ignored, or will it be catched by the Intermediate Message Event step, that has been already run?
Message will be ignored as no intermediate step is waiting for it. If business requirement is to receive multiple events for intermediate step , loop should be define such that after execution of step , transition should go back into intermediate step. You can use gateway steps to achieve this.
The Message is “ignored” in the sense that it is making any progress in the related Process Instance.
But there is a BIG side effect when resending the message a second time: the related Intermediate Message Event step is back to “waiting” status and so, for example, if there is a “Join Timeout” set on this step, it is fired when receiving the second Message… so, it is not really “ignored” from my point of view…
When sending the second document again, the join step will wait for the first document again and as this one most likely will not be repeated executes the join timeout path.
You will have to avoid that the second message can reach the process instance a second time.
Agree with Shahed that this can be handled by a loop back using gateways if this is a planned behahaviour.
Addtiionally check the config of the WmPR package w.r.t. “Duplicate Event Detection”.
I cannot avoid the second message to reach the process instance a second time, because the external application that is sending the message is a web app and I cannot easily avoid the end user to double-click on the link/button…
I just had a look at the “Duplicate Event Detection” option, but it seems to be able to detect only Start Event Messages to avoid duplicate process instance creation: am I right? Is it also working for Intermediate Message Event?
The second message will be forwarded to the process instance if the process instance still holds the appropriate correlation (most likely the case if you don’t do anything to delete it). Hence the catch event will be in waiting state.
If you can’t prevent the world from sending you messages (which you normally can’t) then you should redesign the process so that it can receive and process the message a second time.
But in the end, you won’t be able to gracefully process them all since eventually the process instance will run to the end and will then receive no messages. There is a cut somewhere, we have to live with that.
I’m ok with your proposal to redesign my process to manage message a second time.
Anyway, I’m still thinking that receiving the Message a second time on a step that is completed should not have impact on the process instance.
Which is not the case currently as following actions are done when receiving the second message:
the step status is set from “Completed” to “Waiting”
In fact my idea was to not implement any logic about this in my process, nor in the client Web application.
I thought it’s the responsability of the webMethods BPMS Engine to “properly” ignore the second message on a already “completed” Intermediate Message Event.
there is a Built-In Service in WmPRT package for this.
You might want to check with SAG Support via Incident if your assumption is correct or not.
Depending on the outcome it might be worth to open a Feature Request in Brainstorm to get this adopted in future.
Then you should set the timeout no in the catch event but in a step after that. The main process thread should fork. In one branch there is catch event without timeout, the other branch goes through. Then the branches join. At the join you’d have the timeout configured.