parallel-processingprocessgatewaybpmn

BPMN 2.0 parallel converging gateway


I have a Bpmn process map.

Let’s say it has 20 steps.

I have a decision (exclusive) gate after step 9. If the decision is ‘no’ I must perform 2 activities in parallel , however these activities both go back to different parts of the processs - one to step 7 and another to step 3 (both happening at same time).

I have used 2 link out events after the parallel gateway with 2 catch link events - one goes to step 7 and other step 3. Where should I put converging parallel gateway?


Solution

  • What it the problem?

    This is a very tricky construct that is not easy to model. The no branch of your exclusive gate would necessarily lead to a parallel gateway. Upon an incoming token, it would send an outgoing token to each of its destination, meaning at the same time at step 3 and at step 7. The problem is that you'd have a kind of trafic jam of tokens:

    This would require a substantial reengineering of your model, if you want something legit and at the same time readable.

    Alternative 1: Duplicate relevant steps in parallel branches

    If the initial flow is sequential and very different from the parallel branching, the easiest and most readable way would be to have a parallel gateway after the no fllowing step 9, and duplicate the steps in two parallel branches, that would then be joined again with a join gateway.

    Pro:

    Cons:

    Alternative 2: parallelise step 3 and 7 from start?

    It's difficult to tell from your narrative. But it is not clear if step 3 and 7 do have to be one after the other in a sequential order in the initial flow. Is it by accident or by intent?

    If it is by accident, i.e. if in reality 3 and 7 could already be done in parallel but mostly are performed in sequence, then reengineer your flow by parallelising step 3 (maybe with 4,5, and 6) and step 7, and joining the parallel flows properly. The fact that they are modeled as parallel, does not prevent them from being done in practice one after the other. The decision after step 9 would then simply branch on the initial parallel gateway.

    Pro:

    Cons:

    Alternative 3: Subprocesses (variant of 1)

    This is a variant of alternative 1. As the subchains to duplicate may be complex, and moreover, both subchains must be kept in sync when maintained, you could consider simplifying your diagram for the initial part, putting the detailed steps (e.g. 3 to 6 and 7 to 8) into subprocesses.

    The simple parallel flow would then just duplicate the subprocess box, keeping the diagram relatively simple and duplicating the minimum possible.

    Pro:

    Cons: