Hi guys,
any good idea on modelling following scenario:
To execute 4 for the first time 3 and either 1 or 2 must be executed (covered by attached model i believe)
In case there is a token in both 1 and 2 the one which is processed later should run a 2nd token through 4 (not covered by attached model).
Thanks for suggestions.
Ingo
Try out: https://docs.camunda.org/manual/7.8/reference/bpmn20/gateways/inclusive-gateway/ and look at the join behaviour
Thx for pointing me the documentation. However I don’t get the idea how it could help for the above scenario.
Also my description was incomplete.
I removed 4 bc it does not really matter for the problem.
These are the desired token flows for the 6 possible sequence of user task 1, 2 and 3 (in case 1 and 2 are set true)
1;2;3;End
1;3;End;2;End
2;1;3;End
2;3;End;1;End
3;1;End;2;End
3;2;End;1;End
In case either 1 or 2 == true
1;3;End
3;1;End
or
2;3,End
3;2;End
This model seem to work, I built a little prototype which behave as expected.
However I was wondering if there is a better and more elegant way to model this behaviour.
diagram_5.bpmn (16.4 KB)
Thx
Hi,
One of the aspects I don’t like about your latest model is there are numerous opportunities for deadlocks, eg process ends up in a stuck state. For example, it may be possible to be stuck at a join forever…
Perhaps you could rephrase your problem - its not clear to me if you are trying to implement;
Serial dependency and sequencing between tasks?
Conditional dependency, eg if task 1 then task 3?
n of m, eg if task 1 and 3 complete, abandon 2?
Depending on your requirement, there are many elegant patterns… You have given us your attempted model to your solution. Please try to rephrase as a problem statement…
regards’
Rob
Thx and I don’t like it either.
Let me try to phrase the problem.
Problem started as a simple model with only 1 and 3 beeing done parallel. Fine
Now task 2 was added. Depending on the process parameters it can be either 1 or 2 or both be needed.
If only 1 or only 2 is needed it should be again simple parallel problem with synchronisation with task 3.
The tricky part is if both 1 and 2 (and 3) are needed.
If 1 and 2 are done before 3 then just synconize with 3 and go to the end
If only 1 or 2 is done at the time 3 is done (regardless of the order) go to the end to not delay the process flow till both 1 and 2 are done. If the delayed 1 or 2 is executed go to the end a 2nd time.
Could you point me to the deadlock scenario you mentioned?
Using the Join scenario i mentioned you can just do the following:
Hi,
At the first fork, you spawn two tokens, one will go through task 3 and wait at the join. Under some scenarios, the other token could either reach an end event, or bypass the join. Hence in these circumstances, the process will never end…It may be possible with a truth table to prove this state is unreachable given the conditions, but even if that’s the case, I prefer not to model like this in case future maintenance breaks the truth table…
regards
Rob
Thx Rob, fully agree with you. I am still looking for a better approach though.
Are the requirements more clear now?
Ingo
Thx Stephen for the proposal. I did quick check and this flow only goes to end event if all 3 task are executed (for Step1 == true and Step2 == true).
But this is does not meet the requirements unfortunately as explained above.
Ingo
Hi,
Im still not quite sure what your requirement is, particularly this…
regards
Rob
What about this?
I read your requirement as you perform tasks (1,2 or both) and always 3. If 3 is complete, and one of 1 or 2, then additional process stuff can happen, however outstanding tasks still need to happen.
Hence in this case, I rely on tasks 1 and 2 setting a process variable such that a conditional gateway can trigger on it…
@pitu72 using the inclusive gateway as the join, it will only wait for the flows that active:
from the docs:
join: all concurrent executions arriving at the inclusive gateway wait at the gateway until an execution has arrived for each of the incoming sequence flows that have a process token. This is an important difference to the parallel gateway. So in other words, the inclusive gateway will only wait for the incoming sequence flows that are executed. After the join, the process continues past the joining inclusive gateway.
So if if Step 3 is always executed, and then Step 1 is only executed, then the flow will only complete once the Step 1 and Step 3 are completed. The tokens will wait at the joining gateway until the flows are completed.
So regardless of which steps you take, the will always be “synchronized”/joined at the joining gateway (second gateway). If you need more work to occur after step 3 you can follow the work of @Webcyberrob, but you dont even need the parallel gateways.
The flow you have described is all of the logical outcomes, but it seems you are mapping it like a matrix of possibilities rather than a BPMN problem and what the camunda engine offers (hence the use of the inclusive gateway’s joining capability)
Thank you guys for you inputs, appreciate.
I think main problem is that I was not able to describe the scenario well.
Let’s have another try with a more done to earth description.
Following model I found in Camunda training material.
In the scenario one can either go with pasta or steak in the choose recipe and will always get the steak or pasta with the salad. Fine.
Now let’s change requirements:
Hungry person can also decide for both pasta and steak. Salad remains mandatory.
Before discussing a BPMN approach - is the requirement clear?
Hope you don’t loose your nerves.
cheers,
Ingo
Hi Ingo,
Heres another attempt based on message passing between process instances.
Note you may also want to look at a CMMN model for yur use case…
regards
Rob
Everyone is way overthinking this. It seems that if you change your final gateway to a Conditional than you will have the behavior you want. Consider that the model works fine for the first scenario where either task 1 or 2 complete first and pass through to the final parallel gateway. Using a parallel gateway, the process waits to receive a token from either task 1 or 2 to complete and also for task 3 to complete. But consider that task 3 only receives one token at the start of the process, and passes it once. If task 1 or 2 complete and gateway 4 is conditional (instead of parallel), the condition will check to see if a token is with task 3 and wait for it, however, if task 3 has already passed the token through to activity 4, there will be no token, so the conditional gateway will see that no token exists and just send the token from task 1 or 2 (which ever completes last) through to task 4, causing it to fire a second time.
https://cawemo.com/diagrams/7ef30ef6-f8ee-4399-b053-0bd9b7753d03--new-diagram?v=681,751,1
This is actually a perfect example of when to use a complex gateway.
Hi,
from my perspective, the challenge with this thread was it seemed to be less about synchronisation of a process flow. The challenge seemed to be temporal synchronisation across the duration to perform the activities. Hence there was an intrinsic race condition which needed to be managed…My last approach thus use messages and a finite state machine paradigm to effect the desired outcome…
BTW - your Cawemo link is not public?
regards
Rob
After thinking about it, my first answer was simply wrong, and this problem is quite complex for solving diagrammatically. I was suggesting that the problem is that the use of gateways leads to an overly complex solution (and there may not even be a solution). In such a case I think the complex gateway is preferred because you can resolve the issue in an algorithm. In the diagram, I would make an assignment (JSON, etc.) at T1, T2, T3 and then just evaluate at the gateway. Sometimes, code is just better. Do you think that would work?
Steve
//
Hi Steve,
thanks for your input. I agree that complex gateway is good approach for modelling the scenario.
Problem is however: this gateway is not supported in the Camunda engine as far as I know.
Also general remark from a discussion with Camunda. For this scenario where you would possible run more than one token to 4 (here twice) it might be better to wrap it in a sub process to have control over the it.
I will probably open own thread on this.
Cheers, Ingo
Thanks a lot Rob for your effort. The idea with the messages and the sub process with event sub process is very interesting.
I don’t understand the dwell time idea. What was the reasoning?
The other limitation I see is that the boundary events at Eat meal task are only catching during task is active.
However there are a lot of interesting patterns that I will need to think over.
regards,
Ingo
