Learn IT with Shikha Blogs

 La Decision Model and Notation (DMN) est un standard permettant de modéliser et d’automatiser des règles métier de manière claire et maintenable. Les versions Camunda 7 et Camunda 8 , proposées par Camunda , prennent en charge DMN, mais avec des différences importantes au niveau de l’architecture, du moteur d’exécution et du langage d’expression. Cet article explique les différences essentielles entre DMN dans Camunda 7 et Camunda 8 afin d’aider les équipes techniques à mieux comprendre les impacts lors d’une migration. Cette architecture est couramment utilisée dans les environnements microservices modernes. 👉  environnements microservices modernes 🔹 1. Architecture et moteur d’exécution La différence la plus fondamentale concerne l’architecture : Camunda 7 repose sur un moteur Java monolithique, généralement intégré dans une application Spring Boot ou exécuté sur un serveur applicatif. Camunda 8 s’appuie sur le moteur Zeebe , conçu pour une exécution cloud-...

Decision Model and Notation (DMN) is a standards-based way to define, manage and automate business decisions that are part of your process automation solution. Both Camunda 7 and Camunda 8 support DMN, but there are important differences in how DMN is executed, modelled and integrated in the newer version. 🎯 1. Underlying Engine and Architecture One of the most fundamental differences between Camunda 7 and Camunda 8 — and therefore for DMN — is the engine architecture: Camunda 7 is built on the traditional Java-based process engine. Camunda 8 uses the Zeebe engine, designed for cloud-native, scalable execution of both BPMN and DMN models. This means that in Camunda 8, DMN execution is part of a distributed, horizontally scalable decision engine, whereas in Camunda 7 it runs in a monolithic embedded or server-based JVM. This foundational change influences performance and how decision models are deployed and scaled. 🧠 2. Expression Language Used in DMN A key technical differe...

 Dans DMN , les Hit Policies définissent comment une table de décision évalue les règles et quel résultat est retourné lorsqu’une ou plusieurs règles correspondent. Une mauvaise compréhension des Hit Policies est l’une des principales causes de décisions incorrectes en production , notamment avec Camunda DMN . Cet article explique : ce que sont les Hit Policies DMN les principales politiques ( FIRST, UNIQUE, ANY, COLLECT, PRIORITY ) des exemples métiers concrets les bonnes pratiques issues de projets réels Cette architecture est couramment utilisée dans les environnements microservices modernes. 👉  environnements microservices modernes 1️⃣ Qu’est-ce qu’une Hit Policy en DMN ? Une Hit Policy définit : combien de règles peuvent correspondre, comment le résultat final est calculé si plusieurs règles correspondent. Sans la bonne Hit Policy : la décision peut retourner un résultat inattendu , des conflits peuvent passer inaperçus, la logique métier peut être fausse en produc...

 In DMN , Hit Policies define how the decision table evaluates rules and returns results . Misunderstanding hit policies is one of the most common causes of wrong decision outcomes in production . This blog explains: What DMN Hit Policies are All major hit policies ( FIRST, UNIQUE, ANY, COLLECT, PRIORITY ) Real-world examples Best practices (with Camunda DMN usage in mind) 1️⃣ What Is a DMN Hit Policy? A Hit Policy defines: How many rules can match Which result is returned if multiple rules match Without the correct hit policy: Decisions may return unexpected values Rules may conflict silently Production logic may break 2️⃣ FIRST – First Matching Rule Wins 🔹 Behavior Rules are evaluated top to bottom The first matching rule is returned Other matching rules are ignored 🧩 Example: Discount Calculation Customer Type Discount Premium 20% Regular 10% If customer = Premium → 20% ✅ Use when : Rules are ordered by priority Only one result should be returned ❌ Risk : Wrong rule or...

 L’un des problèmes les plus fréquents avec Camunda DMN en environnement de production est l’ erreur d’évaluation booléenne , lorsque l’exécution d’une table de décision échoue parce qu’une condition ne retourne pas une valeur booléenne . Ce type d’erreur : N’apparaît souvent pas en développement Surgit après le déploiement en recette ou production Bloque totalement l’exécution du processus Dans cet article, nous allons analyser : Les causes racines réelles de cette erreur Pourquoi elle apparaît principalement en production Les solutions fiables utilisées en projet réel Cette architecture est couramment utilisée dans les environnements microservices modernes. 👉  environnements microservices modernes 🔴 Message d’erreur typique Vous pouvez rencontrer une erreur similaire à : Cannot evaluate expression: condition expression returns non - Boolean : result has class java.lang.String and not java.lang.Boolean ou : FEEL expression did not return...

 One of the most common Camunda DMN issues seen in production environments is the infamous Boolean evaluation error , where a decision table fails with a message indicating that a condition did not return a Boolean value . This problem often: Does not appear in development Surfaces suddenly after deployment Blocks process execution in production In this blog, we’ll cover: The exact root causes of this issue Why it appears unexpectedly in production Proven fixes used in real projects 🔴 Typical Error Message You may see an error similar to: Cannot evaluate expression: condition expression returns non - Boolean : result has class java.lang.String and not java.lang.Boolean or FEEL expression did not return a Boolean result This usually occurs when: A process reaches a DMN decision task A decision table condition is evaluated Camunda expects true or false , but receives something else 🧠 Root Cause Analysis (Most Important Section) ...