SAP-Praxishandbuch ABAP Core Data Services (CDS) - 2., erweiterte Auflage

2.1 ABAP Development Tools (ADT)

2.1.1 Installation

Die ABAP Development Tools basieren auf der Eclipse-Entwicklungsumgebung. Diese können Sie unter https://eclipse.org/downloads herunterladen. Bei der Installation wählen Sie zwischen verschiedenen Programmiersprachen (z.B. Java oder C++), wobei ABAP standardmäßig nicht enthalten ist. Um die ABAP-Development-Tools zu installieren, wählen Sie Help • Install New Software im Menü der Eclipse-IDE (Abbildung 2.1).

Abbildung 2.1: Eclipse-IDE – neue Software installieren

Im zweiten Schritt geben Sie die URL https://tools.hana.ondemand.com/latest in das Feld Work With ein, wählen die ABAP Development Tools in der Liste aus und bestätigen den Schritt mit Next.

Abbildung 2.2: Eclipse-IDE – ADT-URL

Im dritten Schritt installiert die Eclipse-IDE die ABAP Development Tools im Hintergrund. Sie brauchen die Eclipse-IDE nach der Installation nur neu zu starten und können mit der ABAP-Entwicklung beginnen.

2.1.2 Erste CDS-View-Entität erstellen

Um Ihre erste CDS-View-Entität zu erstellen, öffnen Sie die ADT und wählen File • New • Other (siehe Abbildung 2.3).

Abbildung 2.3: CDS-View-Entität erstellen – Schritt 1

Daraufhin öffnet sich der in Abbildung 2.4 gezeigte Dialog, in dem Sie die Kategorie Core Data Services • Data Definition auswählen.

Abbildung 2.4: CDS-View-Entität erstellen – Schritt 2

Im dritten Fenster, das Sie in Abbildung 2.5 sehen, geben Sie das Entwicklungspaket (Package), den technischen Namen sowie die Beschreibung für die Entität ein.

Abbildung 2.5: CDS-View-Entität erstellen – Schritt 3

Im vierten Fenster wählen Sie die Vorlage defineViewEntity (Abbildung 2.6).

Abbildung 2.6: CDS-View-Entität erstellen – Schritt 4

Nun öffnet sich der in Abbildung 2.7 gezeigte Editor. Dieser enthält die CDS-View-Entität in der CDS-Datendefinitionssprache, die Sie, wie bereits erwähnt, in Abschnitt 2.1.3 näher kennenlernen werden.

Abbildung 2.7: ADT-Editor mit CDS-View-Entität

In ABAP-Programmen unterscheidet sich die Handhabung von CDS-View-Entitäten und klassischen Dictionary-Views nicht. Sie können CDS-View-Entitäten folgendermaßen einsetzen:

• zur Definition von Strukturen oder internen Tabellen
• als Datenquelle in Open SQL-SELECT-Anweisungen

Die Strukturen und Tabellen können Sie nur in ABAP-Programmen definieren, nicht jedoch im ABAP-Dictionary. Wenn Sie Strukturen oder Tabellentypen im ABAP-Dictionary mit Bezug zu CDS-Entitäten definieren möchten, müssen Sie zu diesem Zweck auf CDS-Views zurückgreifen.

Die Umsetzung von in der CDS-Datendefinitionssprache geschriebenen CDS-View-Entitäten in Datenbank-Views können Sie im ADT-Editor über einen Rechtsklick im Menüpunkt Show SQL CREATE Statement überprüfen (siehe Abbildung 2.8).

Abbildung 2.8: ADT – SQL-CREATE-Anweisung

Mit den Buttons prüfen und aktivieren Sie CDS-View-Entitäten. Sie finden die Buttons mittig in der Menüleiste (Abbildung 2.9). Bei der Aktivierung erzeugt oder ändert das System den entsprechenden Datenbank-View.

Abbildung 2.9: ADT – Menüleiste

Syntaxfehler und Warnungen sehen Sie unterhalb des Editors (Abbildung 1.7).

Abbildung 2.10: ADT – Syntaxprüfung

