OData

OData décrit les données métier sous forme d'entity sets que les clients adressent par des URL, avec des verbes HTTP standard pour chaque opération :

• GET lit un entity set ou une entité unique, par exemple les commandes d'achat de Cedar Office Supply.
• POST, PATCH/PUT et DELETE créent, modifient et suppriment des entités.
• Les options de requête système telles que $filter, $select, $expand, $orderby, $top et $skip permettent au client de demander au serveur de filtrer, trier et paginer les données.
• `$metadata` renvoie le modèle de données du service : types d'entités, propriétés, clés, associations et annotations.
• `$batch` regroupe plusieurs requêtes en un seul appel HTTP.

Comme le modèle et les opérations sont standardisés, un client générique tel que le modèle OData de SAPUI5 peut lier des contrôles à n'importe quel service conforme sans code de requête spécifique. OData est donc un contrat sur la manière d'exposer les données, et non un élément de logique métier.

Une fois que le SAP Fiori Launchpad a résolu une tile et démarré l'application, l'accès aux données suit le même chemin pour toute application SAPUI5 ou SAP Fiori elements :

1. L'application démarre. L'app descriptor désigne le service OData que l'application utilise comme source de données.
2. L'application appelle le service. Le modèle OData de SAPUI5 envoie des requêtes, souvent regroupées dans un $batch, à l'URL du service. Sur SAP S/4HANA, SAP Gateway vérifie que l'utilisateur a le droit de démarrer le service (objet d'autorisation S_SERVICE) et achemine la requête.
3. La logique métier s'exécute. L'implémentation du service — vues CDS, comportement RAP ou code basé sur SEGW — applique les validations et les autorisations sur les données.
4. L'enregistrement est lu ou écrit. La réponse renvoie les données, ou la modification est enregistrée dans le document métier, ce qui peut déclencher un traitement en aval tel qu'un workflow.

Une étape défaillante se manifeste différemment selon le cas : une autorisation de démarrage manquante apparaît dans SU53, tandis qu'une erreur côté service apparaît dans /IWFND/ERROR_LOG ou /IWBEP/ERROR_LOG en on-premise. Tout écran SAP Fiori alimenté par des données est, en dessous, une suite de requêtes OData.

Les deux versions coexistent dans les environnements SAP, et la version détermine les outils et les modèles applicables :

RAP peut exposer le même business object en OData V2 ou V4, et certaines fonctionnalités récentes de SAP Fiori elements ne sont évaluées qu'avec OData V4, alors que de nombreuses applications livrées continuent de fonctionner en V2. Choisir une version d'OData est une décision d'outillage et de prise en charge par les applications, et pas seulement de fonctionnalités du protocole.

SAP propose plusieurs façons de créer un service OData, selon la plateforme et l'âge du code :

• RAP (ABAP RESTful Application Programming Model) : une service definition sélectionne des entités CDS, et un service binding les publie en OData V2 ou V4, avec la catégorie UI (porte les annotations d'interface pour SAP Fiori elements) ou Web API (sans métadonnées propres à l'interface).
• Projets SEGW : le SAP Gateway Service Builder modélise les entités et génère des classes d'exécution pour du code ABAP écrit à la main ; courant dans les applications spécifiques plus anciennes.
• CDS avec `@OData.publish: true` : génère un service OData V2 à partir d'une vue CDS ; toujours documenté pour l'on-premise et la Private Edition, alors que les service bindings RAP constituent l'approche plus récente.
• CAP sur SAP BTP : des définitions de services en CDS servies en OData, avec V4 par défaut et V2 disponible via un adaptateur.

Le protocole sur le réseau est le même ; c'est le modèle de programmation qui se trouve derrière qui détermine le traitement de la logique, des drafts et des extensions. Il est préférable de démarrer un nouveau service OData dans le modèle de programmation que la plateforme cible recommande actuellement.

• On-premise et Private Edition : les administrateurs enregistrent et activent les services OData sur SAP Gateway, attribuent les system aliases et gèrent les nœuds ICF. L'ensemble des transactions et des journaux de Gateway est disponible.
• Public Edition : SAP exploite les services qui se trouvent derrière les applications SAP Fiori livrées. L'accès aux outils d'administration et de supervision est encadré plutôt qu'ouvert comme en on-premise ; les consommateurs externes appellent des API libérées via des communication arrangements, et les services spécifiques proviennent de l'extensibilité développeur ou de l'extensibilité key user.
• SAP BTP : les applications appellent directement des services OData sur SAP BTP ou atteignent des services on-premise via des destinations et le SAP Cloud Connector.

Le protocole OData se comporte de la même façon partout ; ce qui change, c'est qui active le service et comment un appelant l'atteint.

1. Traiter un service d'interface comme une API d'intégration. Un service conçu pour une application SAP Fiori peut évoluer avec l'application. Les intégrations doivent reposer sur des API libérées ou sur des services conçus comme Web API.
2. Récupérer trop de données. Les listes sans $select ou avec un $expand profond transfèrent bien plus de données que l'écran n'en affiche ; vérifiez les requêtes dans les outils de développement du navigateur.
3. Ignorer `$batch` lors du débogage. Le navigateur affiche un seul appel batch ; l'opération en échec se trouve dans le corps de sa réponse.
4. Mélanger les versions dans la conception d'une même application. V2 et V4 utilisent des modèles SAPUI5 et des piles SAP Fiori elements différents, si bien que les composants passent rarement de l'une à l'autre sans modification.
5. Imputer à l'interface des lacunes d'autorisation. Une liste vide peut provenir d'un filtre d'autorisation sur les données dans le service, et non d'un bug du front-end.

La plupart des problèmes OData dans les projets SAP Fiori sont des problèmes de conception ou d'autorisation qui ne se manifestent que sous forme d'erreurs de protocole.