Políticas en SAP API Management: cómo proteger, controlar y enriquecer tus APIs sin tocar el backend

Cuando empiezas a publicar APIs en SAP Integration Suite, casi siempre ocurre lo mismo. La primera versión funciona: el API Proxy responde, el backend devuelve los datos y todo el mundo está contento. Hasta que llega la siguiente conversación: ¿qué pasa si un cliente nos lanza diez mil peticiones por minuto? ¿Cómo limitamos el acceso por aplicación? ¿Y si el partner consume JSON pero S/4HANA habla OData en XML?

Todas estas preguntas se responden en el mismo sitio: las políticas del proxy. No son un detalle de configuración, son la pieza que convierte un proxy plano en un servicio gestionado de verdad.

En este artículo repasamos qué son, dónde se ejecutan, qué tipos hay y cómo encajan en un escenario real. Todo basado en lo que se trabaja en el curso de SAP API Management & Open Connectors de Logali Group y en la documentación oficial de SAP Help Portal.

¿Qué es una política y qué no es?

Una política en SAP API Management es un componente declarativo que se ejecuta dentro del API Proxy en un punto concreto del flujo. Cada política hace una sola cosa: validar una clave, contar peticiones, transformar un payload, lanzar un error controlado, llamar a un servicio externo. Se configura en XML y se asocia al flujo desde el editor visual del API Portal.

Antes de seguir conviene descartar tres confusiones habituales:

• Una política no es código del backend. Vive en el proxy. El backend ni se entera. Si retiras la política, el backend sigue exactamente igual.
• Una política no es un middleware genérico. Está atada a un flujo concreto del proxy y se aplica solo a ese tráfico. Otra API con otro proxy puede tener otras políticas, o ninguna.
• Una política no sustituye a Cloud Integration. Sirve para controlar y mediar tráfico, no para orquestar procesos complejos con varios sistemas. Para eso está Cloud Integration (antes CPI).

Dónde se ejecutan: ProxyEndpoint y TargetEndpoint

Toda política vive dentro de un flujo. Y todo proxy tiene dos endpoints donde adjuntar esos flujos: el ProxyEndpoint, que mira al consumidor, y el TargetEndpoint, que mira al backend. Cada endpoint tiene un PreFlow (se ejecuta antes) y un PostFlow (después).

La regla práctica es sencilla: lo que afecta al consumidor (validar una API Key, aplicar una cuota, controlar picos) se coloca en el PreFlow del ProxyEndpoint, lo más temprano posible. Lo que afecta al backend (transformaciones de formato, cabeceras de autenticación) suele ir en el TargetEndpoint. Si lo pones en el sitio equivocado, no rompe nada, pero gastas recursos en peticiones que vas a rechazar dos pasos después.

Las cuatro categorías de políticas

API Management agrupa las políticas en cuatro familias. No es una clasificación arbitraria: cada familia resuelve un tipo distinto de problema y suele aparecer en momentos distintos del proyecto.

1. Seguridad

Es la primera familia que se usa porque sin ella el proxy es público. Aquí entran las políticas de autenticación y autorización del tráfico que entra:

• Verify API Key: valida que la petición incluye una API Key vigente, asociada a una aplicación registrada en el Developer Hub. Es la forma más rápida de poner una API detrás de un control de acceso.
• OAuth v2: verifica un access token. Es el estándar para escenarios donde el consumidor es una aplicación de terceros y quieres delegar la emisión de credenciales en un servidor de autorización.
• Basic Authentication: válida en escenarios internos contra backends que solo entienden usuario y contraseña. Se suele usar en el TargetEndpoint para inyectar la cabecera hacia el backend, no en el ProxyEndpoint.
• JWT y SAML: validación o generación de tokens firmados, útiles cuando hay un Identity Provider corporativo en medio.

2. Gestión de tráfico (Traffic Management)

