Information

Please visit our international page to see all the numbers matching your region.

Praxishandbuch SAP CAP - Cloud Application Programming Model

Praxishandbuch SAP CAP - Cloud Application Programming Model

Sprache

Deutsch

Seiten

220

Auflage

1

Niveau

Fortgeschritten

ISBN

9783960122609

ISBN-Druck

9783960122159

Gedrucktes Buch

29.95

inkl. 7% MwSt.

  • Seiten:220
  • ISBN:9783960122609
oder Zugang zu allen Inhalten

Flatrate

19 € pro Monat

  • Einzellizenz
  • 1000+ E-Books und Videos
  • Sofortiger Zugang
  • 12 Monate(228 €pro Jahr)
  • Automatische Verlängerung

Mehr Informationen

Das SAP Cloud Application Programming Model, kurz SAP CAP, ist ein Framework zur Erstellung von Unternehmensanwendungen, das sich besonders für wiederkehrende Aufgaben eignet. Dabei vereint es SAP- und Open-Source-Technologien. Es basiert nicht auf ABAP, sondern auf einer eigenen Datendefinitionssprache, CAP CDS, sowie Java bzw. JavaScript.

In diesem Buch erklärt Ihnen der Softwareentwickler Johannes Gerbershagen zunächst die Grundlagen von SAP CAP. Sie werden mit den nötigen Entwicklungswerkzeugen, insbesondere Node.js, vertraut gemacht, lernen die Core Data Services Definition Language (CDL), die Core Data Services Query Language (CQL) und Vue.js kennen. Sie erfahren, wie Projektionen und Views, Aktionen, Funktionen und Berechtigungen aufgebaut sind, und erhalten Informationen zum Deployment. Des Weiteren stellt der Verfasser die Entwicklung einer SAP-CAP-Anwendung anhand eines Beispielfalls vor, für den er auch den Code zur Verfügung stellt. Ferner erfahren Sie, wie die Integration von SAP-CAP-Anwendungen mit bestehenden ABAP-Anwendungen funktioniert.

Das Buch ist ein kompakter, praxisnaher Helfer für Entwickler, die mit SAP CAP zu neuen Ufern aufbrechen möchten.

  • Eine Alternative zu SAP RAP, die keine ABAP-Vorkenntnisse erfordert
  • Praxisnahe Tipps für Neu-und Quereinsteiger
  • Grundlagen für die Erstellung von SAP-BTP-Anwendungen
  • Erläuterung anhand einer Beispielanwendung mit Code

Leseprobe

2.1 Core Data Services Definition Language

Die Core Data Services Definition Language (CDL) legt ihr Hauptaugenmerk darauf, Datenmodelle kurz und prägnant zu beschreiben, ohne dass dabei der Fokus auf die Problemdomäne in technischen Details verloren geht. Dazu wurde eine SQL-ähnliche Syntax entwickelt. Kernelement ist wie bei ABAP CDS und dem SAP Gateway die Entität (im folgenden CDL-Entität genannt). Eine Entität repräsentiert einen Eintrag in einer Datenbanktabelle bzw. Einträge in mehreren zusammenhängenden Datenbanktabellen und besteht aus mehreren Feldern, die einen elementaren oder zusammengesetzten Datentyp besitzen. SAP CAP veröffentlicht Entitäten mittels OData-Services.

2.1.1 Datentypen

CDL-Entitäten setzen sich aus elementaren Datentypen (CDL-Datentypen) zusammen. Tabelle 2.1 zeigt alle elementaren CDL-Datentypen. Dazu ist der jeweilige SQL-Datentyp, der bei Generierung des Datenbankschemas Anwendung findet, mit angegeben.

CDL-Datentyp Beschreibung SQL-Datentyp
UUID Eindeutige ID (36 Zeichen lang) NVARCHAR(36)
Boolean Wahrheitswert BOOLEAN
Integer Natürliche Zahl INTEGER
Integer64 Natürliche Zahl mit erweiterter Länge BIGINT
Decimal Dezimalzahl1 DECIMAL
Date Datum DATE
Time Uhrzeit TIME
DateTime Datum und Uhrzeit2 TIMESTAMP
Timestamp Zeitstempel3 TIMESTAMP
String Zeichenkette NVARCHAR
Binary Binärdaten VARBINARY
LargeString Zeichenkette mit unbegrenzter Länge NCLOB
LargeBinary Binärdaten mit unbegrenzter Länge BLOB

1 Länge und Dezimalstellen sind eine optionale Angabe. Ohne diese Angabe wird der Datentyp »DECFLOAT« verwendet.

2 Genauigkeit von einer Sekunde.

3 Genauigkeit von 0,1 µs.

Tabelle 2.1: CDL-Datentypen

CDL-Datentypen sind Case-sensitive

Anders als bei ABAP und SQL muss bei Angabe der CDL-Datentypen auf Groß- und Kleinschreibung geachtet werden.

Aus den elementaren Datentypen können Sie wie in Listing 2.1 strukturierte Datentypen erstellen. Mit dem Zusatz many lassen sich auch Array-Typen konstruieren.

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress name: String } 

Listing 2.1: Array-Typen

