Este apartado explica cómo modificar el flujo de agregación simple que se proporciona para cumplir con distintos requisitos. Esto también puede resultar útil si se están actualizando flujos de agregación existentes de la versión 5 o anteriores del producto.
El terminal de Control del nodo Aggregate Control se utiliza para propagar el mensaje de control que contiene el estado y la información de seguimiento para una operación de agregación determinada. Puede utilizarlo de tres formas:
Los factores a tener en cuenta cuando se elige una de las opciones son:
En anteriores releases del producto, la opción 1 sólo se permitía si el valor de configuración del tiempo de espera excedido
del nodo Aggregate Control se había establecido en cero, es decir, que las operaciones de agregación no excedían nunca
el tiempo de espera. En la versión 6 del producto, la opción 1 es la mejor solución en todos los casos - tanto si se
utilizan tiempos de espera de agregación excedidos como si no. Utiliza la cantidad mínima de CPU para almacenar el estado de agregación
y simplifica el flujo de abanico de salida.
También en la Versión 6 del producto, los flujos que utilicen las opciones 2 y 3 tomarán por omisión, de forma transparente, la
opción 1. En otras palabras, se ignorarán todas las conexiones al terminal de control del nodo
Aggregate Control. Esto se hace para maximizar la eficacia de los flujos de agregación de versiones anteriores del producto
sin necesidad de volverlos a escribir.
Este procedimiento puede invertirse de forma que los mensajes de control se envíen al terminal de control, si está conectado,
exportando la siguiente variable de entorno al entorno de arranque del intermediario:
MQSI_AGGR_COMPAT_MODE=ON
La opción 2 es funcionalmente equivalente a la opción 1 en lo que se refiere al proceso de tiempo de espera excedido,
pero existe un desgaste de proceso adicional en la propagación del mensaje desde el terminal de control y en el proceso subsiguiente en el nodo
Aggregate Reply. Este desgaste se puede evitar conectando el terminal del
Control de nodo Aggregate Control, como en la opción 1.
La opción 3 es la elección más compleja entre las opciones disponibles y debe tenerse en cuenta que la elección de esta opción tiene implicaciones relacionados con el rendimiento y el comportamiento de la agregación de mensajes. Para que el proceso en el mecanismo de agregación sea más eficiente, antes de recibir ningún mensaje en el terminal de entrada, el nodo Aggregate Reply del flujo de mensajes de abanico de entrada (Fan-In) ha de haber recibido información del nodo Aggregate Control en el flujo de mensajes de abanico de salida (Fan-Out).
En determinadas situaciones, esto no puede llevarse a cabo, por ejemplo, cuando el proceso realizado en un mensaje de petición de abanico de salida es muy rápido y, al mismo tiempo, la entrega del mensaje desde el terminal de Control del nodo
Aggregate Control se retrasa debido al proceso en el nodo Compute.
Esto podría causar un problema en el proceso del nodo Aggregate
Reply.
No obstante, la agregación seguirá pudiendo realizarse correctamente si el tiempo de espera excedido de mensaje desconocido
(Unknown Message Timeout) del nodo Aggregate Reply no es cero. En ese caso, las respuestas desconocidas se almacenan y después se
vuelven a procesar tras el periodo de tiempo de espera excedido y, al llegar a este punto, se agrupan en la información de
estado de control. La operación de agregación sigue finalizando correctamente después del retraso causado por la
terminación del tiempo de espera excedido del mensaje desconocido.
Si establece en cero el tiempo de espera excedido del mensaje desconocido, las
respuestas que llegan antes del mensaje de control se propagarán directamente al terminal desconocido (Unknown) del
nodo Aggregate Reply y no se agruparán con el resto de los datos de agregación.
La opción 3 será parecida a esta imagen truncada:
El nodo AddMqmd Compute contendrá ESQL parecido a éste para que se pueda grabar el mensaje de control en una cola:
CREATE COMPUTE MODULE AggregationOut_AddMqmd
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
Ha de establecer la Modalidad de transacción del nodo MQInput en el flujo de abanico de salida en Sí para evitar la posibilidad de que los mensajes de respuesta sean recibidos por el flujo de abanico de entrada antes de que el nodo Aggregate Control haya almacenado la información de control.
Cuando el flujo de abanico de salida no se ejecuta bajo el control de transacciones, cada mensaje de petición de MQOutput se puede elegir para que la aplicación invocada lo procese inmediatamente. Dependiendo de la respuesta de esta aplicación, la respuesta podría recibirla el nodo Aggregate Reply antes de que se almacene la información de control.
El mismo problema puede producirse si el terminal de Control del nodo Aggregate Control se conecta a un nodo Compute y a un nodo MQOutput, es decir, que los flujos de abanico de entrada y de abanico de salida se encuentran en Para distintos. Incluso si el abanico de salida se ejecuta bajo una transacción, el alcance de la transacción es es la grabación del mensaje que efectúa el nodo MQOutput, por lo que las respuestas podrán seguir procesándose como desconocidas mientras se procesa la ramificación de control del flujo de abanico de entrada. Esto se explica en la opción 3 de arriba.
En ambos casos, la agregación seguirá pudiendo realizarse correctamente si el tiempo de espera excedido de mensaje desconocido (Unknown Message Timeout) del nodo Aggregate Reply no es cero. Las respuestas desconocidas se almacenan y después vuelven a procesarse tras el número de segundos especificado y, al llegar a este punto, se agrupan en la información de estado de control. La operación de agregación sigue finalizando correctamente después del retraso causado por la terminación del tiempo de espera excedido del mensaje desconocido. Si establece en cero el tiempo de espera excedido del mensaje desconocido, las respuestas que llegan antes del mensaje de control se propagarán directamente al terminal desconocido (Unknown) del nodo Aggregate Reply y no se agruparán con el resto de los datos de agregación.
Para resumir este apartado y el anterior se podría decir que el diseño más eficaz de un flujo de abanico de salida de agregación debe asegurarse de que:
Si sigue estas dos recomendaciones sobre el diseño, podrá estar seguro de que no se producirán los problemas de tiempo de espera excedido descritos anteriormente. No obstante, si por algún motivo no pudiese tener en cuenta estas recomendaciones, seguirá pudiendo establecer en un valor que no sea cero el parámetro de tiempo de espera excedido del nodo Aggregate Reply para garantizar que las operaciones de agregación se realizan correctamente.
El nodo Aggregate Reply tiene tres terminales de salida que no son de error: Out, Unknown y Timeout. Es importante comprender cuándo y por qué motivo los mensajes se envían desde estos distintos terminales, poniendo especial atención en el contexto transaccional. El contexto transaccional puede ser propiedad del nodo MQInput (esto se produce cuando un mensaje de respuesta entrante desencadena la salida desde el nodo Aggregate Reply) o puede ser propiedad del nodo Aggregate Reply propiamente dicho
Cuando es propiedad del nodo Aggregate Reply, el contexto de transacción tiene la semántica habitual, pero el control transaccional se centra en el nodo Aggregate Reply en vez de en el nodo MQInput. Las implicaciones de esto son que un error que se produzca después en el flujo de mensajes hará que el nodo Aggregate Reply se restituya y propague un mensaje a su terminal de captación (Catch), en vez de al nodo MQInput. Los mensajes que se propagan desde el nodo Aggregate Reply dentro del contexto de sus propias transacciones no los suministra directamente el nodo MQInput; el nodo Aggregate Reply es el nodo de entrada para esta invocación de flujo de mensajes.
El comportamiento transaccional del nodo Aggregate Reply se controla mediante su parámetro de configuración de modalidad de transacción (Transaction Mode). Asegúrese de que este valor y el del nodo MQInput son iguales para estar seguro de que toda la salida del nodo Aggregate Reply está bajo el mismo nivel de control transaccional.
Las siguientes situaciones están bajo el control transaccional del nodo MQInput:
Las siguientes situaciones están bajo el control transaccional del nodo Aggregate Reply:
El nodo Aggregate Reply tiene dos terminales de entrada: In y Control.
Si utiliza estos dos terminales, recuerde que el uso del terminal de Control es optativo, la forma más eficaz de suministrar datos
al nodo Aggregate Reply es tener un nodo
MQInput exclusivamente para el flujo de mensajes de abanico de entrada seguido de un nodo de filtro (Filter).
El nodo Filter se usa para dirigir un mensaje de entrada a los terminales In o
Control del nodo Aggregate Reply, según corresponda. Use este método en vez de usar dos nodos
MQInput en el flujo de mensajes: uno para el terminal de entrada y otro para el terminal de control. El flujo de abanico de entrada ha de ser similar a este:
El nodo Filter necesitará un módulo ESQL parecido al que aparece abajo para asegurarse de que los mensajes se
dirigen al terminal adecuado del nodo
Aggregate Reply:
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XML.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
Ha de utilizarse un solo nodo MQInput porque no hay manera de especificar cómo deben distribuirse las hebras adicionales (disponibles mediante la utilización de instancias adicionales) entre los dos nodos MQInput. Es probable que el tráfico en el terminal In del nodo Aggregate Reply sea más alto y, por lo tanto, sería más útil tener más hebras ejecutándose en su nodo de entrada, pero no esto no puede configurarse. Por lo tanto, es posible que el nodo necesite más hebras, haciendo copias de seguridad de mensajes de respuesta y atascando el mecanismo de agregación.
Este tema sólo es aplicable si el terminal de control del nodo Aggregate Control se conecta a una cola para su salida. Si el terminal de control no se conecta, se podrán solucionar las cuestiones tratadas en este apartado.
Como último recurso, si la solución anterior no puede implementarse por algún motivo, puede forzar al nodo MQInput que esté leyendo los mensajes de control a que funcione con una sola hebra. Esto puede llevarse a cabo en el panel Avanzadas de configuración del nodo MQInput estableciendo la Modalidad de orden en Por orden de cola y seleccionando Orden lógico. Esto libera todas las instancias adicionales configuradas para que las utilice el otro nodo MQInput. Esto sólo debe hacerse como último recurso debido a que el rendimiento del primer nodo MQInput quedará gravemente limitado.