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:
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:
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:
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.
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í.
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í.
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.