Low-Code ohne Middleware: wie der Mobile Builder mobile SAPUI5-Apps direkt im System baut
Kein Node, kein externes Hosting, keine Integrationsschicht: Der Mobile Builder wird als Transport-Paket direkt ins SAP-System eingespielt. Was das für Betrieb und Sicherheit im Mittelstand bedeutet.
11. August 2026
Mobile SAP-Apps galten lange als Projekt mit eingebautem Overhead: ein zusätzliches Frontend-Framework, ein Node-Server, eine eigene Hosting-Umgebung, dazu ein Integrationslayer, der Daten zwischen SAP und der App hin- und herschiebt. Jede dieser Schichten bringt eigene Releases, eigene Sicherheitsupdates und eigene Ausfallszenarien mit. Der Mobile Builder verfolgt einen anderen Ansatz: Er wird als Transport-Paket direkt in das SAP-System des Kunden eingespielt. Designer und Runtime laufen dort, wo die Daten ohnehin liegen, ohne Node, ohne externes Hosting.
Was das konkret bedeutet
Wer eine App im Mobile Builder anlegt, öffnet einen visuellen Editor innerhalb des SAP-Systems. Komponenten werden per Drag-and-Drop auf die Landefläche gezogen, Eigenschaften direkt im Properties-Panel angepasst. Es entsteht keine separate Codebasis, die parallel zum SAP-System gepflegt werden müsste, und es gibt keine Middleware-Schicht, die zusätzlich betrieben, gepatcht und überwacht werden muss. Das Ergebnis ist am Ende eine native BSP-Anwendung, ein Artefakt, das sich wie jede andere SAP-Entwicklung transportieren, versionieren und in den Fiori Launchpad einbinden lässt.
Für IT-Abteilungen im Mittelstand ist das mehr als eine technische Fußnote. Jede zusätzliche Instanz zwischen SAP-Backend und Endgerät ist ein zusätzlicher Punkt, an dem etwas ausfallen, veralten oder ein Sicherheitsrisiko werden kann. Fällt diese Schicht komplett weg, verkürzt sich nicht nur die Angriffsfläche, sondern auch der Betriebsaufwand: Ein System, ein Patch-Zyklus, ein Verantwortlicher.
Kein Verzicht auf Tiefe
Low-Code wird oft mit "einfach, aber begrenzt" gleichgesetzt. Der Mobile Builder widerspricht dem an der Stelle, an der es zählt: der Anbindung ans Backend. Views lassen sich direkt an ABAP-Klassen binden, Event-Methoden hinterlegen und Konstanten-Klassen automatisch generieren. Wer JavaScript-Erfahrung mitbringt, wird sie in der Oberfläche kaum brauchen, wer ABAP-Erfahrung mitbringt, wird sie im Backend sofort wiedererkennen. Die Logik der App bleibt dort, wo SAP-Entwickler sie erwarten.
Ein System, ein Patch-Zyklus, ein Verantwortlicher.
Warum das für den Mittelstand relevant ist
Mittelständische SAP-Teams haben selten die Kapazität, ein zusätzliches Frontend-Team parallel zum ABAP-Team aufzubauen. Der Mobile Builder verschiebt die Entscheidung: Statt eine neue Technologie und eine neue Betriebsumgebung einzuführen, bleibt die App-Entwicklung Teil der bestehenden SAP-Landschaft, inklusive Transport-Request-Integration und Mehrsprachigkeit über zentral gepflegte i18n-Texte. Das senkt nicht die fachliche Anforderung an gute App-Konzeption, aber es senkt die Zahl der Systeme, die ein Team beherrschen muss, um vom ersten Wireframe zur produktiven App zu kommen.
Als SAP Gold Partner begleiten wir bei HPC Aktiengesellschaft Mittelstandskunden genau an diesem Punkt: bei der Frage, wo Low-Code echte Entlastung bringt und wo weiterhin fundiertes ABAP-Wissen gefragt ist, nicht als Widerspruch, sondern als Kombination.
Ihren Prozess einmal gemeinsam durchdenken?
Wir prüfen mit Ihnen, wo Low-Code echte Entlastung bringt und wo weiterhin fundiertes ABAP-Wissen gefragt ist.
Kontakt aufnehmen