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

Message Channel

Avant de parler de routage, de traduction ou d'agrégation, il faut nommer ce qui sépare deux applications : le canal. EIP §60 pose cette brique élémentaire que toute la suite du catalogue habille de sémantiques plus riches.

Problème

Deux applications doivent échanger des messages sans se connaître directement. Si l'émetteur ouvre une socket TCP sur l'IP du récepteur, on couple le code des deux côtés au transport, à la disponibilité simultanée, à la stabilité réseau. À la première panne ou au premier ajout d'un troisième consommateur, tout s'effondre. En EDI, on a en plus des contraintes de chiffrement, de signature, d'accusé ; et l'émetteur ne sait souvent pas si le récepteur est connecté. Il faut donc une abstraction qui représente le conduit lui-même — adressable, typée, avec une sémantique de livraison définie.

Forces

  • Découplage spatial. L'émetteur ne doit pas connaître l'IP ni la disponibilité du récepteur, seulement le nom du canal.
  • Découplage temporel. L'émetteur et le récepteur ne doivent pas tourner au même moment ; le canal peut bufferiser.
  • Typage. Un canal ne transporte pas n'importe quoi : on lui associe un type (ORDERS, INVOIC, MDN…) pour qu'un consommateur ne lise pas un message qu'il ne peut pas traiter.
  • Sémantique de livraison. At-most-once, at-least-once, exactly-once — chacune a son coût et ses compromis ; le canal doit la déclarer.
  • Durabilité. Persiste-t-on les messages sur disque ou non ? Trade-off latence ↔ tolérance aux pannes.

Solution

EIP §60 (Hohpe & Woolf, 2003) définit le Message Channel comme un conduit logique nommé entre deux ou plusieurs participants. Le canal porte cinq attributs essentiels : un nom adressable (URI, sujet JMS, queue ARN, topic Kafka), une direction (input / output / bidirectionnel), un type de message (schema accepté), une sémantique de livraison (at-most-once, at-least-once, exactly-once) et un profil de durabilité (persistant, mémoire, signé). Le code applicatif ne se relie pas à un peer, il se relie à un canal.

plaintext topology.txt 
Application A                         Application B
   ─────────────                         ─────────────

   ┌──────────┐         channel          ┌──────────┐
   │ producer │ ───────────────────────▶ │ consumer │
   └──────────┘   addressable conduit    └──────────┘
                  - direction
                  - typage du message
                  - sémantique de livraison
                  - durabilité

Implémentation EDI

En EDI, chaque connexion partenaire est, conceptuellement, un canal distinct :

  • Canal AS2 point-à-point. Une connexion AS2 entre deux partenaires (RFC 4130) est un canal bilatéral, chiffré (CMS / PKCS#7), signé, avec accusé MDN. Le nom du canal est typiquement le couple (AS2-From, AS2-To). Une direction par sens.
  • Canal SFTP. Un répertoire de drop sur un serveur SFTP est un canal asynchrone par fichier. Le nom du canal est le chemin (/edi/in/walmart/). Pas de livraison transactionnelle par défaut, donc surface d'idempotence requise en aval.
  • Canal AS4 PEPPOL. Un Access Point reçoit sur une URL HTTPS un message AS4 ; le canal est le couple (endpoint URL, participant ID). La sémantique de livraison est at-least-once (NRR garanti par WS-ReliableMessaging).
  • Canal interne Kafka / RabbitMQ. Entre le hub d'intégration et les microservices internes, des canaux topic Kafka (edi.invoic.in.canonical) ou queue RabbitMQ avec retention configurée.
http as2-channel.http 
# AS2 message envelope — canal point-à-point chiffré et signé
POST /as2 HTTP/1.1
Host: partner.example.com
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
AS2-From: SUPPLIER_GLN
AS2-To: BUYER_GLN
Message-ID: <inv-202605140001@ediverse.io>
Disposition-Notification-To: as2@ediverse.io
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature;
  signed-receipt-micalg=optional, sha-256
EDIINT-Features: multiple-attachments, AS2-Reliability

<encrypted-EDIFACT-payload>

Lecture : l'en-tête HTTP AS2 porte les attributs du canal — From / To identifient les pairs, Message-ID indique la sémantique d'unicité, Disposition-Notification-To réclame l'accusé MDN. L'application émettrice ne sait pas comment le canal est implémenté en dessous (TLS, routage IP, retry HTTP) ; elle publie sur le canal AS2 logique.

Taxonomie des canaux

Hohpe regroupe les canaux en quatre familles fondamentales :

  • Point-to-Point Channel (EIP §103) — un seul consommateur reçoit chaque message. Équivalent EDI : AS2 entre deux partenaires.
  • Publish-Subscribe Channel (EIP §106) — plusieurs consommateurs reçoivent chaque message. Équivalent EDI : un SBDH UBL routé via PEPPOL vers plusieurs AP destinataires d'une même facture.
  • Datatype Channel (EIP §111) — un canal ne transporte qu'un type de message. Équivalent EDI : edi.orders.canonical et edi.invoic.canonical séparés.
  • Invalid Message Channel (EIP §115) — où vont les messages mal formés. Voir Dead Letter Channel.

Anti-patterns

  • Couplage au transport. Écrire dans le code applicatif new Socket("partner.example.com", 21) au lieu de publish("partner.invoic.out"). Migration vers AS4 impossible sans réécriture.
  • Canal poubelle. Un canal nommé edi.in qui reçoit tous les types de messages. On retombe alors sur la nécessité d'un Message Router en amont — autant le nommer.
  • Sémantique de livraison implicite. Ne pas déclarer si le canal est at-most-once ou at-least-once mène inévitablement à des incidents de doublons ou de pertes.
  • Canaux non versionnés. Quand le schéma d'un type évolue, créer edi.invoic.v2.canonical à côté plutôt que de casser tous les consommateurs.

Patterns liés

Sources