SAP S/4HANA-Implementierungen verlassen sich stark auf das Fiori-Launchpad als zentrale Benutzeroberfläche und ersetzen traditionelle SAP GUI-Transaktionen durch SAPUI5-Anwendungen. Diese Anwendungen konsumieren Daten über OData-Dienste, die oft ältere RFC (Remote Function Call)-Funktionsmodule umhüllen. Die Bereitstellungsarchitektur umfasst mehrere Schichten: die Frontend-BSP (Business Server Pages)-Anwendung, die SAP Gateway-Schicht (die OData exponiert), den Backend-ABAP-Stack und die PFCG (Profil-Generator)-Autorisierungsprofile.
Bei der Landschaftsförderung (Entwicklung → Qualitätssicherung → Produktion) treten häufig Inkonsistenzen nicht aufgrund von Codefehlern auf, sondern aufgrund von Konfigurationsdrift. OData-Dienste cachen Metadaten aggressiv im IWBEP-Komponenten, während PFCG-Rollen eine manuelle Regenerierung (Profil → Generieren) erfordern, um neue Authorization Objects wie S_START oder benutzerdefinierte Z*-Objekte zu propagieren. Diese Frage testet die Fähigkeit eines Testers, sich in der n-tier Architektur zurechtzukommen und systematisch zu isolieren, ob eine fehlende Kachel auf den Cache des Frontends, Metadaten des Gateways, Transportsequenzierung oder Latenz des Autorisierungs-Puffers zurückzuführen ist.
Die zentrale Herausforderung ist die Symptom-Ambiguität: Ein Benutzer meldet sich beim Fiori-Launchpad an und sieht entweder eine ausgegraute Kachel, oder die Kachel fehlt vollständig, oder beim Klicken wird angezeigt "Die App konnte nicht geöffnet werden. Bitte versuchen Sie es später erneut." Diese Symptome können aus resultieren:
OData-Metadaten-Veraltetheit: Die SAPUI5-App ruft $metadata ab, um die Struktur der Entitäten zu verstehen. Wenn der Gateway-Cache (/IWFND/CACHE) eine alte Version nach dem Transport hält, kann die App möglicherweise nicht an RFC-Felder binden, die sich im Backend geändert haben.
PFCG Rollenübertragungsverzögerung: Selbst wenn die Transportanfrage die Rolle erfolgreich in QAS verschoben hat, spiegeln die User Master (USR04)-Tabellen möglicherweise die neuen Profil-Versionen nicht wider, bis ein Vergleich durchgeführt wird (PFUD) oder der Benutzer sich erneut anmeldet. Die Rolle könnte den Katalog auflisten, aber die spezifische S_IWSG (Internet Communication Framework)-Autorisierung für den OData-Dienst fehlen.
Target Mapping-Waisenkinder: Der LPD_CUST (Launchpad-Anpassung)-Eintrag oder die KATALOG-Zuordnung könnten ein semantisches Objekt (z.B. ZPurchaseOrder) und eine Aktion (create) referenzieren, aber wenn der Transport die Gruppen-Zuordnung verpasst hat oder die SAPUI5-Komponenten-ID in der manifest.json nicht mit dem Namen der BSP-Anwendung übereinstimmt, wird die Kachel gerendert, navigiert aber nirgendwohin.
Ohne einen systematischen Ansatz verschwenden Tester Stunden mit der Überprüfung von SE80-Code, wenn das Problem eine fehlende Systemalias in SM59 oder einen nicht geleerten SU56-Autorisierungspuffer ist.
Ein geschichteter Eliminationsprotokoll ist erforderlich, der von statischer Konfiguration zur dynamischen Laufzeit führt:
Schritt 1: Transport-Konsistenz-Audit
Vor allen funktionalen Tests verifizieren Sie den Inhalt der Transport of Copies (TOC) oder Workbench Request mit SE01 und SE09. Bestätigen Sie die Co-Abhängigkeit: die BSP-Anwendung, den ICF-Knoten (Transaktion SICF), den OData-Dienst (/IWFND/MAINT_SERVICE), die Fiori-Katalog/Gruppen-Zuordnungen (/UI2/FLPD_CUST) und die PFCG-Rolle müssen entweder im selben Transport enthalten sein oder dokumentierte Sequenzierung haben. Verwenden Sie SCMP (View/Table Comparison), um die Tabellen LPD_T (Launchpad-Daten) zwischen Systemen zu unterscheiden.
Schritt 2: Metadaten-Cache-Invalidierung
Führen Sie /IWFND/CACHE_CLEANUP im Gateway-System aus, um Model- und Metadata-Caches zu löschen. Im Browser erzwingen Sie ein vollständiges Neuladen (Strg+F5) und fügen ?sap-ui-xx-noCache=true zur SAPUI5-Bootstrap-URL hinzu. Überprüfen Sie die Netzwerk-Registerkarte auf die $metadata-Anforderung; vergewissern Sie sich, dass die XML-Antwort die korrekten EntitySets enthält, die mit der aktuellen RFC-Signatur übereinstimmen.
Schritt 3: Autorisierungspuffer leeren
Verwenden Sie die Transaktion SU56, um den aktuellen Autorisierungspuffer des Benutzers zu löschen. Führen Sie PFUD (Anpassung von Benutzerdaten) mit der "Vergleichen"-Option aus, um sicherzustellen, dass das PFCG-Rollenprofil aktuell ist. Führen Sie SU53 sofort nach einem fehlgeschlagenen Kachelzugriff aus, um die letzte fehlgeschlagene Autorisierungsprüfung anzuzeigen. Achten Sie insbesondere auf S_START (generische Startautorisierung), S_IWSG und S_SERVICE-Objekte.
Schritt 4: Überprüfung der Zielzuordnungsauflösung
Verwenden Sie die Transaktion /UI2/FLIA (Fiori Launchpad Intent Analysis), um das semantische Objekt und die Aktion einzugeben. Dies zeigt, welche SAPUI5-Anwendung (über Component ID) aufgelöst wird, den ICF-Pfad und ob der LPD_CST-Eintrag gültig ist. Wenn FLIA die Zuordnung zeigt, der Benutzer sie jedoch nicht sehen kann, liegt das Problem bei PFCG (fehlende Katalogzuordnung). Wenn FLIA keine Zuordnung zeigt, liegt das Problem bei LPD_CUST oder dem Transport.
Schritt 5: RFC-Konnektivitätstracing
Aktivieren Sie die Gateway-Fehlerprotokolle über /IWFND/ERROR_LOG. Verfolgen Sie das RFC-Ziel über SM59 → Verbindungstest, dann SM50 (Prozessübersicht), um nach RFC-Fehlern zu suchen, wenn der OData-Dienst versucht, das Backend zu erreichen. Überprüfen Sie auf S_RFC oder S_RFCACL-Autorisierungsfehler in SM21 (Systemprotokoll).
Problem Beschreibung
Im Rahmen eines S/4HANA 2022-Upgradeprojekts funktioniert die SAP Fiori-Anwendung "Manage Purchase Requisitions" einwandfrei in der Entwicklung, konnte jedoch in der Qualitätssicherung nicht gestartet werden mit dem Fehler: "Die Anwendung konnte nicht geöffnet werden, da die SAPUI5-Komponente ui.sscim.prereq nicht geladen werden konnte." Das Basis-Team bestätigte, dass alle Transporte erfolgreich mit RC=0 (Return Code null) importiert wurden. Das SAPUI5-ABAP-Repository (SE80) zeigte die ui.sscim.prereq-BSP-Anwendung in QAS an. Der OData-Dienst C_PURCHASEREQ_SRV war in /IWFND/MAINT_SERVICE aktiv. Allerdings erschien die Kachel für Administratoren, nicht jedoch für Einkaufsleiter, was auf ein Autorisierungsproblem hindeutet, dennoch erhielten auch die Administratoren den Ladefehler beim Klicken auf die Kachel.
Lösung 1: Browser-Cache-Leerung und Rollback der UI5-Version
Die erste Hypothese war, dass QAS einen beschädigten SAPUI5-Cache oder eine Versionsinkonsistenz im ABAP-Repository hatte. Das Team löschte die Browser-Caches für alle Benutzer und invalidierte manuell den MIME-Repository-Cache mit /UI5/APP_INDEX_CALCULATE.
Vorteile: Dies ist eine schnelle, nicht-invasive Lösung, die häufig Probleme mit dem Laden von SAPUI5-Ressourcen (404s in Component-preload.js) behebt. Es sind keine Änderungen am ABAP-Code erforderlich.
Nachteile: Es löste das Problem nicht. Der Fehler blieb bestehen, und noch kritischer, er erklärte nicht, warum die Kachel für die Mitarbeiter unsichtbar war. Es behandelte das Symptom (Ladefehler), ohne zu diagnostizieren, warum die Metadaten nicht geladen werden konnten, möglicherweise masking ein tieferes OData-Dienstkonfigurationsproblem.
Lösung 2: Vollständige PFCG-Rollenregenerierung und Benutzervergleich
Das Team vermutete, dass die Fiori-Katalog-Zuordnung in PFCG fehlte. Sie regenerierten alle Profile für die Beschaffungsrollen und führten PFUD mit der Option „Vollständiger Abgleich“ aus, um sicherzustellen, dass alle Benutzer die aktualisierten Berechtigungen erhielten.
Vorteile: Stellt sicher, dass die Autorisierungsprofile (PROF_NAME in UST04) mit den Rollen-Definitionen synchronisiert sind. Dies behob das Problem mit der "unsichtbaren Kachel" für die Mitarbeiter, da die Katalog-Gruppen-Zuordnung in der QAS-Rollen-Version tatsächlich fehlte.
Nachteile: Obwohl die Kachel sichtbar wurde, führte ein Klick darauf immer noch zu der Fehlermeldung "Die Komponente konnte nicht geladen werden". Dieser Ansatz scheiterte, da er sich ausschließlich auf die Autorisierungsschicht (PFCG) konzentrierte und die OData-Dienst-zu-RFC-Mapping-Schicht ignorierte. Die Administratoren, die die Kachel sehen konnten, konnten sie dennoch nicht öffnen, was bewies, dass das Problem über die Autorisierung hinausging.
Lösung 3: Systematische Validierung von Gateway und ICF-Knoten (Gewählte Vorgehensweise)
Die gewählte Methodik beinhaltete die Überprüfung des Aktivierungsstatus des OData-Dienstes unabhängig von der UI5-App. Mithilfe der Transaktion /IWFND/GW_CLIENT führte das Team eine GET-Anfrage an C_PURCHASEREQ_SRV?sap-client=100 aus. Die Anfrage lieferte HTTP 200, aber die XML-Nutzlast zeigte, dass die Metadaten aus einer zwischengespeicherten Version stammten, die vor einer kürzlichen RFC-Schnittstellenänderung lag. In der Folge zeigte die Überprüfung der Transaktion SICF (Dienste verwalten), dass der ICF-Knoten /sap/bc/ui5_ui5/sap/ui_sscim_prereq in DEV aktiv, jedoch in QAS (der Import war aufgrund eines gesperrten Objekts stillschweigend fehlgeschlagen). Schließlich zeigte die Überprüfung von /IWFND/ERROR_LOG, dass der App-Versuch, $metadata abzurufen, auf einen Autorisierungsfehler bei der Systemalias-Zuordnung stieß, die auf ein veraltetes SM59-Ziel hinwies, das nach der Migration außer Betrieb genommen worden war.
Warum gewählt: Dieser Ansatz isolierte die drei gleichzeitigen Fehler: (1) OData-Cache-Desynchronisierung zwischen DEV und QAS, die eine Metadateninkonsistenz verursachte, (2) Inaktivität des ICF-Knotens, die verhinderte, dass die SAPUI5-Ressourcen über HTTP bereitgestellt wurden, und (3) Fehlkonfiguration der Systemalias in QAS, die auf ein nicht vorhandenes RFC-Ziel zeigte. Es lieferte spezifische Fehlercodes (ICF 403s im Vergleich zu OData 404s) anstelle generischer benutzergerichteter Nachrichten.
Das Ergebnis
Die Ausführung von /IWFND/CACHE_CLEANUP aktualisierte die OData-Metadaten, um der neuen RFC-Signatur zu entsprechen. Die Aktivierung des ICF-Knotens über SICF beseitigte den "Die Komponente konnte nicht geladen werden"-Fehler, indem die HTML- und JS-Dateien der BSP-Anwendung zugänglich gemacht wurden. Die Korrektur der Systemalias in /IWFND/MAINT_SERVICE → SAP-Systemalias stellte sicher, dass der Gateway auf das Backend zugreifen konnte. Die Beschaffungsmitarbeiter konnten dann die Anwendung sehen und öffnen, da die PFCG-Rolle (in Lösung 2 behoben) den Zugriff auf die nun funktionale Kachel gewährte. Der systematische Ansatz sparte ungefähr 8 Stunden ABAP-Debugging, die auf der Annahme verschwendet worden wären, dass der Code fehlerhaft war.
Wie bestimmen Sie eindeutig, ob eine fehlende Fiori-Kachel durch eine fehlende Target Mapping (LPD_CUST) oder eine fehlende Katalogzuweisung in PFCG verursacht wird, da beides dazu führt, dass die Kachel nicht angezeigt wird?
Antwort:
Eine fehlende Target Mapping (konfiguriert in LPD_CUST oder dem Fiori KATALOG-Designer) bedeutet, dass die Kombination aus semantischem Objekt und Aktion keine zugehörige SAPUI5-Anwendung hat, die Kachel selbst jedoch immer noch erscheinen könnte, wenn die Katalogzuordnung in PFCG existiert. Ein Klick darauf würde zu einem Fehler "Navigationsziel konnte nicht gefunden werden" führen. Um dies zu überprüfen, verwenden Sie die Transaktion /UI2/FLIA (Fiori Launchpad Intent Analysis). Geben Sie das semantische Objekt und die Aktion ein; wenn FLIA "Keine Anwendung für diese Absicht gefunden" zurückgibt, fehlt die Target Mapping oder der Name der BSP-Anwendung in der Zuordnung ist falsch.
Umgekehrt, wenn FLIA erfolgreich die Ziel-SAPUI5-Anwendung und Component ID anzeigt, die Kachel jedoch vom Launchpad des Benutzers fehlt, ist das Problem PFCG-bezogen. Überprüfen Sie, ob der Katalog, der die Kachel enthält, dem Benutzer-Rolle in PFCG zugeordnet ist (überprüfen Sie die Registerkarte Menü) und stellen Sie sicher, dass die Gruppe (die die Kacheln auf der Startseite des Launchpads organisiert) ebenfalls zugeordnet ist. Überprüfen Sie außerdem, ob das Autorisierungsobjekt S_START mit dem Wert WEBGUI im SU53-Trace des Benutzers vorhanden ist, da dies erforderlich ist, um eine Fiori-App zu starten und oft bei Rollen-Upgrades von SAP GUI-Systemen übersehen wird.
Warum könnte ein OData-Dienst erfolgreich über den Gateway-Client (/IWFND/GW_CLIENT) getestet werden, jedoch mit einem 403 Forbidden-Fehler erscheinen, wenn er von der SAPUI5-Anwendung im Browser aufgerufen wird?
Antwort:
Der Gateway-Client (/IWFND/GW_CLIENT) wird innerhalb des SAP GUI-Sitzungskontexts ausgeführt, verwendet die SAP Logon-Authentifizierung und umgeht die Sicherheitsprüfungen des HTTP Internet Communication Framework (ICF)-Knotens. Die SAPUI5-Anwendung hingegen leitet Anforderungen über die ICF-Knotenstruktur (/sap/bc/ui5_ui5/... oder /sap/opu/odata/...).
Daher weist ein 403 im Browser typischerweise auf Folgendes hin:
ICF-Knoteninaktivität: Der spezifische Servicenode in SICF ist im Zielclient inaktiv, obwohl der OData-Dienst selbst in /IWFND/MAINT_SERVICE registriert ist.
S_ICF-Autorisierung: Der Benutzer hat nicht das S_ICF-Autorisierungsobjekt mit den richtigen ICF-Feldwerten (Service-Name, Host usw.), um auf diesen spezifischen HTTP-Pfad zuzugreifen. Überprüfen Sie die Transaktion SU53 sofort nach dem Fehler.
CSRF-Token-Validierung: SAPUI5-Anwendungen benötigen ein gültiges CSRF (Cross-Site Request Forgery)-Token, das über eine HEAD-Anfrage abgerufen wird. Wenn die Frontend- und Backend-Systeme falsch konfiguriert sind (z. B. verschiedene System-IDs in einem Fiori Front-End Server-Szenario), schlägt die Token-Validierung mit einem 403 fehl, während der GW_CLIENT (zustandslos und CSRF-agnostisch) erfolgreich ist.
Wie testen Sie auf Rennbedingungen bei PFCG-Rollenaktualisierungen, wenn mehrere Transportanfragen, die Änderungen an den Autorisierungsprofilen enthalten, gleichzeitig während eines engen Release-Fensters importiert werden?
Antwort:
Wenn mehrere Transportanfragen, die PFCG-Rollen enthalten, gleichzeitig importiert werden, können bei der Rollenerstellung (PFCG → Profil generieren) Tabellen-Sperrkollisionen bei USR10 oder USR12 auftreten, was zu unvollständigen Autorisierungspuffern führt, in denen einige Benutzer partielle Rollenaktualisierungen erhalten. Um dies zu testen:
Gestufte Import-Simulation: Im QAS-System importieren Sie die Rollen-Transporte nacheinander statt gleichzeitig. Dokumentieren Sie die Rückgabecodes (Ziel RC=0 oder RC=4 Warnungen). Setzen Sie dann das System zurück und importieren Sie sie gleichzeitig. Vergleichen Sie die User Master-Datensätze (Tabelle UST04) zwischen den beiden Szenarien mit SE16 oder abfragen Sie AGR_USERS, um zu sehen, ob die Rollen zuweisungen unterschiedlich sind.
Vergleich der Autorisierungsspuren: Verwenden Sie ST01 (Autorisierungsspur) für denselben Benutzer vor und nach dem gleichzeitigen Import. Erfassen Sie die Autorisierungsprüfungs-Puffer. Wenn der sequenzielle Import für Z_CUSTOM_AUTH_OBJECT erfolgreiche Prüfungen zeigt, der gleichzeitige Import jedoch Fehlschläge aufweist, ist wahrscheinlich eine Rennbedingung bei der Profil-Erstellung vorhanden.
PFUD-Latenztests: Führen Sie unmittelbar nach dem gleichzeitigen Import SUIM → Benutzer → Nach komplexen Auswahlkriterien aus und überprüfen Sie, ob die Profil-Versionen (PROFN in USR10) mit der Rollen-Version in PFCG übereinstimmen. Wenn sie nicht übereinstimmen, wurde die Benutzermaster-Anpassung (PFUD) möglicherweise übersprungen oder ist stillschweigend fehlgeschlagen. Die Lösung besteht darin, einen obligatorischen PFUD-Lauf mit RSUSR200 (Analyse der Benutzer-Rollen-Zuweisungen) zur Überprüfung vor der Abnahme durchzusetzen.