Das SAP Low-Code-Portfolio: SAP Build, SAP Fiori Elements und SAP BAS

Wenn man sich Low-Code-Tools und -Services im Umfeld der SAP BTP ansieht, zeichnen sich aktuell drei wesentliche Bausteine ab, aus denen sich das Low-Code-Portfolio der SAP zusammensetzt: SAP Build, SAP Fiori Elements & SAP Business Application Studio (BAS). Der prominenteste Vertreter hierbei ist sicherlich SAP Build, doch auch Fiori Elements und Business Application Studio tauchen in jüngster Zeit vermehrt in Diskussionen und Beiträgen rund um Low-Code auf. Grund genug daher für unseren Head of Development Jakob Frankenbach, sie einmal näher unter die Lupe zu nehmen.

SAP Build – drei starke Tools für Citizen Developer

Bei SAP Build handelt es sich um eine Suite von Low-Code-Tools, die sich hauptsächlich an Citizen Developer richten und die es diesen ermöglichen, Geschäftsanwendungen für ihren digitalen Arbeitsplatz selbst zu entwickeln, um dadurch Geschäftsprozesse eigenverantwortlich digitalisieren und (teil-)automatisieren zu können, ohne hierfür auf die Bereitstellung knapper IT-Ressourcen angewiesen zu sein. Im Wesentlichen setzt sich SAP Build aus den folgenden drei Services zusammen:

1. SAP Build Apps
Hierbei handelt es sich ursprünglich um die Low-Code-Plattform AppGyver, die SAP 2021 erwarb und anschließend in die SAP Build Suite überführte. SAP Build Apps erlaubt es, responsive Webanwendungen mittels visueller Editoren zu erstellen. Über das Zusammenbauen der reinen UI-Elemente hinaus bietet das Tool zudem auch Möglichkeiten, Datenquellen und Datenvariablen zu konfigurieren und somit die Anwendungen mit bestehenden Backendsystemen zu integrieren. Das Schreiben von Code ist nicht erforderlich, das Tool bietet jedoch verschiedene Erweiterungspunkte an, die es erlauben, mit nativem JavaScript zusätzliche Funktionalität zu implementieren.

2. SAP Build Process Automation
Ehemals unter dem Namen SAP Workflow Management und SAP iRPA bekannt, dient die SAP Build Process Automation dazu, Geschäftsprozesse in einer grafischen Oberfläche mittels an BPMN orientierten Strukturelementen abzubilden und anschließend durch die darunterliegende Workflow Engine des Tools automatisiert ablaufen zu lassen. Dabei ist es möglich, rein konfigurativ manuelle Zwischenschritte wie Genehmigungen oder formularbasierte Eingabe von Informationen hinzuzufügen. Auch entsprechende einfache UIs lassen sich ohne Quellcode erstellen, über die die Endbenutzer dann im späteren Prozessablauf die oben erwähnten manuellen Eingaben durchführen können. Auch Entscheidungstabellen und die Integration von externen Datenquellen lassen sich über das visuelle UI anlegen. Für komplexere Use Cases können zusätzliche Logikbausteine oder UIs, die mit Pro-Code erstellt werden, hinzugefügt werden.

3. SAP Build Work Zone
Auch bei der SAP Build Work Zone handelt es sich um einen alten Bekannten, nämlich um das SAP Fiori Launchpad (SAP Build Work Zone Standard Edition) sowie die SAP Work Zone (SAP Build Work Zone Advanced Edition). Mittels SAP Build Work Zone lässt sich für die Mitarbeitenden eines Unternehmens ein digitaler Arbeitsplatz kreieren. Dieser digitale Arbeitsplatz ist als ein zentraler Einstiegspunkt zu verstehen, über den alle Zugriff auf die für sie im digitalen Umfeld seines Aufgabenbereichs relevanten Anwendungen und Tools erhalten. Dies ist also der Ort, der die zentrale Klammer bildet, um die Lösungen, die mittels SAP Build Apps und SAP Build Process Automation gebaut wurden. Angereichert wird die SAP Build Work Zone zusätzlich um Dashboarding-Funktionalität sowie Tools zur Kommunikation und Kollaboration. Die Bereitstellung einer SAP Build Work Zone erfolgt rein konfigurativ, aber auch hier gibt es Möglichkeiten beispielsweise mittels Pro-Code entwickelten Integration Cards maßgeschneiderte Inhalte zusätzlich bereitzustellen und zu integrieren.

Wie gut kennen Sie sich schon mit Low-Code aus?

Das Thema Low-Code ist derzeit allgegenwärtig und macht auch vor der SAP-Welt keinen Halt: SAP Build (bald auch mit Unterstützung durch den SAP GenAI-Assistent Joule), SAP Fiori Elements, SAP Business …

Bei sovanta beschäftigen wir uns bereits seit längerer Zeit intensiv mit diesen verschiedenen Tools und Services der SAP Build Suite und sind durchaus beeindruckt von der Praxistauglichkeit. Die Geschwindigkeit, mit der sich Use Cases realisieren lassen, ist enorm. Funktionsfähige Prototypen, die bereits nach wenigen Stunden oder Tagen das Licht der Welt erblicken, sind eher die Regel als die Ausnahme. Es ist jedoch wichtig zu beachten, dass sich das Lösungskonzept streng an den Möglichkeiten der Tools orientiert. Sobald man versucht, aus der Standardfunktionalität auszubrechen, was durch die bereits erwähnten Pro-Code-Erweiterungspunkte grundsätzlich möglich ist, steigen Komplexität und Aufwände deutlich an. Daher empfiehlt es sich, SAP Build zur Realisierung kleinerer, klar definierter Use Cases zu verwenden, die zu 100% standardkonform sind und es voraussichtlich auch mittel- bis langfristig bleiben werden.

SAP Fiori Elements

Bevor wir näher auf SAP Fiori Elements eingehen, zunächst ein paar einleitende Sätze zum SAPUI5 Framework. Dieses wird dazu verwendet, Webanwendungen basierend auf dem SAP Fiori Design System zu entwickeln. Klassischerweise sind SAPUI5-Anwendungen Pro-Code Applikationen, d.h. Software Developer schreiben einen entsprechenden JavaScript/TypeScript-Code und bedienen sich dabei vordefinierter SAPUI5-Komponenten des Frameworks, reichern diese um zusätzliche Geschäftslogik an und kümmern sich um die Integration der relevanten Backend-Schnittstellen, wobei es sich im Regelfall um OData-Services handelt.

Bestehen die fünf SAP Fiori Design Principles den Praxistest?

Eine gute User Experience in Anwendungen ist längst kein Hexenwerk mehr. Mit SAP Fiori entsteht dank ausgereiftem Design System eine einheitliche und konstante UX über diverse Anwendungen hinweg. Attraktive Oberflächen, …

Bei Fiori Elements handelt es sich um eine Bibliothek innerhalb des SAPUI5-Frameworks, die dieses um eine deklarativ geprägte Spielart erweitert. Hierfür definiert Fiori Elements eine Menge vorgegebener Floorplans und Layouts, die typische Szenarien für Fiori-Anwendungen abbilden, beispielsweise eine tabellarische Listenansicht oder eine Detail-/Steckbriefansicht einzelner Entitäten. Darüber hinaus gibt es definierte Metadaten-Annotationen, die sich zu OData-Services (auf der Backendseite) hinzufügen lassen, d.h. ein OData-Endpunkt kann um weitere Informationen angereichert werden, die beschreiben, wie sich die zurückgelieferten Entitäten auf einen bestimmten Floorplan mappen lassen. Eine SAPUI5-Applikation mit Fiori Elements ruft also einen Endpunkt auf und erhält vom OData-Service nicht nur Geschäftsdaten zurück, sondern darüber hinaus auch die annotierten Metadaten, die interpretiert und zur Laufzeit in ein entsprechendes UI umgesetzt werden.

Die Vorteile dieses Ansatzes sind vergleichbar mit denen von SAP Build Apps. Ein Entwickler, der mit der Funktionsweise und Syntax von Fiori Elements vertraut ist, kann innerhalb weniger Stunden funktionierende Applikationen inklusive Integration mit Datenendpunkten realisieren, der Aufwand ist signifikant geringer als beim klassischen Pro-Code-Vorgehen mit SAPUI5. Allerdings gelten auch hier ähnliche Einschränkungen wie bei SAP Build Apps. Der Geschwindigkeits- und Kostengewinn setzt voraus, dass man sich an den vordefinierten Floorplans und Layouts orientiert. Diese decken zwar die klassischen Use Cases ab, doch für sehr komplexe Anwendungen kann man schnell an die Grenzen des Möglichen geraten. Hier bietet Fiori Elements zwar Erweiterungspunkte an, über die sich Pro-Code-Funktionalität hinzufügen lässt, doch auch diese Möglichkeit sollte man sparsam einsetzen, ansonsten findet man sich allzu bald in verworrenen und komplexen Workarounds um das Framework wieder, wodurch der Effizienzvorteil schnell wieder verloren geht. Im Gegensatz zu SAP Build Apps ist SAP Fiori Elements jedoch kein Tool, das es erlaubt, Entwicklungsarbeit an Citizen Developer auszulagern.

