SAP IS-U Archives - Digital Innovation Blog

SAP Fiori: Eigentümerwechsel einer Verbrauchsstelle mit SAP IS-U, ODATA und SAPUI5 (Teil 3)

Fiori Apps sind aus der modernen SAP-Entwicklung nicht mehr wegzudenken! Sie dienen der Umsetzung anwenderfreundlicher SAP-Oberflächen und bieten mehr Möglichkeiten bzgl. moderner Usability. Die dahinter liegenden Technologien OData und SAPUI5 sollen im Folgenden näher betrachtet werden.
Im ersten Teil der Blogreihe wurde der Use Case eines Eigentümerwechsels im SAP IS-U System vorgestellt. Davon ausgehend wurde in einem ersten Schritt die Erstellung des OData-Services beschrieben, welcher die zur Anforderung passenden Informationen bereitstellt. Darauf aufbauend konnte im zweiten Teil der Blogreihe die umgesetzte UI5-Anwendung vorgestellt werden. Diese nutzte den im ersten Teil beschriebenen OData-Service, um bestimmte Daten aus dem SAP-System zu lesen, zu aktualisieren und neue Datensätze zu erstellen.

Vorbetrachtung des dritten Parts

Im dritten und letzten Teil der Blogbeitragsreihe werden die alte und die neue Welt auf Prozessebene gegenübergestellt und es wird auf das User Centered Design (UCD) mit Hilfe von Fiori eingegangen, welches den Anwender für die Erstellung effizienter Software in den Vordergrund rückt. Doch zuvor soll in einem ersten Schritt auf das SAP-Bypassing eingegangen werden, welches die Art und Weise der Anwendungsentwicklung für SAP-Systeme neu charakterisiert.

SAP-Bypassing mit OData

In der heutigen Zeit besitzen Unternehmen eine Vielzahl verschiedener Systeme zur Bewältigung unterschiedlichster Aufgaben. Im Kontext einer SAP-Systemlandschaft gibt es also Unternehmen, welche verschiedene SAP-Systeme, z.B. für die Ressourcenplanung oder für B2B-, B2C- und B2E-Szenarien, betreiben. Dies bringt verschiedene individuelle oder gesetzliche Anforderungen mit sich, die in einem System oder über eine Systemlandschaft hinweg umzusetzen sind.

*Abbildung 1: Arten von Anforderungen an ein System*

Im Laufe der Zeit entstehen somit viele verschiedene Anforderungen an ein System. Mit der Umsetzung nehmen die Komplexität und die Verzahnung mit anderen Komponenten im System sowie mit Kommunikationspartnersystemen stetig zu.

Die Anpassungen und Eigenentwicklungen verkomplizieren die Systemabläufe und sind teilweise extreme Performancekiller.

Die Ergebnisse sind unter anderem:

Immer längere Ladezeiten
Hoher und komplexer Wartungsaufwand und
Unzufriedene Nutzer

*Abbildung 2: Nachteile vieler umgesetzter Anforderungen*

Hier kommt das Bypassing ins Spiel. Dessen Kernziel ist es, das System möglichst nahe am Standard zu belassen und die Umsetzung verschiedener Anforderungen aus dem SAP-System herauszulösen.

Um dies zu realisieren, bietet das SAP-System das Werkzeug der OData-Service-Entwicklung, welches bereits im ersten Teil der Blogreihe gezeigt wurde. Mit Hilfe des Open Data Protokoll (OData) ist es also möglich, eine standardisierte Schnittstelle zum SAP-System bereitzustellen. Die Umsetzung der gestellten Anforderungen kann somit nun vom System getrennt werden und es entsteht eine modulare Architektur, welche kombiniert, ausgetauscht, erweitert oder verändert werden kann.

*Abbildung 3: Auslagerung der Anforderungen aus dem System*

Damit entstehen für das System und die Anwendungsentwicklung weitere Vorteile, wie in Abbildung 4 „Vorteile der Komponententrennung“ zu sehen ist.

Der Eigentümerwechsel in der alten Welt

Im SAP-System werden Funktionalitäten in Transaktionen abgebildet, welche über sogenannte Transaktionscodes aufgerufen werden. Das Problem ist jedoch, dass viele Transaktionen mit Funktionalitäten überladen sind. So kann es vorkommen, dass es in einer Transaktion vielleicht zehn Reiter für verschiedene Anforderungen gibt, der Nutzer jedoch nur einen oder zwei Reiter für seine spezielle Aufgabe benötigt und der Rest ungenutzter Ballast ist. Dies führt, gerade bei neuen Mitarbeitern, zu einem Mehraufwand in der Einarbeitung oder schreckt diese auf Grund der Komplexität direkt ab.

