Qu'est-ce que l'OCI et à quoi sert-il en e-procurement ?

L’OCI - pour Open Catalog Interface - est un protocole d’échange créé par SAP à la fin des années 1990 pour connecter ses systèmes d’achats (SAP SRM, SAP S/4HANA) à des catalogues fournisseurs externes.

C’est un mécanisme plus simple que cXML : pas de XML, pas de DTD, pas de validation stricte. L’OCI s’appuie sur des paramètres URL et des formulaires HTML standards. Si vous travaillez avec un client SAP qui n’utilise pas Ariba, il y a de fortes chances que ce soit en OCI.

À quoi sert OCI

L’OCI permet à un prescripteur d’un système SAP de “sortir” vers le catalogue d’un fournisseur, naviguer, sélectionner ses articles, et renvoyer son panier au système d’achats SAP - sans avoir à maintenir le catalogue côté SAP.

L’objectif est le même que pour le PunchOut cXML : laisser au fournisseur la maîtrise de son catalogue (prix, stocks, références) tout en gardant le circuit d’approbation côté acheteur. Mais le mécanisme technique est radicalement différent.

C’est un cas particulier du concept général de PunchOut, avec une implémentation propre à SAP.

Origines

OCI a été créé par SAP pour son système SRM (Supplier Relationship Management). Plutôt que d’inventer un protocole XML complexe, SAP a opté pour une approche pragmatique :

• une URL ou un formulaire HTML pour ouvrir la session (GET ou POST selon la configuration acheteur)
• un formulaire HTML POST pour renvoyer le panier
• des noms de champs normalisés (NEW_ITEM-DESCRIPTION[1], NEW_ITEM-PRICE[1], etc.)

Pas de signature dans le payload, pas de schéma à valider, pas de session XML. La simplicité est le maître-mot.

Le mécanisme OCI étape par étape

Le flux OCI tient en trois étapes :

Pas de XML, pas de message de Setup, pas de validation asynchrone. Le prescripteur navigue, valide son panier, et celui-ci remonte directement dans son système SAP via un POST HTML standard.

Les paramètres clés à l’ouverture de session

Quand le système SAP redirige vers le catalogue fournisseur, il transmet en paramètres URL :

Paramètre	Rôle
HOOK_URL	L’URL de retour côté SAP - le formulaire HTML doit y poster le panier
OCI_VERSION	Version du protocole (4.0, 5.0…)
~caller	Identifiant du système appelant (variable selon les implémentations)
~OkCode	Code d’action attendu (souvent ADDI pour “ajouter au panier”)
username, password	Authentification basique côté URL (selon configuration acheteur)

L’authentification est plus légère qu’en cXML : pas de SharedSecret dans un payload signé, juste des paramètres URL ou des headers HTTP côté serveur.

GET ou POST : OCI supporte les deux

OCI permet deux méthodes HTTP pour transmettre les paramètres d’ouverture de session - les deux sont officiellement supportées par SAP, configurables côté SAP par catalogue (transaction de customisation des Web Services Externes).

GET : paramètres dans l’URL (?HOOK_URL=...&OCI_VERSION=4.0&username=...).

• Plus simple à implémenter et déboguer (URL directement testable dans un navigateur)
• Inconvénient : credentials exposés dans les logs serveur, l’historique navigateur, les en-têtes Referer ; limité à ~2048 caractères

POST : paramètres dans le corps HTTP (formulaire HTML auto-soumis).

• Plus sécurisé : credentials absents des logs et de l’URL, pas de fuite via Referer
• Pas de limite de taille
• Plus complexe à tester (formulaire ou outil type curl nécessaire)

Lequel choisir ?

• POST dès que les paramètres contiennent un username/password ou des tokens sensibles - c’est la recommandation pour les déploiements OCI modernes (S/4HANA notamment).
• GET acceptable sur les catalogues sans authentification dans les paramètres OCI eux-mêmes (auth gérée à un autre niveau : IP whitelist, mutual TLS, cookie de session) ou en environnement de test.

