Acerca del ejemplo de Correlación de mensajes

Las correlaciones de ejemplo muestran patrones de diseño que implementan diversos escenarios de intermediación. El diseño de las herramientas de correlación de mensajes permite que estos patrones de diseño puedan combinarse juntos formando patrones compuestos. De esta manera se pueden crear correlaciones de mensajes para escenarios complejos juntando patrones de diseño para escenarios más sencillos. Los archivos de ejemplo no están pensados para ser desplegados.

Manejar mensajes ensamblados completos

Los archivos de ejemplo para procesar mensajes ensamblados completos se encuentran en la carpeta message_assembly en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

Un mensaje ensamblado es la combinación de todas las cabeceras y el cuerpo o carga útil del mensaje. Los nodos Mapping, DataInsert, DataUpdate, DataDelete y Extract de un flujo de mensajes manejan siempre un mensaje ensamblado completo. Esto significa que la correlación de esos nodos muestra siempre un modelo de mensaje ensamblado como orígenes y destinos de una correlación.

En WebSphere Message Broker hay dos modelos de mensaje ensamblado: el modelo simplificado de Propiedades y el modelo completo de Cabeceras. Elija el modelo que se ajuste a las necesidades de su caso. La imagen de la izquierda muestra el modelo Propiedades de un mensaje ensamblado; la de la derecha muestra el modelo Cabeceras de un mensaje ensamblado.

Propiedades ensambladas

Propiedades ensambladas

Un mensaje ensamblado de WebSphere Message Broker incluye cuatro elementos enumerados en la imagen:

  1. la carpeta Entorno local;
  2. la carpeta Propiedades;
  3. el grupo Cabeceras de mensajes de la capa de transporte;
  4. el cuerpo o carga útil del mensaje.

Puede configurar un flujo de mensajes para que realice un salto a Route To Label después de uno de los nodos de correlación; esto resulta útil en casos de direccionamiento entre flujos basados en el contenido.

Este ejemplo contiene tres casos comunes:

En todos los casos, el cuerpo o carga útil del mensaje es el último elemento del mensaje ensamblado.

Volver al principio

Controlar el proceso de flujos de mensajes con una correlación

Use el elemento de mensaje ensamblado labelName para controlar el direccionamiento de un mensaje después de un nodo de correlación. Esto resulta útil en caso en los que se desea seleccionar los siguientes nodos de flujos de mensajes para continuar el proceso desde una correlación.

La siguiente figura muestra el archivo de flujo de mensajes de ejemplo RouteToLabelUsingMap.msgflow configurado con un nodo Mapping, un nodo Route To Label y varios nodos Label de destino. Las etiquetas de destino de los nodos Label se han configurado para que sean las que indican sus nombres.

Flujo de mensajes Route To Label

Para poder seleccionar el nodo Label que procesa el mensaje de entrada, la correlación ha de especificar la propiedad de Nombre de etiqueta del nodo Label. El archivo de correlación de ejemplo SetLabelNodeLabelName.msgmap maneja este proceso utilizando una fila if con 2 condiciones y un else:

Correlación de mensajes Route To Label

En este ejemplo:

Volver al principio

Copiar todas las cabeceras

A menudo, una correlación se centra automáticamente el cuerpo de un mensaje. En ese caso, la correlación ha de copiar todas las cabeceras sin cambios.

Utilice el modelo Propiedades para copiar todas las cabeceras sin cambios. Cuando se selecciona el mensaje ensamblado simplificado Propiedades, todas las cabeceras del mensaje excepto la carpeta Propiedades se copian en orden y sin cambios.

Cuando haya creado una correlación de mensaje de Propiedades, correlacione el elemento complejo $origen/Propiedades con el elemento complejo $destino/Propiedades. Esto hará que la carpeta Propiedades se copie sin cambios desde el origen al destino, junto con las demás cabeceras sin cambios.

La imagen que sigue muestra el archivo de ejemplo CopyAllHeaders.msgmap configurado para copiar todas las cabeceras (Propiedades incluida) sin cambios.

