Erscheinungsbild
Unterschiede zu On-Prem
Designer, Komponenten, Funktionen, Vorlagen, Versionsverlauf und die View-Bindung sind in beiden Welten identisch. Unterschiede gibt es bei der Umgebung: Anmeldung, Kanäle, ABAP-Sprachversion, Berechtigungsobjekte und Auslieferung.
Überblick
| Thema | On-Prem | S/4HANA Cloud |
|---|---|---|
| Framework-Objekte | Namensraum /MOBBUILD/ | Präfix ZMOBBUILD_ |
| Basisklasse der View-Klassen | /mobbuild/cl_request_base | zmobbuild_cl_request_base |
| Beispielklassen | Paket /MOBBUILD/EXAMPLE | Paket ZMOBBUILD_EXAMPLE, gleicher Umfang plus Push-Beispiele und ein Beispiel-RAP-Objekt |
| Kanal Designer ↔ Backend | HTTP-Endpunkt /mobbuild/admin | OData-Service ZMOBBUILD_UI_DESIGNER |
| Kanal App ↔ Backend | HTTP-Endpunkt /mobbuild/run | OData-Service ZMOBBUILD_UI_RUNTIME |
| Sperren, Live-Update, Push | WebSocket | Polling, siehe Backend-Konfiguration |
| Wertehilfe | Suchhilfen des Systems | Entitätsmengen veröffentlichter OData-Services; die App liest deren Service direkt |
| Backend-Konfiguration | Tabellen über SM30 | Dialoge im Lizenz-Monitor |
| Kundenpaket | Z…, Y… oder eigener Namensraum | nur Z… oder Y… |
| Transport | Aufgabe des Benutzers | Aufgabe des Benutzers; Objekte werden im zugehörigen Auftrag gebucht |
Backend-Coding
View-Klassen im Tenant sind ABAP for Cloud Development. Die Helper-API der View-Klasse ist gleich, die Umgebung nicht:
| Thema | On-Prem | S/4HANA Cloud |
|---|---|---|
| SQL | Standard-ABAP | strikte Syntax: INTO am Ende, @ vor jeder Hostvariablen |
| Schreiben auf Datenbanktabellen aus der Event-Methode | erlaubt | nicht erlaubt; die View-Klasse läuft in einem RAP-Handler. App-Daten über ein eigenes RAP-Objekt mit MODIFY ENTITIES ohne COMMIT ENTITIES ändern, der Aufruf wird beim Abschluss der Anfrage gesichert |
| Push aus ABAP | Push-Service-Klasse über WebSocket | Aktion pushRefresh per EML; die Beispielklasse ZMOBBUILD_CL_EX_PUSH_SERVICE kapselt beide Fälle, aus der Event-Methode und von außerhalb |
| Verfügbare Typen und APIs | alle | nur freigegebene; die Syntaxprüfung im Tenant zeigt Verstöße |
| Meldungsklassen, Ausnahmen, Hilfsklassen | gleich | gleich |
Launchpad, Deploy, Rollen
| Thema | On-Prem | S/4HANA Cloud |
|---|---|---|
| Deploy | Backend legt das Repository an, Katalog und Gruppe entstehen automatisch | Browser lädt das Repository hoch und legt IAM-App, Katalog und Zuordnung an, siehe Launchpad |
| Intent der App | optional | Pflicht; ohne Intent kein Deploy |
| Rollen | PFCG | Business-Rolle mit App-Katalog und ZMB_RUNTIME_BC |
| FLP-Gruppen-Verwaltung im Designer | vorhanden | entfällt, Bereiche und Seiten sind Tenant-Administration |
| Undeploy | vorhanden, nur bei offener Version | vorhanden, sobald die App einmal deployt wurde |
| Vorschau | eigene Seite | über den Launchpad-Intent des Designers |
| Übersetzungen zur Laufzeit | aus dem Backend | im Build-Artefakt der App |
MCP-Server
| Thema | On-Prem | S/4HANA Cloud |
|---|---|---|
| Anmeldung | Benutzer und Passwort | Anmeldung im Browser, Sitzung wird gespeichert |
| Werkzeuge nur in einer Welt | check_view_class, create_view_constants | trigger_push |
Einzelheiten: MCP-Server on-prem und MCP-Server in der Cloud.
Nächste Schritte
- Installation
- Mobile-Builder-API – Coding-Regeln im Tenant