Normalizer

Quand plusieurs partenaires envoient des messages dans des formats différents pour décrire le même concept métier (une commande), le Normalizer est le composant qui détecte le format de chaque entrée et oriente vers le Message Translator approprié. C'est la porte d'entrée canonique d'un hub d'intégration.

Problème

Une plateforme EDI moderne reçoit des ORDERS sous 4-5 formats différents selon le partenaire : EDIFACT D.96A pour les fournisseurs européens historiques, X12 850 pour les fournisseurs nord-américains, cXML pour les acheteurs sur Coupa, UBL pour les flux PEPPOL, IDoc pour les intégrations SAP point à point. Toutes ces variantes représentent la même information métier — une commande — mais sont structurellement incompatibles. Sans normalisation en amont, chaque consommateur de commandes (CRM, ERP, WMS) devrait connaître les 5 formats.

Forces

• Hétérogénéité des sources. Aucun partenaire ne changera son format pour s'aligner sur les autres. La normalisation doit être absorbée en interne.
• Détection légère. Pour des raisons de performance et de fiabilité, la détection doit reposer sur les premiers octets — pas sur un parse complet.
• Extensibilité. Ajouter un nouveau format (par exemple OAGIS BOD) doit se faire sans toucher au reste du pipeline.
• Canonical first. Le pipeline aval doit voir une seule structure — le canonique. Tout le reste est du nettoyage en amont.

Solution

EIP §352 (Hohpe & Woolf, 2003) modélise le Normalizer comme la composition de deux composants : un Content-Based Router qui détecte le format, suivi d'un Message Translator spécifique par format. La sortie de tous les translators est un seul et même modèle canonique. Le reste du pipeline (validation, idempotence, routage métier) n'a plus qu'un seul schéma à connaître.

EDIFACT ──┐
              │     ┌────────────────┐
   X12     ──┼───▶ │   Normalizer   │
              │     │  (detect +     │   ┌─────────────────┐
   cXML    ──┤     │   route by    │──▶│  Canonical JSON │
              │     │   format)     │   └─────────────────┘
   UBL     ──┤     └────────────────┘
              │              │
   IDoc    ──┘              ▼
                  ┌────────────────────────────────┐
                  │ Specific translator per format │
                  │  - edifact-translator           │
                  │  - x12-translator               │
                  │  - cxml-translator              │
                  │  - ubl-translator               │
                  │  - idoc-translator              │
                  └────────────────────────────────┘

Topologie

Trois variantes :

• Sniffer-based. Détection par lecture des premiers octets. Rapide, mais peut être trompée si le format est ambigu (JSON peut décrire un Order ou un Invoice).
• Header-based. Détection par en-tête de transport (HTTP Content-Type, SMTP Subject, métadonnée AS2). Plus fiable mais nécessite que l'émetteur soit discipliné.
• Schema-detection. Combinaison : détection grossière par sniffer, puis confirmation par validation XSD/JSON Schema. Plus robuste mais plus coûteuse.

Détection de format

La détection canonique fait sniffing sur les premiers 100 octets et croise avec l'en-tête de transport quand disponible :

Bytes 0..3   Indication                         Verdict
─────────────────────────────────────────────────────────────────
"UNB+"       segment EDIFACT                     EDIFACT
"UNA:+"      service advice EDIFACT              EDIFACT
"UNH+"       message header (interchange unique) EDIFACT
"ISA*"       segment X12                         X12
"<cXML"      racine cXML                         cXML
"<Invoice"   racine UBL (avec ns)                UBL
"<Order"     racine UBL                          UBL
"BEGIN_OF"   IDoc texte SAP                      SAP IDoc
"{"          JSON                                JSON
"<?xml"      XML générique, à approfondir        XML undetermined

Note technique : EDIFACT autorise un segment service advice UNA optionnel avant UNB qui redéfinit les séparateurs (par défaut :, +, ', ?, .). Le sniffer doit accepter les deux préfixes UNA et UNB.

Implémentation EDI

Trois choix d'architecture en production :

• Une queue d'entrée unique + Normalizer. Tout message arrive sur inbox.raw. Le Normalizer émet sur inbox.canonical après traduction. Simple, lisible.
• Une queue par format + topic canonique. Les adapters de transport déposent dans inbox.edifact, inbox.x12, etc. ; les translators consomment leur queue et publient sur canonical.order. Plus de couplage, mais aussi plus de granularité de scaling.
• Adapter pattern + canonical broker. Chaque format a son adapter complet (transport + parse + translate). Tous publient sur un canonical broker. C'est la décomposition canonique des iPaaS modernes (MuleSoft, Boomi, SAP CPI).

Anti-patterns

• Détection fragile sur extension de fichier. Le partenaire qui nomme son fichier .edi mais y met du XML casse tout. Le sniffer doit toujours lire le contenu.
• Pas de canonical par défaut sur erreur. Si la détection échoue (format inconnu), un Dead Letter Channel doit recevoir le payload pour examen humain — jamais d'abandon silencieux.
• Translators couplés. Chaque translator doit être indépendant : le translator EDIFACT ne doit rien partager avec le translator X12. Un bug dans l'un ne doit pas en propager.
• Validation après normalisation seulement. La validation syntaxique du format source (CONTRL, 997) doit avoir lieu avant la traduction, pour que l'émetteur soit notifié de l'erreur dans son propre format.

Patterns liés

• Canonical Model — la cible de toutes les traductions.
• Message Translator — le composant invoqué par le Normalizer pour chaque format.
• Claim Check — pour conserver le payload original sans dupliquer.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Normalizer (§352). enterpriseintegrationpatterns.com — Normalizer
• Apache Camel — Normalizer EIP, implémentation de référence. camel.apache.org — Normalizer
• ISO 9735 §4.1. Définition du segment UNA Service String Advice et de la détection EDIFACT.
• MuleSoft — Anypoint Platform, documentation de la DataWeave Sniffer et patterns d'iPaaS.