Skript: Recycling-Heroes - RAP Modeling Contact [010]

Inhaltsverzeichnis

• Datenmodell
• RAP Objekt
• Draft und Service
• Fehlerbehebung
• Testdaten
• Zusammenfassung

Einleitung 

In der heutigen Folge bauen wir das RAP-Objekt manuell auf und erklären das Classic Pattern im Detail. Damit richtet sich der erste Aufbau des Objekts an neue Entwickler im Bereich ABAP RESTful Application Programming Model. Wir werden dabei Stück für Stück die einzelnen Layer aufbauen.

 

Datenmodell

Beginnen wir deshalb beim Datenmodell der eigentlichen Datenbank Tabelle. Über das Kontextmenü können wir uns ein neues Repository-Objekt anlegen. Hier können wir nach "Database Table" suchen. Wir vergeben einen Namen, eine Beschreibung und ordnen das Objekt einem Transport zu. Beim nächsten Schritt definieren wir uns alle Felder, die wir auch im Datenmodell bereits definiert haben. Dabei kannst du grundsätzlich mit der Anlage der Tabelle beginnen alle Felder und Datentypen herunterschreiben, auch wenn diese noch nicht vorhanden sind. Sind wir mit der Anlage der Felder fertig, beginnen wir mit der weiteren Anlage der verschiedenen Typen. Speichern wir die Tabelle, dann wird diese automatisch für uns formatiert. 

Um das erste Datenelement anzulegen, verwenden wir den Quick-Fix in den ABAP Development Tools. Über den Kontext können wir ein neues Datenelement anlegen. Der Name und das Paket werden bereits aus dem Kontext vorgeschlagen und eine Beschreibung definieren wir noch zusätzlich. Möchten wir eine eigene Domäne anlegen, kopieren wir uns den gleichen Namen in das Feld "Type". Zusätzlich vergeben wir noch entsprechende Labels, die wir später in unserer Anwendung sehen. Über einen Klick auf den Link können wir uns die Domäne anlegen und dorthin navigieren. Dort tragen wir einen entsprechenden Datentyp ein und die Länge und aktivieren das Element. Nach der Aktivierung können wir zurückgehen und ebenfalls das Datenelement aktivieren. Und wenn wir dann den Prüfen Button betätigen, ist es ein Fehler weniger und wir können mit dem nächsten Datenelement weitermachen. In diesem Fall legen wir uns den "Contact type" an. Dieser bekommt ebenfalls eine zusätzliche Domäne. Dies hat den Grund, da wir verschiedene Festwerte definieren wollen, die wir später als Möglichkeit zur Verfügung stellen wollen. Hier gibt es die Werte "CU" für Customer, "EM" für Employee und "AD" für Address. Auch hier wieder die entsprechenden Elemente aktivieren und danach schließen, um zurück zur Tabelle zu kommen. Definieren wir nun die weiteren Elemente, die wichtig sind. Grundsätzlich legen wir uns auch Datentypen an die wir übergreifend verwenden, wie zum Beispiel den Text100 ein Character Feld, was 100 Zeichen Länge hat und Groß- und Kleinschreibung beachtet. Damit können wir dieses später bei anderen Feldern verwenden und müssen nicht immer separat eine eigene Domäne anlegen. Eine Besonderheit beim Datenmodell ist noch, dass wir für die Country das Datenelement LAND1 verwenden, welches aus dem Standard kommt und für ABAP Cloud freigegeben ist. 

Sind wir mit der Anlage der Tabelle fertig, können wir diese aktivieren, um sie auf der Datenbank anzulegen. Im Anschluss öffnen wir die Tabelle im Project Explorer und können über das Kontextmenü einen neuen Core Data Service dafür anlegen. Dieser Core Data Service ist ein Base View und propagiert unsere Tabelle nach außen. Der CDS View hat den Typ "View Entity", die heute als Standard in der CDS Entwicklung gelten. Das System schlägt uns bereits entsprechende Namen vor, die wir so weit akzeptieren, einmal formatieren und den View zum Abschluss aktivieren.

 

RAP Objekt

Eine Änderung müssen wir allerdings vornehmen, da wir später einen RAP-Objekt mit Draft Funktionalität haben wollen, müssen wir die typischen Draft Felder noch in die Tabelle einfügen. Dazu können wir uns das Code Snippet über den Code Snippet Bereich auf der Webseite besorgen. Über das Git Repository können wir uns über einen einfachen Kopieren Button das Snippet kopieren und in die Tabelle einfügen. Das Ganze müssen wir jetzt noch auf der Ebene des Core Data Service machen, dazu gibt es ein zweites Code Snippet mit den entsprechenden Annotationen und den aufbereiten Namen. Zum Abschluss einmal beide Objekte aktivieren.

