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 volume d'une réponse dépend notamment du format, des champs et des entités retournés. Pour une application Fiori, il est utile d'analyser le payload et les requêtes réseau avant de choisir une optimisation.

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.

Une modernisation de service peut être l'occasion de revoir les requêtes, les données transmises et les usages de l'interface. La comparaison avant et après doit porter sur les mêmes scénarios et conditions de mesure.

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.

RAP propose des mécanismes de gestion du Draft à configurer pour le Business Object. Les scénarios de saisie, les verrous et les conflits doivent être vérifiés avec les utilisateurs.

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 avec les deux endpoints pendant la migration des consommateurs.
5. Décommissionner l'ancien service V2 après vérification de l'absence d'usages et validation du plan de reprise.

La durée de la migration dépend du nombre de services, de leurs consommateurs et des contraintes d'exploitation. Une transition progressive permet d'organiser les validations et les adaptations sans imposer une bascule unique.