Support Error catch events without error code (catch-all Error events)

[koevskinikola]

Problem you would like to solve

With camunda/camunda#11126, Zeebe now supports Error catch events without an error code.

This enables users to model a specific response for a known escalation code, and a general response for unknown escalation codes.

Currently, Error catch events without error codes are not supported in the Modeler for Camunda 8 BPMN diagrams.

Proposed solution

• The Modeler allows the creation of Error catch all events without explicitly referencing a specific error, in two ways:
  • ErrorEventDefinition#errorRef is optional
  • Error#errorCode is optional (Support Error catch events without error code (catch-all Error events) #3362 (comment))
• There can only be one Error catch all event per scope
• Support for global errors is validated for Camunda 8.2

Alternatives considered

/

Additional context

In Zeebe, the feature will be available with version 8.2.0-alpha3.

[nikku]

@koevskinikola Thanks for opening the issue.

For clarity could you attach an example process that defines a global error?

[koevskinikola]

Hey @nikku, of course.

Here's a process where the two possible cases of a global error catch event are defined:

1. The Error Start event of the Event sub process references an Error where no errorCode is defined.
2. The Error Boundary event of the SubProcess doesn't define the errorRef attribute of the errorEventDefinition element.

Let me know if you need more details, or if there's a better way to attach a BPMN process on GitHub.

[nikku]

@koevskinikola You can attach by renaming to diagram.bpmn.txt.

Thanks for sharing the diagram. It is now clear to me that errorRef is optional, but also errorCode can be optional.

[nikku]

Updated the issue accordingly, please review @koevskinikola.

[koevskinikola]

Looks good @nikku, thanks!

[nikku]

Moving to ready to potentially pick up this alignment topic in the next iteration(s).

[philippfromme]

@koevskinikola Can you help me understand what is not allowed. I'm not entirely sure about how scopes work. A couple of examples:

Example 1

Example 2

Example 3

Example 4

[koevskinikola]

Hey @philippfromme,

From the examples you provided above:

• Example 1 - not allowed. Event sub-processes are on the same scope as the root (process instance) scope. So two event sub-processes with a catch-all Error start event shouldn't be allowed since we need only one of them to catch all of the "un-assigned" errors.
• Example 2 - allowed. The boundary catch-all Error event will catch all "un-assigned" errors in the scope of the sub-process Task (and any child scopes that it has). The catch-all Error start event will catch any "un-assigned" error events from the main process.
• Example 3 - not allowed. Similar to example 1, the catch-all Error boundary events are assigned to the same Task scope, so any "un-assigned" errors that bubble up from the Task scope, or any child scopes only need to be caught by one of these events, the second is unnecessary.
• Example 4 - allowed. The catch-all Error boundary events are assigned to different Task scopes. So each will catch "un-assigned" errors of the Task scope (and any child scopes) of the Task it borders on. So they aren't in conflict.

I can't think of any other use cases, so I think you managed to cover all of them. :)

Let me know if I can be of more help.

[koevskinikola]

@nikku @philippfromme I've been writing the Zeebe docs for this feature, and while going through our test coverage I realized I gave you the wrong answer here:

It is now clear to me that errorRef is optional, but also errorCode can be optional.

If we use our BPMN model API to model a catch-all error event, the XML output for a catch-all error event without an errorRef and without an errorCode will be the same, i.e. at the end an errorRef is not added. This is an example XML:

<boundaryEvent attachedToRef="task" id="error" name="error">
  <errorEventDefinition id="errorEventDefinition_bc91ed16-c948-4fc4-a201-fa7933fcb672"/>
</boundaryEvent>

From my understanding, for the Modeler this means that you don't need to make the errorCode optional.

[nikku]

From my understanding, for the Modeler this means that you don't need to make the errorCode optional.

This sounds like the more reasonable thing, if we don't have additional Zeebe specific things maintained on the error in the catch all case.

On the other hand, what happens if I deploy an error without an errorCode? Will it also have catch all semantics? We'd want to decide if we want to mirror the BPMN model API, or capabilities Zeebe has internally.

I'm always happy to go for the simpler solution.

[nikku]

CC @philippfromme.

Did you account for #3362 (comment)?

[CatalinaMoisuc]

@philippfromme @nikku if this is fixed upstream, maybe we can pull out the remaining stuff in a separate issue so it is clear this is closed from Modeler side in the Product Hub issue.

[philippfromme]

If we want to mirror the Zeebe engine behavior, we have to change the lint rules to always require an error code if an error reference exists but to not require an error reference. So we'd get rid of this error:

I'd say let's change it since the whole point of the linter is to ensure engine compatibility including quirks that might exist in the engine.

[philippfromme]

@nikku camunda/bpmnlint-plugin-camunda-compat#89 changes the rules to mirror Zeebe engine behavior. Can you have a look?