SAP API Management en Integration Suite: activación, entorno y el camino hasta tu primera API Proxy

La conversación sobre integraciones en SAP suele empezar por Cloud Integration y los iFlows. Pero cuando el paisaje crece —partners que consumen datos, apps móviles internas, microservicios, un S/4HANA que no debería estar expuesto directamente al mundo—, el problema deja de ser cómo conecto A con B y pasa a ser cómo gobierno, protejo y mido todo lo que entra y sale.

Ahí entra SAP API Management. No es un middleware más. Es la capa de gobierno que convierte servicios sueltos en APIs versionadas, seguras, monitorizadas y —si el negocio lo pide— monetizables. Y desde hace tiempo vive dentro de SAP Integration Suite en SAP BTP, compartiendo subaccount con Cloud Integration, Event Mesh y las demás capabilities.

Este artículo es el recorrido que cualquiera que empieza con API Management necesita: qué activar, qué roles asignar, cómo se organiza el entorno, y qué significan exactamente Discover, Configure, Test, Analyze, Monetize y Engage cuando los ves en el menú sin contexto.

Índice

• Qué es SAP API Management y por qué importa en tu arquitectura
• Activación de la capability desde Integration Suite
• Colecciones de roles: el paso silencioso que bloquea a medio mundo
• El entorno: Discover, Design, Configure, Test, Analyze, Engage
• API Providers: el puente a tu backend
• API Proxies: anatomía, creación y ciclo de vida
• Policies: las 40+ reglas que hacen el trabajo real
• Analyze: medir antes de optimizar
• Engage y Monetize: cuando la API deja de ser técnica y pasa a ser producto
• Takeaways prácticos para arrancar

Qué es SAP API Management y por qué importa

API Management es la práctica de crear, publicar, asegurar, monitorizar y monetizar APIs de forma centralizada. En la práctica, significa que entre tus consumidores (apps móviles, partners, frontends) y tus backends (S/4HANA, SuccessFactors, sistemas legacy, APIs de terceros) pones una capa intermedia que hace de policía, contador y traductor.

SAP lo resuelve con una capability de Integration Suite que expone tres elementos clave: API Providers (la definición del backend), API Proxies (la API que tú publicas hacia afuera, con su propia lógica) y API Products (agrupaciones de proxies que se consumen como una unidad comercial o funcional).

¿Por qué no exponer los servicios OData directamente desde S/4HANA? Porque pierdes control. No puedes limitar volumen por consumidor, no puedes cambiar el backend sin romper contratos externos, no puedes inyectar autenticación moderna sobre sistemas que no la soportan, y no tienes analítica decente del consumo. La capa de API Management resuelve los cuatro problemas de una vez.

Activación de la capability desde Integration Suite

Antes de tocar nada, confirma una regla que pilla desprevenido a muchos: las capabilities de API Management desde Integration Suite y las suscripciones standalone del API Management no pueden convivir en la misma subaccount SAP. Si existe una suscripción standalone previa, hay que eliminarla.

Con eso claro, el proceso es directo. En la home de Integration Suite, entras en Capabilities y pulsas Add Capabilities. Marcas Design, Develop, and Manage APIs (o Manage APIs según la versión del cockpit), y en la siguiente pantalla decides si activas también el Developer Hub —el portal al que entrarán los desarrolladores externos a descubrir y suscribirse a tus APIs.

Tras pulsar Activate, el estado pasa de In Progress a Active en unos minutos. Hasta que no esté en verde no sigas, porque la configuración del runtime depende de ello.

El último paso conceptual de la activación está en Settings → Runtimes, dentro de Integration Suite. Ahí eliges si el servicio es de tipo Production o Non-Production. No es un detalle cosmético: afecta a SLA, a límites de throughput y a si el entorno es apto para cargas críticas. Para pruebas, sandbox y formación va Non-Production. Para cualquier cosa que vaya contra datos reales de negocio, Production.

Cuando termina la provisión llega un email de confirmación con los detalles del tenant, y toca cerrar sesión y volver a entrar para que aparezcan todas las opciones del menú.

Colecciones de roles: el paso silencioso que bloquea a medio mundo

El patrón de error más repetido en los primeros contactos con API Management es este: se activa la capability, se entra al portal y… faltan iconos, botones grises, secciones que no abren. La causa casi siempre es la misma: no se asignaron las role collections correctas al usuario.

SAP BTP separa tener acceso al tenant de tener permisos para operar. La activación hace lo primero; las role collections hacen lo segundo. Se asignan desde el BTP Cockpit, en Security → Users, seleccionando el usuario y añadiendo las colecciones necesarias.

