Geschiedenis van de Vraag

SAP S/4HANA implementaties steunen sterk op de Fiori launchpad als de centrale gebruikersinterface, waarbij traditionele SAP GUI transacties worden vervangen door SAPUI5 applicaties. Deze applicaties verbruiken gegevens via OData diensten die vaak legacy RFC (Remote Function Call) functie modules wikkelen. De implementatiearchitectuur omvat meerdere lagen: de frontend BSP (Business Server Pages) applicatie, de SAP Gateway laag (die OData blootstelt), de backend ABAP stack, en de PFCG (Profile Generator) autorisatie profielen.

Tijdens landschapsbevordering (Ontwikkeling → Kwaliteitszorg → Productie) ontstaan inconsistenties vaak niet door codefouten, maar door configuratiedrift. OData diensten cachen metadata agressief in de IWBEP component, terwijl PFCG rollen handmatige regeneratie vereisen (Profiel → Genereren) om nieuwe Autorisatieobjecten zoals S_START of aangepaste Z* objecten te propagateren. Deze vraag test het vermogen van een tester om door de n-tier architectuur te navigeren en systematisch te isoleren of een ontbrekende tegel te wijten is aan frontend cache, gateway metadata, transport sequentie of autorisatie buffer latentie.

Het Probleem

De kernuitdaging is de symptoomambiguïteit: een gebruiker logt in op de Fiori launchpad en ziet ofwel een grijs gemaakte tegel, of de tegel ontbreekt volledig, of door erop te klikken verschijnt "Kon de app niet openen. Probeer het later nog eens." Deze symptomen kunnen voortkomen uit:

OData Metadata Oudheid: De SAPUI5 app haalt $metadata op om entiteitsstructuren te begrijpen. Als de Gateway cache (/IWFND/CACHE) een oude versie vasthoudt na transport, kan de app falen om te binden aan RFC velden die in de backend zijn veranderd.
PFCG Rol Verspreiding Vertraging: Zelfs als de Transportverzoek succesvol de Rol naar QAS heeft verplaatst, weerspiegelen de User Master (USR04) tabellen mogelijk de nieuwe Profiel versies niet totdat een vergelijking wordt uitgevoerd (PFUD) of de gebruiker zich opnieuw aanmeldt. De rol kan de Catalogus vermelden maar kan ontbreken aan de specifieke S_IWSG (Internet Communication Framework) autorisatie voor de OData service.
Target Mapping Wees: De LPD_CUST (Launchpad Customized) entry of CATALOG toewijzing kan een Semantisch Object (bijv. ZPurchaseOrder) en Actie (creëren), maar als het transport de Groep toewijzing gemist heeft of de SAPUI5 component ID in manifest.json niet overeenkomt met de BSP applicatienaam, dan renderen de tegel, maar kunnen nergens heen navigeren.

Zonder een systematische aanpak verspillen testers uren met het controleren van SE80 code wanneer het probleem een ontbrekend Systeem Alias in SM59 of een niet-opgefriste SU56 autorisatie buffer is.

De Oplossing

Een gelaagde eliminatieprotocol is vereist, werkend van statische configuratie naar dynamische runtime:

Stap 1: Transportconsistentie Audit Voordat enig functioneel testen plaatsvindt, verifieer de inhoud van de Transport van Exemplaren (TOC) of Werkbankverzoek met behulp van SE01 en SE09. Bevestig co-afhankelijkheid: de BSP applicatie, ICF node (transactie SICF), OData service (/IWFND/MAINT_SERVICE), Fiori Catalogus/Groep toewijzingen (/UI2/FLPD_CUST), en PFCG rol moeten ofwel in hetzelfde transport zijn of gedocumenteerde sequenties hebben. Gebruik SCMP (Weergave/Tabel Vergelijking) om LPD_T (Launchpad Data) tabellen tussen systemen te vergelijken.

Stap 2: Metadata Cache Ongeldig Verklaring Voer /IWFND/CACHE_CLEANUP uit in het Gateway systeem om Model en Metadata caches te wissen. Dwing in de browser een harde herlaad (Ctrl+F5) af en voeg ?sap-ui-xx-noCache=true toe aan de SAPUI5 bootstrap URL. Controleer het Netwerk tabblad voor de $metadata aanvraag; bevestig dat de XML reactie de juiste EntitySets bevat die overeenkomen met de huidige RFC handtekening.

