SAPUI5 – Richtig eingesetzt

Fangen wir zunächst damit an, was SAPUI5 überhaupt ist. Viele Leute sagen, es sei eine schnelle, übersichtliche und schöne Oberfläche. Dies trifft allerdings nicht ganz zu. SAPUI5 ist ein Framework, das uns dabei hilft, die vorher genannten Kriterien zu erfüllen.

SAPUI5 steht für «UI Development Toolkits für HTML5». Es stellt sich jedoch die Frage:  Wofür ist das gut? Die Autoren von »SAPUI5 – Das umfassende Handbuch«1) definieren es so: »SAPUI5 ist das neue Toolkit von SAP zur Programmierung von Benutzeroberflächen als wichtiger Bestandteil in der aktuellen Technologiestrategie von SAP. Insbesondere handelt es sich dabei um die Technologie, die zur Entwicklung von SAP-Fiori-Anwendungen genutzt wird, die den neuen Standard für das moderne Aussehen von SAP-Anwendungen verkörpern.

Mit SAPUI5 erstellte Anwendungen sind mit verschiedensten Browsern und Geräten einsetzbar und bieten eine integrierte Erweiterbarkeit, funktionsreiche UI-Controls für komplexe Muster und Layouts, die Übersetzung in mehrere Sprachen und Barrierefreiheitsfunktionen.

Manche versuchen mit SAPUI5 komplette SAP Dynpros nachzubauen. Das bedeutet, SAPUI5 sieht am Ende aus wie ein komplettes SAP System. Es wird überladen mit Funktionen, umständlich an Firmenrichtlinien (Stichwort Corporate Design) angepasst und zu guter Letzt meist nicht richtig durchdacht.

Um SAPUI5 richtig verstehen zu können, muss man wissen, wie es überhaupt aufgebaut ist. Eine SAPUI5 Anwendung kann in drei Teile gegliedert werden:

  • Oberfläche

 

 

 

 

 

  • Gatewayserver

 

 

 

 

 

  • Backend System

 
Dadurch, dass die Oberfläche separat für sich steht, also nicht wie in einem ABAP-Programm  oder einer Web Dynpro-Anwendung direkt im Back End läuft, sollten Daten jeweils vor der Speicherung geprüft werden.

Allein dadurch, dass sich eine Frontend-Logik relativ leicht in einem Browser ändern lässt, hat der User die Möglichkeit, diese umzuschreiben. Das bedeutet, Restriktionen, die wir in der Oberfläche gesetzt haben, können umgangen werden. Dies kann man nur dadurch verhindern, dass man die Daten wie oben erwähnt noch einmal prüft. Bei dem Design der Anwendung sollte darauf geachtet werden, dass der Aufwand für diese zweifache Logik nicht zu hoch wird.

Weil sich die Front End-Logik leicht in einem Browser ändern lässt, hat der Benutzer prinzipiell die Möglichkeit, diese komplett umzuschreiben. Das bedeutet, in der Oberfläche gesetzte Restriktionen können auf diese Weise leicht umgangen werden. Des Weiteren ändert sich gegenüber ABAP- oder Web Dynpro-Anwendungen die MVC-Geographie. Der Controller befindet sich in der UI5-Anwendung und somit direkt im Front End. Dies hat Einfluss auf unsere Entwicklung. Wird datenhungrige Geschäftslogik beispielsweise direkt im Controller untergebracht, kann dies den limitierten Speicher im Browser durchaus sprengen. Deswegen empfehlen wir folgende Massnahmen:

  • Strikte Einhaltung des MVC-Konzeptes: Datenbeschaffung und Geschäftslogik sind im Model unterzubringen. Nur Ereignisbehandlung, Datenformatierung und einfache Eingabeprüfungen sind direkt im Controller zu implementieren.
  • Nutzung von OData-Features: Das Laden des kompletten Datenbestandes ins Front End sollte vermieden werden. Stattdessen können OData-Funktionen wie Paging, Sortierung und Filterung benutzt werden. Das drückt datenintensive Logik nach unten in die Datenbank und schützt den limitierten Speicher im Browswer.
  • Persistierung des Anwendungszustandes: Die Persistierung von Zwischenergebnissen (inkl. Fehlermeldungen und UNDO/REDO-Stack) nach jeder Benutzereingabe ist ein Weg, um sich vor Datenmanipulation im Front End zu schützen. Auf diese Weise liegt die Kontrolle über die tatsächlich zu speichernden Daten vollständig im Back End. So kann beispielsweise das Resultat einer komplexen Kalkulation zur Bestätigung an das Front End geschickt werden. Das Back End muss anschliessend nur noch das zwischengespeicherte Ergebnis in die Datenbank schreiben und nicht die aus dem Front End zurückgelieferten Daten. Dieser Ansatz ermöglicht des Weiteren kontinuierliches Arbeiten, Kollaboration und das Wechseln von Endgeräten. Füllt ein Benutzer beispielsweise unmittelbar vor einem Meeting ein langes Formular aus und vergisst zum Schluss auf «Speichern» zu klicken, so könnte er trotzdem mit dem zuvor persistierten Zwischenstand weiterarbeiten, obwohl die Web Session inzwischen bereits abgelaufen ist (Kontinuierliches Arbeiten). Des Weiteren wäre er z.B. auch in der Lage, das erwähnte Formular im Zug via Tablet weiterzubearbeiten (Wechsel des Endgerätes).
Übersicht (CubeServ Materialstamm in SAPUI5)
Suche (CubeServ Materialstamm in SAPUI5)
Eingabeassistent (CubeServ Materialstamm in SAPUI5)
Drag & Drop-Funktionalität (CubeServ Materialstamm in SAPUI5)
Konfiguration (CubeServ Materialstamm in SAPUI5)

Beim Konzipieren einer UI5-Anwendung achten wir darauf, sinnvolle Module zu schaffen, so dass wir Funktionen auslagern und vereinfachen können. Wenn ein Anwender für einen Prozessschritt drei alte Anwendungen öffnen muss, können wir dies in einer neuen Anwendung zusammenfassen. Allerdings sollten wir nicht versuchen, den ganzen Prozess mit Gewalt in eine Applikation zu quetschen. Es sollte frei nach dem Motto «Keep it smart, keep it simple» gehandelt werden.

Haben wir mit diesem Artikel Ihr Interesse geweckt?
Wir helfen Ihnen gerne bei der Technologieauswahl und der Formulierung der richtigen Entwicklungsstrategie. Des Weiteren unterstützen wir Sie gerne bei der Entwicklung Ihrer neuen Anwendungen mit SAPUI5.
Rufen Sie uns an oder senden Sie uns eine E-Mail. Gerne vereinbaren wir mit Ihnen einen Präsentationstermin und besprechen Ihre individuellen Anforderungen.

 
1) Christiane Goebels, Denise Nepraunig, Thilo Seidel: SAPUI5 – Das umfassende Handbuch. Rheinwerk, 2016