Copiar todas las cabeceras

Volver al principio

Correlacionar Propiedades

El modelo Propiedades habilita muchos casos de intermediarios sin tener que ocuparse de la complejidad de correlacionar varias cabeceras. Propiedades proporciona la mayoría de los atributos importantes de cabecera para MQ Series y el analizador de MRM y los presenta en un solo paquete. Además de en el caso Copiar todas las cabeceras, utilice el modelo Propiedades en situaciones en las que WebSphere MQ sea la capa de transporte y MRM el analizador del cuerpo del mensaje. Esos atributos pueden categorizarse como se indica a continuación:

Modelo Propiedades

  1. Formato físico del mensaje
  2. "Calidad de servicio" de la capa de transporte
  3. Información de vía de acceso de respuesta
  4. Tema de publicación/suscripción

Es necesario tener en cuenta que se han de establecer todos los campos de un modelo Propiedades. Si, necesita establecer un solo campo, por ejemplo, MessageFormat para seleccionar el formato físico del mensaje de salida, establezca también, o copie, el resto de valores de la carpeta Propiedades. Los campos que no se hayan establecido explícitamente no se copiarán en el mensaje de salida.

Volver al principio

Correlación de cabeceras

El modelo Cabeceras permite correlacionar cabeceras seleccionadas además de las propiedades. Recuerde que el modelo Cabeceras no tiene soporte para la opción "copiar todas las cabeceras": las cabeceras que no se hayan correlacionado explícitamente no se crearán como parte del destino.

Las Cabeceras tienen las siguientes categorías MQMD, MQ, HTTP y JMS. Utilice el modelo Cabeceras para casos de JMS, SOAP sobre JMS, y HTTP. Utilice el modelo Cabeceras para casos de MQ en los que el modelo Propiedades no proporcione el control necesario.

  1. El grupo MQ incluye las cabeceras MQMD y MQRFH2. Tenga en cuenta que se trata de la definición de la estructura de la cabecera; durante la ejecución una correlación maneja los analizadores de origen automáticamente. Para un destino MQRFH2 la correlación selecciona dinámicamente el analizador MQRFH2 en intermediarios de la versión 5 y el analizador de alto rendimiento de MQRFH2C en intermediarios de la versión 6.
    Todo el ESQL descendente de una correlación de mensajes que correlacione la cabecera MQRFH2 (lo que es distinto de copiarla utilizando la función para copiar todas las cabeceras) necesita configurarse con el nombre de analizador correcto para esa cabecera.
  2. El grupo HTTP incluye todas las cabeceras estándar; las otras cabeceras HTTP se ignoran, Si necesita procesar cabeceras HTTP personalizadas deberá configurar un nodo Compute de ESQL para llamar a la correlación, como se explica más abajo.
  3. El grupo JMS incluye las cabeceras JMS estándar. Para procesar versiones personalizadas necesitará definir la cabecera JMS personalizada en un conjunto de mensajes y configurar un nodo Compute de ESQL para llamar a la correlación, como se explica más abajo.
Modelo de cabeceras

Volver al principio

Crear varios mensajes de salida

Los archivos de ejemplo para varios casos de mensajes de salida se encuentran en la carpeta multiple_output del proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

La norma básica para crear varios mensajes de salida es declarar, implícita o explícitamente, múltiples filas $de destino. Se pueden declarar múltiples filas implícitamente utilizando una fila for . Utilizando una fila for se crearán cero o mas mensajes de salida, uno por elemento de origen proporcionado como origen de la fila for. También se pueden crear varios mensajes de salida añadiendo explícitamente más de un destino en el menú Añadir orígenes y destinos. Cada destino creará un mensaje de salida. Incluso se pueden combinar filas for con múltiples destinos si cada elemento de un origen crea varios mensajes de salida por su cuenta.

En varios casos resulta útil configurar una correlación de mensajes para efectuar la salida de varios mensajes. Estos son algunos de los casos:

