First, it’s about how to model the process and user’s interacting with it. This is a design decision. If the user is a process participant, who is part of the company executing the process - I’d prefer the user task. It clearly shows the responsibilities.
If your user is an external party, e.g., a customer, I’d choose a message.
The implementation also depends on the Camunda Version you’re using. In the enterprise version, you can also access the Tasklist API to complete your user tasks.
A fourth alternative (if you’re using self-managed Camunda 8) is a custom exporter that stores and maintains your user task IDs.
The Fill Form task is the culprit momentarily.
It feels not right to complete the task in a Java method by just completing(zeebeClient.newCompleteCommand()) it.
From my point of view, in that case the API takes over control and overrules the Camunda process while with the message the process control stays on Camunda side.
Camunda should always be in control and only influenced by messages. Am I wrong here?
This point confuses me since days
The zeebe client only sends messages. However, these messages are on a technical abstraction layer, while BPMN messages are on a conceptual level. The Zeebe client remains in full-control, as messages can be rejected/ignored. So using this functionality is fine.
It’s also completely fine to, e.g., write your own exporter to implement your custom tasklist-API. This is how Camunda 8’s own components are implemented. An exporter, however, should be as lightweight as possible and site effects must not affect the engine.