Nachdem Sie Ihren ersten View mit der Tastenkombination Strg + S gesichert haben, können Sie diesen mit dem Button in der Menüleiste erneut öffnen. Es erscheint der in Abbildung 2.11 gezeigte Dialog, in dem Ihre zuletzt verwendeten Objekte angezeigt werden oder in dem Sie nach bestimmten Objekten suchen können.

Abbildung 2.11: ADT – Dialog zum Öffnen von Entwicklungsobjekten

Wenn Sie ein Objekt suchen, brauchen Sie nur dessen Name in das Suchfeld einzugeben. Die Entwicklungsumgebung gibt automatisch alle Objekte aus (Programme, Klassen, Funktionsgruppen, Datendefinitionen), die dem Suchbegriff entsprechen.

2.1.3 CDS-Datendefinitionssprache

Codebeispiele

Die Codebeispiele in den nachfolgenden Abschnitten basieren auf dem DMO-Namensraum, der die Abwicklung eines Flugbetriebs darstellt, sowie auf Z-Tabellen. Die Codebeispiele sollen dabei nicht die Umsetzung einer konkreten Aufgabe, sondern die Syntax und Verwendung der CDS-Datendefinitionssprache demonstrieren.

Syntax Datendefinition

In diesem Abschnitt möchte ich Ihnen den Teil der CDS-Datendefinitionssprache vorstellen, den Sie für CDS-View-Entitäten benötigen.

Eine CDS-View-Entität leiten Sie mit den Schlüsselwörtern DEFINE VIEW ENTITY ein. An diese Schlüsselwörter schließen sich die folgenden Elemente an:

1. der technische Name der CDS-Entität, den Sie bei der Erstellung gewählt haben (Abbildung 2.5)

2. die Datenquelle, die mit AS SELECT FROM eingeleitet wird dies kann eine einzelne Datenbanktabelle, eine Verknüpfung aus mehreren Datenbanktabellen (ein sogenannter JOIN bzw. eine Assoziation) oder wiederum ein CDS-View/eine CDS-View-Entität sein.

Wie bei Open SQL-SELECT-Anweisungen geben Sie als Nächstes die View-Felder in der Feldliste ein, die Sie mit geschweiften Klammern umschließen. Schlüsselfelder leiten Sie mit dem Schlüsselwort KEY ein. Bei Open SQL-Anweisungen verknüpft das Sonderzeichen »~« die Datenbanktabelle mit dem Feld. Bei CDS-View-Entitäten ersetzen Sie dieses Sonderzeichen durch einen Punkt. Mit dem Schlüsselwort AS können Sie dem Feld einen alternativen Namen (Aliasnamen) geben. In Listing 2.1 bekommt das Feld BOOKING_ID aus der Tabelle /DMO/A_BOOKING_D den Aliasnamen BOOKING_NUMBER.

@EndUserText.label: 'Flight booking' define view entity zcds2_flight_booking as select from /dmo/a_booking_d{ key booking_uuid, carrier_id, connection_id, flight_date, booking_id as booking_number, booking_date } 

Listing 2.1: Einfache CDS-View-Entität »zcds2_flight_booking«

Die erste Zeile in Listing 2.1 enthält eine sogenannte Annotation. Mit Annotationen definieren Sie während der Entwicklung Metadaten der CDS-View-Entität. In Listing 2.1 enthält die Annotation @EndUserText.label die Kurzbeschreibung der CDS-View-Entität.

Annotationen im Vergleich zu CDS-Views

Wenn Sie mit CDS-Views vertraut sind, werden Sie in Listing 2.1 bemerkt haben, dass folgende Annotationen fehlen:

• @AbapCatalog.sqlViewName
• @AbapCatalog.compiler.compareFilter
• @AbapCatalog.preserveKey

Diese Annotationen sind nur für die Generierung der Dictionary-Views relevant, die der ABAP-Applikationsserver bei CDS-Views im Hintergrund erstellt. Bei CDS-View-Entitäten benötigen Sie sie nicht mehr. Der Compiler wird Ihnen einen Fehler liefern, sobald Sie versuchen, eine der Annotationen in CDS-View-Entitäten einzufügen.

