CDS - Typen von Data Definitions

Inhaltsverzeichnis

• Einleitung
• Typen
• VIEW
• VIEW ENTITY
• PROJECTION
• CUSTOM ENTITY
• HIERARCHY
• ABSTRACT ENTITY
• EXTERNAL ENTITY
• TABLE ENTITY
• TABLE FUNCTION
• Überblick
• Suche
• Vollständiges Beispiel
• Fazit

In diesem Artikel schauen wir uns verschiedene Typen an und wie wir sie in der ABAP Entwicklung einsetzen können.

 

Einleitung

Mittlerweile gibt es in ABAP zahlreiche Data Definitions mit unterschiedlichen Keywords, die wir in unterschiedlichen Szenarien einsetzen können. Objekte wie der View sind mittlerweile sogar wieder obsolet geworden, zumindest du auf einem aktuellen System unterwegs bist. Daher wird es einmal Zeit auf die Vielzahl von Objekten in dieser Kategorie zu schauen.

 

Typen

In diesem Kapitel schauen wir uns die unterschiedlichen Typen einmal im Detail an und gehen auf mögliche Use-Cases ein. Dabei findest du auch jeweils ein Beispiel einer Implementierung an dem jeweiligen Objekt.

 

VIEW

Der View war einer der ersten Core Data Services, der von SAP entwickelt wurde, um die Modellierung von Datenmodellen in ABAP abzubilden. Der View verwendet immer einen SQL View, der als zusätzliches Artefakt auf der Datenbank abgelegt wird. Damit hat der View auch einige Nachteile, wie Abhängigkeiten, schlechte Änderbarkeit und langsame Aktivierung. Datenquelle ist eine Tabelle oder ein anderer View zum Erstellen von View Stacks im Datenmodell.

@AbapCatalog.sqlViewName: 'ZBSIETYCLASSVIEW'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Classic CDS View'
define view ZBS_I_ETypeClassicView
  as select from zbs_dmo_partner
{
  key partner               as Partner,
      name                  as Name,
      street                as Street,
      city                  as City,
      country               as Country,
      payment_currency      as PaymentCurrency
}

 

VIEW ENTITY

Die View Entity ist der Nachfolger des Views und benötigt keine zusätzlichen Artefakte mehr. Die Aktivierung, Erweiterung und Anpassung sind schneller und es kann auf Felder im eigenen View einfacher zugegriffen werden. In einem aktuellen Release solltest du nur noch solche Views verwenden und auf den klassischen View verzichten. Datenquelle ist hier eine Tabelle oder andere Objekte mit Daten (Table Entity, External Entity) aus dem Bereich der Core Data Services.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'View Entity'
define view entity ZBS_I_ETypeViewEntity
  as select from zbs_dmo_partner
{
  key partner          as Partner,
      name             as Name,
      street           as Street,
      city             as City,
      country          as Country,
      payment_currency as PaymentCurrency
}

 

PROJECTION

Eine Projektion ist Teil eines RAP Objekts und kann nur für Views verwendet werden, die in einem Business Objekt verwendet werden. Sie stehen für die Consumption Schicht im Datenmodell und folgen auch anderen Regeln. So wird zum Beispiel eine Provider Contract definiert, hier können keine neuen Assoziationen im Datenmodell angelegt werden und virtuelle Felder sind auf dieser Ebene möglich.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection'
define root view entity ZBS_C_ETypeProjection
  provider contract transactional_query
  as projection on ZBS_I_ETypeViewEntity
{
  key Partner,
      Name,
      Street,
      City,
      Country,
      PaymentCurrency
}

 

CUSTOM ENTITY

Die Custom Entity hat selbst keine eigene Datenquelle, sondern repräsentiert eine Struktur nach außen. Über eine zusätzliche Annotation kann eine Query-Klasse definiert werden, die durch das SADL Framework ausgeführt wird und für diese Struktur Daten zur Verfügung stellt. Innerhalb der ABAP Klasse können dann alle möglichen Funktionen ausgeführt werden, was es zu einer flexiblen Art der Entwicklung macht. Allerdings funktioniert damit nur die Entität in einem OData Service.

@EndUserText.label: 'Custom Entity'
@ObjectModel.query.implementedBy: 'ABAP:ZCL_BS_DEMO_ETYPE_QUERY'
define custom entity ZBS_I_ETypeCustomEntity
{
  key uuid        : sysuuid_x16;
      description : abap.sstring( 350 );
      counter     : abap.int4;
}

 

HIERARCHY

Möchtest du eine Hierarchie darstellen, dann gibt es dafür unter den CDS Artefakten einen eigenen Typen. Dieser definiert die Beziehung der Informationen untereinander, gibt weitere Felder nach außen und bestimmt auch die Reihenfolge und Sortierung. Die Hierarchie kann mittlerweile auch genutzt werden, um einen Tree in Fiori Elements zu erzeugen.

@AccessControl.authorizationCheck: #NOT_REQUIRED
define hierarchy ZBS_I_ETypeHierarchy
  as parent child hierarchy(
    source ZBS_I_DMOTeamView
    child to parent association _Leader
    start where
      TeamLeader is initial
    siblings order by
      UserIdentification
  )
{
  key UserIdentification,
      TeamLeader,
      TeamName
}

 

ABSTRACT ENTITY

