Invalidación de la caché del launchpad

Tres cachés pueden contener contenido desactualizado del launchpad:

• Caché UI2 del servidor, en el front-end server, para los servicios propios del launchpad, como la construcción de páginas y la personalización. El sistema la invalida automáticamente cuando cambia la configuración de un tile o de un catálogo, un rol PFCG, el contenido de LPD_CUST o una app SAPUI5.
• Caché del navegador, para recursos SAPUI5, código de las apps, target mappings y metadatos OData. Los tokens de cache buster en las URL de los recursos hacen que el navegador recargue solo lo que cambió en el servidor.
• Caché de metadatos de SAP Gateway, para los modelos de los servicios OData, que se borra por separado con /IWFND/CACHE_CLEANUP y /IWBEP/CACHE_CLEANUP.

Saber cuál de las tres contiene los datos obsoletos determina qué paso de invalidación de la caché del launchpad se necesita.

La posición de SAP es que la invalidación manual de la caché UI2 normalmente no debería ser necesaria, porque los cambios la desencadenan automáticamente. Borrar las cachés está justificado cuando:

• un catálogo o una app transportados no aparecen aunque los roles y el contenido son correctos;
• se ha aplicado un support package, una nota de SAPUI5 o un upgrade de release;
• los usuarios ven el comportamiento antiguo de una app tras un despliegue y no se recalculó el índice de aplicaciones SAPUI5.

No borre las cachés como reflejo ante cada tile que falta. Un catálogo ausente en el rol o un target mapping sin el tipo de dispositivo del usuario producen el mismo síntoma, y /UI2/FLIA los encuentra en minutos. La invalidación de la caché del launchpad corrige datos obsoletos, no contenido incorrecto.

Después de que Alder Manufacturing importa un support package en su front-end server:

1. Ejecute /UI5/APP_INDEX_CALCULATE, o confirme que se ejecutó su job programado, para que los tokens de cache buster reflejen las nuevas versiones de las apps.
2. Ejecute /UI2/INVALIDATE_GLOBAL_CACHES en SE38, o la transacción /UI2/INVAL_CACHES, para invalidar todas las cachés UI2.
3. Si es necesario, ejecute /UI2/INVALIDATE_CLIENT_CACHES en SE38, para todos los usuarios o para uno. Invalidar las cachés de otros usuarios requiere el rol SAP_UI2_ADMIN_700.
4. Ejecute /UI2/DELETE_CACHE_AFTER_IMP después de la importación si la guía de upgrade de su release lo indica.
5. Limpie la caché de metadatos de SAP Gateway si cambiaron servicios OData.
6. Pida a los usuarios afectados que recarguen la página, o que borren la caché del navegador si los síntomas persisten.

Cada invalidación de cachés del cliente queda registrada en el registro de aplicación (SLG1). Seguir este orden hace que la invalidación de la caché del launchpad sea predecible en lugar de un proceso de prueba y error.

/UI2/INVALIDATE_CLIENT_CACHES renueva el token global de cache buster. Desde que SAP introdujo el cache busting específico por aplicación, las apps SAP Fiori del repositorio SAPUI5 obtienen sus propios tokens del índice de aplicaciones SAPUI5, y el navegador recarga una app solo cuando ha cambiado. El token global sigue cubriendo:

• los datos de las solicitudes OData propias del launchpad, como target mappings y personalización;
• los recursos SAPUI5 clásicos que no son componentes, por ejemplo algunas implementaciones de tiles personalizados;
• las apps que faltan en un índice de aplicaciones incompleto.

Por eso SAP describe la ejecución de /UI2/INVALIDATE_CLIENT_CACHES como necesaria solo en casos excepcionales. Con un índice de aplicaciones programado con regularidad, /UI2/INVALIDATE_CLIENT_CACHES rara vez hace falta.