Vor einiger Zeit haben wir für den Servicebereich eines Kunden eine Dashboardlösung entwickelt. Bei der Analyse, mit welcher Technologie die Lösung umgesetzt werden soll, fiel die Wahl am Ende auf SAPUI5. Einigkeit bestand jederzeit in der Wahl der Technologie für die Datenbeschaffung. Der Kunde nutzt bereits SAP Business Intelligence (BI) und es entsprachen bereits einige Infoprovider den Anforderungen bezüglich der darzustellenden Daten. Da die EasyQueries in der Lage sind die Daten direkt als OData-Service zur Verfügung zu stellen, konnte das Projekt schnell umgesetzt werden. Während der Implementierungsphase sprachen wir mit dem Kunden über die geographische Darstellung der Servicemeldungen anhand einer Google-Map. Die Idee kam so gut an, dass wir dieses Feature auch umsetzten. Dank der Anreicherung der bestehenden OData-Services-Daten mit den Geolocations, die wir über eine REST-API abfragten, konnte auch dieses Feature mit vertretbarem Aufwand umgesetzt werden.
Was hat das Kundenprojekt mit der Blogserie zu tun? Bei der Vorbereitung der Produktivsetzung hat das Dashboard die Servicemeldungen so gut dargestellt, dass sichtbar wurde, dass einige Meldungen offensichtlich im Backend nicht nachhaltig gepflegt wurden. Um die Meldungen anzuschauen, musste man sich diese am Dashboard heraussuchen und in die SAPGUI wechseln, um die Servicemeldung anzuzeigen. Der damit verbundene Medienbruch stört die Userexperience und ist umständlich und ineffizient. Es geht auch benutzerfreundlicher.

OpenUI5 / SAPUI5 und das SAP Gateway

Manchmal passen Dinge, so wie hier, einfach zusammen. Wir beschäftigen uns seit längerem mit neuen SAP Technologien wie Fiori, Overview Pages (OVP) und anderen Dinge, die ähnlich coole Namen haben. Fangen wir kurz mit der Beschreibung einiger Buzzwords an (diese werden wir später noch auf der Website und in Blogbeiträgen genauer beschreiben): Es hält sich das Gerücht, dass vor ein paar Jahren einige Mitarbeiter (nennen wir sie ruhig Geeks) bei SAP die SAPGUI nicht zeitgemäß fanden und machten sich Gedanken, wie man die Benutzeroberfläche auf den aktuellen Stand der Zeit bringen kann. Die Geeks mischten „Technologien und Ansätze“ moderner Webstandards (HTML5, CSS und JavaScript) und entwickelten damit das SAPUI5 Framework. Mittlerweile hat SAP dieses Framework (mit ein paar kleineren Einschränkungen) unter der Bezeichnung OpenUI5 als open source veröffentlicht. Mit SAPUI5 und OpenUI5 lassen sich auch Anwendungen entwickeln, die keinen Bezug zum SAP Backend haben. Dies wird nur selten genutzt, da im Nicht-SAP-Bereich andere Frameworks zum Teil besser geeignet sind. Eine durchweg charmante Fähigkeit von SAPUI5 ist die Darstellung der gleichen Anwendung auf dem Desktop, einem Tablet oder Smartphone. Das adaptive Design der Anwendung sorgt dafür, dass es sich an die Größe des genutzten Devices anpasst. So sieht man auf dem Desktop die Informationen beispielsweise nebeneinander, während man die Informationen auf dem Smartphone untereinander sieht. Es wird immer dafür Sorge getragen, dass die Anwendungen (sofern möglich) auf allen Devices funktionieren.

BI EasyQueries als Gateway-Services

Um die Daten aus dem SAP System zu bekommen, gibt es unterschiedliche Möglichkeiten. Neben den remotefähigen Funktionsbausteinen (RFCs), SOAP Webservices und anderen Techniken, entwickelte die SAP das sogenannte SAP Gateway (die ältere/erfahrenere Leserschaft sollte dieses neue Wording bitte nicht mit dem alten SAP Gateway verwechseln). Kurz gesagt wird das SAP Gateway dazu genutzt, Daten aus dem SAP Backendsystem mittels REST API bereitzustellen, die im Regelfall im OData-Format zur Verfügung gestellt werden (aber es spricht auch JSON). Hierzu wird zwischen dem Gateway System und dem Backend-System eine vertrauenswürdige Verbindung hergestellt und dem Gateway System gesagt, wie es auf die Daten im Backend zugreifen kann. Die Grundfunktionalitäten, die normalerweise vom Gateway unterstützt werden, sind die CRUDQ-Operationen: Erstellen (create), lesen (read), ändern (update), und löschen (delete) eines Datensatzes. Dazu noch die Abfrage einer Liste von Daten (query). Dazu kommen noch weitere Möglichkeiten, wie beispielsweise die Navigation von Kopfdaten zu Positionsdaten. Weder REST noch OData sind Erfindungen der SAP, sondern werden von der SAP und anderen genutzt. Somit sind sie offen für andere Programmier- und Skriptsprachen. Beispielsweise kann man mit REST und OData Daten von einem SAP-System und Sharepoint auf die gleiche Art und Weise bereitstellen.

