Cannot find Error End Event in Zeebe Modeler

Hi

I cannot see how to create an Error End Event in Zeebe Modeler. I can see how to create the Error Catch Event, is the throw event supported by Zeebe Modeler?

I am trying to achieve something similar to this:

1 Like

You can only throw the event in code at the moment, from a client (for example: Node.js). In an upcoming-to-you-soon release, you will be able to model the throw in the BPMN.

3 Likes

How can we do “Cancel End Event”?

What I want to do is that if worker catches some error (business error), then workflow is canceled, no need to retry. Hopefully this is specified by the BPMN workflow instead of in the worker code.

Interrupting boundary error event leading to end event.

@jwulf Do you mean like this?

But it doesn’t make the instance Canceled, but Completed. I want it to be Canceled.

1 Like

Then Interrupting boundary error catch to a task where the worker cancels the job.

@jwulf is there API to cancel job from worker? I can only see:

  • complete.success()
  • complete.error()
  • complete.failure()
  • complete.forwarded()

I couldn’t a “cancel” API.

A workflow instance has the state “Canceled” (i.e. terminated) if it was canceled by a cancel (user) command. Or, if the instance was created by a call activity and the call activity was canceled.

Why do you want the workflow instance to have the state “Canceled” in Operate?
Did you consider any alternatives?

Best regards,
Philipp

If you are using the Node client, it is ZBClient.cancelWorkflowInstance().

Hmmm… would it make sense to make that available as complete.cancel()?

If you think so, feel free to open a feature request for the Node client.

@jwulf It seems that while this is already possible to do in the BPMN file and supported by Zeebe Broker (see https://github.com/zeebe-io/zeebe/issues/3176, https://github.com/zeebe-io/zeebe/pull/3244), however it is currently not possible to create this using Zeebe Modeler.

If it’s true, should I file request at Zeebe Modeler instead?

@philipp.ossler For example, when workflow was started with incorrect input, there are several ways to handle this:

  1. default error, means it will raise an incident, which user can then retry. Problem is, it will never succeed because the variable to create the workflow instance was wrong. So there’s no need to retry and no need to raise incident. So the better semantic in business perspective is to cancel the workflow instance altogether, automatically.
  2. regular End Event. It’s simplest by making an interrupting error boundary event that flows to end event. My problem with this is the workflow instance is now Completed, not Canceled.
  3. ZBClient.cancelWorkflowInstance() is a nice workaround, that cancels the instance. But the problem is that this isn’t visible in the workflow. Sometimes (or most times?) the responsibility to cancel an instance is determined by the workflow, not the worker.
  4. Cancel End Event. Supported by Camunda: docs.camunda .org/manual/7.4/reference/bpmn20/events/cancel-and-compensation-events/#cancel-end-event. I would hope that this is usable on a root workflow and also supported by Zeebe + Zeebe Modeler.
  5. Error End Event. Supported by Camunda: docs.camunda .org/manual/7.4/reference/bpmn20/events/error-events/#error-end-event, but not yet in Zeebe. I hope soon supported by Zeebe + Zeebe Modeler.

Hi @ceefour,

thank you for the insides.

Regarding the options

  1. From the BPMN side, a cancel end event can only be used in combination with an embedded transaction subprocess. So, it can not be used to cancel the workflow instance.
  2. The error end event is supported by Zeebe since 0.23.0-alpha1. And it will be available in the next version of the Zeebe modeler. However, the error end event can not be used to cancel a workflow instance. It can be used to throw an error event that is caught by an error catch event. If it is not caught then an incident is raised.

IMO, there is no clear way to cancel a workflow instance in BPMN. It is additional business information about the workflow instance. This information can be modeled by using a workflow instance variable (e.g. inputData = invalid).

In Operate, this variable can be used to filter the workflow instances.

Does this help you?

Best regards,
Philipp