Aplicación freestyle SAPUI5

Una aplicación freestyle SAPUI5 utiliza la estructura estándar de aplicación SAPUI5, con todas las pantallas escritas por el equipo de desarrollo:

1. Componente y app descriptor: el componente inicia la app; el manifest.json declara las fuentes de datos, los modelos, las rutas y los inbounds de navegación.
2. Vistas: normalmente vistas XML que colocan controles SAPUI5 como tablas, formularios y gráficos.
3. Controladores: código JavaScript o TypeScript para eventos, mensajes de validación, diálogos y navegación.
4. Modelos: modelos OData para los datos del back-end, modelos JSON para el estado local y modelos de recursos para los textos.
5. Integración con el launchpad: un target mapping o un inbound hace que la app sea accesible desde un tile o un enlace.

SAP Fiori tools sigue generando el esqueleto del proyecto, pero SAP marca ahora sus plantillas freestyle SAPUI5 como obsoletas y recomienda partir de la custom page de SAP Fiori elements para OData V4, que sigue dejando el contenido de la página en manos del equipo. Nada en la UI se deriva de anotaciones salvo que el equipo añada building blocks deliberadamente. Por tanto, una aplicación freestyle SAPUI5 se define por quién escribe la UI (el equipo), no por qué framework la ejecuta.

La guía de SAP para desarrolladores recomienda usar SAP Fiori elements tanto como sea posible y código freestyle tanto como sea necesario. El desarrollo freestyle es el punto de partida adecuado cuando se cumple al menos una de estas condiciones:

• la interacción no corresponde a ningún floorplan, por ejemplo una pantalla de escaneo guiado o un tablero de planificación;
• la app debe trabajar con fuentes de datos que no son servicios OData anotados, o con sistemas externos;
• el equipo necesita un control detallado sobre el renderizado y el rendimiento;
• el diseño se aparta deliberadamente de los patrones estándar para un grupo de usuarios concreto.

Ejemplo: Alder Manufacturing quiere que el personal de almacén confirme las entregas de Bright Freight escaneando palés en una tableta, con botones grandes y un flujo de un solo paso. Ningún floorplan se ajusta a esa interacción, así que una página freestyle está justificada. En cambio, una lista de entregas abiertas para los supervisores encaja en un list report. La decisión de crear una aplicación freestyle SAPUI5 debe tomarse pantalla por pantalla, no por proyecto.

• Control total del diseño: es posible cualquier diseño, interacción o visualización que puedan expresar los controles SAPUI5.
• Cualquier fuente de datos: la app puede combinar servicios OData, API REST y datos locales sin necesidad de anotaciones.
• El mismo lenguaje visual: como utiliza controles y temas SAPUI5, una app freestyle bien diseñada tiene el mismo aspecto que el resto de SAP Fiori.
• Combinable: las páginas freestyle y las páginas de SAP Fiori elements pueden convivir en la misma app, y los building blocks de SAP Fiori elements para OData V4 pueden combinarse en diseños personalizados.
• Ampliable por terceros: SAPUI5 flexibility permite adaptar tanto apps freestyle como apps de SAP Fiori elements, siempre que la app active el flag flexEnabled y use IDs de control estables.

Una aplicación freestyle SAPUI5 es la opción que elimina el techo de lo que puede hacer la interfaz de usuario.

• La responsabilidad sigue siendo del cliente. La guía de SAP sitúa el mantenimiento y la propiedad del código de las apps freestyle principalmente en el cliente o el partner, a diferencia de SAP Fiori elements, donde el framework asume una parte mayor.
• La coherencia es una tarea de diseño. El cumplimiento de SAP Fiori es automático en los floorplans, pero en las pantallas freestyle hay que construirlo y revisarlo.
• La evolución del framework es manual. Las nuevas funciones de los floorplans llegan a las apps de SAP Fiori elements a través del framework; las apps freestyle solo cambian cuando alguien las cambia, también cuando SAPUI5 declara obsoletas algunas API.
• Los conocimientos son específicos. El equipo necesita conocimientos de desarrollo web y del framework SAPUI5, no solo de OData y anotaciones.
• La lógica puede desplazarse al navegador. Las reglas programadas en un controlador no protegen los datos escritos a través de otros canales.

Estos límites son el precio de la flexibilidad: mantener en buen estado una aplicación freestyle SAPUI5 cuesta más a lo largo de su vida útil.

SAP describe tres puntos de partida, y una misma app puede combinar los tres:

La opción intermedia forma parte del flexible programming model, que permite a los desarrolladores combinar building blocks basados en metadatos con su propio código. Para los equipos que optan por freestyle por costumbre, suele ser el mejor compromiso. Elegir entre freestyle y SAP Fiori elements rara vez es una cuestión de todo o nada; el flexible programming model la convierte en una decisión página por página.

1. Elegir freestyle por costumbre. Revise primero los floorplans; recurra a freestyle solo donde no encajen.
2. Ningún responsable designado tras el go-live. Una queja frecuente en las comunidades de profesionales son las apps personalizadas que nadie mantiene una vez que el equipo del proyecto se marcha. Asigne la responsabilidad antes del despliegue.
3. Desarrollar con una versión de SAPUI5 más reciente que la de producción. Pruebe con la versión del front-end server de destino.
4. Reglas de negocio solo en el controlador. Mantenga también las validaciones en el servicio del back-end.
5. IDs de control inestables. SAPUI5 flexibility identifica los controles por IDs estables, por lo que los IDs generados socavan la adaptación por key users y hacen frágiles las pruebas automatizadas.

La mayoría de los problemas de las apps freestyle SAPUI5 aparecen meses después del go-live, y por eso la responsabilidad importa tanto como la calidad del código.