Why force Zeebe elements onto BPMN?

Camunda 8 Topics Discussion & Questions
1

I wonder why I cannot use a simple BPMN diagramm in Zeebe: without the additional zeebe:taskDefinition type="foo" for each task, the workflow cannot be deployt.

I really like the idea of having only the workflow-state in Zeebe and using job-workers who register themselfs. But I dont see the reason why a job-worker cannot just use the BPMN-standard Task-Id field to register itself? Maybe there is some added value in doing so, but for simple one-to-one mappings from task → worker it just feels wrong (and gives the impression of wanted vendor-lock-in).

2

Hi @lostiniceland,

thank you for your input. So, your proposal is to use the element id of the service task as job type if no zeebe:taskDefinition is defined?

    <bpmn:serviceTask id="payment" name="Payment">
      <bpmn:extensionElements>
        <zeebe:taskDefinition type="payment" />
      </bpmn:extensionElements>
      <bpmn:incoming>SequenceFlow_1xdmkt8</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_0wq4zbj</bpmn:outgoing>
    </bpmn:serviceTask>

This would work if the workflow has only one-to-one mappings and no task retries are defined.

However, it is quite common to use specific extension elements/properties for implementation details.

Best regards,
Philipp

3

Hi Philipp, thanks for the quick reply.

Yes, that’s what I meant. If zeebe:taskDefinition provides some usefull extension for convenience (like retries, which could be modelled in BPMN as well) then I can decide when and where to use them.

Even if I use multiple workers, it shouldn’t matter (from the diagram) if I use id or type to register. I guess there is some internal magic in zeebe that requires the type, but why force this onto the user.

Can you name an example use-case where the service-task id would not suffice.

4

Hi @lostiniceland, Philipp’s point is not about multiple workers, but rather multiple instances of the same task type in a process. Since a service-task id must be unique in a process diagram, you could not have the same worker type serving multiple service task instances in a process diagram.

For a naive example, if I wanted to insert a bunch of Print State tasks in my process diagram, I couldn’t have a single console-log worker service each of them (by giving each of them the console-log task type). I’d need to write a different worker for each, or at least register the same handler code for each one. Adding 10 inspection tasks in a process would not be trivial.

This is a naive example, but it demonstrates that you can’t have multiple instances of the same task type easily if you use a unique id to link a worker to a task, with a strict one-to-one mapping as you’d have if you used the service-task id.

5

Thanks for the clarrification @jwulf

I expected something this way. Anyways, I just wanted to provide some feedback.
Looking forward to a production-ready release.

6