Esta familia es la que protege el backend de sí mismo. Sin políticas de tráfico, una integración mal hecha en el lado del cliente puede tumbar tu S/4HANA. Las más usadas:

3. Mediación

Aquí está la magia de exponer una API moderna sobre un backend que no lo es. La capa de mediación transforma, enriquece o filtra el mensaje sin que el backend tenga que cambiar:

• JSON to XML / XML to JSON: conversión de formato. Imprescindible cuando el consumidor habla JSON pero el backend SAP devuelve OData en XML.
• XSL Transform: aplica una hoja de estilo XSLT para reestructurar XML de forma más fina que con políticas de mapeo simples.
• Assign Message: crea, modifica o elimina elementos del mensaje (cabeceras, query params, body, variables de flujo). Es el cuchillo suizo del proxy.
• Raise Fault: interrumpe el flujo y devuelve un error controlado al consumidor. Usar Raise Fault es lo que diferencia un proxy serio de uno que filtra errores crudos del backend al cliente.

4. Extensión

Cuando ninguna política estándar resuelve el problema, las políticas de extensión te dan una vía de escape. La regla es usarlas con criterio: cuanto más código pones en el proxy, más mantenimiento te llevas a futuro.

• JavaScript: ejecuta lógica personalizada sobre el mensaje. Útil para validaciones específicas, cálculos o reglas de negocio sencillas.
• Python: alternativa a JavaScript con la misma filosofía.
• Service Callout: llama a un servicio HTTP externo en medio del flujo. Sirve para enriquecer la respuesta con datos de otra API antes de devolverla al cliente.
• Message Logging: envía el contenido del mensaje a un sistema de log externo. Clave para auditoría y depuración en entornos productivos.

Un caso real: cadena típica en una API expuesta a partners

La teoría se entiende mejor con una cadena concreta. Imaginemos una API que expone datos de productos de S/4HANA a partners externos. El flujo de políticas, en orden, podría ser este:

• Verify API Key valida que el partner está registrado en el Developer Hub.
• Quota controla que no supere su plan mensual contratado.
• Spike Arrest amortigua ráfagas que pudieran saturar el backend.
• JSON to XML convierte la petición REST/JSON al formato OData/XML que entiende S/4HANA.
• JavaScript añade un identificador de correlación para trazar la petición extremo a extremo.
• Service Callout pregunta a un servicio de catálogo externo el precio actualizado antes de entregar la respuesta al partner.

El backend no se ha tocado. La aplicación cliente cree estar hablando con una API REST/JSON moderna y limpia. La realidad es que detrás hay un OData clásico que ni siquiera sabe que existe el partner.

Buenas prácticas que ahorran tiempo

Conclusión

Las políticas son lo que diferencia un API Proxy de un Gateway real. Permiten exponer servicios SAP de forma segura, controlada y consistente, sin tocar el backend ni reescribir lógica de negocio. Cuatro familias, una decena de políticas en uso habitual, y una regla de oro: cuanto más declarativa sea tu configuración, más fácil será mantenerla.

Si trabajas con SAP Integration Suite y todavía no has separado claramente seguridad, tráfico, mediación y extensión en tus proxies, este es un buen momento para revisarlo. Es la base sobre la que después se construyen los productos de API, los planes de tarifas y la monetización.

En la siguiente entrega entramos en la publicación de productos de API y el Developer Hub: cómo agrupar varios proxies en un producto consumible, cómo gestionar la suscripción de aplicaciones y cómo conectar las cuotas con un plan de tarifas para empezar a monetizar de verdad. Si has llegado hasta aquí, no te pierdas la siguiente.

Fuentes

• SAP Help Portal · API Management · Policy Reference.
• SAP Help Portal · Configure Flows and Policies.
• SAP Community Blogs · API Management on SAP BTP.
• Curso SAP API Management & Open Connectors · Logali Group, Bloque II – Diseño y Seguridad de APIs.