OData V4 sur S/4HANA : guide pour DSI (différences V2/V4, RAP, performances)

Pendant près d'une décennie, OData V2 a été le pivot d'intégration de l'écosystème SAP : SAP Gateway, Fiori 1.x, applications mobiles, intégrations B2B, partenaires CRM — tout passait par les mêmes endpoints /sap/opu/odata/sap/<service>/. Le format Atom XML, les $expand limités à un niveau et l'absence d'actions typées ont fait leur travail le temps que SAP construise le successeur.

Depuis 2018, ce successeur s'appelle OData V4 — standard OASIS, profondément intégré à RAP, et désormais le seul chemin recommandé pour exposer un Business Object S/4HANA. Cet article fait le tour, pour une DSI, des décisions techniques structurantes : quand basculer, comment exposer, comment sécuriser, et quel ROI attendre.

OData : qu'est-ce que c'est exactement ?

OData (Open Data Protocol) est un protocole REST standardisé par l'OASIS qui définit une grammaire commune pour interroger et modifier des données via HTTP. Il standardise ce que chaque équipe back-end réinvente sans cela : pagination ($top, $skip), filtrage ($filter), tri ($orderby), sélection de champs ($select), expansion d'entités liées ($expand), et même les opérations métier non-CRUD (Actions, Functions).

Sur S/4HANA, OData est le protocole d'intégration officiel entre la couche métier ABAP/RAP et le reste de l'écosystème : applications Fiori, intégrations BTP, partenaires externes, apps mobiles, batchs d'extraction temps réel. Toute donnée standard SAP ou tout Business Object spécifique correctement modélisé peut être exposé sous forme de service OData.

Différences V2 vs V4 : le tableau qui résume tout

Le saut conceptuel entre V2 et V4 est massif. V4 n'est pas une simple version mineure : c'est un protocole repensé en intégrant huit ans d'expérience opérationnelle.

Le tableau parle de lui-même. Sur tout sujet structurant (sérialisation, navigation, actions, draft, concurrence), V4 fait progresser le protocole d'un cran. Pour une DSI, l'arbitrage n'est plus « est-ce qu'on bascule un jour ? » mais « comment cadencer la migration de nos services V2 historiques sans rompre la continuité métier ? ».

OData V4 sur S/4HANA via RAP

Sur S/4HANA, le chemin standard pour exposer un service OData V4 ne passe plus par la SEGW. Il passe par RAP. Le pipeline est le suivant :

1. CDS Interface View qui modélise les données — voir notre guide CDS Views
2. CDS Projection View qui ajoute les annotations @UI et les champs exposés
3. Behavior Definition (BDEF) qui déclare le comportement transactionnel (CRUD, actions, draft)
4. Service Definition qui sélectionne les Projection Views à exposer
5. Service Binding de type ODATA V4 qui publie l'endpoint réel

L'endpoint généré est de la forme /sap/opu/odata4/sap/<service>/srvd_a2x/sap/<service>/0001/. Le métadonnées ($metadata) est généré automatiquement à partir des annotations CDS — aucun fichier d'annotations XML externe à maintenir, contrairement à V2.

Voici un exemple de payload OData V4 retourné par un appel GET /SalesOrder?$top=2&$expand=_Items&$select=SalesOrder,NetAmount :

{
  "@odata.context": "$metadata#SalesOrder(SalesOrder,NetAmount,_Items())",
  "@odata.metadataEtag": "W/\"20260518000000\"",
  "value": [
    {
      "SalesOrder": "0000010234",
      "NetAmount": 12450.00,
      "@odata.editLink": "SalesOrder('0000010234')",
      "_Items": [
        {
          "SalesOrder": "0000010234",
          "ItemNumber": "00010",
          "Material": "KH-PRESS-2000",
          "Quantity": 2,
          "NetAmount": 8200.00
        },
        {
          "SalesOrder": "0000010234",
          "ItemNumber": "00020",
          "Material": "KH-SERVICE-INST",
          "Quantity": 1,
          "NetAmount": 4250.00
        }
      ]
    }
  ]
}

Performance : pourquoi JSON change tout

Le format Atom XML d'OData V2 est lourd : namespaces XML, balises ouvrantes et fermantes, encodage caractère par caractère. Sur une réponse complexe avec dix entités enfants et trente champs, le payload XML est 40 à 60 % plus volumineux que son équivalent JSON V4. Pour une app Fiori qui charge une Object Page sur réseau d'entreprise puis se propage à des utilisateurs en mobilité, cette différence se traduit directement en temps de chargement perçu.

Mais le gain ne s'arrête pas au volume transporté. JSON est nativement parsé par les moteurs JavaScript des navigateurs modernes — pas de pipeline XML/DOM lourd. Le typage natif (nombres, booléens, dates ISO 8601) évite les conversions explicites. Et le $expand multi-niveaux de V4 permet de récupérer un graphe métier complet en un seul roundtrip réseau, là où V2 demandait trois ou quatre appels en cascade.

