Invalidation des caches du launchpad

Trois caches peuvent conserver un contenu de launchpad obsolète :

• Le cache UI2 côté serveur, sur le serveur front-end, pour les services propres au launchpad comme la construction des pages et la personnalisation. Le système l'invalide automatiquement lorsqu'une configuration de tile ou de catalogue, un rôle PFCG, un contenu LPD_CUST ou une application SAPUI5 change.
• Le cache du navigateur, pour les ressources SAPUI5, le code des applications, les target mappings et les métadonnées OData. Les jetons cache buster dans les URL des ressources font recharger par le navigateur uniquement ce qui a changé sur le serveur.
• Le cache de métadonnées SAP Gateway, pour les modèles de services OData, vidé séparément avec /IWFND/CACHE_CLEANUP et /IWBEP/CACHE_CLEANUP.

Savoir lequel des trois contient les données obsolètes détermine l'étape d'invalidation des caches du launchpad nécessaire.

La position de SAP est que l'invalidation manuelle du cache UI2 ne devrait normalement pas être nécessaire, car les modifications la déclenchent automatiquement. Vider les caches se justifie lorsque :

• un catalogue ou une application transportés n'apparaissent pas alors que les rôles et le contenu sont corrects ;
• un support package, une note SAPUI5 ou une mise à niveau de release a été appliqué ;
• les utilisateurs voient l'ancien comportement d'une application après un déploiement, et l'index des applications SAPUI5 n'a pas été recalculé.

Ne videz pas les caches par réflexe pour chaque tile manquante. Un catalogue absent du rôle ou un target mapping sans le type d'appareil de l'utilisateur produit le même symptôme, et /UI2/FLIA les détecte en quelques minutes. L'invalidation des caches du launchpad corrige des données obsolètes, pas un contenu erroné.

Après l'import d'un support package sur le serveur front-end d'Alder Manufacturing :

1. Exécutez /UI5/APP_INDEX_CALCULATE, ou vérifiez que son job planifié a tourné, afin que les jetons cache buster reflètent les nouvelles versions des applications.
2. Exécutez /UI2/INVALIDATE_GLOBAL_CACHES dans SE38, ou la transaction /UI2/INVAL_CACHES, pour invalider tous les caches UI2.
3. Si nécessaire, exécutez /UI2/INVALIDATE_CLIENT_CACHES dans SE38, pour tous les utilisateurs ou un seul. Invalider les caches d'autres utilisateurs requiert le rôle SAP_UI2_ADMIN_700.
4. Exécutez /UI2/DELETE_CACHE_AFTER_IMP après l'import si le guide de mise à niveau de votre release le mentionne.
5. Nettoyez le cache de métadonnées SAP Gateway si des services OData ont changé.
6. Demandez aux utilisateurs concernés de recharger la page, ou de vider le cache du navigateur si les symptômes persistent.

Chaque invalidation des caches client est consignée dans le journal d'application (SLG1). Respecter cet ordre rend l'invalidation des caches du launchpad prévisible au lieu de procéder par tâtonnements.

/UI2/INVALIDATE_CLIENT_CACHES renouvelle le jeton cache buster global. Depuis que SAP a introduit le cache busting spécifique à chaque application, les applications SAP Fiori du référentiel SAPUI5 obtiennent leurs propres jetons à partir de l'index des applications SAPUI5, et le navigateur ne recharge une application que si elle a changé. Le jeton global couvre encore :

• les données des requêtes OData propres au launchpad, comme les target mappings et la personnalisation ;
• les ressources SAPUI5 classiques qui ne sont pas des composants, par exemple certaines implémentations de tiles spécifiques ;
• les applications absentes d'un index des applications incomplet.

SAP décrit donc l'exécution de /UI2/INVALIDATE_CLIENT_CACHES comme nécessaire uniquement dans des cas exceptionnels. Un index des applications planifié régulièrement rend /UI2/INVALIDATE_CLIENT_CACHES rarement nécessaire.