Conectar BizTalk Server a una cola en el Azure Service Bus – Parte 1

En una arquitectura Hibrida siempre vamos a tener componentes “on premises” y componentes en la nube. En este post vamos a conectar el bus de integración BizTalk Server con el Azure service bus.

Escenario

Normalmente en una arquitectura hibrida, los componentes que se dejan “on premises” son los que están relacionados con datos sensibles o los sistemas legacy que no se pueden correr o integrar directamente con los servicios o endpoints en la nube. Estos sistemas por lo general no tiene todas las características para integrarse a la nube o es muy complicado integrarlos de manera integrar (con transaccionabilidad, tolerancia, seguridad, etc.) a las buses que exponen los endpoints en la nube. En estos casos debemos usar un bus de integración para poder conectar estas aplicaciones con los endpoints a través de la nube. Cuando hablamos de endpoints hablamos de puntos de acceso para consumir servicios SOAP y REST ya sea directamente o través de aplicaciones utilizando servicios en la nube tales como los “mobile services” de azure.

Para este post vamos a imaginar una aplicación que la única interface al mundo exterior ( dentro de un mismo datacenter) que tiene disponible son archivos de texto. Esta aplicación graba un archivo de texto en un folder y espera la respuesta en otro archivo de texto en otro folder. Este archivo será tomado por BizTalk Server y enviado al bus de azure apenas la aplicaciones lo escriba. Seguidamente otro adaptador de BizTalk lo traerá de vuelta de la nube lo pondrá en el folder definido para la respuesta.

Demo

No vamos a hacer una aplicación que grabe un archivo en un folder, pero si vamos a definir un folder y vamos a poner un archivo en este folder para que BizTalk server lo consuma. Como se ve en la siguiente imagen, el adaptador define un uri de donde recoger los archivos para que BizTalk los procese.

Luego procedemos a configurar el puerto de envío. Lo primero que tenemos que hacer es crear el filtro para que el mensaje se pueda rutear desde el puerto de recibo al puerto de envío.

El siguiente paso es seleccionar el adaptador para el bus de servicios como se muestra en la siguiente figura.

Ahora procedemos a configurar el adaptador para que se pueda conectar al bus. El primero paso es establecer el uri de la cola que vamos a utilizar.

Luego procedemos a configurar la autenticación de la conexión a la cola del bus de servicios de azure. En primera instancia el uri del ACS lo tomamos del portal de de seguridad de Azure. Este portal lo podemos acceder del dialogo que nos presenta la clave y el usuario para conectarnos al namespace donde reside la cola. El detalle desde donde se toma la dirección de la autenticación se ve en la siguiente figura.

Ahora procedemos a configurar el adaptador en su parte de autenticación. El owner y el issuer key son los mismos que usamos para consumir la cola desde las aplicaciones que normalmente desarrollamos y que se comunican con el el Azure Service Bus.

Listo!!! si ponemos un archivo en el folder especificado, veremos que el mensaje llega a la cola en el bus de servicios de Azure – en este caso podemos ver que hay un mensaje en la cola llamada queuereportes.

En el siguiente post vamos a configurar el adaptador de recibo de mensajes de BizTalk Server para el Azure Service Bus para ir a obtener el mensaje enviado anteriormente.

Etiquetas de Technorati: BizTalk Server,Azure Service Bus,Azure,ACS

Windows Azure Mobile Services – Aplicaciones Móviles de Valor 2

En este post procedemos a crear nuestro servicio móvil desde el portal de Windows Azure. Para esto, vamos a la opción de Mobile Services y en la esquina inferior izquierda seleccionamos crear, lo que nos lleva a ver la cejilla básica donde seleccionamos la opción de crear un nuevo servicio móvil.

Seguidamente procedemos a completar el “wizard” que se nos va a presentar con la opción de crear, la cual nos permite definir un nombre para el servicio móvil (que debe de ser único) y luego a seleccionar la base de datos en la nube con la cual vamos a trabajar y la subscripción de Azure que vamos a utilizar.

