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.

Gesamtbild

Bausteine

Baustein	Rolle
Designer (hpc.mobile.builder.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.
ABAP-Backend (/MOBBUILD/*)	App-Persistenz, Build/Deploy, Transport- & Package-Handling, Lock-Registry, FLP-Registrierung.
MCP-Server	Optionaler KI-Zugang zum Designer-Backend – steuert App-/View-/Control-Mutationen per Werkzeug. Siehe Automatisierung & MCP.

Kommunikation mit dem Backend

Alle fachlichen Backend-Calls 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.

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.

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.

Details zu den beteiligten Verwaltungsschritten: Templates, Transport-Requests, SAP-Pakete.

Laufzeit-Modell

Der aktuelle App-Zustand liegt im benannten JSON-Model Application. Daraus wird ein Control-Tree aufgebaut, den die Runtime zur Laufzeit rendert. Änderungen am Tree werden per Diff erkannt, sodass nur tatsächliche Änderungen gespeichert werden.

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 die WebSocket-Verbindung verteilt:

Ereignis	Bedeutung
lock / unlock	Eine View wurde gesperrt bzw. freigegeben.
remove	Eine View wurde gelöscht.
save	Eine View wurde gespeichert – offene Designer aktualisieren sie live.

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