Las herramientas de correlación de mensajes facilitan la generación de varios mensajes de salida: todo lo que hay que hacer es especificar varios mensajes ensamblados o incluir un mensaje ensamblado de destino en una fila for.

Volver al principio

Crear varios mensajes de salida para un campo de repetición

Los archivos de ejemplo para este caso se encuentran en la carpeta multiple_output en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

Lo único que se necesita para crear varios mensajes de salida para un campo de repetición de origen es incluir el mensaje ensamblado de destino en una fila for que opere en el origen de la repetición.

La correlación de mensajes de ejemplo repeating_source.msgmap convertirá un campo de repetición de un mensaje ensamblado de origen en una corriente de mensajes ensamblados del flujo de mensajes de llamada. repeating_source.msgmap reinicia la fila $target en una fila for para crear múltiples mensajes ensamblados de salida, uno por entrada de repetición. La carpeta Propiedades se copia para cada mensaje ensamblado, lo que significa que se utiliza el comportamiento copiar todas las cabeceras. A continuación, se copia un solo rtl:body en cada mensaje ensamblado de salida.

Repetición de proceso por lotes

Volver al principio

Crear varios mensajes de salida para un mensaje de entrada de varias partes

Los archivos de ejemplo para este caso se encuentran en la carpeta multipart_messages del proyecto Flujos de mensajes de ejemplo de correlación de mensajes.

Como para los campos de repetición, todo lo que se necesita para crear varios mensajes de salida para un mensaje de origen de repetición de varias partes es incluir el mensaje ensamblado de destino en una fila for que opere en la definición del mensaje de repetición de varias partes.

La diferencia clave entre un mensaje de repetición de varias partes y un campo de repetición normal es que un mensaje de varias partes se define mediante un grupo de contenido local con un modelo open u open-defined (una extensión de intermediarios para el esquema XML), mientras que un campo de repetición se define mediante un elemento.

En vez de introducir una construcción distinta de correlación de mensajes para un mensaje de varias partes, el grupo de contenido se trata como si su contenido fuese un comodín de un esquema XML. La creación de una correlación para un elemento comodín de esquema XML requiere la utilización de una subcorrelación llamada.

Como muestra el ejemplo, los elementos comodines se correlacionan mediante la utilización de una subcorrelación específica del elemento. En efecto, el comodín o elemento "unknown" se convierte en elemento "known" mediante una llamada de subcorrelación.

Repetición de proceso por lotes

Volver al principio

Crear varios mensajes de salida para entrada que no sea de repetición

El archivo de ejemplo para este caso es nonrepeating_source.msgmap y se encuentra en la carpeta multiple_output bajo el proyecto Flujos de mensajes de ejemplo de correlación de mensajes.

La técnica para producir múltiples mensajes es la misma tanto si el origen es de repetición como si no lo es. En este caso, varias filas $target se declaran explícitamente mediante la correlación. Cada fila de destino (target) declarada creará un mensaje de salida. En los casos de repetición, los ensamblajes múltiples se declararon implícitamente mediante las filas for que contenían los ensamblajes de destino y se creó un ensamblaje por elemento en for.

Repetición de proceso por lotes

Volver al principio

Clasificar, agrupar o intercalar campos en un mensaje

Los archivos de ejemplo para este caso se encuentran en la carpeta sorting en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes. Hay dos variaciones sobre este tema:

Clasificación con claves conocidas por adelantado

El archivo sorting.msgmap ilustra una clasificación o agrupación cuando los valores de claves para la clasificación se conocen mientras se crea la correlación. Se clasifican tres posibles valores de campo en tres mensajes separados utilizando el patrón de diseño Crear varios mensajes de salida para entrada que no sea de repetición.

Frecuentemente es necesario calcular cantidades totales o registrar cuentas después de haber transformado un solo mensaje en varios mensajes. Esto se ha de manejar mediante un segundo paso en el archivo total.msgmap. El flujo de mensajes sort.msgflow explica como conectar dos nodos de correlación para llevar esto a cabo.

