Is the zeebe task blocking (or synchronous)

In the usual camunda BPMN engine (not zeebe) a “service task” is not intended for activities that take a long time to complete, and is typically used to invoke a non-blocking function of some kind. In that engine, the “human task” is recommended for situations where long waits/delays are expected.

The zeebe engine has no “human task”, so my question is how do we model activities that take a long time to complete?

Some parts of the documentation suggest that zeebe’s “service task” is in fact robust enough to handle long delays or waits. For example, a line on the Service Tasks page clearly states that “When a service task is entered then a corresponding job is created. The workflow instance stops at this point and waits until the job is completed”.

But the Message Events page has a diagram that seems to suggest that the service task merely kicks off the desired activity, and it is the BPMN author’s responsibility to add a downstream “Intermediate Message Catch” to wait for that activity to complete. The names on the elements (“Collect Money” and “Money collected” also reinforce this point of view)

Can someone clarify this topic please? And if zeebe’s “service task” does indeed support blocking usage, can the diagram on the Message Events page please be changed or suitably annotated to provide a clear description of the way these elements work in practice?

Thanks in advance for any help with this.

Sanjay Dasgupta

Hey @sdg

thanks for your report.

I agree this diagram looks a bit confusing. I think the idea behind that was just to model all message catch events, which we support.

Yes you can use the service task for long running things and it will block the workflow instance. You can compare it with the external task pattern of the Camunda BPMN Platform engine.

I created an issue to fix this diagram to make it less confusing.

Hope this helps.


1 Like