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

Correlation Identifier

Quand un MDN arrive trois heures après la commande, comment retrouver la commande ? Chaque réponse EDI porte explicitement la référence du message qu'elle acquitte — c'est le pivot qui ferme la boucle.

Problème

Un demandeur émet plusieurs requêtes en parallèle : 50 commandes 850 dans la même journée. Les réponses arrivent dans un ordre arbitraire, parfois sur un autre canal, parfois après plusieurs heures. Comment le demandeur retrouve-t-il la requête qui correspond à chaque réponse ? Sans identifiant explicite, il faut joindre par horodatage, contenu, deviner — fragile et non scalable.

Forces

  • Asynchrone par défaut. En EDI, presque tout est asynchrone : la réponse n'est pas dans la même connexion que la requête.
  • Multiplexage. Un même canal AS2 transporte des dizaines de transactions en parallèle ; le demandeur a besoin d'un identifiant unique pour chaque corrélation.
  • Stabilité. L'identifiant doit survivre aux retransmissions, aux traversées de hub, aux changements de format.
  • Pas d'information sémantique requise. L'identifiant n'a pas à avoir de sens métier : c'est juste un libellé opaque.

Solution

EIP §163 (Hohpe & Woolf, 2003) prescrit : chaque réponse porte une référence (le Correlation Identifier) à l'identifiant unique de la requête d'origine. Le demandeur tient une table request id → contexte ; à réception, il lit l'identifiant et restaure son contexte (callback à appeler, état de transaction à mettre à jour, futur à compléter). Le pattern est dual du Return Address — l'un dit où, l'autre dit quoi.

X12 — AK1 / AK2 du 997

L'acquittement fonctionnel X12 997 est l'exemple canonique. Quand le récepteur acquitte un fonctional group PO contenant un 850, le 997 porte :

  • AK1 qui référence l'identifier code du group (PO) et son Group Control Number (GS06 d'origine) ;
  • AK2 qui référence chaque transaction set par son identifier (850) et son Transaction Set Control Number (ST02 d'origine) ;
  • AK5 et AK9 qui portent la décision globale.
x12 997-correlation.x12 
ISA*00*          *00*          *ZZ*ACMEVENDOR    *ZZ*ACMERETAIL    *260514*1500*U*00401*000000456*0*P*>~
GS*FA*ACMEVENDOR*ACMERETAIL*20260514*1500*456*X*004010~
ST*997*0001~
AK1*PO*123~
AK2*850*0001~
AK5*A~
AK9*A*1*1*1~
SE*6*0001~
GE*1*456~
IEA*1*000000456~
plaintext x12-correlation-trace.txt 
Original message
 ─────────────────
 ST 850, Control 0001         (ST02 = original)
 GS, Control 123              (GS06 = original)
 ISA, Control 000000123       (ISA13 = original)

Functional ACK 997
 ──────────────────
 AK1 PO 123                   ← references GS06 of the original group
 AK2 850 0001                 ← references ST02 of the original transaction
 AK9 A 1 1 1                  ← group-level decision

Lecture : à réception du 997, le demandeur lit AK101 (PO) et AK102 (123) → il sait que c'est l'ACK du functional group 123 qu'il a émis ce matin. Puis AK2 850 0001 → il identifie précisément la transaction. Sans ces références, impossible d'automatiser le rapprochement.

EDIFACT — UCI / UCM du CONTRL

Le message CONTRL EDIFACT applique la même mécanique. UCI (Interchange Response) référence l'Interchange Control Reference de l'UNB original ; UCM (Message Response) référence l'Reference Number de l'UNH original. Le demandeur retrouve son contexte exactement comme en X12, en lisant ces deux niveaux de référence.

AS2 et AS4 — Original-Message-ID

AS2 (RFC 4130) inscrit le pattern dans l'en-tête MIME du MDN : le champ Original-Message-ID du MDN porte la valeur du Message-ID du message d'origine. L'application AS2 réceptrice du MDN utilise ce champ comme clé pour retrouver la trace de l'envoi.

AS4 (OASIS ebMS3) systématise via le bloc eb:Receipt : l'élément eb:RefToMessageId dans l'en-tête de la réponse pointe le MessageId de l'original. C'est l'instrument du Receipt PEPPOL et de la Non-Repudiation of Receipt (NRR).

Anti-patterns

  • Corrélation par horodatage. Croire que la réponse la plus proche dans le temps est celle de la requête en cours casse dès qu'il y a parallélisme, retransmission, ou décalage horaire entre les deux systèmes.
  • Corrélation par contenu. Joindre sur le numéro de commande métier interne est trompeur : deux requêtes peuvent porter le même contenu sans être la même transaction (retransmission, doublon).
  • Identifiant émis côté récepteur. Si le récepteur assigne un nouvel ID dans la réponse sans reprendre l'ID original, le demandeur ne peut plus corréler. Toujours relayer l'ID d'origine.
  • Identifiant trop court ou non unique. Un compteur à 4 chiffres rollover en quelques jours sur un canal à fort volume — utiliser un UUID ou un ISA13 à 9 chiffres.

Patterns liés

  • Return Address — dit où envoyer la réponse ; Correlation Identifier dit quoi mettre dedans.
  • Idempotence — l'identifiant de corrélation peut servir de clé d'idempotence côté récepteur.
  • Acquittements — le mécanisme qui transporte le Correlation Identifier.
  • Process Manager — l'orchestrateur qui consomme les corrélations pour faire avancer sa machine à états.

Sources