This is a test message to test the length of the message box.
Login
ABAP CDS View Entity
Erstellt von Software-Heroes

CDS - View Entity

846

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.

Werbung


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.


Enthaltene Themen:
CDSCore Data ServiceView Entity
Kommentare (0)



Und weiter ...

Bist du zufrieden mit dem Inhalt des Artikels? Wir posten jeden Freitag neuen Content im Bereich ABAP und unregelmäßig in allen anderen Bereichen. Schaue bei unseren Tools und Apps vorbei, diese stellen wir kostenlos zur Verfügung.


CDS - Migration der Views

Kategorie - ABAP

Du hast noch viele alte Core Data Services in deinem ABAP System? Zeit für die Migration zur neuen Entität.

15.11.2024

CDS - Typen und Enums

Kategorie - ABAP

Was wird im ABAP Dictionary die Datenelemente ablösen und wie kannst du schon heute die Typen für die Core Data Services verwenden? Mehr hier.

05.11.2024

ABAP in Praxis - String Verarbeitung

Kategorie - ABAP

In diesem praktischen Beispiel schauen wir uns die String Verarbeitung zur Ermittlung der CDS Namen in CamelCase an und wie du das mit ABAP umsetzen kannst.

15.10.2024

ABAP - CDS Extraktor

Kategorie - ABAP

Wie funktioniert der CDS Extraktor in ABAP und welche Herausforderungen gibt es bei der Entwicklung damit. In diesem Artikel schauen wir uns ein paar Details an.

20.09.2024

ABAP Tools - Arbeiten mit Eclipse (CDS Templates)

Kategorie - ABAP

Wieder das falsche CDS Template bei der Erstellung ausgewählt? Hier ein kleiner Tipp um nachträglich noch den View in ABAP zu korrigieren.

02.07.2024