Stratégie de nettoyage de l’historique Camunda 7 – Garder la production rapide et stable

 Introduction

Dans les systèmes en production utilisant Camunda 7, l’un des problèmes de performance les plus fréquents mais souvent ignorés est la croissance incontrôlée des données d’historique.

Symptômes courants

  • Cockpit et Tasklist de plus en plus lents

  • Charge CPU base de données en hausse continue

  • Requêtes sur les tables ACT_HI_* très lentes

  • Incidents production après quelques mois de mise en service

👉 Dans 90 % des cas, la cause est la même : absence de stratégie de nettoyage de l’historique.

Ce blog explique :

  • Le fonctionnement de l’historique dans Camunda 7

  • Pourquoi le nettoyage est indispensable

  • Les stratégies disponibles

  • La configuration pas à pas

  • Les bonnes pratiques terrain

Fonctionnement des données d’historique dans Camunda 7

Camunda 7 stocke les données d’exécution et d’audit dans des tables relationnelles.

Tables principales d’historique

  • ACT_HI_PROCINST – Instances de processus

  • ACT_HI_ACTINST – Activités exécutées

  • ACT_HI_TASKINST – Tâches humaines

  • ACT_HI_VARINST – Variables

  • ACT_HI_DETAIL – Historique des mises à jour

👉 Chaque instance terminée ajoute des lignes dans ces tables.

🔷 Cycle de vie de l’historique Camunda 7 (diagramme conceptuel)

Exécution du processus
        ↓
Écriture de l’historique
        ↓
Rétention des données
        ↓
Nettoyage (cleanup)
        ↓
Réduction des tables

Sans nettoyage, la dernière étape n’existe jamais.

Pourquoi le nettoyage de l’historique est critique

Sans nettoyage

❌ Croissance infinie des tables
❌ Index inefficaces
❌ Sauvegardes DB très longues
❌ UI Camunda lente
❌ Dégradation progressive des performances

👉 Le history cleanup n’est pas optionnel en production.

Stratégies de nettoyage disponibles dans Camunda 7

Camunda 7 fournit un mécanisme intégré de nettoyage de l’historique, configurable de plusieurs façons.

Option 1 : Nettoyage basé sur le TTL (recommandé)

Principe

  • Définir un TTL (Time-To-Live) pour :

    • Processus

    • Cas (CMMN)

    • Décisions (DMN)

  • Camunda supprime automatiquement l’historique plus ancien que le TTL

Exemple

TTL = 30 jours

👉 Toute donnée historique de plus de 30 jours devient éligible au nettoyage.

Où configurer le TTL

1️⃣ Dans le modèle BPMN (meilleure pratique)

Dans la définition du processus :

History Time To Live : 30

✔ Précis
✔ Adapté par processus
✔ Compatible versioning

2️⃣ TTL global (moins recommandé)

Dans camunda.cfg.xml :

<property name="historyTimeToLive">30</property>

⚠️ S’applique à tous les processus
⚠️ Moins flexible

Option 2 : Job de nettoyage automatique

Le nettoyage est exécuté via un job interne Camunda.

Fonctionnement

  • Job planifié

  • Suppression par lots (batch)

  • Transactions courtes

  • Évite les verrous DB longs

🔷 Exécution du job de nettoyage – Diagramme

Planificateur
     ↓
Job Cleanup
     ↓
Suppression par batch
     ↓
Commit
     ↓
Répétition

Configuration du nettoyage de l’historique

Activer le nettoyage (Camunda ≥ 7.4)

<property name="historyCleanupEnabled">true</property>

Définir la fenêtre de nettoyage (très important)

<property name="historyCleanupBatchWindowStartTime">01:00</property>
<property name="historyCleanupBatchWindowEndTime">05:00</property>

✔ Exécuter la nuit
✔ Éviter les heures de pointe

Taille des batchs

<property name="historyCleanupBatchSize">500</property>

  • Petit batch → charge DB faible

  • Grand batch → nettoyage plus rapide

👉 À ajuster selon la base de données.

Option 3 : Nettoyage manuel ou par script (avancé)

Utilisé pour :

  • Migration d’anciens systèmes

  • Purge exceptionnelle

  • Nettoyage d’urgence

⚠️ Risque élevé
⚠️ À réserver aux DBA expérimentés

Erreurs fréquentes en production 🚨

❌ Aucun TTL défini
❌ TTL défini mais job désactivé
❌ Nettoyage pendant les heures de pointe
❌ Batch trop volumineux
❌ Suppression manuelle directe en base
❌ Absence d’index sur les tables d’historique

Bonnes pratiques de performance

