Mapping

L'artefact qui matérialise le 'BTNR du 850 X12 correspond au BGM01 de l'ORDERS EDIFACT' — sans lui, pas d'intégration partenaire.

Problème

Un même concept métier (PO number, GLN, currency) porte des noms et des positions différentes selon le standard partenaire. Comment matérialiser ces correspondances de manière auditable et réutilisable ?

Forces

• Les mappings doivent vivre comme code (versionnés, testés, déployés).
• Un même champ source peut alimenter plusieurs champs cibles (split / fan-out).
• Les défauts, transformations (uppercase, padding, lookup) doivent être explicites.
• Un mapping doit être testable par des fixtures bilatérales.

Solution

Définir le mapping dans un format structuré : (1) XSLT pour XML→XML, (2) DataWeave (MuleSoft) ou JSLT/jq (JSON→JSON), (3) Smooks / FreeMarker pour EDIFACT/X12. Chaque règle a une source, une cible, un transform optionnel, et un fallback. Le mapping est versionné en Git, testé via fixtures (input.x12 + expected.json), et déployé comme artefact distinct du code applicatif. Le pattern Canonical Model en dépend fortement : N mappings vers le canonique au lieu de N×N entre formats.

Implémentation EDI

En EDI, un mapping typique relie un ORDERS EDIFACT D.96A à un canonical `Order` JSON : `BGM[1010] → order.number` ; `NAD+BY[3035=BY]/3039 → order.buyer.gln` ; `DTM+137 → order.documentDate (yyyymmdd → ISO 8601)`. Outils courants : IBM DataPower XI52, Software AG webMethods Mapper, Apache Camel marshal/unmarshal avec data formats, ou des libs custom Smooks. Chaque mapping doit avoir des fixtures Walmart-realistic et Stellantis-realistic à minima.

Anti-patterns

• Mapping dans du code Java/Python pur — non testable indépendamment, change requires redeploy.
• Mapping sans fixtures — toute évolution casse silencieusement la prod.
• Mapping qui assume des défauts implicites du parseur — refactoring du parseur casse la prod.
• N×N mappings au lieu d'un canonical model — explosion combinatoire.

Patterns liés

• Message Translator — moteur d'application du mapping.
• Canonical Model — schéma cible pivot.
• Normalizer — router qui choisit le mapping.

Sources

• Hohpe G., Woolf B. — EIP, Message Translator (p. 85) (Mapping is the base-level abstraction). www.enterpriseintegrationpatterns.com/patterns/messaging/MessageTranslator.html
• MuleSoft — DataWeave language guide. docs.mulesoft.com/dataweave/