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 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:
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:
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.
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:
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.
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, este análisis podría tener lugar en puntos diferentes. Este método "analizar si es necesario" también se denomina 'análisis parcial' o 'análisis a petición' y, en el proceso habitual, 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í.
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 los protocolos WebSphere MQ Enterprise Transport y WebSphere MQ Telemetry Transport) y, de forma predeterminada, el cuerpo de 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í.
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.
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; a continuación debe analizar un MQMD. 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. Este escenario significa que la carpeta Propiedades no proviene de un MQMD de entrada; se crea y se llena con valores de transporte que vienen con 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.
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:
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