Intégration B2B avec Anypoint Partner Manager & X12 EDI (Course #b2b-edi)
For développeurs d'intégration, spécialistes B2B/EDI, responsables SI supply chain, architectes de solution.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de piloter un programme partenaires sur Anypoint Partner Manager — profils partenaires onboardés, message flows X12, acquittements réconciliés et runbook de rejeu — afin que chaque document B2B ait un propriétaire, un statut et un remède traçables.
Cas fil rouge
Havenmark Distribution achemine des produits alimentaires et d'entretien pour 260 enseignes dans 9 pays et échange environ 38 000 documents X12 par jour — 850, 855, 856, 810 — via un broker VAN vieux de 14 ans dont plus personne dans la maison ne sait relire les mappings. L'onboarding technique d'un nouveau partenaire prend 6 semaines, 4,1 % des interchanges entrants meurent sur des erreurs d'enveloppe qui n'apparaissent qu'à l'arrivée des pénalités enseignes, et les 997 restent des jours sans réconciliation. Cibles : onboarding partenaire sous 5 jours, arriéré d'interchanges non acquittés résorbé en 24 heures, rejeu d'un document en échec en moins de 15 minutes.
Programme chaque ligne est quelque chose que vous faites
5 modules · 15 sujets · dans l'ordre du cours
-
Module 1
Des partenaires, pas des dépôts de fichiers
Objectif. Diagnostiquer le patrimoine B2B de Havenmark et produire le plan d'onboarding technique sur lequel basculer un premier partenaire.
- Modéliser le graphe d'objets Partner Manager — profil partenaire, identifiants, endpoints, message flows — pour 3 partenaires couvrant les transports AS2, SFTP et HTTPS
- Déclarer les identifiants d'interchange (couples qualifiant ISA05/ISA06, codes applicatifs GS02/GS03) pour que le routage s'appuie sur la combinaison ISA + type de message, et non sur des conventions de nommage de fichiers
- Ramener l'onboarding technique de 6 semaines à moins de 5 jours grâce à un modèle de partenaire réutilisable et une checklist de mise en service contresignée par le partenaire
-
Module 2
Les transaction sets qui portent la commande
Objectif. Concevoir le catalogue de types de documents du cycle order-to-cash et rattacher chaque transaction set à un contrat applicatif.
- Parcourir la chaîne order-to-cash — bon de commande 850, accusé 855, avis d'expédition 856, facture 810 — en nommant le système de référence propriétaire de chaque étape
- Appairer chaque set X12 avec son équivalent EDIFACT (ORDERS, ORDRSP, DESADV, INVOIC) pour les 3 enseignes européennes qui refusent X12
- Figer une version de schéma par partenaire — 005010 comme socle maison, 004010 pour 40 partenaires historiques — et consigner chaque écart dans le profil partenaire
-
Module 3
Message flows, de bout en bout
Objectif. Construire les message flows entrants et sortants qui traduisent les documents partenaires en contrats applicatifs, validés étape par étape sur des endpoints réels.
- Bâtir le flux entrant : endpoint Receive from Partners → X12 850 → map de traduction DataWeave → Target at Host, en validant chacune des 4 étapes avant déploiement
- Bâtir le miroir sortant : Source at Host (JSON) → map → X12 810 → Send to Partners via AS2, en tenant les interchanges sous le plafond de 15 MB par fichier du X12 EDI Connector 2.19
- Dimensionner la mémoire runtime sur le ratio fichier/RAM d'environ 40:1 du connecteur — un interchange de 12 MB réclame quelque 480 MB — et découper les lots trop gros avant que la production ne s'en charge
-
Module 4
Des acquittements vraiment réconciliés
Objectif. Évaluer les paramètres d'acquittement de tout le patrimoine et livrer une vue de réconciliation qui fait vieillir chaque interchange non acquitté.
- Régler Expect functional acknowledgement (X12 997) ou Expect CONTRL functional acknowledgement (EDIFACT) flux par flux, avec Mark overdue after aligné sur le SLA — 24 heures par défaut, 4 heures pour les 12 enseignes tier-1
- Arbitrer 997 contre 999 contre TA1 partenaire par partenaire : acquitter chaque transaction en AK2/AK5, ou ne remonter que les erreurs en AK3/IK3 et garder un payload de retour léger
- Ramener à zéro en 24 heures l'arriéré non acquitté en faisant vieillir les transmissions sur Acknowledgment status = Overdue et en attribuant un propriétaire à chacune
-
Module 5
Interchanges en échec, triés et rejoués
Objectif. Arbitrer la sévérité de validation face à la réalité des partenaires et produire le runbook de tri et de rejeu qui réveillera l'exploitation.
- Régler les contrôles — limites de longueur, ordre des segments, répétitions, jeux de codes, règles conditionnelles — en tranchant partenaire par partenaire ce qui échoue durement et ce qui se contente d'être journalisé (cible : rejets d'enveloppe de 4,1 % à moins de 0,5 %)
- Rejeter les doublons rejoués sur l'unicité ISA13, GS06 et ST02, en dimensionnant le store de numéros de contrôle face à son time-to-live par défaut de 30 jours et à votre rétention d'audit
- Trier dans Tracking par partenaire, direction, statut de traitement et statut de rejeu, puis rejouer une transmission en échec en prouvant que l'Original Transmission Id reste relié — le tout en moins de 15 minutes
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Composants d'un flux de messagesDoc MuleSoft
- Identifiants d'expéditeur et de destinataireDoc MuleSoft
Module 2
Module 3
- Types de messagesDoc MuleSoft
- X12 EDI Connector 2.19Doc MuleSoft
Module 4
- Créer des flux de messages sortantsDoc MuleSoft