Would you be so kind to provide me with an example about how to configure an error boundary event for a receive task? I have a situation where my Zeebe workflow waits for an information about some process-relevant current account data from an external system (request for this data is handled by a Zeebe client and triggered during a preceding service / send task). This information is needed to route process to an appropriate path (including or not re-activation of an account depending on its status). The receive task here is used to emphasize asynchronous nature of the data retrieval process and avoid a situation when an overloaded target system would need some time to respond.
My understanding of a receive tasks’ advantage over message events is that I can handle any abnormal situation, for example when given current account data is unavailable (following your documentation: ‘An alternative to intermediate message catch events is a receive task, which behaves the same but can be used together with boundary events.’). Unfortunately, I have no idea how to trigger an appropriate error event when there is some permanent problem with this data (e.g. current account ID is wrong) since there is no corresponding job which I can use to correlate the error thrown via gRPC. My idea is that any ThrowError message needs ‘jobKey’ ID to be properly correlated to a workflow instance.
I can think of a workaround using publishing message with a data request status (instead of triggering an error) and storing it as a process variable to use in nexst step / gateway to trigger an appropriate error, but I think would unnecessary bloat my model. I am using a self-managed Camunda Platform 8.1 along with desktop Camunda Modeler 5.5.0. I would be very grateful for any hints regarding the aforementioned situation.
I see the problem and I like the approach in general. The problem is that:
A error boundary event can only be triggered by something happening inside a task. Inside a receive task, there is no direct implementation.
I would suggest 2 workarounds:
Use only a service task for the communication. This service task might have a error boundary event attached. As a service task is executed by a jobWorker, the actual “blocking” of the response delay depends on the actual implementation. If the response delay is too much (and the job times out), you could consider setting a variable to the task after submitting the request for the first time which declares something like a transaction code. If the job is then re-executed, the next job worker would find this transaction code. This prevents multiple execution of the same job.
Use a message boundary event instead. I know, this has some implication on the modeling means, however you would then be able to react on an incoming error message.
Honestly, I like the idea of using an interrupting message boundary event better since it fits my idea of process representation and increases transparency. Still, do you think that the behavior described above (i.e. attaching an error boundary event to a receive task) may be implemented in the future releases of the Camunda Platform?
Idea: Similar to Camunda 7, there could be an expression on the error event that is evaluated on task complete. If this expression evaluates to true, the bpmn error is thrown instead.
You can also mention me in the ticket, so I can follow it. (github user: jonathanlukas)
