Allow to specify every technical attribute as expression

[menski]

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

Most technical attributes, i.e. timer duration, task headers, called process id, are set as static value during the modeling phase. But often these values depend on runtime data provided to the process itself. It should be possible to set technical attributes using expressions.

Describe the solution you'd like

A technical attribute is per default an expression an evaluated based on the process variables. A constant value is a valid expression. i.e. strings can be quoted.

Describe alternatives you've considered

Having different attributes which distinguishes constants and expressions. This requires more input fields in the modeler and the user has to understand the differences while modeling.

Additional context

Camunda BPM allows to set expressions for the majority of attributes but uses JUEL with a specific syntax to mark an expression to distinguish it from constant values, i.e. ${myVariable}. It needs to be decided if we want to have expressions or constants as default.

[saig0]

Outcome of discussion:

• one input field in the modeler to avoid confusion
• supporting the user to write either a static value or an expression (e.g. toggle the input field between both)
• use two attributes in the XML: one for the static value and one for the expression
• using FEEL (the expression language of the DMN spec) as the expression language for Zeebe

[0x15e]

After reading some docs about FEEL, it looks like it's intended for decision-making expressions. Will there be features for, e.g., string concatenation, simple math, date math, etc. included? How fully-featured is the FEEL implementation you intend to use and are there additional docs I could read to learn more about it?

[falko]

@0x15e Yes, FEEL is part of the DMN Standard and – like JSONPath – it has been originally derived from XPath to work on object structures. One advantage over JSONPath is exactly that FEEL has a built-in function library and does not rely on any underlying scripting language for more complex expressions. Our implementation is 99.5% feature-complete as demonstrated through the DMN Technology Compatibility Kit.

[0x15e]

Fantastic. Thanks!

[saig0]

Thank you for your interest! Here is an overview of the expressions you can write with FEEL:
https://camunda.github.io/feel-scala/feel-expression.

• math expressions ✔️
• date/time/duration expressions ✔️
• string concatenation ✔️
• comparisons ✔️
• list operations: every, some, for, filter, projection ✔️
• and more using the built-in functions

[B-Stefan]

Just an idea:

Maybe it would be nice to register a worker to evaluate expressions.
The use case would be to support multiple expression-languages depending on customer needs.
For us, a some kind of Mongo like syntax could be interesting.

[saig0]

The idea with the worker is possible in addition to the builtin expression support. There is already a community project like this: https://github.com/zeebe-io/zeebe-script-worker

However, in Zeebe we also need some kind of expression support to do variable mappings or to define conditions on exclusive gateways. This kind of expressions should be evaluated inside the Zeebe broker itself to reduce the latency.
For now, we decided against a pluggable expression support to have more control over the expressions.

[saig0]

Closing this proposal issue. The state can be tracked via milestone: https://github.com/zeebe-io/zeebe/milestone/35