ODATA Grundlagen: Services aus der UI5 App verwenden
Nachdem der OData Service in der Transaktion SEGW angelegt und im Gateway Client ausführlich getestet wurde, verlassen Sie endgültig die vertraute SAP Backend Umgebung. Jetzt kommt es darauf an, den Service auch entsprechend aus dem Frontend nutzen zu können.
Hierfür zeige ich Ihnen in diesem Beitrag die wichtigsten Varianten für die Verwendung der Services direkt aus der XML View und aus dem JavaScript Controller heraus. Als Szenario verwende ich hierfür eine UI5 SplittApp, welche den im vorigen Beitrag implementierten Service nutzt, um Personendaten zu übertragen. Die SplittApp hat dafür auf der linken Seite eine Masteransicht, auf der eine Übersicht aller zur Verfügung stehenden Personen zu sehen sein soll. Auf der rechten Seite können neue Entitäten angelegt und ans Backend übertragen werden, oder aber Details der vorhandenen Personen eingesehen werden. Auf die Details der SplittApp gehe ich in diesem Beitrag nicht ein, heute soll der Fokus auf der Verwendung von OData Standard Methoden liegen.
Inhalte
- Einrichten des OData Service als Datenquelle für die App
- DataBinding in der XML View
- Ansteuern der OData Standard Methoden
- Lesen und Ändern der Model Attribute
- Templating im Javascript
Einrichten des OData Service als Datenquelle für die App
Um einen OData Service aus der UI5 App verwenden zu können, muss dieser zuerst als Datenquelle für die Anwendung angelegt werden. Eine Möglichkeit dafür ist, in die Datei “manifest.json” zu gehen. Dort findet sich unter dem Reiter “Data Sources” die Möglichkeit, einen neuen Odata Service zu hinterlegen. Hier können Sie einfach nach dem Gateway System suchen, auf dem Sie den Service registriert haben und anschließend nur noch bestätigen. Der Service sollte nun als Datenquelle eingerichtet und als Default Model hinterlegt sein.
Zur Überprüfung können Sie im Reiter “Models” schauen, ob das Default Model befüllt ist. Damit ich im weiteren Verlauf alle Operationen zeigen kann, habe ich die Einstellungen des Default Models wie folgt eingerichtet:
DataBinding in der XML View
In der Detail View meiner SplittApp habe ich mir eine Struktur mit einem Form aufgebaut, damit die Einträge ordentlich untereinander angeordnet sind. Später werde ich eine Entität meines OData Services an die View binden. Hierfür richte ich im XML bereits das entsprechende Data Binding ein, um die Attribute anzeigen zu können:
In dieser View binde ich Attribute von 2 verschiedenen Models: Zum einen meine OData Entität, welche ich später an die View binden werde. Diese steuere ich einfach mit “{Attributname}” an. In diesem Fall zeige ich die Attribute jeweils im Form Field als Text an. Die Namen der Attribute müssen natürlich 1:1 mit den Namen übereinstimmen, welche im Entitätstypen in der Transaktion SEGW auch zu sehen sind. Bitte beachten Sie hierbei auch Groß- und Kleinschreibung.
Das zweite Model ist i18n. Hier sind all meine freien Texte gespeichert, um Mehrsprachigkeit und Übersetzungen zu vereinfachen. Dieses steuere ich mit “{i18n>Attributname}” an. In meinem Beispiel habe ich die Labels, also die Bezeichnungen meiner Felder alle damit umgesetzt.
Ansteuern der ODATA Standard Methoden
Bislang ist das Data Binding zwar in der Detail View vorbereitet, allerdings wird der OData Service noch nicht aufgerufen und dementsprechend gibt es auch keine Daten zum Anzeigen. Dafür zeige ich Ihnen im Folgenden, wie Sie die 5 OData Standart Methoden GET_ENTITYSET, GET_ENTITY, UPDATE_ENTITY, DELETE_ENTITY und CREATE_ENTITY aus der UI5 Anwendung aufrufen können.
GET_ENTITYSET
Der Aufruf von GET_ENTITYSET kann ganz einfach aus der XML View getätigt werden. Dafür erstelle ich in der Master View eine Liste, in welcher die Ergebnisse des Aufrufs angezeigt werden sollen. In der Liste wird über items=”{/PersonSet}” automatisch eine GET_ENTITYSET Anfrage ans Backend gesendet. Die Ergebnisse werden dann in der Liste aufgeführt. Damit feststeht, welche Attribute der Ergebnismenge eigentlich angezeigt werden sollen, können Sie wieder DataBinding verwenden. In diesem ObjectAttribute ist das DataBinding noch etwas aufwändiger, da ich das Datum anzeigen möchte und hierfür neben dem reinen Pfad auch noch Optionen zur Formatierung übergebe:
Ich habe also pro Eintrag der Ergebnismenge einen Eintrag in meiner Master Liste, zu dem mir der Name als Titel und das Geburtsdatum als Zusatzinformation angezeigt werden:
GET_ENTITY
Aktuell werden mir alle Ergebnisse vom GET_ENTITYSET in der Master Liste angezeigt. Nun möchte ich, dass ein GET_ENTITY Aufruf gestartet wird, sobald ich einen der Einträge in der Liste anklicke und das Ergebnis rechts in der Detail Ansicht zu sehen ist. Das notwendige Data Binding in der Detail View ist bereits vorbereitet. Um den Backend Aufruf zu starten, starte ich im Detail Controller den Aufruf “bindElement()” auf die entsprechende View. Hierfür übergebe ich in der Navigation den angeklickten Pfad. Hierfür gibt es verschiedene Möglichkeiten. In meinem Fall ist alles schon vorbereitet, sodass “(‘Pernr’)” in meiner Variable sPath steht. Diese füge ich nur noch an /PersonSet an, schon habe ich den aus dem ersten Teil bekannten Aufruf von GET_ENTITY:
Klicke ich beispielsweise links auf eine Person mit der Personalnummer 12345678, so liefert mir der obige Ausdruck oEvent.getParameter(“arguments”).path bereits “(‘12345678’)” zurück. Der komplette Pfad für den Backend Aufruf ist in dem Falle dann /PersonSet(‘12345678’).
Das Ergebnis des Aufrufs wird als Model an die View gebunden. Dadurch wird das Data Binding der Detail View aktiv und zeigt uns die entsprechenden Attribute an. Wenn alles funktioniert, sieht das Ergebnis wie folgt aus:
Durch klicken auf einen Eintrag in der Master Liste wird im Detail Controller der Aufruf “bindElement()” gestartet. Dieser ruft die Methode GET_ENTITY des OData Services auf. Das Ergebnis des Aufrufes wird an der Detail View hinterlegt und durch DataBinding werden die entsprechenden Attribute auf der Oberfläche sichtbar.
UPDATE_ENTITY
Mit GET_ENTITYSET und GET_ENTITY haben Sie bereits die rein lesenden Operationen kennengelernt. UPDATE_ENTITY ist nun der nächsten Schritt: Es werden auch Daten ins Backend geschrieben. Für den Test im Gatway Client haben Sie im vorigen Beitrag eine GET_ENTITY Anfrage gestartet, das Ergebnis “als Anfrage verwendet” und vor dem PUT Request die Daten entsprechend abgeändert. Nach dem selben Schema funktioniert es auch aus dem Frontend:Die Details zu einer Person werden in die Detail View geladen, die Werte dann entsprechend angepasst und das Ergebnis geht dann zurück ans Backend.
Hierfür habe ich alle Text Controls der Detail View durch Input oder DatePicker ersetzt. Zusätzlich habe ich einen Button im Footer erstellt, um das Update starten zu können:
In der Methode “onUpdateEntityButtonPressed” in Detail Controller sorge ich nun dafür, dass ein UPDATE_ENTITY Aufruf ans Backend gestartet wird. Hierfür hole ich mir den Eintrag, welcher an meine Detail View gebunden ist und rufe einfach nur die Methode “submitChanges()” auf. Diese geht dann direkt ans Backend und startet den UPDATE_ENTITY Befehl:
In einem etwas größeren Projekt würden Sie bei dem Aufruf natürlich auch noch Fehler und Erfolgsmeldungen an den Benutzer ausgeben.
DELETE_ENTITY
Zum Löschen habe ich einen weiteren Button in den Footer aufgenommen. Dieser ruft die Methode onDeleteEntityButtonPressed() im DetailController auf. Im Gateway Client wird dafür die HTTP Methode auf “Delete” gestellt und der Pfad /PersonSet(‘Pernr’) verwendet. Auch hier ist das Vorgehen in der UI5 App analog:
Über den Binding Context hole ich mir den Pfad der aktuell an der Detail View gebunden Entität. Dieser ist analog zum oben genannten Pfad aus dem Gateway Client. Entsprechend wird “remove” auf das entsprechende Model aufgerufen und der Pfad übergeben. Dadurch wird ein DELETE Request mit dem Pfad der Entität ans Backend gesendet und durch die Implementierung von DELETE_ENTITY ausgeführt:
CREATE_ENTITY
Für die Erstellung eines neuen Eintrages, habe ich mir eine weitere View erstellt. Sobald ich durch Routing zu dieser View navigiere, erstelle ich mir einen neuen Eintrag mit der createEntry(“/PersonSet”) Methode und binde den entstandenen BindingContext an meine View. Dadurch steht mir sozusagen ein “leerer” Eintrag zur Verfügung, der an der View gebunden ist und über DataBinding befüllt werden kann. Sobald ich auf den entsprechenden Button klicke, lade ich mir die Daten über den BindingContext und sende sie dann mit “create” auf das OData Model ab. Dabei gebe ich den Pfad meines OData Service und die entsprechenden Daten mit. Hierdurch wird im Backend die CREATE_ENTRY Methode aufgerufen. Falls ihr dabei auf einen Fehler lauft, die CREATE_ENTRY Methode aber im Gateway-Client erfolgreich testen könnt, empfehle ich die Metadaten vom Model Eintrag vor dem Absenden zu löschen. Das kann je nach Version erforderlich sein.
Lesen und Ändern der Model Attribute
Wenn Sie bis hierhin durchgehalten haben, können Sie bereits alle 5 OData Standard Methoden aus dem UI5 Frontend aufrufen und die Ergebnisse über DataBinding entsprechend an der Oberfläche anzeigen. Jetzt wird es Zeit, die Daten über JavaScript zu manipulieren. Dies kann besonders hilfreich sein, wenn Daten falsch ans Backend übertragen werden, oder Sie noch zusätzliche Informationen mitgeben möchten.
Über den Binding Context haben Sie die Möglichkeit, alle Attribute meines gebundenen Eintrags auszulesen und beliebig abzuändern. Zum Auslesen wird die Methode “getProperty()” auf das Model angewandt, zum Ändern die Methode “setProperty()”. Für dieses Beispiel habe ich die UpdateEntity Methode von eben im Javascript etwas angepasst. Vor dem Update lese ich den vollständigen Namen der Person aus, verändere ihn und setze den neuen Namen. So steht ab jetzt nach jedem Update “(modified)” hinter dem eigentlichen Namen:
Ändere ich jetzt über das Update einen bestehenden Eintrag, steht automatisch “(modified”) hinter dem geänderten Datensatz:
Templating im Javascript
Zuletzt möchte ich Ihnen noch ein einfaches Beispiel von Templating vorstellen. Hierfür habe ich die Create View von vorhin wieder aufgegriffen und um ein weiteres Form Element erweitert:
Beim Laden der Seite sehe ich nur den Button und direkt daneben ein leeres Dropdown-Menü. Dieses soll mit dem entsprechenden Button gefüllt werden. Im CreateController implementiere ich mir also die onLoadPersonButtonClicked Methode dafür:
Im ersten Schritt hole ich mir das leere Select Control, welches ich mit Werten befüllen möchte über die vergebene ID. Anschließend lege ich mir das Template zum Anzeigen der Ergebnisse an. Dies funktioniert analog zum ObjectAttribute, welches in der Master View als Template hinterlegt ist. Im Controller wird festgelegt, welche Eigenschaft der Schlüssel für die angezeigten Elemente sein soll und welches Attribut als Text im Menü dienen soll. Die Personalnummer ist hier der Schlüssel und der vollständige Name wird dem Benutzer angezeigt. Mit dem Aufruf “bindItems()” auf das entsprechende Select Control wird die GET_ENTITYSET Methode des OData Service angesteuert, genauso wie auch im XML der Master View zu sehen war. Zusätzlich wird das Template zum Anzeigen der Ergebnisse mitgegeben. Folgendes Ergebnis erscheint nach Klicken des Buttons:
Hat es Ihnen gefallen?
In diesem Beitrag habe ich Ihnen vorgestellt, wie Sie die Standard Methoden Ihres OData Service aus einer UI5 Anwendung aufrufen können, wie Sie die Daten an der Oberfläche anzeigen können und wie sie mit JavaScript Änderungen vornehmen können. Wenn es Ihnen gefallen hat, schauen Sie doch gerne bei der ODATA-Grundlagenreihe vorbei. Dort gibt es weitere Themen praktisch erklärt!
Testdaten on request für SAP HCM
Unsere Lösung bietet Ihnen über ein Testdatenkiosk die Möglichkeit synthetische "Testdaten on request" für das SAP HCM zu erstellen.
