Configuración de Worker Service para Topics de Azure Service Bus

La implementación de colas y tópicos (queues y topics) en entornos .NET mediante Azure Service Bus implica ajustar aspectos claves en la configuración y lógica del proyecto. A continuación, se aborda claramente cómo configurar una aplicación para recibir mensajes de tipo topic y guardar estos mensajes en una base de datos SQL.

¿Cómo configurar correctamente app settings en tu proyecto .NET?

Configurar adecuadamente el archivo appsettings.json resulta crítico para la integración entre Azure Service Bus y la base de datos SQL.

Se requieren dos configuraciones principales:

• La cadena de conexión a Service Bus identificando claramente el nombre del topic.
• Cadena de conexión a una base de datos SQL (indiferentemente puede ser local o remota).

Un ejemplo básico debería incluir lo siguiente:

"ConnectionStrings": {
    "ServiceBusConnection": "[TuCadenaDeServiceBus]",
    "DefaultConnection": "[TuCadenaSQL]"
},
"TopicName": "adultsTopic"

¿Qué pasos seguir para convertir Program.cs en una aplicación Worker?

Al adoptar una aplicación tipo Worker, es esencial realizar modificaciones claras y concisas en el archivo Program.cs. Este cambio transforma el enfoque desde endpoints tradicionales hacia un servicio que se ejecuta continuamente en segundo plano. Las acciones son las siguientes:

• Modificar Program.cs para que no sea un endpoint común, sino que instale y gestione un servicio tipo Worker.
• Crear un nuevo archivo llamado Worker.cs siguiendo la estructura prescrita en la documentación.

En Worker.cs, además se incluirá lógica específica para consumir mensajes provenientes del topic y posteriormente confirmar la persistencia de los datos hacia SQL.

¿Cómo manejar correctamente mensajes recibidos desde un Topic para guardarlos en SQL?

La clave para gestionar mensajes provenientes de un topic reside en un método especializado. Este método captura, procesa y guarda la información en la base de datos.

El proceso esencial incluye:

1. Recepción del mensaje desde Azure Service Bus (desde el topic).
2. Fragmentación y conversión de ese mensaje a un formato que pueda almacenarse como entidad en SQL.

Un ejemplo de fragmentación sencilla del mensaje:

var mensajeFragmentado = mensaje.Split(new[] { "\",\"" }, StringSplitOptions.None);
var adulto = new Adult {
    Nombre = mensajeFragmentado[0],
    Apellido = mensajeFragmentado[1],
    AnioNacimiento = int.Parse(mensajeFragmentado[2]),
    UrlImagen = mensajeFragmentado[3]
};

3. Uso del método SaveChanges de Entity Framework Core para almacenar en base de datos.

_context.Adultos.Add(adulto);
_context.SaveChanges();

¿Qué componentes adicionales requiere el nuevo Worker Service?

El proyecto debe incluir elementos organizacionales esenciales para que el Worker Service sea funcional:

• Crear un directorio Data o data para manejar acceso y configuración a la base de datos.
• Crear dentro de esta carpeta un archivo DataContext.cs que proporciona contexto de base de datos.

Ejemplo del archivo:

public class DataContext: DbContext {
    public DbSet<Adult> Adultos { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) =>
        optionsBuilder.UseSqlServer("[CadenaConexionSQL]");
}

• Crear un directorio Models para definir el modelo de datos.
• Crear archivo Adult.cs, clave para mapear los datos recibidos con SQL y Entity Framework.

public class Adult {
    public int Id { get; set; }
    public string Nombre { get; set; }
    public string Apellido { get; set; }
    public int AnioNacimiento { get; set; }
    public string UrlImagen { get; set; }
}

Ahora, con la estructura lista y conectada, el siguiente paso será probar toda la integración enviando mensajes a través de otros microservicios.

Si tienes dudas o deseas compartir experiencias similares, comenta y participa activamente en nuestra comunidad.