Fiori elements o freestyle: cómo elegir y los conceptos del front end de SAP
Fiori es diseño y SAPUI5 es tecnología. Las diferencias entre Fiori elements, freestyle y el punto intermedio, el Flexible Programming Model; OData, RAP y anotaciones; el launchpad; y cómo extender una app estándar sin modificación.
En un proyecto SAP, "hacerlo en Fiori" puede significar cosas muy distintas: una app generada a partir de anotaciones en pocas horas, una app escrita desde cero en JavaScript a lo largo de semanas, o solo una transacción antigua abierta desde un tile del launchpad. Conocer la diferencia ayuda a presupuestar, a elegir el camino y a no crear, sin darse cuenta, una modificación en una app de SAP.
Fiori es el diseño, SAPUI5 es la tecnología
SAP Fiori es el sistema de diseño de SAP: directrices, patrones de página, componentes visuales y temas. El tema actual se llama Horizon. Fiori no es un lenguaje ni un framework.
SAPUI5 es el framework JavaScript que SAP usa para construir las apps Fiori. Viene dentro de los productos SAP: en S/4HANA, como el componente SAP_UI del servidor de front end, y en SAP BTP. Existe también OpenUI5, la versión de código abierto (licencia Apache 2.0). Los dos tienen el mismo núcleo, pero OpenUI5 no incluye las bibliotecas propietarias, y entre ellas está Fiori elements completo.
Cada release de S/4HANA tiene su versión de SAPUI5 con mantenimiento prolongado: 1.108 en 2022, 1.120 en 2023 y 1.136 en 2025. Una app tiene que funcionar en la versión del sistema del cliente, y no en la versión más reciente publicada en internet.
Fiori elements: la pantalla que nace de las anotaciones
En Fiori elements, el equipo no escribe las pantallas. Describe lo que quiere mostrar en anotaciones en el servicio OData (qué campos aparecen en la lista, cuáles se convierten en filtro, cómo se divide la página de detalle), y el framework arma la pantalla al abrir la app, siguiendo un floorplan, un modelo de página ya listo:
| Floorplan | Para qué |
|---|---|
| List Report + Object Page | Lista con filtros y página de detalle: el caso más común |
| Worklist | Lista de tareas por tratar, sin barra de filtros |
| Analytical List Page | Lista con gráficos y análisis |
| Overview Page | Panel de tarjetas con indicadores y listas cortas |
| Form Entry Object Page | Formulario de entrada de datos, sin la lista previa |
La ventaja es que el comportamiento estándar viene listo: filtros, variantes guardadas, borrador (draft), exportación a hoja de cálculo, diseño adaptable y accesibilidad. Las mejoras de diseño llegan con el upgrade de SAPUI5, sin retrabajo en la app. El mantenimiento queda, en palabras de SAP, "more on SAP side".
Fiori elements existe en dos generaciones: la de OData V2, todavía soportada y presente en muchas apps estándar, y la de OData V4, que SAP recomienda para todo lo nuevo.
Freestyle: todo escrito por el equipo
En freestyle, el equipo escribe las pantallas (views en XML) y la lógica (controllers en JavaScript o TypeScript) con los controles de SAPUI5. El control es total: cualquier diseño, cualquier fuente de datos, incluso fuera de OData. A cambio, cada comportamiento que Fiori elements daría listo tiene que escribirse, probarse y mantenerse, y el mantenimiento queda del lado del cliente o del socio.
El punto intermedio: el Flexible Programming Model
Desde SAPUI5 1.94, Fiori elements para OData V4 cuenta con el Flexible Programming Model, que da a la app estándar las libertades de freestyle en los puntos donde las necesita. Son tres recursos:
- puntos de extensión: columnas, acciones, secciones o páginas enteras propias, declaradas en el
manifest.json; - building blocks: las piezas de Fiori elements (tabla, barra de filtros, campo, formulario, gráfico) usadas dentro de una página propia, todavía configuradas por las anotaciones;
- controller extensions: código propio que reacciona a los eventos del framework.
Con una custom page, es posible armar una página fuera de los floorplans usando building blocks y seguir dentro de Fiori elements, con borrador, filtros y personalización listos. Los building blocks son los sucesores de los antiguos smart controls, que solo funcionan con OData V2.
Cómo elegir
SAP resume la recomendación en una frase: "as much SAP Fiori elements as possible and as much freestyle SAPUI5 as needed".
| Situación | Camino |
|---|---|
| La app cabe en un floorplan, aun con pequeños ajustes de diseño | Fiori elements |
| Cabe casi entera, pero una parte necesita diseño o comportamiento propio | Fiori elements V4 con puntos de extensión o custom page |
| Proceso muy específico, fuente de datos fuera de OData, interacción que ningún floorplan admite | Freestyle |
El error más común, según el propio equipo de SAP, es descartar el floorplan demasiado pronto: requisitos que cabrían en un List Report con pequeñas concesiones terminan en freestyle, y se pierde el ahorro de desarrollo y de mantenimiento. También ocurre lo contrario: forzar en Fiori elements una app que se aleja mucho del estándar cuesta más que escribirla en freestyle.
De dónde vienen los datos: OData, RAP y anotaciones
Las apps Fiori leen y graban datos mediante servicios OData. En S/4HANA, el camino actual para crear esos servicios es RAP (ABAP RESTful Application Programming Model):
- las CDS views definen los datos;
- la service definition indica qué entidades expone el servicio;
- el service binding publica el servicio en un protocolo, OData V2 o V4, para uso desde una interfaz o como API.
Los caminos anteriores todavía existen en muchos sistemas y son legado para el desarrollo nuevo:
| Camino | Situación |
|---|---|
Gateway Service Builder (transacción SEGW) |
Legado; RAP es el sucesor |
CDS con @OData.publish: true |
Legado; genera solo OData V2 |
| Service definition y service binding (RAP) | El camino recomendado; OData V2 o V4 |
Las anotaciones que lee Fiori elements pueden estar en dos lugares:
- en el backend, en la propia CDS o en una metadata extension (un archivo de anotaciones separado de la view). Valen para toda app que use el servicio;
- en la app, como anotación local. Valen solo para esa app y se superponen a las del backend, lo que es útil cuando el servicio no es propio.
Dónde aparece la app: el launchpad
En S/4HANA, las apps se abren desde el SAP Fiori launchpad. Cada app aparece como un tile; los tiles se agrupan en catálogos, que se asignan a los roles de los usuarios. El diseño actual organiza la pantalla inicial en espacios y páginas; la home page antigua, basada en grupos, está descontinuada. En SAP BTP, el papel de punto de entrada corresponde a SAP Build Work Zone, que puede reunir apps de S/4HANA, apps propias y de terceros.
El launchpad abre también transacciones de SAP GUI (mediante SAP GUI for HTML) y aplicaciones Web Dynpro, con el tema visual de Fiori. Aparecen como tiles, pero no son apps Fiori: por debajo, siguen siendo la tecnología clásica. La Fiori Apps Reference Library de SAP muestra, para cada app, el tipo de tecnología, el ID y todo lo que hay que activar para usarla.
Extender una app estándar sin modificación
Una app Fiori de SAP es un objeto de SAP en el sistema. Cambiar su código directamente es una modificación, con el mismo riesgo de upgrade que cualquier otra modificación. Los caminos sin modificación son:
| Camino | Quién lo hace | Qué permite |
|---|---|---|
| Adaptación por el key user (Adapt UI) | Usuario clave, en la propia pantalla, sin código | Mover, ocultar y renombrar campos y secciones, crear variantes |
| Adaptation project | Desarrollador, en SAP Fiori tools | Una variante de la app con ID propio: campos, fragmentos de pantalla, código de extensión, anotaciones locales, otro servicio |
| App propia sobre el mismo servicio | Desarrollador | Una app nueva, cuando la variante no alcanza |
Las dos primeras usan SAPUI5 flexibility, que SAP describe como "modification-free": la app original no cambia, y los ajustes se aplican sobre ella cuando se abre la pantalla. Desde S/4HANA 1909, SAP indica el adaptation project como la forma de extender sus apps; el antiguo extension project quedó solo por compatibilidad.
Aun sin modificación, la extensión tiene reglas para sobrevivir al upgrade: usar solo controles con ID estable, no llamar a métodos privados de la app de SAP y acompañar las versiones nuevas de la app base. Existe un check de ATC (UI5_BASE_APP_VERS) que avisa cuando la app base de un adaptation project se actualizó y hay que revisar la variante.
Fiori y Clean Core
En la clasificación de tecnologías que SAP publica para Clean Core (nota 3578329), el desarrollo Fiori con RAP y service binding es nivel A. Los servicios creados en el Gateway Service Builder y las aplicaciones Web Dynpro son nivel B, y SAP Screen Personas sobre Web Dynpro y SAP GUI es nivel D. Los niveles se explican en Qué es Clean Core y por qué se convirtió en prioridad.
Un cuidado con la sigla: en la misma nota, "FPM" aparece junto a Web Dynpro y se refiere al Floorplan Manager, una tecnología clásica de Web Dynpro. No tiene relación con el Flexible Programming Model de Fiori elements.
Una app Fiori en RAP sobre CDS liberadas es el camino natural para sacar una pantalla clásica del nivel B: el motivo por el que un programa con pantalla no pasa del B está en Por qué un programa con pantalla clásica se queda en el nivel B, y lo que cambia en el ABAP del lado del servidor, en ABAP Cloud: qué cambia respecto al ABAP clásico.
Confusiones comunes
| Idea común | Lo que vale |
|---|---|
| "Fiori es lo mismo que UI5" | Fiori es el diseño; SAPUI5 es la tecnología de referencia. El tema Fiori también se aplica a SAP GUI for HTML y a Web Dynpro |
| "Una app en el launchpad es una app Fiori" | El launchpad abre también transacciones SAP GUI, Web Dynpro y enlaces. El tile no dice cuál es la tecnología |
| "Fiori elements no se puede personalizar" | Hay adaptación por el key user, puntos de extensión, building blocks, código de extensión y custom pages. El límite real es alejarse mucho del floorplan |
| "Freestyle siempre es más caro" | No siempre: cuando el requisito exige mucha extensión, freestyle puede resultar más simple. Pero para una app de negocio estándar, Fiori elements cuesta menos de hacer y de mantener |
| "OpenUI5 tiene Fiori elements" | No: las bibliotecas de Fiori elements existen solo en SAPUI5 |
| "Los smart controls funcionan con OData V4" | No: en V4, el equivalente son los building blocks |
Fuentes
- SAPUI5 Demo Kit (ui5.sap.com): SAPUI5 vs. OpenUI5, Developing Apps with SAP Fiori Elements, Developing Apps with Modern Concepts: Guidance for Developers, Standard Floorplans, Building Blocks, OData V4 Model, SAPUI5 Flexibility: Adapting UIs Made Easy, Extending Delivered Apps Using Adaptation Projects y Extending Apps.
- SAP, SAP Design System (SAP Fiori for Web).
- SAP Help: ABAP RESTful Application Programming Model, Service Binding, ABAP CDS – Metadata Extensions y la guía del SAP Fiori Launchpad.
- SAP Fiori tools (documentación en GitHub SAP-docs/btp-fiori-tools): Capabilities Overview, Supported Floorplans, Upgrade Safe Compatibility Rules y Check Whether Your Adaptation Project Is Up-To-Date with Base App Upgrades.
- Stefanie Hager (SAP), Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4, SAP Community, 2021.
- Peter Spielvogel (SAP), How to create an SAP Fiori app using SAP Fiori elements, SAPUI5 freestyle, or a mix of both, SAP Community, 2022.
- SAP Fiori Apps Reference Library, sección de extensibilidad de las fichas de las apps.
- Nota SAP 3578329 (clasificación de tecnologías para Clean Core).