Haben wir diese Änderung durchgeführt, können wir den Core Data Service für unser RAP Objekt einlegen. Dazu gehen wir auf dem bestehenden Base View und können über das Kontextmenü unseren neuen Root View anlegen. Das TP am Ende bedeutet Transactional Provider, weil wir eine transaktionales Verhalten implementieren werden. Wir wählen das Template "define root view entity" und lassen uns den View generieren. Zum Abschluss müssen wir noch einige Informationen entfernen und können dann den View noch einmal formatieren. Damit haben wir den Root View im System angelegt. Als nächstes können wir auf dem View unseren Consumption View anlegen. Dazu wieder über das Kontextmenü gehen, den Consumption View anlegen, einen Namen vergeben und eine Beschreibung. Am Ende wählen wir das Template für den Projection View aus. Hier müssen wir noch zusätzlich den Provider Contract hinzufügen, diesen findest du über den Quick-Fix. Hier wählen wir "Transactional Query". Zum Abschluss nicht vergessen auch das Wort "root" hinzuzufügen, da dieser Teil zum Root View gehört. Zum Abschluss fügen wir noch das Tag "metadata allow extension" hinzu, um später eine Metadata Extension auf dem CDS View erzeugen zu können. 

Im nächsten Schritt können wir das Verhalten anlegen. Dazu über das Kontextmenü unseres Root View gehen und dort eine neue Verhaltensdefinition anlegen. Hier gehen wir mit dem "Managed" Ansatz. Nachdem die Verhaltensdefinition angelegt wurde, können wir anfangen sie anzupassen. Dazu definieren wir zum Beispiel den Alias und geben der Verhaltensklasse einen passenden Namen. Im nächsten Schritt definieren wir uns für die Tabelle ein Mapping. Das Mapping geht vom Core Data Service auf die eigentliche Tabelle, hier müssen wir die verschiedenen Felder aufeinander Mappen. Sind wir damit fertig, lassen wir uns die Klasse im System generieren, formatieren diese einmal und aktivieren sie. Damit ist die Grundlage der Verhaltensdefinition angelegt und wir können uns den nächsten Teil anschauen.

 

Draft und Service

Nun wollen wir den Draft in der Verhaltensdefinition aktivieren. Dazu fügen wir im Header den Zusatz "with draft" hinzu. Auf Ebene der Entität ergänzen wir die Draft-Tabelle und geben der Tabelle einen neuen Namen. Über die Quick-Fix-Funktionalität lassen wir uns die Tabelle generieren. Hier haben wir eigentlich fast keinen Aufwand, außer der Anlage und der Aktivierung der Tabelle. Ist die Draft-Tabelle aktiviert, können wir diese schließen und zurück zur Verhaltensdefinition gehen. Wenn wir nun auf den Prüfen-Button gehen, kommen weitere Fehlermeldungen, die wir beheben müssen. Dazu müssen wir zum Beispiel den Lock-Master ergänzen und das E-Tag hinzufügen. Hier verwenden wir das Feld "Last changed". Zusätzlich müssen wir auch den E-Tag-Master implementieren und dort das Feld "local last changed date" hinterlegen. Da wir uns im Draft befinden, müssen wir noch zusätzlich weitere Aktionen, die für den Draft notwendig sind, hinzufügen. Dazu gibt es zum Beispiel die Draft-Action für "Edit", diese können wir uns dann kopieren und die entsprechenden Namen abändern. Wir fügen daher noch eine "Activate" Action und eine "Discard" Action zum Aktivieren und zum Zurücknehmen hinzu, genauso wie für Resume. Bei "Activate" ergänzen wir noch den "Optimized"-Zusatz, damit die Warnmeldung verschwindet. Möchten wir das Ganze nun aktivieren, kommt noch eine Fehlermeldung, dass die entsprechende "Prepare" Action hinzugefügt werden muss? Hierbei handelt es sich um eine "Determine Action". Sind wir damit fertig, können wir die Verhaltensdefinition aktivieren. 

Nun können wir damit beginnen, auf dem Consumption View die Projektion dafür anzulegen. Nach der Anlage der Projection ergänzen wir noch den Alias. Ansonsten müssen wir keine weiteren Änderungen vornehmen. Ist die Verhaltensdefinition nun aktiviert, können wir mit der Anlage des eigentlichen Services beginnen. Dazu legen wir uns eine neue Service Defination an und geben ihr einen Namen oder eine Beschreibung. Da wir über das Kontextmenü den neuen Service angelegt haben, wird unsere Entität bereits freigegeben. Hierfür vergeben wir noch einen Alias, über den die Entität im Service ansprechbar ist. Zusätzlich suchen wir noch nach der Annotation für die Leading-Entity, kopieren uns den Namen und fügen diesen dann ein. Die Annotation bewirkt, dass am Ende die Entität im Service Binding hervorgehoben wird. Zum Abschluss definieren wir uns das neue Service Binding. Dazu können wir wieder über das Kontextmenü der Service Definition gehen. Dort vergeben wir einen entsprechenden Namen und wählen den entsprechenden Binding-Type aus. Da wir einen UI Service erstellen wollen und mit Draft arbeiten, wählen wir den OData Version 4 für UI. Zum Abschluss aktivieren wir das Service Binding und veröffentlichen den Service über den "Publish" Button. Dieser Vorgang kann einige Minuten in Anspruch nehmen. Wurde die Aktivierung durchgeführt, können wir über den "Preview" Button die Anwendung starten.

 

