The Main Holder of the account can invite some joint holders during its own onboarding process. In the solution I’ve implemented, the “Invite Joint Holders” user task sends a message to the parent process and triggers the creation of N parallel multi instance call activities.
In the happy path, once the main holder and the 2 joint holders have finished, the workflow can proceed on the service task. It works as expected
However, the main holder must be given the ability to cancel an ongoing joint holder onboarding. I tried to cancel the first joint holder process via deleteProcessInstance method. The parent workflow looks like this.
When I try to complete the call activity of both the main holder and the remaining joint holder the workflow does not complete, it is stuck in this situation.
Is there a way to cancel the process instance so that the service task get executed after the parallel gateway? Alternative, is there a better way to model the scenario?
If the message never arrives while the Main Holder Onboarding is still in progress, your process will never end.
I’m not fully understanding your model. Is the standalone process that sends a message to the main process a representation of the Main Holder Onboarding? If so, you’re really sending a message from the process to itself, which isn’t allowed.
If the message never arrives while the Main Holder Onboarding is still in progress, your process will never end.
You are right, I took it for granted without testing it.
I’m not fully understanding your model. Is the standalone process that sends a message to the main process a representation of the Main Holder Onboarding? If so, you’re really sending a message from the process to itself, which isn’t allowed.
The message is sent from the main holder Onboarding (child process instance) process to the Account (super process instance). When the message is received, the account process adds a new branch/token with the joint holder onboardings call activities.
Here’s the BPMN file. I tried to model it based on this stackoverflow answer but I probably missed something. Any suggestion?
EDIT: additional information. I already designed this flow without parallel gateways and without call activities, but orchestrating the message flow between parent and child is becoming triky and relies too much on custom implemented logic.
I’ll have to dig in a bunch to try to throw some high-level images back.
Remember that when you have a “Main Flow” process throwing messages, and a “Implementing” process starting from those messages that each “Implementing” instance is distinct. That can help.
There’s a whole set of chapters on this in BPMN Method and Style that helped me wrap my head around it, but it’s more theory than practice.
If I simplify your diagram as follows, can you see how what you’re trying to do is an issue?
The StackOverflow that you linked to is about getting a message from OUTSIDE the process, not about getting a message from within the (called) process.
Remember that when you have a “Main Flow” process throwing messages, and a “Implementing” process starting from those messages that each “Implementing” instance is distinct. That can help.
I’m not sure I’m getting the point, sorry. For an account creation with 1 MainHolder and 2 JointHolder I actually expect 4 distinct process instances. 1 for the account, 1 for the MH, 2 for the JHs.
If I simplify your diagram as follows, can you see how what you’re trying to do is an issue? The StackOverflow that you linked to is about getting a message from OUTSIDE the process, not about getting a message from within the (called) process.
Not really, sorry. I’m not seeing the difference since the message could be also sent from outside the camunda context just using the createMessageCorrelation API.
In the version you’ve drawn it seems that 1) the account process instance and the main holder process instance are the same 2) the main holder can’t insert its own data unless the joint holders have finished.
An alternative solution I am exploring (working so far) is this.
That’s because I don’t understand the process you’re trying to convey.
Basic BPMN rules are that you cannot send a message from within a process to itself. Your processes continue to break that rule, which is why you’re having trouble. Even though you can do it by using workers and reaching outside the context, you shouldn’t
A “call activity” is effectively a code refactor that allows you to move steps into a different logical diagram (and allows for re-use), but it’s really one process. Try remodeling your entire set of processes as one process (no call activities), and that will help you get the logic straight. Then refactor to call activities / message controls later.
Thank you, apparently I need to go back to the basics
Try remodeling your entire set of processes as one process (no call activities), and that will help you get the logic straight. Then refactor to call activities / message controls later.
I already modeled the process and it is already running in production. The simplified version of what I’ve modeled is this:
the main holder decides to open an account
the application instantiates the account process instance and the main holder process instance
main holder invites a joint holder and a new onboarding process instance (related to the same account) is created
an event listener (spring boot) receives an event every time an onboarding is terminated or aborted
when all the onboardings related to the same account are terminated or aborted, the application sets the condition “allOnboardingsCompleted=true” to progress the account workflow
My question originated from the fact that I’m not sure that I’m taking advantage of the bpmn features here. Step 4 and 5 described above are basically implemented to handle potentially concurrent termination of processes. Isn’t this the role of a parallel gateway?
