Cómo se llena el árbol de mensaje

El nodo de entrada del flujo de mensajes llena inicialmente el árbol de mensaje.

Cuando el nodo de entrada recibe el mensaje de entrada, crea el árbol Propiedades (el primer subárbol del árbol de mensaje) y lo llena con las propiedades de nodo que se han configurado en el flujo de mensajes. Entonces examina el contenido de la corriente de bits del mensaje de entrada y crea el resto del árbol de mensaje para reflejar dicho contenido. Este proceso depende hasta cierto punto del propio nodo de entrada, que está controlado por el transporte a través del cual se recibe el mensaje:

Protocolos WebSphere MQ Enterprise 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, o SCADAInput correspondiente, todos los mensajes que se reciben deben empezar con una cabecera MQMD (Message Queue Message Descriptor - Descriptor de mensaje de cola de mensajes). Si no existe ningún MQMD válido al principio del mensaje, se rechaza el mensaje y no se realiza ningún proceso adicional.

El nodo de entrada invoca primero el analizador MQMD y crea el subárbol para dicha cabecera.

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

El intermediario invoca el analizador apropiado para interpretar cada cabecera, a continuación de la cadena del mensaje. Cada cabecera se analiza de forma independiente. Los campos contenidos en una sola cabecera se analizan en un orden controlado por el analizador. No puede predecir o confiar en el orden elegido, pero el orden en el 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 a un cuerpo de mensaje. El formato de cada parte del mensaje lo definen el campo Formato de la cabecera inmediatamente anterior (si la parte siguiente es un formato de WebSphere MQ reconocido) o los valores establecidos en la cabecera MQRFH o MQRFH2:

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

Este proceso se repite tantas veces como sea necesario para el número de cabeceras que preceden al cuerpo de mensaje. No tiene que llenar estos campos; el intermediario maneja automáticamente esta secuencia.

El intermediario realiza este proceso para asegurar que los campos Formato de las cabeceras identifican correctamente cada parte del mensaje. Si el intermediario no realiza este proceso, es posible que WebSphere MQ no pueda entregar el mensaje. Puesto que el analizador de cuerpo de mensajes no es un formato de cabecera de 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 en la cabecera MQRFH o MQRFH2 para conservar la información sobre el contenido del cuerpo de mensaje. Si no existe MQRFH o MQRFH2, la información se almacena en el árbol Propiedades.

Por ejemplo, si la cabecera MQRFH2 precede inmediatamente al cuerpo de mensaje y el campo Formato está establecido en XML, lo que indica que el cuerpo de mensaje debe ser analizado por el analizador XML genérico, el campo Dominio de MQRFH2 se establece en XML y el campo Formato se restablece en MQFMT_NONE.

Es posible que estas acciones hagan que la información se almacene explícitamente mediante la sustitución de una expresión ESQL por el intermediario.

Cuando se han analizado todas las cabeceras y se han creado los subárboles correspondientes en el árbol de mensaje, el nodo de entrada asocia el analizador especificado al cuerpo del mensaje. Debe especificar el analizador que se debe asociar al contenido del cuerpo del mensaje. Puede especificarlo en una cabecera del mensaje, por ejemplo la carpeta <mcd> de la cabecera MQRFH2 (recomendado en general), o en las propiedades de nodo de entrada (recomendado si el mensaje no incluye cabeceras). El nodo de entrada realiza 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 (en Formato o en los datos de nombre/valor) determina el analizador que se asocia con este mensaje.

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

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

El cuerpo de mensaje no se analiza por razones de rendimiento; es posible que la configuración del flujo de mensajes no necesite que se analice el cuerpo de mensaje. El cuerpo sólo se analiza cuando se hace una referencia al contenido durante el flujo de mensajes.

Por ejemplo, el cuerpo de mensaje se analiza cuando se hace referencia a Root.XML.Field (o InputRoot.XML.Field en el nodo Compute) o Root.MRM.Field. En función de las vías de acceso tomadas en el flujo de mensajes, este análisis puede tener lugar en puntos diferentes. Este análisis, en primera instancia, se conoce también como análisis parcial y, en el proceso normal, no afecta a la lógica de un flujo de mensajes. Sin embargo, existen algunas implicaciones para los escenarios de manejo de errores, tal como se describe en el apartado Manejar errores en flujos de mensajes.

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

Si configura las cabeceras de mensaje o las propiedades de nodo de entrada para identificar un analizador definido por el usuario, es posible que el modo en el que éste interpreta el mensaje y construye el árbol lógico difieran del modo 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 correspondientes, no es necesario que los mensajes que se reciben incluyan una cabecera determinada. Las aplicaciones pueden incluir la cabecera MQRFH2 para proporcionar información relacionada con el mensaje, por ejemplo sobre publicaciones y suscripciones. Si se incluyen cabeceras reconocidas, el nodo de entrada invoca los analizadores apropiados para interpretar las cabeceras y para crear las partes pertinentes del árbol de mensaje, como se describe para los demás protocolos soportados.

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

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

Si configura las cabeceras de mensaje o las propiedades de nodo de entrada para identificar un analizador definido por el usuario, es posible que el modo en el que éste interpreta el mensaje y construye el árbol lógico difieran del modo 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 Message Broker no proporciona soporte incorporado o desea que proporcione algún proceso específico al recibir un mensaje, utilice la interfaz de programación de lenguaje Java o C para crear un nuevo nodo de entrada definido por el usuario.

Esta interfaz no genera automáticamente un subárbol Propiedades para un mensaje (este subárbol se describe en el apartado Estructura del árbol de mensaje). No es obligatorio que un mensaje tenga un subárbol Propiedades, aunque es posible que encuentre útil crear uno para proporcionar una estructura de árbol de mensaje coherente independientemente del nodo de entrada. Si desea crear un subárbol Propiedades en el árbol de mensaje y está utilizando un nodo de entrada definido por el usuario, deberá realizarlo usted mismo.

Si necesita 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 nuevo analizador definido por el usuario.

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

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

Conceptos relacionados
Estructura del árbol lógico
Estructura del árbol de mensaje
Estructura del árbol Environment
Estructura del árbol de Entorno local
Estructura del árbol Lista de excepciones
Análisis parcial
Nombres de correlaciones
Tareas relacionadas
Manejar errores en flujos de mensajes
Desarrollar flujos de mensajes
Referencia relacionada
Nodos incorporados
Nodos definidos por el usuario
Cabecera MQRFH2
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac18520_