Sprache & Region
Fiori
erste Hilfe

29. September 2025

Troubleshooting in Fiori: ein praxisnaher Leitfaden als erste Hilfe

Troubleshooting in Fiori: Was tun, wenn Fiori-Apps nicht im Launchpad erscheinen, Daten fehlen oder es unerklärliche Fehler auftreten? Ein praxisnaher Leitfaden als erste Hilfe.

Obwohl SAP Fiori den Anspruch hat, moderne und benutzerfreundliche Oberflächen bereitzustellen, stoßen Projektteams und Anwender in der Praxis immer wieder auf Herausforderungen: Apps erscheinen nicht im Launchpad, Daten fehlen oder es treten unerklärliche Fehler auf, wodurch die App nicht mehr reagiert. In solchen Fällen ist gezieltes Trouble Shooting gefragt. Dieser Beitrag gibt Ihnen eine strukturierte Anleitung zur Fehleranalyse in Fiori-Apps – kompakt, praxisnah und erprobt.

1. Die App ist nicht im Fiori Launchpad sichtbar

Ein Klassiker unter den Fehlerbildern: Eine App soll verfügbar sein, ist im Launchpad aber nicht auffindbar. Die Ursachen hierfür sind meist technischer oder berechtigungsbezogener Natur.

Prüfschritte:

  • Verfügbarkeit der App im System prüfen: Ist die App überhaupt in Ihrem System aktiv und verfügbar? Nutzen Sie für die Details zur App die zentrale Fiori App Library. Insbesondere unter dem Reiter „Implementation Information“ finden sich hilfreiche Daten zur Konfiguration der App.
  • OData-Services aktivieren: Über die Transaktion /n/iwfnd/maint_service lässt sich feststellen, ob die relevanten OData-Services aktiv sind. Falls nicht, aktivieren Sie diese nach.
  • Berechtigungen kontrollieren:  Berechtigungen prüfen Sie mit SU53, PFCG oder SU01. Die App muss dem User über die passende Rolle (mit Katalog und Gruppe) zugewiesen worden sein.
  • Katalogeinstellungen kontrollieren: Über die Transaktionen /n/ui2/flpcm_cust (mandantenspezifisch) und /n/ui2/flpcm_conf (mandantenübergreifend) prüfen Sie, ob die App in einem Katalog enthalten ist.
  • Launchpad Bereiche und Seiten kontrollieren: Ist die App im App Finder im Fiori Launchpad auffindbar, wird aber nicht standardmäßig im Launchpad angezeigt, kann der User sich diese App selbst hinzufügen. Alternativ kann über die App "Launchpad-Bereiche verwalten" die Anzeige für alle User einer Rolle gesetzt werden.

2. Die App sieht anders aus als erwartet

In manchen Fällen sind Apps zwar sichtbar, zeigen aber nicht die erwarteten Felder oder Namen. Häufig liegt das an sogenannten Key User Extensions.

Prüfschritte:

Prüfen Sie, 

  • ob Erweiterungen oder UI-Anpassungen vorgenommen wurden. Achtung: Um die UI-Erweiterungen sehen zu können, wird die Berechtigungsrolle SAP_UI_FLEX_KEY_USER benötigt. 

3. Daten fehlen oder wirken inkonsistent: Debugging auf Feldebene

Wenn spezifische Daten fehlen oder nicht wie erwartet erscheinen, lohnt sich ein Blick in die Datenquelle. Fiori verwendet verschiedene App-Technologien, was einen Einfluss auf den Ursprung der Daten hat. Typischerweise ist eine CDS-View die Datenquelle. Ob das der Fall ist, ist am einfachsten der Fiori Library zu entnehmen: Unter OData Service(s) sind die OData Services der jeweiligen App aufgelistet. Die Erweiterung „_CDS“ ist ein Hinweis darauf, dass die Datenquelle auf einem CDS-View basiert. Die Erweiterung „_SRV“ steht dagegen für ABAP-Quellen. 

Prüfschritte

  1. CDS View ermitteln:
    • Per Rechtsklick auf das Feld → „Untersuchen“ → HTML-Element analysieren.
    • Typischerweise finden Sie dort einen View-Namen, der mit „C_“beginnt - wie beispielsweise C_PurchaseReqnHeader.
  2. CDS-Daten prüfen:
    • Öffnen Sie die View in der Transaktion SE16N (mit und ohne _CDS).
    • Auch über ST05 (SQL-Trace) lassen sich verwendete Views zurückverfolgen – achten Sie auf Objektnamen mit C_ oder I_.
  3. Analytical Queries:
    • Bei analytischen Apps verwenden Sie „Technische Hilfe“ → bsa_query zeigt den View-Namen.
  4. Detaillierte Analyse der Datenherkunft:
    • In SE80 bzw. in Eclipse können Sie dann die Datenquelle und Logik iterativ analysieren.

4. OData-Services gezielt testen

Nicht jede App basiert auf einer CDS View. In diesen Fällen oder beim Testen von Annotationen ist ein gezielter OData-Test hilfreich.

  • Verwenden Sie in /iwfnd/maint_service die Funktion zum Testen im SAP Gateway Client (SEGW).
  • Alternativ können Sie über „Browser aufrufen“ den generierten Link im Browser öffnen und so den OData-Service direkt testen.

5. Fehlerprotokolle gezielt nutzen

Fehlerquellen effizient aufspüren:

  • Backend-Fehler: Da im Fiori-Umfeld viele Fehler nicht in der ST22 landen, nutzen Sie /n/iwfnd/error_log und /n/iwbep/error_log, um Probleme beim Service-Call zu identifizieren.
  • Frontend-Fehler: Öffnen Sie im Browser mit F12 die Entwicklerkonsole und beobachten Sie Fehler in der Konsole. Faustregel: Fehler mit lediglich 1–2 Zeilen sind meist nicht relevant.
  • Script-Ausnahmen: Nicht jeder Fehler ist kritisch – viele stammen aus dem allgemeinen Shell-Bereich (ui2/ushell/resources) und Code davon kann ignoriert werden.
Banner: Sie möchten mehr erfahren? Hier geht's zum passenden Webinar!

Fazit: Mit System zur Fehlerursache

Troubleshooting in Fiori erfordert technisches Know-how, systematisches Vorgehen und ein gutes Verständnis der zugrunde liegenden Architektur. Ob fehlende Apps, unvollständige Daten oder kryptische Fehler – mit den hier beschriebenen Tools und Tipps kommen Sie den Ursachen auf die Spur. Und wenn doch mal nichts hilft: Ein erfahrener Frontend-Entwickler aus Ihrem Team kann oft entscheidend weiterhelfen.

SAP Fiori macht moderne Oberflächen erlebbar – doch wenn Apps verschwinden, Daten fehlen oder Fehler blockieren, zählt systematisches Troubleshooting. Unser Leitfaden zeigt praxisnah, wie Sie Schritt für Schritt zur Ursache gelangen.

Fabian Höll, Consultant CONSILIO GmbH Kontakt aufnehmen

Keine Neuigkeiten mehr verpassen

Melden Sie sich jetzt zu unserem Newsletter an, um direkt benachrichtigt zu werden, wenn es neue Blogbeiträge und News zu Ihrem Thema gibt!

Informiert bleiben
Newsletter Icon