ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Saga Choreography

Une saga sans chef d'orchestre — chaque service réagit aux événements du domaine et émet les siens. Adapté aux cycles EDI partenaires autonomes, là où la Saga Orchestration imposerait un coordinateur centralisé.

Problème

Un cycle EDI ORDERS → ORDRSP → DESADV → INVOIC → REMADV traverse plusieurs services internes (Achats, Logistique, Facturation, Trésorerie) qui sont autonomes et déjà découplés par messagerie. Imposer un orchestrator centralisé ajoute un point de couplage et un goulot d'étranglement : chaque étape doit signaler son achèvement à l'orchestrator, qui doit décider de l'étape suivante. Pourquoi ne pas laisser chaque service réagir directement à l'événement précédent ?

Forces

  • Pas de service central. La saga vit dans l'interaction d'événements ; aucune équipe ne possède le workflow complet.
  • Couplage faible. Chaque service ne connaît que les événements qu'il consomme et émet, pas la séquence globale.
  • Mais le workflow se dissimule. Comprendre la séquence end-to-end demande de lire le code de tous les services.
  • Cycle de dépendances possible. Si A réagit à B qui réagit à C qui réagit à A, on peut boucler sans s'en rendre compte.

Solution

Chaque service de domaine est abonné aux événements pertinents et émet les siens en retour. Les compensations sont déclenchées par des événements inverses (OrderCancelled, ShipmentRecalled) qui chaque service consomme s'il a réalisé l'effet correspondant. Aucun service ne possède la séquence complète ; elle émerge de la composition.

plaintext saga-choreography-edi.txt 
[Buyer service] reçoit ORDERS d'un fournisseur
    │
    ├─emit─► OrderAccepted(orderId=ORD789) ─► topic: orders
    │
[Supplier service] consomme OrderAccepted
    ├─emit─► ORDRSP envoyé au partenaire EDI ─► topic: order-responses
    │
[Logistics service] consomme OrderAccepted, prépare expédition
    ├─emit─► ShipmentDispatched(asn=ASN9001) ─► topic: shipments
    ├─send─► DESADV au partenaire
    │
[Billing service] consomme ShipmentDispatched (+ trigger temps)
    ├─emit─► InvoiceIssued(invoice=INV-7811) ─► topic: invoices
    ├─send─► INVOIC au partenaire
    │
[Treasury service] consomme InvoiceIssued + ReceiptConfirmed
    ├─emit─► PaymentRemitted(amount=1240.00) ─► topic: payments
    └─send─► REMADV au partenaire

Compensation = chaque service expose un handler pour les événements
inverses (OrderCancelled, ShipmentRecalled, InvoiceCredited).

Implémentation EDI

Cas concret EDI : l'orchestration d'un cycle PO ↔ ASN ↔ INVOIC ↔ REMADV. Le service Buyer reçoit l'ORDERS d'un partenaire, le valide, publie un événement OrderAccepted sur le topic Kafka orders. Le service Supplier consomme, émet un ORDRSP et publie OrderConfirmed. Le service Logistics consomme OrderAccepted, prépare l'expédition et publie ShipmentDispatched — il émet aussi le DESADV au partenaire EDI. Le service Billing consomme ShipmentDispatched et émet l'INVOIC. Le service Treasury attend le ReceiptConfirmed de la réception RECADV, déclenche le règlement et émet le REMADV. Aucun composant ne possède le workflow complet ; il vit dans la grille des abonnements Kafka.

Choreography vs Orchestration

Les deux variantes de Saga (Choreography, Orchestration) sont complémentaires :

  • Choreography convient aux workflows à 3-5 étapes stables et bien comprises, dans des organisations matures découpées en bounded contexts.
  • Orchestration convient aux workflows complexes, changeants, ou avec branches conditionnelles fines, où la lisibilité du workflow prime sur le découplage.
  • Souvent les deux coexistent : choreography entre domaines, orchestration interne à un domaine.

Anti-patterns

  • Workflow caché dans 10 services. Sans cartographie des événements, plus personne ne comprend le cycle bout-en-bout après 18 mois.
  • Boucle non détectée. Service A produit X, B réagit en produisant Y qui fait que A produit X — la chaîne explose.
  • Compensations partielles. Un service oublie de consommer OrderCancelled : la commande reste annulée dans 4 services sur 5, ce qui rend l'état incohérent.
  • Pas de TraceId transverse. Sans identifiant de corrélation propagé dans tous les événements, l'investigation d'incident devient une chasse au trésor.

Patterns liés

Sources