MIS CURSOS
SAP Integration Suite, API Management, SAP BTP
OData XML a JSON: mediación en SAP API Management
OData XML a JSON en SAP API Management permite ofrecer una API clara a aplicaciones web, móviles y partners sin modificar el backend. El patrón es sencillo: S/4HANA conserva el formato que necesita; el API proxy adapta el contrato público para cada consumidor.
Esta guía explica cómo diseñar esa mediación sin convertir el proxy en una capa de lógica de negocio, qué políticas intervienen y qué revisar antes de transformar cada respuesta XML automáticamente.
Contenido
El problema: un backend correcto no siempre es una API cómoda
Muchos servicios OData v2 entregan XML por defecto. Es un formato válido para el backend, pero puede resultar incómodo para consumidores modernos que esperan JSON y nombres de campos consistentes. Cambiar el servicio de origen solo para satisfacer un canal suele aumentar el acoplamiento y el coste de mantenimiento.
La capa de API Management está precisamente para desacoplar el contrato externo del sistema que implementa la lógica. La política debe ser: el backend mantiene su contrato interno; el proxy publica el contrato que necesitan los consumidores.
Primero, comprueba si OData ya puede entregar JSON
Antes de añadir una transformación, prueba la capacidad nativa del servicio. En muchos escenarios OData el parámetro $format=json permite solicitar JSON directamente. Si la respuesta cumple el contrato que necesitas, es preferible evitar pasos de conversión innecesarios: reduces latencia, complejidad y puntos de fallo.
Las políticas de mediación que resuelven la mayoría de casos
XML to JSON y JSON to XML
Las políticas de conversión cambian el formato del mensaje. XML to JSON se usa normalmente en la respuesta; JSON to XML entra en juego cuando un cliente envía datos JSON y el backend requiere XML. La conversión sirve para el transporte, pero no garantiza por sí sola una experiencia de API bien diseñada.
Assign Message
Esta política permite ajustar cabeceras, parámetros y cuerpos del mensaje. Es útil para añadir $format=json, eliminar cabeceras que no deben salir del perímetro o conformar una respuesta que respete el contrato documentado en el portal de desarrolladores.
Extract Variables
Extrae datos de la ruta, los parámetros, cabeceras o cuerpo y los almacena en variables de flujo. Así puedes reutilizar, por ejemplo, un identificador de producto o un contexto de cliente sin trasladar esa complejidad al backend.
XSL Transform
Cuando una conversión directa no es suficiente, XSLT permite reestructurar XML de forma controlada. Debe reservarse para transformaciones que realmente lo justifiquen: cuanto más compleja sea la hoja, más pruebas y gobierno necesitará.
Cómo convertir OData XML a JSON con un flujo claro
- Valida el acceso antes de ejecutar cualquier transformación.
- Extrae las variables necesarias de la petición.
- Ajusta la petición con parámetros o cabeceras necesarias para el backend.
- Convierte solo cuando haga falta: JSON a XML en escritura, XML a JSON en respuesta.
- Normaliza la salida para que los nombres y la estructura coincidan con la especificación publicada.
- Gestiona los errores con el mismo contrato JSON que las respuestas correctas.
El punto más importante suele ser el último. Si solo conviertes respuestas 200, un error del backend puede llegar como XML o con una estructura distinta. Para el consumidor, una API profesional debe devolver errores previsibles, documentados y sin filtrar detalles internos.
Errores que conviene evitar
- Confiar a ciegas en la conversión automática: revisa el payload resultante y sus casos límite.
- Hacer lógica de negocio en el proxy: cálculos, orquestaciones complejas o agregaciones pertenecen a una capa de integración o a un servicio específico.
- Olvidar el manejo de errores: el formato de fallo forma parte del contrato de API.
- Transformar sin pruebas: valida colecciones, valores nulos, caracteres especiales y grandes volúmenes de respuesta.
Conclusión
La mediación de payloads permite modernizar la interfaz de un backend SAP sin alterar su implementación. La mejor solución no es transformar siempre: es decidir cuándo usar JSON nativo, cuándo adaptar en el proxy y cómo mantener un contrato estable para quienes integran la API.
Preguntas frecuentes
¿Es mejor XML to JSON o $format=json?
Si el servicio OData ofrece JSON nativo y su estructura satisface el contrato, esa suele ser la opción más simple. La mediación aporta valor cuando necesitas adaptar o normalizar la respuesta.
¿El proxy debe transformar también los errores?
Sí. La respuesta de error debe seguir un formato coherente y no exponer detalles sensibles del backend.
Fuentes oficiales
