Les mises en œuvre de SAP S/4HANA s'appuient fortement sur le launchpad Fiori comme interface utilisateur centrale, remplaçant les transactions traditionnelles de SAP GUI par des applications SAPUI5. Ces applications consomment des données via des services OData qui englobent souvent des modules de fonction RFC (Remote Function Call) hérités. L'architecture de déploiement implique plusieurs couches : l'application frontend BSP (Business Server Pages), la couche SAP Gateway (exposant OData), la pile backend ABAP, et les profils d'autorisation PFCG (Profile Generator).
Lors de la promotion de paysage (Développement → Assurance Qualité → Production), des incohérences se produisent souvent non pas à cause de défauts de code, mais en raison de dérive de configuration. Les services OData mettent en cache les métadonnées de manière agressive dans le composant IWBEP, tandis que les rôles PFCG nécessitent une régénération manuelle (Profil → Générer) pour propager de nouveaux Objets d'autorisation comme S_START ou des objets personnalisés Z*. Cette question teste la capacité d'un testeur à naviguer dans l'architecture à n niveaux et à isoler systématiquement si une tuile manquante est due à un cache frontend, des métadonnées de passerelle, un séquençage de transport ou une latence de tampon d'autorisation.
Le défi principal est l'ambiguïté des symptômes : un utilisateur se connecte au launchpad Fiori et voit soit une tuile grisée, soit la tuile est complètement manquante, soit en cliquant dessus, cela retourne "Impossible d'ouvrir l'application. Veuillez réessayer plus tard." Ces symptômes peuvent provenir de :
Obsolescence des métadonnées OData : L'application SAPUI5 récupère $metadata pour comprendre les structures d'entité. Si le cache de la Gateway (/IWFND/CACHE) contient une ancienne version après le transport, l'application peut échouer à se lier aux champs RFC qui ont changé en backend.
Délai de propagation du rôle PFCG : Même si la Demande de Transport a réussi à déplacer le Rôle vers QAS, les tables User Master (USR04) peuvent ne pas refléter les nouvelles versions de Profil jusqu'à ce qu'une comparaison soit effectuée (PFUD) ou que l'utilisateur se reconnecte. Le rôle pourrait lister le Catalogue mais manquer l'autorisation spécifique S_IWSG (Internet Communication Framework) pour le service OData.
Orphelins de Mapping Cible : L'entrée LPD_CUST (Launchpad Customizing) ou l'affectation de CATALOG pourrait référencer un Objet Sémantique (p.ex., ZPurchaseOrder) et une Action (create), mais si le transport a omis l'affectation de Groupe ou si l'ID de composant SAPUI5 dans manifest.json ne correspond pas au nom de l'application BSP, la tuile se rend mais ne navigue nulle part.
Sans une approche systématique, les testeurs perdent des heures à vérifier le code SE80 lorsque le problème est un Alias système manquant dans SM59 ou un tampon d'autorisation SU56 non vidé.
Un protocole d'élimination en couches est nécessaire, travaillant de la configuration statique au runtime dynamique :
Étape 1 : Audit de cohérence de transport
Avant tout test fonctionnel, vérifiez le contenu de la Transport of Copies (TOC) ou de la Demande de Workbench en utilisant SE01 et SE09. Confirmez la co-dépendance : l'application BSP, le nœud ICF (transaction SICF), le service OData (/IWFND/MAINT_SERVICE), les affectations de Catalogue/Group Fiori (/UI2/FLPD_CUST), et le rôle PFCG doivent soit être dans le même transport, soit avoir un séquençage documenté. Utilisez SCMP (Comparaison de Vue/Table) pour comparer les tables LPD_T (Launchpad Data) entre les systèmes.
Étape 2 : Invalidation du cache des métadonnées
Exécutez /IWFND/CACHE_CLEANUP dans le système Gateway pour effacer les caches de Modèle et de Métadonnées. Dans le navigateur, forcez un rechargement complet (Ctrl+F5) et ajoutez ?sap-ui-xx-noCache=true à l'URL de bootstrap SAPUI5. Vérifiez l'onglet Réseau pour la requête $metadata ; vérifiez que la réponse XML contient les bons EntitySets correspondant à la signature RFC actuelle.
Étape 3 : Vidage du tampon d'autorisation
Utilisez la transaction SU56 pour supprimer le tampon d'autorisation de l'utilisateur actuel. Exécutez PFUD (Ajustement des données utilisateur) avec l'option "Comparer" pour garantir que le Profil du rôle PFCG est à jour. Exécutez SU53 immédiatement après un accès échoué à la tuile pour afficher la dernière vérification d'autorisation échouée. Recherchez spécifiquement les objets S_START (autorisation de démarrage générique), S_IWSG, et S_SERVICE.
Étape 4 : Vérification de la résolution de Mapping Cible
Utilisez la transaction /UI2/FLIA (Analyse de l'intention du Launchpad Fiori) pour entrer l'Objet Sémantique et l'Action. Cela révèle quelle application SAPUI5 (via ID du composant) est résolue, le chemin ICF, et si l'entrée LPD_CST est valide. Si FLIA montre le mapping mais que l'utilisateur ne peut pas le voir, le problème est PFCG (affectation de catalogue manquante). Si FLIA ne montre aucun mapping, le problème est dans LPD_CUST ou le transport.
Étape 5 : Traçage de connectivité RFC
Activez les journaux d'erreurs Gateway via /IWFND/ERROR_LOG. Tracez la destination RFC en utilisant SM59 → Test de connexion, puis SM50 (Vue des processus) pour surveiller les échecs RFC lorsque le service OData tente d'atteindre le backend. Vérifiez les échecs d'autorisation S_RFC ou S_RFCACL dans SM21 (Journal système).
Description du problème
Lors d'un projet de mise à niveau S/4HANA 2022, l'application SAP Fiori "Gérer les demandes d'achat" fonctionnait parfaitement en Développement mais échouait à se lancer en Assurance Qualité avec l'erreur : "L'application n'a pas pu être ouverte car le composant SAPUI5 ui.sscim.prereq n'a pas pu être chargé." L'équipe Basis a confirmé que tous les transports avaient été importés avec succès avec RC=0 (code de retour zéro). Le dépôt ABAP SAPUI5 (SE80) montrait que l'application BSP ui.sscim.prereq était présente dans QAS. Le service OData C_PURCHASEREQ_SRV était actif dans /IWFND/MAINT_SERVICE. Cependant, la tuile apparaissait pour les administrateurs mais pas pour les agents d'approvisionnement, suggérant un problème d'autorisation, bien que les administrateurs aient également reçu l'erreur de chargement en cliquant sur la tuile.
Solution 1 : Effacement du cache du navigateur et retour à une version antérieure dUI5
L'hypothèse initiale était que QAS avait un cache SAPUI5 corrompu ou un décalage de version dans le dépôt ABAP. L'équipe a effacé les caches de navigateur pour tous les utilisateurs et a invalidé manuellement le cache du dépôt MIME en utilisant /UI5/APP_INDEX_CALCULATE.
Avantages : C'est une solution rapide et non invasive qui résout souvent les problèmes de chargement des ressources SAPUI5 (404 sur Component-preload.js). Cela ne nécessite aucun changement de code ABAP.
Inconvénients : Cela n'a pas résolu le problème. L'erreur persistait, et plus critique, cela n'expliquait pas pourquoi la tuile était invisible pour les agents. Cela traitait le symptôme (erreur de chargement) sans diagnostiquer pourquoi les métadonnées échouaient à se charger, masquant potentiellement un problème de configuration de service OData plus profond.
Solution 2 : Régénération complète du rôle PFCG et comparaison des utilisateurs
L'équipe suspectait que l'affectation du Catalogue Fiori dans PFCG était manquante. Ils ont régénéré tous les profils pour les rôles d'approvisionnement et ont exécuté PFUD avec l'option "Rapprochement complet" pour s'assurer que tous les utilisateurs recevaient les autorisations mises à jour.
Avantages : Garantit que les Profils d'autorisation (PROF_NAME dans UST04) sont synchronisés avec les définitions de Rôle. Cela a corrigé le problème de la "tuile invisible" pour les agents, car l'affectation du groupe de Catalogue était effectivement manquante dans la version de rôle QAS.
Inconvénients : Bien que la tuile soit devenue visible, cliquer dessus entraînait toujours l'erreur "le composant n'a pas pu être chargé". Cette approche a échoué car elle se concentrait uniquement sur la couche d'autorisation (PFCG) et a ignoré la couche de mappage de service OData à RFC. Les administrateurs qui pouvaient voir la tuile ne pouvaient toujours pas l'ouvrir, prouvant que le problème transcendait l'autorisation.
Solution 3 : Validation systématique de la passerelle et du nœud ICF (Approche choisie)
La méthodologie choisie consistait à vérifier l'état d'activation du service OData indépendamment de l'application UI5. En utilisant la transaction /IWFND/GW_CLIENT, l'équipe a exécuté une requête GET à C_PURCHASEREQ_SRV?sap-client=100. La requête a retourné HTTP 200, mais le payload XML a montré que les Métadonnées provenaient d'une version mise en cache précédant un récent changement d'interface RFC. Ensuite, vérifier la transaction SICF (Services de maintenance) a révélé que le nœud ICF /sap/bc/ui5_ui5/sap/ui_sscim_prereq était actif en DEV mais inactif en QAS (l'import avait échoué silencieusement en raison d'un objet verrouillé). Enfin, vérifier /IWFND/ERROR_LOG a montré que lorsque l'application essayait de récupérer $metadata, elle rencontrait une erreur d'autorisation sur le mappage de System Alias, qui pointait vers une destination SM59 obsolète qui avait été décommissionnée après la migration.
Pourquoi choisi : Cette approche a isolé les trois échecs simultanés : (1) désynchronisation du cache OData entre DEV et QAS causant un décalage de métadonnées, (2) inactivité du nœud ICF empêchant les ressources SAPUI5 d'être servies via HTTP, et (3) mauvaise configuration de l'Alias système en QAS pointant vers une destination RFC inexistante. Elle a fourni des codes d'erreur spécifiques (ICF 403 vs OData 404) plutôt que des messages génériques destinés aux utilisateurs.
Le résultat
L'exécution de /IWFND/CACHE_CLEANUP a rafraîchi les métadonnées OData pour correspondre à la nouvelle signature RFC. L'activation du nœud ICF via SICF a résolu l'erreur "le composant n'a pas pu être chargé" en rendant accessibles les fichiers HTML et JS de l'application BSP. La correction de l'Alias système dans /IWFND/MAINT_SERVICE → Aliases système SAP a assuré que la Gateway pouvait atteindre le backend. Les agents d'approvisionnement pouvaient alors voir et ouvrir l'application car le rôle PFCG (corrigé dans la solution 2) accordait l'accès à la tuile maintenant fonctionnelle. L'approche systématique a permis d'économiser environ 8 heures de débogage ABAP qui auraient été perdues en supposant que le code était défectueux.
Comment déterminez-vous de manière définitive si une tuile Fiori manquante est causée par un mapping cible manquant (LPD_CUST) par rapport à une affectation de catalogue manquante dans PFCG, étant donné que les deux résultent en une tuile non affichée ?
Réponse :
Un Mapping Cible manquant (configuré dans LPD_CUST ou le designer CATALOG Fiori) signifie que la combinaison de l'Objet Sémantique et de l'Action n'a pas d'application SAPUI5 associée, mais la tuile elle-même pourrait encore apparaître si l'affectation du Catalogue existe dans PFCG. En cliquant, vous obtiendrez une erreur "Hôte de navigation introuvable". Pour vérifier, utilisez la transaction /UI2/FLIA (Analyse d'intention du Launchpad Fiori). Entrez l'Objet Sémantique et l'Action ; si FLIA retourne "Aucune application trouvée pour cette intention", le Mapping Cible est manquant ou le nom de l'application BSP dans le mapping est incorrect.
Inversement, si FLIA montre avec succès l'application SAPUI5 cible et ID du composant, mais que la tuile est manquante sur le launchpad de l'utilisateur, le problème est lié à PFCG. Vérifiez si le Catalogue contenant la tuile est attribué au Rôle de l'utilisateur dans PFCG (vérifiez l'onglet Menu), et assurez-vous que le Groupe (qui organise les tuiles sur la page d'accueil du launchpad) est également attribué. De plus, vérifiez que l'Objet d'autorisation S_START avec la valeur WEBGUI est présent dans la trace SU53 de l'utilisateur, car cela est requis pour lancer n'importe quelle application Fiori, et est souvent manqué lors des mises à niveau des rôles à partir de systèmes uniquement SAP GUI.
Pourquoi un test de service OData réussit-il via le Client Gateway (/IWFND/GW_CLIENT) mais échoue avec un 403 Interdit lorsqu'il est invoqué par l'application SAPUI5 dans le navigateur ?
Réponse :
Le Client Gateway (/IWFND/GW_CLIENT) s'exécute dans le contexte de session de SAP GUI, utilisant l'authentification SAP Logon et contournant les vérifications de sécurité du nœud ICF HTTP. L'application SAPUI5, cependant, achemine les demandes via la structure du nœud ICF (/sap/bc/ui5_ui5/... ou /sap/opu/odata/...).
Par conséquent, un 403 dans le navigateur indique généralement :
Inactivité du Nœud ICF : Le nœud de service spécifique dans SICF est inactif dans le client cible, même si le service OData lui-même est enregistré dans /IWFND/MAINT_SERVICE.
Autorisation S_ICF : L'utilisateur n'a pas l'objet d'autorisation S_ICF avec les bonnes Valeurs de Champ ICF (Nom du service, Hôte, etc.) pour accéder à ce chemin HTTP spécifique. Vérifiez la transaction SU53 immédiatement après l'échec.
Validation de Jeton CSRF : Les applications SAPUI5 nécessitent un jeton CSRF (Cross-Site Request Forgery) valide récupéré via une requête HEAD. Si les systèmes frontend et backend sont mal configurés (par exemple, différentes ID système dans un scénario de Fiori Front-end Server), la validation de jeton échoue avec un 403, tandis que le GW_CLIENT (sans état et sans CSRF) réussit.
Comment testez-vous pour les conditions de concurrence dans les mises à jour de rôle PFCG lorsque plusieurs demandes de transport contenant des modifications de profil d'autorisation sont importées simultanément durant une fenêtre de publication serrée ?
Réponse :
Lorsque plusieurs Demandes de Transport contenant des rôles PFCG sont importées simultanément, la génération de Profil (PFCG → Générer Profil) peut créer des collisions de verrouillage de table sur USR10 ou USR12, entraînant des tampons d'autorisation incomplets où certains utilisateurs reçoivent des mises à jour de rôle partielles. Pour tester cela :
Simulation d'importation séquencée : Dans le système QAS, importez les transports Rôle séquentiellement plutôt que simultanément. Documentez les Codes de Retour (cible RC=0 ou RC=4 avertissements). Ensuite, réinitialisez le système et importez-les simultanément. Comparez les enregistrements User Master (table UST04) entre les deux scénarios en utilisant SE16 ou interrogez AGR_USERS pour voir si les affectations de rôle diffèrent.
Comparaison de Trace d'Autorisation : Utilisez ST01 (Trace d'autorisation) pour le même utilisateur avant et après l'importation simultanée. Capturez les tampons de vérification d'autorisation. Si l'importation séquentielle montre des vérifications réussies pour Z_CUSTOM_AUTH_OBJECT mais que l'importation simultanée montre des échecs, une condition de concurrence dans la génération de Profil est probable.
Tests de Latence PFUD : Immédiatement après l'importation simultanée, exécutez SUIM → Utilisateur → Par Critères de Sélection Complexes et vérifiez si les versions de Profil (PROFN dans USR10) correspondent à la version de Rôle dans PFCG. Si elles ne correspondent pas, l'ajustement User Master (PFUD) a été ignoré ou a échoué silencieusement. La solution consiste à imposer un exécution obligatoire de PFUD avec RSUSR200 (Analyse des Assignations Utilisateur-Rôle) vérification avant validation.