Message History

Chaque message porte la trace de son propre voyage. Quand on cherche pourquoi un INVOIC arrive en retard ou pourquoi un ORDERS est rejeté, on ouvre l'historique embarqué : liste des composants traversés, versions, horodatages. La pierre angulaire du débogage distribué.

Problème

Un pipeline EDI moderne traverse une vingtaine de composants : AS2 gateway, sniffer, parser, validator, enricher, translator, router, ERP adapter, etc. Chacun a sa version, sa configuration, son nœud d'exécution. Quand quelque chose ne va pas — facture rejetée, latence anormale, mauvaise traduction — il faut pouvoir reconstituer le parcours exact du message : quels composants l'ont touché, dans quel ordre, à quelle version, sur quel nœud. Sans Message History, l'enquête se transforme en chasse aux logs disséminés. Avec, c'est lisible à l'œil dans le message lui-même.

Forces

• Auto-documentation. Le message porte sa propre preuve de chemin ; pas besoin de corréler 20 fichiers de logs.
• Auditabilité. Pour les flux fiscaux, prouver qui a touché quoi est utile lors des contrôles.
• Aide au débogage. Quand un message reproduit un bug, l'historique pointe directement vers la version coupable.
• Surcharge du message. Chaque composant ajoute ~200 octets ; sur 20 composants = ~4 KB. Acceptable pour des messages EDI typiques (KB-MB), à externaliser pour de très petits messages.
• RGPD. L'historique peut contenir des données personnelles (qui a traité ?). Ne pas exposer aux partenaires sans masquer.

Solution

EIP §551 (Hohpe & Woolf, 2003) définit le Message History comme un en-tête de message qui s'enrichit à chaque composant traversé. Le contrat est simple : chaque composant qui touche le message ajoute une entrée à la fin de la liste, contenant au minimum : son nom, sa version, son hôte, l'horodatage, l'action effectuée. Il ne supprime jamais une entrée existante. À la fin du pipeline (ou en cas d'incident), la liste est l'image fidèle du parcours.

┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
   │ A      │──▶│ B      │──▶│ C      │──▶│ D      │
   └────────┘   └────────┘   └────────┘   └────────┘
       │            │            │            │
       │            │            │            ▼
       │            │            │     append { D, ts, version }
       │            │            ▼     ────────────────────────
       │            │     append { C, ts, version }
       │            ▼     ────────────────────────
       │     append { B, ts, version }
       ▼     ────────────────────────
   append { A, ts, version }
   ────────────────────────

   Le message porte une liste cumulative : à la fin,
   on lit qui l'a touché, dans quel ordre, à quel moment.

Implémentation EDI

Trois usages concrets :

{
  "messageId": "01HVF8K3X1ABCDE0123456789",
  "messageType": "INVOIC",
  "messageHistory": [
    {
      "component": "as2-gateway",
      "version": "2.4.1",
      "host": "edi-gw-prod-02",
      "ts": "2026-05-14T12:00:00.123Z",
      "action": "received-from-partner",
      "details": { "as2From": "SUPPLIER_GLN", "as2To": "BUYER_GLN" }
    },
    {
      "component": "parser-edifact",
      "version": "1.7.0",
      "host": "edi-parse-prod-05",
      "ts": "2026-05-14T12:00:00.842Z",
      "action": "parsed",
      "details": { "format": "EDIFACT D96A", "sizeBytes": 4218 }
    },
    {
      "component": "validator-schema",
      "version": "1.7.0",
      "host": "edi-valid-prod-03",
      "ts": "2026-05-14T12:00:01.012Z",
      "action": "validated",
      "details": { "rulesPassed": 47, "rulesWarned": 1 }
    },
    {
      "component": "translator-canonical",
      "version": "3.0.2",
      "host": "edi-trans-prod-01",
      "ts": "2026-05-14T12:00:01.247Z",
      "action": "translated-to-canonical"
    },
    {
      "component": "router-outbound",
      "version": "2.1.0",
      "host": "edi-rout-prod-04",
      "ts": "2026-05-14T12:00:01.318Z",
      "action": "routed",
      "details": { "destination": "erp.sap.invoice.in" }
    }
  ]
}

• Chaîne d'acquittements CONTRL/997. Pour chaque acquittement reçu (CONTRL, 997, APERAK), inscrire dans l'historique du message original : « à 12:00:05Z, CONTRL+1 reçu du partenaire 5798000000122 ». L'historique raconte tout le cycle d'acquittement.
• Diagnostic de latence. Un INVOIC met anormalement 3 minutes à atterrir. L'historique montre que le validator a mis 2m45 à 12:00:01 — bug ou backpressure. Trace immédiate, pas besoin de corréler 5 systèmes.
• Audit fiscal. « Pouvez-vous prouver que cette facture a été émise sans modification ? » L'historique liste chaque transformation et son auteur ; combiné au hash avant/après, c'est la preuve d'intégrité.
• Détection de boucles. Si le même composant apparaît plusieurs fois (ex : deux fois router-outbound), il y a un cycle. Le pattern le détecte automatiquement.

Articulation avec W3C TraceContext

En 2026, on n'écrit pas un Message History from scratch ; on s'aligne avec W3C TraceContext (traceparent + tracestate, 2020) pour qu'OpenTelemetry / Jaeger / Tempo / Datadog puissent corréler les traces. Le Message History sert pour la couche métier (qui = quel composant a fait quoi), TraceContext sert pour la couche réseau (corrélation entre spans). Les deux coexistent dans l'enveloppe canonique du message.

Anti-patterns

• Historique qui efface. Un composant qui remplace l'historique au lieu de l'enrichir détruit la valeur du pattern. Append-only, jamais remplacé.
• Historique sans version. Tracer « passé par le validator » sans dire dans quelle version, c'est perdre la moitié de l'utilité de débogage.
• Trop verbeux. Inclure le payload complet à chaque étape multiplie la taille du message par 20. Garder symbolique, déléguer le détail aux logs.
• Historique exposé aux partenaires. Le partenaire n'a pas besoin de savoir vos détails internes (noms d'hôtes, versions). Stripper avant émission externe.
• Pas de horodatage normalisé. Mélanger timezone et formats rend l'analyse cauchemardesque. ISO 8601 UTC partout.

Patterns liés

• Message Store — stocke l'historique pour l'audit long terme.
• Process Manager — utilise l'historique pour comprendre l'état du cycle.
• Routing Slip — couplage canonique pour la chorégraphie observable.
• Acquittements — chaque ACK reçu est inscrit dans l'historique du message original.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Message History (§551). enterpriseintegrationpatterns.com — Message History
• W3C Trace Context (W3C Recommendation, novembre 2020). Format standard du traceparent et tracestate, qui complète le Message History côté observabilité réseau. w3.org/TR/trace-context
• OpenTelemetry — Specification. Modèle de tracing distribué adopté par tous les outils modernes, compatible avec Message History pour les méta-données métier. opentelemetry.io/docs/specs
• UN/EDIFACT — CONTRL et APERAK. Les types d'accusés EDIFACT, dont la chaîne s'inscrit naturellement dans le Message History.