Ampliar el ejemplo de agregación

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.

Control del estado de agregación en abanico de salida

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:

  1. Dejándolo sin conectar.
  2. Conectarlo directamente al terminal de entrada de control del nodo AggregateReply. La conexión directa sólo es aplicable si ambos nodos están en el mismo flujo de mensajes.
  3. Conectarlo a un nodo MQOutput, y utilice un nodo Compute para añadir un MQMD que graba el mensaje de control en una cola definida por el usuario. El nodo AggregateReply correspondiente, que se encuentra probablemente en un flujo distinto, tiene un nodo MQInput que se lee desde esta cola conectado a su terminal de control. Es posible que los flujos de agregación existentes de la versión 5 y anteriores del producto funcionen bien de esta forma.

Los factores a tener en cuenta cuando se elige una de las opciones son:

Gestión de transacciones en abanico de salida

Debe establecer la Modalidad de transacción del nodo MQInput del flujo de abanico de salida en 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.

Contexto transaccional en abanico de entrada

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:

Evitar la falta de hebras en el abanico de entrada

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:
Flujo de mensajes de abanico de entrada con filtrado
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:

  1. En el panel Avanzadas de la configuración del nodo Modalidad de ordenMQInput, establezca Modalidad de orden en Por orden de cola.
  2. Seleccione Orden lógico, que libera las instancias adicionales configuradas, de modo que puedan utilizarse en otro nodo MQInput.

No obstante, el rendimiento del primer nodo MQInput se ve notablemente limitado como consecuencia de esta configuración.

Volver a la página inicial del ejemplo