Beim Vergleich des Showcases aus dem ersten und zweiten Teil der Blogreihe wurden die einzelnen Schritte zum Ändern eines vorhandenen Geschäftspartners im SAP-System in der folgenden Abbildung dokumentiert. Dabei fällt auf, dass neben der bereits erwähnten Überladung mancher Transaktionen, drei verschiedene Modi erzeugt werden mussten, um die Anforderung umzusetzen.

Abbildung 5: Prozessschritte Eigentümerwechsel in der alten Welt

Wenn der Nutzer also in seiner Transaktion jedes Mal von vorn beginnen möchte, ist er gezwungen in mehreren Fenstern zu arbeiten und sich lange, nichtssagende Nummern zu merken oder in den Zwischenspeicher zu legen. Dies ist wenig intuitiv und bietet neben einer schlechten User Experience eine große Angriffsfläche für Fehler.

Fortfolgend wird der gleiche Prozess noch einmal betrachtet, jedoch dieses Mal unter Nutzung des SAP-Frontend-Frameworks SAPUI5.

Schöne neue Welt

Mit ihrer neuen Frontend-Technologie legt die SAP ihre eingestaubten Transaktionen für die Nutzer ab und verschlankt diese. So werden die ehemals funktional aufgeblähten Transaktionen in kleinere Anwendungen (UI5-Apps) aufgeteilt. Dabei übernehmen diese Anwendungen verschiedene Teilaufgaben eines ganzheitlichen Szenarios und ermöglichen dem Nutzer eine intuitive und effiziente Arbeit ohne unnötigen Ballast.

*Abbildung 6: Prozessschritte Eigentümerwechsel in der neuen Welt*

Der Nutzer im Vordergrund der Anwendungsentwicklung

Neben der Einführung in die Neuerung der Anwendungsentwicklung auf dem SAP-Stack gibt es noch einen weiteren Teil, den es zu beleuchten gibt. Die User-Experience-Strategie „SAP Fiori“.

Was ist Fiori?

Während SAPUI5 als Web-Framework Entwickler bei der Umsetzung moderner Enterprise-Anwendungen auf dem SAP-Stack unterstützt, legt Fiori die Design-Prinzipien fest.

Abbildung 7: SAP Fiori Design Guidelines – Bildquelle: Fiori Design Guidelines

Anhand der Fiori Design Guidelines erhalten Entwickler ein Nachschlagewerk für die visuelle Umsetzung der Anwendung, um die höchstmögliche, von der SAP vorgesehene Anzahl an Vorteilsmerkmalen für die Anwendung zu erreichen.

*Abbildung 8: Fiori Merkmale – Bildquelle: Fiori Design Guidelines*

Fazit

Mit der Kombination aus OData, SAPUI5 und Fiori geht die SAP einen neuen Weg und verabschiedet sich vom Grau ihrer monolithischen ERP-Lösungen. Durch die Eigenschaften von OData können Anwender nun (z.B. anhand von im Unternehmen verfügbarem Know-how) freier entscheiden, welche Frontend-Technologie sie einsetzen möchten. Gleichzeitig ermöglicht diese Komponententrennung und die Auslagerung von Funktionalitäten aus dem SAP-System eine besser wartbare und austauschbare Systemlandschaft.

Frontend-seitig rückt der eigentliche Anwender in den zentralen Blick der Anwendungsentwicklung. Musste sich ein Anwender vorher in überladene Transaktionen einarbeiten, werden diese Funktionalitäten jetzt in viele kleinere Anwendungen aufgeteilt und für eine bestmögliche Effizienz und Effektivität für den Nutzer entworfen.

Die Entwickler erhalten mit dem SAPUI5 Demo Kit, den Community-Foren und den Fiori Design Guidelines eine umfangreiche und ausführliche Dokumentation an die Hand, welche die Entwicklung moderner Webanwendungen auf dem SAP-Stack deutlich verbessert.

SAP Fiori: Eigentümerwechsel einer Verbrauchsstelle mit SAP IS-U, ODATA und SAPUI5 (Teil 2)

Im ersten Teil der Blogreihe wurde der Use Case eines Eigentümerwechsels im SAP IS-U System vorgestellt. Davon ausgehend wurde in einem ersten Schritt die Erstellung des OData-Services beschrieben, welcher die zur Anforderung passenden Informationen bereitstellt. Aufbauend auf diesem Service wird in diesem Teil der Blogreihe die umgesetzte UI5-Web-App vorgestellt.

Vorbetrachtung des zweiten Parts

Für die Entwicklung und Bereitstellung der Anwendung wurde die SAP Cloud Plattform (SCP) verwendet. Diese beinhaltet eine Integrated Development Environment (Web-IDE) sowie den Portal-Service. Die Web-IDE bietet unterstützende Funktionalitäten (z. B. Templates) für die Entwicklung von SAPUI5-Apps. Über den Portal-Service wurde ein Fiori Launchpad angelegt, welches als zentralen Einstiegspunkt zur Verwendung der Apps dient.

