WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Cómo se llena el árbol de mensaje

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

Cuando el nodo de entrada recibe el mensaje de entrada, crea y completa el árbol de propiedades (el primer subárbol del árbol de mensaje). Consulte el apartado Estructura del árbol de mensaje.

El nodo examina entonces el contenido de la corriente de bits del mensaje de entrada y crea el resto del árbol de mensajes 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:

Protocolo WebSphere MQ Enterprise Transport
Si su aplicación se comunica con el intermediario a través de estos protocolos, y su flujo de mensajes incluye el nodo MQInput 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 hay un MQMD válido al principio del mensaje, el mensaje se rechaza y no se lleva a cabo 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 después del MQMD. Estas cabeceras están encadenadas; el campo Formato de una cabecera define el formato de la cabecera siguiente, hasta la última cabecera, incluida ésta, que define el formato del cuerpo del mensaje. Si existe una cabecera MQRFH y MQRFH2 en la cadena, los datos de nombre y valor en cualquiera de estas dos cabeceras también pueden contener información sobre el formato de los datos siguientes. Si el valor que se especifica en Formato es un analizador reconocido, este valor siempre tiene prioridad sobre los datos de nombre y valor.

El intermediario invoca el analizador apropiado para interpretar cada cabecera, siguiendo 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 el orden elegido, pero el orden en el que los campos se analizan no afecta al orden en el que los campos aparecen 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 se define mediante el campo Formato de la cabecera inmediatamente anterior (si la parte siguiente es un formato de WebSphere MQ reconocido) o mediante los valores que se establecen 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 precedente.
  • El formato del cuerpo del mensaje se corresponde con el dominio de mensajes y el analizador que se debe invocar para el cuerpo de mensaje (por ejemplo XMLNSC). Esta información se establece en la cabecera MQRFH o MQRFH2, o en la propiedad Dominio del 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 hace falta que llene 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. El analizador de cuerpo del mensaje no es un formato de cabecera de WebSphere MQ reconocido, por lo que 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.

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

Estas acciones pueden tener como consecuencia que el intermediario sustituya información que una expresión ESQL o Java™ ha almacenado explícitamente.

Los campos CodedCharSetId y Encoding no se rellenan de la misma forma que el campo Formato. En concreto, el cuerpo del mensaje no se utiliza para determinar los valores CodedCharSetId y Encoding. En su lugar, estos valores afectan a la forma en que se escribe el mensaje. Esto puede provocar resultados inesperados si una cabecera de intermediario (por ejemplo MQRFH2) se elimina sin actualizar la cabecera precedente en la cadena con los valores de cabecera eliminados.

Cuando todas las cabeceras se han analizado, y los subárboles correspondientes se han creado en el árbol de mensaje, el nodo de entrada asocia el analizador especificado al cuerpo del mensaje. Especifique el analizador que se debe asociar al contenido del cuerpo del mensaje, bien en una cabecera del mensaje (por ejemplo, la carpeta <mcd> en la cabecera MQRFH2) o en las propiedades del nodo de entrada (si el mensaje no incluye cabeceras). El nodo de entrada realiza la asociación tal como se describe en la lista siguiente:

  • 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 y valor) determina el analizador que se asocia a este mensaje.
  • Si el mensaje no tiene una cabecera MQRFH o MQRFH2, o bien si la cabecera no identifica el dominio, la propiedad Dominio de mensajes del nodo de entrada indica el dominio del mensaje y el analizador que se ha de utilizar. Puede especificar un dominio y un analizador definidos por el usuario.
  • Si el dominio no se puede identificar mediante los valores de cabecera o la propiedad Dominio de mensajes del nodo de entrada, el mensaje se maneja como un objeto binario. El analizador BLOB se asocia al mensaje. Un BLOB se puede interpretar como una Serie hexadecimales y se puede modificar o examinar en el flujo de mensajes especificando la ubicación del subconjunto de la Serie.

De forma predeterminada y por motivos de rendimiento, el mensaje no se analiza inmediatamente. Puede que no sea necesario analizar el cuerpo del mensaje durante el flujo de mensajes. Sólo se analiza cuando se hace una referencia a su contenido.

Por ejemplo, el cuerpo del mensaje se analiza cuando se hace referencia a un campo en el cuerpo del mensaje, por ejemplo: Root.XMLNSC.MyDoc.MyField. En función de las rutas que se tomen en el flujo de mensajes, esto podría tener lugar en puntos diferentes. Esté método de análisis si es necesario también se denomina "análisis parcial" o "análisis a petición", y en un proceso típico no afecta a la lógica de un flujo de mensajes. Sin embargo, hay algunas implicaciones para los escenarios de manejo de errores; consulte Manejar errores en flujos de mensajes.

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

Si configura las cabeceras de mensaje o las propiedades del nodo de entrada para identificar un dominio y un analizador definidos por el usuario, es posible que el modo en el que éste interprete el mensaje y construya el árbol lógico difiera del modo que se describe aquí.

Protocolos WebSphere Broker File Transport, WebSphere Broker Adapters Transport, WebSphere MQ Web Services Transport y WebSphere Broker JMS 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 de entrada correspondientes, no será necesario que los mensajes recibidos incluyan una cabecera determinada. 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 otros protocolos soportados.

Si no hay ninguna cabecera, o las cabeceras no especifican el analizador para el cuerpo del mensaje, establezca las propiedades del nodo de entrada para definir el analizador de cuerpo del mensaje. Si no establece las propiedades de nodo de este modo, el mensaje se trata como un BLOB. Puede especificar un analizador definido por el usuario.

