Cómo se rellena el árbol de mensajes

Inicialmente, el árbol de mensajes se rellena mediante el nodo de entrada del flujo de mensajes.

Cuando el nodo de entrada recibe el mensaje de entrada, crea el árbol Properties (el primer subárbol del árbol de mensajes) y lo rellena con las propiedades del nodo que ha configurado en el flujo de mensajes. A continuación, analiza el contenido de la corriente de bits del mensaje de entrada y crea el resto del árbol de mensajes para reflejar el contenido. Este proceso depende hasta cierto punto del propio nodo de entrada, que está regido por el transporte a través del cual se recibe el mensaje:

Protocolos de WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport y WebSphere MQ Telemetry Transport
Si la aplicación se comunica con el intermediario a través de estos protocolos y el flujo de mensajes incluye el nodo MQInput, MQeInput o SCADAInput correspondiente, todos los mensajes recibidos deben comenzar por una cabecera MQMD (Message Queue Message Descriptor). Si MQMD no está presente al principio del mensaje, se rechaza el mensaje y no se realiza ningún proceso adicional.

En primer lugar, el nodo de entrada invoca el analizador y crea el subárbol para dicha cabecera.

Un mensaje puede tener cero o más cabeceras adicionales después de MQMD que están encadenadas y el campo Formato de una cabecera define el formato de la cabecera siguiente hasta la última cabecera inclusive que define el formato del cuerpo del mensaje. Si en la cadena hay una cabecera MQRFH y MQRFH2, los datos de nombre/valor de cualquiera de estas dos cabeceras también pueden contener información acerca del formato de los datos siguientes. Si el valor especificado en el campo Formato es un analizador reconocido, éste siempre tendrá prioridad sobre los datos de nombre/valor.

El intermediario invoca el analizador adecuado para interpretar cada cabecera, siguiendo la cadena del mensaje. Cada cabecera se analiza independientemente. Los campos de una sola cabecera se analizan en un orden regido por el analizador. No puede prever ni basarse en el orden seleccionado sino que el orden en que se analizan los campos no afecta al orden en el que aparecen los campos en la cabecera.

El intermediario asegura que se mantenga la integridad de las cabeceras que preceden al cuerpo del mensaje. Se define el formato de cada parte del mensaje, ya sea mediante el campo Formato de la cabecera inmediatamente anterior (si la parte siguiente la reconoce el formato WebSphere MQ) o mediante los valores establecidos en la cabecera MQRFH o MQRFH2:

  • El formato de la primera cabecera es conocido porque debe ser MQMD.
  • El formato de cualquier cabecera siguiente del mensaje se establece en el campo Formato de la cabecera anterior.
  • El formato del cuerpo corresponde al dominio del mensaje y al analizador que se debe invocar para el cuerpo del mensaje (por ejemplo, XML). Esta información se establece en la cabecera MQRFH o MQRFH2 o en la propiedad de dominio del mensaje del nodo de entrada que recibe el mensaje.

Este proceso se repite tantas veces como sea necesario según el número de cabeceras que preceden al cuerpo del mensaje. No tiene que rellenar estos campos usted mismo, el intermediario maneja esta secuencia automáticamente.

El intermediario completa este proceso para asegurarse de que los campos Formato de las cabeceras identifican cada parte del mensaje. Si el intermediario no lo hace, es posible que WebSphere MQ no pueda entregar el mensaje. Debido a que el analizador del cuerpo del mensaje no es un formato de cabecera WebSphere MQ reconocido, el intermediario sustituye este valor en el campo Formato de la última cabecera por el valor MQFMT_NONE. El valor original de dicho campo se almacena en el campo Dominio de la cabecera MQRFH o MQRFH2 para conservar la información relacionada con el contenido del cuerpo del mensaje. Si no hay ningún MQRFH ni MQRFH2, la información se almacena en el árbol Properties.

Por ejemplo, si la cabecera MQRFH2 precede inmediatamente al cuerpo del mensaje y su campo Formato se establece en XML, lo que indica que el cuerpo del mensaje lo debe analizar el analizador XML genérico, el campo de dominio MQRFH2 se establece en XML y el campo Formato se restaura a MQFMT_NONE.

Estas acciones pueden dar como resultado que el intermediario sustituya una expresión ESQL para almacenar de forma explícita la información.

Cuando se hayan analizado todas las cabeceras y se hayan creado los subárboles correspondientes creados con el árbol de mensajes, el nodo de entrada asocia el analizador especificado con el cuerpo del mensaje. Debe especificar el analizador que se ha de asociar al contenido del cuerpo del mensaje. Puede hacerlo en una cabecera del mensaje, por ejemplo, la carpeta <mcd> de la cabecera MQRFH2 (el método recomendado generalmente) o en las propiedades del nodo de entrada (el método que se recomienda si el mensaje no incluye las cabeceras). El nodo de entrada crea la asociación como se describe a continuación:

  • Si el mensaje tiene una cabecera MQRFH o MQRFH2, el dominio que se identifica en la cabecera (ya sea en el formato o en los datos de nombre/valor) determina el analizador asociado a este mensaje.

    En los flujos de mensajes de publicación/suscripción, el nodo MQeInput crea mensajes con formato WebSphere MQ y cabeceras MQRFH2 a partir de los mensajes de entrada que el escucha recibe en la puerta TCP/IP.

    En los flujos de mensajes de punto a punto, la acción que lleva a cabo el nodo MQeInput depende del tipo de mensaje (MQeMsgObject o MQeMbMsgObject) que recibe el escucha. Para obtener información detallada, consulteWebSphere MQ Mobile Transport.

    El nodo SCADAInput crea los mensajes con formato WebSphere MQ y cabeceras MQRFH2 a partir de los mensajes de entrada que el escucha recibe en la puerta TCP/IP.

  • Si el mensaje no tiene una cabecera MQRFH o MQRFH2 ni la cabecera identifica el dominio sino que las propiedades del nodo de entrada, almacenadas en el árbol Properties, indican el dominio del mensaje, se utiliza el analizador que especifica la propiedad del nodo de entrada. Puede especificar un analizador definido por el usuario.
  • Si no se puede identificar el dominio del mensaje mediante los valores de cabecera o mediante las propiedades del nodo de entrada, el mensaje se maneja como un objeto binario (BLOB). El analizador BLOB se asocia con el mensaje. Se puede interpretar un BLOB como una serie de caracteres hexadecimales y se puede modificar o analizar en el flujo de mensajes especificando la ubicación del subconjunto de la serie.

El cuerpo del mensaje no se analiza por motivos de rendimiento. Es posible que la configuración del flujo de mensajes no requiera que se analice el cuerpo del mensaje. El cuerpo se analiza solamente cuando se hace una referencia a su contenido durante el flujo de mensajes.

Por ejemplo, el cuerpo del mensaje se analiza cuando hace referencia a Root.XML.Field (o InputRoot.XML.Field en el nodo Compute) o Root.MRM.Field. Dependiendo de las vías de acceso que tome en el flujo de mensajes, este análisis puede llevarse a cabo en puntos diferentes. Cuando este análisis es el primer método necesario, se hace referencia al mismo también como un análisis parcial y, durante el proceso normal, no afecta a la lógica de un flujo de mensajes. No obstante, hay algunas implicaciones para los casos de manejo de errores, como se describe en Manejo de errores en flujos de mensajes.

Si desea que un flujo de mensajes acepte mensajes de más de un dominio de mensajes, puede incluir una cabecera MQRFH2 en el mensaje de la cual los nodos de entrada extraerán el dominio del mensaje y la información de definición del mensaje relacionada (el conjunto, tipo y formato).

Si configura las cabeceras de los mensajes o las propiedades del nodo de entrada para identificar un analizador definido por el usuario, el modo en que interpreta el mensaje y crea el árbol lógico puede ser diferente del que se describe aquí.

Protocolos de WebSphere MQ Multicast Transport, WebSphere MQ Real-time Transport y WebSphere MQ Web Services Transport
Si la aplicación se comunica con el intermediario a través de estos protocolos soportados y el flujo de mensajes incluye los nodos Real-timeInput, HTTPInput o HTTPRequest correspondiente, no es necesario que ningún mensaje recibido incluya una cabecera determinada. Las aplicaciones pueden incluir la cabecera MQRFH2 para proporcionar información relacionada con los mensajes, por ejemplo, sobre publicaciones y suscripciones. Si se incluyen cabeceras reconocidas, el nodo de entrada invoca los analizadores correctos para interpretar las cabeceras y para crear las parte relevantes del árbol de mensajes, como se describe para otros protocolos soportados.

Si no hay ninguna cabecera o si estas cabeceras no especifican el analizador para el cuerpo del mensaje, debe establecer las propiedades del nodo de entrada para definir el analizador del cuerpo del mensaje. Si no lo hace, el mensaje se trata como un BLOB. Puede especificar un analizador definido por el usuario.

El analizador especificado se asocia al cuerpo del mensaje mediante el nodo de entrada (del mismo modo que lo hace para los protocolos WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport, y WebSphere MQ Telemetry Transport) y no se analiza el cuerpo del mensaje.

Si configura las cabeceras de los mensajes o las propiedades del nodo de entrada para identificar un analizador definido por el usuario, el modo en que interpreta el mensaje y crea el árbol lógico puede ser diferente del que se describe aquí.

Todos los demás protocolos
Si desea que el flujo de mensajes acepte mensajes de un protocolo de transporte para el que WebSphere Business Integration Message Broker no proporciona un soporte incorporado o si desea proporcionar algún proceso específico cuando reciba un mensaje, utilice la interfaz de programación del lenguaje Java o C para crear un nuevo nodo de entrada definido por el usuario.

Esta interfaz no genera automáticamente un subárbol Properties para un mensaje (este subárbol se describe en Árbol de propiedades). No es necesario que un mensaje tenga un subárbol Properties aunque puede resultarle útil crear uno para proporcionar una estructura de árbol de mensajes coherente independientemente del nodo de entrada. Si desea crear un subárbol Properties con el árbol de mensajes y está utilizando un nodo de entrada definido por el usuario, debe hacerlo manualmente.

Si tiene que procesar mensajes que no se ajustan a ninguno de los dominios de mensajes definidos, puede utilizar la interfaz de programación de lenguaje C para crear un analizador definido por usuario nuevo.

Consulte la interfaz del nodo para comprender cómo utiliza los analizadores y si puede configurarla para modificar su comportamiento. Si el nodo utiliza un analizador definido por usuario, la estructura de árbol creada para el mensaje puede ser ligeramente diferente de la creada para analizadores incorporados. Un nodo de entrada definido por el usuario puede analizar un mensaje de entrada por completo o puede participar en el análisis parcial en el que se analiza el cuerpo del mensaje solamente cuando sea necesario.

También puede crear sus propios nodos de proceso de salida y de mensajes en C o Java.

Conceptos relacionados
Estructura lógica de árbol
Árbol de mensajes
Árbol Environment
Árbol LocalEnvironment
Árbol ExceptionList
Árbol de propiedades
Análisis parcial
Nombres de correlación

Tareas relacionadas
Desarrollo de aplicaciones de flujos de mensajes

Referencia relacionada
Nodos incorporados
Nodos definidos por el usuario
Cabecera MQRFH2