Las implementaciones de SAP S/4HANA dependen en gran medida del launchpad de Fiori como la interfaz de usuario central, reemplazando las transacciones tradicionales de SAP GUI con aplicaciones SAPUI5. Estas aplicaciones consumen datos a través de servicios OData que a menudo envuelven módulos de función de RFC (Llamada de Función Remota) legados. La arquitectura de implementación involucra múltiples capas: la aplicación frontend BSP (Business Server Pages), la capa SAP Gateway (que expone OData), la pila ABAP en el backend y los perfiles de autorización PFCG (Generador de Perfiles).
Durante la promoción del paisaje (Desarrollo → Aseguramiento de Calidad → Producción), las inconsistencias a menudo surgen no por defectos de código, sino por deriva en la configuración. Los servicios OData almacenan en caché los metadatos de manera agresiva en el componente IWBEP, mientras que los roles PFCG requieren regeneración manual (Perfil → Generar) para propagar nuevos Objetos de Autorización como S_START o objetos personalizados Z*. Esta pregunta evalúa la capacidad de un evaluador para navegar por la arquitectura en capas y aislar sistemáticamente si un mosaico perdido se debe a la caché del frontend, metadatos del gateway, secuenciación de transporte o latencia del búfer de autorización.
El desafío principal es la ambigüedad del síntoma: un usuario inicia sesión en el launchpad de Fiori y ve un mosaico atenuado, o el mosaico está completamente ausente, o al hacer clic devuelve "No se pudo abrir la aplicación. Por favor, intente de nuevo más tarde." Estos síntomas pueden derivarse de:
Desactualización de Metadatos de OData: La aplicación SAPUI5 obtiene $metadata para comprender las estructuras de entidades. Si la caché del Gateway (/IWFND/CACHE) mantiene una versión antigua después del transporte, la aplicación puede fallar al intentar vincular campos de RFC que cambiaron en el backend.
Retraso en la Propagación del Rol PFCG: Incluso si la Solicitud de Transporte movió exitosamente el Rol a QAS, las tablas de Usuario Maestro (USR04) pueden no reflejar las nuevas versiones de Perfil hasta que se ejecute una comparación (PFUD) o el usuario inicie sesión nuevamente. El rol podría listar el Catálogo pero carecer de la autorización específica S_IWSG (Marco de Comunicación por Internet) para el servicio OData.
Huérfanos de Mapeo de Objetivos: La entrada LPD_CUST (Personalización del Launchpad) o la asignación de CATÁLOGO puede referirse a un Objeto Semántico (p.ej., ZPurchaseOrder) y Acción (crear), pero si el transporte omitió la asignación del Grupo o el ID del componente SAPUI5 en manifest.json no coincide con el nombre de la aplicación BSP, el mosaico se renderiza pero no navega a ningún lado.
Sin un enfoque sistemático, los evaluadores pierden horas revisando el código en SE80 cuando el problema es una Alias de Sistema faltante en SM59 o un búfer de autorización SU56 no reciclado.
Se requiere un protocolo de eliminación por capas, trabajando desde la configuración estática hasta el runtime dinámico:
Paso 1: Auditoría de Consistencia del Transporte
Antes de cualquier prueba funcional, verifique el contenido de los Transportes de Copias (TOC) o Solicitud de Trabajo utilizando SE01 y SE09. Confirme la co-dependencia: la aplicación BSP, el nodo ICF (transacción SICF), el servicio OData (/IWFND/MAINT_SERVICE), las asignaciones de Catálogo/Grupo de Fiori (/UI2/FLPD_CUST), y el rol PFCG deben estar ya sea en el mismo transporte o documentar la secuenciación. Use SCMP (Comparación de Vista/Tabla) para diferenciar las tablas de LPD_T (Datos del Launchpad) entre sistemas.
Paso 2: Invalidación de Caché de Metadatos
Ejecute /IWFND/CACHE_CLEANUP en el sistema Gateway para limpiar las cachés de Modelo y Metadatos. En el navegador, fuerce una recarga completa (Ctrl+F5) y agregue ?sap-ui-xx-noCache=true a la URL de inicio de SAPUI5. Verifique la pestaña de Red para la solicitud de $metadata; asegúrese de que la respuesta XML contenga los correctos EntitySets coincidiendo con la actual firma de RFC.
Paso 3: Búfer de Autorización de Desbloqueo
Utilice la transacción SU56 para eliminar el búfer de autorización actual del usuario. Ejecute PFUD (Ajuste de Datos Maestro del Usuario) con la opción "Comparar" para asegurar que el Perfil del rol PFCG esté actualizado. Ejecute SU53 inmediatamente después de un acceso fallido al mosaico para mostrar la última verificación de autorización fallida. Busque específicamente los objetos S_START (autorización de inicio genérica), S_IWSG y S_SERVICE.
Paso 4: Verificación de Resolución del Mapeo de Objetivos
Utilice la transacción /UI2/FLIA (Análisis de Intención del Launchpad de Fiori) para ingresar el Objeto Semántico y la Acción. Esto revela qué aplicación SAPUI5 (a través del ID del Componente) se ha resuelto, la ruta ICF, y si la entrada LPD_CST es válida. Si FLIA muestra el mapeo pero el usuario no puede verlo, el problema es PFCG (asignación de catálogo faltante). Si FLIA no muestra mapeo, el problema está en LPD_CUST o el transporte.
Paso 5: Trazado de Conectividad RFC
Active los registros de errores de Gateway a través de /IWFND/ERROR_LOG. Trace el destino RFC utilizando SM59 → Prueba de Conexión, luego SM50 (Vista de Procesos) para vigilar fallos de RFC cuando el servicio OData intenta alcanzar el backend. Verifique los fallos de autorización en SM21 (Registro del Sistema) para S_RFC o S_RFCACL.
Descripción del Problema
Durante un proyecto de actualización de S/4HANA 2022, la aplicación de SAP Fiori "Gestionar Requisiciones de Compra" funcionaba perfectamente en Desarrollo pero fallaba al lanzarse en Aseguramiento de Calidad con el error: "La aplicación no pudo abrirse porque el componente SAPUI5 ui.sscim.prereq no se pudo cargar." El equipo de Basis confirmó que todos los transportes se importaron correctamente con RC=0 (Código de Retorno cero). El repositorio SAPUI5 ABAP (SE80) mostró que la aplicación BSP ui.sscim.prereq estaba presente en QAS. El servicio OData C_PURCHASEREQ_SRV estaba activo en /IWFND/MAINT_SERVICE. Sin embargo, el mosaico apareció para los administradores pero no para los administrativos de compras, sugiriendo un problema de autorización, aunque los administradores también recibieron el error de carga al hacer clic en el mosaico.
Solución 1: Limpieza de Caché del Navegador y Reversión de Versión UI5
La hipótesis inicial era que QAS tenía una caché SAPUI5 corrupta o un desajuste de versión en el repositorio ABAP. El equipo borró las cachés del navegador para todos los usuarios y invalidó manualmente la caché del repositorio MIME usando /UI5/APP_INDEX_CALCULATE.
Pros: Esta es una solución rápida y no invasiva que a menudo resuelve problemas de carga de recursos SAPUI5 (404s en Component-preload.js). No requiere cambios de codificación en ABAP.
Contras: No resolvió el problema. El error persistió y, más críticamente, no explicó por qué el mosaico era invisible para los administrativos. Trató el síntoma (error de carga) sin diagnosticar por qué los metadatos estaban fallando en cargarse, posiblemente enmascarando un problema más profundo de configuración del servicio OData.
Solución 2: Regeneración Completa del Rol PFCG y Comparación de Usuarios
El equipo sospechaba que la asignación del Catálogo de Fiori en PFCG estaba faltando. Regeneraron todos los perfiles para los roles de compras y ejecutaron PFUD con la opción "Reconciliación completa" para asegurar que todos los usuarios recibieron las autorizaciones actualizadas.
Pros: Asegura que los Perfiles de Autorización (PROF_NAME en UST04) estén sincronizados con las definiciones de Rol. Esto resolvió el problema del "mosaico invisible" para los administrativos, ya que la asignación del grupo Catálogo estaba efectivamente faltante en la versión de rol QAS.
Contras: Aunque el mosaico se volvió visible, al hacer clic todavía resultaba en el error "el componente no pudo ser cargado". Este enfoque falló porque se centró puramente en la capa de autorización (PFCG) e ignoró la capa de mapeo del servicio OData a RFC. Los administradores que podían ver el mosaico aún no podían abrirlo, demostrando que el problema trascendía la autorización.
Solución 3: Validación Sistemática del Gateway y Nodo ICF (Enfoque Elegido)
La metodología elegida implicó verificar el estado de activación del servicio OData independientemente de la aplicación UI5. Usando la transacción /IWFND/GW_CLIENT, el equipo ejecutó una solicitud GET a C_PURCHASEREQ_SRV?sap-client=100. La solicitud devolvió HTTP 200, pero la carga útil XML mostró que los Metadatos eran de una versión almacenada en caché anterior a un reciente cambio de interfaz RFC. Posteriormente, la verificación de la transacción SICF (Mantener Servicios) reveló que el nodo ICF /sap/bc/ui5_ui5/sap/ui_sscim_prereq estaba activo en DEV pero inactivo en QAS (la importación había fallado silenciosamente debido a un objeto bloqueado). Finalmente, al verificar /IWFND/ERROR_LOG, se mostró que cuando la aplicación intentaba obtener $metadata, se encontró con un error de autorización en el mapeo de Alias de Sistema, que apuntaba a un destino SM59 obsoleto que había sido descontinuado después de la migración.
Por qué elegido: Este enfoque aisló las tres fallas simultáneas: (1) desincronización de cachés de OData entre DEV y QAS causando un desajuste de metadatos, (2) inactividad del nodo ICF impidiendo que los recursos SAPUI5 fueran servidos a través de HTTP, y (3) mala configuración del Alias de Sistema en QAS apuntando a un destino RFC que no existía. Proporcionó códigos de error específicos (ICF 403s vs OData 404s) en lugar de mensajes genéricos para los usuarios.
El Resultado
La ejecución de /IWFND/CACHE_CLEANUP refrescó los metadatos de OData para coincidir con la nueva firma de RFC. Activar el nodo ICF a través de SICF resolvió el error "el componente no pudo ser cargado" haciendo accesibles los archivos HTML y JS de la aplicación BSP. La corrección del Alias de Sistema en /IWFND/MAINT_SERVICE → Alias de Sistemas de SAP aseguró que el Gateway pudiera alcanzar el backend. Los administrativos de compras pudieron entonces ver y abrir la aplicación porque el rol PFCG (solucionado en la Solución 2) otorgaba acceso al mosaico que ahora funcionaba. El enfoque sistemático ahorró aproximadamente 8 horas de depuración de ABAP que se habrían desperdiciado en la suposición de que el código estaba defectuoso.
¿Cómo determinas de manera definitiva si un mosaico de Fiori faltante es causado por un Mapeo de Objetivo faltante (LPD_CUST) versus una asignación de Catálogo faltante en PFCG, dado que ambos resultan en la no visualización del mosaico?
Respuesta:
Un Mapeo de Objetivo faltante (configurado en LPD_CUST o el diseñador de CATÁLOGO de Fiori) significa que la combinación de Objeto Semántico y Acción no tiene una aplicación SAPUI5 asociada, pero el mosaico en sí podría seguir apareciendo si la asignación del Catálogo existe en PFCG. Al hacer clic se obtendría un error "El destino de navegación no pudo ser encontrado". Para verificar, use la transacción /UI2/FLIA (Análisis de Intención del Launchpad de Fiori). Ingrese el Objeto Semántico y la Acción; si FLIA devuelve "No se encontró ninguna aplicación para esta intención", el Mapeo de Objetivo está faltante o el nombre de la aplicación BSP en el mapeo es incorrecto.
Por otro lado, si FLIA muestra con éxito la aplicación SAPUI5 de destino y el ID del Componente, pero el mosaico falta en el launchpad del usuario, el problema está relacionado con PFCG. Verifique si el Catálogo que contiene el mosaico está asignado al Rol del usuario en PFCG (verifique la pestaña Menú), y asegúrese de que el Grupo (que organiza los mosaicos en la página de inicio del launchpad) también esté asignado. Además, verifique que el Objeto de Autorización S_START con el valor WEBGUI esté presente en el rastreo SU53 del usuario, ya que esto es requerido para lanzar cualquier aplicación Fiori, y a menudo se omite en las actualizaciones de roles de sistemas solo de SAP GUI.
¿Por qué podría un servicio OData probarse con éxito a través del Cliente de Gateway (/IWFND/GW_CLIENT) pero fallar con un 403 Prohibido al invocarse desde la aplicación SAPUI5 en el navegador?
Respuesta:
El Cliente de Gateway (/IWFND/GW_CLIENT) se ejecuta dentro del contexto de sesión de SAP GUI, utilizando la autenticación de SAP Logon y eludiendo las verificaciones de seguridad de los nodos de ICF sobre HTTP. La aplicación SAPUI5, sin embargo, dirige las solicitudes a través de la estructura de nodos ICF (/sap/bc/ui5_ui5/... o /sap/opu/odata/...).
Por lo tanto, un 403 en el navegador típicamente indica:
Inactividad del Nodo ICF: El nodo de servicio específico en SICF está inactivo en el cliente de destino, aunque el servicio OData en sí esté registrado en /IWFND/MAINT_SERVICE.
Autorización S_ICF: El usuario carece del objeto de autorización S_ICF con los valores de campo de ICF correctos (Nombre del Servicio, Host, etc.) para acceder a esa ruta HTTP específica. Verifique la transacción SU53 inmediatamente después de la falla.
Validación del Token CSRF: Las aplicaciones SAPUI5 requieren un token CSRF (Prevención de Falsificación de Solicitud en Sitios Cruzados) válido obtenido a través de una solicitud HEAD. Si los sistemas frontend y backend están mal configurados (p.ej., diferentes IDs de Sistema en un escenario de Servidor Frontend de Fiori), la validación del token falla con un 403, mientras que el GW_CLIENT (sin estado y agnóstico a CSRF) tiene éxito.
¿Cómo pruebas las condiciones de carrera en las actualizaciones de roles PFCG cuando múltiples solicitudes de transporte que contienen cambios de perfil de autorización se importan simultáneamente durante una ventana de liberación ajustada?
Respuesta:
Cuando se importan múltiples Solicitudes de Transporte que contienen roles PFCG de manera concurrente, la generación de Perfiles (PFCG → Generar Perfil) puede crear colisiones de bloqueo en las tablas USR10 o USR12, lo que lleva a búferes de autorización incompletos donde algunos usuarios reciben actualizaciones parciales de roles. Para probar esto:
Simulación de Importación Escalonada: En el sistema QAS, importe los transportes de Rol secuencialmente en lugar de simultáneamente. Documente los Códigos de Retorno (objetivo RC=0 o advertencias RC=4). Luego, restablezca el sistema e impórtelos simultáneamente. Compare los registros de Usuario Maestro (tabla UST04) entre los dos escenarios usando SE16 o consulte AGR_USERS para ver si las asignaciones de roles difieren.
Comparación de Rastro de Autorización: Utilice ST01 (Rastro de Autorización) para el mismo usuario antes y después de la importación simultánea. Capture los búferes de Verificación de Autorización. Si la importación secuencial muestra verificaciones exitosas para Z_CUSTOM_AUTH_OBJECT pero la importación simultánea muestra fallos, es probable que haya una condición de carrera en la generación de Perfiles.
Pruebas de Latencia PFUD: Inmediatamente después de la importación simultánea, ejecute SUIM → Usuario → Por Criterios de Selección Compleja y verifique si las versiones de Perfil (PROFN en USR10) coinciden con la versión de Rol en PFCG. Si no coinciden, el ajuste de Usuario Maestro (PFUD) fue omitido o falló silenciosamente. La solución es imponer una ejecución obligatoria de PFUD con verificación de RSUSR200 (Análisis de Asignaciones de Usuario-Rol) antes de la aprobación.