Côté fournisseur, supporter les deux méthodes est la bonne pratique : votre endpoint accepte GET et POST avec la même logique de parsing, ce qui vous rend compatible avec toutes les configurations clients sans imposer de contrainte sur leur SI.

Les champs clés du retour panier

Le panier OCI est un ensemble de champs NEW_ITEM-<NOM>[<index>]. Pour chaque article, on retrouve :

Champ	Rôle
NEW_ITEM-DESCRIPTION	Description du produit
NEW_ITEM-PRICE	Prix unitaire
NEW_ITEM-QUANTITY	Quantité commandée
NEW_ITEM-UNIT	Unité de mesure (EA, KG, M…)
NEW_ITEM-MATNR	Code article SAP (s’il existe côté acheteur)
NEW_ITEM-MATGROUP	Catégorie produit
NEW_ITEM-VENDORMAT	Référence fournisseur
NEW_ITEM-VENDOR	Identifiant fournisseur
NEW_ITEM-CURRENCY	Devise
NEW_ITEM-LONGTEXT_<n>	Description longue ou commentaires

L’index [1], [2], etc. identifie chaque ligne du panier. Trois articles dans le panier = trois jeux de champs préfixés [1], [2], [3].

Pour le mapping de la classification produit (équivalent du Classification domain="UNSPSC" en cXML), OCI utilise NEW_ITEM-MATGROUP. Cette correspondance est moins normalisée qu’en cXML - chaque acheteur peut imposer son référentiel. Voir notre guide mapping en PunchOut pour les principes généraux.

OCI vs cXML : les différences qui comptent

Pour aller plus loin sur les écarts entre les deux protocoles : cXML vs OCI : quelle différence et lequel choisir ?.

Quand vous croiserez OCI

OCI reste le format imposé dans deux cas principaux :

• Clients SAP “pure souche” : SAP SRM ou S/4HANA sans couche Ariba intermédiaire. Le SI préfère rester dans l’écosystème SAP standard.
• ETI industrielles européennes : beaucoup d’industriels ont des installations SAP historiques qui utilisent encore OCI plutôt que cXML, parfois depuis 15 à 20 ans.

Si votre client utilise SAP Ariba, c’est généralement du cXML qui sera demandé - même si le backend est SAP. La présence d’Ariba comme couche intermédiaire fait basculer le protocole.

Les limitations à connaître

• Mapping moins riche : moins de champs disponibles que cXML. Pour un mapping fin (UNSPSC fin, taxes complexes, prix négociés contractuels), OCI est moins expressif.
• Pas de validation automatique : les erreurs de structure se découvrent à la réception côté SAP, souvent sans message exploitable.
• Sécurité plus légère : pas de signature dans le payload. La sécurité repose sur HTTPS et l’authentification d’URL.
• Versions : il existe plusieurs versions d’OCI (4.0, 5.0). Le client précise la version dans OCI_VERSION. Les variations sont mineures mais à anticiper.
• Champs custom : certains acheteurs ajoutent leurs propres champs NEW_ITEM-* non standards (codes analytiques, centres de coûts). Comme en cXML, le mapping doit s’adapter à chaque acheteur.

OCI et Magento

Pour une boutique Magento ou Adobe Commerce qui doit servir un acheteur SAP en OCI, l’implémentation côté boutique est plus simple qu’en cXML : c’est un endpoint qui génère un formulaire HTML à la place du flux XML POST.

La complexité se déplace sur le mapping des données catalogue Magento vers les champs NEW_ITEM-*. Et si votre boutique sert plusieurs acheteurs avec des systèmes différents (certains en cXML, d’autres en OCI), il faut une couche de mapping unifiée capable de gérer les deux protocoles depuis le même catalogue.

En résumé

OCI est le pendant SAP du PunchOut, plus simple que cXML mais aussi plus limité. Si vous vendez à un grand compte SAP qui n’utilise pas Ariba, c’est probablement le format que vous rencontrerez.

La bonne approche n’est pas de choisir entre cXML et OCI - c’est de gérer les deux. Un fournisseur B2B qui vend à plusieurs grands comptes croisera fatalement les deux protocoles dans son portefeuille de connexions.