El siguiente paso es configurar la base de datos y el servidor de base de datos contra el cual va a interactuar el servicio móvil. Es importante destacar que el servicio requiere una base de datos, pero no es necesario utilizarla, podríamos usar el service bus – como lo haremos mas adelante – para conectarnos a servicios ”on premises” utilizando “relay services”.

Cuando se finaliza la creación del servicio móvil nos aparece este mensaje.

Con esto ya tenemos creado nuestro servicio móvil. Si examinamos el servicio y vamos a la opción de configuración, podemos ver el servidor y la base de datos contra la cual estamos interactuando.

 

Etiquetas de Technorati: Mobile Service,Azure

Windows Azure Mobile Services – Aplicaciones Móviles de Valor 1

Definitivamente las aplicaciones móviles tienen toda la atención de las empresas  ya que el no tener presencia móvil en estos tiempos es como no tener sitio web hace 10 años. Este disrruptor tecnológico ha hecho que los departamentos de TI de las empresas se enfrenten a escenarios a los cuales no están acostumbrados y por lo tanto quedan expuestos a el “conocimiento” de terceros que se presentan como conocedores del mundo móvil y muchas veces no es así.

En este nuevo mundo móvil y por la ya mencionada falta de experiencia de las empresas se cometen muchos errores que pasan desapercibidos por muchos y por mucho tiempo; entre estos errores podemos mencionar los siguientes:

• Diseñamos las aplicaciones móviles como si fueran aplicaciones Web: como estamos tan acostumbrados al mundo web, llevamos los mismos conceptos a los dispositivos móviles, lo cual en la mayoría de los casos es un groso error porque a nivel móvil no se tiene el mismo poder computacional, la misma energía disponible e incluso la misma cantidad de ancho de banda. Igualmente los usuarios no se comportan de la misma manera cuando utiliza un aplicativo móvil y un aplicativo web.
• Creamos las aplicaciones sin pensar en el impacto que tendrán en el dispositivo donde van a correr: Esto es provocado porque seguimos usando las tecnologías que hemos usado siempre para hacer cosas diferentes. Un ejemplo típico de esta situación es el uso de servicios web SOAP para su consumo desde los aplicativos móviles; esto porque el servicio SOAP utiliza XML para representar todo el mensaje que se envía de ida y vuelta y como ya lo hemos mencionado en este blog, el procesamiento del XML requiere mucho poder computación, por lo tanto mucha energía lo que conlleva a que la batería de los celulares se drene rápidamente lo que conlleva a que el usuario final no use mas la aplicación.
• Tiempos de espera elevado entre transacciones: Como normalmente hacemos transacciones para aplicaciones web, en donde un usuario puede esperar hasta un minuto en frente de la computadora para que su transacción se lleve a cabo, procedemos a crear la transaccionabilidad de la misma forma en las aplicaciones móviles. Sin embargo a nivel móvil las transacciones deben de ser mas rápidas y con información mas condensada – cada bit que se transporta importa.
• Agregamos la misma funcionalidad del sitio web a la aplicación móvil: Este es otro error grave, ya que las aplicaciones móviles no deben tener funcionalidades que no aplican bien o que no se resuelven bien en la plataforma, – ejemplo los filtros de lista en línea – ya que en una pantalla tan pequeña normalmente no se logra comprender fácilmente la funcionalidad y los usuarios terminan descartándola. Además, el consumo de recursos intensos – consultas vía web por letra digitada por ejemplo –, terminan dando la impresión de que la aplicación no es de calidad, cuando en realidad son aspectos externos los que terminan dando esa idea.
• Aplicaciones transaccionales móviles web: Este quizás sea uno de los temas más complicados de tratar en lo que se refiere al desarrollo móvil. Las empresas con tal de tener presencia móvil, terminan haciendo sitios web que permitan hacer transacciones vía el dispositivo móvil. Aunque desde un punto de vista informativo las aplicaciones web móviles funcionan de maravilla, desde un punto de vista transaccional pueden ser muy problemáticas. Esto porque las aplicaciones móviles pueden salirse de una transacción por razones mínimas ( entrada de un msm, una llamada, un mensaje de facebook, etc ) y con eso el manejo de la cancelación de la transacción se vuelve muy truculenta. Igualmente la confianza del usuario no es la misma si usa una aplicación nativa a una aplicación web porque básicamente trae miedos (muchas veces con toda razón) de los peligros de las transacciones vía web.
• Uso de bases de datos en los dispositivos: Por increíble que parezca esta idea (ahora solo falta alguien pidiendo un servidor web en el móvil) hay aplicaciones que para funcionar necesitan una base de datos local. Las bases de datos no son para usarse en dispositivos móviles ya que consumen recursos necesarios para el dispositivo, agrega necesidad de trabajo en “background” por lo que el consumo de batería es constante, además la seguridad de los datos pasa a otro nivel porque un usuario podría perder su dispositivo y por lo tanto sus datos en donde podrían existir transacciones importantes como movimientos financieros que están en cola esperando por una conexión para llevarse a cabo.
• Funcionalidad de la aplicación móvil – agregar valor al usuario de la aplicación: Definitivamente el objetivo de tener una aplicación móvil no es solo presencia en alguna plataforma, si no también dar valor agregado al usuario de la misma. Nadie va a consultar las noticias de una empresa mas de una vez y en la empresa seguramente tampoco las van a actualizar de forma seguida. Es importante que el usuario encuentre de valor la aplicación y le permita llevar a cabo acciones que le mejoran la percepción hacia la empresa. Tener una aplicación por tenerla, no tiene sentido ya que requiere tiempo y dinero para desarrollarla y al final en lugar de dar una buena imagen, haremos que nuestros clientes piensen que todos los servicios que oferta la empresa son de esa calidad.