Fiori

Okay, wir haben nun kurz über die Geschichte von UI5 gesprochen und darüber was ein Gateway macht. Bleibt noch die Frage, was Fiori ist. Unter der Bezeichnung Fiori entwickelt SAP eigene Anwendungen. Diese sind (bis zur Partnerschaft mit Apple) alle in SAPUI5 entwickelt wurden und nutzen das SAP Gateway. Zudem laufen sie in einem Framework, das sich um die Darstellung im sogenannten Fiori Launchpad, Berechtigungen und anderen Dingen kümmert. Dank des Fiori Designguide von SAP sehen alle Anwendungen ähnlich aus und verhalten sich gleichartig. Das ermöglicht Unternehmen, wie der unseren, Fiori-like Anwendungen zu erstellen, die sich wie ganz normale Fiori-Anwendungen verhalten.

Fiori Overview Pages (OVP)

Fiori Overview Page (Quelle: SAP) Das Dashboard funktioniert sehr gut und erfüllt alle Anforderungen des Projektes. Da es die relevanten Informationen sehr übersichtlich darstellt, wird es mittlerweile auch von den Mitarbeitern des Service genutzt. Für Szenarien, in denen sich ein Mitarbeiter einen Überblick über Daten aus einem bestimmten Bereich verschaffen möchte, um tiefer in die Datenbasis einzusteigen und Folgeaktivitäten anzustoßen, hat SAP die Fiori Overview Pages entwickelt. Die OVPs werden für unterschiedliche Bereiche Themengebiete (z.B. Service, Vertrieb, Einkauf) erstellt und zeigen sogenannte Cards an. Cards gibt es in Listen- und Tabellenform, als Diagramm und in Form eines Kartenstapels. Die OVP lässt sich personalisieren. Somit kann jeder Mitarbeiter selber steuern, welche Cards ihm auf der Übersichtsseite angezeigt werden. Ein globaler Filter sorgt dafür, dass die Informationen auf den Karten gefiltert werden können. Dadurch ist es beispielsweise möglich, die angezeigten Informationen auf einen Kunden zu filtern und hierdurch nur diesen Kunden genauer zu betrachten. Eine weitere charmante Eigenschaft der Karten ist die Möglichkeit der Navigation. Damit wird es möglich, aus der Liste der neuesten Serviceaufträge einen heraussuchen und mit einem Klick in der Darstellung des Serviceauftrags zu gelangen. Von hier kann ich dann die relevanten Informationen weiter ansehen und bei Bedarf ändern. Auf das Beispiel mit den Serviceaufträgen bezogen, ergeben sich für die OVPs unterschiedliche Cards. Auf den Listen- und Tabellen-Cards kann man sehr gut die ältesten und neuesten Serviceaufträge darstellen. Die Serviceaufträge mit Stillstand lassen wir uns übersichtlich als Kartenstapel anzeigen. Ein Klick auf den Kartenstapel zeigt die Kerninformationen zu den Serviceaufträgen. Über Buttons im Footer der Card hat der Anwender die Möglichkeit Aufträge anders zu priorisieren oder die erfolgreiche Bearbeitung des Auftrages zu bestätigen. Noch einmal kurz zum globalen Filter: Haben Sie es schon einmal erlebt, dass Ihr Vorgesetzter hinter Ihnen steht und einige Informationen zu dem Kunden benötigt, mit dem er gerade telefoniert? Wie schön ist es dann, die angezeigte Übersichtsseite auf den Kunden zu filtern und sofort sehen zu können, ob er noch offene Serviceaufträge hat und wie deren Status ist. Kein Heraussuchen von Werten in den vielen Listen, sondern Informationen dort wo man sie benötigt. Der größte Wermutstropfen ist die fehlende Möglichkeit, eigene Kartentypen zu erstellen. Standardszenarien können über die vorhanden Kartentypen abgedeckt werden, für die komplette Freiheit auch kundenindividuellere Wünsche zu realisieren, bleibt der Wunsch auch eigene Kartentypen erstellen zu können.