SAP Fiori Elements

SAP Fiori elements traslada las decisiones de UI del código a los metadatos:

1. Un servicio OData expone las entidades de negocio, por ejemplo los pedidos de compra y sus posiciones.
2. Las anotaciones describen cómo debe presentarlas la UI: UI.SelectionFields para los campos de filtro, UI.LineItem para las columnas de tabla, UI.HeaderInfo para los títulos de objeto, UI.Facets para las secciones de la object page.
3. El app descriptor (manifest.json) selecciona una plantilla de floorplan para cada página y define opciones como la carga inicial o la edición masiva.
4. En tiempo de ejecución, el framework lee los metadatos, las anotaciones y el descriptor y construye las páginas, incluidos la barra de filtros, las variantes, las tablas, los formularios, los mensajes y la navegación.
5. Cuando la página generada no basta, los desarrolladores añaden extensiones en lugar de reescribir la página.

Por tanto, el trabajo principal del desarrollador está en el servicio y sus anotaciones, no en JavaScript. SAP Fiori elements convierte un servicio bien anotado en una aplicación que funciona, y uno mal anotado en una aplicación deficiente.

OData V4 añade building blocks y custom pages, de modo que los desarrolladores pueden combinar elementos estándar con su propio código SAPUI5 dentro de la misma aplicación. El list report combinado con la object page es la combinación clásica, a menudo abreviada como LROP. En SAP Fiori elements, elegir un floorplan significa elegir un patrón de interacción, no una plantilla visual.

SAP recomienda SAP Fiori elements para OData V4 en las nuevas aplicaciones e indica que la variante para OData V2 sigue teniendo soporte completo. En la práctica, la elección depende de tres factores:

• Back-end: los service bindings de RAP pueden publicar un servicio de UI como OData V2 o V4, y CAP sirve OData V4 de forma predeterminada. Los servicios creados en SEGW suelen ser OData V2.
• Necesidades de extensión: los building blocks y el flexible programming model solo están disponibles con OData V4.
• Aplicaciones existentes: una aplicación que funciona en V2 no necesita migración para seguir funcionando; los ajustes de configuración difieren entre ambas, por ejemplo initialLoad en V4 frente a loadDataOnAppLaunch en V2.

Para una nueva aplicación personalizada sobre un back-end actual de SAP S/4HANA o SAP BTP, OData V4 es la opción predeterminada en SAP Fiori elements, y V2 es la opción pragmática cuando el servicio ya existe.

SAP Fiori elements encaja cuando la tarea sigue un patrón estándar: buscar en una lista, abrir un objeto, editarlo, ejecutar acciones. El framework proporciona barras de filtros, gestión de variantes, tablas, drafts, mensajes, accesibilidad y soporte de traducción sin código personalizado, y SAP mantiene esas funciones actualizadas en las distintas releases de SAPUI5.

SAPUI5 freestyle encaja cuando la propia interacción es poco habitual: un tablero de planificación, un flujo guiado de escaneo, un diseño muy visual o datos de fuentes que no son OData. El código freestyle da control total y también la responsabilidad total del mantenimiento.

Las propias directrices de SAP tratan ambos enfoques como combinables y no excluyentes: empezar con SAP Fiori elements, usar building blocks y escribir código freestyle solo para las carencias. Una prueba útil para decidir es si las partes interesadas pueden aceptar el diseño del floorplan al menos para las pantallas principales. SAP Fiori elements es la mejor opción siempre que el requisito sea un business object y no una interacción a medida.

Las opciones de extensión dependen de quién es el propietario de la aplicación:

• Su propia aplicación: los puntos de extensión permiten a los desarrolladores añadir columnas, acciones, secciones, facets de cabecera y filtros personalizados; con OData V4, el flexible programming model añade building blocks y custom pages.
• Una aplicación entregada por SAP: los adaptation projects, creados con SAP Fiori tools, modifican o amplían la aplicación sin modificar el código de SAP; la adaptación key user permite a los key users reorganizar u ocultar campos en tiempo de ejecución.
• El lado de los datos: un campo nuevo suele empezar en el servicio y sus anotaciones, no en la UI.

La disponibilidad varía según la edición: en SAP S/4HANA Cloud Public Edition, compruebe cuáles de estas vías admite SAP para la aplicación en cuestión. Cada extensión de una aplicación SAP Fiori elements se convierte en código o configuración que alguien debe mantener a lo largo de las actualizaciones.

1. Luchar contra el floorplan. Grandes cantidades de código personalizado para forzar un diseño no estándar anulan la ventaja de mantenimiento; llegados a ese punto, SAPUI5 freestyle suele ser más honesto.
2. Tratarlo como no-code. Las anotaciones son código en otra forma; necesitan revisión, control de versiones y pruebas.
3. Ignorar la gestión de draft. Los escenarios de edición sin un servicio habilitado para draft pierden el comportamiento de reanudación, bloqueo y validación que los usuarios esperan.
4. No revisar los valores predeterminados. La carga inicial, la edición masiva y los tipos de tabla tienen valores predeterminados que pueden cargar demasiados datos o demasiado pocos; defínalos de forma deliberada.
5. Anotar en dos sitios. Las anotaciones pueden estar en el CDS del back-end y en archivos de anotaciones locales; los archivos locales prevalecen sobre los metadatos del servicio, y gana el último archivo listado en manifest.json, por lo que los duplicados hacen que el comportamiento sea difícil de rastrear.

La mayoría de los problemas de SAP Fiori elements son problemas de diseño del servicio y de las anotaciones que solo se hacen visibles en la UI.