Dado este escenario tan apocalíptico, cual es la perspectiva mas adecuada para desarrollar las aplicaciones móviles? En realidad existen muchas formas de desarrollar aplicaciones móviles útiles para el usuario final. Entre las cosas que podemos mencionar que hay que tener en cuenta a la hora de hacer estos desarrollos podemos enumerar algunas importantes:

• La aplicación tiene que ser diseñada con la funcionalidad móvil necesaria para que el cliente aprecie el valor de la misma. Debe de ser fácil de administrar y actualizar por parte de la empresa desarrolladora y debe de causar un impacto positivo en el cliente. Por ejemplo, si la aplicación es para teléfonos, NO DEBEMOS usar GRIDS.
• Utilizar JSON como esquema para serializar datos que viajan a través de servicios: JSON es mas simple de parsear y requiere menos poder computacional que XML, si utilizamos JSON para representar nuestros datos vamos a tener mejor desempeño a la hora de consumir servicios desde un dispositivo móvil.
• Las transacciones deben de ser expeditas; es decir los servicios que se consumen deben de llevar a cabo solo una tarea y retornar la información solicitada, con esto nos garantizamos que el tiempo de respuesta sea el optimo. Además la cantidad de datos a retornar debe de estar pre filtrada, por ejemplo nunca deberíamos presentar en un dispositivo móvil todas las transacciones del cliente en la pantalla principal de la aplicación.
• La aplicación debe de integrarse con el middleware de la empresa para que su funcionalidad aporte valor al usuario. Por ejemplo, en una aplicación móvil podría ver mis transacciones bancarias del ultimo mes, y ver por solicitud los meses anteriores; o también podría ver todas las solicitudes de servicio al cliente que tiene y el estado de cada una – de nuevo en cantidades manejables.
• Los servicios que consume la aplicación móvil son los mismos servicios que consumen otras aplicaciones tales como el sitio web, lo que garantiza uniformidad en los procesos que se mandan a ejecutar. Esto quiere decir que seguramente vamos a tener que agregar endpoints REST para soportar JSON en el servicio.
• Minimizar el uso de base de datos: No es que no necesitemos en alguna momento una base de datos en nuestra aplicación móvil, pero sin duda el aplicativo debe de estar en línea siempre que sea posible; sin embargo, cuando se requiere que pueda llevar ciertas tareas estando offline, debemos buscar métodos alternativos para guardar estas transacciones que se deberán sincronizar luego con el repositorio central. Además, no toda la funcionalidad debería estar disponible online solo la realmente es necesaria; por ejemplo, las consultas no deberían estar disponibles offline, pero transacciones que se pueden ejecutar después contra el repositorio centralizado si podrían guardarse en el dispositivo para ejecutarlas cuando haya conexión.
• Preferiblemente codificar la aplicación en la plataforma de desarrollo nativa, esto principalmente porque las aplicaciones nativas tienen mejor desempeño que las aplicaciones web o las aplicaciones que se convierten en nativas a partir de algún framework de desarrollo móvil como phonegap o Sencha Touch; esto principalmente porque aunque estos frameworks generan código nativo, las instrucciones generadas no siempre son las optimas.

