Camunda 8.8 marque une étape décisive avec son Orchestration Cluster unifié et la consolidation des APIs vers un modèle REST V2 moderne. Cette migration mineure nécessite pourtant une préparation rigoureuse pour éviter les pièges classiques. Guide pratique basé sur les release notes officielles et retours d’expérience.
Les 4 transformations majeures de 8.8
Composant |
Changement 8.8 |
Impact technique |
|---|---|---|
Orchestration Cluster
|
Architecture unifiée Zeebe + Operate + Tasklist + Identity
|
Simplification K8s/Helm, reconfiguration exporter + OpenSearch obligatoire
|
APIs REST V2
|
Endpoints consolidés, dépréciation progressive V1 (Tasklist/Operate)
|
Refactoring clients Java/JS/REST avant 8.10
|
Camunda User Tasks
|
Migration job-based → engine-managed avec Tasklist V2
|
Meilleure visibilité Operate, permissions Identity natives
|
Agentic Orchestration
|
Connecteurs IA (agents, vector DB) pour ad-hoc subprocess
|
Nouveaux patterns BPMN dynamiques et non-déterministes
|
Checklist préparation technique
1. Infrastructure & Déploiement
- Dernier patch 8.7.x avant upgrade (un minor à la fois)
- Backup complet DB Zeebe + OpenSearch/Elasticsearch
- Helm charts Orchestration Cluster (profil production)
- Configuration exporter interne (remplace ancien exporter)
2. APIs & Intégrations Clients
- Inventaire V1 : Lister tous appels Zeebe gRPC / Operate REST V1 / Tasklist V1
- Migration V2 : Adapter pagination, structures réponses, auth OAuth2 cluster
- SDKs : Java Client 8.8+, JS SDK avec nouveaux types UserTask
3. Modélisation BPMN à valider
- Priorité haute : • Multi-instance tâches/sous-processus (collections, terminaison)
- Boundary events concurrents (timer/error/message)
- Ad-hoc subprocess avec completionCondition FEEL
- Camunda User Tasks vs job-based (cycle complet, migration instances)
Plan d'upgrade en 5 phases
Phase 1 : Préparation (J-7)
- Analyse dépendances APIs V1/V2
- Environnements staging avec Orchestration Cluster
- Scripts backup/restore DB + snapshots Helm [web:61]
Phase 2 : Tests non-régression
- Processus happy paths + erreurs métier/techniques
- Zeebe Process Test / Camunda Process Test automatisés
- Charge : 1000+ instances parallèles
Phase 3 : Bascule plateforme
- Helm upgrade Orchestration Cluster
- Monitoring exporter + OpenSearch index rebuild
- Vérification instances actives Operate (no « not found »)
Phase 4 : Validation métier
- Tasklist V2 : assignations, formulaires, permissions
- APIs V2 : pagination, filtrage process instances
Phase 5 : Post-production
- Surveillance 48h : logs, métriques, alertes
- Plan rollback : snapshots DB + Helm downgrade 8.7
Pièges à éviter (Lessons Learned)
- Exporter mal configuré → Instances invisibles Operate
- APIs V1 oubliées → Échecs Tasklist/Operate post-upgrade
- User Tasks job-based → Perte fonctionnalités Tasklist V2
- Identity sans Keycloak → Permissions cassées
- OpenSearch non migré → Métriques/historiques perdus
Nouveau paradigme : Agentic Orchestration
8.8 démocratise les AI agents en BPMN :
Ad-hoc subprocess :
├── AI Agent Connector (LLM décision)
├── Vector DB Connector (contexte métier)
├── Camunda User Task (humain si besoin)
└── completionCondition dynamique
Parfait pour les workflows « analyse → décision → exécution » complexes.
Roadmap post-8.8
- 8.9 : BPMN Copilot self-managed (« Bring Your Own Model »)
- 8.10 : Suppression définitive APIs V1 Tasklist/Operate
- Focus : 100% Camunda User Tasks + agentic patterns
Conclusion : Migration stratégique
Camunda 8.8 n’est pas une simple mise à jour : c’est la fondation d’une plateforme enterprise-grade pour l’IA orchestrée. L’effort initial (tests APIs + infra) paie par des déploiements simplifiés et des capacités agentiques inédites. Planifiez dès maintenant avant la fenêtre 8.10.
