Obtenga información acerca de cómo modificar el flujo de agregación 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 AggregateControl 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. Tiene las opciones siguientes para conectar el terminal Control:
Los factores a tener en cuenta cuando se elige una de las opciones son:
En determinadas situaciones de l opción 3, es posible que no existan implicaciones de rendimiento y de comportamiento, 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 AggregateControl Control se retrasa debido al proceso en el nodo Compute. En este caso se podría ocasionar un problema en el proceso del nodo AggregateReply.
No obstante, la agregación se podrá completar correctamente si el Tiempo de espera de mensaje desconocido del nodo AggregateReply no es cero. En este caso, las respuestas desconocidas se almacenan y luego se vuelven a procesar después del período de tiempo de espera y, llegado a este punto, se consolidan en la información del estado de control. No obstante, la operación de agregación se completa correctamente después del retardo debido a que ha caducado el Tiempo de espera de mensaje desconocido.
Si establece Tiempo de espera de mensaje desconocido en cero, las respuestas que llegan antes que el mensaje de control se propagan directamente en el terminal Desconocido del nodo AggregateReply y no se consolidan con el resto de los datos de agregación.
La opción 3 es similar a la siguiente imagen truncada:
El nodo Compute AddMqmd Compute contiene ESQL parecido al siguiente que permite 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.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
Debe establecer la Modalidad de transacción del nodo MQInput del flujo de abanico de salida en Sí para evitar la posibilidad de que los mensajes de respuesta se reciban en el flujo de abanico de entrada antes de que el nodo AggregateControl 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, es posible que el nodo AggregateReply reciba la respuesta antes de que se almacene la información de control.
El mismo problema puede producirse si el terminal de Control del nodo AggregateControl 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 flujos de mensajes diferentes. Incluso si el abanico de salida se ejecuta bajo una transacción, el alcance de la transacción 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. Este escenario se describe en la opción 3 de la sección anterior.
En ambos casos, la agregación se completa correctamente si Tiempo de espera de mensaje desconocido del nodo AggregateReply 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. No obstante, la operación de agregación se completa correctamente después del retardo debido a que ha caducado el Tiempo de espera de mensaje desconocido. Si establece Tiempo de espera de mensaje desconocido en cero, las respuestas que llegan antes del mensaje de control se propagan directamente al terminal Desconocido del nodo AggregateReply y no se consolidan 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 no puede utilizar estas opciones, puede establecer el parámetro Tiempo de espera de mensaje desconocido del nodo AggregateReply en un valor que no sea cero para asegurarse de que las operaciones de agregación se completan correctamente.
El nodo AggregateReply 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 es así cuando un mensaje de respuesta entrante desencadena la salida desde el nodo AggregateReply, o puede ser propiedad del nodo AggregateReply propiamente dicho.
Cuando el contexto de transacción es propiedad del nodo AggregateReply, el contexto de transacción tiene la semántica típica pero el control de las transacciones está centrado en el nodo AggregateReply y no en el nodo MQInput, lo cual implica que si se produce un error más adelante en el flujo de mensajes, el nodo AggregateReply se retrotraerá y propagará un mensaje a su terminal Catch, en lugar de hacerlo al nodo MQInput. Los mensajes que se propagan desde el nodo AggregateReply dentro del contexto de sus propias transacciones no los suministra directamente el nodo MQInput; el nodo AggregateReply es el nodo de entrada para esta invocación de flujo de mensajes.
El comportamiento transaccional del nodo AggregateReply se controla mediante su parámetro de configuración Modalidad de transacción. Asegúrese de que este valor y el del nodo MQInput son iguales para garantizar que toda la salida del nodo AggregateReply 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 AggregateReply:
El nodo AggregateReply 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 AggregateReply es tener un nodo
MQInput exclusivamente para el flujo de mensajes de abanico de entrada seguido de un nodo Filter.
El nodo Filter se usa para dirigir un mensaje de entrada a los terminales De entrada o de
Control del nodo AggregateReply, 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 diagrama:
El nodo Filter necesita un módulo ESQL parecido al del ejemplo siguiente
para asegurarse de que los mensajes se dirigen al terminal adecuado del
nodo AggregateReply:
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XMLNSC.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
Debe utilizar un único nodo MQInput porque no puede especificar cómo se deben distribuir las hebras adicionales (disponibles al utilizar instancias adicionales) entre los dos nodos MQInput. El tráfico en el terminal de entrada del nodo AggregateReply es posible que sea más elevado; por consiguiente, es útil tener más hebras ejecutándose en este nodo de entrada, pero 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.
Esta situación sólo es aplicable si el terminal de control del nodo AggregateControl se conecta a una cola para su salida. Puede solucionar estos problemas si no conecta el terminal de control.
Si no es posible implementar la solución anterior, puede forzar el nodo MQInput que lee los mensajes de control para que funcione con una sola hebra:
No obstante, el rendimiento del primer nodo MQInput se ve notablemente limitado como consecuencia de esta configuración.