Process Manager

Le cycle complet d'une commande EDI dure des jours, voire des mois : PO émise, accusé fonctionnel, accusé métier, ASN livraison, INVOIC, paiement. Le Process Manager est l'orchestre stateful qui maintient l'état de chaque cycle et déclenche les actions / escalades.

Problème

Un échange EDI n'est jamais un message isolé : c'est une conversation. Un PO (ORDERS) attend un accusé fonctionnel (CONTRL / 997), un accusé métier (APERAK / 855), une livraison (DESADV / 856), une facture (INVOIC / 810), un paiement (REMADV / 820). Chaque étape a son timing attendu, ses escalades en cas d'absence, sa compensation en cas d'annulation. Si chaque microservice ne sait que son étape, personne ne tient la vue d'ensemble ; les commandes se perdent en silence. Il faut un composant qui tient l'état du cycle complet.

Forces

État persistant longue durée. Le cycle dure des semaines ; impossible de tenir l'état en mémoire d'un processus.
Réception asynchrone et désordonnée. Le 855 peut arriver avant ou après le 856 selon les partenaires. Le manager doit gérer.
Timers et escalades. Si le 855 n'arrive pas en J+7, déclencher une relance ; en J+14, escalader à l'opérateur ; en J+30, ouvrir un ticket métier.
Compensation. Si une commande est annulée après ASN, il faut envoyer un message de retour, créditer l'inventaire, annuler la facture si déjà émise.
Observabilité. À tout instant on doit pouvoir lister les cycles en cours, leur état, leur prochaine échéance.

Solution

EIP §312 (Hohpe & Woolf, 2003) définit le Process Manager comme un composant central qui : (a) instancie une machine à états par cycle métier (par PO, par interchange), (b) lit les messages entrants et applique les transitions, (c) maintient des timers par état pour détecter les non-réponses, (d) émet des commandes ou des messages de compensation. L'état est persisté (DB relationnelle ou event store) pour survivre aux redémarrages. C'est le pendant centralisé de la chorégraphie distribuée ; chacune a son terrain (voir le débat orchestration vs. chorégraphie de Newman).

plaintext topology.txt

ORDERS  ───▶  ┌──────────────────────────┐
                  │  Process Manager (PO-12)  │
   ORDRSP  ───▶  │   state: PO_CONFIRMED     │
                  │   started: 2026-05-01     │
   DESADV  ───▶  │   timers:                 │
                  │     - ASN expected D+5    │
   INVOIC  ───▶  │     - INV expected D+30   │
                  │     - REMADV expected D+60│
   REMADV  ───▶  │   compensations:          │
                  │     on_timeout(ASN)       │
                  └──────────────────────────┘
                            │
                            ▼
                  emits commands / events
                  on canaux pipeline

Implémentation EDI

Cycle Walmart 850 → 855 → 856 → 810 → 820 (PO américain). Équivalent EDIFACT : ORDERS → ORDRSP → DESADV → INVOIC → REMADV.

yaml po-state-machine.yaml

# Machine à états du processus PO (Walmart 850→855→856→810→820)
states:
  - INITIATED          # PO créé en interne
  - SENT               # 850 émis vers fournisseur (acquitté 997)
  - CONFIRMED          # 855 reçu (acceptation, modif ou refus)
  - SHIPPED            # 856 ASN reçu
  - INVOICED           # 810 INVOIC reçu
  - PAID               # 820 remittance émise
  - CLOSED             # cycle complet
  - CANCELLED          # PO annulé en route

transitions:
  INITIATED -> SENT:    on send_purchase_order
  SENT      -> CONFIRMED: on receive 855
  CONFIRMED -> SHIPPED:   on receive 856
  SHIPPED   -> INVOICED:  on receive 810
  INVOICED  -> PAID:      on send 820
  PAID      -> CLOSED:    automatic
  (any)     -> CANCELLED: on cancel command

timers:
  SENT      timeout 7d  -> escalate(no-855)
  CONFIRMED timeout 30d -> escalate(no-shipment)
  SHIPPED   timeout 30d -> escalate(no-invoice)
  INVOICED  timeout 30d -> escalate(unpaid)

Lecture : chaque PO créée instancie une machine au statut INITIATED. À chaque réception d'un message attendu (855, 856, 810…), la transition est déclenchée. Si un timer expire avant la transition, une escalade est émise sur un canal dédié (edi.escalation.po.unconfirmed par exemple), qui peut alimenter un dashboard, un mail à l'opérateur, ou une relance automatique.

PunchOut B2B (cXML). Le cycle PunchOut a un manager qui suit l'état entre PunchOutSetupRequest, PunchOutSetupResponse, sélection panier, retour PunchOutOrderMessage, conversion en commande formelle. Si l'utilisateur abandonne en route, timer + nettoyage.
Vendor Managed Inventory (VMI). Le cycle INVRPT (inventaire) → ORDERS (commande générée) → DESADV (livraison) est piloté par un manager qui calcule les seuils et déclenche les commandes automatiquement.
Facturation B2G CTC. Un manager suit l'envoi facture → réception accusé fiscal (administration) → réception acceptation buyer → réception paiement, avec timers réglementaires (par exemple FE-B2B pré-validation 24h).

Timeouts et compensation

Trois types d'actions sur timer :

Relance automatique. Réémettre un 850 si pas de 997 dans 1h.
Escalade humaine. Ouvrir un incident si pas de 855 dans 7j (le partenaire ne répond pas).
Compensation. Annulation après ASN ? Émettre un message de retour, créditer l'inventaire, annuler la facture si déjà émise — séquence d'actions compensatoires pour défaire le travail déjà fait.

Anti-patterns

État en mémoire. Un redémarrage perd 100 % des cycles en cours. État toujours persistant.
Pas de timer. Sans timer, un partenaire silencieux passe inaperçu jusqu'à ce qu'un opérateur tombe dessus. Toujours des timers + alertes.
Compensation oubliée. Annuler une commande sans annuler la facture déjà émise produit des incidents comptables graves. Tracer chaque étape réversible.
Couplage trop fort. Process manager qui appelle directement les microservices, au lieu d'émettre des commandes sur le bus. On perd le découplage.
Saga sans idempotence. Réception d'un même 855 deux fois doit être idempotente (transition une fois). Sinon double facturation.

Patterns liés

Routing Slip — l'alternative dynamique stateless (chorégraphie).
Message History — l'historique des étapes traversées, alimenté par le manager.
Flux d'exception — la matrice d'escalade pilotée par le manager.
Aggregator — outil utilisé par le manager pour consolider des partiels.

Sources

Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Process Manager (§312). enterpriseintegrationpatterns.com — Process Manager
Garcia-Molina H., Salem K. — SAGAS, ACM SIGMOD 1987. La référence académique du pattern saga, modèle formel des transactions longues compensables.
Newman S. — Building Microservices, O'Reilly, 2e éd. 2021, chapitre 6. Le débat orchestration vs. chorégraphie et son traitement moderne.
X12 Implementation Guide — 850/855/856/810/820 cycle. La séquence canonique des messages PO américains, référence pratique pour la machine à états.

Fondamentaux

Standards

Messages phares

Outils