Contenido del curso
Arquitectura Basada en Microservicios
Automatización y Preparación del Entorno
Comunicación Asíncrona entre Servicios
Despliegue
Observabilidad
Envía mensajes a Azure Service Bus desde .NET
Resumen
Conectar un microservicio a Azure Service Bus desde .NET te permite desacoplar procesos y enviar datos a la nube mediante colas. Aprenderás a configurar el emisor de mensajes en el microservicio AddMember usando la extensión Rest Client en VS Code, y dejarás listo el flujo para que un receptor procese esos mensajes después.
¿Cómo configurar la conexión a Service Bus en el microservicio?
El primer paso es crear la estructura que permita al microservicio comunicarse con la cola en la nube. Dentro del proyecto AddMember creas una carpeta llamada data y, dentro, un archivo ServiceBus.
Ese archivo cumple dos funciones puntuales:
- Importa el paquete NuGet previamente instalado para Service Bus.
- Define dos variables: la connection string y el nombre de la cola.
- Recibe estos valores mediante un constructor que los inyecta al cliente.
El método principal envía mensajes de forma asíncrona. Construye el cuerpo del mensaje con tres campos del transcript: nombre, apellido y año de nacimiento. Esa información se serializa y viaja hacia la nube a través de un objeto ServiceBusMessage, despachado por el sender del cliente con SendMessage.
¿Qué es una connection string en Azure Service Bus? Es la cadena que autentica tu aplicación contra el namespace. Siempre inicia con la palabra
Endpoint, y sin ella el cliente no puede enviar ni recibir mensajes.
¿Dónde se guarda la cadena de conexión y el nombre de la cola?
La configuración sensible vive en el archivo appsettings.json, no dentro del código. Desde la documentación copias únicamente el bloque de Service Bus y lo pegas en el appsettings del proyecto AddMember.
Ahí defines dos valores:
- La connection string real obtenida desde Azure.
- El nombre de la cola, en este caso
PeakAge.
Para obtener la cadena auténtica vas al portal de Azure, entras al namespace de tus servicios y, en Settings, abres las políticas de acceso compartido (Shared access policies). Siempre existe una creada por defecto al generar el namespace. Seleccionas la política y copias el valor de Primary Connection String.
Un detalle de validación: si la cadena empieza con Endpoint=, es la correcta. Cualquier otro prefijo indica que copiaste un dato equivocado.
¿Cómo se reemplaza el program.cs para exponer el endpoint?
El program.cs por defecto trae el ejemplo del clima en .NET. Lo eliminas completo y pegas el contenido que indica la documentación.
El nuevo program.cs hace tres cosas:
- Importa el namespace
datadonde vive la clase Service Bus. - Crea una aplicación tipo API.
- Define un método POST llamado
AddMemberque recibe tres parámetros: nombre, apellido y año de nacimiento.
Esos tres parámetros son exactamente los que el método SendMessageAsync necesita para construir el cuerpo del mensaje. La configuración lee la connection string y el nombre de la cola desde appsettings, y con eso instancia el cliente que envía el mensaje a la cola correspondiente.
¿Por qué se usa POST y no GET para AddMember? Porque estás creando un recurso nuevo y enviando datos al servidor. POST es el verbo HTTP correcto cuando el cliente envía información que provoca un cambio o registra algo nuevo.
¿Cómo probar el envío de mensajes con Rest Client?
Para ejecutar la prueba abres la terminal y corres dotnet run. La consola muestra el puerto donde quedó expuesto el microservicio. En la grabación apareció primero el puerto 5226 y al reiniciar cambió a 5242, así que actualizas el archivo .http con ese puerto.
El flujo completo de prueba queda así:
- Ejecutar
dotnet runen la terminal. - Confirmar el puerto que asigna .NET y reflejarlo en el archivo HTTP.
- Lanzar la petición POST con los tres parámetros desde Rest Client.
- Validar la respuesta
Miembro Miranda agregado con éxito.
Cuando la respuesta llega correcta, vuelves al portal de Azure. En la sección Queues del namespace verás el contador de mensajes enviados aumentar. En la demo aparecen dos mensajes: uno de prueba previo y el recién enviado desde el microservicio.
Con el emisor funcionando, queda pendiente lo más interesante: construir el receptor que escuche la cola y procese cada mensaje conforme llega. ¿Has probado ya enviar tu primer mensaje a una cola de Service Bus? Cuéntame en los comentarios cómo te fue con la connection string.