Vues ABAP CDS

Une vue ABAP CDS est du code source que le système ABAP transforme en vue de base de données :

1. Un développeur crée une définition de données dans ABAP Development Tools et écrit une instruction DEFINE VIEW ENTITY : sources de données, champs sélectionnés, calculs, jointures et associations vers d'autres entités CDS.
2. Les annotations ajoutent des métadonnées : libellés, sémantique telle que les champs de devise ou d'unité, rôles analytiques, indications d'interface et paramètres d'exposition OData.
3. À l'activation, le système crée l'entité CDS et la vue correspondante dans la base de données, de sorte que la logique s'exécute là où se trouvent les données.
4. Les consommateurs lisent la vue : ABAP SQL dans les programmes, services OData construits avec RAP, requêtes analytiques et API libérées.
5. Si un contrôle d'accès CDS existe pour la vue, ses conditions s'appliquent à chaque lecture de la vue.

Les associations constituent une différence majeure avec les vues de base de données classiques : elles déclarent une relation une seule fois, et la jointure n'est construite que lorsqu'un consommateur suit le chemin d'association. Une vue ABAP CDS est donc un modèle de données sémantique réutilisable, et pas simplement un SELECT stocké.

La documentation SAP cite une activation plus rapide, une syntaxe plus simple et des contrôles plus stricts parmi les raisons d'adopter les view entities. Les vues DDIC-based existantes continuent de fonctionner, et ABAP Development Tools propose un assistant de migration, documenté en on-premise à partir de SAP S/4HANA 2023 FPS00. RAP en strict mode attend également des view entities comme sources de données. Pour tout nouveau développement, les view entities sont la variante de vues ABAP CDS à utiliser.

SAP S/4HANA livre des milliers de vues CDS organisées en virtual data model (VDM). Les basic interface views exposent les entités métier au plus près des tables, les composite interface views les combinent et les consumption views servent une application ou une requête précise. Le préfixe du nom indique le niveau : I_ pour les interface views, comme I_SalesOrder, et C_ pour les consumption views.

Ce qui compte pour les clients, c'est le statut de libération d'une vue :

• Libérée pour l'extensibilité key user (contrat C1) : utilisable dans les outils key user tels que l'application Custom CDS Views.
• Libérée pour le développement cloud (contrat C1) : utilisable par les développeurs en ABAP Cloud, y compris en extensibilité développeur.
• Non libérée : visible dans le système mais sans contrat de stabilité ; SAP peut la modifier lors de n'importe quelle mise à niveau.

Un key user d'Alder Manufacturing qui a besoin des commandes d'achat ouvertes par fournisseur, par exemple, construit une vue CDS spécifique sur des vues achats libérées au lieu de lire les tables. Dans le virtual data model, c'est le statut de libération qui détermine s'il est sûr de s'appuyer sur une vue ABAP CDS.

Une vue CDS fournit des données et des métadonnées ; d'autres objets en font une application :

1. Chemin actuel (RAP) : des CDS view entities forment un business object, une behavior definition ajoute des opérations, des projection views l'adaptent, et une service definition accompagnée d'un service binding l'exposent en OData V2 ou V4.
2. SAP Fiori elements lit les annotations d'interface de ce service et génère un list report ou une object page.
3. Les applications analytiques consomment des requêtes analytiques CDS, définies comme transient view entities dans les releases récentes et avec l'annotation dépréciée @Analytics.query dans les plus anciennes.

Les systèmes plus anciens utilisent des chemins antérieurs : l'annotation @OData.publish de l'ABAP Programming Model for SAP Fiori, ou un projet SAP Gateway qui utilise la vue CDS comme source de données référencée ; vérifiez lesquels votre release prend encore en charge. Dans tous les cas, la vue ABAP CDS définit ce que sont les données ; le comportement transactionnel provient de RAP ou, dans le modèle précédent, de BOPF.

Les points forts sont importants. Un même modèle sert aussi bien OData que l'analytique et ABAP SQL ; les calculs s'exécutent dans la base de données ; les annotations portent une sémantique que tous les consommateurs comprennent ; et le contrôle d'accès est déclaré à côté des données.

Les limites découlent de la nature même d'une vue :

• Modèle de lecture uniquement. Une vue CDS ne crée, ne modifie ni ne valide de données. Les transactions nécessitent un business object RAP par-dessus.
• SQL déclaratif, pas de logique procédurale. Les algorithmes complexes sont déplacés vers des CDS table functions implémentées en AMDP, ou vers ABAP.
• Les performances dépendent de l'empilement. Des vues construites sur des vues elles-mêmes construites sur des vues peuvent produire un SQL lourd ; des associations utilisées sans précaution multiplient les jointures.
• Liées à la release. Les fonctionnalités de syntaxe arrivent release après release ; une vue écrite pour l'environnement ABAP de SAP BTP peut ne pas s'activer sur une release on-premise plus ancienne.

Les vues ABAP CDS sont le bon endroit pour la sémantique des données, pas pour la logique de processus ou de transaction.

1. Créer de nouvelles vues DDIC-based. Elles sont obsolètes ; commencez par des view entities.
2. S'appuyer sur des vues SAP non libérées. Cela fonctionne jusqu'à ce qu'une mise à niveau modifie la vue. Vérifiez d'abord le contrat de libération.
3. Oublier le contrôle d'accès. Sans contrôle d'accès CDS, toute personne autorisée à lire la vue voit l'ensemble de ses données. Ajoutez un contrôle d'accès et conservez également les autorisations de démarrage des applications.
4. Écrire les annotations d'interface dans la définition de données. Les metadata extensions gardent le modèle lisible et permettent aux métadonnées d'interface d'évoluer à leur propre rythme.
5. Confondre ABAP CDS et CAP CDS. Même idée et syntaxe similaire, mais environnement d'exécution différent : un modèle CAP ne s'active pas dans un système ABAP.

La plupart des problèmes liés aux vues ABAP CDS proviennent de décisions de cycle de vie, et non du SQL.