Error in Variable Resolution (juel)?

I think I found an bug in the resolution of variables in DMN expressions using juel: When calling the attached DMN we pass the following variables:

  • Long consumption = 3000
  • String billingType = “A”
  • Map privateBanking = hierarchical Map with the following logical structure:
    { “consumption”: { “rates”: { “minimum”: 0, “A”: 0.2, “B”: 0.5 }}}
  • Object func = class providing method min(int, int) which is a wrapper for Math.min(int, int)

I get the exception:

Exception in thread “Thread-1” org.camunda.bpm.dmn.engine.impl.DmnEvaluationException: DMN-01002 Unable to evaluate expression for language ‘juel’: ‘${func.min(2500, consumption) * privateBanking.consumption.rates.A}’
at org.camunda.bpm.dmn.engine.impl.DmnEngineLogger.unableToEvaluateExpression(

Caused by: javax.el.PropertyNotFoundException: Could not find property rates in class java.lang.Long
at javax.el.BeanELResolver.toBeanProperty(
at javax.el.BeanELResolver.getValue(
at javax.el.CompositeELResolver.getValue(
at de.odysseus.el.tree.impl.ast.AstProperty.eval(

Apparently, when resolving the expression privateBanking.consumption.rates.A , instead of the hierarchical map containing { “rates”: { “minimum”: 0, “A”: 0.2, “B”: 0.5 }, the Long from consumption is used. When I change the name of the Long variable from consumption to consumptionX in the DMN and the variables passed, everything works fine. So it seems that the coincidentally same names of the variable consumption and the key name consumption used in the Map privateBanking cause confusion in the look-up - although they’re used in different hierarchies inside the variables.

Version used: 7.6.0-alpha2

calculateFees.dmn (2.2 KB)

Hi @neuweiler,

thank you for reporting this bug. It seems that it’s related to JUEL and not the Camunda DMN engine. Maybe you can create a bug ticket in JUEL repository :wink:

BTW: this may work if you use the DMN engine in combination with the Camunda process engine. I test a similar expression in a script task and it works.

Best regards,

Hi @Philipp_Ossler,

Hmm… no commits in the JUEL repo for over 2.5 years and two hanging pull requests which are both older than 6 months. My guess is that nothing will happen anymore on that front.
We’d have to find out what’s different when you execute a rule from the process engine. Due to overhead it’s not the best option to wrap everything in a mini-process. Is it possible that by using the process engine not JUEL but a different script language is used?

The issue is critical for advanced usage of the engine. It means in all variables - no matter in which hierarchy - we could only use unique names. That’s not feasible in a project with hundreds of rules and parameters. It seems like the hierarchical maps are somehow flattened and one “consumption” entry overwrites the other in a flattened map.
But the conflicting expressions are once in a input expression and once in the output entry.

Maybe this helps: I found another symptom. If the input comes from a chained rule like we’re already discussing here and the input expression is like “func.evaluate(‘’, variableContext)” and in a output entry we want to refer to a variable named “”, the latter expression also crashes… The rule name (“” is somehow looked at as a variable name). If I switch the input expression from standard to JS, it works again. (BTW: The modeller writes expressionLanguage="Javascript" but the engine needs expressionLanguage="javascript" to work).

Hi @neuweiler,

maybe the easiest way is to use another script language (e.g. Groovy) instead of JUEL.

You can set the expression language for each expression, global for the decision definition or via configuration.

Regarding your question:

Yes, the process engine includes an own JUEL implementation which is based on JUEL 2.2.1. So if you evaluate a decision via Decision Service or Business Rule Task then the own implementation is used.[quote=“neuweiler, post:3, topic:1703”]
BTW: The modeller writes expressionLanguage=“Javascript” but the engine needs expressionLanguage=“javascript” to work

Can you please create an issue on Github for this.

Best regards,

This is a bug in Camunda DMN JUEL VariableContextElResolver.