Stap 3: Autorisatie Buffer Oppompen Gebruik transactie SU56 om de huidige autorisatie buffer van de gebruiker te verwijderen. Voer PFUD (Aanpassing van Gebruikersgegevens) uit met de "Vergelijk" optie om ervoor te zorgen dat het PFCG rol Profiel actueel is. Voer onmiddellijk SU53 uit na een mislukte tegeltoegang om de laatste mislukte autorisatiecontrole weer te geven. Kijk specifiek naar S_START (algemene startautorisatie), S_IWSG, en S_SERVICE objecten.

Stap 4: Target Mapping Resolutie Controle Gebruik transactie /UI2/FLIA (Fiori Launchpad Intent Analyse) om het Semantisch Object en Actie in te voeren. Dit onthult welke SAPUI5 applicatie (via Component ID) wordt opgelost, het ICF pad, en of de LPD_CST entry geldig is. Als FLIA de mapping toont maar de gebruiker deze niet kan zien, is het probleem PFCG (ontbrekende catalogus toewijzing). Als FLIA geen mapping toont, zit het probleem in LPD_CUST of het transport.

Stap 5: RFC Verbinding Tracering Activeer Gateway foutlogboeken via /IWFND/ERROR_LOG. Trace de RFC bestemming met behulp van SM59 → Verbinding Test, dan SM50 (Procesoverzicht) om te kijken naar RFC fouten wanneer de OData service probeert de backend te bereiken. Controleer op S_RFC of S_RFCACL autorisatie fouten in SM21 (Systeemlog).

Situatie uit het Leven

Probleembeschrijving

Tijdens een S/4HANA 2022 upgradeproject werkte de SAP Fiori "Beheer Aankoopaanvragen" applicatie perfect in Ontwikkeling maar kon niet worden geopend in Kwaliteitszorg met de fout: "De applicatie kon niet worden geopend omdat de SAPUI5 component ui.sscim.prereq niet geladen kon worden." Het Basis team bevestigde dat alle transporten succesvol waren geïmporteerd met RC=0 (Return Code nul). De SAPUI5 ABAP repository (SE80) toonde de ui.sscim.prereq BSP applicatie was aanwezig in QAS. De OData service C_PURCHASEREQ_SRV was actief in /IWFND/MAINT_SERVICE. Echter, de tegel verscheen voor beheerders maar niet voor inkoopmedewerkers, wat op een autorisatieprobleem duidde, toch kregen beheerders ook de laadfout toen ze op de tegel klikten.

Oplossing 1: Browser Cache Opschonen en UI5 Versie Terugrol

De eerste hypothese was dat QAS een beschadigde SAPUI5 cache of een versie mismatch in de ABAP repository had. Het team wist de browser caches voor alle gebruikers en invalideerde handmatig de MIME repository cache met behulp van /UI5/APP_INDEX_CALCULATE.

Voordelen: Dit is een snelle, niet-invasieve oplossing die vaak SAPUI5 resource laadproblemen (404s op Component-preload.js) oplost. Het vereist geen ABAP code wijzigingen.

Nadelen: Het loste het probleem niet op. De fout bleef bestaan, en nog kritischer, het verklaarde niet waarom de tegel onzichtbaar was voor medewerkers. Het behandelde het symptoom (laadfout) zonder te diagnosticeren waarom de metadata niet laadde, wat een dieper OData service configuratieprobleem kon verhullen.

Oplossing 2: Volledige PFCG Rol Regeneratie en Gebruiker Vergelijking

Het team vermoedde dat de Fiori Catalogus toewijzing in PFCG ontbrak. Ze regenerate alle profielen voor de inkooprollen en voerden PFUD uit met de "Volledige verzoening" optie om ervoor te zorgen dat alle gebruikers de bijgewerkte autorisaties ontvingen.

Voordelen: Zorgt ervoor dat Autorisatieprofielen (PROF_NAME in UST04) gesynchroniseerd zijn met de Rol definities. Dit loste het "onzichtbare tegel" probleem voor de medewerkers op, aangezien de Catalogus groeps toewijzing inderdaad ontbrak in de QAS rol versie.

