camunda / camunda-modeler

An integrated modeling solution for BPMN, DMN and Forms based on bpmn.io.
https://camunda.com/products/modeler
MIT License
1.5k stars 481 forks source link

BPMN Modeler: Introduce "Events" and "Gateways" tabs in error panel #4624

Open till-stadtler opened 17 hours ago

till-stadtler commented 17 hours ago

Problem you would like to solve

Event relation visibility on canvas: As a user, I want to have an overview of all (throwable) events that are configured in my BPMN process model and how they are related to one another. Throwable events are: messages, signals, links, errors and escalations. On large models, it is difficult to understand how the depicted events are related, e.g,. when there are multiple BPMN error events that can be thrown and caught. Labels can help, but currently, I have to click on all events, look at the property panel, and try to remember which event has which configuration, to understand the process flow.

Event visibility from worker code: As a user, I want to be able to add error and escalation configurations to service/send tasks to document that the underlying worker code is able to throw these events.

Event visibility from call activities: As a user, I want to be able to add error and escalation configurations to call activities to document that the referenced BPMN model is able to throw these events.

Gateway configuration visibility: (related to #4043) In #4043, I expressed my wish to be able to see the entire logic of a splitting XOR/OR gateway in a single view. I restate the same wish here, as I propose related solutions for all problems in this feature request.

Proposed solution

I propose to add an "Events" and a "Gateways" tab in the error panel of the BPMN Modeler. Visually, this fits well with the current functionality, given the existing "Variables" tab. The UI of these new tabs can share various aspects with the "Variables" tab, only the right-hand side can differ to show event- or gateway-related information.

"Events" tab Soft prerequisite: ability to document error/escalation configurations on service/send tasks and call activities, also message configurations on service/send tasks (potentially, there are even more elements).

All elements that either throw or catch an event (message, signal, link, error, escalation) are listed in the "Elements" view. This includes receive tasks, connectors (analyzing the "error expression"), and also service/send tasks with job worker implementation, and call activities.

When an element is selected, the right-hand side shows a list of events that are related to the element with the following information:

When selecting one of the events, all origins and catching elements are highlighted in two different colors on the canvas (plus the selected element being highlighted as well).

"Gateways" tab All splitting XOR/OR gateways are listed in the "Elements" view.

When an element is selected, the right-hand side shows an overview of the gateway configuration. It starts with a section about the gateway itself, mentioning its type, label, and number of outgoing sequence flows. After that, a list of information about the outgoing sequence flows follow:

When selecting one of the outgoing sequence flows, it is highlighted on the canvas. Optionally, the gateway and target can also be highlighted in a different color.

Alternatives considered

"Events" tab There might be an option to use the property panel for a similar solution. E.g., when the name input element is active, all related events on the canvas are highlighted. But this is not that compatible with the "error expression" for connectors which potentially throw multiple error events.

"Gateways" tab An overlay might be used as discussed in #4043, but this would introduce new UI elements, and would require more implementation effort.

Additional context

Related ticket on gateway visibility: #4043

Both new tabs could also include warnings from the problems tab, e.g., an event or sequence flow missing required configuration.

till-stadtler commented 15 hours ago

Listing the outgoing sequence flows by their order in the XML also solves a current issue: for XOR gateways, the conditions on the outgoing sequence flows are evaluated one-by-one following the order in the XML. The first path that evaluates to true is taken.

In the current modeler, it is not possible to inspect the order of the outgoing sequence flows in the XML. This can lead to unexpected behavior with the order of the XML not "conforming" with the order on the canvas.