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.

FLP-Gruppen verwalten

Neben der automatischen Katalog-Registrierung kann der Designer FLP-Gruppen direkt verwalten — also die Kachel-Anordnung, die Endanwender auf ihrer Launchpad-Startseite sehen. Der Button FLP-Gruppen (Gruppen-Icon) in der Aktions-Toolbar der App-Übersicht öffnet dafür eine eigene View:

Links stehen die Gruppen, rechts die Kacheln der ausgewählten Gruppe. Möglich ist:

• Gruppe anlegen (Titel eingeben) und löschen.

• App(s) zuordnen — über „App zuordnen" eine oder mehrere Apps auswählen. Angeboten werden nur FLP-registrierte Apps (Status ✓/R), die noch nicht in der Gruppe sind; zugeordnet wird die App-Launcher-Kachel aus dem Auto-Katalog Z_MOBBUILD_<BSP_NAME>.

  

• Kachel entfernen — die markierte Kachel aus der Gruppe nehmen.

• Reihenfolge per Drag & Drop — Kacheln umsortieren; die neue Reihenfolge wird sofort gespeichert.

Nur Mobile-Builder-Gruppen

Die View listet die vom Designer angelegten Gruppen (ID-Präfix MB_). Bereits vorhandene, direkt in /UI2/FLPD gepflegte Standard-Gruppen erscheinen hier bewusst nicht.

Die Gruppen sind mandantenabhängiges Customizing (Katalog /UI2/FLPD_CATALOG) — für den Transport gilt dasselbe wie im folgenden Abschnitt. Damit eine Gruppe für Endanwender sichtbar wird, weist BASIS sie einer PFCG-Rolle zu (Rollenmenü → SAP-Fiori-Launchpad-Gruppe, GruppeID = die im Designer angezeigte MB_…-ID).

Lokale FLP-Kataloge und Gruppen transportieren

FLP-Kataloge und -Gruppen sind kein Repository-Objekt (kein R3TR/TADIR-Eintrag), sondern mandantenabhängiges Customizing in der Page-Builder-Persistenz. Sie können daher lokal existieren — nur im aktuellen Mandanten, ohne in einem Transport zu sein. Ob beim Anlegen automatisch ein Transport aufgezeichnet wird, steuert die Mandanteneinstellung in SCC4 (Abschnitt Änderungen und Transporte für mandantenabhängige Objekte).

Ein lokal angelegter Katalog/eine lokale Gruppe (z. B. direkt im Launchpad Designer angelegt) lässt sich nachträglich in einen Transport bringen:

Kataloge & Gruppen — Launchpad Content Manager

Ebene	Transaktion	Transport-Typ
Mandantenabhängig (Customizing)	/UI2/FLPCM_CUST	Customizing-Auftrag
Mandantenübergreifend (Configuration)	/UI2/FLPCM_CONF	Workbench-Auftrag

1. /UI2/FLPCM_CUST starten, Tab Kataloge bzw. Gruppen.
2. Den Katalog/die Gruppe in der oberen Tabelle markieren.
3. In der Toolbar Transport wählen und den Customizing-Auftrag angeben.

Alternativ im Launchpad Designer (/UI2/FLPD_CUST): unter Einstellungen einen Customizing-Auftrag wählen, dann eine Kachel/ein Target Mapping speichern — ab dann werden die Änderungen in diesen Auftrag aufgezeichnet.

Semantic Objects

Kundeneigene Semantic Objects werden als Customizing-Eintrag in /UI2/SEMOBJC geführt (Schlüssel = Name des Semantic Object) und über die SM30-Pflegeview /UI2/V_SEMOBJC gepflegt:

• Transaktion /UI2/SEMOBJ — im Kommandofeld mit /n davor (/n/UI2/SEMOBJ) — oder direkt SM30 → View /UI2/V_SEMOBJC.
• Über Neue Einträge das Semantic Object anlegen und sichern. Bei aktiver Aufzeichnung fragt SM30 einen Customizing-Auftrag ab — darüber kommt der Eintrag zugleich in den Transport. Alternativ nachträglich manuell in SE09/SE10 als R3TR TABU /UI2/SEMOBJC + Schlüssel.

Semantic Object registrieren ist optional

Der Build legt beim Registrieren das Target Mapping mit dem Semantic Object der App an, trägt das Semantic Object selbst aber bewusst nicht in /UI2/SEMOBJC ein — die Navigation funktioniert auch ohne (der Intent trägt den Namen direkt). Das ist Absicht: Die SM30-Pflege bündelt alle SO-Einträge in einen Transport, der sich nicht sinnvoll an den jeweiligen App-Transport koppeln lässt. Wer das Semantic Object in der Wertehilfe sehen will, pflegt es einmalig manuell per /n/UI2/SEMOBJ nach.

Nach dem Import

Im Zielsystem die Launchpad-Caches invalidieren (Report /UI2/INVALIDATE_GLOBAL_CACHES) und den Browser-Cache leeren — sonst erscheinen Kataloge/Gruppen/Kacheln unter Umständen nicht.

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.

Zusätzlich passt die Runtime im FLP den App-eigenen Seitenkopf an, damit keine doppelte Kopfzeile entsteht:

• App-Icon und View-Titel erscheinen nicht noch einmal im Seitenkopf — die FLP-Kopfzeile zeigt stattdessen den Titel der aktiven View (Fallback: App-Titel) und wird bei jedem View-Wechsel aktualisiert (ShellUIService.setTitle).
• Trägt der Seitenkopf einer View keine eigenen Header-Controls aus dem Designer, wird er komplett ausgeblendet.
• Hat die View eigene Header-Controls, bleibt der Seitenkopf sichtbar (inklusive Zurück-Button, ohne Icon/Titel).

Im Standalone-Modus bleibt der Seitenkopf unverändert.

Zurück-Navigation über die FLP-Shell

Die Zurück-Taste der FLP-Shell verhält sich wie der App-eigene Zurück-Button:

• Hat die aktive View das Event onNavButtonPress gesetzt, wird es ausgelöst (das Backend steuert die Navigation).
• Sonst navigiert die Runtime zur vorherigen View (View-Stack).
• Zeigt die View keinen Zurück-Button (Show Nav Button = false) oder gäbe es nichts zurückzunavigieren (Start-View), greift das FLP-Standardverhalten: zurück zur Launchpad-Übersicht.

Auch hier ist nichts zu konfigurieren — die Kopplung folgt automatisch den View-Eigenschaften Show Nav Button und onNavButtonPress.

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