Felddefinitionen

Innerhalb von CDS-View-Entitäten können Sie nicht nur bereits vorhandene Felder aus den Datenquellen übernehmen (siehe Listing 2.1), sondern auch Felder nach eigenen Regeln definieren. Wie Sie später in diesem Abschnitt noch sehen werden, habe ich diese Möglichkeit in Listing 2.19 und Listing 2.21 genutzt. Daher möchte ich Ihnen die Regeln in diesem Abschnitt schon einmal vorstellen:

1. Aggregatsfunktionen:

• Maximum max( feld )
• Minimum min( feld )
• arithmetischer Mittelwert avg( feld )
• Summe sum( feld )
• Anzahl count(*)

Die Aggregatsfunktion wird für mehrere Einträge gebildet. Daher ist bei Verwendung einer Aggregatsfunktion immer eine GROUP BY-Klausel notwendig.

2. arithmetische Ausdrücke:

• Summe feld1 + feld2
• Subtraktion feld1 − feld2
• Multiplikation feld1 * feld2
• Division feld1 / feld2

Die Operanden müssen dabei numerische Felder sein.

3. Fallunterscheidungen: Abhängig vom Wert des Vergleichsfeldes wird der Wert des resultierenden Feldes gebildet (case feld1 when wert1 then resultat1 when wert2 then resultat2 else resultat3 end). Den Wert des resultierenden Feldes können Sie dabei aus den in dieser Liste aufgeführten Regeln festlegen. Dies kann beispielsweise ein arithmetischer Ausdruck, eine Aggregatsfunktion oder eine geschachtelte Fallunterscheidung sein.

4. Konvertierungen zwischen Dictionary-Typen, beispielsweise vom Typ Dezimalzahl in den Typ Gleitkommazahl (cast( feld1 as abap.fltp )).

Listing 2.2 zeigt die Syntax der Aggregatsfunktionen Summation (sum( price )), Maximum (max( price )), Minimum (min( price)), arithmetischer Mittelwert (avg( price as abap.curr(16, 2) )) und Anzahl (count(*)):

@EndUserText.label: 'Aggregat functions' define view entity zcds2_aggregat_functions as select from /dmo/flight { key carrier_id, key connection_id, currency_code, @Semantics.amount.currencyCode : 'currency_code' sum( price ) as sum_price, @Semantics.amount.currencyCode : 'currency_code' max( price ) as max_price, @Semantics.amount.currencyCode : 'currency_code' min( price ) as min_price, @Semantics.amount.currencyCode : 'currency_code' avg( price as abap.curr(16, 2) ) as avg_price, count(*) as flight_count } group by carrier_id, connection_id, currency_code 

Listing 2.2: Felddefinitionen mittels Aggregatsfunktionen

Listing 2.3 zeigt die Syntax für:

1. arithmetische Ausdrücke (seats_max – seats_occupied subtrahiert die Anzahl belegter Sitzplätze von der maximalen Sitzplatzanzahl)

2. Fallunterscheidungen (case plane_type_id when 'A340' then 4 else 2 end gibt vier Triebwerke für den Flugzeugtyp A340 aus, sonst zwei)

3. Konvertierungen (cast( price as abap.fltp ) konvertiert den Preis in eine Gleitkommazahl)

@EndUserText.label: 'Field rules' define view entity zcds2_field_rules as select from /dmo/flight{ key carrier_id, key connection_id, key flight_date, seats_max, seats_occupied, seats_max - seats_occupied as free_seats, plane_type_id, case plane_type_id when 'A340' then 4 else 2 end as engines, cast( price as abap.fltp ) as price_float } 

Listing 2.3: Felddefinitionen mittels arithmetischer Ausdrücke – Fallunterscheidungen und Konvertierungen

Diese Regeln sind schachtelbar. Einen arithmetischen Ausdruck können Sie beispielsweise mit einer Aggregatsfunktion umschließen.

Verknüpfungen aus mehreren Datenbanktabellen

