Fiori Apps sind aus der modernen SAP-Entwicklung nicht mehr wegzudenken! Sie dienen der Umsetzung anwenderfreundlicher SAP-Oberflächen und sorgen für eine gesteigerte Usability. Die dahinter liegenden Technologien OData und SAPUI5 sollen im Folgenden näher betrachtet werden. Da der Einsatz dieser Technologien in der Praxis einiges an Vorwissen voraussetzt, soll mit diesem Beitrag eine Blogpost-Reihe gestartet werden, die Schritt für Schritt das notwendige Know-how vermitteln.
Als Einstieg in diese Reihe wird in diesem Post erläutert, wie ein Teil des Prozesses eines Eigentümerwechsels im IS-U (Industry Solutions for Utilities) mit Hilfe eines OData-Services und SAPUI5 umgesetzt werden kann. Der zweite Teil der Blog-Reihe geht dann auf die Frontend-Entwicklung mit der SAP WebIDE ein. Dabei wird die SAPUI5-Beispielanwendung betrachtet, welche den erstellten OData-Service nutzt. Der dritte Teil wird schließlich den Vergleich der klassischen Eigentümerverwaltung sowie die Vorteile der webbasierten Eigentümerverwaltung mit SAPUI5 beinhalten.
Der Use Case
Die dabei abzubildende User Story lautet: Als Verwaltungsangestellter möchte ich eine Verbrauchsstelle anhand eines Anschlussobjekts finden, um dafür einen neuen Eigentümer zu hinterlegen. Daraus ergibt sich, dass über die Adresssuche eine Verbrauchsstelle zu ermitteln ist. Weiterhin bedarf es für den neuen Verbraucher eines Eingabeformulars.
Damit die benötigten Daten später in der SAPUI5-Anwendung konsumiert werden können, muss zunächst ein OData-Modell aufgebaut werden. Dies setzt voraus, dass ein entsprechender OData-Service erstellt wird. Da das dafür notwendige Vorgehen bereits sehr gut über Tutorials beschrieben ist, soll es an dieser Stelle nicht näher erläutert werden und es wird sich rein auf das Modell der Anwendung konzentriert. Jenes Modell wird mithilfe der Transaktion „SEGW“ (SAP Gateway) erstellt:
Um dem Anwender die Arbeit zu erleichtern und ihn nicht mit Objektnummern zu konfrontieren, wird als Einstieg eine Adresssuche gewählt. Ausgehend von einer gefundenen Adresse (dem Anschlussobjekt) erhält der Anwender alle Verbrauchsstellen mit entsprechenden Eigentümern. In einem weiteren Schritt folgen die Details zum jeweiligen Eigentümer.
Der Service-Test
Nachdem das Modell nun angelegt wurde, kann der Service in der Transaktion „/IWFND/MAINT_SERVICE“ (“Services aktivieren und verwalten”) registriert werden:
Erste Schritte
Nach der Registrierung wird über den Button „SAP Gateway Client“ im unteren Teil des Bildschirmes in die Transaktion „/IWFND/GW_CLIENT“ (“SAP Gateway Client“) gewechselt, um den registrierten Service zu testen:
Über den Button „Ausführen“ ergeben sich allgemeine Informationen zum erstellten Service. Dazu zählen zum Beispiel die Verarbeitungszeit zum Abrufen, den HTTP-Responsecode mit weiteren Header-Informationen sowie die im Modell erstellten Collections:
Über den Zusatz „$metadata“ in der URL wird nun ein neuer Request abgesetzt. Die Response liefert dann das Metadatenmodell des Services. In diesem sind ausführlichere Informationen zu den einzelnen Entity Sets, den Propertys eines Sets (wie der Key) und die durch den Entwickler implementierten Funktionen (Creatable, Updateable usw.) dargestellt.
Da es in größeren Projekten verschiedene Entwickler für den OData-Service und für SAPUI5 geben kann, muss der Frontend-Entwickler den Backend-Entwickler nicht zwangsläufig persönlich konsultieren. Vielmehr kann der Backend-Entwickler dem Frontend-Entwickler über diese Eigenschaften mitteilen, wie er die Felder einsetzen kann und welche Funktionen mit ihnen möglich sind:
Abfrage eines Entity Sets
Schauen wir uns nun beispielhaft einen Datensatz des Services an und testen damit die implementierte Funktionalität des Abrufens eines Eigentümers zu einer Verbrauchsstelle eines Anschlussobjektes. Dazu wird die „$metadata“-Abfrage in der URL durch den Namen des Entity Sets ersetzt, welches betrachtet werden soll:
Über den Button „Ausführen“ werden alle Anschlussobjekte ermittelt, welche im Entity Set verfügbar sind. Die Ergebnismenge ist dabei abhängig von der implementierten Select-Abfrage in der Methodenredefinition der Service-Erstellung. Da sich in diesem Testsystem durchaus auch unvollständige Datensätze zu Anschlussobjekten ergeben können, wurden diese nicht im Select mit aufgenommen. Das Ergebnis der Selektion sieht wie folgt aus:
Abfrage einer einzelnen Entity
Nun soll ein einzelnes Anschlussobjekt behandelt werden. Die Betrachtung eines einzelnen Entity-Objektes erfolgt über die Methode „GetEntity“ des Anschlussobjektsets. Als Key dient hier die Anschlussobjektnummer, über die der gewünschte Datensatz gelesen wird. Der Key wird der URL wie folgt angehangen:
Die Response ergibt einen einzelnen Datensatz:
Erweiterung der Informationen durch Navigation
Der nächste Schritt dient dazu, die implementierte Assoziation zu testen. Hierbei ist der folgende Teil des Eintrags zu prüfen, der angibt, ob bei einem Entity eine Assoziation zu einem anderen Entity Set besteht:
Durch Erweitern des bestehenden URL-Teils mit dem Zusatz der Navigation ergeben sich alle erfassten Verbrauchsstellen zum selektierten Anschlussobjekt:
Im Beispiel sind diesem Anschlussobjekt zwei Verbrauchsstellen zugeordnet. Zum einen die Verbrauchsstelle mit „70000322“ und die Verbrauchsstelle „70001232“. Weiterhin ist zu sehen, dass unter der angezeigten Property „Eigent“ bei beiden Verbrauchsstellen ein Eigentümer hinterlegt ist:
Die Metadaten zeigen, dass in diesem Fall bei den Datensätzen zu jedem Objekt zwei Assoziationen oder Navigationsmöglichkeiten hinterlegt sind. Zum einen ist es die Navigation zu den Anlagen einer Verbrauchsstelle und zum anderen die Navigation zu dem zugehörigen Eigentümer einer Verbrauchsstelle. Da die Endanwendung das Ändern des Eigentümers ermöglichen soll, testen wir an dieser Stelle die Navigation zu dem hinterlegten Eigentümer. Um zu navigieren, wird die URL wie folgt erweitert:
Als Ergebnis der Abfrage erhalten wir die Informationen zum Eigentümer der Verbrauchsstelle mit der Nummer „’70001232’“.
Damit ist der Test des Services beendet. Die Funktionalität weiterer CRUD-Methoden wie das Anlegen oder das Ändern eines Eigentümers werden im weiteren Verlauf der Blogpost-Reihe, bei der Betrachtung der Frontend-Technologie, demonstriert.
Dieser Beitrag wurde verfasst von:
