Integración de Azure Service Bus con Azure Event Grid: fundamentos y ejemplos prácticos

Introducción

Azure Service Bus y Azure Event Grid resuelven problemas distintos dentro de una arquitectura distribuida:

Azure Service Bus se utiliza para mensajería empresarial, desacoplamiento entre productores y consumidores, colas, temas, suscripciones y patrones de procesamiento asíncrono.
Azure Event Grid se utiliza para distribuir eventos de forma reactiva hacia destinos como Azure Functions, Logic Apps, webhooks u otros servicios compatibles.

La integración entre ambos permite que Service Bus publique eventos en Event Grid cuando detecta mensajes disponibles y no hay receptores activos. Esto no sustituye al consumo de mensajes desde Service Bus, pero sí permite activar automatizaciones cuando una cola o una suscripción necesita atención.

Un caso típico es despertar una función, lanzar una alerta o iniciar un flujo de trabajo cuando existen mensajes pendientes y ningún consumidor los está procesando.

Qué problema resuelve esta integración

En arquitecturas basadas en colas, es habitual que los productores sigan enviando mensajes aunque los consumidores estén detenidos, escalados a cero o temporalmente no disponibles.

Sin esta integración, para detectar esa situación se suele recurrir a estrategias como:

sondeos periódicos sobre la cola;
métricas y alertas en Azure Monitor;
procesos auxiliares que revisan el estado de las colas;
consumidores siempre activos, incluso cuando no hay carga.

Con Event Grid, Service Bus puede emitir una notificación cuando hay mensajes disponibles y no existen receptores activos. Esto facilita modelos más reactivos y puede reducir la necesidad de sondeo constante.

La idea importante es esta:

Event Grid notifica que hay mensajes disponibles; no transporta el contenido de los mensajes de Service Bus.

El consumidor final debe seguir leyendo los mensajes desde Service Bus mediante el SDK, un trigger de Azure Functions, un worker, una Logic App u otro mecanismo compatible.

¿Qué es Azure Service Bus?

Azure Service Bus es un servicio de mensajería administrado para integrar aplicaciones y servicios desacoplados. Está diseñado para escenarios donde se necesita comunicación asíncrona, control de entrega y patrones de mensajería empresarial.

Entre sus capacidades principales se incluyen:

Colas: permiten enviar mensajes a un único consumidor lógico.
Temas y suscripciones: permiten patrones de publicación/suscripción, donde varios consumidores pueden recibir copias filtradas de los mensajes.
Dead-letter queues: almacenan mensajes que no han podido procesarse correctamente o que han expirado según la configuración.
Sesiones: permiten agrupar mensajes relacionados y mantener orden dentro de una misma sesión.
Bloqueo de mensajes y finalización explícita: los consumidores pueden completar, abandonar, diferir o enviar mensajes a la cola de mensajes muertos.

Conviene matizar que Service Bus no garantiza FIFO global en todos los escenarios. Si necesitas orden estricto, normalmente debes diseñar el procesamiento usando sesiones y tener en cuenta la concurrencia del consumidor.

¿Qué es Azure Event Grid?

Azure Event Grid es un servicio de distribución de eventos basado en publicación/suscripción. Permite reaccionar ante cambios o señales emitidas por distintos orígenes, tanto de Azure como personalizados.

Sus características más relevantes son:

Entrega de eventos a múltiples destinos.
Integración con servicios de Azure, como Azure Functions, Logic Apps y Webhooks, entre otros.
Filtrado de eventos, por tipo de evento o por asunto.
Entrega al menos una vez, por lo que los consumidores deben ser idempotentes y tolerar posibles duplicados.
Modelo reactivo, útil para automatizaciones y flujos orientados a eventos.

Event Grid no debe confundirse con un broker de mensajería empresarial como Service Bus. Event Grid distribuye eventos; Service Bus almacena y entrega mensajes.

Cómo funciona la integración entre Service Bus y Event Grid

La integración permite que un namespace de Service Bus actúe como origen de eventos para Event Grid. Cuando se cumplen determinadas condiciones, Service Bus emite eventos que pueden ser consumidos por un manejador externo.