Wie bereits erwähnt, kann eine CDS-View-Entität mehrere Datenbanktabellen als Quellen enthalten. Zur Verknüpfung dieser Datenbanktabellen bestehen folgende Möglichkeiten:

• INNER JOIN
• LEFT OUTER JOIN
• RIGHT OUTER JOIN
• CROSS JOIN
• Assoziation

Die Ergebnismenge weist jeweils folgenden Inhalt auf:

• INNER JOIN: alle Zeilen, die in beiden Tabellen gemeinsam enthalten sind. Abbildung 2.12 zeigt einen INNER JOIN zwischen den Tabellen /DMO/CONNECTION und /DMO/FLIGHT. Die Ergebnismenge enthält die Verbindung AA/100, da sie sowohl in der Tabelle /DMO/CONNECTION als auch in der Tabelle /DMO/FLIGHT vorkommt. Die Verbindung BA/400 ist nicht in der Ergebnismenge enthalten, da Sie in der Tabelle /DMO/CONNECTION, aber nicht in der Tabelle /DMO/FLIGHT vorkommt. Der Flug XS/900/07.01.2025 kommt nicht in der Ergebnismenge vor, da er zwar in der Tabelle /DMO/FLIGHT vorkommt, nicht jedoch in der Tabelle /DMO/CONNECTION.
• LEFT OUTER JOIN: alle Zeilen, die in der Tabelle der linken Seite enthalten sind. Fehlt die Zeile in der Tabelle der rechten Seite, sind die Felder dieser Tabelle in der Ergebnismenge mit Initialwerten gefüllt. Abbildung 2.13 zeigt einen LEFT OUTER JOIN zwischen den Tabellen /DMO/CONNECTION (linke Seite) und /DMO/FLIGHT (rechte Seite). Die Ergebnismenge enthält alle Zeilen der Tabelle /DMO/CONNECTION. Der Eintrag BA/400 ist beim LEFT OUTER JOIN in der Ergebnismenge mit initialem Flugdatum vorhanden, obwohl die Tabelle /DMO/FLIGHT diese Verbindung nicht enthält.
• RIGHT OUTER JOIN: alle Zeilen, die in der Tabelle der rechten Seite enthalten sind. Fehlt die Zeile in der Tabelle der linken Seite, enthalten die Felder dieser Tabelle in der Ergebnismenge Initialwerte. Abbildung 2.14 zeigt einen RIGHT OUTER JOIN zwischen den Tabellen /DMO/FLIGHT (linke Seite) und /DMO/CONNECTION (rechte Seite). Diesmal enthält die Ergebnismenge die Verbindung AA/100 sowie den Flug XS/900/07.01.2025. Der Flug XS/900/07.01.2025 ist nur in der Tabelle /DMO/FLIGHT (rechte Seite) vorhanden und daher trotzdem Bestandteil der Ergebnismenge. Die Verbindung BA/400 ist nicht in der Ergebnismenge vorhanden, da sie nicht in der Tabelle /DMO/FLIGHT vorkommt.
• CROSS JOIN: das Kreuzprodukt aus den Zeilen der Tabelle der linken Seite und rechten Seite.

Abbildung 2.12: INNER JOIN – Ergebnismenge

Abbildung 2.13: LEFT OUTER JOIN – Ergebnismenge

Abbildung 2.14: RIGHT OUTER JOIN – Ergebnismenge

Assoziationen können Sie mithilfe von Pfadausdrücken als INNER JOIN oder als LEFT OUTER JOIN implementieren. Die Definition /dmo/carrier[left outer].carrname in Listing 2.5 stellt einen Pfadausdruck dar. In eckigen Klammern finden Sie die Information, dass die Tabelle /DMO/CARRIER über einen LEFT OUTER JOIN mit der Tabelle /DMO/CONNECTION verknüpft ist, die sich auf der linken Seite der Assoziation befindet.

Wenn Sie auf die Angabe eines Pfadausdrucks (siehe Listing 2.4) verzichten, wandelt das System die Assoziation bei der Aktivierung automatisch in einen LEFT OUTER JOIN um.

