Process Engine

Le moteur qui fait tourner les workflows EDI longue durée (jours, semaines) sans tomber sur un crash applicatif.

Problème

Un cycle PO → ORDRSP → DESADV → INVOIC → REMADV peut s'étaler sur 30 jours, avec des timers (relance 48h), des compensations (annulation à mi-parcours), et 5 décisions humaines possibles. Un code applicatif simple ne tient pas.

Forces

• L'état doit survivre aux crashes — persistence obligatoire à chaque step.
• Les timers doivent déclencher même si l'application est down (à reprendre au démarrage).
• Les compensations doivent être documentées par modèle, pas inventées en code ad-hoc.
• Le métier doit pouvoir visualiser le workflow (BPMN diagram).

Solution

Adopter un Process Engine : Camunda, Zeebe, Activiti, AWS Step Functions, Netflix Conductor, Temporal. Le workflow est défini en BPMN (ou DSL), déployé comme artefact, exécuté par le moteur. Le moteur garantit at-least-once durabilité, retries déclaratifs, timers, et observabilité du run. Le code applicatif n'implémente que les `task workers` (les actions atomiques) ; le moteur orchestre.

Implémentation EDI

En EDI, un Process Engine est le moyen pragmatique d'implémenter le Process Manager pour des cycles complexes. Cas : un cycle 'expectation 856 dans 24h après 850 sinon escalade' devient un BPMN diagram déployé sur Camunda. Le task worker `send850` publie l'EDIFACT sur Kafka ; le timer Camunda déclenche l'escalade ; un human task ouvre un ticket Jira. Le pattern paye sur la lisibilité métier : le BPMN diagram est compris par les analystes EDI, alors qu'un Java code ne l'est pas.

Anti-patterns

• Workflow en code Java/Python pur — non versionnable comme modèle, ré-implémenté à chaque évolution.
• Process Engine pour des workflows courts (< 1 minute) — overengineering, latence inutile.
• Process Engine partagé entre métiers sans namespacing — un workflow bloque les autres.
• BPMN diagram décoré sans correspondance précise au code — la documentation diverge du runtime.

Patterns liés

• Process Manager — concept dont Process Engine est le runtime.
• Saga Orchestration — compensations explicitement modélisées.
• Control Bus — observation et contrôle des runs.

Sources

• Hohpe G., Woolf B. — EIP, Process Manager (p. 312) — base conceptuelle. www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html
• Camunda — BPMN Engine. docs.camunda.io/
• OMG — BPMN 2.0 specification. www.omg.org/spec/BPMN/2.0/