CODEWITHSUNDEEP
bpmn
specimen
specimen

Reputation: 1765

Stop tasks from parallel branch when another branch is taken

In the process illustrated, if the XOR gateway goes into its “else” branch, there is no point for tasks 2 A and B to continue.

Can this be drawn more elegant than what I’ve done here?

I know about the compensation event, but in this example there is no need for “undo”, just stop.

enter image description here

Upvotes: 1

Views: 1096

Answers (2)

rob2universe
rob2universe

Reputation: 7628

I see 3 alternatives, which some may consider better. To judge which option is best one needs to understand the business context and which path is considered the "happy path".

  1. Place the task 2a and 2b into an embedded sub process to define the scope in which the interruption can occur and then would attach the interrupting boundary event only once. Then remove the signal throw event and replace the catching signal event with a interrupting conditional boundary event, which check the condition: "a<=5".

solution with scope and conditional event

  1. If a >5 (> 1,(2a,2b)+3,4) is the happy path, I would model the parallel as one logical block as shown here:

solution with parallel activities in one logical block

  1. A third simpler option is to remove the signals and interrupting boundary events. Instead a terminating end event after task 5 can be use to terminate the token on the parallel branch. This option is usually less desirable in big process models as the possibly of the branch getting interrupted is no longer explicitly visible. For a small model it is more compact though.

compact solution using terminating end event

Upvotes: 2

Ister
Ister

Reputation: 6328

Well, I've seen the description without seeing the diagram first and that was exactly the solution that I came up with in my mind.

I don't see how could you draw that better.

Note, in detailed requirement it should be clear that the thrown event is limited to the scope of the current process (so in implementation it should have the process' id). Otherwise you will be throwing an event in one process and other process could catch it and react upon it.

One more thing. If you have more complex logic (instead of just task 2 a and task 2 b) you may want to encapsulate that entire logic in one larger task and have only a single interrupting event on this higher level task rather than creating one for every subtask.

Upvotes: 2

Related Questions