CDS View Entity – schnellere und einfachere Datenmodellierung in SAP S/4HANA

Fällt das Wort HANA, geht es schnell um CDS View Entities. Klar, beide Technologien sind untrennbar miteinander verbunden.

Die In-Memory-Datenbanktechnologie ist der Grund, warum SAP von der DDIC-basierten ABAP CDS View abgerückt ist. Die Ziele: verbesserte Performance, übersichtlicherer Code und neue Funktionen, die Entwicklern das Leben erleichtern. 

Tatsächlich ist das den Walldorfern weitestgehend gelungen. Dieser Beitrag erklärt, wie genau SAP das geschafft hat und warum auch du auf CDS View Entities setzen solltest. 

Das Wichtigste auf einen Blick

• CDS View Entities ermöglichen die Datenmodellierung auf verschiedenen Abstraktionsebenen.  
• CDS View Entity basiert auf der HANA-Technologie und löst die datenbankunabhängige, DDIC-basierte ABAP CDS View ab.
• Durch weitere Verbesserungen wie Annotationen statt Joins weisen CDS View Entities den Weg in Richtung eines schlankeren und wartbareren Codes im ERP.

Was ist eine CDS View Entity?

Core Data Services (CDS) Views Entities gibt es seit 2020, genauer gesagt seit dem ABAP-Release 7.55. Sie entwickelten sich aus den DDIC-basierten CDS Views und dienen denselben Zwecken:

• Sie greifen über eine SQL-Abfrage Daten aus einer oder mehreren Quellen ab.
• Die gesammelten Daten konsolidieren sie für verschiedene Anwendungen.
• Sie bereiten die Daten für Reportings, Fiori Elements oder andere Anwendungen auf.
• Über CDS Annotations können sie mit Metadaten angereichert werden.

Nun stellt sich die Frage: Warum der Wandel hin zu CDS View Entity?

Dies liegt an der strategischen Entscheidung von SAP, im Zuge von S/4HANA ganz auf die eigene Datenbanktechnologie zu setzen. CDS View Entities sind dementsprechend komplett auf HANA ausgelegt und nutzen die Stärken der In-Memory-Technologie voll aus. 

Wie? Indem sie die direkte Berechnung von Daten auf der Datenbank ermöglichen. Das steigert die Performance enorm.

CDS View Entity erstellen

Eine CDS View Entity lässt sich in Eclipse mit den ABAP Development Tools (ADT) erstellen. Im ersten Schritt muss eine neue „Data Definition“ angelegt werden. Das funktioniert unter anderem über die Tastenkombination STRG + N.

Beim Klick auf „Next“ erscheint eine Eingabemaske. Hier können der ABAP-Projektname hinterlegt und die Paketzuordnung erfolgen. Der Name definiert die anzulegende CDS View unter Berücksichtigung der Namenskonventionen. Unter „Referenced Object“ wird die zugrunde liegende Datenbanktabelle eingegeben oder ausgewählt.

Im nächsten Fenster kann ein Transportauftrag ausgewählt werden. Achtung: Nach Fertigstellung nicht auf „Finish“, sondern auf „Next“ klicken. Dadurch erscheint ein Fenster, mit dem das Grundgerüst der CDS View automatisch erstellt werden kann.

Das Tool bietet dafür eine Vielzahl an Vorlagen mit Assoziation, Parameter, Extension, Table Function und mehr. Mein Tipp: Immer nach einer passenden Vorlage schauen. Das kann viel Arbeit ersparen und potenzielle Fehlerquellen ausschließen.

Sobald das richtige Template ausgewählt wurde, wird die CDS View automatisch generiert. 

CDS View Entity vs. CDS DDIC View – die Unterschiede erklärt

Beim Anlegen einer ABAP CDS View kann im Template-Fenster des Wizards zwischen DEFINE VIEW und DEFINE VIEW ENTITY ausgewählt werden. Ersteres ist die klassische DDIC-based Version. Sie gilt seit ABAP 7.57 (S/4 HANA 2022) als obsolet und sollte für neue Entwicklungen nicht mehr verwendet werden.

Was unterscheidet die CDS View Entity nun von der Vorgängerversion aus technischer Sicht?

Der grundlegende Unterschied liegt darin, dass klassische ABAP CDS Views plattformunabhängig sind und somit auch auf Nicht-HANA-Datenbanken laufen. Dies erfordert eine Abstraktionsschicht. Diese SAP Data Dictionary (DDIC) definiert und verwaltet alle technischen und semantischen Eigenschaften der Daten, sodass sie auf unterschiedlichen Datenbanken genutzt werden können.

