SAP tiene cuatro puertas de salida y elegir mal la puerta es lo que hace que una integración funcione en la demo y falle en producción. La pregunta que ordena la elección no es cuál es más moderna, sino si necesitas una respuesta inmediata o aguante.
Síncrono o asíncrono: la única pregunta que importa
Una interfaz síncrona espera respuesta: mandas el pedido, SAP lo procesa y te dice al instante si entró o si lo rechazó por crédito. El vendedor se entera en pantalla. Una interfaz asíncrona no espera: deja el mensaje y sigue. SAP lo procesa cuando puede, y si algo falla te enteras después.
Lo síncrono es lo que necesitas cuando alguien está esperando del otro lado: crear un pedido, consultar disponibilidad, validar crédito. Lo asíncrono es lo que necesitas cuando el volumen importa más que la inmediatez: cargar el catálogo, sincronizar miles de clientes, avisarle a varios sistemas a la vez. Ninguna es mejor: son para cosas distintas.
La prueba práctica para clasificar cualquier flujo cabe en una pregunta: si esto falla, ¿alguien está mirando una pantalla esperando el resultado? Si la respuesta es sí, va síncrono y necesitas mostrar el error en esa pantalla. Si la respuesta es no, va asíncrono y necesitas una cola donde el error quede visible para quien lo revise después. Confundir las dos es lo que produce el peor de los mundos: un vendedor que ve "pedido enviado" sobre un mensaje que quedó atascado.
OData: la puerta moderna
Es la interfaz de estilo web de SAP, la que más se parece a integrar con cualquier herramienta actual. Es síncrona, devuelve confirmación inmediata y es la que S/4HANA impulsa y expone mejor. Si tu instalación es S/4HANA —y sobre todo si es la nube pública— OData va a ser el eje de tu integración, porque además es de lo poco que queda habilitado.
Su límite es el volumen: no es la herramienta para empujar cien mil registros de una vez. Para la carga inicial del catálogo o de la base de clientes vas a querer paginar, respetar los límites de llamadas y correrla en horario de baja carga. Meter el maestro completo de materiales de golpe contra un límite de API es la manera clásica de estrenar la integración con una falla.
IDoc: el lote que aguanta
Es el formato clásico de intercambio de SAP y sigue siendo el caballo de batalla de las instalaciones ECC. Es asíncrono y orientado a lotes: brilla moviendo volumen y sobrevive a que el otro sistema esté caído, porque el mensaje queda en cola.
Su contra es la que te va a doler si lo usas mal: no hay confirmación inmediata. El pedido "se envió" no significa que entró. Si tu flujo necesita que el vendedor sepa en el momento si SAP aceptó, IDoc solo no alcanza. Y ojo: S/4HANA Cloud pública no lo habilita.
Hay algo más que conviene saber ahora y no en producción: cada IDoc lleva un estado dentro de SAP, y ese estado vive en SAP, no en tu integración. Un IDoc procesado y uno rechazado por validación se ven exactamente igual desde afuera. Quién revisa esa bandeja y con qué frecuencia es una decisión que se toma en el paso 7, pero se diseña acá: si eliges IDoc, estás eligiendo también que alguien tenga que mirar del lado de SAP.
BAPI, RFC y eventos: la puerta vieja y la nueva
BAPI y RFC son las llamadas de función internas de SAP. Son síncronas, transaccionales y muy directas: sirven para operaciones puntuales contra un consumidor único. Su problema es el acoplamiento —quedas atado a la firma exacta de esa función— y que la nube pública las bloquea. Si tu instalación es ECC, van a aparecer en la propuesta y no está mal.
Los eventos son el otro extremo: SAP publica que algo pasó y varios sistemas se enteran en segundos, sin que SAP tenga que saber quiénes son. Es lo indicado cuando el mismo hecho —un pedido se despachó— tiene que llegar al CRM, al servicio al cliente y al tablero, sin encadenar tres integraciones distintas.
El punto donde los eventos se pagan solos es el cuarto consumidor. Con uno o dos sistemas escuchando, montar la infraestructura de eventos es esfuerzo de más. Con cuatro o cinco, la alternativa —una integración punto a punto por cada uno— se vuelve imposible de mantener: cada cambio en SAP obliga a tocar cinco lugares. Si tu hoja de ruta a dos años incluye sumar sistemas alrededor de SAP, conviene evaluarlo desde el principio aunque el primer flujo no lo necesite.
Si tu SAP es Business One, las puertas son otras: la Service Layer (OData, síncrona) para prácticamente todo, y la DI API para lo que no cubra. La pregunta que ordena la elección —¿hay alguien esperando en pantalla?— es exactamente la misma; lo que cambia es que tienes una sola puerta síncrona, así que el volumen se resuelve paginando y programando cargas, no cambiando de protocolo.
Elegir IDoc para un flujo donde el vendedor espera respuesta en pantalla no es un error técnico: es un error de expectativa que se descubre el primer día en producción.
Errores comunes en este paso
- Un solo protocolo para todo el proyecto. Lo normal y sano es combinar: OData para lo que espera respuesta, lotes para el volumen.
- Diseñar sobre IDoc sin confirmar la versión. Si es nube pública, ese diseño no se puede construir.
- Prometer tiempo real sobre una interfaz asíncrona. El mensaje encolado no es el pedido confirmado.
- Apoyarse en BAPI a medida. Cuanto más se personaliza la llamada, más caro sale el día de la actualización.
Checklist antes de pasar al siguiente
- Cada flujo clasificado como síncrono o asíncrono, según quién espera del otro lado.
- Protocolo asignado por flujo, no uno solo para todo.
- Confirmación de que cada protocolo elegido está habilitado en tu versión.
- Definido qué ve el usuario cuando SAP rechaza una operación.
- Límites de volumen y de llamadas conocidos y documentados.
Con las puertas elegidas, falta decidir quién las opera: paso 5, quién orquesta. O vuelve a la guía completa.