DMN-Engine - Regression regarding "satisfies" expression in combination with "in"
nils-christian opened this issue · 9 comments
Hi,
We encountered a regression between Camunda 7.19.0 and 7.20.0 regarding the evaluation of an expression using "satisfies". Please take a look at the following example:
private static final class UnsupportedElProvider implements ElProvider {
@Override
public ElExpression createExpression( final String expression ) {
throw new UnsupportedOperationException( );
}
}
@Test
void test( ) {
final DmnEngine dmnEngine = new DefaultDmnEngineConfiguration( )
.elProvider( new UnsupportedElProvider( ) )
.buildEngine( );
final DmnDecision decision = dmnEngine.parseDecision( "rule", new ByteArrayInputStream( """
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns:dmndi="https://www.omg.org/spec/DMN/20191111/DMNDI/" xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/" xmlns:modeler="http://camunda.org/schema/modeler/1.0" id="Definitions_1l3308w" name="DRD" namespace="http://camunda.org/schema/1.0/dmn" exporter="Camunda Modeler" exporterVersion="5.9.0" modeler:executionPlatform="Camunda Platform" modeler:executionPlatformVersion="7.17.0">
<decision id="rule" name="rule">
<decisionTable id="DecisionTable_1me3usc" hitPolicy="FIRST">
<input id="InputClause_1t0w2cw">
<inputExpression id="LiteralExpression_0durxaq" typeRef="">
<text>A</text>
</inputExpression>
</input>
<output id="OutputClause_0spmo3u" name="output" typeRef="string">
<outputValues id="UnaryTests_117rzr5">
<text></text>
</outputValues>
</output>
<rule id="DecisionRule_0mqk1s7">
<description></description>
<inputEntry id="UnaryTests_1546eit">
<text>every k in ? satisfies k.B in ["42"]</text>
</inputEntry>
<outputEntry id="LiteralExpression_1hoo6ou">
<text>"Satisfied"</text>
</outputEntry>
</rule>
<rule id="DecisionRule_1ad8zlf">
<inputEntry id="UnaryTests_1c7l2qf">
<text>every k in ? satisfies not(k.B in ["42"])</text>
</inputEntry>
<outputEntry id="LiteralExpression_16dfbxp">
<text>"Not Satisfied"</text>
</outputEntry>
</rule>
</decisionTable>
</decision>
</definitions>
""".getBytes( StandardCharsets.UTF_8 ) ) );
final DmnDecisionResult decisionResultEntries = dmnEngine.evaluateDecision( decision, Map.of( "A", List.of( Map.of( "B", "42" ), Map.of( "B", "42" ) ) ) );
System.out.println( decisionResultEntries );
}The decision is evaluated to
Camunda 7.19.0: [{output=Value 'Satisfied' of type 'PrimitiveValueType[string]', isTransient=false}]
Camunda 7.20.0: [{output=Value 'Not Satisfied' of type 'PrimitiveValueType[string]', isTransient=false}]
Thank you and best regards
Nils
Hi,
In the meantime we realized that the same applies when we use
count(?[item.B in ["42"]]) = count(?)
as expression. With 7.19.0 this is evaluated as "true", with "7.20.0" as false. So it seems that there is something wrong with the in-expression in combination with a list loop.
As a workaround we identified the usage of "list contains" which seems to work as expected.
Best regards
Nils
Hi @nils-christian,
This problem seems to me like a FEEL Engine one.
It could also be possible that this has been fixed already in a newer release of the FEEL Engine.
Can you try to replace the FEEL Engine library version shipped with 7.20 with the latest version?
https://github.com/camunda/feel-scala/releases/tag/1.17.5
If the problem you are facing is still present in FEEL Engine version 1.17.5, please raise an issue here:
https://github.com/camunda/feel-scala/issues/new/choose
Best,
Tassilo
Hi @tasso94,
I cannot reproduce the issue with the plain FEEL engine. This is why I am asking you to investigate. The same expression is evaluated correctly when I use just the engine:
final FeelEngine feelEngine = new Builder( ).build( );
final Either<Failure, Object> evaledExpression = feelEngine.evalExpression( "every k in A satisfies k.B in [\"42\"]", Map.of( "A", List.of( Map.of( "B", "42" ), Map.of( "B", "42" ) ) ) );
assertThat( evaledExpression.contains( true ) ).isTrue( );
So I assume that the issue lies somehow in the DMN engine and not in the FEEL engine.
Best regards
Nils
Hi @nils-christian,
I reopened that issue.
Did you try to update to the latest version of the FEEL Engine? It may solve the problem. I will have a look myself soon.
We didn't change anything in the DMN Engine between 7.19 and 7.20.
Stay tuned!
Best,
Tassilo
Hi @tasso94,
I enforced the feel engine in Version 1.17.5 and I still encounter the same issue.
Best regards
Nils
Hi @tasso94,
After some experimenting it seems that there are multiple classes called "FeelEngine" in the classpath. Using the scala feel engine, I can reproduce the error:
package com.example.demo;
import org.camunda.bpm.dmn.feel.impl.FeelEngine;
import org.camunda.bpm.dmn.feel.impl.scala.ScalaFeelEngineFactory;
import org.camunda.bpm.engine.variable.context.VariableContext;
import org.camunda.bpm.engine.variable.impl.VariableMapImpl;
import java.util.List;
import java.util.Map;
public class Main {
public static void main(String[] args) {
final FeelEngine feelEngine = new ScalaFeelEngineFactory( ).createInstance();
final String expression = "every k in ? satisfies k.B in [\"42\"]";
final VariableContext variableContext = new VariableMapImpl( Map.of( "cellInput", List.of( Map.of( "B", "42" ), Map.of( "B", "42" ) )));
final Object result = feelEngine.evaluateSimpleExpression(expression , variableContext );
System.out.println( result );
}
}
Hi @tasso94,
I narrowed it down to a behaviour of the FEEL engine (camunda/feel-scala#807). I would ask you to leave this ticket open until we know whether this is something that has to be corrected in the FEEL engine wrapper in the DMN engine.
Thank you and best regards
Nils
Hi @nils-christian,
It's great that you figured it out.
Let's wait and see. I'll stay tuned 🙂 👍
Best,
Tassilo
Hi @nils-christian,
As outlined here camunda/feel-scala#807 (comment), the problem has been fixed with versions 1.17.5 and 1.16.3 of the FEEL Engine.
Please update to one of the recommended versions.
Camunda 7 will likely ship the FEEL Engine in version 1.17.5 with Camunda 7.21.0.
I'll close this issue accordingly.
Best,
Tassilo