Clasificación con claves procedentes de la base de datos

El archivo de ejemplo es sorting_dynamic.msgmap. Este ejemplo es bastante parecido al de Clasificación con claves conocidas por adelantado, la diferencia crucial es que la correlación necesita ir a la base de datos para obtener la lista de claves válidas. Los pasos de la correlación son los siguientes:

Como en el ejemplo anterior, esto no es suficiente para tener un mensaje de salida correcto y será necesario llamar de nuevo a la correlación total.msgmap para calcular los totales por mensaje de salida.

Volver al principio

Llamar a una correlación desde ESQL

Los archivos del ejemplo se encuentran en la carpeta esql_calling_msgmap, en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

El ejemplo muestra cómo llamar a una correlación desde ESQL. Esperamos que los usuarios llamen a subcorrelaciones (submap) en vez de a correlaciones principales (main). Una subcorrelación es cualquier correlación de mensajes concebida para ser llamada desde otra correlación o desde ESQL. Una subcorrelación se crea con el Asistente de Nueva correlación de mensajes (Archivo>Nuevo>Correlación de mensajes) seleccionando el botón de selección Esta correlación se invoca desde otra correlación....

Crear una subcorrelación en el Asistente de Nueva correlación de mensajes

La signatura ESQL esperada para llamar a una subcorrelación es:

	submapName(
		sourcePath1, [sourcePath2, [...]]
		[targetPath, ]
		InputLocalEnvironment [, OutputLocalEnvironment])
	

Hay siempre un parámetro sourcePath como mínimo; representa la entrada de mensajería que dirige el nodo de flujo de mensajes. Las vías de acceso de origen (sourcePath) son variables REFERENCE de ESQL que se inicializan para hacer referencia al árbol de origen antes de llamar a la correlación de mensajes.

targetPath es una variable opcional REFERENCE de ESQL que hace referencia al nodo del árbol raíz de destino. Ha de inicializarse antes de llamar a la correlación de mensajes. targetPath es opcional y si una correlación de mensajes no tiene ningún parámetro de destino, la correlación no creará ninguna salida de mensajería. Se utiliza para casos de mensaje a base de datos relacional, en los que las correlaciones se llaman desde nodos Database de ESQL.

InputLocalEnvironament y OutputLocalEnvironment son variables REFERENCE de ESQL inicializadas para los nombres de correlaciones del nodo ESQL asociado. Las correlaciones de mensajes se implementan como procedimientos en el ámbito del esquema, por lo que no pueden acceder directamente a los nombres de correlación.

El código de ejemplo inicializa los parámetros necesarios y llama a la correlación.

Volver al principio

Utilizar una correlación de mensajes en un caso de Agregación

Los archivos del ejemplo se encuentran en la carpeta esql_calling_msgmap, en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

Se ha implementado el patrón básico de ESQL llamando a una correlación. El código MODULE de ESQL se ha escrito para inicializar las carpetas Propiedades y Cabeceras, crear las referencias necesarias y llamar a la correlación.

La correlación construye un solo mensaje de salida desde todas las carpetas del nodo Aggregate (Request1, Request2, etc). Como MODULE de ESQL ya se ocupó de las propiedades y cabeceras, lo único que queda por hacer es copiar el contenido de LocalEnvironment.Aggregate.AgregateRequestFolderName en el mensaje de salida.

Volver al principio

Casos de esquema XML

Estos casos de ejemplo muestran el patrón de diseño para transformar modelos de esquema XML que utilicen comodines, extensiones de tipo y limitaciones, grupos de sustitución y grupos de modelo de contenido en una correlación de mensajes.

Volver al principio

Elementos comodín

Los archivos de ejemplo para procesar elementos comodín y atributos se encuentran en la carpeta multipart_messages del proyecto Flujos de mensajes de ejemplo de correlación de mensajes.