Auch wenn der deklarative, annotationsgetriebene Ansatz wahrscheinlich leichter zu erlernen ist als die JavaScript-Programmiersprache und deren Verwendung zusammen mit dem SAPUI5-Framework, ist das Vorgehen dennoch stark technisch ausgeprägt und erfordert ein tieferes Verständnis für Datenstrukturen und -schnittstellen, kurz gesagt die klassischen Pro-Code-Skills.
Jakob Frankenbach
Head of Development, sovanta

Business Application Studio

Ähnlich wie SAP Fiori Elements ist auch das SAP Business Application Studio ein Tool, das man zunächst eher in der Pro-Code-Ecke verorten würde, das in jüngster Zeit aber auch zunehmend im Zusammenhang mit Low-Code genannt wird. Beim Business Application Studio (Nachfolger der WebIDE) handelt es sich um einen Service der SAP Business Technology Platform (BTP), der Software Developer eine browserbasierte und für die Zwecke der Erstellung von Anwendungen auf der SAP BTP eine vorkonfigurierte Entwicklungsumgebung bereitstellt. Das heißt, Software Developer müssen nicht länger eine eigene Entwicklungsumgebung lokal auf der eigenen Hardware einrichten, sondern benötigen letztlich nur einen Webbrowser, um von jedem beliebigen Endgerät online auf diese zuzugreifen.

Das SAP Business Application Studio ist aber nicht nur eine klassische Entwicklungsumgebung im Sinne einer Anwendung, in der sich Quellcode-Dateien lesen und schreiben lassen, angereichert um diverse Shortcuts und Tools zur effizienten Code-Navigation und Autovervollständigung. Stattdessen liefert das SAP Business Application Studio darüber hinaus einen wachsenden Katalog von Wizards und Code-Generatoren. Bei diesen navigieren Software Developer je nach Use Case durch verschiedene Konfigurationsschritte, bei denen sich formularbasiert beispielsweise externe Datenquellen, eigene Datenstrukturen oder ganze UIs (basierend auf Floorplans) konfigurieren lassen. Sobald alle erforderlichen Eingaben gemacht wurden, erzeugt das Business Application Studio den für das konfigurierte Szenario erforderlichen, lauffähigen Code. Für sehr einfache Use Cases können hierdurch im besten Fall fertige Anwendungen ganz ohne Schreiben von Quellcode generiert werden. Zumeist dient das Ergebnis des Wizards als Prototyp, der sich vom Software Developer anschließend im Pro-Code-Verfahren erweitern und verfeinern lässt. Das Ergebnis ist hierbei dann immer noch eine deutliche Beschleunigung des Entwicklungsprozesses.

Fusion-Teams in der Low-Code-Welt

Auch wenn, wie zum Beispiel oben zu SAP Build Apps beschrieben, alles rein konfigurativ über die UI gehandhabt werden kann, erfordert die Arbeit mit den SAP Low-Code-Tools dennoch ein tieferes Verständnis für technische Schnittstellen und Integrationsansätze sowie ein ausgeprägtes logisches und analytisches Denkvermögen. Aus diesem Grund empfehlen wir den Einsatz von Low-Code in sogenannten Fusion-Teams, d.h. Entwicklungsteams, die sich nicht nur aus Software Developers, sondern auch aus Citizen Developers zusammensetzen. In diesem Setup lassen sich viele Tätigkeiten von Citizen Developers durchführen, es wird aber gleichzeitig durch die involvierten IT-Experts sichergestellt, dass Anwendungen nachhaltig stabil, skalierbar aufgebaut und relevante Aspekte rund um das Thema Governance, wie beispielsweise IT-Sicherheit und Datenschutzkonformität, in angemessener Weise berücksichtigt werden.

Jakob Frankenbach
Head of Development, SAP BTP Solution Architect

Ihr Kontakt

Mit seiner breiten Expertise ist Jakob als Head of Development der perfekte Ansprechpartner für unsere Kunden in Cloud-Projekten.
Tags
AI & Data IT verein­fachen SAP BTP SAP Build Apps SAP Build Process Automation SAP Build Work Zone SAP Business Technology Platform SAP Fiori Software Development