Implementing DMN 1.6

Development
1

There is a new DMN Standard, 1.6, currently in beta: About the Decision Model and Notation Specification Version 1.6 beta

Currently we are still in the stabilization phase, but I think it would be sensible to talk about this already, because this is one of the reasons why we forked the engine in the first place - maintain it and keep it up to current standards.

I wanted to start this discussion with several questions and topics to discuss:

  1. When would be the appropriate time to tackle this? I think we should stick to our plan and not introduce new features before releasing our stable 1.0, do you agree? In this limits, I think standard-updates should have a high priority on the roadmap.
  2. How do we handle Tooling? We are currently depending on the Camunda Modeler for all modelling tasks. While it should be possible to introduce new bpmn.io versions into the web apps, which will then bring DMN 1.6 support, I doubt that Camunda will Patch DMN 1.6 support into the Camunda 7 DMN moddle libraries and the modeler. We need to either find a way to adapt this tooling ourselves, or create new tooling
  3. Cooperation with other tool vendors, especially OpenBPM should be initiated early on. We are still planning to roll our own web apps, but if we decided to implement new BPMN / DMN standards, we should do what is possibile for us to make sure that tooling in the ecosystem supports it, too.

Again, I donā€™t think it is reasonable to start development on this now, as our resources are better spent with the stabilization efforts, but I wanted to bring awareness to the upcoming standard update and the implications for ous

1 Like
2

Agreed, it is important to keep up with these essential standards. And yes, I do think it should be out of scope for 1.0. We should have feature parity with C7 7.24, not more.

For employing DMN 1.6 we need the proper resources to implement and especially to test them. Fortunately we have with @steven someone who could help testing that DMN features are working on a real-life usage.

For me, upgrading to that DMN level is something I could imagine for a version 1.1 or 1.2. Does someone now for when we could expect the final version of the standard? I would like to see a commitment for that on the roadmap. It would be a clear sign that Operaton is not staying where C7 ends, but really moves forward and has a vision for it.

1 Like
3

Iā€™d like to add a comment regarding FEEL engine support in the DMN engine.

Currently, the engine provides two different implementations for evaluating FEEL expressions:

  • FeelEngineImpl: A legacy engine that transforms FEEL unary tests into JUEL expressions and evaluates them using Jakarta EL. This approach is limited in portability and depends on Jakarta EE infrastructure.
  • ScalaFeelEngine: A modern engine that evaluates FEEL expressions directly using the external feel-scala project, with the goal of full DMN FEEL compliance.

I propose we deprecate and eventually remove the legacy FeelEngineImpl, as it is both outdated and not guaranteed to work across all environments.

If we do proceed with removing the legacy engine, we become fully reliant on the feel-scala project for FEEL support. In that case, we should ensure it aligns with DMN 1.6 going forward, and possibly contribute upstream to maintain compatibility.

4

Iā€™m not sure if removing FeelEngineImpl now is right: My gut feeling is to leave it for 1.0. But if we address it later I would be fine. Would we expect that clients are potentially affected, i.e. removal would be a breaking change?

1 Like
5

Agreed. I also wouldnā€™t make any changes for 1.0. In the medium to long term, however, Iā€™d like to move away from the effort of maintaining two FEEL engines.

Whether removing the FeelEngineImpl is a breaking change is a good question. If the Scala engine represents a superset of FEEL functionality compared to FeelEngineImpl, and if the same FEEL expressions consistently yield the same results, there shouldnā€™t be any issues from the perspective of DMN models. From a configuration standpoint, it is a breaking change, since the configuration parameter for selecting the FEEL engine implementation would be removed. But I donā€™t see that as a problem. The default is already the Scala engine, so the vast majority of users are already using it.

6

Just wanted to add a quick follow-up.

I had a look at the DMN TCK results (Decision Model and Notation TCK), and itā€™s pretty clear that the Scala engine performs better in terms of DMN support compared to Camunda Platform 7.21.0. For example, the Camunda DMN-Scala engine 1.9.0 passes 2,854 out of 3,349 tests, while Camunda Platform 7.21.0 only manages 2,745. Both report zero actual test failures.

