Recipient List

L'émetteur calcule lui-même qui doit recevoir le message, message par message. Plus précis qu'un canal pub/sub, indispensable quand la liste dépend du contenu — typiquement les Continuous Transaction Controls fiscaux.

Problème

Un événement métier doit atteindre une liste précise de destinataires qui change à chaque envoi : une facture UBL doit aller à l'acheteur désigné, à l'autorité fiscale du pays acheteur (5-coins en Italie, France à partir de 2026), et au coffre d'archivage. Le canal pub/sub est trop large : il diffuserait à tout abonné, alors qu'on veut une diffusion contrôlée dépendant du contenu de chaque facture (pays acheteur, montant, type d'opération).

Forces

• La liste dépend du message. Selon le pays acheteur, le type d'opération, le montant, l'audience varie.
• L'émetteur a le contexte. Lui seul connaît les règles métier qui déterminent qui doit recevoir.
• Auditabilité. En réglementaire, il faut prouver à qui un message a été envoyé ; pub/sub à abonnés inconnus rend cette preuve impossible.
• Précision > généralité. Diffuser à 200 abonnés quand seuls 3 sont pertinents pollue les downstream et complique l'idempotence.

Solution

EIP §249 (Hohpe & Woolf, 2003) prescrit : l'émetteur calcule explicitement la liste des destinataires pour ce message, et achemine une copie à chacun via des canaux dédiés. Le composant typique est un routeur stateful qui : (1) lit le message, (2) applique des règles métier pour produire la liste, (3) émet une copie par destinataire sur son canal point-à-point dédié.

Producer chooses the audience explicitly
   ─────────────────────────────────────────

   ┌──────────┐    ┌────────────────────┐      ┌──▶ recipient A (buyer)
   │ producer │ ──▶│  Recipient List   │ ─────┼──▶ recipient B (tax authority)
   └──────────┘    │  [A, B, C]        │      │
                   └────────────────────┘      └──▶ recipient C (archive)

   The list is built per message; A/B/C don't pre-subscribe.

Différence avec Publish-Subscribe

Le contraste avec Publish-Subscribe Channel est essentiel :

Implémentation EDI

• SBDH multi-Receiver. Le Standard Business Document Header (ISO/IEC 15000-5) supporte plusieurs éléments <Receiver> dans le même header — c'est la Recipient List nativement encodée dans le wrapper UBL/PEPPOL. Le hub d'émission calcule la liste par règles, l'encode dans le SBDH, route une copie par receiver.
• X12 — diffusion 856 multi-store. Un fournisseur Walmart qui livre 12 magasins reçoit la liste des destinataires Store ID dans le manifest de routing ; il émet un 856 par Ship To en utilisant cette liste.
• EDIFACT — APERAK ciblé. Un hub de validation qui détecte 3 partenaires concernés par une erreur (émetteur, destinataire, plate-forme tierce) émet 3 APERAK distincts dans sa Recipient List explicite, pas un broadcast.

<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
  <StandardBusinessDocumentHeader>
    <Sender>
      <Identifier Authority="iso6523-actorid-upis">0088:5798000000122</Identifier>
    </Sender>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">0088:7300010000001</Identifier>
    </Receiver>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">9925:BE0987654321</Identifier>
    </Receiver>
    <Receiver>
      <Identifier Authority="urn:archival:ediverse">archive-eu-1</Identifier>
    </Receiver>
    <DocumentIdentification>
      <InstanceIdentifier>inv-202605140001</InstanceIdentifier>
      <Type>Invoice</Type>
    </DocumentIdentification>
  </StandardBusinessDocumentHeader>
  <Invoice>
    <!-- payload UBL -->
  </Invoice>
</StandardBusinessDocument>

Lecture : le SBDH ci-dessus déclare trois Receivers (acheteur, autorité fiscale belge, coffre d'archivage). Le hub d'émission calcule cette liste à partir des règles fiscales du pays acheteur et des règles d'archivage interne — un 4e ou 5e receiver est ajouté automatiquement si le montant dépasse un seuil de reporting.

CTC et 5-coins PEPPOL

Le pattern est devenu central avec l'adoption des Continuous Transaction Controls (CTC) en Europe : Italie (Sistema di Interscambio, 2019), Pologne (KSeF, 2024), France (PPF / PDP, septembre 2026). Le modèle 5-coins PEPPOL ajoute un coin « autorité fiscale » qui doit recevoir une copie de chaque facture taxable. La Recipient List, calculée par la plateforme de dématérialisation au moment de l'émission, est exactement le mécanisme : à chaque facture, le système décide quelles autorités sont concernées (selon les pays émetteur et acheteur, les seuils, les régimes spéciaux).

Anti-patterns

• Hard-coding de la liste dans la config. La liste change avec la réglementation et les pays ; la coder en dur ralentit chaque évolution réglementaire (ex : arrivée du KSeF polonais en 2024).
• Pub-sub là où Recipient List s'impose. Diffuser une facture à un topic « facture-emise » où des dizaines de systèmes s'abonnent rend impossible la preuve d'audit réglementaire.
• Liste recalculée côté receiver. Si chaque receiver doit décider lui-même s'il est concerné par un message reçu, on gaspille de la bande et on crée des incohérences interprétatives.
• Pas d'idempotence cross-receiver. Sans clé d'idempotence partagée, une retransmission ciblée d'un seul receiver peut ré-injecter le message ailleurs.

Patterns liés

• Publish-Subscribe Channel — l'alternative à liste implicite par souscription.
• Content-Based Router — un routeur qui ferait choisir un canal unique ; Recipient List en émet plusieurs.
• Splitter — découpe le message ; Recipient List le copie sans le découper.
• Idempotence — pré-requis pour gérer la retransmission par receiver.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Recipient List (§249). enterpriseintegrationpatterns.com — Recipient List
• ISO/IEC 15000-5 — ebXML CCTS, formalise le Standard Business Document Header (SBDH), incluant la possibilité de multiples Receivers.
• OpenPEPPOL — 5-corner model. Document décrivant l'extension du modèle 4-coins à 5-coins pour la CTC. peppol.eu/peppol-explained
• Apache Camel — Recipient List EIP. Implémentation open-source de référence du pattern. camel.apache.org — Recipient List