Fehlerbehebung

Aktuell haben wir einen Fehler beim Laden der Anwendung. Hierzu können wir die Entwicklerkonsole des Browsers über F12 aufrufen. Schauen wir dort in die Konsole finden wir eine Fehlermeldung, die uns sagt, dass die App nicht geladen werden konnte, weil das Feld ContactType mehrfach definiert ist. Dies deutet darauf hin, dass unser Feld aus dem Core Data Service nicht den gleichen Namen haben kann, wie der Typ der Entität der automatisch generiert wurde. Daher gehen wir in den Core Data Service und ändern das Feld auf "ContactTypeInt" ab. Diesen Vorgang wiederholen wir durch die komplette Hierarchie bis zum Consumption View. In der Verhaltensdefinition müssen wir zusätzlich noch das Mapping anpassen. Wir können nun versuchen die Objekte zu aktivieren. Dabei wird es weiterhin zu einem Fehler innerhalb der Verhaltensdefinition kommen. Hier ist das Problem, dass wir die Draft-Tabelle erneut erzeugen müssen. Über den Quick-Fix können wir ganz einfach die Draft-Tabelle noch einmal generieren lassen und können diese im Anschluss aktivieren. Um weitere Fehler prüfen zu können, öffnen wir das Service Binding und drücken dort auf den Button prüfen, um weitere Informationen zu erhalten, ob noch Fehler in der Entität vorhanden sind. Sind keine Fehler mehr vorhanden, können wir die Anwendung noch einmal aktualisieren und erhalten dieses Mal eine leere Liste. Über die verschiedenen Einstellungen können wir die Liste der Felder sehen, Filter einblenden und die Felder in der Liste anzeigen. Da wir noch keine Daten haben, sehen wir aktuell noch keine Datensätze in der Liste.

 

Testdaten

Dazu legen wir uns erst einmal eine neue Klasse an, um Testdaten in unserer Tabelle zu generieren. Die Klasse legen wir in dem "Test"-Paket innerhalb der Software-Komponente an. Der Klasse geben wir einen Namen, eine Beschreibung und fügen das Interface für ausführbare Klassen hinzu. Nachdem die Klasse im System generiert wurde, können wir damit beginnen, eine interne Tabelle anzulegen, die wir mit den Daten befüllen können. Im Anschluss können wir über das VALUE Statement Daten in die Tabelle übernehmen. Zum Abschluss wollen wir immer alle Daten aus der Tabelle löschen, bevor wir die neuen Daten aus unserer internen Tabelle einfügen. Aus Clean ABAP Gesichtspunkten sollten wir natürlich unsere Tabelle nach dem Inhalt benennen.

Dann öffnen wir die Tabelle. Um alle Felder zur Verfügung zu haben, kopieren wir uns diese einmal und fügen sie zwischen den Klammern ein. Über die Blockfunktion der ABAP Development Tools können wir dann den gesamten Block bearbeiten. Damit löschen wir die Typdefinition und ergänzen die leeren Literale. Dann deaktivieren wir die Blockfunktion und löschen das Client-Feld und entfernen den Key Zusatz. Nun können wir damit beginnen erste Inhalte in die verschiedenen Felder zu übernehmen. Dabei denken wir uns erst einmal einige Inhalte aus, damit wir später etwas in der Anzeige zur Verfügung haben. Sind wir damit fertig, legen wir noch einen zweiten Datensatz an, um später auch den Filter zu validieren. Dabei ändern wir aber nur einige wenige Daten ab, da das für den Anfang reichen sollte. Sind wir damit fertig, führen wir die Klasse einmal aus und lassen uns die Daten in der Tabelle generieren. Um dann die Daten zu überprüfen, öffnen wir die Tabelle und führen mit F8 die Data Preview aus. Wir sehen die beiden Datensätze in der Tabelle und haben damit alle Testdaten erzeugt.

 

Zusammenfassung

In dieser Folge haben wir uns angeschaut, wie wir manuell die verschiedenen Layer des RAP Stacks erzeugen und die Draft Funktionalität implementieren. Wir haben uns einen Fehlerfall angeschaut, der bei der Modelierung auftreten kann und zum Abschluss haben wir Testdaten für unser RAP Objekt erzeugt.

Danke fürs Zuschauen und bis zum nächsten Mal.

 

YouTube
Video