Florian Tent
 - 14. November 2019

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.

UI5 Datenquelle einrichten

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:

Default Model

 

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:

Data Binding Detail View

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.

Wenn der OData Service zu Fehlern führt [Whitepaper]

Mit der App-Entwicklung in Fiori hat sich eine Sache grundlegend geändert: Es ist ein Zugriff über die OData Services notwendig.

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:

GET_ENTITYSET in Liste

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:

Ansicht Master Liste

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:

Detail Controller 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:

Detail View nach Navigation

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:

Footer mit Update Button

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:

onUpdateEntityButtonPressed

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:

onDeleteEntityButtonPressed

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.

CreateController

CREATE_ENTITY

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:

DetailController Modify Name

Ändere ich jetzt über das Update einen bestehenden Eintrag, steht automatisch „(modified“) hinter dem geänderten Datensatz:

Name modified

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:

Empty Select & Button

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:

UI5 JS Templating

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:

PersonDropdown

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!

SAPUI5: ODATA Grundlagen in der praktischen Verwendung

Florian Tent

Florian Tent

Als SAP Consultant bei der mindsquare begeistere ich mich für das Verstehen und Lösen von Problemen. Die Beratung im Personalwesen sticht für mich aufgrund des hohen Kommunikationsanteils und der großen Anzahl betroffener Mitarbeiter besonders heraus!

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren


Mehr von unseren Partnern


Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Angebot anfordern
Preisliste herunterladen
Expert Session
Support