Die Anwendung

Die SAPUI5-App besteht aus mehreren Seiten. Auf der Einstiegsseite befindet sich eine Suche, mit der das gewünschte Anschlussobjekt schnell gefunden werden kann.

SAP Fiori - Panel mit Suchfeldern — *Abbildung 2: Panel mit Suchfeldern*

Die Ergebnismenge wird dynamisch in einer darunter liegenden Tabelle entsprechend der Suchkriterien gefiltert.

SAP Fiori - Gefilterte Ergebnisliste — *Abbildung 3: Gefilterte Ergebnisliste*

Über die im OData-Service implementierte Navigation ist es nun möglich, kontextbezogene Informationen zum Anschlussobjekt auf einer weiteren Seite anzuzeigen. So wurden in diesem Showcase die Adressdaten des Anschlussobjekts sowie die zugehörigen Verbrauchsstellen abgefragt.

SAP Fiori - Detailseite des Anschlussobjektes — *Abbildung 4: Detailseite des Anschlussobjektes*

Durch die Auswahl einer Verbrauchsstelle wird zu einer weiteren Detailansicht navigiert.

SAP Fiori - Navigation durch Klick auf einen Eintrag — *Abbildung 5: Navigation durch Klick auf einen Eintrag*

In dieser werden detaillierte Informationen sowie die eingebauten Anlagen zu der hinterlegten Verbrauchsstelle angezeigt. Weiterhin ermöglicht diese Seite die Aktualisierung des Eigentümers über den Button „Bearbeiten“.

SAP Fiori - Detailansicht einer Verbrauchsstelle — *Abbildung 6: Detailansicht einer Verbrauchsstelle*

Im Folgenden werden nun zwei Szenarien aufgezeigt. Als erstes wird für die Verbrauchsstelle ein neuer Eigentümer angelegt, welcher noch nicht im System vorhanden ist. Die Besonderheit an dieser Funktionalität ist die Vereinfachung des Prozesses mit SAPUI5. Wird das gleiche Szenario im SAP-System selbst durchgeführt, so ist es nötig mehrere Transaktionen zu nutzen und eine bestimmte Prozessreihenfolge einzuhalten (erst Anlegen eines Eigentümers, dann Ändern eines Eigentümers in verschiedenen Transaktionen), da man sonst an bestimmten Punkten in der Transaktion zum Ändern eines Eigentümers nicht weiterkommt. Weiterhin wird durch die Umsetzung mit SAPUI5 das Merken und Suchen der Nummern zum Anschlussobjekt, der Verbrauchsstelle und dem Eigentümer überflüssig und die Benutzerfreundlichkeit kann (insbesondere für SAP-Unerfahrene) gesteigert werden.

Anlegen eines Eigentümers

Über den Bearbeitungsbutton wird das XML-Fragment zum Anzeigen eines Eigentümers durch ein Fragment für die Bearbeitung ausgetauscht.

SAP Fiori - Wechsel in den Bearbeitungsmodus — *Abbildung 7: Wechsel in den Bearbeitungsmodus*

Der Hinweis auf den Bearbeitungsmodus wird in diesem Szenario durch zwei Merkmale gekennzeichnet. Zum einen wechselt der Button „Bearbeiten“ in den Button „Anzeigen“ mit einem neuen Icon.

SAP Fiori - Bearbeitungsmodus — *Abbildung 8: Bearbeitungsmodus*

Zum anderen erscheinen zwei neue Buttons in der Fußleiste der Anwendung. Diese dienen dem Anlegen eines neuen Eigentümers und dem anschließenden Wechsel vom alten zum neuen Eigentümer.

Abbildung 9: Button zum Anlegen und Updaten eines hinterlegten Eigentümers

Mit einem Druck auf den Plus-Button erscheint eine Dialogbox. Diese soll den Anwender durch den Prozess führen und gleichzeitig den Prozess vereinfachen, indem sie nur die für das Anlegen eines Eigentümers relevanten Felder anzeigt. Diese Felder sind kontextbezogen, je nachdem ob der Nutzer als Geschäftspartnertyp eine Person, eine Organisation oder eine Gruppe angibt.

SAP Fiori - Anlegen mit SAPUI5 - App — *Abbildung 10: Anlegen mit SAPUI5 – App*

Es soll nun eine neue Person als Eigentümer angelegt werden. Ausgehend von der Angabe des Geschäftspartnertyps „Person“ kann in dem neu erschienenen Feld „Anrede“ nur „Herr“ oder „Frau“ hinterlegt werden. Im Vergleich wäre beim Anlegen einer Organisation die Anrede „Firma“ auswählbar.

SAP Fiori - Auswahl der Anrede — *Abbildung 11: Auswahl der Anrede*

