Allow to specify every technical attribute as expression #3417
Comments
menski
added
kind/feature
Outcome of discussion:
|
|
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? |
|
@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. |
|
Fantastic. Thanks! |
|
Thank you for your interest! Here is an overview of the expressions you can write with FEEL:
|
|
Just an idea: Maybe it would be nice to register a worker to evaluate expressions. |
|
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. |
|
Closing this proposal issue. The state can be tracked via milestone: https://github.com/zeebe-io/zeebe/milestone/35 |
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.The text was updated successfully, but these errors were encountered: