The issue is that because the event subprocess is non-interruptive, both throw events trigger almost simultaneously, causing the “Sending SMS” Service Task inside the event subprocess to execute in an unpredictable order, leading to issues.
What is the simplest way to ensure that the first event subprocess completes before the second one starts?
(Note: The flow is simplified to illustrate the problem; the actual process is more complex.)
The easiest way to make this happen would be to stick a timer event that could trigger after 5 seconds between the two message send events. It’s a little hacky… but it’ll get the job done.
I know that this is a simplified model, but what’s shown doesn’t follow the BPMN rules… the “Update Status” message should be coming from outside the process instance, not from within it.
To me, in this simplified example, the easiest fix is to move the “Send SMS” step into a distinct process, and then use a “Call Activity” where you have the to “Send Message” events. Since “Call Activity” will be Sync, it will keep them in order.
Thanks for the suggestion! However, using a timer event is not ideal because time is relative—‘Sending SMS’ may take longer in some cases, leading to potential race conditions. What would be the best practice or the perfect way to implement this?
How about designing an Intermediate Catch Event that receives a completion confirmation before triggering the next step?
Thanks for the feedback! Could you clarify why this model doesn’t follow BPMN rules? I need some tasks to run asynchronously/in parallel without interrupting the main flow’s progress. Do you have any suggestions on how to implement this correctly while staying BPMN-compliant? Also, I’d appreciate any references to BPMN rules or best practices to review. Thanks in advance!
Since your requirements involve both asynchronous execution and ensuring that SMS messages are sent in a specific order, I prefer using a timer only after the first throw message (as suggested by @Niall). Since the second throw message is the final one, there is no need to block execution after it, unlike in your last suggested solution where you used a catch message “Confirmation”.
Additionally, I prefer modeling the SMS sending process as a separate process (as suggested by @GotnOGuts ) rather than an event sub-process.
Could you please elaborate on which specific BPMN rule this violates? In which BPMN specification or detail is it stated that the message throw event must come from outside the process instance or that it shouldn’t be thrown and caught within the same process flow?
The rule being violated is that message events cannot have the same destination and origion process.
They’re indented to show cross-process communication and so this isn’t strickly correct BPMN
The BPMN spec requires all messages to be thrown across the process instance boundary. Since the message is being thrown inside the process, and caught within the same instance (in an event subprocess), that doesn’t meet the spec.
You could simply put the event subprocess into its own process, and throw the message, but if the overall process ends, this other process could live on.
I understand that continuing this discussion may deviate from the main topic, but I’d still appreciate any insights on this matter.
Based on the BPMN specification stating that ‘messages must be thrown across process instance boundaries,’ I’ve modeled the process as shown below:
Regarding the suggestion: 'You could simply put the event subprocess into its own process and throw the message, but if the overall process ends, this other process could live on…
Turning the mentioned event subprocess into an independent process would require calling it via a Call Activity or Message. Since a Call Activity acts as a synchronous/interruptive mechanism while a message throw event enables asynchronous/non-interruptive behavior, does this approach make sense if it is intended to progress the flow asynchronously ?
The top image would meet your Async requirement, but has no guarantees (but high likelihood) that the SMS messages would happen in order. They should happen in order, as your worker should be processing them based on create time, but that’s a whole other conversation.
The bottom image will NOT allow your Async requirement, but will guarantee that the SMS messages go in order.
So the question really becomes which of the two requirements are more important?
