Cross workflow communication between Zeebe & Camunda

@wints @philipp.ossler, I was trying to understand what problems zeebe can resolve.

Also referring the writeup:

We have multiple microservices. Lets say, we have built around 5 major workflows using camunda for each microservice, where each workflow is modeled using various bpmn notations like message task/user task/ timer events, error events/Embedded sub process, etc.

In this use case, how zeebe fits?

Do we have to migrate all camunda workflows to zeebe which has usertasks/message recieve tasks which is not available in zeebe.?

Or By using Zeebe just integrate the microservices, and let the individual microservices use their own camunda workflows?

I’m considering below use case, please correct me if i’m wrong.

Each step in zeebe will execute respective camunda workflows to handle their job? :slight_smile:

Hi @aravindhrs, thanks for the question!

First, a couple notes:
• Good news, Zeebe does support the Receive Task! You can read about it here: Not sure if that changes the approach described here, just FYI.
• Although Zeebe doesn’t support the User Task, it might be possible to replicate User Task behavior if you were to use a Service Task in your model then build your own user-facing Tasklist-like ( application that embeds a Zeebe client for communication with the broker. Zeebe doesn’t have a Tasklist or anything similar right now, though.

And a broader question for you: what would make Zeebe the best fit for orchestrating these services in your use case? For example, it’d be possible to use Camunda BPM for orchestration. Are you interested in Zeebe for scalability / throughput, or is there something else about Zeebe that makes it the best for this use case?

From a technical standpoint, the use case you described–using Zeebe to orchestrate “services” that are themselves workflows executed by another engine–should be possible, but I’m hoping to get a bit more info about how Zeebe might fit with it.


I have thought about in what are the ways zeebe can fit into my usecases. And I found 2 design solutions.

  1. We are already running couple of microservices, each will have their own business implementation and own camunda bpmn workflows which has usertask/manual task,service task and other bpmn2 standard notations. So i can design zeebe workflow to integrate these workflows execution into one parent process using zeebe where each camunda workflow will be defined as service task and let the job worker intitate those camunda workflows and update the job completion status to broker.

  2. Create tasks in zeebe for each microservices and eliminate the camunda workflow, thus microservice refactor will occur wherever manual task or other task types used. In this case only zeebe workflow will exists, and each task type will refer to one microservice.

Thanks for the detail, @aravindhrs. From a technical standpoint, both of these approaches should be possible.

One thing I’d mention: whether you use Zeebe or Camunda to define this high-level “parent” workflow (where each task is executed by a microservice that itself might also have logic that’s modeled as a workflow), our recommendation is to always keep microservice-specific logic in each microservice only and to not let this mircoservice-specific logic drift into the high-level workflow model.

Bernd talks about this in one of his blog posts in case it’s still not clear the way I described it: (see the “Ownership of process models” section).


1 Like