Nachrichtenkanal on-prem

Designer, Vorschau und gebaute Apps tauschen on-prem Sperren, Speicher-Ereignisse, Build-Meldungen und Push-Nachrichten über WebSocket-Verbindungen (ABAP Push Channel) mit dem Backend aus. Diese Seite beschreibt, was dabei im System passiert und woran Sie Störungen erkennen.

Verbindungen

Verbindung	Endpunkt	Wer verbindet sich
Designer-Kanal	/sap/bc/apc/mobbuild/apc_designer	jeder geöffnete Designer, einmal je Browser-Tab
Push-Kanal	/sap/bc/apc/mobbuild/apc_push	jede laufende App (gebaut oder Vorschau)

Beide Endpunkte müssen in der Transaktion SICF aktiv sein (siehe Installation). Die Verbindung trägt in der URL eine Sitzungskennung (mobbuildClientId, je Tab neu erzeugt) und die Applikation (mobbuildApplicationId; für den Designer der feste Wert designer). Das Backend legt je Verbindung einen Satz in der Tabelle /MOBBUILD/WS_H an und entfernt ihn beim Schließen der Verbindung.

View-Sperren

Wer im Designer eine View öffnet, sperrt sie für andere Bearbeiter. Die Sperre gehört zur Sitzung des Tabs und liegt in der Tabelle /MOBBUILD/LOCK_H.

• Eine View je Sitzung. Beim Wechsel auf eine andere View gibt der Designer die bisherige Sperre frei; die anderen Designer der App erhalten die Freigabe sofort.
• Fremde Sperre. Ist die View bereits gesperrt, meldet der Designer „Diese View wird gerade von einem anderen Benutzer bearbeitet." Die View ist dann schreibgeschützt und zeigt im View-Baum ein rotes Schloss mit dem Benutzer als Tooltip. Hält der eigene Benutzer die Sperre in einem anderen Tab, lautet die Meldung „Diese View ist in einer anderen Sitzung von Ihnen geöffnet. Dort schließen oder hier nur lesen."
• Warteschlange. Die abgewiesene Sitzung wird als Wartende auf diese View vermerkt. Gibt der Inhaber die View frei, geht die Sperre automatisch an die am längsten wartende Sitzung über, die daraufhin bearbeiten kann.
• App-weite Wirkung. Solange irgendeine View der App fremd gesperrt ist, sind Aktionen auf den ganzen Baum (Versionsverlauf laden, JSON-Import, ganze View einfügen) für alle Bearbeiter deaktiviert.
• Verwaiste Sperren. Schließt sich die Verbindung sauber, löscht das Backend die Sperren der Sitzung. Bleibt eine Sperre nach einem Absturz liegen, gilt sie nach 8 Stunden als verwaist und wird beim nächsten Sperrversuch einer beliebigen Sitzung entfernt.

Speichern und Live-Update

Beim Speichern sendet das Backend an alle Designer, die dieselbe App geöffnet haben, die geänderte View und die geordnete View-Liste. Die anderen Designer übernehmen die View sofort ohne Neuladen; Umbenennungen und Reihenfolgeänderungen im App-Baum erscheinen ebenfalls live. Auch der MCP-Server löst dieses Ereignis beim Speichern aus.

Build-Meldung

Der Build läuft im Backend asynchron. Ist das Deployment fertig, schickt das Backend eine Meldung an den Designer, der den Build gestartet hat. Der Designer zeigt sie als Dialog an und lädt die App-Übersicht neu.

Push an gebaute Apps

Aus einer View-Klasse heraus kann das Backend gezielt laufende Apps ansprechen. Die App empfängt die Nachricht über den Push-Kanal und löst in der aktuell angezeigten View das Ereignis pushRefresh mit dem übergebenen Ereignisschlüssel und den Parametern aus; die zugehörige Event-Methode der View-Klasse verarbeitet es wie einen Klick. Angesprochen werden entweder alle offenen Instanzen einer Applikation oder eine einzelne Sitzung. Beispiele dazu sind die Klassen /MOBBUILD/CL_EX_PUSH_REFRESH_1, /MOBBUILD/CL_EX_PUSH_REFRESH_2 und /MOBBUILD/CL_EX_PUSH_SERVICE im Paket /MOBBUILD/EXAMPLE.

Verbindungsanzeige und Reconnect

In der Kopfzeile der App-Übersicht zeigt der Designer den Zustand des Designer-Kanals, solange er nicht verbunden ist:

Anzeige	Bedeutung
„Verbindung wird aufgebaut…" (gelb)	Verbindung wird gerade hergestellt
„Getrennt – neu verbinden" (rot)	Verbindung verloren; Klick auf die Anzeige verbindet sofort neu
keine Anzeige	verbunden

Bricht die Verbindung ab, verbindet der Designer selbstständig neu: erster Versuch nach 0,5 Sekunden, danach mit verdoppeltem Abstand bis höchstens 30 Sekunden. Ein Verbindungsaufbau, der nach 10 Sekunden nicht zustande kommt, wird abgebrochen und zählt als Fehlversuch.

Ohne Verbindung nur lesen

Solange der Designer-Kanal getrennt ist, schaltet der Editor in den Schreibschutz, weil er keine Sperren setzen und keine Änderungen anderer empfangen kann. Nach dem Reconnect sperrt er die geöffnete View erneut und gibt die Bearbeitung frei.

Fehlersuche im System

Symptom	Prüfen
Designer bleibt auf „Verbindung wird aufgebaut…"	SICF-Knoten apc_designer aktiv? Reverse-Proxy oder Load-Balancer muss WebSocket-Upgrades durchlassen.
View bleibt gesperrt, obwohl niemand sie bearbeitet	Sätze in /MOBBUILD/LOCK_H zur Applikation; nach 8 Stunden räumt das Backend selbst auf, vorher den Satz löschen.
Kein Live-Update bei anderen Bearbeitern	Beide Designer müssen im selben Mandanten verbunden sein; Sätze in /MOBBUILD/WS_H mit der Kennung des Designers (75EB228277AB, die Kurzform, die das Backend aus designer bildet) je offenem Tab.
Push kommt in der App nicht an	Die View muss die aktuell angezeigte sein; SICF-Knoten apc_push aktiv; Satz der App in /MOBBUILD/WS_H.
Verbindungen im Systemmonitor	Transaktion SMWS zeigt die offenen WebSocket-Verbindungen des Applikationsservers.

Nächste Schritte

• Versionsverlauf – Speichern und Stände
• MCP-Server on-prem – Sperren und Live-Sync aus dem MCP