Cómo hace SAP para llamarte a TI: webhooks y eventos para quien viene del mundo “pull”

Si llevas años integrando SAP, tienes un instinto grabado a fuego: cuando necesitas un dato, tú llamas a SAP. Lanzas una BAPI, ejecutas una RFC, haces un GET contra un servicio OData. La flecha siempre apunta en la misma dirección: de ti hacia el sistema. Preguntas, y SAP responde.

Esa mentalidad —la del pull (tirar del dato)— resuelve la mitad del trabajo de integración. La otra mitad, la más potente, ocurre cuando inviertes la flecha: cuando es SAP, o el sistema que orbita a su alrededor, quien te llama a TI. Cuando se aprueba un pedido, se contabiliza una factura o entra una orden de un canal externo, y un evento dispara tu automatización sin que tú hayas preguntado nada.

Esta es, sin exagerar, la pregunta que más se repite cuando un consultor SAP descubre n8n: “vale, ya sé leer y escribir en SAP… pero ¿cómo hago para que SAP me avise a mí cuando pasa algo?”. Es un cambio de chip más grande de lo que parece, porque el mundo SAP tradicional rara vez trabaja con eventos entrantes hacia herramientas externas.

En este artículo invertimos la flecha. Vamos a explicar el modelo push (empujar) con una analogía que cualquier persona de SAP entiende a la primera, vamos a aterrizar los cuatro patrones reales por los que SAP puede disparar n8n, y vamos a desmontar el error tonto que descarrila más demos de webhooks que ningún otro.

Pull vs Push: dos formas opuestas de mover un dato

Antes de tocar nada, conviene fijar el marco mental. Hay dos maneras de que dos sistemas intercambien información, y son simétricas.

En el modelo pull (sondeo), tú tomas la iniciativa. Preguntas activamente: “¿hay pedidos nuevos? ¿hay facturas pendientes?”. Es lo que haces toda la vida con un GET de OData o con una BAPI de lectura. El control es tuyo, pero a costa de preguntar una y otra vez, aunque no haya nada nuevo.

En el modelo push (notificación), la iniciativa la toma el otro. No preguntas: te avisan. El otro sistema te golpea la puerta justo en el instante en que ocurre algo relevante. No hay sondeo, no hay espera activa, no hay desperdicio: reaccionas solo cuando hay motivo.

Qué es un webhook, explicado para gente de SAP

Olvida por un momento la palabra. Un webhook (gancho web) es, simplemente, lo contrario de llamar a un endpoint.

Cuando haces una llamada OData normal, tú conoces la URL de SAP y le pegas a esa URL para pedirle algo. Con un webhook le das la vuelta: eres tú quien expone una URL, y es otro sistema el que te llama a ti cuando ocurre un evento. n8n se queda ahí, vivo, esperando a que alguien le golpee esa dirección.

La analogía que mejor funciona con audiencia SAP es esta:

Un webhook es lo contrario de un BAdI. Cuando trabajas con un BAdI, tú llamas y SAP responde dentro de su propio proceso. Con un webhook, SAP —o cualquier sistema externo— te llama a TI, hacia fuera. Y se parece muchísimo a un IDoc entrante: un evento de negocio que llega a tu sistema y dispara un proceso, sin que tú lo hayas pedido.

Si ya has procesado IDocs entrantes, ya entiendes el modelo push. Solo cambia el destino: en lugar de que el evento aterrice en otro SAP, aterriza en una URL de n8n que reacciona al instante.

En n8n esto se materializa con el nodo Webhook (o, en general, un trigger (disparador) de entrada). Lo das de alta, n8n te genera una URL, se la entregas al sistema que va a avisarte, y a partir de ahí cada vez que ese sistema dispare el evento, tu workflow arranca solo.

Los 4 patrones reales por los que SAP dispara n8n

Aquí está el corazón del asunto. “SAP me llama a mí” no es una sola cosa: hay cuatro patrones, y cuál te toca depende de tu paisaje (ECC clásico, S/4HANA, BTP, Integration Suite). Te los ordeno del más universal al más específico.

Conviene matizar cada uno:

El patrón 1, polling (sondeo), no es push de verdad: sigues preguntando tú. Pero es honesto reconocer que es el que resuelve el 80% de los casos. No necesita BTP, no necesita CPI, no necesita desarrollo ABAP. Un Schedule Trigger cada N minutos lanzando un GET con $filter por fecha de creación o por estado, y listo. Funciona incluso en un ECC viejo sin nada montado encima. Cuando dudes, empieza por aquí.

