Hi @Tauwin
I think there is nothing wrong with your model.
Due to using boundary timer event, your solution is better than using intermediate message event.
In the event that the assignee receives the document prior to the timer going off, your process ends. I do not think this is what you intend.
In a “Good Practices” note, all activities should be named “(Verb) (Noun)” (at least for English. Other languages may be different) this is due to the imperative nature of this construct. This is an instruction to the assignee. “Doc Available” does not match this structure. What is the action (activity) that the assignee is to complete?
The way that you are using the boundary timer is correct, but you might want to consider using either non-interrupting timers (send the request for the document again until you get it), or determining what the flow should be if the document never arrives.
You may need to refactor this a little bit to have it executable in Camunda Community Edition - if your “client” is too fast on returning the document, the process might not be ready to receive it yet. The usual design setup to solve that is to put the “Request” and the “Receive” in parallel. This will need some extra thought to design for having a timer on it as well.
@GotnOGuts
Thank you for your answer. Sometimes it’s hard for me to put things in verb tense and also keep it short and sweet. But I will make the final changes.
I have already changed the structure of the BPMN. Maybe you can look at it again.
Changelog
If the document is not received after 2 hours, it will be requested again. The same for missing data. I will not break it down any further. This behaviour is sufficient for the description of my client’s process.
For improved clarity, you might (not required, just a “might”) want to put an Exclusive Join before the “Check Complete” user task. How you have modeled it will work, but you aren’t consistent comparing your paths for “Doc Exists” and “Check Complete”
You are multiplying the number of tokens on your “Receive Doc” and “Receive Missing Data” tasks, even though you did exactly what I said to do.
Every time your timer goes off, it will go back to requesting the Doc again, which will then flow into another Receive task (this is BAD for executable diagrams).
You can use either an interrupting timer (as you did in your first diagram), which will end the receive task; or you can leave the timer as non-interrupting, and add an additional “Repeat Request for Doc” with the same message as the “Request Doc” followed by an End step. The token that gets created to handle the timer will disappear in the End step.
@GotnOGuts
Good morning GotnOGuts,
maybe you could actively help me. As written, I am a beginner and am trying to learn BPMN. I have certainly not yet internalised good practice and I have not yet executed my diagrams. That is not my goal, to create executable diagrams.
In the second version of the attached process, you’re missing the “happy path” from the “Received Doc” (with the two day timer). If you connect the first “Receive Doc” to the Exclusive Join as well, then if the document is received in that first activity, it will flow through correctly.
The first version can end up in an infinite loop. Every two days, “Receive Doc” will be cancelled, and a fresh request of the document will occur. The system would then wait for 2 days to receive the doc. It can wait there forever if the document is never received.
I have a copy of “Real-Life BPMN” which I found really quite useful, but I’ve also read “BPMN Method & Style” which covers some other logistics.
