Improve DMN modeling UX for Camunda Cloud

[saig0]

Is your feature request related to a problem? Please describe.

In Camunda Cloud 1.3.0 1.4.0, we will support evaluating DMN decisions in Zeebe. Since Zeebe will use a different DMN engine than Camunda Platform and doesn't support all features from the Platform, we should remove some properties to improve the modeling UX.

Describe the solution you'd like

In order to improve the DMN UX for Zeebe and the new DMN engine, we should adjust the following parts:

• decisions (in DRG view):
  • remove the property Version Tag - not supported by Zeebe
  • remove the property History Time to Live - not supported by Zeebe
  • remove the description of the Id property (similar to the Id property of processes) - in Zeebe the ID will be serialized as decisionId (in Zeebe, keys are the identifiers of the record entity)
  • tracked via Migrate properties panel to new architecture bpmn-io/dmn-js-properties-panel#29
• decision table:
  • remove the property to select the Expression Language on inputs (i.e. input expressions), input entries, and output entries - Zeebe supports only FEEL
  • remove the property Input Variable on inputs - in FEEL, the input value can be accessed by using ? if needed
  • remove the options integer + long + double in favor of a new option number on selecting the Type of inputs and outputs - in FEEL, there is only a number type (represented as BigDecimal)
  • add the options time + dateTime + dayTimeDuration + yearMonthDuration + Any on selecting the Type of inputs and outputs - in order to cover the most common types of FEEL
• literal expression:
  • remove the property to select the expression language - Zeebe supports only FEEL
  • remove the options integer + long + double in favor of a new option number on selecting the Variable Type - in FEEL, there is only a number type
  • add the options time + dateTime + dayTimeDuration + yearMonthDuration + Any on selecting the Variable Type of inputs and outputs - in order to cover the most common types of FEEL

Describe alternatives you've considered

No changes. It should be possible to deploy a DMN with the current modeler if no unsupported features are used. Otherwise, the deployment with the DMN is rejected.

Additional context

None.

[MaxTru]

Assigning to @barmac who will work on this conceptually (how will we ship this stripped-down dmn editor)

[barmac]

Thanks @saig0 for creating this issue. I am moving this currently to the backlog until we start working on it (which will happen later this quarter).

[saig0]

@barmac we should plan a few more adjustments to improve the UX:

Restricting the naming/usage of the decision ID

• currently, the decisionId must be a valid QName
• but in a DMN for Camunda Cloud, the decisionID may be referenced in a dependent decision (i.e. to access the decision result/output of a required decision)
• the FEEL engine has the limitation that a variable should not contain any special characters or symbols (e.g. whitespace, dashes, etc.), except the variable name is escaped
• if the decisionId has a special character (e.g. my-decision) and it is used in an input expression then the FEEL expression can't be parsed and the DMN is rejected by Zeebe
• it works for Camunda Platform 7 because their DMN engine uses the output names instead of the decisionId (but this behavior is not correct according to the DMN specs)
• we have the same issue for output name (i.e. the name of a decision table output) and variable name of decision literal expressions

Suggestion/idea:

• add a new validation for the decisionId (and the other properties) and limit the value to alphanumeric names

Avoiding differences of the decision ID and the output name

• a decision table can have one or more outputs and each output has an output name
• currently, the output name can be named independently from the decisionId
• but in a DMN for Camunda Cloud, the output name is not used if the decision table has only one output
• instead, the DMN engine uses the decisionId. It uses the output names only if the decision table has more than one output.
• if the output name is different from the decisionId and the output name is used in an input expression then the FEEL expression/the DMN decision may fail or return an unexpected result
• it works for Camunda Platform 7 because their DMN engine uses always the output name instead of the decisionId (but this behavior is not correct according to the DMN specs)

Suggestion/idea:

• the output name is not editable if the decision table has only one output

cc: @nikku

[nikku]

Makes a lot of sense @saig0.

@barmac please correct me on the following assessment:

Restricting the naming/usage of the decision ID

Straight forward to implement.

Differences of the decision ID and the output name

A little harder to implement; to be decided if we implement it (need to trade of with modeling UX) => Maybe handle via linting?

---

Avoiding differences of the decision ID and the output name

As I understand the engine will ignore the output name, right? @saig0.

So we could argue here that this is a case for linting (tell users their output name is going to be ignored for single output column tables).

[barmac]

I think we can change the ID validation pretty easily. However, I believe in this case linting is more suitable as the DMN is still valid but the engine cannot handle the ID (yet?). The same can be applied to the single output decision -> we should be able to model DMN as we want but get a warning if it's not supported by the engine.

[andreasgeier]

we should be able to model DMN as we want but get a warning if it's not supported by the engine.

That approach would follow the principles that we defined for validation and linting:

1. Direct validation only for entries that would break the diagram in the modeler. Behavior: we ignore the input, refuse to change the XML, and as result keep the previous (valid) state.
2. Everything else is part of the linting scope. No additional direct validation in the properties panel.

However, so far there is no DMN linting in place. So, doing things differently here is not preferred but is an option.

[barmac]

Hey @saig0, I created follow-up issues for your suggestions in #2525 (comment):

• Avoid difference of the decision ID and the output name #2836
• Restrict naming/usage of the decision ID #2835