El patrón 2, Event Mesh / Business Events, es el push nativo de SAP en la nube. SAP publica el evento de negocio en un topic y n8n se suscribe. Es elegante y en tiempo real, pero exige tener BTP en juego.

El patrón 3, vía CPI, es el que verás en las casas grandes. Si el cliente ya tiene SAP Integration Suite desplegada, lo natural es que el cambio o el IDoc salga por ahí y CPI haga de orquestador, reenviando un POST limpio a tu webhook de n8n. No reinventas nada: te enchufas al middleware que ya existe.

El patrón 4, handler ABAP custom, es el camino del desarrollo a medida. Un programa Z, expuesto como servicio por SICF, que ante un evento (un BAdI, un punto de salida, un cambio en una tabla) construye el payload y hace un HTTP POST contra la URL de n8n. Es la opción para ECC on-premise sin Event Mesh cuando el cliente quiere control total.

El error que descarrila la demo: URL de test vs URL de producción

Aquí viene el detalle que cuesta horas de depuración a quien estrena webhooks, y que conviene grabarse antes de tocar un solo nodo. El nodo Webhook de n8n no expone una URL, expone dos, y se comportan de forma radicalmente distinta.

Y el anti-patrón a memorizar, porque es el “404 silencioso” más común del mundo:

Si copias la URL de producción y el workflow no está activo, vas a recibir un 404 silencioso: nadie escucha. Y si copias la URL de test pero no le has dado a “Listen for test event”, tampoco responde nadie. El emisor pega a la puerta y no hay nadie en casa.

Cuando algo “no llega” en un webhook, lo primero que tienes que mirar no es el código ni el payload: es si estás usando la URL correcta para el estado en el que está el workflow. Test sin escuchar, o producción sin activar, explican la inmensa mayoría de los “no me funciona”.

Un ejemplo concreto: factura entrante → procesar → notificar a Teams

Bajemos a tierra con un caso reproducible. Quieres que, cuando un sistema externo dé de alta una factura o un pedido, n8n lo reciba, lo procese y avise al equipo en Microsoft Teams. Como no siempre tienes el sistema emisor a mano para probar, montamos también un segundo workflow “llamador” que simula ese POST. Es el patrón llamador / receptor.

Lo elegante de este montaje es que separa con nitidez los tres caminos posibles: el feliz (documento válido → 200 y notificación de éxito en Teams), el de error de negocio (SAP rechaza → 502 y alerta en Teams) y el de validación temprana (payload incompleto → 400 sin llegar a tocar SAP). Y todo arranca por push: nadie ha sondeado nada; el receptor simplemente reaccionó a un evento que le llegó.

Un apunte de diseño que sale siempre: si los dos workflows son tuyos y viven en la misma instancia de n8n, no uses webhook entre ellos: usa un sub-workflow, que se ejecuta de forma interna y es más eficiente. El webhook es para que te hablen sistemas que no son tuyos (un canal externo, un middleware, el handler ABAP), o para simular ese escenario en una demo como esta.

Buenas prácticas para webhooks en producción

Recibir eventos abre tu integración al mundo, y eso obliga a un puñado de disciplinas que no son negociables en un entorno serio.

Conclusión

El consultor que solo sabe “llamar a SAP” automatiza la mitad del mundo: la mitad en la que él toma la iniciativa. Vive cómodo en el pull —BAPI, RFC, OData GET— y resuelve mucho, pero se pierde todo lo que ocurre cuando no está mirando.

El que entiende el push deja que SAP trabaje para él. No sondea: espera, y reacciona en el instante exacto en que un pedido se aprueba o una factura se contabiliza. Empieza por el polling si tu paisaje es modesto, sube a Event Mesh o a CPI cuando el cliente lo tenga, y reserva el handler ABAP para cuando necesites control total. Pero el cambio de mentalidad es el mismo en los cuatro casos: dejar de ser quien pregunta para convertirte en quien es avisado.

La flecha que cambia el juego no apunta hacia SAP. Apunta hacia ti.

Fuentes

• Webhook node — n8n Docs
• SAP Event Mesh / SAP Business Events — SAP Help Portal
• Business Add-Ins (BAdI) e IDoc — SAP Help Portal
• avanai SAP Connect — Trigger node