Message Router

Un composant qui consomme un message d'un canal d'entrée et le republie sur l'un de plusieurs canaux de sortie selon des règles. Il ne modifie ni le contenu ni l'enveloppe — il prend juste une décision d'aiguillage.

Problème

Une plateforme EDI reçoit indifféremment des ORDERS, des INVOIC, des DESADV, des CONTRL, parfois mélangés dans un même point d'entrée (notamment quand le transport est AS2 ou SFTP commun à toute la relation). Côté aval, chaque type de message va vers un traitement différent : un ORDERS doit être routé vers le moteur de commandes, un INVOIC vers la comptabilité, un DESADV vers le WMS. Sans aiguillage en amont, chaque consommateur devrait filtrer lui-même tout le flux, couplant tout le monde au format brut et démultipliant le code.

Forces

• Hétérogénéité des consommateurs aval. Le moteur de commandes, la comptabilité et le WMS sont souvent trois systèmes différents qui ne devraient pas se connaître mutuellement.
• Un seul point d'entrée transport. AS2 et SFTP sont souvent négociés une fois par partenaire — pas un point par message.
• Découplage temporel. Le router permet de bufferiser par canal, donc d'absorber des pics d'INVOIC sans bloquer les ORDERS.
• Évolutivité. Ajouter un nouveau type de message ne doit pas obliger à modifier les consommateurs existants.

Solution

Hohpe & Woolf (2003, EIP §109) définissent le Message Router comme un filtre stateless qui : (a) lit l'enveloppe ou un sous-ensemble des en-têtes, (b) évalue une règle de routage et (c) republie le message intact sur le canal cible. La règle peut être figée (table de routage) ou dynamique (calculée à partir des en-têtes). Le routeur ne consomme jamais le message au sens métier — il ne change rien.

┌────────────────────────┐
─── in ────▶│      Message Router    │
             │  (inspecte enveloppe)  │
             └──────────┬─────────────┘
                        │
       ┌────────────────┼────────────────┐
       │                │                │
       ▼                ▼                ▼
   canal A          canal B          canal C
(ORDERS)         (INVOIC)         (DESADV)

Topologie

Trois variantes courantes :

• Fixed Router. Une table de mapping {type → canal} embarquée dans la configuration. Simple, statique, déployée par release.
• Dynamic Router. La table est externe (base ou service de configuration). Permet d'ajouter un partenaire sans redéploiement.
• Recipient List. Variante multicast — le même message part vers plusieurs canaux (par exemple INVOIC vers la compta + le portail client + l'archivage légal).

Implémentation EDI

En EDIFACT la règle classique inspecte le segment UNH (Message Header) pour extraire le type (ORDERS, INVOIC, DESADV...). En X12 c'est l'élément ST01 qui porte le numéro de transaction (850, 810, 856). Une lecture des premiers 100 octets suffit : pas besoin de parser tout le fichier.

Filename                          Routing key       Channel
─────────────────────────────────────────────────────────────
ORD_WALMART_20260514_001.edi      UNH=ORDERS        orders.in
INV_CARREFOUR_20260514_007.edi    UNH=INVOIC        invoic.in
DES_AMAZON_20260514_022.edi       UNH=DESADV        desadv.in
ORD_X12_850.edi                   ST=850            orders.in
ACK_X12_997.edi                   ST=997            ack.in

En pratique, la table de routage croise trois clés typiquement : (a) émetteur (UNB S002 ou ISA06), (b) type de message (UNH ou ST01), (c) environnement (P/T flag de l'ISA ou compte logique EDIFACT). C'est ce qui permet à un même partenaire d'avoir des canaux différents prod et test.

Anti-patterns

• Routeur qui modifie. Si le composant transforme le message en chemin, ce n'est plus un router — c'est un Message Translator. Garder les deux responsabilités séparées (single responsibility).
• Règles cachées dans le code applicatif. Le routage doit être déclaratif (table, fichier de config). Un if/else en dur sur le type de message dans un service métier crée une dépendance qui empêchera d'ajouter un partenaire ultérieurement.
• Lecture intégrale du fichier. Le router ne doit lire que le minimum nécessaire (en-tête) pour décider. Parser tout le payload coûte du CPU inutilement et expose le routeur à des erreurs de syntaxe métier qui ne sont pas sa responsabilité.

Patterns liés

• Content-Based Router — quand la décision doit lire la charge utile.
• Splitter — quand un message composite doit être éclaté avant aiguillage.
• Dead Letter Channel — où va un message dont aucun canal de routage ne matche.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Message Router (§109). enterpriseintegrationpatterns.com — Message Router
• Apache Camel — Routing EIPs. La référence open-source de l'implémentation de ce pattern. camel.apache.org — EIP
• UN/EDIFACT — ISO 9735. Spécification du segment UNH qui porte le type de message — la clé de routage EDIFACT par convention.
• ASC X12 — 004010. Spécification de l'élément ST01 qui porte le numéro de transaction — la clé de routage X12.