Message Endpoint
Le point de raccordement code métier ↔ système de messagerie EDI — la couche d'abstraction qui rend AS2/AS4/SFTP interchangeables.
Problème
Une application métier (ERP, OMS, TMS) doit échanger avec un partenaire via un protocole EDI. Comment éviter que le code métier dépende des détails du protocole (URL AS2, certificats X.509, options SOAP AS4) ?
Forces
- Les protocoles EDI évoluent : OFTP → AS2 → AS4 ; le code métier ne doit pas être refait à chaque migration.
- Plusieurs partenaires peuvent demander des protocoles différents — le même message ORDERS doit pouvoir partir en AS2 vers l'un et en SFTP vers l'autre.
- Les compétences sécurité (X.509, mTLS, OCSP) ne doivent pas polluer le code métier.
- Les retries, timeouts, idempotence doivent être traités à un seul endroit, pas dispersés.
Solution
Introduire une classe Message Endpoint (ou un service dédié) qui expose au métier une API simple — sendOrder(order), receiveInvoice() — et qui encapsule en interne tout le protocole : sérialisation, chiffrement, retries, gestion d'accusé. Le métier ne voit que des objets métier ; l'endpoint voit le wire.
Implémentation EDI
En EDI, le Message Endpoint est typiquement implémenté comme service Apache Camel, Spring Integration, ou MuleSoft connector. La règle classique : un endpoint par couple (partenaire, protocole). Côté entrant, l'endpoint reçoit l'AS2 MDN, désérialise le payload, valide la signature, dépose un évènement dans Kafka. Côté sortant, il consomme un évènement, sérialise en EDIFACT/X12/UBL, signe, chiffre, envoie. Patterns Camel : producer / consumer / route DSL.
Anti-patterns
- Endpoint omniscient qui mélange métier et transport — séparer les concerns par couche.
- Endpoint sans timeout/retry configurés — le partenaire down bloque toute la chaîne.
- Endpoint partagé entre partenaires — un partenaire problématique impacte tous les autres.
- Endpoint sans observability (logs structurés, traces, metrics) — debugger une chaîne de production devient impossible.
Patterns liés
- Message Channel — le canal sur lequel le endpoint se branche.
- Point-to-Point Channel — topologie typique pour un endpoint EDI.
- Polling Consumer — type d'endpoint qui pull.
- Event-Driven Consumer — type d'endpoint qui push.
Sources
- Hohpe G., Woolf B. — EIP, Message Endpoint (p. 95). www.enterpriseintegrationpatterns.com/patterns/messaging/MessageEndpoint.html
- Apache Camel — Component Reference. camel.apache.org/components/4.4.x/