User defined functions do not execute

[Hamilton-dfp]

Describe the bug

To Reproduce I get this error if I run on the playground and on my local implementation.

Perhaps its user error? Please let me know if so.

Expected behavior Engine should find function cool in the context and return the value 3.

Environment

• "org.camunda.feel:feel-engine:1.15.2"

• Playground

• Affects:

  • Camunda Automation Platform 7: [7.x]
  • Zeebe broker: [0.x]

[saig0]

@Hamilton-dfp thank you for raising this up.

User-defined functions can be invoked. But it is not possible to pass them as a variable.

Possible use cases:

• in DMN: define a function in a required decision literal expression and invoke the function in the dependent decision
• in BPMN: define a function in a context and invoke the function within this context
• embedded FEEL engine: pass the function via custom context or function provider SPI

Please see the following example:

Does this make sense to you? Do you have a concrete use case?

[Hamilton-dfp]

@saig0, thank you for the response, and the instructions on how to provide a user defined function.

My use case is as below:

I process FEEL expressions for my users. I am not processing within the context of BPMN or DMN. FEEL was chosen because of the features defined in 10.1 of the DMN 1.3 specification (namely, that it's a "Simple syntax designed for a wide audience"). My users have identified a calculation that they perform multiple times and want to define a function that would make these calculations easier. They want me to support this as a "built in" function.

If a function could be defined in a context, then I could have a pre-defined context with all built in functions that I can pass in to each evaluation of an expression along with the pre defined variables I am providing.

What you provided above gives me a work around. However, where the expression/context separation provided a clear delineation on what the user provided and what the system provided, now I need to wrap the user provided expression within a custom context to pass into the engine, and then pull the result back out before sending it to the user. It works, but it seems to defeat the purpose of the context?

[saig0]

My users have identified a calculation that they perform multiple times and want to define a function that would make these calculations easier. They want me to support this as a "built in" function.

This sounds like a good fit for the function provider SPI: https://camunda.github.io/feel-scala/docs/reference/developer-guide/function-provider-spi

Alternatively, you could use the custom context API and provide the function by the custom context.

Both are valid options to ship a custom built-in function.

[Hamilton-dfp]

I like the power of the function provider spi if I needed to enable a feature that could not be performed in FEEL. However, I worry by opening that door I might have a hard time ensuring the functions that are written by engineers are true FEEL compatible functions.

I will look into the Custom Context with the intent that any functions written in it MUST be written using FEEL expressions so I can ensure we are maintaining compatibility.

Thanks!

[saig0]

Thank you for sharing these insides. 👍