✔ Définir un TTL par processus
✔ Rétention typique : 30 à 90 jours
✔ Activer le cleanup dès le premier jour
✔ Planifier le nettoyage la nuit
✔ Surveiller la durée du job
✔ Indexer :

  • END_TIME_

  • PROC_DEF_KEY_

  • REMOVAL_TIME_
    ✔ Coupler nettoyage + archivage si nécessaire

Supervision du nettoyage

À surveiller

  • Durée du job de cleanup

  • Nombre de lignes supprimées

  • Charge DB pendant le nettoyage

  • Croissance des tables ACT_HI_*

Question d’entretien fréquente

Q : Que se passe-t-il si le nettoyage de l’historique n’est pas activé ?
R : Les tables d’historique grossissent indéfiniment, entraînant une dégradation progressive des performances de la base et de Camunda.

Recommandation terrain

EnvironnementTTL recommandé
Développement7–14 jours
Test / QA30 jours
Production60–90 jours (selon le métier)

Conclusion

Une stratégie de nettoyage de l’historique est indispensable pour toute plateforme Camunda 7 en production.

À retenir :

  • Les données d’historique croissent rapidement

  • Le nettoyage doit être planifié dès le départ

  • Le TTL + job planifié est la solution la plus sûre

  • Ignorer le cleanup mène inévitablement à des problèmes de performance

👉 Si Camunda devient lent après quelques mois, le nettoyage de l’historique est presque toujours la cause.

💼 Support professionnel disponible

Si vous rencontrez des problèmes sur des projets réels liés au développement backend d’entreprise ou à l’automatisation des workflows, je propose des services de conseil payants, de débogage en production, de support projet et de formations ciblées.

Les technologies couvertes incluent Java, Spring Boot, PL/SQL, Azure, ainsi que l’automatisation des workflows (jBPM, Camunda BPM, RHPAM), DMN/Drools.

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

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

Comments

Post a Comment

Popular posts from this blog

jBPM Installation Guide: Step by Step Setup

  jBPM Installation Guide – Step by Step for Beginners If you are starting with jBPM (Java Business Process Management) , the first step is to set up your environment. In this guide, we’ll walk through how to install jBPM, configure it, and run your first business process. 🔎 What is jBPM? Before we dive into installation, a quick recap: jBPM is an open-source Business Process Management (BPM) suite , written in Java, that allows you to model, execute, and monitor workflows using BPMN 2.0 standards. It can run standalone , embedded in applications , or deployed on a Java EE server . 🖥️ Prerequisites Before installing jBPM, make sure you have: Java JDK 11 or later (Java 17 is commonly used) Maven 3.x (for building and managing dependencies) Git (optional, if you want to clone sample projects) A Database (H2, MySQL, PostgreSQL, or Oracle) – jBPM ships with H2 for testing At least 4GB RAM (8GB recommended for Workbench & KIE Server) 📦 Download ...
Read more

Scopes of Signal in jBPM

Image
💡 Introduction Signals in jBPM 7 are a core part of event-driven workflow design. They allow asynchronous communication between process instances, making it possible to start , interrupt , or coordinate processes without direct linking. However, signals can have different scopes , which define how far the signal travels and who receives it . Let’s explore the four available scopes in detail: 🔹 Process Scope 🔹 Default Scope 🔹 External Scope 🔹 Project Instance Scope 🧩 1️⃣ Process Scope 📘 Definition Process scope signals are local to a single process instance or its child subprocesses . They are not visible outside that instance hierarchy. 📋 Use Case Used for communication inside the same process , like triggering subprocesses or event sub-processes. 🖼️ Process Scope Example Below is an example of a simple process-scoped signal. Only this process (or its subprocess) will catch this signal. ⚙️ 2️⃣ Default Scope 📘 Definition The default scope ...
Read more

OOPs Concepts in Java | English | Object Oriented Programming Explained

Image
🔹OOPS (Object Oriented Programming System) in Java Object-Oriented Programming (OOPS) is a programming paradigm that uses classes and objects to design software. It simplifies development and maintenance by applying key concepts: 📌 Class: Class   is a user-defined data type which defines its properties and its functions. Class is the only logical representation of the data. For example, Human beings in an organisation is a class like Employee. The age, name, department, salary etc. of a human being/employee are its properties, and the jobs performed by the employees in an organisation are known as functions.  The class does not occupy any memory space till the time an object is instantiated. A class is a user-defined data type that defines properties and functions. For example: Class: Employee Properties: name, age, salary Functions: work(), attendMeeting() A class does not occupy memory until an object is created. ...
Read more