Fiori Launchpad

Eine mit dem Mobile Builder gebaute App lässt sich als Kachel im SAP Fiori Launchpad (FLP) bereitstellen und kann aus anderen Fiori-Apps per Intent gestartet werden. Der Designer pflegt die nötigen Manifest-Felder automatisch und registriert die App beim Build automatisch im FLP (Katalog + Target Mapping + Kachel). Als BASIS-Aktion verbleibt nur das Zuweisen des Katalogs zu einer PFCG-Rolle.

Was der Designer automatisch generiert

Beim Build trägt der Designer in das manifest.json der App ein:

Manifest-Feld	Quelle (App-Property)	Default
sap.app.id	applicationId (sanitisiert)	—
sap.app.crossNavigation.inbounds.<SO>-<action>	semanticObject + action	Semantic Object = applicationId, Action = display
sap.fiori.archeType	archeType	transactional
sap.fiori.registrationIds	registrationIds (kommagetrennt)	leer

Die Properties pflegen Sie im Eigenschaften-Panel der Application (oberster Knoten im View-Tree der App):

Property	Bedeutung
FLP Inbound	Dropdown true/false. true = Manifest enthält Intent-Inbound und die App wird automatisch registriert, false = nur direkter URL-Launch, keine Registrierung
Semantic Object	SAP-Konvention: beginnt mit einem Buchstaben, danach nur Buchstaben/Ziffern, max. 30 Zeichen (keine Unterstriche/Sonderzeichen). Das Eingabefeld prüft das direkt. Leer → es wird keine automatische FLP-Registrierung durchgeführt.
Action	Dropdown mit den gängigen Fiori-Actions (display, create, change, manage, approve, track, analyze, monitor). Default display.
Archetype	transactional, analytical, factsheet, search, reusecomponent

Sperre nach Registrierung

Sobald eine App im FLP registriert ist, werden die FLP-Properties (FLP Inbound, Semantic Object, Action, Archetype) im Eigenschaften-Panel schreibgeschützt angezeigt — das verhindert, dass Semantic Object/Action nachträglich von dem abweichen, was im FLP als Target Mapping registriert wurde.

Automatische FLP-Registrierung beim Build

Sobald eine App mit gesetztem Semantic Object und aktivem FLP Inbound gebaut wird, registriert das Backend sie automatisch im FLP:

• Es legt einen eigenen Katalog pro App an: Z_MOBBUILD_<BSP_NAME> (z.B. Z_MOBBUILD_ZUI5MB_MS).
• Darin entstehen Target Mapping (Intent → SAPUI5-Komponente + BSP-URL) und eine statische App-Launcher-Kachel (Titel = App-Titel, Untertitel = Beschreibung).
• Alle Customizing-Einträge hängen am selben Transport wie der BSP-Deploy.

Der FLP-Status pro App ist in der App-Liste des Designers sichtbar (Spalte FLP):

Icon	Status	Bedeutung
✓ (grün)	R	erfolgreich registriert
⚠ (gelb)	W	Customizing-Berechtigung fehlt — Build war erfolgreich, Registrierung nicht. BASIS einbinden.
✕ (rot)	F	Registrierung fehlgeschlagen (Detail siehe Build-Log)
(kein Icon)	''	nicht registriert (kein Semantic Object / FLP Inbound = false / nie gebaut)

Bei Status W oder F erscheint in der App-Zeile ein Wiederholen-Button, der die Registrierung erneut anstößt (RPC application_register_flp) — z.B. nachdem BASIS die fehlende Berechtigung erteilt hat. Bei Status R (registriert) erscheint stattdessen ein Entfernen-Button, der die FLP-Registrierung wieder aufhebt (RPC application_unregister_flp, löscht Katalog/Kachel/Target Mapping nach Rückfrage). Der Unregister benötigt einen offenen Transport der App; ist keiner offen, bleibt der Status unverändert.

Voraussetzung: Customizing-Berechtigung

Der Build-Benutzer braucht die Berechtigung, FLP-Customizing zu schreiben (S_DEVELOP / FLPD-Customizing). Fehlt sie, bleibt der Build erfolgreich, der FLP-Status ist aber W und es wird keine Kachel angelegt.

Verbleibende BASIS-Aufgabe: Katalog einer Rolle zuweisen

Die automatische Registrierung legt Katalog, Target Mapping und Kachel an — sie weist den Katalog aber nicht automatisch einer Rolle zu (bewusst, das ist eine Berechtigungsentscheidung). Damit die Kachel für Endbenutzer im Launchpad sichtbar wird, muss BASIS einmalig pro App (oder einmalig über eine Sammelrolle):

• den Katalog Z_MOBBUILD_<BSP_NAME> in die PFCG-Rolle der Endbenutzer aufnehmen,
• ggf. die Kachel einer Group/Page zuweisen (Transaktion /UI2/FLPD_CONF bzw. Spaces/Pages).

Bis das geschehen ist, ist die App registriert und per Intent erreichbar, aber nicht als Kachel sichtbar.

Manuelle Registrierung als Fallback

Ist die Auto-Registrierung deaktiviert (FLP Inbound = false) oder gewünscht, kann der Katalog/Target Mapping/die Kachel weiterhin manuell über /UI2/FLPD_CUST angelegt werden. Werte: Semantic Object/Action wie in den Designer-Properties, Application Type SAPUI5 Fiori App, URL /sap/bc/ui5_ui5/sap/<bsp_name>, ID = sap.app.id aus dem deployten Manifest.

Cross-App-Navigation aus einer gebauten App heraus

Mit dem LogicFlow-Baustein NavToApp ruft Ihre gebaute App eine andere Fiori-App per Intent auf. Siehe auch Logic Flow.

Property	Bedeutung
Semantic Object	Ziel-App (Wert aus deren Manifest)
Action	meistens display
Parameters	JSON-Objekt-String, z.B. {"customerId":"4711"} — wird zu URL-Parametern
Fallback URL	URL, die geöffnet wird wenn die App nicht im FLP läuft
Open Mode	_blank (neuer Tab) / _self (gleiches Fenster) — nur für den Fallback-Pfad

Standalone- vs. FLP-Modus

NavToApp prüft zur Laufzeit, ob ein FLP-Shell verfügbar ist:

• Im FLP: sap.ushell.Container.getServiceAsync('CrossApplicationNavigation').toExternal(...) → kontextbewusste Navigation, Browser-Tab bleibt erhalten
• Standalone (direkter App-URL-Aufruf): window.open(Fallback URL, Open Mode) als Notnagel

Lassen Sie die Fallback URL leer, wenn die App ausschließlich aus dem FLP heraus genutzt wird.

Doppelte Shell-Header vermeiden

Wenn die App im FLP läuft, wird das umschließende sap.m.Shell automatisch unterdrückt — das FLP-Shell-Header übernimmt die Chrome. Im Standalone-Modus wrappt die Runtime ihre View selbst in ein sap.m.Shell. Sie müssen nichts konfigurieren; die Erkennung läuft automatisch über window.sap.ushell.Container.

Nächste Schritte

• Logic Flow — Wie NavToApp und andere Bausteine zusammenspielen
• Transport-Requests — Wie der Build die BSP-Anwendung in den Transport hängt
• SAP-Pakete — Paket-Auswahl beim App-Anlegen