Capítulo 7: Consumo de Servicios OData en SAPUI5/FioriPage 1

Mientras que el capítulo anterior se centró en la creación de servicios OData en el backend de SAP, este capítulo cambia el enfoque hacia el frontend, explorando cómo las aplicaciones SAPUI5 y SAP Fiori consumen estos servicios para mostrar datos y permitir la interacción del usuario. SAPUI5, el framework de UI HTML5 de SAP, proporciona modelos de datos específicos para facilitar la integración con servicios OData.

El Rol de OData en SAP Fiori y SAPUI5

OData es el protocolo estándar y preferido para la comunicación entre las aplicaciones SAP Fiori/SAPUI5 y los sistemas backend de SAP (como SAP Gateway que expone datos de S/4HANA o Business Suite).11 Las aplicaciones Fiori dependen en gran medida de los servicios OData para:

• Recuperar Datos: Obtener datos de negocio para mostrarlos en listas, tablas, formularios, gráficos, etc..91

• Actualizar Datos: Enviar cambios realizados por el usuario (creaciones, modificaciones, eliminaciones) de vuelta al backend.91

• Invocar Lógica de Negocio: Ejecutar acciones o funciones definidas en el servicio OData.70

• Habilitar Características de UI: Utilizar metadatos y anotaciones OData para impulsar características como ayudas de búsqueda, validaciones y la generación automática de UIs con Fiori Elements.11

La estandarización que ofrece OData simplifica enormemente el desarrollo de frontend, ya que proporciona una interfaz de datos consistente y predecible.11

Modelos OData en SAPUI5

SAPUI5 proporciona clases de modelo específicas para interactuar con servicios OData. Un modelo en SAPUI5 actúa como un contenedor para los datos de la aplicación y proporciona mecanismos para el enlace de datos (data binding) a los controles de la interfaz de usuario. Los dos modelos principales para OData son:

1. sap.ui.model.odata.v2.ODataModel: Diseñado para consumir servicios OData Versión 2.0.55 Ha sido ampliamente utilizado y sigue siendo relevante para muchos servicios existentes.

2. sap.ui.model.odata.v4.ODataModel: Diseñado para consumir servicios OData Versión 4.0.11 Es el modelo recomendado para nuevos desarrollos que utilizan OData V4, ofreciendo una mejor alineación con las características del protocolo V4 y mejoras potenciales.

Ambos son modelos del lado del servidor (server-side models), lo que significa que los datos completos residen en el servidor, y el cliente solo conoce los datos que ha solicitado explícitamente (ej. la página actual de una tabla).55 Operaciones como el filtrado y la ordenación se delegan al servidor a través de las opciones de consulta OData.55

Consumiendo OData V2 con sap.ui.model.odata.v2.ODataModel

Este modelo es la opción estándar para interactuar con los numerosos servicios OData V2 disponibles en el ecosistema SAP.

Instanciación y Configuración

Se crea una instancia del modelo, típicamente en el archivo manifest.json (descriptivo de la aplicación) o programáticamente en el controlador.

• En manifest.json (Recomendado): JSON "sap.app": { "dataSources": { "mainService": { "uri": "/sap/opu/odata/SAP/YOUR_SERVICE_SRV/", "type": "OData", "settings": { "odataVersion": "2.0", "localUri": "localService/metadata.xml", // Otras configuraciones: defaultBindingMode, defaultCountMode, useBatch, etc. } } } }, "sap.ui5": { "models": { "": { // Modelo por defecto "dataSource": "mainService", "preload": true, "settings": { // Configuraciones específicas del modelo V2 "defaultBindingMode": "TwoWay", "defaultCountMode": "Inline", "useBatch": true, "refreshAfterChange": true } } //... otros modelos } }

• Programáticamente: JavaScript // En un controlador var oModel = new sap.ui.model.odata.v2.ODataModel("/sap/opu/odata/SAP/YOUR_SERVICE_SRV/", { // Parámetros de configuración opcionales json: true, // Usar JSON loadMetadataAsync: true, defaultBindingMode: sap.ui.model.BindingMode.TwoWay, useBatch: true, headers: { "myHeader": "value" } // Cabeceras personalizadas [109] }); this.getView().setModel(oModel); // Establecer como modelo por defecto de la vista 55

Binding de Datos (Vistas XML)

El enlace de datos conecta las propiedades de los controles UI a las propiedades del modelo OData.

• Binding Absoluto: Se especifica la ruta completa desde la raíz del servicio. XML <Table items="{/ProductSet}"> <columns> <Column><Text text="Product ID"/></Column> <Column><Text text="Name"/></Column> </columns> <items> <ColumnListItem> <cells> <Text text="{ProductID}"/> <Text text="{ProductName}"/> </cells> </ColumnListItem> </items> </Table>

• Binding Relativo (Element Binding): Un control contenedor (ej. Page, Form) se enlaza a una entidad específica, y los controles internos usan rutas relativas a esa entidad. XML <Page binding="{/ProductSet('123')}"> <Input value="{ProductName}"/> <Input value="{Price}"/> <Text text="{ToCategory/CategoryName}"/> </Page>

• Opciones de Consulta en Binding: Se pueden pasar parámetros como $select, $expand, $filter, $orderby directamente en la sintaxis de binding. XML <Table items="{path: '/ProductSet', parameters: {expand: 'ToCategory', select: 'ProductID,ProductName,ToCategory/CategoryName'}}"> </Table> 108

Operaciones CRUD (Métodos create, read, update, remove)

El modelo V2 proporciona métodos explícitos para realizar operaciones CRUD 55:

• read(sPath, mParameters?): Dispara una solicitud GET a la ruta especificada (sPath). Los datos devueltos se pasan a la función success en mParameters. mParameters puede incluir success, error, urlParameters, filters, sorters, etc..55 JavaScript oModel.read("/Products(999)", { urlParameters: { "$expand": "Supplier" }, success: function(oData, oResponse) { /*... */ }, error: function(oError) { /*... */ } });

create(sPath, oData, mParameters?): Dispara una solicitud POST a la ruta del conjunto de entidades (sPath) con los datos proporcionados en oData. mParameters puede incluir success, error, groupId, etc..55 JavaScript var oNewProduct = {