Return Address

Quand un message attend une réponse, où celle-ci doit-elle aller ? Plutôt que de laisser le récepteur deviner ou consulter un annuaire, le message porte l'adresse explicite — la signature même de tous les accusés EDI.

Problème

L'émetteur d'un message EDI attend généralement une réponse : un MDN AS2, un CONTRL EDIFACT, un 997 X12, un AS4 Receipt. Le récepteur doit acheminer cette réponse quelque part, mais d'où vient l'information ? Trois mauvaises options : (1) déduire de l'identifiant émetteur via un annuaire, ce qui suppose un annuaire centralisé et à jour ; (2) hard-coder dans la configuration de la relation bilatérale, ce qui multiplie les points de maintenance ; (3) renvoyer par le même canal, ce qui fonctionne en synchrone mais pas en asynchrone décalé (heures, jours).

Forces

• Le canal de réponse n'est pas toujours le canal d'envoi. En EDI asynchrone, le MDN peut revenir par une nouvelle connexion AS2 sortante, pas dans la réponse HTTP.
• L'émetteur veut changer d'adresse sans recâbler les partenaires. Un hub qui migre de edi.acme.com à edi-eu.acme.com ne veut pas que chaque partenaire mette à jour son annuaire.
• Le récepteur ne doit pas couplé sur la topologie de l'émetteur. Il ne sait pas — et ne veut pas savoir — si l'émetteur a un load balancer, un sub-domain dédié, une queue interne.
• L'adresse de retour doit survivre au routage intermédiaire. Un message peut traverser un VAN, un Access Point PEPPOL, un broker cloud — la Return Address ne doit pas être réécrite par les étapes intermédiaires.

Solution

EIP §159 (Hohpe & Woolf, 2003) prescrit : chaque message porte explicitement l'adresse à laquelle la réponse doit être envoyée. C'est un en-tête dédié, distinct de l'identifiant émetteur, qui désigne un endpoint — URL, queue, AS2 URL, MessageId à utiliser comme clé. Le récepteur lit cette adresse et y route la réponse, sans avoir à consulter un annuaire ou la configuration locale.

EDI — AS2 et MDN signé

AS2 (RFC 4130) institutionnalise le pattern Return Address via deux en-têtes : Disposition-Notification-To qui désigne l'adresse e-mail logique du destinataire du MDN, et le moins connu Receipt-Delivery-Option qui désigne l'URL HTTP où poster le MDN asynchrone. C'est l'URL qui compte techniquement, pas l'email — le récepteur AS2 utilise Receipt-Delivery-Option comme cible HTTP-POST de son MDN.

POST /as2/inbound HTTP/1.1
Host: partner-b.example.com
AS2-Version: 1.1
AS2-From: "PARTNER_A_ID"
AS2-To: "PARTNER_B_ID"
Message-ID: <msg-2026-05-14-0001@partner-a>
Subject: Invoice batch 0001
Disposition-Notification-To: edi-receipts@partner-a.example.com
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature;
  signed-receipt-micalg=optional, sha-256
Receipt-Delivery-Option: https://partner-a.example.com/as2/mdn

Lecture : l'en-tête Receipt-Delivery-Option dit au récepteur AS2 « envoie ton MDN à cette URL, pas à celle déduite de AS2-From ». Cela permet de poster le MDN sur un endpoint dédié (par exemple un domaine d'archivage edi-receipts) sans changer la configuration de chaque partenaire.

EDIFACT — UNB Sender/Recipient

En EDIFACT (ISO 9735), le segment UNB porte les identifiants émetteur (S005) et destinataire (S010). L'adresse de retour pour le CONTRL fonctionnel est implicitement l'émetteur du message original, mais le partenaire peut, par convention bilatérale, demander que le CONTRL soit envoyé à un identifiant différent — par exemple, le hub d'archivage central plutôt que l'émetteur de la transaction. C'est ce qu'on encode dans un identifiant secondaire de routage stocké dans la configuration EDIINT et lu sur réception.

AS4 — eb:From et ReplyPattern

AS4 (OASIS ebMS3) systématise le pattern : le bloc eb:Messaging contient un eb:From qui identifie l'émetteur logique, et un eb:ReplyPattern qui précise si la réponse (Receipt, Error) doit revenir Response (dans la même connexion HTTP) ou Callback (vers une URL distincte, portée par PMode.Receipt.ReplyPattern). En PEPPOL, la valeur typique est Response pour les Receipts car les Access Points sont co-hébergés, mais Callback est nécessaire pour les flux où l'émetteur n'expose pas d'écoute synchrone.

Anti-patterns

• Hard-code l'adresse de retour dans la configuration récepteur. L'émetteur ne peut plus migrer son endpoint sans coordonner avec tous les partenaires — c'est le contraire du couplage faible que le pattern apporte.
• Adresse de retour absente. Sans en-tête explicite, le récepteur doit deviner ou consulter un annuaire ; si l'annuaire est désynchronisé, le MDN est envoyé dans le vide et l'émetteur ne sait pas que sa transmission a réussi.
• Adresse de retour réécrite par un intermédiaire. Un VAN ou un hub qui réécrit Receipt-Delivery-Option vers sa propre URL casse l'observabilité bout-en-bout : l'émetteur reçoit un MDN mais ne sait pas d'où il vient vraiment.
• Confusion avec l'identifiant émetteur. AS2-From identifie l'émetteur logique ; Receipt-Delivery-Option est l'URL technique. Confondre les deux force l'émetteur à exposer un endpoint AS2 dédié sur le même nom logique.

Patterns liés

• Correlation Identifier — l'identifiant qui permet de relier la réponse à la requête.
• Acquittements — la réponse qui utilise la Return Address.
• Point-to-Point Channel — le canal sous-jacent.
• Message Router — le composant côté récepteur qui lit la Return Address.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Return Address (§159). enterpriseintegrationpatterns.com — Return Address
• RFC 4130 — AS2. Section sur Disposition-Notification-To et Receipt-Delivery-Option, le contrat AS2 du Return Address. rfc-editor.org/rfc/rfc4130
• OASIS ebMS3 / AS4. Le bloc eb:Messaging et ReplyPattern de PMode. docs.oasis-open.org/ebxml-msg
• ISO 9735 — segments UNB et UNZ de la syntaxe EDIFACT.