Los eventos más relevantes para este escenario son:

Microsoft.ServiceBus.ActiveMessagesAvailableWithNoListeners
Microsoft.ServiceBus.DeadletterMessagesAvailableWithNoListeners

Estos eventos indican, respectivamente, que existen mensajes activos o mensajes en la cola de mensajes muertos sin receptores activos escuchando en ese momento.

Es importante tener en cuenta varias limitaciones conceptuales:

No se emite un evento por cada mensaje individual.
El evento representa una condición del recurso: hay mensajes disponibles sin consumidores activos.
El evento no contiene el cuerpo del mensaje.
Para procesar los mensajes, el manejador debe conectarse posteriormente a Service Bus.
La entrega de eventos puede producir duplicados.
Como en cualquier diseño con Event Grid, el consumidor debe ser idempotente.
El evento puede llegar antes de que el consumidor final procese la cola.
Event Grid activa la reacción, pero el procesamiento real depende de la lógica posterior.
No sustituye a las métricas ni a la observabilidad.
Para operación en producción, conviene complementarlo con Azure Monitor, alertas y trazabilidad de los consumidores.

Arquitectura típica

Una arquitectura habitual sería la siguiente:

Una aplicación publica mensajes en una cola de Azure Service Bus.
No hay consumidores activos escuchando esa cola.
Service Bus emite un evento hacia Event Grid.
Event Grid entrega el evento a un destino, por ejemplo una Azure Function.
La función valida el evento y decide qué hacer:
- iniciar un proceso de consumo;
- escalar un componente;
- enviar una alerta;
- registrar la incidencia;
- llamar a una API interna;
- revisar la dead-letter queue.

La clave es separar dos responsabilidades:

Event Grid despierta o notifica.
Service Bus sigue siendo el origen desde el que se leen los mensajes.

Configuración básica

A continuación se muestra un ejemplo orientativo usando Azure CLI. Los nombres de recursos deben adaptarse a tu entorno y debes validar que la característica está disponible para el SKU, región y configuración que utilices.

Paso 1: Crear un namespace de Service Bus y una cola

Primero necesitas un grupo de recursos existente o crear uno previamente. Después puedes crear el namespace y la cola:

az servicebus namespace create \
  --name MiNamespaceSB \
  --resource-group MiResourceGroup \
  --location eastus \
  --sku Standard

az servicebus queue create \
  --name MiColaSB \
  --namespace-name MiNamespaceSB \
  --resource-group MiResourceGroup

En entornos reales conviene revisar también parámetros como:

tamaño máximo de la cola;
duración del bloqueo de mensajes;
tiempo de vida de los mensajes;
configuración de dead-letter;
sesiones, si necesitas orden por grupo de mensajes;
autorización mediante identidades administradas o políticas de acceso.

Paso 2: Crear una suscripción de Event Grid

La suscripción de Event Grid se crea sobre el recurso de Service Bus que actúa como origen. En este caso, el origen habitual es el namespace de Service Bus.

Ejemplo con una Azure Function como destino:

az eventgrid event-subscription create \
  --name MiSuscripcionEventGrid \
  --source-resource-id /subscriptions/{subscription-id}/resourceGroups/MiResourceGroup/providers/Microsoft.ServiceBus/namespaces/MiNamespaceSB \
  --endpoint-type azurefunction \
  --endpoint /subscriptions/{subscription-id}/resourceGroups/MiResourceGroup/providers/Microsoft.Web/sites/MiFunctionApp/functions/MiFunction

Sustituye los siguientes valores:

{subscription-id} por el identificador real de la suscripción de Azure.
MiResourceGroup por el grupo de recursos.
MiNamespaceSB por el namespace de Service Bus.
MiFunctionApp por el nombre de la Function App.
MiFunction por el nombre de la función que recibirá el evento.

Si el namespace contiene varias colas, temas o suscripciones, es recomendable aplicar filtros para procesar únicamente los eventos que correspondan al recurso deseado.

Paso 3: Filtrar los tipos de evento

Puedes limitar la suscripción a los tipos de evento que te interesan. Por ejemplo:

az eventgrid event-subscription create \
  --name MiSuscripcionServiceBus \
  --source-resource-id /subscriptions/{subscription-id}/resourceGroups/MiResourceGroup/providers/Microsoft.ServiceBus/namespaces/MiNamespaceSB \
  --included-event-types Microsoft.ServiceBus.ActiveMessagesAvailableWithNoListeners Microsoft.ServiceBus.DeadletterMessagesAvailableWithNoListeners \
  --endpoint-type azurefunction \
  --endpoint /subscriptions/{subscription-id}/resourceGroups/MiResourceGroup/providers/Microsoft.Web/sites/MiFunctionApp/functions/MiFunction

Además de filtrar por tipo de evento, en escenarios con muchos recursos puede interesarte filtrar por el asunto del evento. Antes de fijar filtros estrictos, revisa el subject real recibido en tu entorno para evitar descartar eventos válidos por un patrón incorrecto.

Ejemplo de Azure Function para recibir eventos

Una Azure Function con trigger de Event Grid puede recibir la notificación y decidir qué acción ejecutar.

Ejemplo simplificado en Python:

import logging
import azure.functions as func

def main(event: func.EventGridEvent):
    logging.info("Evento de Event Grid recibido")
    logging.info("Tipo de evento: %s", event.event_type)
    logging.info("Asunto: %s", event.subject)
    logging.info("Datos: %s", event.get_json())

    if event.event_type == "Microsoft.ServiceBus.ActiveMessagesAvailableWithNoListeners":
        logging.info("Hay mensajes activos disponibles sin receptores.")
        # Aquí podrías iniciar el procesamiento de la cola,
        # llamar a un servicio interno o generar una alerta.

    elif event.event_type == "Microsoft.ServiceBus.DeadletterMessagesAvailableWithNoListeners":
        logging.warning("Hay mensajes en dead-letter sin receptores.")
        # Aquí podrías avisar al equipo de operación
        # o lanzar un proceso de inspección de la DLQ.

Este ejemplo no procesa directamente los mensajes de Service Bus. Para hacerlo, la función tendría que conectarse posteriormente a la cola o suscripción usando el mecanismo adecuado, como el SDK de Azure Service Bus o un trigger específico de Service Bus.

Ejemplo práctico: alerta por mensajes sin consumidores

Imagina una aplicación de pedidos en la que los mensajes entran en una cola llamada orders. Los consumidores se ejecutan en segundo plano, pero por un problema de despliegue dejan de estar activos.

Sin una reacción automática, los mensajes podrían acumularse hasta que una alerta de métricas detecte el crecimiento de la cola. Con la integración de Event Grid, puedes reaccionar cuando Service Bus notifique que hay mensajes disponibles sin listeners.

Flujo propuesto

La aplicación publica mensajes en la cola orders.
No hay consumidores activos.
Service Bus emite Microsoft.ServiceBus.ActiveMessagesAvailableWithNoListeners.
Event Grid entrega el evento a una Azure Function.
La función:
- registra el evento;
- envía una alerta al equipo de operación;
- opcionalmente llama a un endpoint para reactivar consumidores;
- o desencadena un flujo de remediación.

Este patrón es útil cuando quieres evitar consumidores siempre encendidos o cuando necesitas detectar rápidamente la ausencia de listeners.

Ejemplo práctico: revisión de la dead-letter queue

Otro escenario frecuente es la gestión de mensajes en dead-letter. Estos mensajes suelen indicar problemas como:

errores repetidos de procesamiento;
mensajes con formato inesperado;
expiración del tiempo de vida;
reglas de negocio incumplidas;
abandono excesivo de mensajes.

Con el evento Microsoft.ServiceBus.DeadletterMessagesAvailableWithNoListeners, puedes activar una función o flujo de trabajo cuando haya mensajes en dead-letter y no exista un receptor activo para revisarlos.

Flujo propuesto

Un mensaje no puede procesarse y termina en la dead-letter queue.
No hay un proceso activo leyendo esa cola de mensajes muertos.
Service Bus publica el evento correspondiente en Event Grid.
Event Grid invoca una Azure Function.
La función notifica al equipo responsable o inicia un proceso de análisis.

