Intro
Die CDS View Entities feiern gerade ihren 5. Geburtstag. Am 2.9.2020 hatte ich den ersten Blogpost A new generation of CDS views: CDS view entities im SAP Community Network zu dem Thema gefunden.
Die klassischen CDS Views sind seit ABAP 7.57 (S/4HANA 2022) obsolet. Ein guter Grund, sich noch einmal die Geschichte und die Unterschiede der beiden Objekte anzuschauen.
Was bisher geschah - ein Blick in die Vergangenheit
2012 - Die ersten CDS Objekte waren für die SAP HANA
Um auf dem XS(C) Applikationsserver der HANA Datenbank Views und Tabellen zu definieren, wurde ein Konzept benötigt, wie man diese Objekte in einem Repository speichern kann. Das Ergebnis war HANA CDS - die Core Data Services. Angelehnt an das DDIC enthält das HANA CDS auch semantische Informationen über die Anwendung. Die Objekte wurden in HANA SQL definiert, angereichert um Annotationen und Assoziationen.
2014 - CDS Views im ABAP
Mit NetWeaver 7.40 SP05 wurden CDS Views im ABAP eingeführt. Nun konnte man CDS direkt im ABAP-Stack definieren, mit nahtloser Integration in das ABAP Dictionary.
- Syntax basiert auf ABAP SQL
- Semantische Informationen werden durch Annotations ergänzt
- Definiert in Quelltext-Dateien in den ABAP Development Tools
- Enge Integration in Open SQL: CDS Views können wie Tabellen selektiert werden.
- Ermöglicht Code Pushdown: Logik läuft in der HANA-DB, nicht im ABAP.
- Unterstützung für Any-DB, also auch Oracle, IBM, etc.
2015 - Virtuelles Datenmodell (VDM) in S/4HANA
Mit der Einführung von S/4HANA bekam CDS eine zentrale Rolle in der SAP-Datenmodellierung. Das Virtuelle Datenmodell (VDM) enthält tausende vorkonfigurierte CDS Views als Basis für Reporting, Fiori-Apps und APIs.
CDS wird die basis von allen Frameworks im ABAP Stack:
- OData Services
- Embedded Analytics
- BW-Extraktion
- Oberflächenerstellung mit Fiori Elements
- Enterprise Search
2019 - CDS wird basis vom RESTful Application Programming Model ABAP (RAP)
2020 - CDS View Entities lösen die DDIC-Based CDS Views ab
Und mit S/4HANA 2022 werden die klassischen CDS Views obsolet
Was war schlecht an den klassischen CDS Views?
Zwei Namen
Der erste Punkt, der jeden Entwickler bei den klassischen CDS Views irritiert hat, waren die zwei Namen:
- CDS View Name - 30 Stellen lang,
- SQL View Name - 16 Stellen lang, weil es eigentlich der Name des DDIC-Views ist
Eigentlich könnte die Quelltextdatei auch noch einen abweichenden Namen haben, aber das hat hoffentlich niemand gemacht. Der Blick in den Objektkatalog offenbart, dass es eigentlich 3 unterschiedliche Objekte sind:
Zu strenge Konsistenzprüfungen
An manchen Stellen wurde die Syntax extrem streng geprüft. Mein Lieblingsbeispiel ist diese Meldung:
Das passiert, wenn man aus der MARA bzw. I_Product das Volumen mit Länge x Breite x Höhe berechnet.
Begrenzte Verschachtelung von Ausdrücken, vor allem in SQL-Funktionen
An vielen Stellen gab es Syntaxprüfungsfehler, wenn Funktionen verschachtelt wurden.
Wo ist der Unterschied zur CDS View Entity
Während der CDS View auf Any-DB laufen musste, konnte die CDS View Entity sich auf die HANA Datenbank fokussieren. Damit war die traditionelle Abstraktionsschicht zwischen den unterschiedlichen Datenbankmanagementsystemen obsolet. Das DDIC konnte entfernt werden.
Weil DDIC-View und CDS View im gleichen Namesnraum befinden, wurden zwei Namen benötigt.
Die folgende Abbildung soll das zeigen. Dabei stehen die Farben für jeweils einen Namen. Bei der klassichen, DDIC Based CDS View erkenne wir zwei Farben, bei der CDS View Entity nur eine.
Was ist an der CDS View Entity besser
Ein Name für alles
Sowohl CDS View als auch SQL View haben den gleichen Namen - und der hat 30 Zeichen Länge. In analytischen Anwendungen, also überall, wo das @Analytics Framework als Annotation vorkommt, spielt normalerweise der SQL-View die führende Rolle. Beispie:
- Viewname für die BW-Extraktoren
- Name von analytischen InfoProvidern und Queries setzen sich aus dem Präfix
2Cund dem SQL-Viewname zusammen
Weniger kleinliche Konsistenzprüfungen
Auch wenn das der Dokumentation der CDS View Entities wiederspricht: Ich halte die Konsistenzprüfungen der View Entities für lockerer. Auf jeden Fall aber für plausibler. Siehe oben.
Mehr Features
Die DDIC Based CDS Views wurden seit einigen Jahren nicht mehr weiterentwickelt. Bei den CDS View Entites gibt es aber noch einige Verbesserungen. Unter anderem:
- Verbesserung beim Verschachteln von Ausdrücken - da geht immer mehr
- Automatische Mandantenbehandlung
- Schnellere Aktvierung, weil kein DDIC View mehr erzeugt werden muss
- Man kann sich in Ausdrücken mit
$projection.auf andere Spalten des Views beziehen
Und soll ich jetzt meine DDIC Based CDS Views migrieren?
Das ist nicht nötig. Wenn diese schon tun was sie sollen, dann sind die ganzen Nachteile ja nicht mehr relevant. Und die SAP hat auch tausende von klassischen CDS Views im Virtuellen Datenmodell und viele davon sind auch C1-Freigegeben. D.h. wir können uns darauf verlassen, dass diese noch sehr, sehr lange unterstützt werde.
Fazit
Bislang habe ich keinen einzigen Nachteil von CDS View Entities gegenüber den CDS Views gefunden. Von daher spricht nichts mehr für die klassischen CDS Views, solange man auf einem entsprechenden Systemstand ist.
