Un fournisseur qui découvre le punch-out pense d’abord à une connexion à brancher entre son site et l’outil d’achat de son client. Il découvre vite que brancher revient à parler une langue, et qu’il en existe deux : cXML et OCI. Chacune fixe ce que le site doit répondre, dans quel ordre, avec quels champs. Et le choix ne revient presque jamais au fournisseur.
Nous avons déjà expliqué le fonctionnement et enjeux du punch-out pour le fournisseur et répondu à la question Qu’est-ce que le Punch Out. Cet article s’intéresse à un point précis : ce que chaque protocole échange réellement, ce qu’il impose au site du fournisseur, et comment décider quoi implémenter, dans quel ordre. Il s’adresse aux équipes e-commerce, aux responsables techniques et aux directions commerciales des fournisseurs B2B.
Le principe du punch-out est le même dans les deux cas. L’acheteur part de son outil d’achat, arrive sur le catalogue du fournisseur, remplit un panier, puis le renvoie à son outil sans passer par le paiement. Le panier devient une demande d’achat, qui suit les validations de l’entreprise cliente avant de se transformer en commande.
Ce qui distingue cXML et OCI, c’est la manière dont cet aller-retour s’exécute. Le premier échange des messages structurés en XML. Le second fait circuler des champs de formulaire HTTP. La différence paraît technique. Elle a des conséquences très concrètes sur la sécurité, sur l’identification des utilisateurs et sur ce que le protocole sait faire après le panier. C’est la logique de l’achats indirects : la commande doit rester dans le circuit de l’acheteur.
cXML, pour commerce eXtensible Markup Language, est le standard popularisé par Ariba à la fin des années 1990. Sa spécification est publiée sur cxml.org, et le guide d’utilisation cXML en détaille tous les éléments. Une session de punch-out repose sur trois messages.
D’après la documentation d’Unimarket, la demande de départ contient un en-tête avec l’expéditeur, le destinataire et un identifiant d’authentification accompagné d’un secret partagé. Elle transporte aussi un BuyerCookie, qui identifie la session de l’acheteur, l’adresse de retour du panier (BrowserFormPost) et parfois des éléments complémentaires, appelés Extrinsic, comme le nom ou l’e-mail de l’utilisateur. Le fournisseur authentifie la demande, crée sa session et renvoie l’adresse de la page de départ. La session de navigation de l’acheteur ne se crée qu’à sa première visite sur cette adresse.
Quand l’acheteur a terminé, le fournisseur construit un PunchOutOrderMessage. Il reprend le BuyerCookie d’origine, inverse les champs From et To, indique le total avec sa devise, puis décrit chaque ligne : quantité, numéro de ligne, référence fournisseur, prix unitaire, description, unité de mesure et code de classification. Ce message est soumis depuis le navigateur de l’acheteur, vers l’adresse de retour reçue au départ, avec le paramètre cxml-urlencoded. Il part du navigateur et non du serveur, pour conserver les cookies de la session.
Quatre éléments de la demande de départ sont à garder avec la session : le BuyerCookie, l’adresse de retour, ainsi que les champs From et To. Sans eux, le panier ne peut pas être reconstruit. Un oubli à cet endroit explique une grande partie des tests qui échouent.
cXML ne s’arrête pas au catalogue. Selon Optimizely, le protocole prévoit aussi la commande d’achat, qui transmet au fournisseur la commande formalisée après approbation. Toutes les intégrations n’emploient pas les trois interfaces, et la commande peut passer par l’échange de données informatisé (EDI) à la place. Cette continuité jusqu’à la commande, parfois jusqu’à la facture, est ce qui rend cXML plus complet que OCI.
OCI, pour Open Catalog Interface, est l’interface de catalogue de SAP, utilisée surtout avec SAP SRM. Selon Tradecentric, le catalogue du fournisseur s’affiche dans l’outil de l’acheteur, souvent dans un cadre intégré, et le panier revient automatiquement.
L’acheteur déclenche la session depuis son navigateur. D’après PunchOut Commerce, la requête de connexion est le plus souvent une requête HTTP POST. Elle contient obligatoirement une adresse de retour, appelée HOOK_URL, et généralement un identifiant et un mot de passe, dont les noms de paramètres se configurent acheteur par acheteur. Un paramètre facultatif, ~TARGET, indique la cible du formulaire quand l’outil d’achat affiche le catalogue dans un cadre. Le fournisseur doit enregistrer HOOK_URL et ~TARGET avec la session.
Le panier retourne dans un formulaire HTML dont l’action pointe vers HOOK_URL. Chaque champ suit le modèle NEW_ITEM-NOM[numéro de ligne], par exemple NEW_ITEM-DESCRIPTION[3]. Les champs principaux sont les suivants :
Ces longueurs sont celles que publie PunchOut Commerce. D’autres sources donnent des limites différentes pour la description selon la version d’OCI : il faut donc confirmer chaque limite avec la documentation SAP ou avec l’équipe du client. À titre indicatif, OCI prévoit jusqu’à quarante champs par ligne, mais la plupart des intégrations en utilisent sept à quinze.
OCI couvre le catalogue et le panier, pas la suite. La commande, la confirmation, l’avis d’expédition et la facture ne font pas partie de la spécification. Autre limite relevée par Tradecentric : le mode de connexion par défaut utilise un identifiant partagé pour tous les acheteurs d’une même organisation, ce qui peut provoquer des conflits de panier quand plusieurs personnes se connectent en même temps. La version 5.0 d’OCI ajoute la prise en charge du format JSON.
Comme nous l’écrivions dans l’article sur le punch-out, le fournisseur choisit rarement entre les deux protocoles. Le choix découle de l’outil d’achat de ses clients. Un client sur SAP SRM demandera OCI. Un client équipé d’une plateforme d’achat plus répandue demandera le plus souvent cXML : selon Tradecentric, cXML est le protocole le plus répandu parmi les plateformes d’e-procurement, alors qu’OCI reste centré sur SAP. Pour comprendre à quoi ressemble l’outil de l’acheteur, voir notre guide de la plateforme e-procurement.
La conséquence est simple. Un fournisseur qui vend à plusieurs grands comptes finit presque toujours par devoir prendre en charge les deux. Mieux vaut le savoir avant de dimensionner le projet. Le cas de {CASE} et de Best Western, où un catalogue e-procurement est construit pour un réseau hôtelier, montre ce que cette démarche donne sur un projet réel.
La plupart des échecs de test viennent de détails, pas de la conception générale. Les plus fréquents :
Plusieurs de ces pièges reviennent au même sujet : la qualité du catalogue. Notre article sur l’intégration de catalogues montre pourquoi des données propres décident de la réussite avant même le protocole.
Listez, pour vos dix à vingt premiers clients, l’outil d’achat utilisé et le protocole attendu. Le résultat décide du périmètre : cXML seul, OCI seul, ou les deux.
Implémentez d’abord celui qui couvre la plus grande part de vos clients. Pour le second, une passerelle qui convertit OCI vers cXML peut éviter de développer deux chaînes distinctes. PunchOut Commerce recommande cette approche pour un site déjà compatible cXML.
Pour chaque article, fixez la référence fournisseur, la désignation, l’unité de mesure reconnue, le prix et le code de classification attendu. Ce tableau de correspondance est le vrai document de travail du projet.
Faites valider les trois étapes avec un client : ouverture de la session, panier dans le catalogue, retour dans l’outil d’achat. Un test réussi sur un cas simple ne prouve rien tant que les unités, les devises et les remises n’ont pas été vérifiées.
Le punch-out se joue sur deux protocoles, et c’est l’acheteur qui décide de celui que vous devez parler.
Vous préparez une connexion à l’outil d’achat de vos clients ? Échangez avec notre équipe pour cadrer le protocole, le catalogue et le calendrier. Pour une vue d’ensemble, voir aussi l’article sur la marketplace et e-procurement.
cXML, pour commerce eXtensible Markup Language, est un standard d’échange en XML entre un outil d’achat et un fournisseur. Il couvre le catalogue en punch-out, et prévoit aussi la commande d’achat.
OCI, pour Open Catalog Interface, est l’interface de catalogue de SAP. Elle permet à un outil d’achat SAP d’ouvrir le catalogue d’un fournisseur et d’en récupérer le panier par un formulaire HTTP.
cXML échange des messages XML et prévoit la suite de la commande. OCI renvoie des champs de formulaire et s’arrête au catalogue et au panier. cXML identifie mieux les utilisateurs, OCI utilise souvent un identifiant partagé.
Le choix dépend des outils d’achat de vos clients. Un fournisseur qui vend à plusieurs grands comptes doit souvent prendre en charge les deux.
En cXML, un message PunchOutOrderMessage est soumis depuis le navigateur de l’acheteur vers l’adresse de retour. En OCI, un formulaire HTML poste les lignes vers le HOOK_URL.
En général la description, la quantité, l’unité, le prix, la devise et la référence du fournisseur. Les champs requis varient selon l’acheteur, il faut donc valider le mapping avec chaque client.
Le punch-out gère le catalogue et le panier. La commande d’achat est prévue par cXML. La facture dépend de l’intégration et du circuit d’échange choisis par l’acheteur.
La durée dépend du catalogue, du protocole et du client. La phase la plus longue est souvent le mapping des données et les tests avec le premier acheteur.
Lancement en1 mois avec notre solution tout-en-un
Spécialiste du e-commerce B2B
Équipe intégration pour simplifier votre projet
Morgan Clark
Platform manager chez Label Corner
"Le service client est très réactif et la plateforme reste simple d'usage.
La solution est très performate, avec un bon rpport de prix et permet une impléentation rapide."