El nodo de entrada asocia el analizador especificado al cuerpo del mensaje (de la misma manera que para el protocolo WebSphere MQ Enterprise Transport) y, de forma predeterminada, el cuerpo del mensaje no se analiza inmediatamente.

Si configura las cabeceras de mensaje o las propiedades del nodo de entrada para identificar un dominio y un analizador definidos por el usuario, es posible que el modo en el que éste interprete el mensaje y construya el árbol lógico difiera 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 tema Estructura del árbol de mensaje). No es necesario que un mensaje tenga un subárbol Propiedades, pero puede que le interese crear uno para proporcionar una estructura de árbol de mensaje coherente, independientemente del nodo de entrada. Si está utilizando un nodo de entrada definido por el usuario, debe crear usted mismo un subárbol Propiedades en el árbol de mensaje.

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

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

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

Propiedades respecto al comportamiento de la carpeta MQMD para varios transportes

Existen diferencias en el modo en que se tratan la carpeta Propiedades y la carpeta MQMD respecto a qué carpeta tiene prioridad para los mismos campos. Este tratamiento está caracterizado por el tipo de transporte (por ejemplo, HTTP o WebSphere MQ) que se utilice.

Cuando el flujo de mensajes proviene de un nodo MQInput, tendrá un MQMD que deberá analizar. En este caso, la carpeta Propiedades proviene de los valores MQMD y, de este modo, la carpeta MQMD tiene prioridad sobre la carpeta Propiedades en cuanto a la propagación de valores entre carpetas. Este escenario significa que puede efectuar ESQL, por ejemplo, SET OutputRoot.MQMD.CorrelId y este mandato actualiza el valor de la carpeta Propiedades.

Cuando el flujo de mensajes proviene de un nodo de entrada que no es el nodo MQInput (como, por ejemplo, el nodo HTTPInput o un nodo de entrada definido por el usuario), no se analiza ninguna MQMD. En este caso de ejemplo, la carpeta Propiedades no proviene de un MQMD de entrada; se crea y se llena con valores de transporte que vienen desde otras cabeceras específicas de transporte. Cuando crea una carpeta MQMD en un flujo de mensajes que no provenía del transporte de WebSphere MQ, la cabecera MQMD no tiene prioridad sobre la carpeta Propiedades porque el transporte de WebSphere MQ no llenó la carpeta Propiedades. Por consiguiente, en este caso, la carpeta Propiedades sobrescribe los valores en MQMD.

La carpeta Propiedades se crea y representa un mensaje recibido en el transporte. En este escenario se están utilizando dos transportes totalmente diferentes que tienen diferentes significados y, por consiguiente, diferentes requisitos de la carpeta Propiedades. Cuando provienen de un nodo HTTPInput, las cabeceras HTTP tienen control sobre la carpeta Propiedades para campos similares. Cuando proviene del nodo MQInput, MQMD tiene control sobre la carpeta Propiedades para campos similares.

Por consiguiente, cuando añade una carpeta MQMD a un árbol que se creó mediante el transporte HTTP, esta carpeta MQMD no tiene control sobre la carpeta Propiedades y la dirección de la propagación de valores no es MQMD a Propiedades, es Propiedades a MQMD. El enfoque correcto es establecer el campo replyIdentifier de la carpeta Propiedades y utilizarlo para llenar el MQMD:
 SET OutputRoot.Properties.ReplyIdentifier = X' ..... '; 
El comportamiento no es exclusivo únicamente de los campos CorrelId a ReplyIdentifier. Se aplica a todos los campos similares entre la carpeta MQMD y Propiedades:
  • CorrelId
  • Encoding
  • CodedCharSetId
  • Persistence
  • Expiry
  • Priority
En resumen:
  1. Cuando el flujo de mensajes proviene de un nodo MQInput, MQMD tiene prioridad sobre la carpeta Propiedades en cuanto a propagación de valores entre las carpetas.
  2. Cuando el flujo de mensajes proviene de un nodo de entrada que no es el nodo MQInput (como, por ejemplo el nodo HTTPInput o un nodo de entrada definido por el usuario), la cabecera MQMD no tiene prioridad sobre la carpeta Propiedades.
  3. Cuando se añade una carpeta MQMD a un árbol que se creó mediante Transporte HTTP, este this MQMD no tiene control sobre la carpeta Propiedades y la dirección de la propagación de valores no es MQMD a Propiedades; es Propiedades a MQMD.

Ejemplo

SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD.Version = 2;
SET OutputRoot.MQMD.CorrelId = X'4d454e53414a453320202020202020202020202020202020';
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Persistence = 1;
SET OutputRoot.MQMD.Expiry = 10000;
SET OutputRoot.MQMD.Priority = 9;
SET OutputRoot.BLOB.BLOB = X'01';
Cuando proviene de un nodo HTTPInput, ninguno de estos cambios tendrá efecto y la salida MQMD del nodo Compute es:
(0x01000000):MQMD       = (
    (0x03000000):Version        = 2
    (0x03000000):CorrelId       = X'000000000000000000000000000000000000000000000000'
    (0x03000000):Encoding       = 546
    (0x03000000):CodedCharSetId = 1208
    (0x03000000):Persistence    = FALSE
    (0x03000000):Expiry         = -1
    (0x03000000):Priority       = 0
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:27


Tema de conceptoTema de concepto | Versión 8.0.0.5 | ac18520_