ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

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.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Format Indicator

Un message qui ne dit pas qui il est rend impossible la coexistence de plusieurs versions. Le pattern Format Indicator demande au message d'auto-déclarer son format et sa version, dès la première ligne.

Problème

Un hub EDI reçoit en continu des messages issus de partenaires qui n'ont pas tous adopté la même version : Walmart est encore en X12 004010, Costco a migré en 005010, une chaîne européenne envoie en EDIFACT D.96A pendant qu'une autre est passée en D.24A. Comment le hub sait-il quel parser utiliser sans agréger un annuaire par partenaire ? Et que se passe-t-il quand un partenaire change silencieusement de millésime entre deux envois ?

Forces

  • Coexistence de millésimes. Aucun standard EDI ne remplace ses versions du jour au lendemain : 4010, 5010 et 6020 coexistent dans la même DMZ pendant des années.
  • Changements unilatéraux. Un partenaire peut migrer sa version sans préavis dans le sens où ses systèmes le supportent ; le hub doit suivre, pas casser.
  • Échecs silencieux. Sans format indicator, un parser 4010 lit un 5010 « à peu près » — les nouveaux segments sont ignorés ou plantent silencieusement. Les pires bugs EDI.
  • Inspection sans contexte. Un opérateur qui ouvre un fichier dans la file d'archive doit savoir à quel format il fait face, sans lire la convention bilatérale.

Solution

EIP §180 (Hohpe & Woolf, 2003) prescrit : chaque message porte, dans une zone très en amont du payload, un indicateur explicite de format et de version. Le récepteur lit cet indicateur en premier, sélectionne le parser approprié, et seulement ensuite consomme le reste du payload. Le pattern est si fondamental qu'il est encodé dans tous les standards EDI sérieux.

EDIFACT — UNH S009

Le segment UNH (Message Header) commence par un composite S009 — Message Identifier qui porte : type de message (ORDERS), numéro de version (D), release (96A), agence contrôlante (UN), et code d'association optionnel (EAN008 pour EANCOM, etc.). C'est le format indicator canonique d'EDIFACT — il dit en quatre champs exactement quel dictionnaire de segments utiliser.

edifact orders-d96a.edi 
UNB+UNOC:3+SENDER:14+RECEIVER:14+260514:1545+ORD202605140001'
UNH+1+ORDERS:D:96A:UN:EAN008'
... segments ORDERS ...
UNT+12+1'
UNZ+1+ORD202605140001'

X12 — GS08 et ISA12

En X12, deux indicateurs coexistent. ISA12 (Interchange Control Version Number) déclare la version de la syntaxe d'enveloppe (00401, 00501) — c'est la grammaire ISA / IEA elle-même. GS08 (Version / Release / Industry Identifier Code) déclare la version des transaction sets dans le groupe (004010, 005010X222A1 pour le 837 HIPAA). Un même interchange peut, en théorie, contenir plusieurs groupes en versions différentes.

x12 x12-version-indicators.x12 
ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID    *260514*1545*U*00401*900042001*0*P*>~
GS*PO*SENDERID*RECEIVERID*20260514*1545*42*X*004010~
ST*850*0001~
...
SE*42*0001~
GE*1*42~
IEA*1*900042001~

Lecture : ISA12 = 00401 dit « syntaxe d'enveloppe 4010 ». GS08 = 004010 dit « transaction sets 4010 ». Une suite HIPAA porterait 005010X222A1 qui encode aussi le sous-profil industriel.

UBL / cXML — namespace et version

Côté XML, le format indicator est porté par le namespace XML et un attribut version explicite. Une facture UBL déclare son namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 avec UBLVersionID et CustomizationID (par exemple urn:cen.eu:en16931:2017 pour PEPPOL BIS 3.0). cXML déclare sa version dans l'attribut version de l'élément racine.

xml cxml-1.2.069.xml 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML xmlns:xml="http://www.w3.org/XML/1998/namespace"
      payloadID="20260514@partner-a"
      timestamp="2026-05-14T15:45:00-05:00"
      version="1.2.069">
  ...
</cXML>

AS2 / AS4 — Content-Type et Service

En transport, AS2 (RFC 4130) utilise le MIME Content-Type pour indiquer le format applicatif : application/EDI-X12, application/EDIFACT, application/xml. AS4 (OASIS ebMS3) va plus loin avec eb:Service et eb:Action qui encodent un identifiant de service business (busdox:noprocess en PEPPOL) — un format indicator de granularité fine, lu par le routeur AS4 avant même l'inspection du payload.

Anti-patterns

  • Format implicite par canal. « Tout ce qui arrive sur /edi/inbound/x12 est en X12 4010 ». Faux dès que le partenaire migre : le hub plante en silence ou ignore les nouveaux segments.
  • Sniffing du contenu. Détecter X12 vs EDIFACT en regardant les premiers octets fonctionne pour le standard mais pas pour la version. Un sniffer ne distingue pas un 4010 d'un 5010 — le format indicator déclaratif est plus fiable.
  • Ignorer le format indicator. Tous les standards le portent. L'ignorer pour gagner trois lignes de code revient à réinventer le pattern par-dessus, avec moins de robustesse.
  • Incohérence Content-Type vs payload. Un AS2 application/EDI-X12 qui contient du JSON est un bogue silencieux côté émetteur ; le récepteur doit valider la cohérence et alerter si elle est rompue.

Patterns liés

  • Normalizer — consomme le Format Indicator pour choisir le Translator approprié.
  • Message Translator — convertit d'un format vers un autre, identifié par les indicators.
  • Content-Based Router — peut router en fonction du format indicator, pas seulement du contenu.
  • Message History — devrait conserver les indicateurs de format à chaque étape pour l'audit.

Sources