En agosto de 1858, el primer cable telegráfico transatlántico consiguió que un mensaje cruzara el océano en minutos en lugar de semanas. La proeza duró poco: la señal era débil, los equipos no estaban bien adaptados y el cable dejó de funcionar tras unas semanas. La historia conservó el instante heroico; la ingeniería aprendió una lección más útil: transmitir una señal una vez no equivale a construir una comunicación fiable.
Muchas arquitecturas orientadas a eventos repiten hoy aquel error con herramientas más modernas. Un sistema SAP publica un evento, un broker lo transporta y una aplicación reacciona durante la demostración. Todo parece instantáneo. Después llegan la duplicidad, el consumidor detenido, un cambio de esquema, una cola saturada o una llamada a una API que termina en timeout. La pregunta importante no es si el evento viaja, sino qué sucede cuando el trayecto deja de ser perfecto.
El patrón que sigue propone una arquitectura reutilizable para conectar SAP S/4HANA, SAP Integration Suite y extensiones en SAP BTP. Su objetivo no es prometer un mítico “exactly once”, sino conseguir algo más defendible: entrega duradera, procesamiento idempotente, fallos visibles y recuperación ensayada.
Un evento no es una orden ni una copia de la base de datos
Un evento de negocio afirma que algo relevante ya ocurrió: un pedido fue creado, una entrega cambió de estado o un proveedor fue bloqueado. Conviene expresarlo en pasado y dotarlo de identidad, origen, tipo, versión y marca temporal. CloudEvents ofrece precisamente un sobre común para esos atributos. SAP CAP puede trabajar con este formato y completar campos estándar cuando se configura la mensajería correspondiente.
También hay que distinguir dos diseños:
- Evento de notificación: contiene la identidad del objeto y pocos datos. El consumidor consulta después el estado autorizado mediante una API.
- Evento de datos: incorpora la información necesaria para reaccionar sin una lectura adicional, a costa de aumentar tamaño, acoplamiento y exposición de datos.
La primera opción suele ser prudente cuando SAP S/4HANA es el sistema de registro y el dato cambia con frecuencia. La segunda puede ser mejor para alto volumen, autonomía temporal o consumidores que necesitan una instantánea histórica. No existe una elección universal: hay que decidir por evento y documentar quién es dueño de su contrato.
Arquitectura de referencia: cinco capas y una regla
1. El productor publica un hecho estable
SAP S/4HANA dispone de capacidades de Enterprise Event Enablement para intercambiar eventos mediante Event Mesh. En escenarios privados u on-premise, la configuración utiliza canales, destinos y OAuth 2.0; en SAP S/4HANA Cloud se configura la conectividad con el tenant y los servicios de SAP BTP. Antes de crear un evento personalizado conviene buscar eventos estándar en SAP Business Accelerator Hub.
El productor no debería conocer a los consumidores. Publica, por ejemplo, SalesOrder.Created.v1; no “avisa al microservicio logístico”. Esta separación permite añadir mañana una proyección analítica, un control de riesgo o un agente de IA sin modificar el núcleo. Es la misma disciplina que persigue clean core: extender mediante contratos publicados, no mediante dependencias ocultas.
2. El broker enruta; no gobierna el proceso
El topic describe la familia del evento y cada consumidor recibe su propia cola duradera. Así, una caída del consumidor de analítica no bloquea el flujo de logística. Las suscripciones pueden filtrar qué señales llegan a cada cola, pero la lógica de negocio compleja no debería quedar dispersa en reglas opacas del broker.
La capacidad Event Mesh de SAP Integration Suite admite AMQP, MQTT y HTTP. Su alcance publicado fija actualmente un mensaje máximo de 1 MB y 2 GB de almacenamiento total de colas. Para escenarios distribuidos, altos volúmenes, múltiples brokers y routing dinámico, SAP posiciona SAP Integration Suite, advanced event mesh. No son dos nombres para el mismo dimensionamiento: la segunda opción añade capacidad y coste operativo, por lo que debe justificarse con volumen, latencia, resiliencia regional o complejidad real.
3. El consumidor supone que habrá duplicados
Si el handler falla, la documentación de CAP indica que el broker puede reenviar el mensaje. Es la conducta correcta para no perderlo, pero obliga a diseñar el consumidor como idempotente. Cobrar dos veces, crear dos expediciones o enviar dos órdenes porque llegó dos veces el mismo evento no es un problema del broker: es un defecto del consumidor.
El patrón mínimo guarda el identificador de CloudEvents en una tabla de mensajes procesados y aplica el cambio de negocio en la misma transacción local:
// Ejemplo simplificado en CAP Node.js
module.exports = async function () {
const messaging = await cds.connect.to('messaging')
const { ProcessedEvents, DeliveryProjection } = cds.entities
messaging.on('sap/s4/salesorder/created/v1', async msg => {
const eventId = msg.headers?.id
if (!eventId) throw new Error('Evento sin identificador')
await cds.tx(async tx => {
const seen = await tx.run(
SELECT.one.from(ProcessedEvents).where({ ID: eventId })
)
if (seen) return
await tx.insert({ ID: eventId, processedAt: new Date() })
.into(ProcessedEvents)
await tx.upsert({
salesOrder: msg.data.SalesOrder,
status: 'PENDING'
}).into(DeliveryProjection)
})
})
}En producción faltarán detalles —retención, índices, concurrencia, multi-tenancy y tratamiento del error de clave duplicada—, pero el principio permanece: deduplicación y efecto deben compartir frontera transaccional. Si el proceso también invoca un sistema externo, se necesita una máquina de estados o una acción compensatoria; una transacción de base de datos no puede deshacer mágicamente una llamada remota.
4. El outbox evita el abismo entre commit y publicación
Un productor personalizado puede guardar correctamente un pedido y caer antes de publicar su evento. También puede publicar y después revertir la transacción. Es el fallo clásico de doble escritura. El patrón transactional outbox guarda el cambio de negocio y una fila de salida en la misma transacción; un worker publica después y marca la fila como enviada.
CAP documenta que los mensajes emitidos dentro de una transacción se envían cuando esta termina correctamente y utiliza por defecto una cola persistente. Cuando se trabaja fuera de ese mecanismo, conviene implementar el outbox de forma explícita. En SAP S/4HANA, por el contrario, debe preferirse el framework de eventos soportado por SAP frente a inventar tablas Z y jobs sin necesidad.
5. Observabilidad que sigue el negocio, no solo la tubería
Una consola verde del broker no demuestra que el pedido llegó a su destino empresarial. Cada señal debería poder rastrearse mediante event_id, correlation_id, tipo y versión. Como mínimo conviene medir profundidad y antigüedad de cola, tasa de reintentos, mensajes en dead-letter queue, latencia de extremo a extremo y porcentaje de resultados de negocio completados.
Desde el 6 de julio de 2026, SAP documenta como disponibilidad general el acceso a métricas de brokers de Advanced Event Mesh desde SAP Cloud ALM. Es una mejora útil, pero no sustituye la telemetría de la aplicación: Cloud ALM puede mostrar que el broker funciona mientras un handler genera datos incoherentes.
La regla común a las cinco capas: reconocer el mensaje solo cuando el efecto local verificable haya terminado. Los errores transitorios deben provocar reintento; los errores permanentes deben ir a cuarentena con contexto suficiente para decidir si se corrigen, se descartan o se reproducen.
El mito de “exactly once”
“Exactly once” suele describir una propiedad limitada a una tecnología o a un tramo del recorrido. En una cadena que incluye SAP S/4HANA, un broker, una aplicación CAP, una base de datos y quizá una API externa, afirmar que todo ocurrirá exactamente una vez es extraordinariamente difícil. Un timeout no permite saber si el receptor no actuó o actuó y perdió la respuesta.
La estrategia robusta combina:
- entrega at least once;
- identidad estable del evento;
- consumidores idempotentes;
- operaciones upsert o claves naturales cuando proceda;
- reintentos con espera creciente y límite;
- dead-letter queue y procedimiento de reproducción;
- orden solo por la clave de negocio que realmente lo necesita.
Exigir orden global para todos los pedidos reduce paralelismo y convierte un mensaje defectuoso en una barrera para los demás. Es preferible preservar la secuencia por pedido, entrega o cuenta cuando exista una dependencia real, y permitir que distintas entidades avancen en paralelo.
Seguridad: el evento también es un dato
Event Mesh transporta y almacena mensajes, pero SAP deja al cliente la responsabilidad sobre contenido y retención. Por eso un evento no debería convertirse en una réplica indiscriminada del objeto SAP. Minimice datos personales y financieros, limite las suscripciones a aplicaciones de confianza y defina TTL coherentes con la recuperación esperada.
Los clientes técnicos deben usar OAuth o certificados X.509 cuando el escenario lo permita, con reglas de publicación y suscripción de mínimo privilegio. Además, CAP advierte que el procesamiento de mensajes opera normalmente con un usuario técnico privilegiado: los handlers han de aplicar explícitamente las comprobaciones de autorización que exija el negocio. Esta es la traducción técnica de una idea ya abordada al hablar del gobierno de automatizaciones: poder ejecutar no significa estar autorizado para decidir.
Un experimento de resiliencia antes de producción
Antes de declarar fiable la arquitectura, ejecute una prueba pequeña pero incómoda:
- Publique cien eventos con identificadores únicos y diez duplicados deliberados.
- Detenga el consumidor durante cinco minutos y compruebe que la cola conserva los mensajes.
- Reinícielo con dos instancias concurrentes y verifique que solo existen cien efectos de negocio.
- Introduzca un evento con esquema inválido y confirme que no bloquea indefinidamente la cola.
- Fuerce un timeout después del efecto local y compruebe que la redelivery no lo duplica.
- Reproduzca un mensaje desde cuarentena y conserve la trazabilidad original.
El criterio de éxito no es “no hubo errores”. Es que los errores previstos produjeron estados previstos, observables y recuperables.
Cuándo elegir cada pieza
| Necesidad | Elección razonable | Advertencia |
|---|---|---|
| Pocos flujos, volumen bajo o medio y topología central | Event Mesh de SAP Integration Suite | Validar límites de mensaje, spool y regiones |
| Alta escala, brokers distribuidos, edge o routing avanzado | SAP Integration Suite, advanced event mesh | Mayor coste y disciplina operativa |
| Transformación, enriquecimiento o conexión con protocolos heredados | Cloud Integration como mediador | No convertir cada evento en una cadena síncrona pesada |
| Extensión de negocio en SAP BTP | Aplicación CAP con mensajería y persistencia | Revisar qué adaptadores o funciones siguen marcados como beta |
Los costes exactos dependen del plan, región, capacidad y contrato; deben comprobarse en SAP Discovery Center y en la oferta comercial vigente. La decisión no debería compararse solo por precio del broker. También cuentan el coste de las caídas, la operación multi-región, el volumen retenido y la complejidad que una plataforma sobredimensionada introduce en el equipo.
La empresa como red de señales confiables
Una arquitectura orientada a eventos puede convertirse en el sistema nervioso que conecte operaciones SAP, extensiones, analítica y agentes de IA. Para que estos últimos actúen con contexto, necesitarán datos gobernados —como explicamos al recorrer SAP Business Data Cloud—, pero también señales oportunas que indiquen qué cambió y por qué merece atención.
El telégrafo no transformó el mundo porque un pulso eléctrico fuera rápido. Lo transformó cuando estaciones, códigos, rutas, operadores y procedimientos hicieron de ese pulso una comunicación repetible. Con los eventos empresariales ocurre lo mismo. El broker es importante, pero la verdadera arquitectura vive en los contratos, la idempotencia, la seguridad y la capacidad de recuperarse.
La prueba definitiva no es contemplar cómo el mensaje cruza el océano. Es saber qué hacer cuando, en mitad de la noche, el cable deja de responder.
Fuentes oficiales
- SAP Architecture Center: Designing Event-Driven Applications
- SAP Architecture Center: Design Considerations for EDA Applications
- SAP Help Portal: Enterprise Event Enablement en SAP S/4HANA
- SAP Help Portal: alcance y límites de Event Mesh
- SAP Cloud Application Programming Model: Messaging
- SAP Help Portal: novedades de Advanced Event Mesh
- SAP Help Portal: protección de datos y privacidad en Event Mesh
