Validateur cXML gratuit, conforme au DTD officiel.

Comment utiliser ce validateur cXML

1. Collez votre message cXML dans le champ de gauche, ou importez un fichier .xml / .cxml depuis votre disque (limite 500 Ko).
2. Cliquez sur Valider. Le validateur applique le DTD officiel cXML 1.2.070 sur votre message en quelques millisecondes.
3. Lisez le résultat. Si le message est valide, vous obtenez un score100%et le type de message détecté. Sinon, chaque erreur s'affiche avec son numéro de ligne et une explication en clair.

Erreurs cXML les plus fréquentes

Les messages cXML cassés viennent presque toujours d'une dérive lente entre l'implémentation côté acheteur (Ariba, Coupa, Oracle Procurement, etc.) et la spécification officielle. Voici les erreurs que ce validateur détecte le plus souvent :

• Élément manquant dans le Header. Le DTD impose la séquence stricte From, To, Sender. Oublier l'un d'entre eux casse toute la requête.
• Attribut payloadID ou timestamp absent sur cXML. Ces deux attributs racine sont obligatoires.
• Valeur operation hors enum sur PunchOutSetupRequest. Seules create, inspect, edit et source sont acceptées.
• Élément non déclaré dans le DTD. Souvent un attribut customisé ou une extension propriétaire qu'il faut encapsuler dans Extrinsic.
• Balises ouvrantes/fermantes qui ne correspondent pas. Typique d'un copier-coller incomplet entre Postman et un éditeur de texte.

Quels messages cXML pouvez-vous valider ?

Tous les messages prévus par le DTD officiel cXML 1.2.070. En pratique, voici les plus utilisés en intégration PunchOut et e-procurement :

• PunchOutSetupRequest / PunchOutSetupResponse - handshake d'ouverture de session catalogue.
• PunchOutOrderMessage - retour panier vers l'ERP acheteur.
• OrderRequest / ConfirmationRequest - la commande et sa confirmation.
• ShipNoticeRequest - l'avis d'expédition (ASN).
• InvoiceDetailRequest - la facture électronique.
• ProfileRequest / ProfileResponse - négociation des capacités.
• QuoteRequest / QuoteMessage - demande de devis, etc.

DTD cXML 1.2.070 - ce qui est vérifié

Notre validateur applique le DTD officiel cXML 1.2.070 publié par cxml.org en mode strict. Concrètement, il vérifie :

• La grammaire structurelle : éléments présents, dans le bon ordre, en cardinalité conforme (un seul Header, exactement un parmi Request/Response/Message).
• Les attributs requis sur chaque élément (payloadID, timestamp, domain, operation, etc.).
• Les valeurs énumérées sur les attributs typés.
• Le bon imbriquage des balises (well-formedness XML).

Ce que le validateur ne vérifie pas : la cohérence métier (un prix négatif, un BuyerCookie réutilisé, un Identity qui ne correspond pas à votre compte chez le fournisseur, etc.). Ces règles sont propres au métier et relèvent de l'intégration sortante.

Pour aller plus loin

• Codes d'erreur cXML - Référence complète des codes Status (200, 401, 406, 450, etc.) sourcée de la spec 1.2.070, plus 15 pièges fréquents hors codes (encoding, payloadID, SharedSecret).
• Validateur OCI - Le pendant pour le protocole OCI (SAP), avec règles PRICEUNIT, unités T006, indexation, etc.
• Guide complet de debug cXML - Codes Status 401, 450, 475, 500 : causes, méthode, résolution.
• Qu'est-ce que le cXML ? - Comprendre le protocole, son histoire et son rôle dans l'e-procurement B2B.
• cXML vs OCI - Les différences entre les deux standards PunchOut historiques.
• Setup Request vs retour panier - Les deux temps clés d'une session PunchOut.
• PunchOut Magento, ce qu'il faut planifier - Checklist d'intégration côté supplier.