Kabel sensoriza el riego por capilaridad en sus oficinas. IoT verde para gestión de edificios inteligentes (BIM)
21 noviembre, 2016
Specification-pattern
25 noviembre, 2016

Una de las características más importantes de cualquier sistema de integración es la posibilidad de procesar varias tareas de forma simultánea.

Habitualmente, un proceso de negocio está formado por varias operaciones sencillas que se deben completar para cubrir toda la lógica funcional requerida.

En la mayor parte de los casos, los requisitos funcionales no se limitan a la construcción de dichos procesos, sino que definen también SLAs que se deben cumplir para que dichos procesos sean viables desde la perspectiva de negocio (por ejemplo, definiendo límites de tiempo en la ejecución de los mismos).

En esta situación, con mucha frecuencia es preciso paralelizar la ejecución de las operaciones simples que componen un proceso de negocio para poder cumplir con los SLAs establecidos.

Debido a sus capacidades de proceso en múltiples hilos de ejecución, BizTalk es una herramienta perfecta para implementar este tipo de aplicaciones. Veremos las ventajas e inconvenientes de cada una de ellas y cómo se lleva a cabo la implementación de las mismas.

 

El componente Parallel Actions

BizTalk incluye un componente que se puede utilizar en los orquestadores y que permite representar acciones que se ejecutan en paralelo. Este componente se denomina Parallel Actions, y su objetivo es indicar que se deben completar todas las ramas de ejecución de dicho componente antes de continuar con el proceso de negocio.

Aunque este componente representa gráficamente varias ramas de ejecución, en realidad NO realiza dicha ejecución en paralelo. Esto es así debido a que una instancia de una orquestación se ejecuta en un único hilo de proceso y esto hace inviable cualquier tipo de ejecución asíncrona.

En realidad, cada una de las ramas se ejecuta de forma secuencial y el componente finaliza cuando se han completado todas ellas.

Un ejemplo de un componente Parallel Actions sería el siguiente:

1

 

El patrón de diseño Scatter-Gather

Este patrón de diseño permite definir un mecanismo de envío de varios mensajes a varios destinatarios, los cuales tratarán dicha información. Una vez finalizado el proceso en cada destino, el patrón permitirá recoger cada una de las respuestas generadas como resultado de cada sistema destino. Se trata de un patrón estándar, es decir, no está vinculado con ninguna tecnología y en BizTalk la implementación se basa en el mecanismo de publicación-suscripción de la base de datos de mensajería.

Adicionalmente, facilita la aplicación de patrones de diseño adicionales, como el patrón de agregación, que define cómo se debe implementar la solución para recuperar todas las respuestas recibidas y agregarlas para componer una respuesta única.

 

En este artículo voy a describir dos formas distintas de implementar este último patrón con BizTalk Server.

La primera se basa en intercambio de mensajería entre los destinatarios basando la solución principalmente en el mecanismo de publicación-suscripción de BizTalk, aplicando filtros mediante el uso de propiedades de contexto.

El segundo modo de implementación se basa en la ejecución asíncrona de orquestadores y la recepción de las respuestas de los mismos mediante el uso de puertos auto-correlacionados.

En ambos casos, el beneficio de implementar este patrón radica en que el envío de los mensajes a cada destinatario se realiza en un nuevo hilo de proceso debido a las capacidades de publicación-suscripción y routing que proporciona BizTalk, con lo que realmente conseguimos que el proceso de negocio se ejecute paralelizando tareas.

Un ejemplo gráfico de implementación de este patrón sería el siguiente:

2

Se recibe un mensaje y se envía una solicitud de forma paralela a cada uno de los destinatarios. Acto seguido, se recogen las distintas respuestas y se agregan las mismas para componer una respuesta como resultado del proceso.

Dado que ambas aproximaciones difieren bastante en su implementación técnica, indicaremos qué proceso se debe seguir para cada uno de ellos.

 

Implementación mediante intercambio de mensajería

Esta implementación se basa en el intercambio de mensajería a través de la Message Box de BizTalk. Es una solución muy desacoplada, ya que, al intercambiar únicamente mensajes, no existe ninguna dependencia con respecto a los sistemas destinos que los consumen.

Debido a este escaso acoplamiento, es recomendable utilizar algún patrón de mensajería canónica para implementar los mensajes intercambiados. Hay que tener en cuenta que los mensajes que se deben transmitir deben tener una estructura homogénea, con lo que es muy recomendable que sea lo más flexible y extensible posible.

Para mayor referencia sobre la implementación de este patrón: https://osmanhbiztalkblog.wordpress.com/tag/mensajeria-canonica-en-biztalk/

Los pasos generales que se deben seguir para llevar a cabo esta implementación suelen estar predefinidos, dado que se trata de un patrón de diseño bastante común.

En primer lugar, debemos definir los esquemas de mensajería que serán objeto de intercambio a través de la Message Box. Estos esquemas deben proporcionar alguna propiedad que nos sirva para identificar de forma unívoca los mensajes.

Para poder implementar esta solución, debemos poder asociar un mensaje enviado a un destino con la respuesta recuperada como resultado de dicha ejecución. Esto es imprescindible, dado que es posible que podamos tener en ejecución varias instancias de un proceso de negocio de forma simultánea y cada una debe procesar únicamente sus mensajes.

Para ello, debemos poder identificar todos los mensajes intercambiados en una determinada instancia mediante un identificador único. Esto lo podemos lograr mediante el uso de una propiedad de contexto donde almacenaremos dicho identificador.

