CDS - View Entity
In diesem Artikel erfährst du mehr über die neuen Core Data Service Entitäten, was sie bringen und was sie von den alten Views unterscheidet.
Inhaltsverzeichnis
Mit ABAP 7.55 oder S/4 HANA 2020 hat SAP neue Typen von CDS Views implementiert. Die neuen Typen bringen vor allem sehr viele Vorteile mit, basieren aber auf einem aktuellen Release. Was es mit den Views auf sich hat, wie du sie nutzt und was die Unterschiede der beiden aktuellen Typen sind, erklären wir dir in diesem Artikel.
Verfügbarkeit
Wie oben beschrieben, gibt es View Entitäten bereits seit ABAP 7.55, werden vor allem im Zusammenhang von RAP eingeführt. Nun sind sie mit der Cloud Version 2205 bzw. dem 2022 Release für S/4 Feature Complete. Für uns als Entwickler heißt das, dass nun alle angekündigten Funktionen und Möglichkeiten implementiert wurden und vollständig verwendet, werden können.
Unterschiede
Bereits mit dem ersten Business Objekt im RAP Blog, haben wir die neuen Views verwendet, hier nur mit dem Zusatz "root", da jedes Business Objekt eine Wurzel hat. Was unterscheidet nun die View von der View Entity? Hier musste SAP einen harten Cut zwischen den beiden Typen machen, damit die älteren Views im Nachgang noch funktionierten und es nicht zu Problemen im System kam.
DEFINE VIEW
Bei dem klassischen CDS View wir der View definiert und über die Annotationen gleichzeitig ein DDIC Artefakt, welches als View im DDIC angelegt wird. Bei der Aktivierung des Core Data Service wird dann jedes Mal auch der DDIC View aktualisiert, was zu längeren Aktivierungszeiten führte. Der typische Aufbau sieht daher wie folgt aus:
Wenn in so einem View auch noch Parameter enthalten waren, wurde der View technisch als Tabellenfunktion auf der Datenbank gespeichert. Dies kann man sich über das "SQL Create Statement" im View anschauen. Wenn man einen View Stack hatte, der aus mehreren aufeinander aufbauenden Views bestand und man nun ein Feld umbenennen wollte, dann musste man jeden einzelnen View anpassen, teilweise mit Dummyfeldern arbeiten, um die gesamte Hierarchie zu aktualisieren.
DEFINE VIEW ENTITY
Die neuen Entitäten benötigen kein DDIC Artefakt mehr und werden als Views direkt generiert. Dadurch wird die Aktivierung des Views und eines ganzen View Stacks viel schneller und einfacher, da nur jeweils ein Objekt generiert und geprüft werden muss. Entsprechend verändert sich die Architektur des Aufbaus:
Vorteile
Welche weiteren Vorteile hat die Verwendung der neuen Core Data Services für dich? An dieser Stelle einmal nur die Aufzählung der verschiedenen Vorteile:
- Schnellere Aktivierungszeiten von Views
- Änderungen auf Feldebene über ganze Views Stacks
- Striktere Syntaxprüfung über den Compiler (Verwendung von Datentypen, Literalen, Prüfung vorhandener Annotationen gegen DDLA)
- Mehr Verschachtelungen von Funktionen und Operanden im View
- Verwendung typisierter Literale
- Automatische Mandantenbehandlung
Weiterhin ergeben sich verschiedene Vorteile in der Architektur und Modellierung mit CDS Views:
- Generierung des Schlüssels nun vereinheitlicht, vorher in View und DDIC teilweise unterschiedlich
- Berechnung von Mengen und Währungen werden besser auf Sinnhaftigkeit geprüft, sodass sinnvolle Einheiten entstehen (z.B.: EUR/m²)
- Anlage eigener Mengeneinheiten bei berechneten Feldern
- Bessere Pufferbehandlung der Views
Vergleich
Für einen kleinen Vergleich definieren wir zwei Views die gleich sind, aber entsprechend auf den zwei Varianten basieren. Der alte View wird entsprechend angelegt und enthält auch einen Parameter zur Eingrenzung der Daten:
@AbapCatalog.sqlViewName: 'ZBSIDMOOLDVIEW'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Old view type'
define view ZBS_I_DmoOldView
with parameters
@Environment.systemField: #SYSTEM_DATE
P_Date : abap.dats
as select from zbs_dmo_invoice
association [0..*] to ZBS_I_DmoPosition as _Position on $projection.DocumentNumber = _Position.DocumentNumber
{
key document as DocumentNumber,
doc_date as DocumentDate,
doc_time as DocumentTime,
partner as PartnerNumber,
_Position
}
where
doc_date = $parameters.P_Date
Das SQL Create Statement sieht nun wie folgt aus, dabei fällt auf, dass es sich nicht um einen definierten View handelt, sondern um eine Datenbank Funktion. Das hat den Hintergrund da damals die Funktionalität auf der HANA Datenbank fehlte, Views mit Parametern mussten anders dargestellt werden.
Definieren wir nun eine entsprechende View Entity die das gleiche Verhalten wie der View davor aufweist:
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'New view type'
define view entity ZBS_I_DmoNewView
with parameters
@Environment.systemField: #SYSTEM_DATE
P_Date : abap.dats
as select from zbs_dmo_invoice
association [0..*] to ZBS_I_DmoPosition as _Position on $projection.DocumentNumber = _Position.DocumentNumber
{
key document as DocumentNumber,
doc_date as DocumentDate,
doc_time as DocumentTime,
partner as PartnerNumber,
_Position
}
where
doc_date = $parameters.P_Date
Der neue View wird auch mit Parameter als View auf der Datenbank generiert und verhält sich so wie der definierte View. Hier gibt es keine Unterschiede ob der View Parameter hat oder eben nicht:
Der neue View enthält weniger Annotationen und auch weniger Objekte, da der DDIC View wegfällt. Ebenso verhält sich das Generieren auf der Datenbank immer gleich und es werden die HANA Views genutzt.
Migration
Die neuen und die alten View-Typen sind allerdings nicht kompatibel zueinander, da hier die SAP einen harten Cut setzen musste, wie bereits oben beschrieben. Doch weiterhin stellt die SAP verschiedene Reports und Tools im System zur Verfügung, um eine manuelle Migration und Analyse auf eigenen Views durchführen zu können.
Damit kannst du auch bestehende Views und Hierarchien mit ein wenig Aufwand auf die neue Welt migrieren. Im Hintergrund werden dann die DDIC Views von der Datenbank gelöscht. Weitere Informationen erhältst du im Link unten bei "Migration".
Links
Natürlich wollen wir dir auch nicht die weiteren Informationen vorenthalten die du auf den verschiedenen Blogs und auf dem offiziellen SAP Blog findet:
Fazit
Sollte dein System bereits einen hohen Release haben, dann solltest du nur noch die neuen View Entitäten für die Modellierung nutzen, das ist auch die Aussage von SAP. Die "alten" Views sollten nur noch so selten wir nötig genutzt werden und bieten auch mehr Nachteile als Vorteile, gegenüber den neuen Objekten.