@EndUserText.label: 'CDS view with association' define view entity zcds2_flight_plan_association as select from /dmo/connection association to /dmo/carrier on /dmo/carrier.carrier_id = /dmo/connection.carrier_id{ key carrier_id, key connection_id, airport_from_id, airport_to_id, /dmo/carrier.name as carrier_name } 

Listing 2.4: Assoziation ohne Pfadausdrücke

Listing 2.5 zeigt, wie Sie Pfadausdrücke in CDS-View-Entitäten angeben.

@EndUserText.label: 'Association with path' define view entity zcds2_flight_plan_associatio_o as select from /dmo/connection as co association to /dmo/flight as fl on fl.carrier_id = co.carrier_id and fl.connection_id = co.connection_id{ key co.carrier_id, key co.connection_id, max( fl[left outer].flight_date ) as last_flight_date } group by co.carrier_id, co.connection_id 

Listing 2.5: Assoziation mit Pfadausdrücken

In diesem Listing wird die Assoziation zwischen den Tabellen /DMO/CONNECTION und /DMO/FLIGHT bei der Aktivierung in einen LEFT OUTER JOIN umgewandelt. Das heißt, die CDS-View-Entität in Listing 2.5 liefert das gleiche Resultat wie die in Listing 2.6 dargestellte Open SQL-Anweisung:

SELECT co~carrier_id, co~connection_id, max( fl~flight_date ) AS last_flight_date FROM /dmo/connection AS co LEFT OUTER JOIN /dmo/carrier AS fl ON fl~carrier_id = co~carrier_id AND fl~connection_id = co~connection_id GROUP BY co~carrier_id, co~connection_id. 

Listing 2.6: Assoziation mit Open SQL-Anweisungen

Wie in Abbildung 2.8 gezeigt, können Sie die Umsetzung der Assoziationen in SQL-JOINs anhand der SQL-CREATE-Anweisung verifizieren.

Die CDS-View-Entität ZCDS2_FLIGHT_PLAN_ASSOCIATIO_O in Listing 2.5 enthält nur einen Pfadausdruck. Bei mehreren Pfadausdrücken ist es oft wünschenswert, individuelle Bedingungen je Pfadausdruck festzulegen. Aufgrund dessen kann jeder Pfadausdruck neben der JOIN-Definition (INNER, LEFT OUTER) auch eine eigene Filterbedingung (WHERE-Bedingung) enthalten. Die CDS-View-Entität in Listing 2.7, die dies demonstrieren soll, gibt die durchschnittlichen Flugpreise in den Kalenderjahren 2024 und 2025 aus. Hierfür wurden zwei Pfadausdrücke mit individuellen Filterbedingungen verwendet.

@EndUserText.label: 'Association with paths' define view entity zcds2_avg_flight_prices as select from /dmo/connection as co association to /dmo/flight as fl on fl.carrier_id = co.carrier_id and fl.connection_id = co.connection_id{ key co.carrier_id, key co.connection_id, fl.currency_code, @Semantics.amount.currencyCode: 'currency_code' avg( fl[left outer where flight_date between '20240101' and '20241231'].price as abap.curr(16, 2) ) as avg_flight_price_2024, @Semantics.amount.currencyCode: 'currency_code' avg( fl[left outer where flight_date between '20250101' and '20251231'].price as abap.curr(16, 2) ) as avg_flight_price_2025 } group by co.carrier_id, co.connection_id, fl.currency_code 

Listing 2.7: Pfadausdrücke – individuelle Assoziationsbedingungen

Die CDS-View-Entität ZCDS2_AVG_FLIGHT_PRICES in Listing 2.7 liefert das gleiche Resultat wie die in Listing 2.8 dargestellte Open SQL-Anweisung.

