Validateur ebMS 3.0 / AS4 (Message Service Handler)

Validateur d'enveloppe SOAP 1.2 portant un message ebMS 3.0 (UserMessage, SignalMessage Receipt / Error / PullRequest). Reconnaît AS4 Action, ebCore PartyId, et le catalogue d'erreurs EBMS:0001-0202. 100 % côté client.

Comment ça marche

ebMS 3.0 est la troisième génération du Message Service Handler OASIS pour la messagerie B2B asynchrone. Le profil AS4 (OASIS ebMS-3 Part 2) en restreint l'usage et est aujourd'hui imposé par plusieurs réseaux opérationnels majeurs en Europe :

• CEF eDelivery — infrastructure officielle de messagerie inter-gouvernementale de l'Union.
• ENTSO-E — TSOs électriques européens (Master Data, balancing, forecasts).
• eHealth Network — résumés patient et e-prescriptions cross-border.
• e-CODEX — procédures judiciaires cross-border européennes.
• OpenPEPPOL AS4 — Access Points de la facturation électronique.

Le format de transport est une enveloppe SOAP 1.2 dont l'en-tête porte un élément <eb:Messaging> (namespace http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/) contenant :

• Un <eb:UserMessage> — le canal des documents métier (Submit, Forward…) : MessageInfo, PartyInfo (From / To), CollaborationInfo (Service / Action / ConversationId), MessageProperties, PayloadInfo (PartInfo avec href cid: vers une pièce MIME).
• Ou un <eb:SignalMessage> — pour les signaux : Receipt (accusé non-répudiation NRR), Error (avec catégorie, sévérité, code EBMS), PullRequest (mode pull AS4).

Le pipeline du validateur :

1. Si l'entrée commence par des en-têtes MIME (multipart/related), extraction de la partie 0 (l'enveloppe SOAP).
2. Parsing XML (DOMParser côté navigateur, fast-xml-parser fallback).
3. Recherche de la racine <soap:Envelope> et de la version SOAP via le namespace.
4. Localisation de <eb:Messaging> dans le Header, puis discrimination UserMessage / SignalMessage.
5. Extraction des sous-éléments, lookups dans les codelists (PartyId types, AS4 actions, codes EBMS), détection WS-Security (ds:Signature, xenc:EncryptedData).
6. Application des règles ci-dessous.

Pourquoi un validateur AS4 ?

Un Access Point AS4 (Axway, IBM, Holodeck B2B, Domibus…) renvoie en général une erreur EBMS:NNNN générique quand un message entrant ne lui plait pas, sans expliciter quel champ de l'enveloppe pose problème. Ce validateur vise à :

• Vérifier rapidement la structure d'un message capturé en production avant de le rejouer.
• Reconnaître les 30 codes EBMS les plus fréquents de l'Annex C (catégorie, sévérité, libellé court).
• Distinguer un Receipt NRR d'un PullRequest et d'un Error sans rentrer dans Domibus.
• Détecter la présence — pas la validité cryptographique — d'une signature WSSE ou d'un EncryptedKey.
• Dé-emballer un body multipart MIME pour vérifier que les cid: du PayloadInfo correspondent bien aux MIME parts annexées.

Règles vérifiées

• SOAP version : l'enveloppe doit déclarer le namespace http://www.w3.org/2003/05/soap-envelope (SOAP 1.2). Une enveloppe SOAP 1.1 déclenche un avertissement (ebMS 3.0 / AS4 impose explicitement SOAP 1.2 sur le wire).
• eb:Messaging : présent dans <soap:Header>, avec soap:mustUnderstand="true" (avertissement sinon).
• UserMessage — MessageInfo/Timestamp (xsd:dateTime), MessageInfo/MessageId (format RFC 2822, avertissement sinon), PartyInfo/From/PartyId et PartyInfo/To/PartyId, CollaborationInfo/Service et CollaborationInfo/Action. Un ConversationId manquant est un avertissement.
• SignalMessage — MessageInfo obligatoire, au moins un de Receipt / Error / PullRequest. Un RefToMessageId est recommandé sur un Receipt.
• PayloadInfo : chaque PartInfo doit porter un attribut href au format cid: ou #fragment. Un href absent ou d'un autre schéma déclenche un avertissement.
• Errors : un code EBMS:NNNN non catalogué déclenche un avertissement ; une catégorie hors {Content, ProcessingMode, Communication, Unpackaging, InternalError} déclenche également un avertissement.
• PartyId types : un type ebCore URN non bundlé déclenche un info-diagnostic — utile en intégration pour repérer un type d'identifiant non standardisé.