Para el administrador que activa y configura todo, las imprescindibles son:

• APIManagement.Selfservice.Administrator: permite configurar el servicio API Management dentro de Integration Suite. Sin esta, el Portal abre con una fracción de las funciones.
• AuthGroup.SelfService.Admin: necesaria durante el onboarding del Developer Hub y para acceder a él.

Si además activaste Graph o el Developer Hub para usuarios distintos al admin, tienes que mapear roles adicionales como Graph.KeyUser, GraphNavigator.Viewer o AuthGroup.API.ApplicationDeveloper para los developers externos que se registrarán.

Un consejo que ahorra horas de diagnóstico: asigna, cierra sesión, vuelve a entrar. Las role collections no se refrescan en caliente, y más de un supuesto bug se resuelve con un logout.

El entorno: Discover, Design, Configure, Test, Analyze, Engage

Cuando entras al API Portal, el menú lateral ofrece seis grandes áreas. Cada una corresponde a una fase del ciclo de vida de una API. Conocer el mapa completo antes de empezar a clickear evita dar vueltas:

Este flujo no es estrictamente lineal: una API madura rota entre Configure, Test y Analyze muchas veces antes de pasar a Engage. Pero el primer proyecto de verdad casi siempre sigue el orden Provider → Proxy → Policies → Test → Product.

Discover: buscar antes de construir30

Antes de crear una API Proxy desde cero, pasa por Discover. SAP mantiene el SAP Business Accelerator Hub (antes API Business Hub), un catálogo público con cientos de APIs estándar de S/4HANA, SuccessFactors, Ariba, Concur, Commerce Cloud y más, ya documentadas en OpenAPI.

El flujo típico: buscas por módulo o por entidad de negocio (por ejemplo, Business Partner, Sales Order, Employee), revisas los endpoints y, si encaja, importas la especificación OpenAPI directamente como punto de partida de tu proxy. Te ahorras redibujar el contrato y garantizas alineación con el backend.

El Discover interno de tu tenant también muestra los proxies que tu propio equipo ya ha creado, lo cual es útil para evitar duplicidades cuando varios consultores trabajan en paralelo.

API Providers: el puente al backend

Un API Provider es la definición técnica de dónde vive el sistema que voy a exponer. Hostname, puerto, protocolo, tipo de autenticación, y —si procede— la URL del catálogo OData. No expone nada por sí solo; es el objeto que los proxies reutilizan como target.

En Configure → APIs → API Providers → Create, los campos principales son:

 

Un buen Provider tiene que pasar el test de conexión antes de que nadie construya un proxy encima. Si el Test Connection falla, no hay policy ni nada que lo salve después.

Patrón arquitectónico recomendado: un Provider por entorno de backend (DEV, QA, PROD) con el mismo nombre lógico y distintos hostnames. Así, al transportar proxies entre tenants, lo único que cambia es el Provider detrás, no la lógica.

API Proxies: anatomía, creación y ciclo de vida

Una API Proxy es la API que tú publicas. Envuelve a un backend (via API Provider) y añade lo que haga falta: autenticación, transformaciones, validaciones, límites, logging. El consumidor externo nunca ve el backend directamente; ve el proxy.

La creación en Configure → APIs → Create ofrece varios caminos: partir de un API Provider existente, importar una OpenAPI spec, apuntar a un Integration Flow publicado desde Cloud Integration, o usar un SOAP/REST URL directo.

Un proxy tiene dos mitades claramente separadas:

• Proxy Endpoint: el lado que mira al consumidor. Aquí se aplica todo lo que tiene que ver con autenticar, validar, cachear y limitar al cliente.
• Target Endpoint: el lado que mira al backend. Aquí se transforma el mensaje para que el Provider lo entienda, se inyecta el token OAuth contra el backend, o se reescriben URLs.

Y cada endpoint tiene tres momentos de ejecución:

PreFlow (antes), Conditional Flows (rutas según condiciones) y PostFlow (después).

Una request atraviesa PreFlow del Proxy → Conditional → PostFlow del Proxy → PreFlow del Target → llamada al backend → respuesta → PostFlow del Target → … y vuelta al cliente.

Entender este recorrido es el cambio mental que convierte a un developer de Cloud Integration en un developer de API Management. No es un iFlow; es un pipeline de request/response con puntos de extensión.

Cada proxy tiene también un API State: Alpha (en desarrollo), Beta (testing con usuarios seleccionados) y Active (producción). Disciplinar este ciclo desde el minuto uno evita mover APIs a producción por error y facilita gobierno frente a auditoría.

Policies: las 40+ reglas que hacen el trabajo real

