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).
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.
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.