I still need to dig deeper into what exactly is being tested and what that means for the Operaton project. Iā€™m not sure yet how the platform is configured for the tests or how the Scala engine is being tested separately.

Maybe we could also hook the DMN TCK tests into our CI? It would be a nice way to catch issues early, keep track of our compliance level, and even include the results in the documentation for transparency.

What do you think?

7

Anything that we could do to increase our level of confidence by CI builds is welcome. What would the requirements to enable DMN TCK tests? How much code is needed? Is it feasible to have the code in the main repo, or should those tests be a separate repo?
At least we would have a separate workflow to execute them.

8

@kthoms I played a bit around with the TCK. Hereā€™s a summary of the current implementation strategy:

The TCK (Test Compatibility Kit) integration in Operaton uses JUnit 5ā€™s dynamic test framework to programmatically discover and execute DMN compliance tests. A fresh DmnEngine instance is created for each individual DynamicTest to ensure test isolation, preventing a single DMN parsing failure from affecting the entire test suite.

The strategy works as follows:

  • It scans a specified classpath or file system directory for XML test case files.
  • It filters for tests that target compliance-level-2 and compliance-level-3.
  • Each XML file is parsed using JAXB to extract the TestCases metadata and individual test scenarios.
  • For each test file, a DynamicContainer is created, with nested DynamicTest instances representing individual test cases.
  • Each test initializes a new DmnEngine via configuration.buildEngine(), parses the DMN model, and executes assertions to validate the expected results.
  • Parsing errors in one model do not impact other tests, allowing robust execution across the entire suite.
  • Both file system and JAR-based resource loading are supported, so tests can run in development environments as well as packaged distributions.
  • The suite is constructed entirely at runtime based on discovered test files, rather than being statically defined.

To make things more flexible, I added configuration options:

  • Test execution can be enabled or disabled via a property.
  • The specific TCK test set (e.g., compliance levels, subsets) can be configured.
  • Thanks to this, tests can also be run locally, not just in a dedicated GitHub action workflow.

Sample Pseudocode:

@TestFactory
@EnabledIfSystemProperty(named = TEST_DMN_TCK_ENABLED, matches = "true")
Stream<DynamicContainer> testTckCases() {
  List<URL> xmlFiles = discoverXmlFiles();
  return xmlFiles.stream()
    .map(xml -> {
      TestCases testCases = parseXml(xml);
      return DynamicContainer.dynamicContainer(testCases.getModelName(),
        testCases.getTestCase().stream()
          .map(tc -> DynamicTest.dynamicTest(tc.getId(), () -> {
            DmnEngine engine = config.buildEngine();
            List<DmnDecision> decisions = engine.parseDecisions(loadDmn(tc));
            assertValid(tc, decisions);
          }))
      );
    });
}

Iā€™m still considering the best long-term strategy for running the TCK tests ā€” whether to integrate them fully into CI or keep them as an optional suite. Weā€™ll figure that out as we go.

1 Like
9

Thanks for the tests! Iā€˜m wondering if this is something for a collaboration with a university. There are many FEEL implementations, this would be a fine usecase for a language implementation in Truffle :thinking:

Undortunately nothing I can provide, I never had a strong theoretical background in compsci

Topics for student thesis
10

Great idea. Implementing at least a subset of FEEL on top of Truffle should definitely be possible, especially since the EBNF grammar is part of the DMN 1.6 specification. That provides a solid foundation to build a compliant parser and evaluator.

Iā€™ve also been thinking that beyond just implementation, it might be valuable to explore different FEEL/DMN engine strategies in terms of:

  • Performance (e.g., interpretation vs. compilation, memory use, throughput)
  • Maintainability (code complexity, modularity, testability)
  • Observability (debugging support, metrics, traceability for audit/compliance)

This could make for a great collaborative research or engineering topic.

11

Iā€™m trying to summon @koppor here. We already had a short call about Operaton and touched if there is a nice case for scientific collaboration, maybe ā€œFEEL implementation in Truffleā€ is exactly that?

12

FYI

I just created the following Backport PR

This has been released with Camunda 7.23.0 and will be part of beta-5.

Operaton then should support for the FEEL Scala Engine as an integrated script engine.

1 Like
13

The MR has been already merged. We are ready soon to release.