Azure Mobile Services

Entre las opciones existentes quizás la mas simple para iniciar con el desarrollo móvil conectado a la capa media de la empresa esta la de Azure Mobile Services. Esta plataforma nos permite enfocarnos en el trabajo de la aplicación en si, y nos permite olvidarnos de todo lo requerido para manejar la conectividad de la aplicación con nuestros centros de datos o procesos de negocio ya existentes. Lo que hace el Azure Mobile service es generar un proxy en la nube que recibe solicitudes de la aplicación móvil y las redirecciona a donde nosotros le indiquemos, en primera instancia a una base de datos en Azure pero lo ideal para integrarlo con nuestro data center es direccionar al Azure Service Bus el cual a través de sus diferentes mecanismos interconecta la aplicación móvil con nuestros procesos de negocio que residen “on premises”.

Plataformas soportadas

Azure mobile services nos permite generar proyectos en las plataformas móviles mas populares, las cuales son al día de hoy Android, iOS, Windows Phone, Xamarin, Windows Store y HTML 5 + js para abarcar las demás opciones existentes. en realidad el proxy se genera para todas las plataformas y los desarrolladores eligen sobre cual quieren trabajar.

En nuestro próximo post veremos como iniciar el desarrollo móvil utilizando Azure Mobile Services.

Etiquetas de Technorati: Azure Mobile Services,Azure Service Bus,Integration

Extracción de mensajes de las colas del Azure Service Bus

En post anteriores hemos mostrado como sacar mensajes de un “queue” tanto desde Java como desde .NET. Sin embargo, el proceso de extracción de estos mensajes ha sido mediante un ciclo que constantemente trata de obtener los nuevos mensajes que residen en la cola seleccionada. Esto podría no ser ideal en ciertos escenarios en donde el flujo de mensajes no es constante o por ejemplo donde tenemos muchos mensajes pero queremos tener paralelismo a la hora de consumir los mensajes entrantes. Con el SDK 2.0 y superior Windows de Azure ahora tenemos la posibilidad de tener una forma alterna de consumir estos mensajes mediante notificación del evento de recibo por parte del Bus de Azure ( o Windows Service Bus ).

Extracción de mensajes con el método OnMessage

Este método nos permite asociar un método “callback” a la instancia de la cola creada el cual se va a ejecutar cada vez que un mensaje llega a la cola del bus.

Ejemplo

Para ilustrar el modelo de extracción de mensajes, vamos a trabajar en un ejemplo de envío y recibo de mensajes a través de una cola de mensajes en el bus. Como se puede ver en la siguiente figura, tenemos 6783 mensajes en el bus esperando a ser procesados. Para extraerlos no vamos a usar un ciclo de extracción, sino mas bien el método OnMessage.