Mit der Auswahl einer Anrede erweitert sich der Dialog nun erneut um alle Felder, die für das Anlegen eines Eigentümers mindestens erforderlich sind. Diese Felder müssen nun nicht mehr mühsam über mehrere Reiter in der SAP-Transaktion zusammengesucht werden, sondern können anwenderfreundlich in einem Dialog gebündelt dargestellt und durch entsprechende Platzhalter und Labels beschrieben werden.

SAP Fiori - Dialog zum Anlegen eines neuen Geschäftspartners — *Abbildung 12: Dialog zum Anlegen eines neuen Geschäftspartners*

Im Folgenden wurden nun alle Felder beispielhaft ausgefüllt, um einen neuen Eigentümer anzulegen.

SAP Fiori - Eigentümerdialog ausgefüllt — *Abbildung 13: Eigentümerdialog ausgefüllt*

Über den Druck auf den Button „Anlegen“ wird der neue Eigentümer angelegt. Als Feedback für den Nutzer erscheint eine Nachricht, dass der Geschäftspartner erfolgreich angelegt wurde.

SAP Fiori - Geschäftspartner erfolgreich angelegt — *Abbildung 14: Geschäftspartner erfolgreich angelegt*

Aktualisieren eines Eigentümers

Nach dem Anlegen des neuen Geschäftspartners kann dieser über den Button zum Partnerwechsel als neuer Eigentümer in der Verbrauchsstelle hinterlegt werden.

Abbildung 15: Button für Partnerupdate

Mit dem Druck auf den Button für den Partnerwechsel erscheint erneut ein Dialog. Dieser beinhaltet eine Tabelle mit allen im System hinterlegten Geschäftspartnern, ob Person, Firma oder Gruppe. Außerdem bietet der Dialog, neben der Möglichkeit der manuellen Durchsuchung, ebenfalls die Suche nach einer Person oder einer Firma über die jeweiligen Suchfelder.

SAP Fiori - Anzeige aller Geschäftspartner — *Abbildung 16: Anzeige aller Geschäftspartner*

An dieser Stelle wurde nach dem neu angelegten Geschäftspartner über das Suchfeld „Person“ gefiltert. Der doppelte Eintrag kommt daher, dass eine Prüfung auf bereits vorhandene Einträge zur Vereinfachung der Tests nicht implementiert wurde.

SAP Fiori - Auswahl des gefilterten Eintrages — *Abbildung 17: Auswahl des gefilterten Eintrages*

Nach der Auswahl des angelegten Geschäftspartners kann dieser über den Button „Update“ als neuer Partner der Verbrauchsstelle hinterlegt werden.

Abbildung 18: Bestätigen des ausgewählten Partners

Die Anwendung bestätigt dem Nutzer die Änderung. Als Feedback erhält dieser ein Popup mit der Erfolgsmeldung.

SAP Fiori - Erfolgsmeldung Aktualisierung des Partners — *Abbildung 19: Erfolgsmeldung: Aktualisierung des Partners*

Ist das Update durchgeführt, erscheint die bekannte Detailseite mit den aktualisierten Eigentümerinformationen.

SAP Fiori - Aktualisierter Eigentümer — *Abbildung 20: Aktualisierter Eigentümer*

Ausblick

Im dritten Teil der Blogreihe werden alte und neue Welt gegenübergestellt. Dabei wird der hier vorgestellte Prozess des Eigentümerwechsels mit dem Vorgehen in der alten Welt verglichen und es sollen die Vor- und Nachteile aufgezeigt werden. Weiterhin werden der generelle Gedanke und die Vorteile des Bypassings, also der Auslagerung von Funktionalitäten aus dem SAP-System, näher beschrieben.

SAP Fiori: Eigentümerwechsel einer Verbrauchsstelle mit SAP IS-U, OData und SAPUI5 (Teil 1)

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:

SAP Fiori - Modellerstellung mit der Transaktion SEGW (SAP Gateway)

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:

SAP Fiori - Services aktivieren und verwalten

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:

SAP Fiori - Ausführen und Ergebnisansicht

Ü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:

SAP Fiori - Mitteilung von Backend- an Frontend-Entwickler

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:

SAP Fiori - Ersetzen der $metadata-Abfrage in der URL durch den Namen des Entity Sets

Ü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:

SAP Fiori - Ausführen und Ergebnis der Selektion

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:

SAP Fiori - Test Entity Assoziation zu einem anderen Entity Set

Durch Erweitern des bestehenden URL-Teils mit dem Zusatz der Navigation ergeben sich alle erfassten Verbrauchsstellen zum selektierten Anschlussobjekt:

SAP Fiori - Erweiterung des bestehenden URL-Teils mit dem Zusatz der Navigation

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:

SAP Fiori - Ansicht zweier Verbrauchsstellen im Anschlussobjekt

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:

SAP Fiori - Erweiterung der URL für Navigation

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.