Receptor OData en SAP CPI: $select, $filter, $expand y $orderby sin errores de tipeo

El adaptador receptor OData de SAP CPI convierte un Resource Path y una línea de opciones de consulta en una llamada a un servicio OData, como una API de SAP S/4HANA. Las opciones de consulta deciden qué campos, filas y entidades relacionadas se devuelven, y basta un nombre de propiedad mal escrito para que el servicio rechace la llamada.

Este artículo recorre $select, $filter, $expand y $orderby con un ejemplo, las diferencias entre OData V2 y V4 que confunden a muchos, y cómo mantener los nombres correctos.

Dónde van las opciones de consulta en el receptor OData

En la pestaña Processing del adaptador eliges la operación y luego defines el Resource Path, que es el entity set o la entidad que llamas, y las Query Options, que son todo lo que va después del ? en la URL. El asistente de consultas del adaptador puede armar ambos a partir de los metadatos del servicio y guarda esos metadatos, el archivo EDMX, en los recursos del iFlow.

Las opciones de consulta pueden contener expresiones Simple, así que los valores pueden venir del mensaje, por ejemplo $filter=SoldToParty eq '${property.customerId}'. El ejemplo siguiente lee pedidos de venta con sus posiciones desde API_SALES_ORDER_SRV, un servicio OData V2:

Resource Path:  A_SalesOrder
Query Options:  $select=SalesOrder,SoldToParty,CreationDate,to_Item/SalesOrderItem,to_Item/Material
                &$expand=to_Item
                &$filter=SoldToParty eq '${property.customerId}' and CreationDate ge datetime'2026-01-01T00:00:00'
                &$orderby=CreationDate desc
                &$top=50

En el adaptador, las opciones de consulta van en una sola línea; aquí se dividen solo para que se lean mejor.

Las cuatro opciones, una por una

$top y $skip limitan y paginan el resultado. En OData V2, una propiedad de una entidad expandida se selecciona con una ruta, como en to_Item/Material, y la propiedad de navegación también debe aparecer en $expand.

$filter tiene sus propios operadores: eq, ne, gt, ge, lt, le, unidos con and, or y not. Los valores de texto van entre comillas simples, y las fechas necesitan la forma literal que espera la versión del servicio.

OData V2 y V4 no se escriben igual

El adaptador OData admite ambas versiones, y muchas API de SAP existen en las dos. Copiar una consulta de una versión a otra es una fuente frecuente de errores:

OData V2:  $inlinecount=allpages
           $filter=substringof('Smith',CustomerName)
           $filter=CreationDate ge datetime'2026-01-01T00:00:00'

OData V4:  $count=true
           $filter=contains(CustomerName,'Smith')
           $filter=CreatedAt ge 2026-01-01T00:00:00Z
           $expand=_Item($select=Product,Quantity)

• Contar filas: $inlinecount=allpages en V2, $count=true en V4.
• Buscar dentro de un texto: substringof('Smith',CustomerName) en V2, contains(CustomerName,'Smith') en V4. Fíjate en que los argumentos van en orden inverso.
• Fechas: V2 escribe datetime'2026-01-01T00:00:00'; V4 escribe el valor sin prefijo.
• Propiedades expandidas: V2 las selecciona con una ruta; V4 anida las opciones dentro del expand, como en $expand=_Item($select=Product,Quantity).

Los errores de tipeo que causan HTTP 400

Cuando una opción de consulta está mal, el servicio suele responder con HTTP 400 e indica la parte que no pudo leer. Los errores detrás de eso son casi siempre los mismos:

• Mayúsculas y minúsculas equivocadas: los nombres de OData las distinguen, así que soldToParty no es SoldToParty.
• Un entity set donde corresponde una propiedad de navegación: $expand=A_SalesOrderItem en lugar de $expand=to_Item.
• Una propiedad que existe en otra entidad, o solo en otra versión del servicio.
• Faltan las comillas alrededor de valores de texto, o se envía un literal de fecha de V2 a un servicio V4.
• Un problema de separadores: las opciones se unen con &, y el nombre de cada opción empieza con $.

Las expresiones añaden su propio riesgo: si ${property.customerId} está vacío, el filtro se convierte en SoldToParty eq '' y no devuelve filas sin avisar, en lugar de dar un error. El artículo sobre expresiones Simple explica cómo se leen esos valores.

Mantén la consulta y el servicio sincronizados

• Toma el EDMX de los recursos del iFlow como la fuente de verdad para los nombres, y actualízalo cuando cambie el servicio.
• Selecciona solo los campos que mapeas; una respuesta más pequeña es más rápida y más fácil de leer en un trace.
• Para lecturas grandes, usa la opción del adaptador para procesar por páginas en lugar de una única respuesta enorme.
• Prueba la consulta una vez con los valores exactos que pondrá en ella un mensaje real.

¿Llamas a una API REST en lugar de a un servicio OData? El artículo sobre Postman y OpenAPI cubre el receptor HTTP.

Cómo ayuda Kitegra

La extensión de navegador Kitegra lee el EDMX que tu iFlow ya contiene para un canal receptor OData. En el diseñador sugiere el Resource Path y los nombres de propiedades y de navegación para $select, $filter, $expand y $orderby a partir de ese EDMX, así que eliges nombres en lugar de escribirlos.

Su panel de lint señala los nombres de OData que no están en el EDMX, además de los ${ sin cerrar y los headers o propiedades que nada define. Si un canal no recibe sugerencias, comprueba que su EDMX esté en los recursos del iFlow. La extensión nunca guarda, despliega ni edita el contenido de un iFlow, y tu tenant solo cambia cuando haces clic en una de cuatro acciones con nombre, que se pueden desactivar.

Para comprobar qué respondió realmente el servicio OData, traza el mensaje paso a paso y lee el cuerpo después de la llamada.

Sin una cuenta de Kitegra funciona en 5 iFlows por módulo. El plan Free cubre 50, Starter 100 y Pro 300; Business no tiene límite. Compara los planes.

Pruébalo en tu próximo iFlow

Descubre lo que hace Kitegra en el diseñador de SAP Integration Suite, o míralo junto a las demás extensiones de Chrome de Kitegra.

Preguntas frecuentes