SELECT co~carrier_id, co~connection_id, fl24~currency_code, avg( fl24~price ) as avg_flight_price_2024, avg( fl25~price ) as avg_flight_price_2025 FROM /dmo/connection AS co LEFT OUTER JOIN /dmo/flight AS fl24 ON fl24~carrier_id = co~carrier_id AND fl24~connection_id = co~connection_id AND fl24~flight_date BETWEEN '20240101' and '20241231' LEFT OUTER JOIN /dmo/flight AS fl25 ON fl25~carrier_id = co~carrier_id AND fl25~connection_id = co~connection_id AND fl25~flight_date BETWEEN '20250101' and '20251231' GROUP BY co~carrier_id, co~connection_id, fl24~currency_code. 

Listing 2.8: Assoziation mit Open SQL-Anweisungen

Im Vergleich zu klassischen Dictionary-Views, die nur die Möglichkeit des INNER JOIN kennen, bieten Ihnen CDS-View-Entitäten weitaus mehr JOIN-Möglichkeiten.

Assoziationsbedingungen

In den Assoziationsbedingungen können Sie mit dem Schlüsselwort $projection auf ein Element der Feldliste verweisen. Die CDS-View-Entität in Listing 2.9 liefert genau die gleichen Daten wie die Entität ZFLIGHT_PLAN_ASSOCIATION aus Listing 2.4. Nur wurde hier in der Assoziationsbedingung mit $projection.carrier auf die Fluggesellschaft verwiesen.

@EndUserText.label: 'Association with projection' define view entity zcds2_flight_plan_association1 as select from /dmo/connection as co association to /dmo/carrier as ca on ca.carrier_id = $projection.carrier_id{ key co.carrier_id, key co.connection_id, co.airport_from_id, co.airport_to_id, ca.name as carrier_name } 

Listing 2.9: Assoziation mit $projection-Schlüsselwort

Kardinalität

Nach dem Schlüsselwort ASSOCIATION können Sie zu Dokumentationszwecken die Kardinalität der Assoziation in eckigen Klammern angeben. Die Umsetzung der CDS-View-Entität in einen Datenbank-View ist unabhängig von der Kardinalitätsangabe. Die ADT-Syntaxprüfung gibt Ihnen bei einer ungültigen Kardinalitätsangabe nur eine Warnung aus. Listing 2.10 zeigt eine Kardinalitätsangabe.

@EndUserText.label: 'Association with projection' define view entity zcds2_flight_plan_association1 as select from /dmo/connection as co association[0..1] to /dmo/carrier as ca on ca.carrier_id = $projection.carrier_id{ key co.carrier_id, key co.connection_id, co.airport_from_id, co.airport_to_id, ca.name as carrier_name } 

Listing 2.10: Assoziation mit Kardinalitätsangabe

[0..1] bedeutet, dass für jeden Eintrag in der Tabelle /DMO/CONNECTION keinen oder höchstens einen korrespondierenden Eintrag in der Tabelle /DMO/CARRIER existiert.

Folgende Kardinalitäten können Sie vergeben:

• [0..1] für keinen bis höchstens einen korrespondierenden Eintrag
• [0..*] für beliebig viele korrespondierende Einträge (einschließlich 0 korrespondierende Einträge)
• [1..1] für genau einen korrespondierenden Eintrag
• [1..*] für mindestens einen korrespondierenden Eintrag

UNION-Klauseln

Mit der UNION-Klausel bilden Sie Vereinigungsmengen aus mehreren ähnlichen Datenquellen. Im Gegensatz zu den in vorherigen Abschnitten dargestellten Verknüpfungen definieren Sie bei Bildung einer Vereinigungsmenge keine Assoziations- oder JOIN-Bedingungen. Die Vereinigungsmenge nimmt nacheinander die Datensätze aus den einzelnen Quellen auf.

Zur Bildung einer Vereinigungsmenge müssen die Datenquellen mehrere gemeinsame Felder besitzen. Und die Feldlisten, die innerhalb der CDS-View-Entitäten für jede Datenquelle definiert werden, müssen den folgenden Voraussetzungen genügen:

• Die Anzahl Felder ist in jeder Feldliste identisch.
• Die Felder müssen auf denselben Positionen identische Dictionary-Typen besitzen.

Position meint in diesem Zusammenhang die Spalte. Spalte 1 entspricht Position 1, Spalte 2 Position 2 etc.

