Multi- & Full-Stack SAP UI5 & OData application development with storm
Die neue Programmiersprache storm ermöglicht es, Anwendungen und Services zu definieren. Im Kontext von SAP geht es hier insbesondere um OData Services und UI5 Apps. In diesem Beitrag werden die grundlegenden Konzepte der Programmiersprache an einer Beispielanwendung aufgezeigt.
Das Ziel der von frequi entwickelten Programmiersprache ist es, Quellcode von Anwendungen zu erzeugen. Die Qualität der Implementierung soll dabei so sein, wie es ein guter UI5 XML, JavaScript oder OData Experte umsetzen würde.
1. Business Case
Wir werden dies am Beispiel der fiktiven Firma „Bavarian Robos“ aufzeigen, die in Deutschland, Bayern, ansässig ist und Roboter für verschiedene Zwecke baut. Im Rahmen der Entwicklung der Roboter ist es notwendig, eine Vielzahl von Regeln und Vorschriften bei der Herstellung einzuhalten. Unter anderem ist es Vorschrift, alle für die Produktentwicklung erstellten Dokumente zu klassifizieren. Ebenso gibt es einen verantwortlichen Geschäftspartner für ein Dokument. Diese Dokumente werden intern und zu großen Teilen extern von Entwicklungspartnern, die nicht vor Ort sind, benötigt und bereitgestellt.
Wir gehen technisch davon aus, dass die „Bavarian Robos“ alle relevanten Daten, wie Produktinformationen oder Geschäftspartner, in ihrem SAP ERP System ES4 abgelegen. Gleichzeitig setzt die Firma die Strategie um, schnelle und flexible Anwendungen, auf die externe Partner zugreifen, auf der SAP Cloud Platform zu entwickeln.
2. Implementierung
Wir starten zuerst mit der Implementierung des OData Service auf der SAP Cloud Platform. Wir bilden auf Basis der Anforderungen alle relevanten Daten zu einer Produktinformation als einfache Entität ab.
Schritt 1: Neuer OData Service
Wir starten zuerst mit der Definition der ProductInfo und dem zugehörigen OData-Service:
Dies ist bereits alles, was notwendig ist, um einen OData-Service inklusive einer Datenbank-Persistenzschicht für die SAP Cloud Platform zu erzeugen.
Schauen wir mal rein, was hier u.a. generiert wurde. Da wir die SAP Cloud Platform (bzw. den Systemtyp SapCloudNeo) angegeben haben, erzeugen wir automatisch Java Code für alle notwendigen Artefakte. Beispielsweise die JPA Entity:
Oder hier ein Ausschnitt aus dem Quellcode zum OData-Service für das Lesen des OData Entity Sets ProductInfos:
Und dies natürlich eingebettet in einem vollständigen Projekt, hier exemplarisch einige generierte Packages und Files aufgeklappt:
Aber eigentlich wollen wir Sie ja gar nicht mit zu vielen Dateien und Details abschrecken, der entscheidende Aspekt bei der Entwicklung mit storm ist ja gerade, dass Sie immer den Überblick behalten und nicht alle Details der Implementierung kennen müssen.
Also, bitte nicht vergessen, aus den knapp 18 Zeilen unserer storm-Datei sind bereits viel mehr notwendige Dateien entstanden.
Das Projekt kann jetzt direkt in der Entwicklungsumgebung Eclipse auf den lokalen TomEE 7 Server deployed werden und somit ist der OData Service sofort verfügbar:
Schritt 2: Einfache UI5 App erstellen
Die Stärke von storm ist es, dass wir jetzt neben den Backend Services auch das Frontend in derselben Sprache beschreiben können. D.h. wir definieren jetzt in derselben Datei eine erste App, die aus einem Launchpad besteht, mit dem wir neue Produktinformationen anlegen können und nach diesen Informationen suchen können:
Diese 12 Zeilen sind bereits ausreichend, um beim Speichern der storm-Datei ein vollständiges UI5 Projekt zu erzeugen, das mehrere UI5 Views umfasst und alle Default CRUD UI’s (Create, Read, Update, Delete) erstellt.
Wenn wir dies deployen, haben wir bereits folgende UI’s angelegt:
– Ein Einstiegs-Dashboard zu unserer App:
– Ein UI zum Anlegen unserer ProductInfo Entität. Nochmal kurz zur Erinnerung, wir haben lediglich Folgendes definiert:
Nur daraus ist jetzt ein UI5 View entstanden, der bereits viele kleine Details per Default und intelligenten Annahmen umsetzt:
-
ein Back-Button zurück zum Dashboard
-
einen größeren Eingabebereich
-
alle notwendigen Navigation-Routing-Konfigurationen
-
Standard-Buttons, da storm weiß, dass dies ein Eingabe-UI für die Entität ProductInfo ist.
– und ein List-UI, mit dem wir nach Produktinformationen suchen können:
Schritt 3: UI5 Erweiterung – Dokumente
Selbstverständlich haben wir in der Regel mit den aktuellen standardmäßig generierten UI’s noch keine optimalen, den Geschäftsanforderungen entsprechenden, Oberflächen fertig implementiert. Die Idee von storm ist, dass wir unsere Anforderungen schrittweise genauer spezifizieren. Dabei bildet storm die für UI-Anforderungen notwendigen Elemente und UX-Pattern in einer Template Library ab. Dadurch bedienen wir typische Anforderungen an die Anwendung direkt aus der Sprachsyntax und den Erweiterungs-UX-Pattern.
Ein Beispiel: Wir haben beim Design unserer Programmiersprache entschieden, dass neben einer Entität (wie ProductInfo) hier ein weiteres strukturierendes Element, das Dokument (PDF, Word-Dokument, Bild, …), eine eigene syntaktische Abbildung benötigt. Dadurch werden Anforderungen optimal und schnell definiert und implementiert.
Im vorliegenden Fall haben wir keine spezifischen Metadaten am Dokument selber. Definieren Sie gerne weitere Felder analog zu den Entitäten, um sie in der Persistenzschicht zu benutzen. Wir verwenden unseren selbstdefinierten Dokumententyp, um bis zu 20 Dokumente dieses Typs als Referenz an unsere ProductInfo-Entität anzuhängen:
Das UI ergänzen wir dann um das storm Documents UX-Pattern, das alle notwendigen UI-Elemente generiert, wie beispielsweise UI5 Control UploadCollection:
Daraus entsteht dann ein vollständiges UI, mit dem wir Dokumente hochladen können:
Die Speicherung der Dokumente erfolgt, da wir als Zielplattform die SAP Cloud angegeben haben, in einem SAP Cloud Platform Document Service (CMIS) Unterordner von /documents/productsinfos mit der ID der ProductInfo Entität. Alle Dokumente werden in diesen Ordner gelegt, der als Ordner-Name den Inhalt des Feldes Name aus der ProductInfo erhält. So hat man rein durch deklarative Definition in storm bereits eine vollständige, wohlgeordnete Dokumentenablage in der SAP Cloud.
Schritt 4: Externe OData Services
Im Business Case haben wir definiert, dass die ProductInfo noch mit den Produkten und Geschäftspartnern aus dem ERP-System verknüpft werden sollen. D.h. wir werden jetzt das ERP-System definieren und die notwendigen OData Entity Sets, die wir von dort benötigen, referenzieren:
Die generate ServiceGroup Anweisung extrahiert alle vom angegebenen OData-Service notwendigen Informationen in eine eigene storm-Datei, die in unser Projekt kopiert wird, so dass wir sofort sehr flexibel auf alle Funktionen und Entity Sets in den OData-Services zugreifen können.
Wir ergänzen unsere Entity-Definition um zwei Felder, zum einen wollen wir eine Menge von Produkten zu dieser Entität verknüpfen, zum anderen soll ein verantwortlicher Geschäftspartner optional angegeben werden können:
Nur diese 5 Zeilen waren notwendig, und wir haben jetzt bereits, wenn wir das Standard-UI generieren, eine vollständig korrekt funktionierende UI5 App generiert, die es ermöglicht auch andere OData-Services zu integrieren:
Die unterschiedliche Visualisierung der beiden Listen ist am Ende der Felddefinition flexibel aus allen Werten der Entität ableitbar.
Schritt 5: UI responsiv, hübscher und dynamischer machen
Natürlich ist das aktuelle UI noch nicht atemberaubend schön, strukturiert und auch noch nicht flexibel und adaptiv.
Daher werden wir aus dem aktuell simplen UI, in dem alle Felder untereinanderstehen, ein tab-basiertes UI bauen, das strukturierte Eingabebereiche hat:
Wir definieren mehrere Bereiche, sogenannte Areas. Im UX-Pattern Tabs werden diese als einzelne Tabreiter umgesetzt. Innerhalb des Form UX-Pattern bedeutet area, dass wir die Felder gemeinsam gruppieren.
Die Responsivität wird durch selbst definierbare Responsive-Pattern pattern6, pattern4 sichergestellt, die oben an verschiedenen Stellen eingebaut worden sind. Diese können Sie auch selber definieren und verwenden:
Auf diese Weise können Sie beliebige eigene Namen und Definitionen für responsive Pattern anlegen, die für Sie gut funktionieren.
Et voila, wir haben somit ein sehr gut strukturiertes UI mit verschiedenen Tabs, das Sie sofort produktiv einsetzen können:
Dieses ist auch wie bereits gezeigt responsive, hier am Beispiel der Darstellung in einem schmalen Fenster oder Smartphone:
Schritt 6: Suche integrieren
Wir haben ja bereits ein List-UI definiert, das aktuell die Liste der Produktinformationen anzeigt. Jetzt machen wir daraus mit wenigen Zeilen Code eine sehr mächtige Suchoberfläche inklusive Volltextsuche und flexiblen Filtern und Suchtabs.
Wir verwenden hier das storm SearchList UX Pattern, das es ermöglicht, die Namen der zu benutzenden Felder für die Ergebnisliste (@UI.ListElement oder gar keine weiteren Angaben) und deren Funktionen über Annotationen zu definieren:
-
@UI.SearchTabFilter für automatische Suchtabs
-
@UI.SearchTerm für Felder, die in der Volltextsuche benutzt werden sollen
-
@UI.SearchFilter, wenn wir hier einen Eingabe Filter bereitstellen wollen
Hier die notwendige Definition des Such UI’s:
Daraus wird ein professionelles und im Sinne der Geschäftsanforderungen vollständiges User Interface inklusive aller notwendigen Backend-Erweiterungen erstellt:
Sobald wir auf Show Filter Bar klicken, werden die oben definierten Filter ebenfalls angezeigt:
Jedes Filter-Element UI wird entsprechend der uns vorliegenden Informationen möglichst optimal gerendert. So sieht beispielsweise der Type Filter aus:
Insbesondere möchten wir darauf hinweisen, dass wir aufgrund der storm Suchdefinitionen auch eine Volltextsuche implementiert haben. Diese ist über mehrere Felder der Entität, hier sogar automatisch, in den Dateinamen der hochgeladenen Dokumente sucht:
3. Multi Stack: Umstellen von SAP Cloud auf SAP NetWeaver
Die von uns erzeugte Anwendung läuft neben dem lokalen TomEE 7 Server auch auf der SAP Cloud Platform und verwendet deshalb die dort benötigten API’s zum User/Group-Management. Als Dokumentenspeicher wird SAP Cloud Document Service (CMIS) verwendet und weitere technische Details wie die Eclipse-Projekte sind spezifisch nur für diese Plattform.
storm abstrahiert in seiner Definition genau von diesen Implementierungs-Spezifika über den SystemType.
Vorher hatten wir das SAP Cloud System so angelegt:
Wenn wir jetzt von SAP Cloud Plattform auf SAP NetWeaver Portal umstellen wollen, ist Folgendes einzugeben:
Damit ist alles erledigt! Die Anweisungen für das Generieren von Apps und Service Groups, die alle den Systemalias referenzieren, sind nun informiert, dass wir jetzt für eine andere Plattform implementieren wollen.
Ihre storm UI5 App hat somit alle dokumentbezogenen API’s auf SAP NetWeaver KM umgestellt, das heißt wir legen die Dokumente jetzt auch dort ab. Auch die UME wird jetzt benutzt, ebenso werden jetzt EAR Projekte erzeugt, damit diese sofort auf dem NetWeaver Stack deployed werden können.
Damit haben Sie als Benutzer von storm einen sehr eleganten und schnellen Weg, um OData- und UI5-JavaScript-Entwicklung effizient auf allen von storm unterstützten Plattformen zu betreiben.
4. Zusammenfassung
Wir haben hier einige Aspekte der von frequi entwickelten Programmiersprache storm dargestellt, die insbesondere zeigen, wie effizient Sie qualitativ hochwertige SAP Cloud und SAP NetWeaver UI5 Anwendungen mit Anbindung an ERP-Systeme erstellen können. Dadurch, dass die Sprache storm in der aktuellen Version insbesondere die typischen Anwendungszenarien wie Dashboard, CRUD-Eingabe-UI’s, und Suche bestens unterstützt, können Sie bei diesen Szenarien Ihre Anforderungen sehr schnell umsetzen.
Wenn wir uns eine der Zeilen aus dem Generierungsprotokoll anschauen:
88 Lines created 107 files with 19976 Lines
wird klar, dass in dem Beispiel -1- Zeile storm Code im Schnitt -266- Zeilen realen Java- und JavaScript-Quellcode erzeugt hat. Das nennen wir den storm Efficiency Faktor.
Die Sprache storm hat allerdings noch viel mehr zu bieten, wie dynamische Formulare (Ein-/Ausblenden bestimmter UI-Bereiche basierend auf Anwendungsdaten oder Berechtigungen), Custom Actions und Exits, flexible Validierungen der UI’s feld- oder modellbezogen, kompletter Support von komplexen ACL-Berechtigungen, die gleichzeitig auch für Daten und Dokumente umgesetzt sind, und natürlich auch die Unterstützung von performanter berechtigungsabhängiger Suche bei den von uns angelegten Entitäten und vieles mehr.
Profitieren Sie davon, dass wir viele Standard-UX-Pattern bereits effizient umgesetzt haben und Sie diese nur noch benutzen oder an den von uns vorbereiteten Erweiterungspunkten auch beliebigen eigenen Frontend- und Server-Code einbringen können. Und wenn Sie wollen, nehmen Sie den erzeugten professionellen Code und machen Sie damit, was immer Sie wollen! Eine Top UI5 App, einmal bei uns bezahlt mit einem fairen Preis, der sich an der Komplexität der App ausrichtet.
Schenken Sie sich Zeit!