Die StoneOne AG ist ein Softwareentwicklungshaus für komplexe Projekte. Mit unserer Web Service Factory setzen wir seit 2010 digitale Transformationsprojekte für Kunden und Geschäftspartner um. Oft geht es dabei um die Modernisierung von Legacy Software und die Ergänzung neuer Apps. So beschloss etwa einer unserer Kunden, die Offenbacher GIP Gesellschaft für innovative Personalwirtschaftssysteme mbH, im Rahmen ihrer „NEO-Strategie“ sukzessive alle Softwarelösungen als App in der Cloud anzubieten, beispielsweise eine digitale Akte oder die Reisekostenabrechnung. Dafür mussten zum einen die existierenden Softwarelösungen modernisiert und Cloud-fähig gemacht werden, zum anderen galt es, neue Serviceangebote von vornherein als Software as a Service (SaaS) bereitzustellen.
Nach und nach entstand aus StoneOne´s Web Service Factory (WSF) eine Plattform mit diversen Tools und Komponenten, die jeweils kundenspezifisch zum Einsatz gebracht wurden. Von Anfang an stand für uns die Herausforderung im Vordergrund in Projekten möglichst viel zu konfigurieren und nicht zu entwickeln. Im Idealfall sollen auch „Nicht-Developer“ in der Lage sein, einen Geschäftsprozess mit möglichst wenig Unterstützung selbst zu modellieren und umzusetzen.
Die WSF ist im engeren Sinn nicht selbst eine klassische Low Code Platform, wie etwa Mendix, Scopeland oder Xvision. Aber an vielen Stellen nutzt StoneOne im Produktportfolio Bausteine mit sehr wenig Code – entweder aus eigener Entwicklung oder von 3rd parties.
Unsere Komponenten entwickeln wir typischerweise agil in Java und nutzen dabei – soweit vorhanden – gut erprobte Open Source Komponenten, wie die Frameworks Spring Boot und oder Tools wie Graylog, Keycloak, Blockly oder Vue. Diese nutzen wir als Basis, um daraus eine adaptierbare, konfigurierbare und dokumentierte WSF-Komponente zu erstellen.
Zur Illustration unserer Vorgehensweise wollen wir hier exemplarisch die WSF-Komponente „Payment“ herausgreifen. Das Payment-Modul beinhaltet gängige Abrechnungsarten (Lizenzen, Dienstleistungen, Pakete, User-Abos, transaktionsbasierte Abrechnungen) und erstellbare Regeln („10 % Rabatt ab 100 Stück“). Die Komponente läuft auf einer Serverumgebung als eigenständiger, sicherer Service und kann über die bereitgestellte Schnittstelle in andere Applikationen integriert (eingebettet) werden. Über mitgelieferte UI-Komponenten, in unserem Beispiel auf Basis von Vue.js, kann die zu erweiternde Applikation auf die verschiedenen Fähigkeiten von Payment zugreifen. Dabei muss der Nutzer nicht den Scope „seiner“ Applikation verlassen.
Im folgenden Beispiel soll grob erklärt werden, wie eine Marktplatz-Applikation ohne viel Entwicklungsarbeit eine der WSF UI-Komponenten integriert. Um bei einem möglichst einfachen Use-Case zu bleiben, soll hier das Kontoverwaltungs-UI der Payment-Komponente zur Veranschaulichung dienen. Diese bietet ein Formular, die dazugehörige Validierung und den Backend-Serviceaufruf zur Anpassung der Kontodaten des Marktplatz-Nutzers.
Benutzeroberfläche ohne viel Entwicklungsaufwand
Die UI-Elemente der WSF Familie können einfach in die View einer (anderen) Applikation eingebettet werden. Die im Marktplatz installierten UI-Komponenten von Payment bringen dabei ein Basis-Styling mit sich. Dieses kann komplett oder nur teilweise von der Applikation überschrieben werden. In unserem Beispiel erbt das Standard „Light“ UI das eher dunklere Erscheinungsbild der Elternapplikation (unserem Marktplatz).
Dank der Vererbung hat der Developer dabei wenig bis keinen Aufwand, da entsprechende Bestandteile wie Eingabefelder und Buttons bereits in den Style des Marktplatzes integriert sind.
Applikation mit integriertem WSF/Payment UI-Element
Basisfunktionen „Out of the Box“
Basisfunktionen, wie etwa die Überprüfung der eingegebenen Daten, sind bereits integriert. Klickt der Nutzer beispielsweise auf Speichern und das System erkennt, dass die angegebene Kontonummer nicht dem erwarteten Format entspricht, wird eine Fehlermeldung zurückgegeben. Die im lokalen Kontext erkennbaren Fehler werden dabei abgefangen.
Einfache Backendanbindung über mitgelieferte Schnittstelle
In das UI-Element ist eine sichere Schnittstelle zum Payment-Service integriert. So müssen lediglich noch ein paar Variablen vergeben werden (z. B. unter welcher Adresse das Payment-Backend erreichbar ist). Über diese Schnittstelle werden Operationen wie die Aktualisierung der Kontodaten behandelt.
Internationalisierung
Alle Textbestandteile sind mit Internationalisierungsvariablen versehen, dabei werden die Standardsprachen deutsch und englisch im Default unterstützt. Die hinterlegten Messages können bei Bedarf einfach von der Applikation überschrieben und durch weitere Sprachen erweitert werden.
Mehr Individualisierungsmöglichkeiten durch granulare Komponenten
Die WSF UI-Elemente bestehen ihrerseits auch wiederum aus kleineren, wiederverwertbaren Elementen. Ist also eines der UI Elemente aus der WSF Familie nicht passend, kann der Developer sich aus deren „Werkzeugkasten“ bedienen.
So können Developer bei Bedarf Schicht für Schicht kleinere Bausteine bis hin zur nativen Implementierung verwenden – je nach Individualisierungsgrad. Komponenten, die mit sogenannten Slots ausgestattet sind, können mit neuen Elementen erweitert werden, ohne diese komplett auszutauschen. Damit kann selbst entschieden werden, wann und wie viel Aufwand investiert werden soll, von High- bis Low-Level-Code.
Low-Code mit generischen adaptiven UI-Komponenten
Die generischen UI-Komponenten erweitern sich auf Basis des mitgegebenen Datenmodells automatisch. Schauen wir uns hierbei die InvoiceList aus einer anderen UI-Komponente des Payment-Moduls an. Ziel dieser Komponente ist es, alle Rechnungen eines Kunden in einer Tabelle anzuzeigen, um sie zum Beispiel zum Download zur Verfügung zu stellen. Hauptbestandteil dieser Komponente ist die DataTable.
Hier könnte die angezeigte Tabelle neben Datum, Nr., Status, Summe und dem Download allein durch Erweiterung des Datenmodells automatisch um eine oder mehrere Spalten ausgebaut werden.
Soll die Pagination deaktiviert werden kann der entsprechende Parameter beim Verwenden dieser Komponente auf false gesetzt werden.
<Box title="Rechnungen">
<DataTable :dataSource="invoices" pagination="true">
<Filter :fields="['date', 'status', 'invoiceId']" />
</DataTable>
<Button :service="someBusinessLogic" />
</Box>
UI-Element mit Pagination
Fazit
Durch den Einsatz von vorkonfigurierten und standardisierten Komponenten können wir die projektspezifische Code-Erstellung auf ein Mindestmaß beschränken. Vieles kann auch durch Konfiguration oder Injektion von vor erstellten Building Blocks (z.B. Vue Components) umgesetzt werden, sodass auch hier oft keine echte Programmierung notwendig ist. Nur für die Implementierung Business-spezifischer Logik oder Konnektoren zu Drittsystemen kann oft nicht auf Programmierung verzichtet werden – aber so bleibt der Anteil „low“.
Auch wenn die Vorteile von „Low Code“ auf der Hand liegen, es gibt auch ganz klare Grenzen. Komplexe Business-Logik kann meist nicht konfiguriert werden, da sie oft auch zeitkritisch ist. Skalierung für Hochlast muss meist auch projektspezifisch implementiert werden.
Für unsere Kunden ergibt sich eine Reduktion von Aufwand und Risiken in Verbindung mit kürzerer Entwicklungszeit – zusätzlich können frühzeitig das UI und auch grobe Abläufe abgestimmt werden, da Rapid Prototyping durch Klickdummys eine schnelle Information und Rückkopplung durch den Kunden ermöglicht.
Neben Payment setzen wir in Projekten auch weitere eigene Komponenten ein, die Low Code Charakter haben, hierzu zählen u. a. Data Acquisition, Audit/Logging, Billing/Tracking, Extraction, PDF Handling, Rules, Storage, User Admin/IAM.
Autoren: Julia Heidrich und Mathias Petri, StoneOne AG