OData en SAP: filtra en origen y controla la paginación

Una respuesta 200 OK puede ser correcta y, aun así, no contener todos los registros. En una integración OData, filtrar en el origen reduce datos, tiempo y exposición innecesaria. Pero la eficiencia no sirve si el flujo lee solo la primera página o reconstruye un enlace de continuación que el servidor ya ha calculado.

Formula una petición precisa en el servicio

$filter expresa el criterio donde viven los datos y $select limita las propiedades que viajan al flujo. Por ejemplo, una integración puede pedir solo registros modificados desde una fecha, con su clave, estado e importe, en vez de descargar la entidad completa para eliminar campos después. Es una mejora de rendimiento y una forma de reducir qué información queda disponible en los registros del proceso.

El patrón no reemplaza el contrato del servicio. Los nombres de entidades, campos filtrables, funciones y límites dependen de cada API SAP. Antes de activar una consulta, revisa $metadata, la documentación concreta y una respuesta real. Que un servicio use OData no garantiza que exponga todas las opciones ni que interprete un filtro como otro.

Paginación OData: por qué $top no basta

$top fija un máximo solicitado por el cliente. El servicio puede devolver menos registros y, si quedan resultados, continuar mediante paginación dirigida por servidor. En OData V4, esa respuesta incluye un enlace de continuación; el cliente debe seguirlo para recibir el resto. El protocolo OData V4 indica que el cliente debe tratar ese enlace como opaco: no debe extraer ni fabricar un $skiptoken, añadir filtros ni reconstruir la URL.

La forma del JSON depende de la versión y de la implementación. En respuestas OData V2 es habitual encontrar d.__next; en V4, @odata.nextLink. La guía de SAP SuccessFactors documenta el caso V2 con __next y un token de continuación que se reutiliza tal como llega. En SAP Gateway, $skiptoken y el enlace next forman parte de las capacidades de paginación dirigida por servidor. La guía de SAP muestra la continuación de su API V2.

El workflow no debe suponer un nombre de propiedad universal. Primero identifica la respuesta del servicio objetivo; después guarda el enlace exacto y solicita la página siguiente con el mismo contexto de autenticación y cabeceras que la primera. Cuando ya no exista enlace, la lectura ha terminado.

Offset y orden: decisiones explícitas

Algunos servicios admiten $skip; usarlo no equivale a un token de continuación. El offset lo define el cliente y puede dar resultados inconsistentes si los datos cambian entre páginas o si no existe una ordenación determinista. Si el contrato permite $skip, combina la lectura con un $orderby estable sobre una clave o criterio documentado. OData V4 exige una ordenación estable al usar $skip, pero conviene validarla frente al servicio real.

Para una extracción que deba representar un corte coherente, define además la regla de negocio: marca de agua de modificación, rango cerrado, delta documentado o identificador de ejecución. Contar páginas no basta si durante la lectura se crean, modifican o eliminan registros.

Usa $expand cuando puedas validar el resultado

$expand trae relaciones navegables y evita llamadas adicionales, pero puede multiplicar el volumen. Pide solo las propiedades relacionadas necesarias y prueba qué ocurre cuando una relación no existe, está vacía o tiene más elementos de los esperados. El éxito técnico de la llamada no demuestra que el dato de negocio requerido haya llegado.

Prueba de aceptación contra lecturas incompletas

1. Prueba cero resultados, una sola página, varias páginas y una última página parcial.
2. Registra páginas, claves únicas, volumen y duración; compara el total con una consulta de control cuando el servicio lo permita.
3. Comprueba que cada siguiente petición usa el enlace devuelto, sin modificar el token ni concatenar parámetros.
4. Fuerza un error temporal o límite de tasa entre páginas y verifica que el reintento no salta ni duplica registros.
5. Ejecuta un caso con datos que cambian durante la extracción y confirma la regla elegida para la consistencia.

Lecturas relacionadas

Continúa con OData XML a JSON en SAP API Management y API Provider y Cloud Connector para profundizar en los conceptos de este artículo.