Launchpad in der S/4HANA Cloud

In der S/4HANA Cloud ist eine gebaute App ausschließlich über das Launchpad erreichbar. Deshalb ist der Intent der App Pflicht, und der Designer legt beim Deploy alle Berechtigungsobjekte an, die das Launchpad für eine Kachel braucht. Er tut das aus dem Browser heraus mit der Berechtigung des angemeldeten Entwicklers; die Rollenzuordnung bleibt Aufgabe der Administration.

FLP-Metadaten im Build

Die App-Eigenschaften FLP Inbound, Semantic Object und Action erzeugen beim Build den Intent im manifest.json, wie on-prem. Anders als dort gilt:

Inbound ist Pflicht

Steht FLP Inbound auf false oder fehlt Semantic Object beziehungsweise Action, verweigert der Designer das Deployment mit der Meldung „Deployment verweigert: Semantic Object und Action sind Pflicht. In SAP S/4HANA Cloud ist die App nur über das Fiori Launchpad erreichbar."

Der Repository-Name der App ist zugleich ihr Component-Namensraum: Namespace der App (sonst ihr Name) in Großbuchstaben, Sonderzeichen durch _ ersetzt, Präfix Z, falls nicht vorhanden, höchstens 15 Zeichen.

Ablauf beim Deploy

1. Build: Der Designer erzeugt das App-Archiv im Browser und lädt es in das UI5-Repository des Tenants hoch. Das Backend friert die App währenddessen ein und protokolliert Ergebnis und Meldungen in der Build Info.
2. Registrierung: Nach erfolgreichem Upload legt der Designer nacheinander die IAM-App, den Business-Katalog und die Katalogzuordnung an und veröffentlicht sie. Das Veröffentlichen dauert im Tenant je Objekt rund zwei Minuten; der Designer wartet darauf.
3. Status: Das Ergebnis wird an der App vermerkt und in der App-Übersicht angezeigt.

Objekt	Name	Bedeutung
UI5-Repository	<REPO>	die gebaute App
IAM-App	<REPO>_EXT	Berechtigungsobjekt der App (Typ „External")
Business-Katalog	<REPO>_BC	Katalog, der der Rolle zugeordnet wird
Katalogzuordnung	<REPO>_BC_0001	verbindet IAM-App und Katalog

Alle Objekte landen im Auftrag zur Aufgabe der App, siehe Pakete und Aufträge.

Registrierungsstatus

Die Symbole in der App-Übersicht entsprechen denen on-prem:

Icon	Status	Bedeutung
✓ (grün)	R	registriert, Katalog vorhanden
✕ (rot)	F	Registrierung fehlgeschlagen; den Fehlertext zeigt der Dialog beim Deploy, er wird an der App gespeichert
(kein Icon)	D	Registrierung entfernt
Warnsymbol	W	Registrierung unvollständig – Berechtigung fehlt
⊘ (grau)	U	undeployt

Bei Status W oder F erscheint neben dem Statussymbol ein Button mit dem Tooltip FLP-Registrierung wiederholen, der die Registrierung erneut anstößt. FLP-Registrierung entfernen löscht Katalogzuordnung, IAM-App und Katalog, das Repository bleibt. Beide Aktionen gibt es nur, solange kein Build läuft.

Rollen und Kataloge

Damit Endanwender die Kachel sehen, ordnet die Administration in Anwendungsrollen pflegen einer Rolle zwei Kataloge zu: den Katalog der App (<REPO>_BC) und den Runtime-Katalog ZMB_RUNTIME_BC, über den die App mit dem Backend spricht.

Die Kachel selbst platzieren Sie über Launchpad-Bereiche verwalten und Launchpad-Seiten verwalten auf einer Seite des Bereichs, der der Rolle zugeordnet ist. Nach erneuter Anmeldung sehen die Benutzer die Kachel.

Keine Gruppen-Verwaltung

Die FLP-Gruppen-Verwaltung des On-Prem-Designers gibt es in der Cloud nicht. Bereiche und Seiten sind Tenant-Administration.

Undeploy

Sobald die App einmal deployt wurde und kein Build läuft, bietet die App-Übersicht App undeployen an, auch bei einer geschlossenen Version. Er entfernt Katalogzuordnung, IAM-App, Katalog und das UI5-Repository aus dem Tenant und vermerkt Status U. Die App-Definition im Designer bleibt erhalten; ein erneuter Build stellt die App wieder her. Das Löschen einer App im Designer ist dagegen nur ein Verschieben in den Papierkorb und rührt das Launchpad nicht an.

Vorschau über den Designer-Intent

Direkte Aufrufe von UI5-Repositories sperrt der Tenant. Die Vorschau aus dem Designer öffnet deshalb einen neuen Tab mit dem Intent des Designers und der App-Kennung als Parameter; der Designer lädt darin die Laufzeit-Ansicht der App. Für die Vorschau braucht der Entwickler keine Rolle mit dem Katalog der App, wohl aber den Runtime-Katalog ZMB_RUNTIME_BC.

Cross-App-Navigation aus einer gebauten App heraus

Der Funktionsbaustein NavToApp arbeitet wie on-prem, siehe Funktionsbausteine. Ziel-Intent ist Semantic Object plus Action der Ziel-App; beide Apps müssen im Katalog der Benutzerrolle liegen.

Nächste Schritte

• Installation – Rollen für Designer, Monitor und Runtime
• Pakete und Aufträge – Auftrag zum Deploy
• Unterschiede zu On-Prem