Adaptación de UI (Adapt UI)

La adaptación de UI nunca edita el código de la app. La flexibilidad de SAPUI5 registra cada cambio como un pequeño delta semántico, por ejemplo "campo Supplier Rating movido al grupo Delivery", vinculado al ID estable del control, y lo almacena en el repositorio por capas.

En tiempo de ejecución, la app carga sus vistas originales y aplica en orden los deltas almacenados de cada capa:

Como los cambios hacen referencia a IDs estables y no a posiciones en la pantalla, sobreviven a las actualizaciones de la app mientras los controles referenciados sigan existiendo. Por lo tanto, la adaptación de UI es una capa de cambios registrados sobre una app intacta.

• Personalización (usuarios finales). Los usuarios ajustan tablas, filtros y vistas para sí mismos y pueden compartir vistas como públicas. Nada cambia para los demás usuarios, salvo que elijan una vista compartida.
• Adaptación por key user (key users). Desde el menú de usuario, Adapt UI abre un modo WYSIWYG con arrastrar y soltar y menús contextuales. Los key users reorganizan, renombran, eliminan o añaden campos y grupos para todos, y pueden publicar el resultado como una app variant independiente. En SAP Fiori elements para OData V4, los key users también pueden ajustar las variantes del list report, mover o renombrar botones, reorganizar las secciones de la object page e incrustar contenido.
• Adaptación por desarrolladores (desarrolladores). Un proyecto de adaptación en SAP Business Application Studio, creado con SAP Fiori tools, añade fragmentos en puntos de extensión, extensiones de controlador o cambios en el descriptor. El resultado es una app variant con su propio ID que hace referencia a la original.

Los tres niveles comparten un mismo mecanismo, pero difieren en alcance: la adaptación de UI por key users cambia la app para todos, la personalización la cambia para un usuario y la adaptación por desarrolladores puede cambiar el comportamiento.

• Sin código y sin modificaciones. Los key users cambian los diseños sin desarrolladores, y la app original de SAP permanece intacta.
• Segura ante actualizaciones por diseño. Los cambios son deltas sobre IDs estables, guardados en su propia capa.
• Red de seguridad integrada. La herramienta avisa antes de cambios arriesgados, como eliminar un campo obligatorio, y los cambios pueden deshacerse o restablecerse a la app original.
• Borradores y versiones. A partir de ABAP Platform 2022, los key users pueden guardar borradores, conservar varias versiones, revertir y publicar una versión elegida.
• App variants. Una sola app entregada puede servir a equipos distintos, por ejemplo una app variant de pedidos de compra con menos campos para los compradores de planta de Alder Manufacturing.

Para el ajuste a nivel de pantalla, la adaptación de UI es la herramienta más ligera de la gama de extensibilidad de SAP S/4HANA.

• Solo apps habilitadas para ello. Una app necesita controles compatibles e IDs estables; las apps que construyen su UI dinámicamente no pueden adaptarse.
• Solo lo que ya existe. La adaptación de UI puede mostrar un campo que el servicio ya proporciona, pero no puede crear un campo, una comprobación ni un cálculo nuevos. Los campos personalizados provienen primero de la extensibilidad key user.
• Diseño, no lógica. Los valores predeterminados, las validaciones y las reglas de proceso quedan fuera del alcance; algunas acciones estándar, como editar, guardar y eliminar, están excluidas de la adaptación de botones en SAP Fiori elements.
• Solo escritorio. La adaptación por key user requiere un navegador de escritorio y un tamaño de pantalla mínimo.
• Las UI clásicas son distintas. Las transacciones de SAP GUI se adaptan con otras herramientas; SAP S/4HANA Cloud Public Edition ofrece adaptación de UI para aplicaciones clásicas basada en SAP Screen Personas.
• Prevalece sobre la personalización. Los ajustes del key user pueden prevalecer sobre los del usuario final, por lo que los usuarios pueden tener que volver a aplicar los suyos.

Estos límites mantienen segura la adaptación de UI: remodela las pantallas sin cambiar lo que hace el sistema.

La recomendación de SAP es adaptar en un sistema de prueba o de desarrollo y llevar el resultado a producción, porque los cambios hechos directamente en producción pueden entrar en conflicto con los transportados.

• SAP S/4HANA on-premise y Private Edition: cuando el key user publica una versión, el sistema solicita una orden de transporte, que un administrador libera. Por lo tanto, los key users necesitan autorizaciones de transporte además del rol de key user.
• SAP S/4HANA Cloud Public Edition: la publicación no solicita un transporte; los cambios se recopilan para su exportación mediante una software collection.
• Las app variants siguen el mismo camino: al publicarlas se añaden a una orden de transporte o a una software collection.

Criterio de decisión: si más de una persona adapta la misma app, acuerden un responsable por app, porque solo un key user debe adaptar una app a la vez. La adaptación de UI es configuración con su propio camino de transporte y merece la misma disciplina de release que cualquier cambio.

Compruebe estas causas en orden:

1. Falta el rol. El usuario no tiene SAP_UI_FLEX_KEY_USER ni una copia de este en PFCG.
2. App no habilitada. La app no admite la adaptación por key user, por ejemplo porque carece de IDs estables.
3. El sistema no lo admite. La app se ejecuta en un back-end o una plataforma donde la adaptación de UI no está disponible.
4. Dispositivo o página incorrectos. El usuario está en un teléfono o una tableta, o no está en la página actual del launchpad.

La documentación de SAP cita las tres primeras como los motivos por los que Adapt UI no aparece. Una entrada de Adapt UI ausente es casi siempre una cuestión de rol o de habilitación de la app, no un defecto del launchpad.