En la siguiente imagen se muestra un ejemplo de definición de una propiedad de contexto que usaremos para una correlación:

3

En este caso definimos la propiedad de contexto MessageIdentifier de tipo string que se usará para identificar los mensajes intercambiados.

Para una mejor comprensión, lo intentaré representar gráficamente. Supongamos que tenemos un proceso principal del que se inician dos instancias de forma simultánea:

4

Cuando esto sucede, nos encontramos con que ambos procesos enviarán mensajes de solicitud a través de la Message Box con el objetivo de que se ejecuten de forma asíncrona instancias del proceso secundario. Para hacerlo más legible, he identificado los mensajes que se intercambian con un identificador.

Una vez completados los procesos secundarios, éstos devolverán un mensaje de respuesta tal y como se indica en el esquema siguiente. Hay que tener en cuenta que las respuestas se recuperarán en el orden en que sean recibidas de los destinatarios, no en función del orden de envío de las solicitudes.

5

Debemos asegurarnos de que el mismo valor de la propiedad de contexto esté informado en el mensaje enviado y en el que se recibe, y que dicho valor sea suficientemente concreto para que cada proceso de negocio recoja únicamente las respuestas que debe obtener de la Message Box. Habitualmente se usa el mismo identificador para todos los mensajes enviados dentro de un mismo proceso de negocio.

Por otro lado, tenemos que implementar un mecanismo para indicarle al motor de mensajería de BizTalk que queremos asociar los mensajes enviados y recibidos a través de una propiedad de contexto específica. Pues bien, esto se consigue mediante la definición de correlaciones de mensajería sobre las propiedades de contexto que definimos.

En la siguiente imagen, muestro un ejemplo de definición de correlación sobre la propiedad de contexto definida anteriormente como MessageIdentifier:

6

La correlación nos sirve para indicar que una o varias propiedades de contexto se van a informar en un mensaje enviado y que se usarán para asociar dicho mensaje con una respuesta recibida. Al enviar el mensaje inicializamos la correlación. Al recibir la respuesta, lo que hacemos es continuar la correlación.

En la imagen mostramos cómo iniciar una correlación en el envío:

7

En la siguiente imagen mostramos como continuar la correlación en la recepción:

8

Para más información sobre implementación de correlaciones, os dejo los siguientes enlaces:

Una vez definidas las propiedades de contexto y creados los tipos de correlación sobre dichas propiedades, debemos adaptar los orquestadores para que hagan uso de dichos artefactos.

El objetivo final es que el funcionamiento sea similar al que mostramos en el esquema:

9

Esta solución, pese a ser la más flexible, tiene algunas desventajas. La más importante es que a través de la Message Box únicamente es posible intercambiar mensajes.

En caso de que precisemos enviar más información necesaria para cubrir la lógica de negocio, tendremos que añadirla de alguna forma al mensaje, con lo que esta solución ya no sería la idónea.

 

Implementación mediante puertos auto-correlacionados

Este modo de implementación se basa en la invocación asíncrona de orquestadores que se encargan de realizar la comunicación con los sistemas destino, pasándoles como parámetro el puerto donde deben enviar las respuestas generadas en cada caso.

Estos puertos que se pasan como parámetro son de tipo auto-correlacionado, que son puertos lógicos enlazados con la Message Box y que están asociados con la orquestación en la que se definen.

Básicamente, la orquestación principal invoca de forma asíncrona a una secundaria y le indica que la respuesta que genere la envíe a través del puerto que le pasa como parámetro. Cuando la orquestación secundaria genera la respuesta, ésta es recibida en el puerto definido en la orquestación principal.

Esta solución tiene tanto ventajas como inconvenientes comparándola con la basada en intercambio de mensajes.

Como inconveniente podemos destacar que es una solución mucho más acoplada, dado que se basa en el uso de unos orquestadores definidos, lo que limita su extensibilidad y reutilización. Sin embargo, tiene bastantes ventajas. La primera es que es mucho más sencilla de implementar, dado que no requiere la definición de propiedades de contexto ni correlaciones. Adicionalmente, nos permite intercambiar cualquier tipo de información entre los orquestadores, desapareciendo la limitación del intercambio de mensajes.

Al igual que con la solución basada en intercambio de mensajería, es conveniente la utilización de un patrón de mensajería canónica, aunque en este caso no es imprescindible, dado que el envío de información es totalmente heterogéneo y dependerá de los parámetros que reciba la orquestación invocada.

La única restricción es el que los mensajes de respuesta enviados a través del puerto auto-correlacionado deben ser de un tipo específico.

Un esquema del funcionamiento sería el siguiente:

10

Para más información sobre puertos auto-correlacionados y su uso práctico, podéis consultar el siguiente enlace: https://msdn.microsoft.com/en-us/library/aa954477.aspx.

 

Si tenéis interés en consultar un caso práctico sencillo de uso de estas dos implementaciones, he dejado un código subido en el siguiente enlace: https://1drv.ms/u/s!AnLgNtlaqXZBllK94AvyQhJIMHo9.

 

Podéis remitirnos las dudas o comentarios que tengáis a info@kabel.es.

También podéis seguirnos en Twitter y LinkedIn.

 

Kabel Geek


 

Compártelo: Share on FacebookTweet about this on TwitterShare on LinkedInPin on Pinterest

Deja un comentario

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

NEWSLETTER