Nadelen: Terwijl de tegel zichtbaar werd, resulteerde het klikken erop nog steeds in de "component kon niet worden geladen" fout. Deze aanpak faalde omdat ze puur op de autorisatielaag (PFCG) focuste en de OData service naar RFC mappinglaag negeerde. De beheerders die de tegel konden zien konden deze nog steeds niet openen, wat bewees dat het probleem autorisatie overstemde.

Oplossing 3: Systematische Gateway en ICF Node Validatie (Gekozen Benadering)

De gekozen methodologie omvatte het controleren van de OData service activatiestatus onafhankelijk van de UI5 app. Met behulp van transactie /IWFND/GW_CLIENT voerde het team een GET aanvraag uit naar C_PURCHASEREQ_SRV?sap-client=100. De aanvraag retourneerde HTTP 200, maar de XML payload toonde dat de Metadata afkomstig was van een gecachte versie voorafgaand aan een recente RFC interface verandering. Vervolgens toonde het controleren van transactie SICF (Onderhoud Diensten) aan dat de ICF node /sap/bc/ui5_ui5/sap/ui_sscim_prereq actief was in DEV maar inactief in QAS (de import was stilletjes mislukt vanwege een vergrendeld object). Ten slotte toonde het controleren van /IWFND/ERROR_LOG aan dat wanneer de app probeerde $metadata op te halen, het een autorisatie fout tegenkwam op de Systeem Alias mapping, die wees naar een verouderde SM59 bestemming die na migratie was gedecommissioneerd.

Waarom gekozen: Deze aanpak isoleerde de drie gelijktijdige fouten: (1) OData cache desynchronisatie tussen DEV en QAS die metadata mismatches veroorzaakte, (2) ICF node inactiviteit die verhinderde dat de SAPUI5 bronnen via HTTP konden worden bediend, en (3) Systeem Alias misconfiguratie in QAS die wees naar een niet-bestaande RFC bestemming. Het leverde specifieke foutcodes (ICF 403s vs OData 404s) in plaats van generieke gebruikersgerichte berichten.

Het Resultaat

De uitvoering van /IWFND/CACHE_CLEANUP verfriste de OData metadata om overeen te komen met de nieuwe RFC handtekening. Het activeren van de ICF node via SICF loste de "component kon niet worden geladen" fout op door de BSP applicatie's HTML en JS bestanden toegankelijk te maken. Het corrigeren van de Systeem Alias in /IWFND/MAINT_SERVICE → SAP Systeem Alias zorgde ervoor dat de Gateway de backend kon bereiken. De inkoopmedewerkers konden de applicatie toen zien en openen omdat de PFCG rol (gecorrigeerd in Oplossing 2) toegang verleende tot de nu-functionele tegel. De systematische aanpak bespaarde ongeveer 8 uur ABAP debuggen dat verspild zou zijn aan de veronderstelling dat de code defect was.

Wat Kandidaten Vaak Missen

Hoe bepaal je definitief of een ontbrekende Fiori tegel wordt veroorzaakt door een ontbrekende Target Mapping (LPD_CUST) versus een ontbrekende Catalogus toewijzing in PFCG, gegeven dat beide resulteren in de tegel die niet wordt weergegeven?

Antwoord:

Een ontbrekende Target Mapping (geconfigureerd in LPD_CUST of de Fiori CATALOG ontwerper) betekent dat de combinatie van Semantisch Object en Actie geen bijbehorende SAPUI5 applicatie heeft, maar de tegel zelf kan nog steeds verschijnen als de Catalogus toewijzing bestaat in PFCG. Klikken zou een "Navigatiedoel kan niet worden gevonden" fout opleveren. Om te verifiëren, gebruik transactie /UI2/FLIA (Fiori Launchpad Intent Analyse). Voer het Semantisch Object en Actie in; als FLIA "Geen applicatie gevonden voor deze intentie" retourneert, ontbreekt de Target Mapping of de BSP applicatienaam in de mapping is onjuist.

