Resiliencia en la integración AMI–IS-U: entrega garantizada, reintentos y replay
En utilities los componentes fallan. Cómo el advanced event mesh de SAP aborda la pérdida de eventos AMI con durable queues, dead message queue, reintentos controlados y replay —y qué garantiza cada mecanismo.
· 10 min de lectura
En una empresa de servicios públicos, los componentes fallan: los concentradores AMI pierden conectividad, la red de comunicación se congestiona, y SAP S/4HANA Utilities (IS-U) entra en ventanas de mantenimiento. La pregunta de arquitectura no es cómo evitar esas fallas —son inevitables— sino qué le ocurre a un evento de medición cuando suceden. Si la respuesta es “se pierde en silencio” o “se reprocesa sin control”, el costo aparece después, en la factura.
La resiliencia de una integración AMI–IS-U no es un atributo abstracto: se construye con mecanismos concretos que SAP documenta. Este artículo describe qué garantiza cada uno —y qué no— para que las decisiones de diseño se tomen sobre capacidades reales, no sobre promesas.
Entrega garantizada: el evento espera, no se pierde
El primer pilar es la entrega garantizada mediante colas durables. En SAP Integration Suite, advanced event mesh, un mensaje recibido se guarda en la cola y se entrega al consumidor cuando está disponible; permanece allí hasta que el consumidor confirma (acknowledge) que lo procesó. Solo entonces se elimina de la cola (SAP Community, Advanced Event Mesh — Queue).
Las colas durables (durable queues) acumulan mensajes con independencia de que los clientes estén conectados o no. Cuando un consumidor que estuvo desconectado vuelve a línea, recibe todos los mensajes que se acumularon durante su ausencia (SAP Tutorials, Queues and subscriptions in advanced event mesh). Aplicado a utilities, esto significa que una ventana de mantenimiento de IS-U no implica pérdida de lecturas: los eventos se retienen y se entregan al reanudar el servicio.
Reintentos y Dead Message Queue: el fallo se hace visible
¿Qué ocurre con un evento que el consumidor no logra procesar? Aquí entra el segundo pilar. El broker reintenta la entrega un número configurable de veces; si sigue recibiendo un rechazo (NACK), el destino del mensaje depende de la configuración: puede moverse a una Dead Message Queue (DMQ) o descartarse. Según la documentación de SAP, el broker “almacenará el mensaje en una dead message queue O descartará el mensaje” (SAP Community, Advanced Event Mesh — Queue). En versiones 10.25.9 y anteriores del broker, el mensaje solo se enruta a la DMQ si el productor lo declara explícitamente como DMQ-eligible; de lo contrario se descarta. Este comportamiento varía en versiones posteriores. Un mensaje también puede llegar a la DMQ cuando expira su Time to Live (TTL) o cuando se supera el número máximo de intentos de entrega.
La DMQ es el mecanismo que convierte un error silencioso en uno gobernable: los mensajes en cuarentena pueden inspeccionarse, corregirse en su payload y reinyectarse para reintentar la entrega al consumidor original. Su comportamiento es configurable —depende del TTL, del máximo de reintentos y de que el mensaje o la cola estén habilitados como elegibles para la DMQ—; no es un destino automático. Una contrapartida a tener presente: una vez que expira el TTL de los mensajes en la DMQ, el broker los elimina de forma irreversible —es decir, la DMQ es una red de seguridad con vencimiento, no un almacén indefinido—.
Sobre los reintentos pesa una advertencia documentada por la propia comunidad SAP: configurarlos sin criterio puede convertirse en una “trampa”, reprocesando indefinidamente mensajes que nunca tendrán éxito y amplificando la carga (SAP Community, Event Mesh + AMQP: The Retry Trap). El reintento es útil acotado por un máximo y respaldado por la DMQ, no como bucle infinito.
Replay: recuperación y auditoría sobre eventos pasados
El tercer pilar es el replay. La función de replay registra los mensajes recibidos y permite reproducir un flujo de eventos histórico hacia un consumidor —por ejemplo, para recuperar un sistema que estuvo caído más allá de la retención de su cola, o para auditar una secuencia M2C—. Su límite es explícito: cuando el log de replay alcanza su capacidad de almacenamiento, comienza a descartar mensajes siguiendo el principio FIFO (SAP Community, Advanced Event Mesh — Replay). El replay, por tanto, ofrece una ventana de reproducción acotada por almacenamiento, no memoria infinita.
Una distinción de producto que cambia el diseño
Conviene no confundir los dos productos de mensajería de SAP: SAP Event Mesh (mensajería nativa de SAP BTP) y SAP Integration Suite, advanced event mesh (la oferta basada en tecnología Solace). Ambos ofrecen colas, pero difieren de forma significativa en sus garantías y características operativas: las capacidades concretas descritas aquí —replay, colas particionadas para orden y la gestión de Dead Message Queue del broker Solace— corresponden al advanced event mesh. SAP Event Mesh clásico presenta capacidades de DMQ más limitadas y, según fuentes especializadas, no soporta replay de eventos (SAP Community, Seamlessly expand from Event Mesh to Advanced Event Mesh). La recomendación de diseño no es que un producto “tenga colas y el otro no”, sino no asumir que ambos son intercambiables: conviene verificar contra la documentación qué garantiza exactamente el producto elegido antes de apoyar una arquitectura crítica en él.
Qué garantiza la resiliencia —y qué exige
“Entrega garantizada” significa que el evento no se pierde mientras el consumidor no esté disponible; no significa “exactamente una vez”. La entrega confiable puede producir reentregas, y evitar que esas reentregas se conviertan en lecturas duplicadas exige una capa de idempotencia aguas abajo —el control determinista que descarta el procesamiento repetido de un mismo evento—. Resiliencia y unicidad son problemas complementarios: el primero asegura que el dato llegue; el segundo, que llegue una sola vez.
Igualmente, estos mecanismos son capacidades configurables, no garantías automáticas. La continuidad operativa real depende de dimensionar correctamente el TTL, el máximo de reintentos, la retención de las colas y la capacidad del log de replay según el volumen de medidores y el comportamiento de la red AMI. La arquitectura provee las herramientas; la resiliencia efectiva se decide en su configuración y se valida con pruebas de falla, no con cifras genéricas.
Fuentes
- SAP Community. Advanced Event Mesh — Queue (entrega garantizada, reintentos, Dead Message Queue, TTL). https://community.sap.com/t5/technology-blog-posts-by-sap/advanced-event-mesh-queue/ba-p/13574698
- SAP Community. Advanced Event Mesh — Replay (log de mensajes, FIFO, límite de almacenamiento). https://community.sap.com/t5/technology-blog-posts-by-sap/advanced-event-mesh-replay/ba-p/13574847
- SAP Tutorials (developers.sap.com). Queues and subscriptions in SAP Integration Suite, advanced event mesh (colas durables, acumulación offline). https://developers.sap.com/tutorials/pubsub-queues-subscriptions..html
- SAP Community. Event Mesh + AMQP: The Retry Trap Nobody Warns You About. https://community.sap.com/t5/integration-blog-posts/event-mesh-amqp-the-retry-trap-nobody-warns-you-about/ba-p/14343475
- SAP Community. Seamlessly expand from Event Mesh to Advanced Event Mesh. https://community.sap.com/t5/technology-blog-posts-by-sap/seamlessly-expand-from-event-mesh-to-advanced-event-mesh-with-our-new/ba-p/14252359
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
