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.

Content-Based Router

Quand la règle d'aiguillage ne se lit pas dans l'enveloppe mais dans le contenu : pays de livraison, montant total, devise, type de transport demandé. Le pattern qui transforme la sémantique métier en destination logique.

Problème

Toutes les ORDERS arrivent dans le même canal d'entrée mais doivent être traitées différemment selon leur contenu : une commande à livrer en Allemagne va à l'entrepôt de Berlin, une commande aux USA part vers le centre du New Jersey, une commande dont le montant dépasse 50 000 € doit passer par une validation manuelle avant intégration. Le Message Router standard, qui lit uniquement le type de message dans l'enveloppe, ne suffit plus.

Forces

  • La sémantique métier est dans la charge utile. Le pays, le montant, la priorité, ce sont des éléments business — pas des en-têtes de transport.
  • Volume vs latence. Lire la charge utile coûte plus cher que lire l'enveloppe (parse partiel ou total). Le routeur de contenu doit néanmoins rester rapide pour ne pas devenir un goulet.
  • Évolutivité des règles. Les règles métier changent souvent (nouveau seuil, nouveau pays). Elles doivent être configurables sans redéploiement.
  • Single responsibility. Le routeur prend une décision — il ne traite pas. La transformation et l'intégration sont en aval.

Solution

EIP §230 (Hohpe & Woolf, 2003) prescrit : parse partiel du message juste assez profond pour extraire les champs de décision, application de règles déclaratives (DSL ou base de règles), republication sur le canal cible. La règle doit être pure — pas d'appel externe en synchrone, sinon on ré-introduit du couplage temporel.

plaintext topology.txt
┌─────────────────────────┐
ORDERS ────────▶│  Content-Based Router   │
                │  (lit NAD+ST, MOA+86)   │
                └──────────┬──────────────┘

        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
   warehouse-EU       warehouse-US       warehouse-APAC
   (pays = DE/FR)     (pays = US)        (pays = JP/KR)

Topologie

Deux décompositions courantes :

  • Single content router. Un seul composant lit le payload et tranche. Simple, lisible — mais le composant grossit avec les règles.
  • Chained predicates. Une chaîne de petits filtres (EIP §253 Message Filter), chacun avec sa règle, son canal de sortie. Plus modulaire, plus facile à tester unitairement, mais plus coûteux en parse répété. Mitigation : parser une fois, passer le résultat structuré le long de la chaîne.

Implémentation EDI

Trois exemples concrets :

  • Routage géographique sur ORDERS EDIFACT. La règle lit NAD+ST (Ship-To) et compose le canal cible. Le qualifieur de pays se trouve en position 8 du composite C817 (pays de l'adresse de livraison).
  • Validation manuelle au-delà d'un seuil. La règle lit MOA+86 (Message total amount) et compare au seuil contractuel. Si dépassé, le message part sur un canal orders.manual-approval au lieu du canal automatique.
  • Routage X12 par TD5. Sur un 856 ASN, l'élément TD5 (Carrier Details) sert à aiguiller vers le module logistique correspondant au transporteur — FedEx, UPS, DHL.
edifact orders-with-ship-to.edi
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+PO-12345+9'
DTM+137:20260514:102'
NAD+BY+8712345600014::9'
NAD+SU+5412345600015::9'
NAD+ST+8712345700421::9+++Berliner Hauptstrasse 12+Berlin++10117+DE'
LIN+1++4006381333931:EN'
QTY+21:24:PCE'
MOA+86:14500:EUR'
UNT+9+1'

Lecture : dans cet ORDERS, le NAD+ST donne un Ship-To avec adresse Berlin et code pays DE. Le content-based router émet sur warehouse-eu.orders.in. Le MOA+86:14500:EUR indique 14 500 € — sous le seuil de validation manuelle (50 000) — donc pas de bifurcation supplémentaire.

Anti-patterns

  • Lecture externe synchrone. Une règle qui appelle un service de référentiel (par exemple pour résoudre un GLN en pays) au moment du routage transforme le router en couplage temporel — si le référentiel est down, le routage l'est aussi. Si on a besoin d'enrichir, le faire en amont (cf. Content Enricher), pas dans la règle de routage.
  • Règles imbriquées illisibles. Plus de 3 niveaux de conditions sur le même contenu = signe qu'il faudrait scinder en plusieurs Message Filter. Préférer une chaîne plate.
  • Pas de canal par défaut. Si aucune règle ne matche, il faut un canal explicite (Default Channel) qui aboutit à la Dead Letter Channel. Ignorer silencieusement un message non-routable est la pire pratique.

Patterns liés

  • Message Router — le pattern de base ; le content-based router en est une spécialisation.
  • Content Enricher — pour ajouter des champs manquants avant le routage.
  • Splitter — souvent appliqué en aval pour traiter chaque ligne séparément.

Sources

  • Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Content-Based Router (§230). enterpriseintegrationpatterns.com — Content-Based Router
  • Apache CamelContent-Based Router, l'une des EIP les plus utilisées dans la pile open-source. camel.apache.org — Choice EIP
  • EANCOM 2002 — segment NAD. Spécification du Ship-To et de ses qualifieurs géographiques.
  • ASC X12 — TD5 Carrier Details. Source canonique du routage par transporteur sur les 856.