Mohit Mehra: How can we pass through A to B without any timer any quick suggestions
Josh Wulf: Can you elaborate? The question is not clear.
Mohit Mehra: We need to make Service Type A as optional we dont want to keep it as mandatory state
Mohit Mehra: if i dont receive information related to A i should not wait there just move to next B
korthout: Let me answer here as well: As I understand you want task A to be optional. I think you need a terminate end event for that, but Zeebe does not support this element
korthout: Instead you can use a workaround with error end event in a subprocess with a error boundary event. It’s a lot more complex. Perhaps there are better ways, but this is what I can come up with
tiesebarrell: In fully fledged BPMN, you might use an inclusive gateway for that. Since that’s not available, have you considered conditional flow? Zeebe Modeler supports that.
korthout: Yes, that works as well as long as you know beforehand that task A will/should be completed or not
tiesebarrell: True, I made an assumption there. In the diagram shared, how else would you know? There’s only the start event before, so the condition has to be known up front I guess
korthout: Yeah its gets more difficult if its not known at that time. The more I think about it, the more I dislike the terminate end event to achieve this because it terminates in stead of completes the workflow instance. I wonder if there is some better common pattern for this.
saig0: I think the solution with the boundary event is a quite common pattern. Optional tasks are also a typical use case for CMMN
Josh Wulf: Can you not simply fork to A and B, then go from optional A to an end event?
saig0: Yes. But if A is optional and is not completed then the workflow instance stays active.
Josh Wulf: The worker will pick up the job for the task, so it can just complete it without doing the work. How is it “optional” in any case in these designs without the worker making the determination?
korthout: Interesting point to consider, but you then say that the task is completed, which is a little misleading from the business perspective. It doesn’t show whether you did or did not do the work in a traceable manner
Josh Wulf: Doesn’t the error event do that? What happens if my B Task worker throws the BPMN error before the A Task worker completes the job? Do I not end up with no data in the history about what happened in A? There is no ability to retry or throw an incident in A then, no?
korthout: You’re absolutely right, its not a nice workaround and I’m interested to find something better
saig0: Maybe, something like this:
Josh Wulf: What does it mean “optional”? Could you not express the condition of the optionality in the diagram using a parallel gateway?
Josh Wulf: That logic has to live somewhere. If it is in the worker, then completing the task is the only way to ensure that it has been considered and discarded. So I think the optionality needs to be expressed in the BPMN, or the optional task worker needs to acknowledge that it has completed the work - which includes “I considered this, and we didn’t do the side-effect” - which has the flaw that @korthout points out - you can’t tell easily by looking at the diagram if it did the side-effect or not.
tiesebarrell: that was my point as well. Either it’s simply an optional task which is determined by one of the inputs and you can use conditional flow to perform it or skip it, OR it’s some task somewhere which determines whether or not to execute the task, then does it itself or you just continue to an exclusive gateway that forks into actually executing the task. For the former, when the task execution is decided and performed in the same worker, you could still have a gateway after, that just forks into different end events to make it visible.
However, some of the suggestions are about cancelling one task when the other has completed and such, but it’s unclear whether that has to do with the optional part. So defining what behaviour is needed has to be clear before we know which option is best.
Josh Wulf: Yes, if the logic is too complex to put into the diagram (needs side-inputs), then you can do the calculation in a worker, then complete that task with a flag, then put a gateway, and action the optional task or not on the other side of that. If it is a simple condition, then you can put it in the diagram.
korthout: So as I understand you are describing something like this? First determining whether to skip A. @Mohit Mehra Perhaps this is can be used in your situation as well.
tiesebarrell: Not entirely, I wasn’t aware that the order was important. In your diagram though, A would not be activated if B comes first, so I don’t think that works.
Josh Wulf: The text is wrong. It should say “Include A, or only B?”
Josh Wulf: That’s all.
Josh Wulf: And the task should say “Determine whether to execute optional task A”
korthout: Another idea is to use a message boundary event, using the external worker model. When the worker for task B completes a job it should publish a message that B is completed
tiesebarrell: For the optional task, determined by a task worker, this is enough
tiesebarrell: If the input is known up front, just remove the determine task
korthout: I’m really enjoying this modelling exercise
Note: This post was generated by Slack Archivist from a conversation in the Zeebe Slack, a source of valuable discussions on Zeebe (get an invite). Someone in the Slack thought this was worth sharing!
If this post answered a question for you, hit the Like button - we use that to assess which posts to put into docs.