CDS View Entity benötigen zwar einen ABAP SQL-View, aber kein DDIC-Artefakt mehr, da sie ausschließlich auf der HANA-Datenbank funktionieren. Entsprechend verändert sich die Architektur des Aufbaus:

Durch den Wegfall der DDIC-View entfallen die Annotationen @AbapCatalog.sqlViewName und @AbapCatalog.preserveKey: true. Auch gibt es kein Client-Field (@ClientHandling.algorithm) mehr, da die Client-Behandlung implizit erfolgt und damit keinen Entwicklungsaufwand mehr erfordert.

Neben den Code-Anpassungen führte SAP weitere Veränderungen ein:

• Eine überarbeitete Pufferverwaltung mittels CDS-Tuning-Objekten bietet mehr Flexibilität.
• Der CDS Compiler stellt sicher, dass nur autorisierte und korrekt definierte Annotationen verwendet werden.
• Ausdrücke können ineinander verschachtelt werden, sodass die Anzahl an View-Stacks sich verringert.
• CDS View Entities ermöglichen eine größere Vielfalt an Operanden in allen Operandenpositionen. 
• Wenig genutzte Funktionen wie Namenslisten und die Syntax SELECT * wurden abgeschafft.

Die Unterschiede noch einmal zusammengefasst: 

Merkmal	DDIC-basierte CDS Views	CDS View Entities
Definition	DEFINE VIEW	DEFINE VIEW ENTITY
Verwendung im ABAP Dictionary	Erzeugt ein DDIC	Erzeugt kein DDIC-View
Objektanzahl	Zwei Objekte: CDS View + DDIC View	Ein Objekt: SQL View (HANA Database View)
Namensgebung	CDS View und DDIC View (max. 16 Zeichen für DDIC)	Ein Name bis 30 Zeichen
Plattformabhängigkeit	Any-DB-fähig	HANA-spezifisch
Client-Handling	@ClientHandling.type und @ClientHandling.algorithm erforderlich	Automatisch und implizit durch Session-Variable $session.client
Aktivierungsdauer	Längere Aktivierungszeit, da jede Hierarchie-Ebene ein DDIC View erstellt	Bis zu 50% schnellere Activation-Performance bei View-Stack, da keine DDIC-Generierung
Features	Eingeschränkte Features, weniger flexibel	Neue Erweiterungen und Features
Zukunftsfähigkeit	Seit ABAP 7.56 obsolet, keine neuen Features mehr	Zukunftssicher und empfohlen
Performance	Weniger optimal, da zwei View-Schichten entstehen	Direkter Datenbank-Zugriff

Welche Vorteile bietet CDS View Entity?

SAP verfolgt mit den CDS View Entities ein klares Ziel: Entwicklungen im ERP-System vereinfachen. Das ist gelungen.

Früher kam es oft zu Verwechslungen, da sowohl für die CDS View als auch die DDIC View Namen vergeben werden mussten. Da für erstere 30 und für letztere nur 16 Zeichen erlaubt sind, waren Namenskonflikte vorprogrammiert. Das gehört der Vergangenheit an, da nur noch ein Objekt benannt werden muss.

Gleichzeitig sorgt der Wegfall des DDIC Views für eine bessere Performance, da das Prüfen, Synchronisieren und Aktivieren zweier Objekte entfällt. Dadurch sinkt die Aktivierungszeit bei View-Stacks um bis zu 50 Prozent.

Zusätzlich weisen die neuen Konsistenzprüfungen in Richtung eines expliziteren, klareren Codes. Denn diese sind nicht nur strenger, sondern auch kontextbezogener und plausibler. Außerdem ersetzen Assoziationen die traditionellen Joins und führen so zu schlankerem und wartbarem Code.

Zu guter Letzt: Die $projection.-Syntax ermöglicht die Wiederverwendung bereits definierter Spalten innerhalb eines Views, während Bedingungen direkt in WHERE-Klauseln gesetzt werden können. Dadurch sinkt die Redundanz und der Code wird präziser.

Fazit

Schneller, schlanker, klarer – diese drei Worte beschreiben treffend die CDS View Entity. Die Technologie bietet schnellere Aktivierungszeiten, eine eindeutige Namensgebung ohne Zeichenlimit-Konflikte und plausiblere Konsistenzprüfungen. Das Ergebnis ist ein performanterer, robusterer und wartbarer Code.

Gleichzeitig sind die Views die logische Antwort auf die strategische Ausrichtung von SAP auf die HANA-Datenbank. Zukunftssicherheit inklusive. Daher lautet meine klare Empfehlung: Bei allen neuen Entwicklungen sollte ausschließlich auf CDS View Entities gesetzt werden.

FAQ

---