Einführung
Core Data Service Views – CDS Views – sind die neue Form der DDIC (SE11)-Datenbankview – aber absolut nicht vergleichbar!
CDS Views werden mit der Data Definition Language – DDL – in den Abap Development Tools definiert und können mit der Data Control Language – DCL – um Berechtigungen bzw. Zugriffsbeschränkungen erweitert werden.
Sie sind eine Möglichkeit des Code Push-Down im ABAP und zentraler Bestandteil des S/4 HANA ABAP-Programmiermodels (mehr Details gibt’s in den Folien zum Webinar).
Die hier gezeigten Beispiele wurden in unserem Webinar ABAP CDS Views verwendet und basieren auf Geschäftspartner-Beziehungen. Als System diente SAP NETWEAVER 750 SP1, bei niedrigeren Releases (ab 740 SP5/SP8) stehen manche Funktionen noch nicht zu Verfügung!
Die verwendeten Tabellen sind:
- BUT000 GP: Allgemeine Daten I
- BUT050 GP-Beziehungen/GP-Rollenfindungen: Allgemeine Daten
- TBZ9A GP-Beziehungstypen: Texte
- BUT100 GP: Rollen
Und hier noch die Datenbasis aus der Geschäftspartnerpflege:
![]()
Schritt 1 – Ein erster CDS View mit JOIN
Definition eines CDS Views mittels DDL
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX1D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientDependent: true
@EndUserText.label: 'BUT050 with Texts'
define view Zwb_But050_Txt_E as select from but050
left outer join tbz9a as cattx
on but050.reltyp = cattx.reltyp {
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
@Semantics.language: true
@EndUserText.label: 'Sprache'
cattx.spras,
cattx.bez50,
cattx.bez50_2
}Wir haben hier einem LEFT OUTER JOIN der BUT050 mit TBZ9A (Alias cattx) und den Viewfeldern Partner1, Partner1, Date_to, Reltyp, Date_from aus der Tabelle BUT050 und Spras, Bez50 und Bez50_2 aus der Tabelle TBZ9A. Als Ergebnis erhalten wir alle Beziehungen aus der BUT050 und den entsprechenden Texten zum Beziehungstyp aus der TBZ9A.
![]()
Das ist jetzt noch nicht wirklich aufregend und, abgesehen vom Syntax, auch nicht neu. Das schafft man auch mittels SE11-Datenbankview.
Wir wollen dieses einfache Beispiel aber nutzen, um die verschiedenen Bereiche, Befehle und Tools genauer zu beschreiben.
DDL Bereiche
Objekte und Namen
![]()
CDS Entity Name (Datenquellenobjekt ): Die CDS Entity wird als Datenquelle z.B. im ABAP Open SQL Statement verwendet.
CDS Datenbank View (generierter SE11 Datenbankview): Für jede Entity wird ein SE11 Datenbankview mit entsprechendem Namen generiert.
CDS Viewname (Sourcecode): Name des DDL Sourcecode Objekt.
Generierter DDL View in der SE11:
![Generierter SE11 DDL View]()
Annotiations
Annotations bieten die Möglichkeit Eigenschaften, Einstellungen und Metadaten für einem CDS View zu definieren. Diese Werte werden z.B. von der ABAP Runtime oder diversen Frameworks (u.a. Gateway/OData Service, BOPF,…) ausgelesen und steuern deren Verhalten bzw. die Ausgabe.
Annotations gelten entweder für den gesamten View – View Annotations:
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX1D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientDependent: true
@EndUserText.label: 'BUT050 with Texts'
...
Oder für einzelne Elemente/Felder – Element Annotations:
...
key but050.reltyp,
but050.date_from,
@Semantics.language: true // Definition VOR dem Element
@EndUserText.label: 'Sprache'
cattx.spras
@<EndUserText.quickInfo: 'Sprache', // Definition NACH dem Element
cattx.bez50,
...
Natürlich gibt’s auch Code Completion:
![]()
Annotations zu CDS Entitäten bzw. deren Feldern können mit der API Klasse CL_DD_DDL_ANNOTATION_SERVICE ausgelesen werden. Es wird auch die Möglichkeit kundeneigener Annotations geben (derzeit noch nicht offiziell unterstützt).
Weitere Details gibt’s hier:
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_f1_view_entity_annotations.htm
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_f1_element_annotation.htm
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_f1_parameter_annotations.htm
SELECT Liste
Die Select Liste (Datenbankfelder, Literale, Parameter, Funktionen, Systemfelder,…) kann entweder VOR oder NACH den Datenquelle angegeben werden:
![]()
Datenquellen
Als Datenquellen können Datenbanktabellen, SE11-Datenbankviews und andere CDS Entitäten angegeben werden. Für ON-Bedingungen von Joins gelten ähnliche Regeln, wie im Open SQL. Vor allem ist auch hier noch kein CAST möglich.
Details findet man hier: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_f1_joined_data_source.htm
Datenvorschau
Die Ergebnisse eines CDS Views kann in den ADT über die Data Preview angezeigt werden. Der Aufruf erfolgt über das Kontextmenü im DDL Code oder im Project Explorer oder direkt mittels F8:
![]()
Die Ausgabe der Data Preview:
![]()
Über Add filter kann, ähnlich der SE16, auf einzelne Feldwerte eingeschränkt werden:
![]()
In der SQL Console kann der abgesetzte SQL SELECT Befehl angezeigt und angepasst werden:
![]()
Cadaxo SQL Cockpit
Um den ABAP Open SQL Aufruf bzw. Syntax zu zeigen, wird das Cadaxo SQL Cockpit verwendet. Die angeführten SELECT Statement können genauso in ABAP Coding verwendet werden. Einzig der Befehl
... INTO TABLE @DATA(lt_but050_txt) ...
muss an den entsprechenden Stellen eingefügt werden.
![Cadaxo SQL Cockpit]()
Das entspricht dem ABAP Befehl:
SELECT *
FROM zwb_but050_txt_e
INTO TABLE @DATA(lt_but050_txt)
WHERE partner2 = '0000000011'.
Cadaxo SQL Cockpit
Schritt 2 – Eingebaute Funktionen
Die CDS Views biete eine ganze Fülle von eingebauten Funktionen, mit denen z.B. mathematische Funktionen und Stringopperationen ausgeführt, Währungs- und Mengeneinheiten umgerechnet, Zeit- und Datumsangaben geprüft oder Datumsintervalle berechnet werden können.
Eine vollständige Liste gibt’s hier: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_f1_builtin_functions.htm
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX3D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts'
define view ZWb_But050_Text1_E as select from but050
left outer join tbz9a as cattx
on but050.reltyp = cattx.reltyp {
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
@Semantics.language: true
@EndUserText.label: 'Sprache'
cattx.spras,
cattx.bez50,
cattx.bez50_2,
dats_days_between(but050.date_from, but050.date_to) as period // Eingebaute Funktion
}Hier wird die eingebaute Funktion DATS_DAYS_BETWEEN verwendet, um die Gültigkeit jeder Beziehung in Tagen zu berechen, und als Viewfeld Period bereitzustellen:
SELECT * FROM ZWB_BUT050_TEXT1_E. " View mit eingebauter Funktion
![]()
Im Ergebnis sehen wir die unterschiedlich langen Gültigkeitsbereiche in der Spalte PERIOD.
Schritt 3 – Views mit Parametern
Für CDS Views können Parameter definiert werden, die beim SELECT übergeben bzw. befüllt werden müssen:
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX4D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts with Parameter'
define view ZwbBut050_Txt_Param_E
with parameters p_langu:abap.lang
as select from but050
left outer join tbz9a as cattx
on but050.reltyp = cattx.reltyp
and cattx.spras = :p_langu // eg here
inner join but000 as partner1
on but050.partner1 = partner1.partner
inner join but000 as partner2
on but050.partner2 = partner2.partner {
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
@Semantics.language: true
@EndUserText.label: 'Sprache'
cattx.spras,
cattx.bez50,
cattx.bez50_2,
case when partner1.name_last <> '' then partner1.name_last
else partner1.name_org1 end as p1_name,
case when partner2.name_last <> '' then partner2.name_last
else partner2.name_org1 end as p2_name
}
where cattx.spras = $parameters.p_langu // or hereDer SELECT wurde um zwei JOINs auf die BUT000 erweitert, um Details zu den Partner zu ermitteln. Durch die beiden CASE Anweisungen werden auch Name_last bzw Name_org1 aus dem entsprechenden BUT000-Eintrag geliefert (natürlich sollte hier das Feld BUT000-TYPE zur Fallunterscheidung verwendet werden, zur Demonstration der Funktionalität reicht uns aber die Prüfung <> “).
Der interessante Teil ist aber die Definition des Parameters p_langu mit dem Datentype abap.lang (entspricht dem ABAP Dictionary Type LANG). Der Parameterwert wird in der ON-Bedingung des JOINs verwendnet, um die Einträge auf die gewünschte Sprache einzuschränken. Er kann aber genauso in die WHERE-Bedingung geschrieben werden. Die beiden Schreibweisen $parameters.p_langu und :p_langu sind gleichwertig und austauschbar.
Beim Aufruf der Data Preview erscheint jetzt zuerst ein Popup für die Parametereingabe:
![]()
Die Ergebniszeilen werden entsprechend eingeschränkt und auch die CASE Anweisung arbeitet richtig:
![]()
Der Open SQL Aufruf erfolgt ähnliche einem Methodenaufruf:
![]()
Als Typen können DDIC-Datenelemente oder vordefinierte Datentypen verwendet werden: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abencds_typing.htm
Die Code Completion unterstützt auch hier:
![]()
Über spezielle Parameter Annotations, die Environment Annotationen, können Systemfelder (z.B. SY-UNAME) als Defaultwerte für Parameter definiert werden. Wird der SELECT im ABAP ausgeführt, kann der Parameter weggelassen werden und wird auf den aktuellen Systemwert gesetzt:
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX4D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts with Parameter'
define view ZwbBut050_Txt_Param_E
with parameters
@Environment.systemField : #SYSTEM_LANGUAGE
p_langu:abap.lang
as select from but050
left outer join tbz9a as cattx
on but050.reltyp = cattx.reltyp
and cattx.spras = $parameters.p_langu // eg here
inner join but000 as partner1
on but050.partner1 = partner1.partner
inner join but000 as partner2
on but050.partner2 = partner2.partner {
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
@Semantics.language: true
@EndUserText.label: 'Sprache'
cattx.spras,
cattx.bez50,
cattx.bez50_2,
case when partner1.name_last <> '' then partner1.name_last
else partner1.name_org1 end as p1_name,
case when partner2.name_last <> '' then partner2.name_last
else partner2.name_org1 end as p2_name
}
![]()
Derzeit ist das für diese SY-Felder möglich:
| sy-mandt |
#CLIENT |
| sy-datum |
#SYSTEM_DATE |
| sy-uzeit |
#SYSTEM_TIME |
| sy-langu |
#SYSTEM_LANGUAGE |
| sy-uname |
#USER |
Das ist zwar nett, kann aber auch über eine Where-Bedingung erreicht werden. Wirklich lustig werden Parameter aber, wenn man mit ihnen Logik in die CDS Views bring:
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX5D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts with Parameter 1'
define view ZwbBut050_Txt_Param1_E
with parameters p_langu:abap.lang
@<Environment.systemField : #SYSTEM_LANGUAGE,
p_name_first:abap.char( 1 )
as select from but050
left outer join tbz9a as cattx
on but050.reltyp = cattx.reltyp
and cattx.spras = :p_langu
inner join but000 as partner1
on but050.partner1 = partner1.partner
inner join but000 as partner2
on but050.partner2 = partner2.partner {
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.relnr,
but050.date_from,
cattx.spras,
cattx.bez50,
cattx.bez50_2,
$parameters.p_name_first as use_first,
case :p_name_first
when 'F' then
case when partner1.name_first <> '' then partner1.name_first
else partner1.name_org1 end
else
case when partner1.name_last <> '' then partner1.name_last
else partner1.name_org1 end
end as p1_name,
case :p_name_first
when 'F' then
case when partner2.name_first <> '' then partner2.name_first
else partner2.name_org1 end
else
case when partner2.name_last <> '' then partner2.name_last
else partner2.name_org1 end
end as p2_name
}Wir legen einen weiteren Parameter p_name_first an und verwenden ihn in einer CASE Anweisung. Wird der Parameter mit dem Wert ‚F‘ übergeben, soll für Personen der Vorname (name_first) geliefert werden. Bei jedem anderen Wert kommt wie bisher der Nachname (name_last):
Die Ergebnislisten der beiden Select enthalten die erwarteten Namen:
![]()
Schritt 4 – Assiociations
Assiociations sind am einfachsten als „JOINs On Demand“ zu beschreiben. Durch Assiociations können Abhängigkeiten zwischen CDS View Entitäten (also Datenbanktabellen) abgebildet und damit komplexe Datenmodelle definiert werden. Datenbankseitig entsprechen sie JOINs. Die JOIN Bedingung wird aber nur ausgeführt, wenn wirklich Daten über die Assiociations gelesen werden müssen, also ein Feld aus der Association in der Select-Liste oder Where-Klausel verwendet wird.
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX6D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts with Association'
define view Zwb_But050_Txt_Asso_E
with parameters @Environment.systemField : #SYSTEM_LANGUAGE p_langu:abap.lang
as select from but050
// left outer join tbz9a as cattx
association [0..*] to tbz9a as _cattx
on but050.reltyp = _cattx.reltyp
// and _cattx.spras = $parameters.p_langu // jetzt als FILTER!
// inner join but000 as partner1
association [1] to but000 as _partner1
on but050.partner1 = _partner1.partner
// inner join but000 as partner2
association [1]to but000 as _partner2
on but050.partner2 = _partner2.partner
{
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
_cattx[spras = $parameters.p_langu ].spras,
_cattx[spras = $parameters.p_langu ].bez50,
_cattx[spras = $parameters.p_langu ].bez50_2
_cattx[spras = 'D'].bez50 as bez50_d,
_cattx[spras = 'D'].bez50_2 as bez50_2_d,
_partner1,
_partner2
}Zunächst modellieren wir unsere JOINs als Assiociations und definieren die entsprechende Kardinalität. In unserem Fall [1..1] für die Partner Beziehung und [0..*] für die Text Beziehung. Die Kardinalität dient derzeit noch hauptsächlich rein zur Abbildung des Datenmodells und wird durch die Syntaxprüfung nur teilweise berücksichtigt. Eine Ausnahme ist die Verwendung in der WHERE-Klausel, wo als Kardinalität nur [0..1] oder [1..1] erlaubt ist.
![]()
Wir verwenden hier einige Felder aus der Assiociation _cattx mit einem FILTER auf das Feld Spras. Damit werden nur Einträge geliefert, die auch dem Filter entsprechen („Where-Klausel“). Die Texte zum Beziehungstyp werden einerseits zu übergebenen Sprache im Parameter p_langu gelesen, aber zusätzlich auch für Deutsch. Wir sehen hier auch eine Warnung bezüglich der Kardinalität ([0..*] für TBZ9A), können den View aber trotzdem ausführen:
![]()
Auch im ABAP:
![]()
Interessanterweise erhalten wir aber mehr Zeilen als über die JOIN-Verknüpfung in Schritt 3!?!
Das liegt daran, dass Assiociations standardmäßig als LEFT OUTER JOIN gebildet werden. Das kann aber übersteuert werden:
@AbapCatalog.sqlViewName: 'ZWB_BUT050_TX6D'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'BUT050 with Texts with Association'
define view Zwb_But050_Txt_Asso_E
with parameters p_langu:abap.lang @<Environment.systemField : #SYSTEM_LANGUAGE
as select from but050
// left outer join tbz9a as cattx
association [0..*] to tbz9a as _cattx
on but050.reltyp = _cattx.reltyp
// and _cattx.spras = $parameters.p_langu // jetzt als FILTER!
// inner join but000 as partner1
association [1] to but000 as _partner1
on but050.partner1 = _partner1.partner
// inner join but000 as partner2
association [1]to but000 as _partner2
on but050.partner2 = _partner2.partner
{
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
_cattx[1: inner where spras = $parameters.p_langu ].spras,
_cattx[1: inner where spras = $parameters.p_langu ].bez50,
_cattx[1: inner where spras = $parameters.p_langu ].bez50_2,
_cattx[1: inner where spras = 'D'].bez50 as bez50_d,
_cattx[1: inner where spras = 'D'].bez50_2 as bez50_2_d,
_partner1,
_partner2
}Über die Angabe inner in den Filterwerten, mit dem Zusatz where, wird nun ein INNER JOIN generiert. Die ebenfalls neue Anweisung 1: setzt die Kardinalität für diese Verwendung auf [0..1]. Die Warnung wird nicht mehr angezeigt:
![]()
Das Ergebnis ist wieder gleich der JOIN Variante:
![]()
Assiociations veröffentlichen – Pfadzugriffe
Wer sich bisher gewundert hat, warum in der SELECT-Liste der Viewdefintion die beiden Assiociations _partner1 und _partner2 (Alisasnamen für Assiociations sollten mit ‚_‘ beginnen) angegeben sind, in der Ergebnisliste aber nicht wirklich aufscheinen: Damit wird Assiociation nur veröffentlicht. Sie kann also „von außen“ durch einen Aufrufer verwendet werden. Der Zugriff auf Assiociations mittels Open SQL erfolgt über Pfade:
Select PARTNER, TYPE, NAME_ORG1, NAME_LAST, MC_NAME1
from Zwb_But050_Txt_Asso_E\_partner2
![]()
Hier wird über die Entität Zwb_But050_Txt_Asso_E selektiert, es werden aber nur Felder der Assiociation _partner2 abgerufen, also Felder aus der Datenbanktabelle BUT000. Im SQL Trace (Transaktion ST05) ist der abgesetzte SELECT Befehl ersichtlich:
![]()
Es wird also zur Laufzeit ein JOIN mit der ON-Bedingung der Association gebildet.
Natürlich kann man auch nur einzelne Felder über Pfadausdrücke ansprechen:
Select Zwb_But050_Txt_Asso_E~*,
\_partner2-PARTNER as p2_partner,
\_partner2-TYPE as p2_type,
\_partner2-MC_NAME1 as p2_mc_name1
from Zwb_But050_Txt_Asso_E
![]()
Oder in der Where-Klausel verwenden:
SELECT zwb_but050_txt_asso_e~*,
\_partner2-partner AS p2_partner,
\_partner2-type AS p2_type,
\_partner2-mc_name1 AS p2_mc_name1
FROM zwb_but050_txt_asso_e
WHERE \_partner1-partner <> '0000000013'
![]()
Der Zugriff auf nicht veröffentlichte Assiociationen von außen ist nicht möglich:
![]()
Compare Filter
Wir haben bisher immer die View-Annotation
@AbapCatalog.compiler.compareFilter: true
verwendet, diese aber noch nicht erklärt. Um zu verstehen, was diese macht, müssen wir uns den generierten, technischen SQL Befehl anschauen. Das ist über das Kontextmenü möglich:
![]()
![]()
Wir erkennen, dass für die Assiociation _cattx (technischer Alias A0) nur eine JOIN Verknüpfung angelegt wird.
Setzen wir den Annotationwert auf false und betrachten den technischen SQL Befehl erneut:
![]()
Jetzt wird für jedes Assiociation-Feld eine JOIN-Bedingung definiert!
Kardinalitätsfehler in der Where-Klausel
Für das Beispiel wurde auch die Assiocation _cattx nach außen veröffentlicht.
![]()
![]()
Schritt 5 – Viewerweiterungen
SAP bietet auch die Möglichkeit CDS Views modifikationsfrei zu erweitern. Dazu kann über einen Extend View eine Entität um zusaätzliche Assiciations und Felder erweitert werden:
@AbapCatalog.sqlViewAppendName: 'ZWB_BUT050_TX7D'
@EndUserText.label: 'View Extend'
extend view Zwb_But050_Txt_Asso_E with Zwb_But050_Txt_Ext1_E
association [0..*] to but100 as _roles
on _roles.partner = but050.partner2
{
but050.relnr,
_roles
}Die Entität Zwb_But050_Txt_Asso_E liefert jetzt auch das Feld Relnr der Tabelle BUT050 und es gibt die Assiociation _roles:
![]()
Die Data Preview bietet auch die Möglichkeit auf Assiocaitions zuzugreifen:
![]()
![]()
Daten der hinzugefügten Assiociation _roles für eine Ergebniszeile der Entität.
Und auch im ABAP:
SELECT partner2 as partner,
reltyp as reltyp,
\_partner2-mc_name1 as name,
\_roles-rltyp as roletyp
FROM ZWB_BUT050_TXT_ASSO_E.
![]()
Schritt 6 – einfach ausprobieren
CDS Views erscheinen auf den ersten Blick vielleicht etwas fremd und komplex. Aber jeder ABAP Entwickler, der bereits über ein SELECT * FROM table hinausgekommen ist und etwas Erfahrung mit ADT hat, findet sich sehr schnell zurecht! Einfach mal ein paar Beispiele ausprobieren und die Templates zum Anlegen verwendet – dann wird man die CDS Views kennen und lieben lernen! Zumindest wars bei mir so ![😉]()
Und spätestens mit S/4 HANA kommen wir an CDS Views nicht mehr vorbei…
ABAP CDS Access Control mit DCL
Appendix
Mit dem Cadaxo SQL Coskpit ist es möglich die DDL Source auch im SAP GUI anzuzeigen, ohne Eclipse starten zu müssen:
![]()
ADT Templates
In den ADT können neue DDL Sourcen angelegt werden und es stehen einige Templates bereit:
![]()
![]()
<Screens skipped…>
![]()
The post ABAP CDS Views – 6 Schritte zum Verständnis appeared first on Cadaxo GmbH.