Sur la modernisation d'un cockpit de pilotage commercial chez un client industriel comparable à Kuhn Group, la bascule du même Business Object de V2 vers V4 a réduit le temps de chargement initial de 2,1 s à 1,3 s — un gain de 38 % obtenu sans aucune optimisation côté UI, uniquement par le changement de protocole.

Actions et Functions typées

OData V4 distingue clairement deux types d'opérations métier non-CRUD :

• Functions (HTTP GET, lecture seule) : calculer une valeur dérivée sans changer l'état du système. Exemples : simuler un prix, estimer une date de livraison, calculer un score de crédit.
• Actions (HTTP POST, transactionnelles) : déclencher une opération métier qui modifie l'état. Exemples : approuver une commande, soumettre un congé, lancer un calcul de paie.

Les deux acceptent des paramètres typés et structurés (entités complexes, collections) et retournent des valeurs typées. C'est un changement majeur par rapport aux Function Imports V2, dont les paramètres se limitaient à des types simples.

Sur Fiori Elements, les Actions apparaissent automatiquement comme boutons sur les Object Pages — annoter une action Approve dans la BDEF avec @UI.lineItem.position suffit à la voir surgir dans la barre d'outils, sans une ligne de code UI5.

Draft natif : l'autre rupture

Le concept de Draft — sauvegarder un enregistrement en cours de saisie sans l'activer définitivement — a été inventé par SAP pour Fiori, hors protocole OData V2. Cela impliquait des conventions maison, des entités draft annexes, et un travail d'intégration côté client lourd.

OData V4 intègre le concept au protocole via le vocabulary Common.DraftRoot et Common.DraftNode. Une entité annotée comme Draft expose automatiquement les actions Edit, Activate, Discard, et le client OData (Fiori Elements, SAPUI5, ou un client tiers compatible) sait nativement les invoquer.

Côté RAP, activer le Draft sur un Business Object revient à déclarer une table de Draft et une ligne dans la BDEF : draft table z_drft_order; et with draft;. Tout le reste — persistance, lock, cleanup périodique, gestion des conflits — est pris en charge par le framework. Hors RAP, l'implémentation manuelle représenterait des semaines de développement.

Sécurité : CSRF, OAuth 2.0 et bonnes pratiques

Un service OData V4 hérite des protections classiques de la stack SAP : authentification (Basic, SAML, OAuth, jeton SSO), autorisations (objets d'autorisation ABAP plus les DCL CDS), et protection CSRF.

Le jeton CSRF reste obligatoire pour toute opération non-GET. Le client récupère le token via un GET initial avec le header x-csrf-token: fetch, puis le réinjecte dans tous les POST, PUT, PATCH, DELETE suivants. C'est un mécanisme transparent pour Fiori et pour les SDK SAP, mais à implémenter explicitement quand le service est consommé par un client tiers.

Pour une exposition au-delà du périmètre interne (partenaire externe, app mobile non SAP, plateforme cloud tierce), le standard est OAuth 2.0. SAP supporte les flows Authorization Code, Client Credentials et SAML Bearer Assertion. Le configurateur OAuth de S/4HANA (transaction OA2C_CONFIG / WD pour SAP Gateway) déclare le client, gère les scopes et publie les endpoints token / autorisation. Le service OData V4 est alors protégé via un module d'authentification ICM.

Trois bonnes pratiques systématiquement recommandées en revue d'architecture :

• Toujours servir en HTTPS, même en interne — un OAuth en clair n'a aucun sens
• Cloisonner les services exposés en externe dans un Communication Scenario dédié, avec son propre Service Binding et ses propres scopes OAuth
• Logger les accès et superviser les anomalies de volume via SAP Web Dispatcher ou un API Manager BTP en amont

Cas de migration V2 → V4

La tentation, sur un parc de cinquante ou cent services V2, est de chercher une conversion automatique de la SEGW vers V4. SAP ne propose pas d'outil de ce type, et c'est une bonne chose : la conversion mécanique produirait un V4 qui ressemble à du V2 en JSON, sans tirer aucun bénéfice du protocole.

La trajectoire recommandée est différente :

1. Inventorier les services V2 en production, classifier par criticité (Fiori critique, intégration partenaire, batch interne) et par fréquence d'usage
2. Reconstruire les Business Objects sous-jacents en CDS Views + BDEF RAP — l'occasion de nettoyer le modèle métier au passage
3. Exposer en V4 via un Service Binding, sur un nouvel endpoint, sans casser l'ancien
4. Cohabiter les deux endpoints le temps que les consommateurs migrent (six à douze mois selon le contexte)
5. Décommissionner l'ancien service V2 quand plus aucun appel n'est tracé pendant deux mois consécutifs

Sur un cabinet d'audit avec lequel nous avons travaillé en 2025, cette trajectoire appliquée à 18 services V2 critiques a pris 14 mois en parallèle d'un projet S/4HANA en cours — sans interruption de service, sans incident utilisateur. Le coût initial paraît élevé, mais il s'agit d'un investissement Clean Core qui sécurise les upgrades suivants.