Azure Service Bus : Queues Brokered Messages – I

Últimamente vivimos unos tiempos muy agradables para todos aquellos a los que nos gusta la tecnología dado el gran volumen de novedades que tenemos a disposición de los desarrolladores cada cierto tiempo. Muchas veces, a los que nos gusta compartir cosas en nuestros blogs, sites etc.., no nos da la vida para nuestro propio trabajo, autoformación y publicación de nuestras experiencias y nos dejamos en el tintero algunas cosas sobre las que nos gustaría escribir. En mi caso, las novedades de ServiceBus introducidas con la versión 1.7 del API es un buen ejemplo de ello, más concretamente todo lo relacionado con el API .NET directo, no Windows Comunication Foundation, para el trabajo con Service Bus. Para intentar solventar este defecto intentaré escribir alguna serie de artículos sobre el tema, hablando de aquellos aspectos que a mi me parecen muy interesantes, empezando por los ‘brokered messages’ con colas.

El servicio de Relay seguro que es uno de los más conocidos de Service Bus, de hecho lo es por méritos propios, ya que desde sus comienzos a muchos nos abría puertas para poder realizar elementos que hasta entonces eran de dificil construcción como por ejemplo la posibilidad de tener un sistema duplex con dispositivos dentro de una NAT. Sin embargo, los servicios ‘brokered’ o màs llanamente el uso de servicios dónde el productor y el consumidor no necesitan/están conectados son también una pieza importante dentro del desarrollo de determinados sistemas empresariales. Quien más o quien menos nos hemos enfrentado al trabajo con colas de mensajerías en sus diferentes tecnologías ( MSMQ,Rabbit,MQSeriese etc… ) y hemos visto su amplio potencial.  Por suerte, dentro de Service Bus tenemos la posiblidad de realizar este tipo de comunicaciones con colas, topics y subscripciones, aunque en esta entrada solamente tocaremos el uso de colas, más adelante nos adentraremos en los diferentes elementos.

 

Tiempos de vida y dead letters

Aunque a priori el API parece distinto de por ejemplo el api de MSMQ en .NET, pronto nos damos cuenta de que con cuatro cosas podemos estar trabajando con colas de service bus de una forma similar a como lo hacíamos con colas de MSMQ y que ciertos conceptos apréndidos de MSMQ son también válidos aquí como por ejemplo los tiempos de vida y las colas de dead letters.

Cuando enviamos un mensaje a una cola para ser consumido, estos mensajes pueden tener un tiempo de expiración, de tal forma que nos garanticemos que el mismo solamente tenga sentido ser procesado en un tiempo dado, un ejemplo de esto podría ser los mensajes de alertar, los cuales solamente podrían tener sentido notificarlos si las alertas han ocurrido cerca en el tiempo. La configuración del tiempo de vida de una ‘brokered message’ se realiza mediante la propiedad TimeToLive tal y como podemos ver en el siguiente fragmento de código:

 

Como se puede observar en el código anterior, marcar el tiempo de vida de un mensaje es realmente sencillo. En nuestro caso, si este mensaje llegara a la cola y durante 3 segundos el mismo no fuera completado, este expiraría y desaparecería de la cola. Para explorar este comportamiento se puede utilizar la herramienta Service Bus Explorer, gracias a la cual, de una forma sencilla podremos ir haciendo peek y comprobar como solamente tenemos resultados durante el TTL marcado al mensaje anterior.

 

Otro de los elementos que también suelen ser útiles es el relativo a los poisson messages y dead letter queues, algo para lo que también teníamos soporte en la integración de WCF y MSMQ hace ya mucho tiempo. La idea, es realmente sencilla, ¿como podemos prevenir que dentro de la cola no tengamos un mensaje que pueda estar provocando errores de procesamiento y no nos bloque la salida de los siguientes en la lista? Pues bien, para resolver esto tenemos las colas de Dead Letter, dónde depositaremos nuestros mensajes envenenados para un posterior tratamiento o investigación en los mismos. Cuando creamos una conexión con una cola especificamos el modo de recepción que queremos usar  de las dos disponibles PeekLock y ReceiveAndDelete. ReceiveAndDelete como su propio nombre indica implica que cuando un mensaje es leído este se elimina del store lo que implica que ante una excepción en el procesamiento perderíamos el mensaje, por el contrario PeekLock nos permite permite poner un bloqueo al mensaje de tal forma que nadie más pueda recuperarlo pero si el mismo no es completado volverá otra vez a la cola para otro consumidor. En nuestro caso, lo que queríamos observar es la capacidad de marcar un mensaje como envenenado y llevarlo a una cola de DeadLetter, para este fin, solamente tenemos que llamar al método DeadLetter como se observa a continuación.

 

Fíjese como en caso de excepción, normalmente esto se hace con reintentos, pero por simplicidad lo dejaremos así, podemos enviar el mensaje a una cola de dead letter para su posterior procesamiento. Por supuesto, una cola de DeadLetter, al igual que en MSMQ, no es más que otra cola cualquiera con un path específico, en ServiceBus, el path es de una cola de dead letter para una cola dada es tan sencillo conseguirlo como llamar al método FormatDeadLetterPath de la clase QueueClient. Aunque es idéntico al proceso de lectura de cualquier cola a continuación está un pequeño fragmento de código para realizar la lectura de una cola de deadletter.

 

 

Esto es todo por ahora, aun nos quedan muchas cosas por ver o sea que si te interesa estate atento…

 

saludos

Unai

5 comentarios sobre “Azure Service Bus : Queues Brokered Messages – I”

  1. Si te ha servido para algo ya me ha valido la pena el post, que para eso se escriben… y anda, tu eres tan friki como yo, no necesitas excusas para estar liado el finde 🙂

    Unai

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *