Extender un SAP ECC de 20 años sin exponerlo

Una capa de integración desacoplada es el conjunto de servicios que se sitúa entre un ERP legado y los canales digitales que necesitan sus datos (tiendas en línea, portales B2B, aplicaciones de ventas, analítica, agentes de IA) y que resuelve para todos ellos lo que ninguno debería resolver por su cuenta: traducir el modelo de SAP, controlar quién accede a qué, proteger la carga sobre el ERP y elegir la forma de interacción correcta para cada caso. Es la manera de extender un SAP ECC, una plataforma cuya generación tecnológica acumula alrededor de 20 años de obsolescencia, sin exponerlo y sin esperar a reemplazarlo. SAP sigue siendo el sistema de registro, y cada canal nuevo se conecta a la capa, nunca al ERP. La diferencia es aritmética: con cinco canales conectados directamente hay cinco acoplamientos distintos a las estructuras internas de SAP, y cada cambio se revisa cinco veces. Con la capa hay uno, y la migración a S/4HANA (con el mantenimiento estándar de ECC terminando a finales de 2027) cambia adaptadores, no canales.

Este artículo es el marco general. Los detalles de implementación están en SAP ECC como API, sobre la capa anti-corrupción que traduce el modelo de SAP, y en seguridad de una API sobre SAP, sobre los controles de cada frontera.

¿Qué significa extender un ERP con 20 años de obsolescencia?

SAP ECC 6.0 es tecnología de mediados de la década de 2000. Su modelo de datos y sus interfaces se diseñaron antes del iPhone, cuando AWS apenas lanzaba sus primeros servicios y la integración empresarial significaba sistemas corporativos hablando entre sí dentro de la misma red. Una instalación concreta puede llevar algo más de una década en producción, pero la plataforma sobre la que corre acumula alrededor de 20 años de obsolescencia, y el propio calendario de SAP lo deja claro:

Visto así, el sistema tiene dos relojes: alrededor de 20 años hacia atrás y, desde 2026, entre uno y cuatro años de soporte hacia adelante. Los dos empujan en la misma dirección.

La obsolescencia se nota primero en las interfaces

RFC, BAPI e IDoc son mecanismos de su época: eficientes y probados para integrar sistemas SAP entre sí, pero ajenos a lo que un canal digital espera hoy (HTTP, JSON, OAuth, eventos). Conectar un e-commerce directamente a ellos no moderniza el ERP; traslada su antigüedad al canal, que queda obligado a hablar el idioma de hace dos décadas.

Y después en el riesgo

Cuanto más viejo es el núcleo, más caro resulta cada acoplamiento nuevo, porque cada uno se suma a lo que la migración tendrá que desenredar, y menos razonable es acercarlo a internet. Veinte años de obsolescencia no se corrigen conectando canales modernos al ERP: se aíslan detrás de una capa que habla el idioma actual hacia afuera y el de SAP hacia adentro. Esa es la función de la capa de integración, y la razón por la que se vuelve más urgente cuanto más antiguo es el sistema que protege.

¿Reemplazar, exponer o extender?

Cuando un ERP legado se encuentra con la demanda digital (el e-commerce necesita stock, los clientes quieren sus pedidos en su propio sistema, la fuerza de ventas quiere consultar crédito desde el teléfono), la organización tiene tres caminos. Casi nunca los compara de forma explícita.

Exponer directo gana siempre la primera comparación, y por eso es el camino por defecto. Su costo no aparece en el primer proyecto sino en el tercero, cuando cada canal resolvió a su manera la autenticación, los reintentos y la conversión de códigos de material, y un cambio en una función ABAP rompe dos integraciones que nadie sabía que la usaban. Reemplazar primero es la opción correcta en el papel y la más cara en la práctica: congela la agenda digital durante toda la migración. Cómo responder a esa agenda mientras el equipo de SAP conduce la migración, sin estorbarle, lo desarrollo en el negocio no espera a S/4HANA.

Gartner describe esta tensión con su estrategia de capas de ritmo (pace layering): los sistemas de registro cambian despacio y deben hacerlo; los sistemas de diferenciación e innovación cambian rápido y necesitan hacerlo. La capa de integración es la bisagra que permite que ambos ritmos convivan sin que el rápido desestabilice al lento ni el lento frene al rápido.

¿Qué posee la capa y qué no debe poseer nunca?

Una capa de integración fracasa de dos formas opuestas: haciendo demasiado poco, y entonces es un proxy con otro nombre, o haciendo demasiado, y entonces se convierte en un segundo ERP. El límite se traza por propiedad.

Lo que la capa posee

• Los contratos: el catálogo cerrado y versionado de capacidades que consumen los canales.
• La traducción: las correspondencias entre identificadores, unidades y códigos de SAP y los del contrato.
• La identidad de los canales: quién es cada consumidor, qué alcances tiene y cuánta carga puede generar.
• La protección del ERP: límites de concurrencia, colas, cachés y circuit breakers.
• Los modelos de lectura replicados: copias derivadas para las consultas que no deben tocar SAP en línea.
• La trazabilidad: la correlación entre la petición de un canal y lo que ocurrió en SAP.

Lo que nunca debe poseer

La verdad de negocio. El stock, el precio, el límite de crédito y el estado de un pedido viven en SAP; la capa solo los transporta o los copia con fecha de corte. La trampa más frecuente es reimplementar reglas de SAP fuera de SAP: calcular precios en la capa «para no llamar al ERP» y replicar a medias una determinación de precios con condiciones, escalas y excepciones acumuladas durante años. El resultado son dos fuentes de verdad que discrepan justo en los casos que más importan. Si una regla de negocio vive en SAP, la capa consulta su resultado o lo replica; no la vuelve a escribir.

¿Cuáles son las cuatro formas de hablar con SAP?

Un canal digital no «se integra con SAP» en abstracto. Cada interacción tiene una forma, y cada forma pide un patrón distinto. Tratarlas todas como llamadas síncronas es el error que más daño hace.

Consultas: cuando el canal necesita el dato ahora

Stock disponible, límite de crédito, estado de un pedido. El canal llama a la API, la capa ejecuta una función RFC concreta y devuelve la respuesta traducida, con un caché corto y un techo de concurrencia que protege al ERP. Es el patrón que desarrollo en SAP ECC como API, junto con la razón por la que nunca debe convertirse en un proxy genérico de BAPIs.

Comandos: cuando el canal necesita que algo ocurra en SAP

Crear un pedido desde el e-commerce es otra clase de problema. Encadenar el checkout a una llamada síncrona contra SAP significa que cualquier lentitud del ERP se convierte en un carrito abandonado, y que un timeout deja al cliente sin saber si compró. El patrón correcto es asíncrono: el canal entrega el pedido y recibe un 202 Accepted con un identificador; la capa lo encola para que un procesador lo cree en SAP al ritmo que el ERP tolere; cuando SAP devuelve el número de documento, la capa publica un evento y el canal se entera.

Lo difícil es que ese procesador va a recibir duplicados. Las colas estándar como Amazon SQS entregan cada mensaje al menos una vez, los reintentos existen, y una BAPI de creación no sabe que ya creó ese mismo pedido hace diez segundos. La idempotencia no es opcional:

def crear_pedido(pedido):
    ref = pedido["id_canal"]
    try:
        tabla.put_item(
            Item={"ref": ref, "estado": "EN_CURSO"},
            ConditionExpression="attribute_not_exists(ref)",
        )
    except tabla.meta.client.exceptions.ConditionalCheckFailedException:
        return resolver_existente(ref)  # ya creado, o un intento anterior quedó a medias
 
    r = conn.call(
        "BAPI_SALESORDER_CREATEFROMDAT2",
        ORDER_HEADER_IN={**cabecera(pedido), "PURCH_NO_C": ref},
        ORDER_PARTNERS=socios(pedido),
        ORDER_ITEMS_IN=posiciones(pedido),
    )
 
    if any(m["TYPE"] in ("E", "A") for m in r["RETURN"]):
        conn.call("BAPI_TRANSACTION_ROLLBACK")
        marcar(ref, "RECHAZADO", r["RETURN"])  # error de negocio: a revisión, no a reintento
        return
 
    conn.call("BAPI_TRANSACTION_COMMIT", WAIT="X")
    marcar(ref, "CREADO", documento=r["SALESDOCUMENT"])

Tres detalles de ese código merecen atención. Las BAPIs que escriben no confirman nada por sí solas: sin BAPI_TRANSACTION_COMMIT, invocada en la misma conexión, el pedido no existe. La referencia del canal viaja también dentro de SAP, en el número de pedido del cliente (PURCH_NO_C), para que la conciliación pueda buscarla desde cualquiera de los dos lados. Y el caso ambiguo, cuando el procesador murió después de confirmar en SAP pero antes de actualizar su registro, se resuelve consultando SAP por esa referencia antes de reintentar, nunca reintentando a ciegas.

Eventos: cuando el canal necesita enterarse de un cambio

Un precio que cambia, un cliente nuevo, un pedido que se despacha. S/4HANA tiene eventos de negocio nativos; ECC no, y hay que construirlos. Hay dos fuentes razonables.

La primera son los IDocs de salida. ECC puede emitir un IDoc cuando cambia un dato maestro, mediante punteros de cambio (MATMAS para materiales, DEBMAS para clientes), o cuando un documento de ventas dispara su determinación de mensajes, y enviarlo por HTTP a un endpoint privado de API Gateway alcanzable solo desde la red corporativa. La segunda, cuando configurar IDocs no es viable, es la consulta programada de deltas sobre los documentos de modificación (CDHDR y CDPOS), siempre acotada por fecha.

En ambos casos la capa normaliza el cambio a un evento de negocio (PrecioActualizado, PedidoDespachado) y lo publica en un bus como Amazon EventBridge. Los canales se suscriben al bus, no a SAP. Agregar un consumidor nuevo no requiere tocar el ERP, ni siquiera avisarle.

Réplicas: cuando el canal necesita volumen, no inmediatez

