Unterschiedliche CDS View Definitionen in ABAP – Was steckt dahinter?

Mit der Einführung von ABAP CDS (Core Data Services) hat sich die Art, wie wir Datenmodelle im SAP-System erstellen, stark verändert. Besonders auffällig ist, dass es verschiedene Varianten zur Definition von Views gibt. Aber welche nimmt man wann? Und warum ist eine Variante inzwischen sogar obsolet?


define view entity

Die wichtigste Variante heute ist define view entity. Sie ist der empfohlene Standard für alle neuen Entwicklungen. Eine View Entity kann direkt in Open SQL genutzt werden und erzeugt im Gegensatz zu älteren Varianten kein eigenes DDIC-SQL-View mehr im Hintergrund. Nur wenn explizit Kompatibilität benötigt wird, kann man dies aktivieren. In modernen Projekten sollte diese Variante immer die erste Wahl sein.

define root view entity

Darauf aufbauend gibt es define root view entity. Diese Syntax markiert die View zusätzlich als Root eines Business Objects und spielt vor allem im RAP (RESTful ABAP Programming Model) eine zentrale Rolle. Jedes Business Object hat genau einen Root, von dem aus über Assoziationen die Child-Entities angebunden werden.

define view entity with to-parent association

Damit ein Business Object auch hierarchisch aufgebaut werden kann, kommt define view entity with to-parent association ins Spiel. Diese Variante verhält sich wie eine normale View Entity, enthält jedoch eine feste Assoziation zum Parent. Sie wird typischerweise für Child-Entities innerhalb eines Business Object verwendet, etwa bei Auftragskopf, Auftragsposition und Lieferposition.

define view

Die älteste Form ist define view. Sie legt im Hintergrund automatisch einen DDIC-SQL-View an und war lange Zeit die Standard-Syntax. Mit ABAP 7.57 ist sie jedoch als obsolet markiert und sollte in neuen Entwicklungen nicht mehr eingesetzt werden. Alte Views laufen zwar weiter, doch wer zukunftssicher arbeiten möchte, setzt heute konsequent auf define view entity.

define view entity - Syntax


@AbapCatalog.sqlViewName: 'ZV_MATVIEW'        // technischer Name (nur wenn Kompatibilität benötigt wird)
@AccessControl.authorizationCheck: #CHECK     // Berechtigungsprüfung aktivieren
@EndUserText.label: 'Materialstammdaten View' // Beschreibung

define view entity ZI_Material
  as select from mara
    inner join marc on mara.matnr = marc.matnr
{
    key mara.matnr           as Material,
        mara.mtart           as Materialart,
        mara.matkl           as Warengruppe,
        mara.ersda           as Anlagedatum,
        marc.werks           as Werk,
        marc.dispo           as Disponent
}

DATA lt_mat TYPE TABLE OF zi_material. "Entity-Namen verwenden! Aufruf aus ABAP-Code:


DATA lt_mat TYPE TABLE OF zi_material.   "Entity-Namen verwenden!

SELECT *
  FROM zi_material
  WHERE werks = @'1000'
  INTO TABLE @lt_mat.


root view entity - Struktur

Eine root view entity ist der Einstiegspunkt eines RAP Business Objects und steht immer an oberster Stelle der Hierarchie. Von dort aus werden Kind-Entities über Kompositionen angebunden. Diese Kind-Entities können wiederum eigene Enkel-Entities besitzen, sodass sich eine mehrstufige Struktur ergibt wie zum Beispiel Auftrag, Position und Anhang. Neue Objekte können ausschließlich über die Root-Entity angelegt oder gelöscht werden, die abhängigen Hierarchien werden automatisch mitgeführt. Auf diese Weise lassen sich im RAP komplexe Geschäftsobjekte als Baum-Hierarchien klar und konsistent modellieren.