Als Beispiel dienen die Tabellen /DMO/BOOKING (Listing 2.11) und /DMO/A_BOOKING_D (Listing 2.12), aus denen eine Vereinigungsmenge gebildet werden soll. Die Vereinigungsmenge soll alle Buchungen enthalten – unabhängig davon, ob die einzelne Buchung in der Tabelle /DMO/BOOKING, in der Tabelle /DMO/A_BOOKING_D oder in beiden Tabellen vorhanden ist. Eine Buchung, die in beiden Tabellen vorhanden ist, soll in der Vereinigungsmenge nur einmal vorkommen.

@EndUserText.label : 'Flight Reference Scenario: Booking' @AbapCatalog.enhancement.category : #NOT_EXTENSIBLE @AbapCatalog.tableCategory : #TRANSPARENT @AbapCatalog.deliveryClass : #A @AbapCatalog.dataMaintenance : #RESTRICTED define table /dmo/booking { key client : abap.clnt not null key travel_id : /dmo/travel_id not null key booking_id : /dmo/booking_id not null gr_data : include /dmo/booking_data } 

Listing 2.11: Tabelle /DMO/BOOKING

@EndUserText.label : 'Active Booking Persistence for Draft Reference Scenario' @AbapCatalog.enhancement.category : #NOT_EXTENSIBLE @AbapCatalog.tableCategory : #TRANSPARENT @AbapCatalog.deliveryClass : #A @AbapCatalog.dataMaintenance : #RESTRICTED define table /dmo/a_booking_d { key client : abap.clnt not null key booking_uuid : sysuuid_x16 not null parent_uuid : sysuuid_x16 booking_id : /dmo/booking_id not null booking_date : /dmo/booking_date customer_id : /dmo/customer_id carrier_id : /dmo/carrier_id connection_id : /dmo/connection_id flight_date : /dmo/flight_date @Semantics.amount.currencyCode : '/dmo/a_booking_d.currency_code' flight_price : /dmo/flight_price currency_code : /dmo/currency_code booking_status : /dmo/booking_status local_last_changed_at : abp_locinst_lastchange_tstmpl } 

Listing 2.12: Tabelle /DMO/A_BOOKING_D

Listing 2.13 zeigt, wie Sie die Vereinigungsmenge mit Open SQL und ABAP bilden können.

SELECT booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date FROM /dmo/booking INTO TABLE @DATA(bookings). SELECT booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date FROM /dmo/a_booking_d APPENDING CORRESPONDING FIELDS OF TABLE @bookings. SORT bookings. DELETE ADJACENT DUPLICATES FROM bookings. 

Listing 2.13: Vereinigungsmenge mit Open SQL

Listing 2.14 zeigt eine CDS-View-Entität zur Bildung der Vereinigungsmenge.

@EndUserText.label: 'Union clause for flight booking' @Metadata.ignorePropagatedAnnotations: true define view entity zcds2_booking_union as select from /dmo/booking{ key booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date } union select from /dmo/a_booking_d{ key booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date } 

Listing 2.14: Vereinigungsmenge mit CDS-View-Entität

Beide Lösungen liefern das gleiche Resultat: In Listing 2.13 liegt dies als interne Tabelle vor, in Listing 2.14 als Datenbank-View.

Wollen Sie doppelte Einträge beibehalten, können Sie die SORT- und die DELETE-ADJACENT-DUPLICATES-Anweisung in Listing 2.13 weglassen. In der CDS-View-Entität aus Listing 2.14 fügen Sie – wie in Listing 2.15 – das Schlüsselwort ALL nach dem Schlüsselwort UNION ein. Doppelte Einträge bleiben damit in der Vereinigungsmenge bestehen.

@EndUserText.label: 'Union clause for flight booking' @Metadata.ignorePropagatedAnnotations: true define view entity zcds2_booking_union as select from /dmo/booking{ key booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date } union all select from /dmo/a_booking_d{ key booking_id, booking_date, customer_id, carrier_id, connection_id, flight_date } 

Listing 2.15: Vereinigungsmenge mit Duplikaten