Como se ilustra en el siguiente código, primero vamos a crear un método para configurar el callback al evento OnMessage. Primero creamos una instancia de la clase MessageOptions donde establecemos si queremos que el mensaje se marque como completo cuando se procesa y cuantas llamadas a la cola concurrentes pueden ser creadas. Luego establecemos el mecanismo para manejar las excepciones y por ultimo configuramos el método onMessage con el callback que viene de parámetro – que va a procesar cada mensaje que llega – y las opciones de recibo.

  public void GetMessagePump(Action<BrokeredMessage> pCallback)
        {
            var _messageOptions = new OnMessageOptions {AutoComplete = true, MaxConcurrentCalls = 5};
            _messageOptions.ExceptionReceived += _messageOptions_ExceptionReceived;
            GetQueueClient().OnMessage( pCallback, _messageOptions);
        }
        void _messageOptions_ExceptionReceived(object sender, ExceptionReceivedEventArgs e)
        {
            if (e != null && e.Exception != null)
            {
                Trace.WriteLine(">> Se presento la siguiente excepcion: {0}",
                    e.Exception.ToString());
            }
        }

Seguidamente procedemos a crear el método que va a manejar el mensaje y que viene de parámetro en el Callback del metodo GetMessagePump. Como se e ve en el código, el método recibe un mensaje del bus como parámetro y luego lo procesa. En este caso hacemos lo que necesitamos hacer con el mensaje, pero específicamente para este ejemplo vamos a loguear el recibo del mensaje en un TextBox de una aplicación Windows Forms – simplemente logueamos una propiedad de la clase BaseRecord la cual es un Guid.

 private void OnMessageArrived(BrokeredMessage pMessage)
        {
            if (pMessage != null)
            {
                txtEstadoProceso.Invoke((MethodInvoker) delegate
                {
                    BaseRecord _baseRecord = pMessage.GetBody<BaseRecord>();
                    txtEstadoProceso.Text +=
                        string.Format(
                            "Procesando registro {0} a las {1} \n" + Environment.NewLine,
                            _baseRecord.TransactionId.ToString(),
                            DateTime.Now.ToString());
                });
          pMessage.Complete();
            }
        }

Por ultimo en el evento del botón obtener mensajes agregamos el siguiente código que activa la recepción de mensajes. En este caso en particular, los métodos anteriores – excepto el de OnMessageArrived – fueron escritos en una clase que encapsula la interacción con el bus de Azure llamada ServiceBusManager.

        private void btnRecibirPorNotificacion_Click(object sender, EventArgs e)
        {
            var _serviceBus = new ServiceBusManager();
            _serviceBus.GetMessagePump(OnMessageArrived);
        }

Si ejecutamos el código anterior podemos ver como se van extrayendo los mensajes vía el método OnMessage a través del Callback OnMessageArrived.

Como podemos en la imagen anterior, los registros se procesan de 5 en 5 ( así se configuro en el MessageOptions ) y todos tienen el Id de la transacción igual porque son mensajes correlacionados. Esta misma operación puede ser llevada a cabo en el Windows Service Bus.

Etiquetas de Technorati: Azure Service Bus

Evento CloudDay Guayaquil

En este post quiero aprovechar para invitarlos a participar el próximo martes 10 de diciembre en el evento CloudDay Guayaquil en el cual estaré brindando 4 charlas. El evento esta orientado a la computación en la nube utilizando las plataformas Microsoft. Nuestra empresa – Arc3Labs – será patrocinador del mismo y yo estaré de expositor en el mismo con 4 charlas. Mis charlas serán orientadas al tema del middleware en la nube y dispositivos móviles

Las charlas que voy a dar son las siguientes:

1. BizTalk Services: En esta charla les estaré presentando de que se trata BizTalk Services y como utilizar el Servidor BizTalk desde la nube.
2. Incorporando dispositivos móviles al middleware de la empresa: En esta charla vamos a hablar de como crear aplicaciones que le aporten valor a la empresa, conectando a través del bus de Azure un dispositivo móvil a un sistema legacy. Para la demo utilizaremos MacOs, iOS, y Java.
3. Middleware Híbridos: En esta demo vamos a ver como crear middleware híbridos utilizando Azure Service Bus y BizTalk Server. Esta combinación resulta sumamente interesante porque con poca inversión permite a las empresas tener una capa media con una capacidad transaccional altísimo y una escalabilidad casi indefinida.
4. Gobernabilidad: Administración y monitoreo de aplicaciones de Windows Azure con System Center: En esta charla vamos a hablar del potencial de una herramienta como System Center, con la cual podemos monitorear no solo herramientas “on premises” si no también nuestro middleware en la nube ( con lo que los middleware híbridos pueden ser monitoreados de forma completa

Para los que estén por Guayaquil ese día, aquí les dejo el registro: http://www.thecloudday.com/Charlas.aspx#

Para los que no puedan llegar luego del evento voy a subir las presentaciones.

Etiquetas de Technorati: BizTalk,Azure,Azure Service Bus,System Center

Utilizando el Azure Service Bus con Java - Queues

Una de las ventajas del Azure Service Bus, es que nos permite utilizarlo no solo con código .NET si no también con código Java, python, javascript, etc. En este post vamos a acceder queues en el Azure Service Bus desde una aplicación java hecha en netbeans y corriendo en Mac OS.

En primera instancia vamos a asumir que el namespace y el queue a utilizar ya están configurados, si no lo están pueden visitar los post anteriores al respecto.

Configurar la conexion

Lo primero que debemos hacer es configurar en el código la información necesaria para poder conectarnos al bus. Para esto procedemos a descargar las librerías java para tal propósito (jars) las cuales podemos  obtener desde este link.

Seguidamente procedemos a agregar dichos jars como una librería a nuestra solución - en este caso una aplicación de consola.

 

Luego procedemos importando las librerías que necesitamos para que el código compile y funcione:

 

 

El siguiente paso es configurar la conexión vía código; esto es, crear el objeto con la configuración de la conexión al bus y crear la clase que mantendrá esta comunicación. Como podemos ver en el siguiente código, esto lo logramos utilizando la clase Configuración en donde pasamos como parámetro el namespace, el usuario, la llave, el url del bus y el tipo de control de acceso. Seguidamente procedemos a crear la clase para conectarnos al service bus a partir de esta configuración.

Enviando un mensaje

Una vez configurada la conexión al bus, procedemos a enviar el mensaje. Para esto, vamos a proceder creando el mensaje - Brokered message como en los post anteriores de .NET. Seguidamente agregamos una propiedad al mensaje ( llamada Propiedad) y por ultimo procedemos a enviar el mensaje. El código lo podemos ver en el siguiente listado.

Si enviamos el mensaje desde la aplicación de consola, podremos ver que el mensaje se envía correctamente.

Si vamos a la consola de Windows Azure, podremos ver que el mensaje esta en la cola esperando a ser consumido por algún cliente.

Recibir un mensaje

Para recibir un mensaje vamos a reutilizar el código para la configuración de la conexión utilizado anteriormente y vamos a proceder creando las opciones para recibir el mensaje, que para este caso será recibir el mensaje y borrarlo de la cola, esto lo vamos a lograr con la clase ReceiveMessageOptions. Luego procedemos a recibir el mensaje utilizando el método receiveQueueMessage desde la instancia de la clase ServiceBusContract y procedemos a manipular el mensaje recibido.  Para este ejemplo, simplemente vamos a imprimir el id del mensaje, el cuerpo del mensaje, y la propiedad personalizada llamada Propiedad que agregamos en el envío del mensaje. El código de este método se puede ver en el siguiente listado.

El resultado a la hora de ejecutar la aplicación se ve en la siguiente figura:

Si vamos de nuevo al portal de Azure, veremos que el largo del queue ya no es 1, si no 0 ya que procedimos con la extracción del mensaje.

Windows Azure Service Bus - Queues

Como vimos en posts anteriores el Azure Service Bus ( y su homologo en Windows Server ) manejan dos esquemas de comunicacion: Queues  y Topics. En este post vamos a ver un ejemplo para hacer funcionar los Queues en el Azure Service Bus.

Las colas tienen muchas ventajas a la hora de implementar sistemas y arquitecturas distribuidas, principalmente porque soportan un flujo muy alto de transacciones y porque son muy tolerante a los fallos, ya que si el consumidor del mensaje no esta disponible, el mensaje se persiste en la cola hasta que el consumidor este de vuelta de nuevo, o hasta que dicho mensaje expire.

Conectarse al Service Bus

Inicialmente, necesitamos conectarnos al bus de Azure en el namespace que hemos creado con anticipación en el post anterior. Para esto, necesitamos instalar en nuestra maquina de desarrollo el SDK para desarrollo de Windows Azure. Para esto, vamos a Visual Studio en donde seleccionamos “Manage NuGet Packages” y en la ventana de búsqueda digitamos Service Bus.

Una vez instalado, procedemos a conectarnos al namespace del bus de Azure utilizando nuestro perfil de conexión – ya visto en post anteriores.

Desarrollar el Demo

Ahora procedemos a crear un ejemplo, en donde vamos a tener una rutina que envía un mensaje a la cola llamada “testqueue1” – que fue creada en nuestro post anterior – y luego otra rutina que recibe ese mensaje desde la cola de Windows Azure. Para esto procedemos a crear un proyecto del tipo Windows Forms y dibujamos la pantalla de la siguiente forma:

En el primer cuadro, vamos a poder escribir un mensaje y enviarlo al bus. Este mensaje se va a quedar en la cola hasta que lo retiremos de la misma. Para esto, vamos a tener otro cuadro con un botón que va a ir sacar el mensaje de la cola del bus, y lo va a presentar en el TextBox de Mensaje Respuesta.

Poniendo el Mensaje en la Cola en el bus de servicios

Para poner el mensaje en la cola en el service bus en Windows Azure vamos a utilizar el siguiente código:

   1:          private void btnEnviar_Click(object pSender, EventArgs pE)

   2:          {

   3:              Cursor = Cursors.WaitCursor;

   4:              var _queueClient = QueueClient.Create("testqueue1", ReceiveMode.PeekLock);

   5:              _queueClient.Send(new BrokeredMessage

   6:                  {

   7:                      Properties = {{"Mensaje", txtMensaje.Text}}

   8:                  });

   9:              Cursor = Cursors.Default;

  10:          }

En este código creamos una instancia de un cliente para acceder a la cola y apuntamos a la cola deseada a través del nombre en el factory de queues – QueueClient.Create. Seguidamente enviamos un mensaje ( muy simple por cierto ) y procedemos a olvidarnos del mismo.

Recibiendo el mensaje desde la cola del bus de servicios

Una vez puesto el mensaje en la cola, procedemos a obtener el mensaje directamente desde el bus de Windows Azure. Para esto, vamos a utilizar el siguiente código:

   1:          private void btnRecibir_Click(object pSender, EventArgs pE)

   2:          {

   3:              Cursor = Cursors.WaitCursor;

   4:              var _queueClient = QueueClient.Create("testqueue1", ReceiveMode.PeekLock);

   5:              var _mensaje = _queueClient.Receive();

   6:              txtRecibir.Text = (string) _mensaje.Properties["Mensaje"];

   7:              _mensaje.Complete();

   8:              Cursor = Cursors.Default;

   9:          }

En este caso, vamos a crear de nuevo un cliente para acceder la cola, luego recibimos el mensaje y obtenemos la propiedad “Mensaje” de la colección de propiedades del mismo. Por ultimo, marcamos el mensaje como completo para que sea removido de la cola.

Ejecutar el programa

Primero procedemos a ejecutar la aplicación y de inmediato enviamos un mensaje:

Para estar seguros de que el mensaje llego al bus, procedemos a detener la aplicación, y buscamos en el namespace la cola con la que estamos interactuando; si vemos sus propiedades, podemos ver que tiene un mensaje activo.

Para recibir el mensaje, procedemos a ejecutar el programa de nuevo y ejecutamos el botón recibir. El mensaje que estaba en la cola ahora se presenta en el text box destinado para la respuesta.

Si revisamos de nuevo las propiedades de la cola, podemos ver que en la propiedad ActiveMessageCount ahora el valor es 0, esto porque la obtención del mensaje, produce su eliminación de la cola del bus de servicios.

Technorati Tags: Azure Service Bus,Queues