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.
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.
Un mensaje ensamblado de WebSphere Message Broker incluye cuatro elementos enumerados en la imagen:
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.
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.
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
:
En este ejemplo:
$source/rtl:body/content
igual a cero los procesarán nodos de
flujos de mensajes en sentido descendente desde el nodo Label
Target1;$source/rtl:body/content
mayor que cero los procesarán
nodos de flujos de mensajes en sentido descendente desde el nodo Label
Target2;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.
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:
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.
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.
Compute
de ESQL para llamar a la correlación, como se explica
más abajo.Compute
de ESQL para
llamar a la correlación, como se explica
más abajo.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:
En este caso, un solo mensaje se transforma en distintos mensajes dirigidos a distintos sistemas de información de la empresa o, por el contrario, contiene varios campos de repetición que se procesan mejor individualmente;
Un mensaje de varias partes es un mensaje modelado utilizando la función mensaje de varias partes de los intermediarios, que permite combinar distintos formatos físicos e incluso distintos diccionarios en un solo mensaje de proceso por lotes.
Un mensaje de origen contiene datos que han de transformarse en mensajes separados para varios sistemas EIS. Es necesario combinar los campos individuales, que no sean de repetición, para crear varios mensajes de salida.
Un mensaje de origen contiene un campo de repetición (quizá una factura) que necesita transformarse en varios mensajes de salida basados en un valor del campo (quizá un identificador de un socio comercial).
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
.
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.
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.
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
.
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:
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.
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:
$db:select
para obtener la lista de claves desde una base de datos.for
procesa cada elemento, de uno en uno, desde
$db:select
. for
seleccionada hay otra fila
for
que, esta vez, elige cada registro del origen, de uno en uno.if
y una fila condition
filtran las dos filas for
de forma que sólo produzcan un mensaje de salida las filas
en las que coincida la clave. $target
crea los mensajes de salida, uno por valor de clave único
que esté en la base de datos y en el mensaje de origen.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.
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....
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.
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.
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.
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.
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.
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.
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.
Los archivos del ejemplo se encuentran en la carpeta modelgroups en el proyecto Flujos de mensajes del ejemplo de correlación de mensajes.