Problème de rollback de transaction dans Camunda 7 – Explication complète

Dans Camunda 7, l’exécution des processus est gérée à l’intérieur de transactions.

Un problème fréquent et déroutant en production est le suivant :

❌ Le processus revient en arrière (rollback), les tâches ne sont pas validées, les variables disparaissent et aucun message d’erreur clair n’apparaît dans Cockpit.

Cet article explique ce qu’est un rollback de transaction, pourquoi il se produit, comment identifier la vraie cause, et comment l’éviter.

---

1️⃣ Qu’est-ce qu’un rollback de transaction dans Camunda 7 ?

Camunda exécute chaque étape BPMN dans une transaction base de données.

Si une exception survient, alors :

• la transaction est annulée (rollback),

• la tâche complétée est annulée,

• les variables ne sont pas sauvegardées,

• l’exécution revient à l’état précédent.

➡️ C’est un comportement normal, mais souvent mal compris.

---

2️⃣ Symptômes typiques d’un rollback

Vous pouvez observer :

• une tâche complétée qui réapparaît,

• un processus qui n’avance pas,

• des variables absentes après soumission,

• des retries qui diminuent,

• un incident sans message clair,

• aucune donnée enregistrée en base.

---

3️⃣ Causes les plus courantes

🔴 Cause 1 : Exception dans un Java Delegate ou Listener

Toute exception non contrôlée provoque un rollback.

throw new RuntimeException("Erreur technique");

✅ Bonne pratique : utiliser BpmnError pour les erreurs métier

throw new BpmnError("ERREUR_METIER");

---

🔴 Cause 2 : Violation de contraintes en base de données

Exemples :

• violation NOT NULL,

• contrainte UNIQUE,

• clé étrangère invalide.

Ces erreurs déclenchent un rollback sans toujours apparaître clairement dans Cockpit.

✅ Solution :

• vérifier les logs applicatifs et DB,

• valider les données avant persistance.

---

🔴 Cause 3 : Appel à un système externe dans la transaction

Appeler une API REST, un service externe ou écrire un fichier dans la transaction Camunda est risqué.

Si l’appel échoue :

• Camunda annule toute la transaction,

• le système externe peut déjà avoir été modifié.

✅ Solution :

• utiliser asyncBefore / asyncAfter,

• externaliser la logique lourde,

• utiliser des workers externes.

---

🔴 Cause 4 : Mauvaise utilisation des frontières asynchrones

Sans frontière async, tout s’exécute dans une seule transaction.

❌ Risque :

Service Task → MAJ DB → Appel REST → Étape suivante

Si l’appel REST échoue → rollback global.

✅ Solution :
Ajouter une frontière asynchrone :

asyncBefore = true

---

🔴 Cause 5 : Boucle de rollback liée au Job Executor

Lorsqu’un job échoue :

• la transaction est annulée,

• les retries diminuent,

• après retries = 0 → incident.

Sans correction de la cause, le rollback se répète.

---

🔴 Cause 6 : Timeout de transaction

Un traitement trop long peut dépasser le timeout transactionnel.

Symptômes :

• rollback silencieux,

• aucun message explicite dans Cockpit.

✅ Solution :

• réduire la durée des transactions,

• découper le process avec des étapes async,

• ajuster les timeouts si nécessaire.

---

🔴 Cause 7 : Mauvaise configuration Spring Transaction

Dans les projets Spring Boot :

• propagation incorrecte (REQUIRED, REQUIRES_NEW),

• transactions imbriquées mal gérées,

peuvent entraîner des rollbacks inattendus.

✅ Solution :

• revoir l’utilisation de @Transactional,

• éviter de mélanger transactions Spring et Camunda sans contrôle.

---

4️⃣ Comment identifier la vraie cause

✔ Activer les logs DEBUG :

org.camunda.bpm.engine
org.springframework.transaction

✔ Corréler les logs avec l’horodatage
✔ Vérifier retries et incidents dans Cockpit
✔ Examiner les logs base de données
✔ Auditer le code personnalisé

---

5️⃣ Requêtes SQL utiles

SELECT * FROM ACT_RU_JOB WHERE RETRIES_ < 3;

SELECT * FROM ACT_RU_INCIDENT;

Ces requêtes permettent d’identifier les jobs à l’origine des rollbacks.

---

6️⃣ Bonnes pratiques pour éviter les rollbacks

✅ Garder des transactions courtes
✅ Utiliser BpmnError pour la logique métier
✅ Ajouter asyncBefore avant les appels externes
✅ Éviter la logique lourde dans les delegates
✅ Surveiller les retries et incidents
✅ Logger les stack traces complètes

---

7️⃣ Besoin d’un accompagnement expert?

Si :

• les rollbacks surviennent uniquement en production,

• aucun message d’erreur n’est visible,

• le comportement devient instable sous charge,

un accompagnement professionnel est recommandé.

---

💼 Support professionnel disponible

Si vous rencontrez des problèmes de rollback de transaction, de défaillances silencieuses ou d’instabilité des processus dans Camunda 7, je propose des services de conseil payants, débogage en production, support projet et formations ciblées.

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

🌐 Website: IT Trainings | Digital lectern | Digital rostrum | Digital metal podium