Architektur

Der Mobile Builder besteht aus zwei ausgelieferten Anwendungen (Designer und Runtime), einer geteilten UI5-Library und einem ABAP-Backend. Alles läuft im SAP-System des Kunden – kein externes Hosting, kein Node-Server zur Laufzeit. Das gilt on-prem wie in der S/4HANA Cloud; die Bausteine sind dieselben, nur die Kanäle zwischen ihnen unterscheiden sich.

Gesamtbild

On-Prem

S/4HANA Cloud

Bausteine

Baustein	Rolle
Designer (hpc.mobile.builder.mobilebuilder, Cloud hpc.mobile.builder.cloud.mobilebuilder)	Visueller Editor: Controls per Drag-and-Drop, Properties, LogicFlow, Build & Deploy.
Runtime	Template, das jede gebaute App ausführt. Wird beim App-Build als template.zip mitgeliefert.
Core-Library (hpc.mobile.builder.mobilebuilder.core)	Geteilte UI5-Library: Custom-Controls, Services, Models, Utility, Decryption – von beiden Apps genutzt. On-prem in jede App eingebettet, in der Cloud ein eigenes Repository ZMB_CORE.
ABAP-Backend (on-prem /MOBBUILD/*, Cloud ZMOBBUILD_*)	App-Persistenz, Build-Buchführung, Transport- & Package-Handling, Lock-Registry, Lizenz; on-prem zusätzlich Deploy und FLP-Registrierung, in der Cloud übernimmt das der Designer aus dem Browser.
MCP-Server	Optionaler KI-Zugang zum Designer-Backend – steuert App-/View-/Control-Mutationen per Werkzeug. Siehe Automatisierung & MCP.

Kommunikation mit dem Backend

On-Prem

Die fachlichen Backend-Calls des Designers laufen als HTTP POST an /mobbuild/admin mit einer JSON-RPC-artigen Nutzlast (method + parameters). Der Designer hängt automatisch Client- und Browser-Kennung sowie den Benutzertyp an. Zwei Ausnahmen: Die FLP-Gruppen-Verwaltung spricht direkt den SAP-Standard-OData-Service /sap/opu/odata/UI2/PAGE_BUILDER_CUST an, und die Vorschau sowie gebaute Apps kommunizieren zur Laufzeit über /mobbuild/run.

Parallel besteht eine WebSocket-Verbindung (/sap/bc/apc/mobbuild/apc_designer) für Echtzeit-Ereignisse beim Multi-User-Editing. Sie wird einmal pro Session aufgebaut und mit Backoff neu verbunden. Details: Nachrichtenkanal.

S/4HANA Cloud

Der Designer spricht den OData-V4-Service ZMOBBUILD_UI_DESIGNER; die Lizenz liest er über dessen Funktion getLicence und hält seine Sitzung mit einem Herzschlag alle 60 Sekunden. Statt der WebSocket-Verbindung fragt er das Backend im Sekundentakt nach Nachrichten (Polling), mit denselben Ereignissen. Klassen, Pakete, Aufträge und die Launchpad-Objekte einer App legt der Designer über die Entwicklungsschnittstelle des Tenants (ADT) an, das UI5-Repository lädt er über den UI5-Repository-Service hoch. Gebaute Apps sprechen den Runtime-Service ZMOBBUILD_UI_RUNTIME. Details: Backend-Konfiguration Cloud, Launchpad Cloud.

Build & Deploy

1. Im Designer wird eine App gebaut. Dabei wird das Runtime-Template mit dem App-Modell zusammengeführt.
2. Das Backend erzeugt daraus eine native BSP-Anwendung und hängt sie an einen Transport-Request.
3. Optional registriert das Backend die App im Fiori Launchpad (Katalog, Target Mapping, Kachel) – siehe Fiori Launchpad.

In der S/4HANA Cloud übernimmt der Designer Schritt 2 und 3 selbst: Er lädt das Repository aus dem Browser in den Tenant und legt IAM-App, Business-Katalog und Zuordnung an; der Intent der App ist dort Pflicht – siehe Launchpad Cloud.

Details zu den beteiligten Verwaltungsschritten: Templates, Transport-Requests, SAP-Pakete, in der Cloud Pakete und Aufträge.

Laufzeit-Modell

Der aktuelle App-Zustand lebt im Control-Baum; jede Komponente trägt ihr eigenes Datenmodell. Daraus wird ein Control-Tree aufgebaut, den die Runtime zur Laufzeit rendert. Beim Speichern sendet der Designer den gesamten App-Baum zusammen mit der aktuell selektierten View an das Backend.

Multi-User & Echtzeit

Bearbeitet ein Benutzer eine View, wird sie gesperrt; andere sehen sie readonly (Lock-Icon + lockedBy-Tooltip im View-Tree). Sperren und View-Updates werden über den Nachrichtenkanal verteilt (on-prem WebSocket, Cloud Polling):

Ereignis	Bedeutung
lock / unlock	Eine View wurde gesperrt bzw. freigegeben.
remove	Eine View wurde gelöscht.
save	Es wurde gespeichert – offene Designer übernehmen die geänderte View und/oder die App-Struktur (Reihenfolge und Namen der Views) live.

Auch der MCP-Server respektiert diese Sperren und löst beim Speichern den save-Broadcast aus.

Solange irgendeine View der App fremdgesperrt ist, sind Funktionen, die den gesamten App-Baum ersetzen, app-weit deaktiviert: Versionsverlauf, JSON-Upload und das Einfügen einer ganzen View. Sie würden die Arbeit der anderen Person überschreiben, ohne dass sich das live sauber verteilen ließe.