Exponer un SAP ECC mediante una API no significa darle acceso al ERP a un tercero. Significa lo contrario: SAP permanece aislado como sistema de registro y lo que se publica es una capacidad de negocio, como «consultar el inventario de mi bodega virtual», detrás de un contrato REST que no menciona RFC, BAPIs ni tablas. La pieza que lo hace posible es una capa anti-corrupción: un servicio intermedio, aquí una función Lambda en AWS, que recibe peticiones en el lenguaje del cliente, ejecuta una función RFC concreta y devuelve la respuesta traducida a ese mismo lenguaje. La decisión pesa más en un ECC con más de una década en producción, cuyo mantenimiento estándar termina a finales de 2027: cada integración que hoy se acople a sus estructuras internas será mañana un frente más dentro de la migración a S/4HANA. Con la capa en medio, esa migración cambia el adaptador y deja intacto el contrato.
¿Por qué «darle acceso a SAP» es la pregunta equivocada?
El punto de partida es concreto. Clientes B2B quieren consultar, desde su propio ERP o su tienda en línea, el stock disponible en su bodega virtual: la porción del inventario que la empresa les tiene asignada. El dato vive en SAP ECC y ya existe una BAPI personalizada que lo devuelve por RFC. La tentación es resolverlo en ese mismo terreno: crear un usuario, abrir el acceso RFC y compartir la documentación de la función.
Basta enumerar lo que esa conversación tiene que responder para ver que el terreno es otro:
- ¿Cómo sabe el cliente qué parámetros enviar y cómo interpretar lo que recibe?
- ¿Qué impide que consulte la bodega virtual de otro cliente?
- ¿Qué le pasa a SAP si un cliente lanza diez mil consultas en una hora?
- ¿Qué recibe el cliente cuando SAP está lento o no responde?
- ¿Cómo se revoca a un cliente, y cómo se audita quién consultó qué?
- ¿Qué ocurre con todas esas integraciones el día que SAP cambie?
Ninguna de esas preguntas se responde con un mecanismo de acceso a SAP. Un usuario RFC puede restringirse, pero no sabe de clientes, de cuotas ni de contratos. Son preguntas que corresponden a una capa que todavía no existe, y el diseño consiste en construirla.
¿Qué es una capa anti-corrupción?
Una capa anti-corrupción (anti-corruption layer) es un componente de traducción que aísla el modelo de un sistema del modelo de otro, de modo que los conceptos, formatos y errores del primero no se filtren al segundo. El término viene del diseño guiado por el dominio de Eric Evans y describe con exactitud la relación con un ERP legado: SAP tiene su propio idioma, coherente y con más de tres décadas de historia, y ningún consumidor externo debería verse obligado a aprenderlo.
Frente a SAP, la capa traduce en tres dimensiones.
Traduce identificadores y unidades
SAP guarda los números de material numéricos con ceros a la izquierda (000000000000012345 en lugar de 12345) porque así opera su rutina de conversión interna. Las unidades de medida tienen un código interno y otro externo que depende del idioma: la pieza es ST en la base de datos y PC en la pantalla de un usuario en inglés. Una bodega se identifica por la combinación de centro y almacén, dos códigos que solo significan algo dentro de la configuración de esa instalación concreta.
Nada de eso debe llegar al cliente. La capa mantiene la tabla de correspondencias (qué centro y qué almacén forman la bodega BODEGA-123, qué número de material corresponde al SKU SKU-001) y es el único lugar del sistema donde esa correspondencia existe.
Traduce errores
Las BAPIs no fallan como falla una API moderna. Por convención, una BAPI que no encuentra lo que se le pide no lanza una excepción: termina con normalidad y devuelve una tabla RETURN con mensajes, cada uno con un tipo (S éxito, I información, W advertencia, E error, A cancelación). Un consumidor que solo verifique que la llamada no falló dará por buena una respuesta vacía.
La capa inspecciona esa tabla y la convierte en semántica HTTP. En Python, con nombres de función y parámetros ilustrativos:
resultado = conn.call("Z_STOCK_BODEGA_VIRTUAL", I_WERKS=centro, I_LGORT=almacen)
errores = [m for m in resultado["RETURN"] if m["TYPE"] in ("E", "A")]
if errores:
# La llamada RFC "funcionó": el error llega como dato, no como excepción.
log.warning("sap_return_error", extra={"mensajes": errores})
return respuesta(502, {"error": "inventory_unavailable"})El texto del mensaje de SAP se registra, pero no se devuelve. Un mensaje interno del ERP no le sirve al cliente y sí le sirve a quien esté mapeando el sistema desde fuera.
Traduce el tiempo
Una respuesta de SAP es una fotografía del momento en que se ejecutó la función. Para proteger al ERP casi siempre conviene introducir caché, y si la capa lo hace, el contrato debe decirlo. Un campo asOf con la hora de la lectura convierte una decisión técnica invisible en un dato que el cliente puede usar.
El contrato resultante es deliberadamente aburrido:
{
"warehouse": "BODEGA-123",
"asOf": "2026-09-14T15:42:10Z",
"items": [
{ "sku": "SKU-001", "description": "Producto A", "unit": "PC", "availableStock": 125 },
{ "sku": "SKU-002", "description": "Producto B", "unit": "PC", "availableStock": 87 }
]
}Para consumirlo, el cliente necesita conocer HTTPS, JSON y OAuth 2.0. No necesita saber que existe SAP. Los precios, por cierto, no van en esta respuesta: son condiciones comerciales específicas de cada cliente, con su propio alcance de autorización, y merecen un endpoint aparte.
¿Por qué no construir un proxy genérico de BAPIs?
Hay una versión de esta arquitectura que parece más eficiente y es la más peligrosa: un único endpoint que recibe el nombre de la función y sus parámetros.
{ "function": "Z_ALGO", "parameters": { "I_WERKS": "1000" } }Se construye una vez y sirve para cualquier integración futura. También es, en la práctica, un gateway RFC publicado en internet. Su superficie de ataque deja de ser lo que la empresa decidió exponer y pasa a ser todo lo que el usuario técnico puede ejecutar. El contrato vuelve a ser el modelo de SAP, así que cada consumidor queda acoplado a nombres de funciones y estructuras ABAP. Y la autorización por cliente se vuelve imposible de razonar, porque no hay casos de uso sobre los cuales razonar: solo llamadas.
La regla que sigo es la contraria: un endpoint, una capacidad de negocio, una función SAP concreta. La lista es cerrada y crece por decisión explícita, nunca por parámetro.
| Endpoint | Capacidad de negocio | Qué ejecuta detrás | Alcance requerido |
|---|---|---|---|
GET /v1/inventory/{warehouse} | Stock disponible de una bodega virtual | Una función RFC de lectura de stock | b2b/inventory.read |
GET /v1/prices/{warehouse} | Precios vigentes para ese cliente | Una función RFC de condiciones de precio | b2b/prices.read |
GET /v1/products | Catálogo publicable | Una copia replicada del catálogo, sin tocar SAP en línea | b2b/catalog.read |
Agregar una capacidad cuesta un endpoint nuevo, una revisión y un despliegue. Ese costo es el control, no un defecto del diseño.
¿Cómo se ve la arquitectura?
La arquitectura separa tres zonas, y el tráfico cruza cada frontera en una sola dirección.
Terceros
El ERP o el e-commerce del cliente obtiene un token y llama a un dominio propio de la empresa, nunca a una dirección de SAP ni a la URL que genera AWS por defecto. Así el contrato no depende de la infraestructura que lo sirve.
AWS: exposición y negocio
API Gateway recibe la petición, aplica límites de tráfico y delega la validación del token en un autorizador. API Gateway es un servicio administrado: no vive dentro de la VPC, y los diagramas que lo dibujan ahí confunden dónde está en realidad la frontera de red.
La Lambda que implementa la capa anti-corrupción, en cambio, sí se conecta a subredes privadas de una VPC. Es el único componente con ruta hacia la red corporativa, y por eso es también el único que necesita permisos sobre SAP.
On-premise
SAP ECC acepta llamadas RFC únicamente desde esas subredes, a través de una VPN site-to-site o de Direct Connect. No tiene exposición a internet y no la necesita. Los controles de cada frontera (autenticación máquina a máquina, autorización por bodega, protección de la disponibilidad del ERP y el usuario RFC de mínimo privilegio) los desarrollo en seguridad de una API B2B sobre SAP.
¿Todo tiene que consultar SAP en tiempo real?
No, y confundir los dos tipos de pregunta es la forma más común de sobrecargar un ERP. La frescura que necesita cada consulta decide la ruta, y la ruta decide cuánta carga llega a SAP.
| Pregunta del cliente | Frescura que necesita | Ruta | Carga sobre SAP |
|---|---|---|---|
| ¿Cuánto stock hay ahora en mi bodega? | Segundos o minutos | API → Lambda → RFC, con caché corto | Una llamada por bodega y ventana de caché |
| ¿Qué precios tengo vigentes? | Minutos u horas | API → Lambda → RFC, con caché más largo | Baja |
| ¿Cuánto compré en los últimos 12 meses? | Hasta el día anterior | Extracción programada a Parquet en S3, consulta con DuckDB | Una extracción diaria, fuera de horario |
La tercera fila es la que marca la diferencia. Una consulta de doce meses de ventas contra un ECC en horario laboral compite con la operación por los mismos procesos de trabajo. Extraída una vez al día a Parquet y servida desde DuckDB, se responde en milisegundos sin que SAP se entere. Es el mismo principio que apliqué en el lakehouse serverless con DuckDB sobre Lambda: desacoplar la lectura analítica del sistema transaccional. SAP queda como sistema operacional y la capa analítica vive en AWS.
¿Qué pasa el día que SAP deje de ser ECC?
SAP fijó el fin del mantenimiento estándar de ECC para finales de 2027, con una extensión opcional y de pago hasta 2030. Para una instalación con más de una década encima, la migración a S/4HANA no es una hipótesis: es una cuestión de calendario.
Con clientes conectados directamente a funciones RFC, esa migración hereda una lista de integraciones externas que revalidar, cada una con su propio equipo, sus plazos y su disposición a cambiar. Con una capa anti-corrupción, el trabajo se concentra en un solo lugar: el adaptador que hoy llama a una BAPI mañana llamará a una API de S/4HANA, y GET /v1/inventory/{warehouse} seguirá respondiendo exactamente lo mismo. Los clientes no se enteran de que el ERP cambió.
Ese es el argumento que más pesa ante una dirección: la capa no es un costo de la integración de hoy, sino un ahorro sobre la migración de mañana.
¿Qué no resuelve esta arquitectura?
Sería deshonesto presentarla sin su costo.
- Es un componente más que operar. Tiene despliegues, monitoreo, alarmas y alguien que responde cuando falla. Una conexión directa a SAP no tiene nada de eso, hasta el día en que falla.
- El contrato se vuelve un producto.
/v1es una promesa. Cambiar un campo exige versionar y sostener dos versiones mientras los clientes migran. - La tabla de correspondencias hay que mantenerla. Una bodega nueva en SAP que nadie registra en la capa es una bodega invisible para el cliente.
- No mejora los datos. Si el stock está mal en SAP, la API lo sirve mal, con mejor formato.
- La presión por filtrar SAP no desaparece. Llegará el pedido de «agregar solo este campo, tal como viene». Cada concesión es una pequeña corrupción del contrato, y la capa solo funciona mientras alguien la defienda.
Cómo lo presento ante seguridad y dirección
Cuando llevo este diseño a una revisión, no lo presento como «una API para conectarnos a SAP». Esa frase invita exactamente a las objeciones que el diseño resuelve, porque suena a abrir el ERP.
Lo presento como una capa de integración desacoplada que extiende un SAP ECC legado hacia ecosistemas digitales sin exponerlo. SAP sigue siendo el sistema de registro; AWS actúa como capa de integración, seguridad, exposición y analítica. Lo que reciben los clientes no es acceso a SAP, sino acceso controlado a capacidades de negocio originadas en SAP.
La diferencia no es retórica. El problema nunca fue «sacar el stock de SAP». El problema era cómo extender un ERP con más de una década en producción hacia terceros sin convertirlo en una dependencia directa de cada integración futura. Es el mismo criterio con el que abordo la integración en general cuando diseño plataformas empresariales en AWS: desacoplar para que un cambio de un lado no obligue a reescribir el otro.
Si estás por exponer datos de SAP a clientes, socios o canales digitales y quieres una segunda lectura del diseño, incluido qué no conviene exponer, puedes escribirme por LinkedIn.