Catalogue d'erreurs EBMS (Annex C)

Le validateur reconnaît les 30 codes les plus fréquents de l'Annexe C du profil AS4. L'absence d'un code n'est pas bloquante : une erreur EBMS personnalisée d'un Access Point sera surfacée avec un avertissement W_UNKNOWN_AS4_ERROR.

Actions AS4 reconnues

Le validateur reconnait 20 valeurs courantes de <eb:Action> couvrant les principaux réseaux opérationnels européens. Une valeur non reconnue déclenche un info-diagnostic.

• Acceptance — e-CODEX — Acceptance (e-CODEX)
• Delivery — e-CODEX — Delivery (e-CODEX)
• Forward — eHealth Network — Forward (eHealth Network)
• GenerationForecast — ENTSO-E — Generation Forecast (ENTSO-E)
• http://docs.oasis-open.org/ebxml-msg/as4/200902/action — AS4 conformance action (default) (OASIS AS4)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay.receive — ebMS 3.0 One-Way Receive (OASIS ebMS 3.0)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay.submit — ebMS 3.0 One-Way Submit (OASIS ebMS 3.0)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay.submit — ebMS 3.0 Two-Way Submit (OASIS ebMS 3.0)
• http://docs.peppol.eu/edelivery/as4/action — PEPPOL AS4 — default action (OpenPEPPOL)
• ImbalancePrice — ENTSO-E — Imbalance Price (ENTSO-E)
• MasterDataReport — ENTSO-E — Master Data Report (ENTSO-E)
• Notify — EU CEF eDelivery — Notify (CEF eDelivery)
• Receive — EU CEF eDelivery — Receive (CEF eDelivery)
• RelayREMMDAcceptanceRejection — e-CODEX — Relay REMMD Acceptance / Rejection (e-CODEX)
• Retrieval — e-CODEX — Retrieval (e-CODEX)
• Submit — EU CEF eDelivery — Submit (CEF eDelivery)
• TC1Leg1 — AS4 conformance — TC1 Leg 1 (OASIS AS4 conformance)
• TC2Leg1 — AS4 conformance — TC2 Leg 1 (OASIS AS4 conformance)
• TransmissionRights — ENTSO-E — Transmission Rights (ENTSO-E)
• urn:oasis:names:tc:ebcore:test:01:01 — ebCore conformance test action (OASIS ebCore)

Limites

• Pas de validation XSD complète de l'enveloppe — uniquement les règles listées ci-dessus. Les schémas officiels ebms-header-3_0-200704.xsd et ebbp-signals-2.0.xsd sont stricts sur quelques cardinalités secondaires que nous ne couvrons pas.
• Pas de vérification cryptographique — le validateur détecte la présence d'une ds:Signature ou d'un xenc:EncryptedData, mais ne valide ni la signature ni les certificats. Pour cela, passez par votre PKI d'entreprise ou par un outil tel que Domibus / Holodeck.
• Pas de validation du PMode — le mapping vers le Processing Mode (PMode) configuré sur votre Access Point n'est pas vérifié. Une Service / Action conforme à OASIS n'est pas forcément acceptée par votre passerelle.
• Pas de validation du payload wrappé — si le contenu est une facture UBL, passez-la par Validateur UBL 2.1 ou Validateur PEPPOL en aval.

Confidentialité

Documentation associée

• OASIS ebMS 3.0 Core (PDF) — la spécification de référence (sections 5 message structure, 6 security, 6.7 error reporting).
• OASIS AS4 Profile v1.0 (PDF) — le profil restrictif AS4 et son Annex C (catalogue d'erreurs EBMS:0001-0202).
• CEF eDelivery (Commission européenne) — la documentation officielle de l'infrastructure CEF AS4.
• PEPPOL AS4 Specification — le profil AS4 utilisé sur le réseau OpenPEPPOL.