Omgekeerd, als FLIA succesvol de doel SAPUI5 applicatie en Component ID toont, maar de tegel ontbreekt van de launchpad van de gebruiker, dan is het probleem PFCG-gerelateerd. Controleer of de Catalogus die de tegel bevat is toegewezen aan de Rol van de gebruiker in PFCG (controleer het Menu tabblad), en zorg ervoor dat de Groep (die tegels op de startpagina van de launchpad organiseert) ook is toegewezen. Daarnaast, verifieer dat het Autorisatieobject S_START met de waarde WEBGUI aanwezig is in de SU53 trace van de gebruiker, aangezien dit vereist is om elke Fiori app te lanceren, en vaak wordt gemist bij rol-upgrades vanuit SAP GUI-alleen systemen.

Waarom kan een OData service succesvol getest worden via de Gateway Client (/IWFND/GW_CLIENT) maar falen met een 403 Verboden wanneer deze wordt aangeroepen door de SAPUI5 applicatie in de browser?

Antwoord:

De Gateway Client (/IWFND/GW_CLIENT) wordt uitgevoerd binnen de context van de SAP GUI sessie, gebruikmakend van de SAP Logon authenticatie en omzeilend de veiligheid controles van de HTTP Internet Communication Framework (ICF) node. De SAPUI5 applicatie, echter, routed aanvragen via de ICF node structuur (/sap/bc/ui5_ui5/... of /sap/opu/odata/...).

Daarom geeft een 403 in de browser typisch aan:

ICF Node Inactiviteit: De specifieke dienst node in SICF is inactief in de doelclient, hoewel de OData service zelf geregistreerd is in /IWFND/MAINT_SERVICE.
S_ICF Autorisatie: De gebruiker heeft niet de S_ICF autorisatie object met de juiste ICF Veldwaarden (Dienstennaam, Host, etc.) om toegang te krijgen tot dat specifieke HTTP pad. Controleer transactie SU53 onmiddellijk na de mislukking.
CSRF Token Validatie: SAPUI5 applicaties vereisen een geldig CSRF (Cross-Site Request Forgery) token dat via een HEAD aanvraag is opgehaald. Als de frontend en backend systemen verkeerd zijn geconfigureerd (bijv. verschillende Systeem ID's in een Fiori Front-end Server scenario), faalt de token validatie met een 403, terwijl de GW_CLIENT (staatloos en CSRF-agnostisch) slaagt.

Hoe test je op racecondities in PFCG rol updates wanneer meerdere transportverzoeken met wijzigingen in autorisatie profielen gelijktijdig worden geïmporteerd tijdens een krap release venster?

Antwoord:

Wanneer meerdere Transportverzoeken die PFCG rollen bevatten gelijktijdig worden geïmporteerd, kan Profiel generatie (PFCG → Profiel Genereren) Tabel Vergrendeling botsingen creëren op USR10 of USR12, wat leidt tot onvolledige autorisatie buffers waarbij sommige gebruikers gedeeltelijke rol updates ontvangen. Om dit te testen:

Gefaseerde Import Simulatie: In het QAS systeem, importeer de Rol transporten sequentieel in plaats van gelijktijdig. Documenteer de Return Codes (doel RC=0 of RC=4 waarschuwingen). Reset dan het systeem en importeer ze gelijktijdig. Vergelijk de User Master records (tabel UST04) tussen de twee scenario's met behulp van SE16 of query AGR_USERS om te zien of de roltoewijzingen verschillen.
Autorisatie Trace Vergelijking: Gebruik ST01 (Autorisatie Trace) voor dezelfde gebruiker voor en na de gelijktijdige import. Leg de Autorisatie Controle buffers vast. Als de sequentiële import succesvolle controles toont voor Z_CUSTOM_AUTH_OBJECT maar de gelijktijdige import fouten vertoont, is een race-conditie in Profiel generatie waarschijnlijk.
PFUD Latency Testing: Onmiddellijk na de gelijktijdige import, voer SUIM → Gebruiker → Op Basis van Complexe Selectiecriteria uit en controleer of de Profiel versies (PROFN in USR10) overeenkomen met de Rol versie in PFCG. Als ze niet overeenkomen, werd de User Master aanpassing (PFUD) overgeslagen of mislukte het stilletjes. De oplossing is om een verplichte PFUD uitvoering met RSUSR200 (Analyse van Gebruikers-Rol Toewijzingen) verificatie af te dwingen voordat het goedgekeurd wordt.