Los elementos comodín se manejan utilizando una subcorrelación. En la subcorrelación, el nombre de los elementos está codificado en fábrica. Para procesar distintos nombres de elementos desde el mismo comodín, utilice las filas if, condition y else.

El ejemplo implementa un caso sencillo de campo de repetición, pero en el caso ligeramente más complejo en el que el origen de repetición se modela como un mensaje de varias partes de intermediarios. Las herramientas de correlación manejan el mensaje de varias partes como un elemento comodín. Los comodines se manejan llamando a una subcorrelación que facilite el nombre de elemento correcto.

En la primera correlación, el mensaje ensamblado de destino está contenido en una fila for. La fila for opera sobre el mensaje de varias partes de repetición que contiene el único mensaje de origen. Cuando el ensamblaje de destino está contenido en la fila for, se efectuará la salida de los ensamblajes de mensajes de destino completos, uno por mensaje de varias partes de entrada en el origen. La primera correlación de mensajes también contiene una correlación para el mensaje comodín que soporta mensajes de varias partes. Esa correlación llama a una subcorrelación que ha de devolver una definición completa del elemento que representa el comodín.

Mensaje envoltorio de varias partes

En la segunda correlación, verá que el elemento de mensaje comodín se ha restringido para que sea un elemento rtl:body. En esta subcorrelación, el origen y el destino son lo mismo, y realiza una copia a fondo del origen para crear el destino.

Mensaje contenido en varias partes

Volver al principio

Herencia de tipo

El archivo de ejemplo de este caso es type_to_substitutiongroup.msgmap y se encuentra en la carpeta xmlschema en el proyecto Flujos de mensajes de ejemplo de correlación de mensajes.

En el editor de correlación de mensajes, se utilizan 'carpetas' especiales del árbol de origen y destino para mostrar las combinaciones válidas de tipo. El nombre de la carpeta es specializations for base type. Dentro de la carpeta pueden verse los elementos combinados con cualquier derivación no abstracta del tipo base. Cada una de las representaciones de elementos concretos contiene su contenido completo, con todos los atributos posibles seguidos de todos los elementos válidos. Esencialmente, el árbol muestra los distintos elementos XML que describe el modelo de esquema XML.

En la Correlación de mensajes de ejemplo, el origen se describe utilizando un modelo de esquema XML que permite las alternativas extensionType1 y extensionType2. Cada una de estas alternativas puede correlacionarse individualmente con el destino.

Se pueden combinar jerarquías de extensión de tipo con modelos de elección, grupos de sustitución, etc., aunque el ejemplo evite esa complejidad.

Volver al principio

Grupos de sustitución

El archivo de ejemplo de este caso es type_to_substitutiongroup.msgmap y se encuentra en la carpeta xmlschema en el proyecto Flujos de mensajes de ejemplo de correlación de mensajes.

En el editor de correlación de mensajes, se utilizan 'carpetas' especiales del árbol de origen y destino para mostrar los elementos válidos que utilizan combinaciones de grupos de sustitución. El nombre de la carpeta es substitutions for head element. Dentro de la carpeta se muestran los distintos nombres de elementos combinados con todas las derivaciones no abstractas para el tipo base. Cada una de las representaciones de elementos concretos contiene su contenido completo, con todos los atributos posibles seguidos de todos los elementos válidos. Esencialmente, el árbol muestra los distintos elementos XML que describe el modelo de esquema XML.

En la correlación de mensajes del ejemplo, el destino se describe utilizando un modelo de esquema XML que permite las alternativas Substitute1 y Substitute2 en el elemento abstracto HeadElement. Cada una de estas alternativas puede correlacionarse individualmente con el origen.

Los grupos de sustitución pueden combinarse con jerarquías de tipo, aunque el ejemplo evita esa complejidad.

Volver al principio

Grupos de modelo de repetición

Los archivos del ejemplo se encuentran en la carpeta modelgroups en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.

Volver al principio

Icono de la página principal   Volver a la Página de presentación de ejemplos