Catálogo completo, histórico de compras, reportería. Nada de eso debe consultarse contra SAP en el momento en que un canal lo pide. La capa mantiene copias derivadas, alimentadas por extracciones programadas y por los mismos eventos: el catálogo publicable en una base de lectura y el histórico en Parquet sobre S3 consultado con DuckDB, como en el lakehouse serverless sobre Lambda. Cada copia declara su fecha de corte, porque una réplica sin fecha es una fuente de verdad falsificada.

Resumen de los cuatro patrones

¿Qué cambia cuando el consumidor es un agente de IA?

Los agentes de IA son el canal digital más reciente y el que más presión pone sobre esta arquitectura, porque la tentación es darles acceso amplio «para que puedan resolver cualquier pregunta». Un agente con una herramienta capaz de ejecutar cualquier función RFC es el proxy genérico de BAPIs, pero con un modelo de lenguaje eligiendo los parámetros.

La capa resuelve el problema sin diseño adicional. Un agente es un canal más: tiene su propio cliente de aplicación, alcances de solo lectura y sus propios límites de tráfico. Sus herramientas son los mismos endpoints cerrados que usan los demás canales. Si el agente necesita crear algo en SAP, pasa por el patrón de comandos, con una aprobación humana antes de encolar.

Lo que hace segura una API para un cliente B2B, una lista cerrada de capacidades con contrato, es exactamente lo que la hace segura para un agente. Es el mismo criterio con el que decido cuándo la IA aplicada aporta valor y cuándo es ruido: la IA propone, y el sistema de registro no queda a merced del modelo.

¿Cómo evita la capa que el núcleo se siga ensuciando?

SAP llama clean core a su estrategia para S/4HANA: mantener el núcleo del ERP lo más cerca posible del estándar y llevar las extensiones fuera de él. En un ECC con años de desarrollos Z acumulados sobre una plataforma de hace dos décadas, ese principio llega tarde para el pasado, pero no para lo que viene.

La regla que aplico es simple: código ABAP nuevo solo cuando expone una capacidad de negocio, nunca cuando sirve a un canal. Una función RFC que devuelve el stock de una bodega es una capacidad; la usarán el portal B2B, el e-commerce y el agente. Una función que devuelve el stock «en el formato que necesita la tienda» es deuda con fecha de vencimiento: pertenece a un canal, se rompe cuando el canal cambia y habrá que migrarla a S/4HANA sin que nadie recuerde para qué existía. Formatear, combinar y adaptar es trabajo de la capa.

¿Cuándo no conviene construirla?

• Hay una sola integración y no hay una segunda a la vista. Una capa para un único consumidor es sobrediseño. Lo que sí conviene es construir ese único adaptador con un contrato propio, para que pueda convertirse en la capa si llega el segundo canal.
• Ya existe una plataforma de integración operada. Si la empresa tiene SAP BTP Integration Suite y un equipo que la domina, extenderla puede salir más barato que construir en AWS. SAP Process Orchestration es un caso distinto: su horizonte de mantenimiento está ligado al de ECC, así que sirve como punto de partida, no como destino.
• No hay dueño. Una capa sin equipo que la opere, sin catálogo de contratos y sin nadie que diga que no a los atajos se degrada en el peor resultado posible: un legacy nuevo delante del legacy viejo.

La capa es un producto, no un proyecto

Un proyecto termina; la capa no. Cada canal que se conecta es una incorporación con pasos conocidos, y escribirlos es lo que evita que el tercer canal se conecte «solo esta vez» directo a SAP:

1. Identificar qué capacidades del catálogo necesita el canal y cuáles faltan.
2. Diseñar las que falten como capacidades genéricas, no como adaptaciones a ese canal.
3. Clasificar cada interacción del canal: consulta, comando, evento o réplica.
4. Registrar el canal como cliente, con sus alcances y sus límites de tráfico.
5. Acordar la versión del contrato y el medio por el que se avisarán los cambios.
6. Definir sus alarmas: errores, latencia y consumo de cuota.

Un catálogo de capacidades, un dueño y una lista de incorporación parecen burocracia hasta que se comparan con la alternativa: descubrir, en plena migración a S/4HANA, cuántos sistemas dependían de una función Z que nadie documentó.

Extender, no exponer ni reemplazar

Un ERP con 20 años de obsolescencia no se moderniza exponiéndolo, y la empresa no puede esperar a reemplazarlo para crecer. La idea completa cabe en una frase: SAP sigue siendo el sistema de registro, la capa de integración es el sistema de extensión, y los canales digitales solo conocen a la segunda. Ninguna pieza de esta arquitectura es novedosa por separado; colas, eventos, APIs y réplicas existen hace décadas. Lo que la hace funcionar es la disciplina de que cada cambio que pide un canal se resuelva en la capa y no en el ERP, y que esa disciplina tenga dueño.

Si tu organización tiene un ERP que todavía no puede reemplazar y canales digitales que no pueden esperar, y quieres contrastar cómo extenderlo, puedes escribirme por LinkedIn.