Core Data Services (CDS) est une collection de langages spécifiques créée par SAP. Techniquement une extension du SQL, il hérite donc d’un langage de définition de données (create, define …), de manipulation de données (select, insert, …) et de contrôle d’autorisation (grant, …)
L’objectif du Core Data Services est de pouvoir définir une modélisation virtuelle des données directement dans l’ERP au travers de ce que l’on appelle le VDM (Virtual Data Model). Le but étant de construire une couche sémantique au-dessus des tables physiques de la base de données.
Cette nouvelle couche permettra de centraliser beaucoup de la logique et de l’effort de développement des concepts métiers, ainsi que de les rendre réutilisables et extensibles pour les développeurs.
Figure 1 : Place du VDM dans l’ERP. SOURCE: S4H410_05 SAP S/4HANA Embedded Analytics and Modeling with Core Data Services (CDS) Views
Il est possible de réaliser ce VDM à plusieurs endroits. Dans son blog, Horst Keller utilise l’appellation « One concept, Two flavors ». Cette dualité représente l’utilisation du Core Data Services directement dans la base de données HANA opposée à son utilisation au sein de la surcouche applicative ABAP. Pourquoi pouvoir le faire à deux endroits me direz-vous :
HANA CDS : Les vues CDS sont créées dans la base de données HANA, on peut y accéder depuis le serveur applicatif en utilisant du Native SQL. Ce mode de fonctionnement présente beaucoup de similitudes avec les Hana informations views.
ABAP CDS : Les vues CDS sont créées dans le serveur applicatif et enrichissent le dictionnaire de données ABAP. Ce mode de fonctionnement à beaucoup d’avantage, notamment d’être lié aux ordres de transports ABAP ainsi que de pouvoir utiliser les objets d’autorisation ABAP. De plus la vue Core Data Services faisant partie du DDIC (data dictionnary), on peut y accéder via Open SQL (beaucoup plus simple à écrire et à relire) à partir de n’importe quel programme ABAP.
A mon sens, dans le cas d’une architecture HANA + SAP Netweaver >= 7.4 SP5, il vaut mieux privilégier l’utilisation des vues ABAP CDS qui bénéficient d’une intégration bien meilleure et qui faciliteront leur réutilisation et leur déploiement.
Néanmoins les vues HANA CDS ont pour avantage de prendre en compte un catalogue de fonctions SQL plus conséquent. Etant donnée que l’ ABAP CDS doit pouvoir être utilisé sur de multiples bases de données différentes, toutes n’acceptant pas les mêmes instructions, son panel de fonctions a dû être restreint.
Dans un cas comme dans l’autre, le développement passe par Eclipse (et le plugin Abap Developpement Tools pour l’ABAP CDS) et est très similaire entre les deux versions.
Le Virtual Data Model
Que ce soit en Hana CDS ou ABAP CDS, le VDM s’articule autour de trois types de vues :
- Vues Basic
La vue Basic sert à ramener les données des tables physiques de la BDD. En fonction de leurs « annotations » elles peuvent correspondre à des dimensions (master data), des textes ou des hiérarchies. Ces vues ne sont pas requêtables et doivent, pour se faire, être utilisées dans une vue composite. A noter que seules les « interfaces views » peuvent servir d’extracteur (« datasource ») pour BW.
- Vues Composite
La vue « composite » sert de manière générale de modèle multidimensionnel et s’occupe de lier les « vues basic » entre elles via des associations (s’utilise à la manière d’une jointure SQL). Elles sont utilisées comme source des vues « consumption »
- Vues Consumption
La vue « consumption » permet de créer une requête spécifique à partir d’une vue composite. A noter que seule la vue « consumption » peut être exposée dans un service OData afin d’être consommée par les clients analytiques compatibles.
Figure 2 : Structure du Virtual Data Model SOURCE: S4H410_05 SAP S/4HANA Embedded Analytics and Modeling with Core Data Services (CDS) Views
Annotations
Les annotations sont utilisées pour ajouter des Meta data aux vues Core Data Services. Elles peuvent être évaluées à l’activation de l’objet ou lors de leur consommation par d’autre framework. Il en existe beaucoup, et ce sont ces annotations qui permettent entre autres :
- De nommer la vue SQL générer dans la base de données
- De catégoriser une vue Core Data Services en basic, composite ou consumption
- De préciser si un control d’accès s’applique
- D’apporter toute sorte de sémantique à chaque champ de la vue
- De passer des paramètres d’entrée à la vue
Chaque annotation commence par un ‘@’ et seule l’annotation « @AbapCatalog.sqlViewName : ‘’ » qui permet de nommer la vue SQL est obligatoire. Attention, à quelques exceptions près, aucun contrôle ne s’effectue dessus, une annotation qui ne peut pas être évaluée par un Framework sera ignorée.
Ci-dessous un liens vers les annotations standard SAP :https://help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/abencds_annotations.htm
Multi-utilisation des vues Core Data Services
La modélisation à partir de vues CDS est inscrite sur la roadmap SAP et l’éditeur entend la placer au cœur des problématiques d’analytiques en temps réel.
Figure 3 : Les vues CDS au centre du monde analytique S/4 . SOURCE: https://blogs.sap.com/2018/08/08/bw-query-on-cds-view-odata-from-bw-and-value-of-bw-query-in-s4hana/
Le schéma ci-dessus illustre uniquement l’utilisation des vues CDS, les liens classiques possibles entre BW et les outils de reporting ne sont pas représentés.
Transients Providers
Chaque vue « Composite » génère un « transient provider » (BW) et chaque vue « Consumption » peut générer une « transient query » (BW). Ces objets transitoires BW permettent aux vues CDS une parfaite intégration aux outils de restitution existants qui se basaient beaucoup sur les requêtes BW du BEX Query designer (BW Modeling tools depuis la 7.5).
Ainsi, pour une vue « Consumption » appelée ‘ABC’ et possédant l’annotation « @Analytics.query : true » à une transient query ‘2CABC’ est automatiquement générée et utilisable par tous les outils de restitution acceptant en source des requêtes BW.
De la même façon, la vue « composite » génère un transient infoprovider ‘2C+nom_de_la_vue’ utilisable par le BW modeling tools
En conclusion
En résumé le Core Data Services, et particulièrement l’ABAP CDS, ouvre les portes d’une nouvelle méthode de modélisation parfaitement adaptée à la conception de reportings opérationnels en temps réel (entre autres).
Le Virtual Data Model permet de structurer son flux et d’enrichir sémantiquement sa donnée pour lui donner plus de sens lors de sa consommation. En intégrant le Core Data Services aux requêtes BW et service OData, SAP est donc cohérent avec sa roadmap et permet son utilisation dans la plupart de ses outils de restitution.
Un point restant à éclaircir est la place que va prendre les HANA CDS vis-à-vis des informations views avec lesquelles elles partagent beaucoup de points communs.
Pour approfondir (articles en anglais) :
https://itpsap.com/dont-try-coding-abap-core-data-services-without-reading-this-first-2/
https://blogs.sap.com/2016/03/10/sap-s4hana-embedded-analytics-a-detailed-walkthrough-part-13/
https://blogs.sap.com/2018/08/08/bw-query-on-cds-view-odata-from-bw-and-value-of-bw-query-in-s4hana/
Guillaume Régnier
Derniers articles parGuillaume Régnier (voir tous)
- Aide à la saisie (F4 values) pour requêtes Bex sur Calculation Views - 17 janvier 2020
- Core Data Services en quelques mots - 6 décembre 2018