Flexible Programming Model

El flexible programming model no es un framework aparte, sino un conjunto de opciones que SAP Fiori elements para OData V4 ofrece para ir más allá de los floorplans mientras el framework sigue al mando:

1. Extension points en list reports y object pages admiten secciones, columnas y acciones personalizadas escritas en SAPUI5.
2. Building blocks colocan elementos basados en metadatos, como una tabla, una barra de filtros o un campo, donde haga falta.
3. Controller extensions y la ExtensionAPI permiten que el código propio reaccione a eventos del framework, como el guardado o la navegación.
4. Custom pages añaden al enrutamiento de la app una página con su propia vista XML. La página se ejecuta sobre el runtime de SAP Fiori elements (componente sap.fe.core.fpm), con el contexto de binding de OData, la navegación a las páginas estándar y el soporte de building blocks.

Por tanto, el flexible programming model es una escala gradual entre la UI generada y la UI escrita a mano, que se decide página a página y sección a sección.

Los building blocks son elementos de UI reutilizables y basados en anotaciones de SAP Fiori elements para OData V4, los mismos elementos que usa el framework para montar sus floorplans.

• No son controles, sino plantillas. Un building block es un conjunto de instrucciones de templating. En tiempo de ejecución genera los controles adecuados a los datos vinculados: un texto para una propiedad de tipo string, un selector de fecha para una fecha.
• Se configuran en tres lugares. Las anotaciones del servicio definen el comportamiento por defecto, los atributos XML en línea lo afinan y el manifest prevalece sobre ambos cuando hay conflicto.
• Se referencian por ruta de metadatos. Un building block apunta a un entity set, una propiedad o una anotación, en lugar de vincular columnas a mano.
• Ejemplos: Table, FilterBar, Chart, Field, Share y Page.

Como leen las mismas anotaciones que los floorplans, los building blocks heredan la gestión de variantes, la personalización y el reconocimiento del draft. Los building blocks son la razón por la que una custom page puede seguir pareciendo y comportándose como una página estándar de SAP Fiori elements.

La recomendación de SAP es usar tanto SAP Fiori elements como sea posible y tanto SAPUI5 freestyle como sea necesario:

Las cuatro opciones pueden convivir en una misma app: un cockpit de proveedores en Alder Manufacturing podría combinar un gráfico personalizado con un building block Table estándar y, después, abrir una object page estándar.

Prueba de decisión: si una página que piensa construir en freestyle contiene una barra de filtros y una tabla estándar, pruebe primero una custom page con building blocks. El flexible programming model es la elección correcta cuando el diseño es personalizado pero las piezas son estándar.

• Sin elección rígida. Los equipos no tienen que abandonar SAP Fiori elements en cuanto un requisito queda fuera de un floorplan.
• Comportamiento estándar sin coste adicional. Los building blocks aportan desde el framework el filtrado, las variantes, los mensajes, la gestión de draft y la accesibilidad.
• Las anotaciones siguen siendo la fuente de verdad. Una etiqueta modificada en las anotaciones del servicio actualiza por igual las páginas de floorplan y las custom pages.
• Superficie de extensión soportada. Las controller extensions y la ExtensionAPI ofrecen al código propio puntos de enganche documentados que resultan más fáciles de mantener estables entre actualizaciones de SAPUI5.

Para las apps OData V4, el flexible programming model es la forma más directa de añadir UI personalizada sin renunciar a lo que SAP Fiori elements ya ofrece.

• Solo OData V4. Los building blocks y las custom pages pertenecen a SAP Fiori elements para OData V4. Una app OData V2 conserva los extension points de V2; adoptar el modelo implica migrar la app y el servicio a V4.
• Depende de la versión. Los building blocks llegan release a release, así que una app solo puede usar lo que ofrece la versión de SAPUI5 del sistema de destino; la referencia de la API indica el release en el que cada building block pasó a estar disponible.
• No todas las funciones del floorplan se trasladan. SAP documenta, por ejemplo, que crear una card para la sección Insights de My Home no está disponible cuando el building block de tabla se encuentra en una custom page o en una sección personalizada.
• El uso en freestyle tiene requisitos previos. Los building blocks pueden aparecer en apps SAPUI5 freestyle, pero la configuración que necesita cada building block debe comprobarse en la documentación de SAPUI5 del release en uso.
• SAP S/4HANA Cloud Public Edition sigue sus propias reglas de extensibilidad para las apps construidas por el cliente; consulte la documentación de esa edición antes de planificar una.

El flexible programming model amplía lo que SAP Fiori elements puede hacer; no elimina la dependencia de OData V4 ni de unas anotaciones bien diseñadas.

1. Reconstruir a mano elementos estándar. Una tabla personalizada con su propia lógica de filtrado duplica los building blocks Table y FilterBar. Configure el building block en su lugar.
2. Configurar en tres lugares. Cuando las anotaciones, los atributos XML y la configuración del manifest describen la misma tabla, el manifest prevalece y los demás parecen no funcionar. Elija un solo lugar para cada ajuste.
3. Cargar fragments de forma incorrecta. SAP exige que los fragments cargados dinámicamente que contienen building blocks se carguen mediante el método loadFragment de la ExtensionAPI.
4. Corregir la UI en lugar del servicio. Una etiqueta que falta suele ser un problema de anotación; parchearla en código propio la oculta de todas las demás páginas.
5. Ignorar la versión de SAPUI5 de producción. Los building blocks probados en el release más reciente pueden no existir en el front-end server.

La mayoría de los problemas del flexible programming model son errores de configuración o de reparto entre capas, no límites del propio modelo.