Microservicio receptor con worker en .NET

Conectar dos microservicios mediante un queue de Azure Service Bus requiere configurar un servicio receptor que escuche mensajes en segundo plano sin exponer endpoints HTTP. Aquí verás cómo construir ese servicio receptor en .NET usando un worker, paso a paso, partiendo del transcript de la clase.

¿Qué necesitas para configurar el servicio receptor PeakAge?

Antes de escribir código, prepara las dependencias y la configuración base que la documentación te indica.

El primer paso es agregar los paquetes de NuGet desde la terminal. Copias cada paquete, lo pegas en la terminal y presionas enter. Si trabajas con .NET, el flujo es idéntico. Una vez instalados, el siguiente paso es replicar el archivo appsettings.json que ya usaste en el servicio emisor.

En lugar de reescribirlo, hay un truco práctico: copia todo el contenido del appsettings de AddMember, muévete al proyecto PeakAge y reemplaza el contenido completo con Control A, Control C y pegar. Así heredas el ConnectionString y el QueueName sin errores de tipeo [03:12].

¿Qué es un worker en .NET? Es un servicio que corre en segundo plano, esperando ser despertado cuando llega un evento, como un mensaje nuevo en una cola de Service Bus. No expone endpoints HTTP.

¿Cómo modificar Program.cs para que no exponga una API?

Aquí ocurre el cambio más interesante: el receptor deja de ser una API tradicional.

Al abrir Program.cs verás el código que normalmente expone los métodos de tu API mediante endpoints. Ese código desaparece por completo. La nueva configuración se encarga solo de dos cosas:

• Leer la información desde appsettings.json.
• Registrar y configurar el servicio como un worker en segundo plano.

Esto significa que el proyecto ya no escuchará en un puerto HTTP. Su único trabajo será mantenerse activo esperando mensajes desde Azure Service Bus.

¿Cómo se construye el archivo Worker.cs?

El archivo Worker.cs es el corazón del servicio receptor. Lo creas dentro del proyecto PeakAge y pegas el contenido que la documentación indica [05:48].

¿Qué contiene la clase Worker?

Este archivo está pensado para mantenerse "durmiendo" y despertar solo cuando hay actividad en la cola. Su estructura incluye:

• La configuración con ConnectionString y QueueName, que deben coincidir exactamente con lo declarado en appsettings.json.
• Un cliente y un procesador encargados de manejar la comunicación con Service Bus.
• Un constructor que recibe los servicios inyectados y los asigna a las variables internas.
• El método ExecuteAsync, que mantiene al worker activo de forma indefinida y registra los manejadores de eventos.
• Métodos obligatorios como ErrorHandler y StopAsync, que el worker exige implementar para gestionar errores y apagados controlados.

Dentro del manejador del mensaje recibido, el body contiene la información que llegó desde el servicio emisor. Una buena práctica de naming es nombrar la variable como mensaje recibido en español si el resto del código está en ese idioma, para mantener consistencia [07:30].

¿Para qué sirve ExecuteAsync en un worker? Es el método que mantiene vivo al servicio en segundo plano y conecta los manejadores de eventos que reaccionan cuando llega un nuevo mensaje a la cola.

¿Cómo verificar que el receptor procesa los mensajes de la cola?

La prueba final demuestra que la comunicación entre microservicios funciona sin HTTP.

Abre dos terminales. En una, ubícate en la carpeta del servicio AddMember. En la otra, en PeakAge. Ejecuta dotnet run en PeakAge y notarás algo distinto: no aparece un puerto expuesto como localhost:5242, porque este servicio no se comunica por HTTP, sino por mensajería.

La aplicación se inicia y, como spoiler, procesa de inmediato los mensajes que estaban en fila esperando. En el ejemplo del transcript aparece el nombre Miranda y dos intentos previos. Al regresar al portal de Azure y actualizar la información, el conteo de mensajes pendientes se resetea a cero [09:15].

Para probar el flujo completo en vivo:

1. Mantén corriendo el servicio PeakAge en una terminal.
2. Desde el archivo HTTP de AddMember, modifica un valor del cuerpo, por ejemplo cambia el año a 2019.
3. Envía la solicitud al servicio emisor.
4. Observa la terminal de PeakAge: aparecerá Mensaje recibido 2019, enviado del otro servicio.

¿Por qué un microservicio receptor no expone un puerto? Porque su comunicación ocurre a través de un queue de Azure Service Bus, no de HTTP. Solo necesita conectarse al broker de mensajería y escuchar.

Con esto, dos microservicios ya conversan entre sí mediante una cola, lo que abre la puerta al siguiente reto: hacer que el segundo servicio publique mensajes a un topic. ¿Qué diferencias crees que tendrá un topic frente a un queue? Déjalo en los comentarios.