Der Nutzerentität aus Listing 2.1 können Sie wegen des Array-Typs mehrere E-Mail-Adressen zuordnen. Die Datenbank legt für Array-Typen ein Feld vom Typ NCLOB an und speichert die Array-Typen als JSON-Arrays.

Mit dem Zusatz type of (siehe Listing 2.2) können Sie auf andere Typen referenzieren (vergleichbar mit der LIKE-Anweisung in ABAP).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String(50) givenName: type of surName } 

Listing 2.2: Typ-Referenzen

2.1.2 Virtuelle Elemente

Der Zusatz virtual kennzeichnet virtuelle Elemente. Diese sind kein Bestandteil der Datenbank, werden aber zur Laufzeit berechnet und den OData-Services zur Verfügung gestellt (siehe Listing 2.3).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.3: Virtuelle Felder

2.1.3 Enums

Enumerationen (Enums) verwenden Sie für Variablen, die nur Werte aus einer vordefinierten endlichen Wertemenge, annehmen können, die Sie bei der Entwicklung festlegen. Beispielsweise können Sie Variablen, die den Kalendermonat oder einen akademischen Titel enthalten, mit Enums darstellen. Listing 2.4 enthält eine Enumeration mit dem akademischen Titel.

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String title: String enum { dr prof drProf } } 

Listing 2.4: Enumerationen

Enums haben im Prinzip dieselbe Funktion wie Domänenfestwerte des ABAP Dictionary.

2.1.4 Einschränkungen

Mit den Zusätzen null bzw. not null definieren Sie Einschränkungen (siehe Listing 2.5).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String not null givenName: String not null virtual completeName: String gender: String enum { male female } null } 

Listing 2.5: Einschränkungen

Die Eingabe null meint in diesem Zusammenhang den SQL-NULL-Wert, d.h., das entsprechende Feld ist undefiniert.

2.1.5 Entitäten

Entitäten leiten Sie mit dem Schlüsselwort entity bzw. define entity ein. Entitäten werden in der Datenbank gesichert und als OData-Service zur Verfügung gestellt. Sie können mithilfe der OData-Services Entitäten erstellen, lesen, ändern und löschen (CRUD-Operationen: CREATE, READ, UPDATE, DELETE).

Mit den folgenden Aspektschlüsselwörtern können Sie Entitäten um häufig benötigte Felder erweitern, ohne die Felder einzeln anzugeben:

  • managed – fügt der Entität die Felder createdAt (Label Angelegt am), createdBy (Label Angelegt von), modifiedAt (Label Geändert am) und modifiedBy (Label Geändert von) hinzu (siehe Abbildung 2.1). In Listing 2.6 verwendet die User-Entität das Aspektschlüsselwort managed und enthält damit die gleichen Felder wie die User1-Entität, der die Felder createdAt, createdBy, modifiedAt und modifiedBy manuell hinzugefügt wurden
  • cuid – ergänzt ein eindeutiges Primärschlüsselfeld (siehe Listing 2.7)
  • temporal (siehe Listing 2.8) – fügt eine zeitliche Gültigkeit hinzu (Felder validFrom, validTo in Abbildung 2.2).
using { managed, sap } from '@sap/cds/common' entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String } entity User1 { key ID : UUID createdAt: DateTime createdBy: User modifiedAt: DateTime modifiedBy: User emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.6: Entitäten mit und ohne Aspektschlüsselwort »managed«

Abbildung 2.1 enthält die Ansichtseinstellungen aus der Testvorschau für die User-Entität (siehe Listing 2.6). In Abschnitt 3.1 ist beschrieben, wie Sie die Testvorschau erstellen.

CAP

Abbildung 2.1: Aspektschlüsselwort »managed«

using { cuid, sap } from '@sap/cds/common' entity User : cuid { emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.7: Aspektschlüsselwort »cuid«

using { temporal, sap } from '@sap/cds/common' entity User : cuid, temporal { emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.8: Aspektschlüsselwort »temporal«

Abbildung 2.2 enthält die Ansichtseinstellungen aus der Testvorschau für die User-Entität (siehe Listing 2.8).

CAP

Abbildung 2.2: Aspektschlüsselwort »temporal«

2.1.6 Assoziationen und Kompositionen

Mit den Schlüsselwörtern Association bzw. Composition (siehe Listing 2.9) bestimmen Sie Zusammenhänge zwischen Entitäten (sogenannte Managed Associations bzw. Managed Compositions). Assoziationen definieren die Beziehung zwischen Positions- und Kopfdaten und Kompositionen die Beziehung zwischen Kopf- und Positionsdaten.

SAP CAP nutzt Assoziationen und Kompositionen, um Navigationseigenschaften (OData-Services) zu generieren. Mit der Assoziation bzw. der Komposition in Listing 2.9 können Sie Aktien- und Firmenobjekte in einem Aufruf lesen oder verändern.

entity Company { key id : String(3) name : String ceo : String shares : Composition of many Share on shares.company = $self volume: Integer } entity Share : cuid { timestamp : Timestamp company : Association to Company stockPrice : Decimal(10, 2) } 

Listing 2.9: Managed Association

Support-Team

  • Für weitere Hilfe besuchen Sie unsere Dokumentation oder klicken Sie auf Chat.