De nuevo, el evento no contiene el mensaje original. El proceso de inspección debe leer la dead-letter queue desde Service Bus.

Buenas prácticas

Diseña consumidores idempotentes

Event Grid utiliza entrega al menos una vez. Esto significa que un mismo evento puede llegar más de una vez.

Tu lógica debe tolerar duplicados. Por ejemplo:

evitando crear alertas repetidas sin control;
deduplicando por identificador de evento cuando sea necesario;
comprobando el estado actual de la cola antes de actuar;
haciendo que las operaciones sean seguras ante reintentos.

No dependas solo del evento

El evento indica que se ha detectado una condición, pero no debe ser tu única señal operacional.

Combínalo con:

métricas de Service Bus;
alertas de Azure Monitor;
logs estructurados;
trazas de los consumidores;
paneles de operación;
revisión periódica de dead-letter queues.

Para sistemas críticos, es preferible tener varias capas de observabilidad.

Valida el estado antes de actuar

Cuando recibas el evento, el estado de la cola puede haber cambiado. Por ejemplo, otro consumidor podría haberse iniciado y empezar a procesar mensajes.

Antes de escalar, alertar o iniciar una remediación costosa, la función puede consultar métricas o comprobar si aún hay mensajes pendientes.

Usa filtros de Event Grid

Si el namespace de Service Bus contiene muchos recursos, evita que todos los eventos lleguen al mismo manejador sin necesidad.

Puedes filtrar por:

tipo de evento;
asunto;
destino;
lógica de enrutamiento posterior.

Esto ayuda a reducir ruido y simplifica el mantenimiento.

Protege los destinos

Si usas webhooks, APIs o funciones HTTP como destino, asegúrate de revisar:

autenticación y autorización;
validación del origen;
control de reintentos;
límites de concurrencia;
protección frente a ejecuciones duplicadas;
registro de errores.

En integraciones productivas, una mala gestión del destino puede convertir una señal útil en una fuente de ruido o coste innecesario.

Separa señal de procesamiento

Una práctica recomendable es no hacer demasiado trabajo dentro del manejador de Event Grid.

El evento puede servir para:

despertar un proceso;
publicar una señal interna;
iniciar una orquestación;
enviar una alerta;
activar un consumidor.

El procesamiento intensivo de los mensajes debería seguir ocurriendo mediante los mecanismos normales de Service Bus, con control de concurrencia, reintentos y manejo de errores.

Cuándo usar esta integración

Esta integración encaja bien cuando necesitas:

detectar colas con mensajes y sin consumidores activos;
activar procesamiento bajo demanda;
reducir sondeo periódico;
generar alertas tempranas;
reaccionar ante mensajes en dead-letter;
conectar Service Bus con flujos event-driven.

También puede ser útil en arquitecturas serverless, donde algunos componentes no están permanentemente activos y conviene activarlos solo cuando hay trabajo real.

Cuándo no es la mejor opción

No deberías usar esta integración como sustituto directo de:

un consumidor normal de Service Bus;
un trigger de Service Bus en Azure Functions;
una solución de monitorización completa;
una estrategia de escalado bien definida;
un mecanismo de auditoría de mensajes.

Si lo que necesitas es procesar cada mensaje individual, lo adecuado es consumir directamente desde Service Bus. Event Grid solo te avisa de una condición relevante.

Conclusión

La integración entre Azure Service Bus y Azure Event Grid permite crear arquitecturas más reactivas alrededor de colas y suscripciones. Su principal valor está en detectar situaciones como mensajes disponibles sin receptores activos o mensajes en dead-letter sin consumidores.

Usada correctamente, puede ayudarte a:

activar procesos bajo demanda;
reducir sondeos innecesarios;
mejorar la respuesta operativa;
conectar mensajería empresarial con flujos event-driven.

La clave es no confundir evento con mensaje: Event Grid notifica, pero Service Bus sigue siendo el sistema desde el que se leen y procesan los mensajes.

Fuente

Microsoft Azure Blog: Azure Service Bus now integrates with Azure Event Grid