OData

OData describe los datos de negocio como entity sets a los que los clientes acceden mediante URL, con verbos HTTP estándar para cada operación:

• GET lee un entity set o una sola entidad, por ejemplo los pedidos de compra de Cedar Office Supply.
• POST, PATCH/PUT y DELETE crean, modifican y eliminan entidades.
• Las system query options como $filter, $select, $expand, $orderby, $top y $skip permiten al cliente pedir al servidor que filtre, ordene y pagine los datos.
• `$metadata` devuelve el modelo de datos del servicio: entity types, propiedades, claves, asociaciones y anotaciones.
• `$batch` agrupa varias solicitudes en una sola llamada HTTP.

Como el modelo y las operaciones están estandarizados, un cliente genérico como el modelo OData de SAPUI5 puede vincular controles a cualquier servicio conforme sin código de solicitud a medida. OData es, por tanto, un contrato sobre cómo se exponen los datos, no una pieza de lógica de negocio.

Una vez que el SAP Fiori Launchpad ha resuelto un tile e iniciado la aplicación, el acceso a los datos sigue el mismo camino en todas las aplicaciones SAPUI5 o SAP Fiori elements:

1. La aplicación se inicia. El app descriptor indica el servicio OData que la aplicación usa como fuente de datos.
2. La aplicación llama al servicio. El modelo OData de SAPUI5 envía solicitudes, a menudo agrupadas en un $batch, a la URL del servicio. En SAP S/4HANA, SAP Gateway comprueba que el usuario puede iniciar el servicio (objeto de autorización S_SERVICE) y enruta la solicitud.
3. Se ejecuta la lógica de negocio. La implementación del servicio (vistas CDS, comportamiento RAP o código basado en SEGW) aplica validaciones y autorizaciones de datos.
4. Se lee o se escribe el registro. La respuesta devuelve los datos, o el cambio se guarda en el documento de negocio, lo que puede desencadenar un procesamiento posterior, como un workflow.

Cada paso fallido se manifiesta de forma distinta: una autorización de inicio ausente aparece en SU53, mientras que un error del lado del servicio aparece en /IWFND/ERROR_LOG o /IWBEP/ERROR_LOG en on-premise. Toda pantalla SAP Fiori basada en datos es, en el fondo, una secuencia de solicitudes OData.

Ambas versiones conviven en los entornos SAP, y la versión determina qué herramientas y modelos se aplican:

RAP puede exponer el mismo business object como OData V2 o V4, y algunas funcionalidades más recientes de SAP Fiori elements solo se evalúan con OData V4, mientras que muchas aplicaciones entregadas siguen funcionando con V2. Elegir una versión de OData es una decisión sobre herramientas y compatibilidad con las aplicaciones, no solo sobre las funcionalidades del protocolo.

SAP ofrece varias formas de crear un servicio OData, según la plataforma y la antigüedad del código:

• RAP (ABAP RESTful Application Programming Model): una service definition selecciona entidades CDS y un service binding las publica como OData V2 o V4, con la categoría UI (incluye anotaciones de UI para SAP Fiori elements) o Web API (sin metadatos específicos de UI).
• Proyectos SEGW: el SAP Gateway Service Builder modela entidades y genera clases de runtime para ABAP escrito a mano; habitual en aplicaciones personalizadas más antiguas.
• CDS con `@OData.publish: true`: genera un servicio OData V2 a partir de una vista CDS; sigue documentado para on-premise y Private Edition, mientras que los service bindings de RAP son el enfoque más reciente.
• CAP en SAP BTP: service definitions en CDS servidas como OData, con V4 por defecto y V2 disponible mediante un adaptador.

El protocolo en la red es el mismo; el modelo de programación que hay detrás determina cómo se gestionan la lógica, los drafts y las extensiones. Conviene iniciar un nuevo servicio OData en el modelo de programación que la plataforma de destino recomienda actualmente.

• On-premise y Private Edition: los administradores registran y activan los servicios OData en SAP Gateway, asignan system aliases y mantienen los nodos ICF. Está disponible el conjunto completo de transacciones y logs de Gateway.
• Public Edition: SAP opera los servicios que hay detrás de las aplicaciones SAP Fiori entregadas. El acceso a las herramientas de administración y supervisión está controlado, en lugar de abierto como en on-premise; los consumidores externos llaman a API liberadas mediante communication arrangements, y los servicios personalizados provienen de la extensibilidad para desarrolladores o de la extensibilidad key user.
• SAP BTP: las aplicaciones llaman directamente a servicios OData en SAP BTP o acceden a servicios on-premise mediante destinations y el SAP Cloud Connector.

El protocolo OData se comporta igual en todas partes; lo que cambia es quién activa el servicio y cómo lo alcanza quien lo llama.

1. Tratar un servicio de UI como una API de integración. Un servicio construido para una aplicación SAP Fiori puede cambiar junto con la aplicación. Las integraciones deben apoyarse en API liberadas o en servicios diseñados como Web API.
2. Recuperar datos de más. Las listas sin $select o con un $expand profundo transfieren muchos más datos de los que muestra la pantalla; compruebe las solicitudes en las herramientas de desarrollo del navegador.
3. Ignorar `$batch` al depurar. El navegador muestra una sola llamada batch; la operación que falla está dentro del cuerpo de su respuesta.
4. Mezclar versiones en el diseño de una aplicación. V2 y V4 usan modelos SAPUI5 y pilas de SAP Fiori elements distintos, por lo que los componentes rara vez pasan de una a otra sin cambios.
5. Culpar a la UI de las carencias de autorización. Una lista vacía puede deberse a un filtro de autorización de datos en el servicio, no a un error del front-end.

La mayoría de los problemas de OData en proyectos SAP Fiori son problemas de diseño o de autorización que solo afloran como errores de protocolo.