Erreur booléenne DMN Camunda en production – Cause racine et solution

 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

---

🔴 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 a Boolean result

Cette erreur se produit généralement lorsque :

• Le processus atteint une tâche de décision DMN

• Une condition de la table de décision est évaluée

• Camunda attend true ou false, mais reçoit un autre type

---

🧠 Analyse des causes (partie la plus importante)

1️⃣ Utilisation de "true" / "false" comme chaînes de caractères

C’est la cause numéro 1.

❌ Condition DMN incorrecte :

= "true"

ou :

= "false"

Ici, Camunda interprète la valeur comme une String, et non comme un booléen.

✔ Condition correcte :

= true

ou simplement :

true

📌 Une condition DMN doit toujours retourner un booléen.

---

2️⃣ Incohérence de type de la variable d’entrée

Très fréquent en production :

• La DMN attend un Boolean

• Mais la variable du processus est en réalité :

  • Une String

  • Provenant d’un appel REST ou d’un formulaire

Exemple :

{
  "approved": "true"
}

Même si la valeur semble correcte, il s’agit d’une chaîne de caractères, pas d’un booléen.

---

3️⃣ Appels REST ou formulaires transformant les booléens en chaînes

Ce problème apparaît souvent lorsque :

• Le processus est démarré via API REST

• Les formulaires renvoient des valeurs texte

• Un système externe envoie "true" / "false"

Camunda ne convertit pas automatiquement les chaînes en booléens.

---

4️⃣ Expression FEEL retournant une valeur non booléenne

Exemple problématique :

approved = "true"

Cette expression compare des chaînes et ne retourne pas un booléen valide pour DMN.

Expression correcte :

approved = true

---

✅ Comment corriger le problème (solutions sûres en production)

✔ Solution 1 : Corriger les conditions DMN (solution idéale)

• Supprimer les guillemets autour des booléens

• Vérifier que chaque condition retourne true ou false

Exemples corrects :

approved = true
amount > 1000
not(isValid)

---

✔ Solution 2 : Forcer le type booléen au niveau du processus

Avant l’appel DMN, convertir explicitement la variable.

Exemple (tâche de service Java) :

execution.setVariable(
  "approved",
  Boolean.parseBoolean(
    execution.getVariable("approved").toString()
  )
);

Cela garantit que la DMN reçoit un Boolean, et non une String.

---

✔ Solution 3 : Valider les variables avant l’exécution DMN

Ajouter une étape de validation :

• Tâche de script

• Tâche de service

Vérifier :

• L’existence de la variable

• Son type réel

👉 Échouer proprement avant la DMN plutôt que casser le flux en production.

---

✔ Solution 4 : Corriger les payloads REST

Lors du démarrage du processus via REST :

❌ Incorrect :

"approved": { "value": "true" }

✔ Correct :

"approved": { "value": true }

---

⚠️ Erreurs fréquentes à éviter

❌ Utiliser "true" / "false" dans DMN
❌ Supposer que Camunda convertit automatiquement les types
❌ Ne pas valider les variables d’entrée
❌ Tester uniquement via Tasklist et pas via API REST

---

🏗️ Bonnes pratiques en environnement de production

• Définir clairement les types de variables

• Garder les règles DMN simples et explicites

• Valider les données avant l’appel DMN

• Aligner :

  • Payload REST

  • Variables de processus

  • Types d’entrée DMN

• Tester avec des données proches de la production

---

🎯 Pourquoi ce problème apparaît surtout en production

En développement :

• Les variables proviennent souvent de formulaires contrôlés

• Les types sont maîtrisés

En production :

• Appels REST

• Systèmes externes

• Multiples intégrations

➡️ Les incohérences de type deviennent inévitables si elles ne sont pas gérées explicitement.

---

📌 Conclusion

Les erreurs booléennes DMN dans Camunda ne sont pas des bugs du moteur.
Elles sont presque toujours dues à :

• Des mauvaises conditions DMN

• Des incohérences de types de variables

Une fois que vous imposez :

• Des booléens réels

• Des expressions FEEL correctes

• Une validation en amont

👉 Ces erreurs disparaissent complètement.

---

💼 Support professionnel disponible

Si cette erreur DMN bloque vos workflows en production ou retarde vos livraisons,
je propose des services de conseil, support projet et formations ciblées autour de Camunda BPM, DMN et de l’automatisation des processus d’entreprise.

📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com

🌐 Website: IT Trainings | Digital metal podium