Die abstrakte Entität ist eine Art Strukturbeschreibung und benötigt auch nicht zwingend eine KEY Definition und Schlüsselfelder. Damit können einfache Eingabe-Popups umgesetzt werden, aber auch komplexe und tiefe Strukturen, für erweiterte Aktionen. Grundsätzlich können auch UI Annotationen für das Popup definiert werden, damit bei späterer Nutzung

@EndUserText.label: 'Abstract Entity'
define abstract entity ZBS_S_ETypeAbstractEntity
{
  uuid        : sysuuid_x16;
  description : abap.sstring( 350 );
  counter     : abap.int4;
}

 

EXTERNAL ENTITY

Externe Entitäten sind noch relativ neu und bilden Entitäten von externen Systemen ab. Möchtest du zum Beispiel eine HANA Datenbank in der Cloud anbinden oder einen SQL Service über ein anderes System einbinden, dann ist die lokale Repräsentation eine External Entity. Aktuell werden dafür statische und dynamische Anbindungen angeboten. Innerhalb der Entität können wir die Felder auf unseren Zieltypen mappen, wenn wir zum Beispiel die Daten harmonisieren wollen.

@EndUserText.label: 'External Entity'
define external entity ZBS_E_ETypeExternalEntity external name BUT000
{
  key BusinessPartner : abap.char(10) external name PARTNER;
      Type            : abap.char(1)  external name TYPE;
      BPEXT           : abap.char(20);
      BU_SORT1        : abap.char(20);
      BU_SORT2        : abap.char(20);
}
with federated data provided at runtime

 

TABLE ENTITY

Die Table Entität ist das neueste Artefakt der CDS Familie und soll später einmal die klassische DDIC Tabelle ablösen. Zum Artefakt gibt es eine entsprechende Repräsentation als Datenbank/Tabelle und es können Daten abgelegt werden. Mittlerweile kann die Entität auch zur Modellierung von RAP Anwendungen eingesetzt werden.

@ClientHandling.type: #CLIENT_DEPENDENT
@AbapCatalog.deliveryClass: #APPLICATION_DATA
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Table Entity'
define table entity ZBS_T_ETypeTableEntity
{
  key MyUUID          : sysuuid_x16;
      SemanticKey     : abap.char( 15 );
      LongDescription : abap.string null;
      ForeignKey      : abap.char( 10 );

      _KeyAsso        : association of exact one to one ZBS_T_ETypeAssociation on _KeyAsso.ForeignKey = $projection.ForeignKey;
}

 

Damit können wir direkt auf Ebene der Tabelle Assoziationen und Kompositionen anlegen. Zur Definition der Felder verwenden wir eingebaute Typen oder Simple Types. Wir können Felder auch auf NULL setzen bzw. müssen das im Fall eines Strings sogar und es funktionieren nur noch die nativen Datentypen.

 

TABLE FUNCTION

Die Table Funktion lagert wiederverwendbare Bestandteile und Ermittlungen auf die Datenbank aus. So kannst du Daten lesen, prüfen und verändern, ohne dies im ABAP Stack zu machen. Damit bekommst du einen guten Code-Pushdown zur Datenbank hin. Für die Implementierung der Logik muss eine Klasse implementiert werden und in der Methode dann SQL Skript.

@EndUserText.label: 'Table Function'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientHandling.type: #CLIENT_DEPENDENT
@ClientHandling.clientSafe: true
@ClientHandling.algorithm: #SESSION_VARIABLE
define table function ZBS_F_ETypeTableFunction
  with parameters
    partner : abap.char( 10 )
returns
{
  Client   : abap.clnt;
  Material : abap.char(5);
  Discount : abap.dec(5,2);
}
implemented by method
  zcl_bs_demo_etpye_tfunc=>get_all_discounts;

 

Überblick

Hier noch einmal ein kurzer Überblick der verschiedenen Typen von oben und ihre Nutzung innerhalb der ABAP Entwicklung. Damit erhältst du einen schnellen Überblick über die Funktionen und Möglichkeiten.

 

Die einzelnen Kategorien haben die folgende Bedeutung:

• Daten - Stellt das Artefakt Daten zur Verfügung.
• Scope - Wo kann das Objekt genutzt werden. Überall in ABAP wäre der Standard, sonst sind die Einschränkungen genannt.
• Modellierung - Kann auf diesem Objekt weiter modelliert werden und es ist es eine Grundlage dafür.
• Release - Ab welchem On-Prem Release steht das Objekt zur Verfügung.

 

Suche

Aktuell werden alle Objekte im Bereich Data Definition abgelegt, was die Suche etwas schwerer macht und die Abgrenzung aktuell nur über die unterschiedlichen Namenskonventionen funktioniert. Aktuell kannst du aber in der Suche (STRG + SHIFT + A) nach den entsprechenden Quelltypen suchen. Über das Attribut "sourcetype", kannst du auf die weiteren Typen einschränken.

 

 

Damit kannst du dann nach spezifischen Views suchen, wenn vielleicht mal wieder nicht die internen Namenskonventionen eingehalten wurden.

 

Vollständiges Beispiel

Alle Objekte aus diesem Beispiel findest du bei uns im GitHub Repository für die CDS Beispiele. Wir haben dafür ein neues Paket ZBS_DEMO_CDS_TYPES angelegt, um die Artefakte und Beispiele abzugrenzen. In diesem Commit findest du alle Änderungen und neuen Objekte.

 

Fazit

Mit dem Artikel solltest du nun einen Überblick über die verschiedenen Artefakte haben, wie und wo du sie einsetzen kannst und für was sie benötigt werden.