Una Policy es una unidad de funcionalidad que se engancha a un punto del flujo del proxy. SAP trae más de 40 policies built-in que cubren los cuatro grandes grupos de problemas que aparecen en cualquier plataforma de APIs:

El patrón más común al empezar es este: añadir VerifyAPIKey en el PreFlow del Proxy Endpoint para asegurar que solo consumidores con clave válida pasan, y un Quota justo después para limitar el número de llamadas por aplicación. Con dos policies ya tienes seguridad básica y protección contra abuso.

Para escenarios con backends que requieren token OAuth (por ejemplo, un iFlow publicado en Cloud Integration), la secuencia cambia: en el PreFlow del Target Endpoint se aplican policies que obtienen el token del Token Provider y lo inyectan en el header Authorization antes de llamar al backend. El cliente externo nunca ve ni gestiona ese token; el proxy lo hace por él.

Las credenciales sensibles —client IDs, secrets, URLs de token— no deberían vivir hardcodeadas en las policies. Van en Key Value Maps (KVM) encriptados, y las policies los leen en runtime con KeyValueMapOperations. Esta es la forma limpia de desacoplar configuración de código y de permitir que el mismo proxy funcione en distintos entornos.

Analyze: medir antes de optimizar

La sección Analyze es probablemente la más infrautilizada de API Management, y la que más decisiones de producto habilita. Ofrece dashboards de:

El valor real aparece cuando cruzas estos datos: una caída de tráfico en un partner puede indicar que su integración rompió sin que te avisara; un pico de latencia en el target revela que el backend está saturado antes de que llegue el ticket; una tasa creciente de 401 denuncia que una aplicación está rotando credenciales mal.

El consejo práctico: antes de pasar cualquier API a Active, define qué dashboards vas a revisar semanalmente. Un proxy en producción que nadie mira es un incidente esperando a pasar.

Engage y Monetize: cuando la API deja de ser técnica y pasa a ser producto

Engage es donde los API Proxies se empaquetan en API Products: agrupaciones lógicas que se publican al Developer Hub para que consumidores externos las descubran, se suscriban y empiecen a usarlas.

Un Product típico agrupa proxies que tienen sentido juntos desde la perspectiva de negocio: Customer Data Product, que contiene los proxies de clientes, direcciones y contactos, aunque vengan de backends distintos. El consumidor no necesita saber si detrás hay S/4HANA, SuccessFactors o un sistema propio.

Cuando un developer externo se registra en el Developer Hub, crea una Application, elige a qué Products se suscribe, y obtiene un par de client credentials (API Key o Client ID/Secret) con el que empezar a consumir. Este flujo self-service es lo que hace escalable todo el modelo: el equipo de integración publica, los consumidores se sirven solos.

Monetize añade una capa más: los Rate Plans. Se definen modelos de cobro asociados al Product —por volumen de llamadas, por tramo, freemium con tier gratuito más pago por exceso, suscripción mensual plana—, y el sistema factura según consumo. SAP no incluye la pasarela de pago; se integra con SAP Subscription Billing o con sistemas externos (Stripe, por ejemplo) según el caso de uso.

Monetizar APIs no tiene sentido para todos los escenarios. Internamente, Rate Plans se usan más como mecanismo de chargeback entre áreas o como control de consumo entre partners estratégicos. Cuando el escenario sí es comercial —datos que vendes a clientes, integraciones que cobras a partners—, esta parte de la plataforma es lo que cierra el círculo entre IT y línea de negocio.

Takeaways prácticos

• Activar API Management es media hora; configurar bien el gobierno es el trabajo real. Dedícale más tiempo a Providers, policies y productos que al clic de Activate.
• Nunca expongas un backend sin proxy en medio. Aunque al principio parezca overhead, el día que tengas que cambiar autenticación, limitar consumo o cambiar de backend lo agradecerás.
• Primer par de policies obligatorias: VerifyAPIKey + Quota. Sin esto, cualquier API es un problema de seguridad esperando a ocurrir.
• Role collections antes que experimentación. Si algo no funciona en el Portal, el 80% de las veces es un tema de permisos, no un bug.
• Piensa en Products desde el diseño. Un buen Product agrupa proxies que el consumidor externo entiende como un todo, no los proxies que tú mantienes juntos por razones internas.
• Analytics no es opcional. Una API en producción sin dashboards revisados es riesgo puro.
• Non-Production vs Production importa. Elegir mal el tipo de runtime al activar tiene coste: uno no cumple SLA y el otro cuesta más si no vas a usarlo.

Este artículo está basado en el video WEBINAR SAP API MANAGEMENT – Activación, Entorno y Configuración inicial del canal de Logali Group en YouTube.