
1. Introducción
Uno de los objetivos principales de SAPUI5 es conectarse con los datos del sistema SAP a través de servicios OData.
El consumo de servicios OData permite a las aplicaciones leer, mostrar, actualizar y eliminar información en tiempo real proveniente del backend SAP, manteniendo la arquitectura MVC y la separación entre lógica, datos y presentación.
En SAPUI5, esta conexión se realiza mediante el modelo ODataModel, un componente del framework que maneja la comunicación con el servicio y simplifica las operaciones CRUD (Create, Read, Update, Delete).
2. Concepto general del consumo OData
El flujo básico entre una aplicación SAPUI5 y un servicio OData es el siguiente:
-
El servicio OData es creado y registrado en el backend SAP (SEGW).
-
El SAP Gateway expone el servicio vía HTTP.
-
La aplicación SAPUI5 utiliza un modelo ODataModel para conectarse al endpoint.
-
Los datos se enlazan (data binding) con controles de la interfaz, como tablas, listas o formularios.
💡 Este modelo de trabajo permite mantener la sincronización automática entre la interfaz y el backend.
3. Tipos de modelo OData en SAPUI5
SAPUI5 ofrece dos tipos de modelo OData:
Tipo
Descripción
Clase utilizada
| ODataModel V2 |
Modelo más utilizado. Soporta binding bidireccional y manejo automático de metadatos. |
sap.ui.model.odata.v2.ODataModel |
| ODataModel V4 |
Versión más reciente. Optimiza rendimiento y manejo de datos masivos, compatible con SAPUI5 ≥ 1.48. |
sap.ui.model.odata.v4.ODataModel |
En la mayoría de los entornos SAP actuales (S/4HANA y BAS), se utiliza OData V2 por su estabilidad y compatibilidad.
4. Configuración del modelo OData en manifest.json
El archivo manifest.json centraliza la configuración del modelo OData y del servicio asociado.
Esto permite definir la conexión una sola vez, haciéndola disponible para toda la aplicación.
Ejemplo:
"models": { "": { "dataSource": "mainService", "settings": { "defaultBindingMode": "TwoWay", "refreshAfterChange": false } } }, "dataSources": { "mainService": { "uri": "/sap/opu/odata/sap/Z_ODATA_CLIENTES_SRV/", "type": "OData", "settings": { "odataVersion": "2.0" } } }
📘 Explicación:
-
"uri" → define la URL del servicio OData.
-
"type": "OData" → indica el tipo de fuente de datos.
-
"defaultBindingMode": "TwoWay" → permite lectura y escritura.
-
"odataVersion": "2.0" → especifica la versión del protocolo.
5. Enlace de datos (Data Binding)
El binding conecta los datos del modelo con los controles de la interfaz.
Existen tres tipos principales:
Tipo
Descripción
Ejemplo
| Property Binding |
Enlaza un valor individual. |
<Text text="{Cliente>Nombre}" /> |
| Element Binding |
Enlaza un conjunto de propiedades a un control. |
<FormElement binding="{Cliente>}" /> |
| Aggregation Binding |
Enlaza colecciones (listas, tablas). |
<List items="{path: '/CustomerSet'}">...</List> |
Ejemplo de lista enlazada:
<List items="{/CustomerSet}"> <StandardListItem title="{Name}" description="{Country}" /> </List>
6. Acceso al modelo desde el controlador
En un controlador, el modelo OData puede accederse mediante los métodos estándar de SAPUI5:
onInit: function () { var oModel = this.getOwnerComponent().getModel(); this.getView().setModel(oModel); }
También se pueden realizar lecturas programáticas:
oModel.read("/CustomerSet", { success: function(oData) { console.log("Datos recibidos:", oData); }, error: function(oError) { console.error("Error al leer datos:", oError); } });
💡 El método read() ejecuta una llamada GET al servicio OData.
Para escritura o actualización se utilizan create(), update() y remove().
7. Prueba del servicio desde SAPUI5
-
Ejecutar la aplicación en SAP BAS o Eclipse.
-
Verificar en la consola del navegador (F12) la carga del servicio OData.
-
Revisar el log de red:
-
Peticiones HTTP GET (lectura).
-
Peticiones POST, PUT, DELETE según el tipo de operación.
-
Validar que los datos coincidan con los registros del sistema SAP.
8. Buenas prácticas
-
Definir el modelo OData en el manifest.json (no directamente en los controladores).
-
Mantener la versión de OData consistente con el backend.
-
Evitar lecturas sin filtros en tablas grandes.
-
Manejar errores en cada operación (bloque success/error).
-
Reutilizar un solo modelo por aplicación (no crear múltiples instancias del mismo servicio).
-
Probar siempre el servicio en /IWFND/GW_CLIENT antes de consumirlo desde SAPUI5.
9. Conclusión
Consumir un servicio OData desde SAPUI5 es el paso que integra la capa de datos del backend con la interfaz Fiori.
El uso del ODataModel permite enlazar datos de manera declarativa, reduciendo el código y garantizando sincronización automática.
Comprender esta integración es esencial para el desarrollo de aplicaciones Fiori completas y dinámicas.
Preguntas de repaso
-
¿Qué clase se utiliza para conectarse a un servicio OData versión 2 en SAPUI5?
→ sap.ui.model.odata.v2.ODataModel
-
¿Dónde se define la conexión al servicio OData dentro del proyecto SAPUI5?
→ En el archivo manifest.json, dentro de las secciones "models" y "dataSources".
-
¿Qué operación HTTP ejecuta el método oModel.read()?
→ Una operación GET.
-
¿Qué parámetro del modelo permite modificar datos tanto en la vista como en el backend?
→ "defaultBindingMode": "TwoWay".
-
¿Qué ventaja ofrece el data binding en SAPUI5?
→ Conecta automáticamente la vista con el modelo, manteniendo sincronizados los datos sin necesidad de código adicional.