Alternativen zu Fiori
Es wird gleich etwas technisch, denn wir wollen die Fiori-Technologie kritisch unter die Lupe nehmen und mit der Architektur unseres eigenen Produkts „CIS mobile“ vergleichen.
Da ist es zum Verständnis hilfreich, wenn Sie einige Fiori-Anwendungen und auch unser CIS mobile davor kurz ausprobieren. Hier sind die Links dazu:
- http://sapfioritrial.com für Fiori-Apps
- http://s10mobile.com für CIS mobile
Jede Fiori-App stellt eine isolierte, kleine Standard-Anwendungsfunktion dar, die als Web-Applikation mit HTML5 als Frontend implementiert ist. Sie kann auf jedem webfähigen Gerät (Desktop, Tablet, Smartphone) ausgeführt werden.
Im Benutzerinterface gleichen sich alle Fiori-Apps, denn sie folgen engen Standards, insbesondere dem „Fiori-1-1-3-UI“: eine Benutzerrolle, ein Szenario, drei Klicks. Jede Fiori-App fällt in eine der Kategorien „Transactional app“, „Fact sheet“ oder „Analytical app“, wobei nur „Transactional“ ohne Hana-Datenbank auskommt.
Technologisch nutzen die Fiori-Apps mehrere komplexe Frameworks: Die Anwendung läuft als JavaScript-Code im Browser. Sie generiert die HTML5-Oberfläche dynamisch mit SAP UI5, benötigt das JQuery-Framework und kommuniziert über OData-Protokoll, SAP Web Dispatcher und SAP Gateway mit dem FES (Fiori Frontend Server).
Der FES kontaktiert schließlich die SAP Business Suite, die Datenzugriffe und Updatefunktionen als zustandslose Services in Abap bereitstellt. Für unser Produkt CIS mobile, eine umfassende mobile Web-Anwendung für Vertriebsmitarbeiter auf Basis von SAP SD, ist Fiori sowohl was das 1-1-3-UI betrifft als auch bezüglich der technologischen Infrastruktur nicht ausreichend.
Das liegt primär an den berechtigten Ansprüchen der Benutzer: Ein Vertriebsmitarbeiter wünscht sich eine integrierte Sicht auf alle Aspekte der von ihm betreuten Kunden, beispielsweise Angebote, Aufträge, Lieferungen, Terminplanung, Besuchsberichte, Kontrakte, Bonusvereinbarungen, Dokumente zum Kunden.
Er erwartet Diagramme und Kennzahlen und möchte Kundeninformationen mobil in das zentrale SAP-System zurückmelden. Damit sind alle drei Anwendungstypen, „transactional“, „fact sheet“ und „analytical app“, erforderlich und ein nahtloser Übergang aller Komponenten.
Vertriebsbemühungen können umso erfolgreicher sein, je besser man die Kundensituation kennt. Dazu gehören dann nicht nur Angebote und Aufträge, sondern z. B. auch Kundenreklamationen und offene Rechnungen. Mit dieser Informationsfülle wäre Fiori mit seinem 1-1-3-UI überfordert.
Selbst wenn es gelingen würde, die Anwendung in das Fiori-Schema zu pressen, würde die Bedienung sehr hakelig, da das in Fiori verwendete Master-Detail-Schema ständige Kontextwechsel mit jeweils nur partikulären Sichten erzwingt.
Das UI in CIS mobile ist dagegen generell so gehalten, dass Sie Detailinformation sukzessiv abrufen können, die dann dynamisch in die angezeigte Seite eingefügt werden. Zum Beispiel können Sie für einen Auftrag die Auftragspositionen anzeigen und dann für die Position die Konditionen.
Das Gleiche nun für eine weitere Auftragsposition. Jetzt können Sie einfach durch Blättern auf der Seite die beiden Positionen im Detail vergleichen, was komfortabler und müheloser ist als eine dauernde Vorwärts-/Rückwärtsnavigation mit eigenem Merken der angezeigten Informationen.
UI und Technologie
Aber könnte man mit der Fiori-Technologie nicht auch ganz andere, komplexere UI-Pattern implementieren? SAP hat das anscheinend vor, da Fiori nach und nach SAP GUI als Frontend für S/4 Hana ersetzen soll.
Wird das funktionieren? Sieht man sich die Implementierung der Fiori-Apps näher an, ist hier trotz der Kleinheit der Anwendungen eine Menge JavaScript nötig. Wenn man in klassischer Abap-Dynpro-Weise eine der Fiori-App vergleichbare Anwendungsfunktion realisiert, reicht ein viel geringerer Codierungsaufwand. Das stimmt nicht sehr optimistisch, was zukünftige komplexe Anwendungen angeht.
CIS-mobile-Technologie
Zwischen unserer CIS-mobile-Technologie und Fiori gibt es einige Gemeinsamkeiten, aber ganz wesentliche Unterschiede. Wie Fiori verwenden wir HTML5 als Frontend, um alle webfähigen Endgeräte zu unterstützen.
Im Browser läuft bei CIS mobile aber nicht die gesamte Anwendung, sondern nur der UI-Teil in Form von vordefinierten HTML5-Masken plus sehr sparsam eingesetztem JavaScript für spezielle UI-Funktionen.
Das statische HTML hat den Vorteil, dass jeder normale HTML-Editor zum Entwickeln und WYSIWYG-Anpassen der Oberfläche eingesetzt werden kann, was bei UI5 nicht der Fall ist.
Die CIS-mobile-Anwendung selbst liegt auf einem zentralen Windows-Server mit Microsoft IIS (Internet Information Services). Sie ist in VB.NET implementiert, was den Vorteil einer ausgereiften und komfortablen Entwicklungsumgebung (Visual Studio) bietet, in der wir im Unterschied zu JavaScript alle Windows-Möglichkeiten zur Verfügung haben, zum Beispiel temporäre Dateien verwenden oder mit Grafikpaketen Diagramme erzeugen können.
Mit dem SAP-System kommuniziert CIS mobile über perfomante Schnittstellen im LAN, die auf SAP RFC und SAP GUI basieren. SAP Gateway und OData sind ebenfalls möglich, werden in CIS mobile aber nicht verwendet, da wir auch ältere ERP-Systeme und auch Non-Unicode unterstützen.
Die Datenbeschaffung ist in Abap-Funktionsbausteinen realisiert, das Update von SAP-Daten (z. B. Termine, Ansprechpartner, Angebote) über SAP-GUI-Transaktionen (Scripting), damit alle SAP-Standardprüfungen und Fortschreibungen garantiert sind.
Alle Bauteile der CIS-mobile-Architektur sind Standardtechnologien (HTML5, VB.NET, IIS, Abap, RFC und SAP GUI), von denen jede einzelne bereits eine robuste und reiche Funktionalität bietet.
In relativ einfacher und naheliegender Weise sind diese Bauteile zu einer Architektur zusammengefügt, mit der die Entwicklung anspruchsvoller Web-Anwendungen im SAP-Umfeld möglich wird.
Serverseitige Anwendung
Die serverseitige Anwendung bietet viele Vorteile: Erstens Sicherheit, denn eine JavaScript-Anwendung im Browser kann durch Aufruf von JavaScript-Debugging manipuliert werden.
Zweitens können wir auf dem Server in einem eigenen Anwendungscache, der von allen Benutzerprozessen erreichbar ist, häufig verwendete Read-only-Daten halten, auf die die Anwendung innerhalb von Mikrosekunden zugreifen kann.
Drittens sind komfortable Entwicklung, Fehlerbehebung und stabiler Dauerbetrieb auf einem Server leichter zu gewährleisten als bei einer Architektur, in der große Anwendungsteile auf einer Vielzahl von Geräten und Software-Versionen ablaufen. Für hohe Benutzerzahlen steht ein Dispatching auf mehrere Server zur Verfügung.
Die Verbindung von HTML-UI und VB.NET geschieht pro Benutzeraktion in einem einzigen Roundtrip zwischen Frontend und Server. Zwischen Server und SAP-System können dann mehrere Requests stattfinden.
Da die Antwortzeit eines Web Requests im Schnitt über dem Zehnfachen der LAN-Antwortzeit liegt, ist das eine vernünftige Strategie, mit der wir sehr gute Antwortzeiten erreichen.
Dagegen muss man sich bei einer browserseitigen Anwendung bemühen, pro Benutzeraktion nicht allzu viele Roundtrips zum Server auszulösen, was in der Regel bedeutet, dass die Datenschnittstelle der aufgerufenen Services immer umfangreicher wird und bei jeder zusätzlichen Information angepasst werden muss.
Die Wiederverwendung von Services durch andere Apps wird schwierig, da man entweder zu viele Informationen besorgt und das SAP-System unnötig belastet ist oder viele spezialisierte Services hat, dann aber mehr Roundtrips braucht.
UI und Anwendung
Die logische Verbindung zwischen HTML-UI und VB.NET besteht in einem Mapping der HTML-Hierarchie auf die Objekthierarchie in VB.NET. Insgesamt ist die CIS-mobile-Anwendung in Form von etwa 200 VB.NET-Klassen realisiert, deren Namen und Inhalt sich meist an SAP-Business-Objekten orientiert, also z. B. Verkaufspositionen VBAP oder Werke T001W.
Die Attribute der Klassen werden in der HTML-Oberfläche über ihren Namen angesprochen, die durch Interpretation des DOM gesammelt und an den Server geschickt werden.
Die Auswertung der Klassenattribute und die Navigation innerhalb der Objekthierarchie auf dem Server erfolgt dann dynamisch. Jede VB.NET-Klasse kann eigene UI-Teile in Form von HTML-Iframes beisteuern.
Damit erreichen wir eine gewisse Unabhängigkeit des UI von der Anwendung. Wenn beispielsweise in der Auftragsposition die Versandstelle als Code „1000“ angezeigt wird („VSTEL“) und nun noch der entsprechende Text „Versandstelle Zürich“ gewünscht wird, genügt es, in HTML das Attribut „VSTEL.VTEXT“ zu verwenden.
Auf dem Server erfolgt dann automatisch der Zugriff auf den Text über die SAP-Tabelle TVSTT, was in der Regel nur einen Cache-Zugriff von einigen Mikrosekunden bedeutet.
Zusätzliches Coding ist hier weder in HTML/JavaScript noch in VB.NET erforderlich, da die Verbindung zwischen dem Code der Versandstelle und dem Text über das Datenmodell bekannt ist. Sobald wir „VSTEL.VTEXT“ wieder durch „VSTEL“ ersetzen, entfällt auf dem Server der Zugriff auf die Texttabelle.
So weit dieser kleine Ausflug in ein Detail der Architektur, der zeigt, dass durch Modellierung und Interpretation des Modells zur Laufzeit viel Anwendungscode eingespart werden kann.
Separation of concerns
Die Trennung von UI (HTML), Anwendungscoding (VB.NET) und SAP-Zugriffen (Abap) erleichtert einen robusten und gut strukturierten Entwicklungsprozess. In Fiori ist diese Trennung, da UI und Anwendung gemeinsam in JavaScript implementiert sind, nur durch entsprechende Disziplin erreichbar.
Fazit
Die Stärke von Fiori liegt architekturbedingt in kleineren isolierten Anwendungen. CIS mobile ist dafür optimiert, dem professionellen Benutzer die SAP Business Suite auch in einer mobilen Web-Oberfläche adäquat zur Verfügung zu stellen: schnell, übersichtlich und umfangreich.
