O fluxo de difusão de agregação recebe a mensagem de entrada inicial e a reestrutura para apresentar vários pedidos a vários aplicativos de destino.
Antes de começar:
Você pode incluir o fluxo fan-out e fan-in no mesmo fluxo de mensagens. Entretanto, você pode preferir criar dois fluxos separados. Para obter informações adicionais sobre os benefícios de como configurar fluxos de mensagens separados, consulte Associando Fluxos de Agregação de Difusão e Recepção.
Para criar o fluxo de difusão:
No entanto, se não desejar que uma mensagem de controle seja enviada do nó AggregateControl para o nó AggregateReply, será necessário conectar o terminal Control ao nó AggregateReply correspondente no fluxo de fan-in (direta ou indiretamente, conforme descrito em Associando Fluxos de Agregação de Difusão e Recepção). Se você conectá-lo indiretamente ao nó AggregateReply, por exemplo, por meio de um nó MQOutput, deverá incluir um nó Compute para incluir os cabeçalhos apropriados na mensagem para assegurar que ele possa ser transmitido com segurança.
Além disso, para que o terminal Control e conexões dele sejam reconhecidas, você deve ativar a variável de ambiente MQSI_AGGR_COMPAT_MODE. No entanto, escolher essa opção tem implicações em relação ao desempenho e ao comportamento das agregações de mensagens. Para obter uma descrição completa dessas implicações e da variável de ambiente, consulte Utilizando Mensagens de Controle em Fluxos de Agregação.
Se os aplicativos de destino que manipulam os pedidos de subtarefa puderem extrair informações de que precisam da única mensagem de saída, não será necessário incluir um nó Compute para dividir a mensagem. Você pode transmitir toda a mensagem de entrada para todos os aplicativos de destino.
Se seus aplicativos de destino esperam receber um pedido individual, não a mensagem de entrada inteira, será necessário incluir um nó Compute para gerar cada mensagem de saída de subtarefa individual a partir da mensagem de entrada. Configure cada nó Compute da seguinte maneira, copiando o subconjunto apropriado da mensagem de entrada para cada mensagem de saída:
Se você especificar um destes valores, o intermediário assumirá que você está customizando o nó Compute com ESQL que grava em LocalEnvironment e que copiará sobre todos os elementos nessa árvore que são necessários na mensagem de saída.
Se desejar modificar Ambiente Local, inclua a seguinte instrução para copiar as informações agregadas requeridas da mensagem de entrada para a mensagem de saída:
SET OutputLocalEnvironment.ComIbmAggregateControlNode = InputLocalEnvironment.ComIbmAggregateControlNode;
O nó de saída deve ser um nó de saída que suporta o modelo de pedido/resposta, como um nó MQOutput, ou uma mistura destes nós (dependendo dos requisitos dos aplicativos de destino).
As informações gravadas por nós internos são o nome da fila, o nome do gerenciador de filas, o ID da mensagem e o ID de correlação (do MQMD) e o identificador de resposta da mensagem (definido com o mesmo valor que o ID da mensagem).
O nó AggregateRequest grava um registro no WebSphere MQ para cada mensagem que ele processa. Este registro permite que o nó AggregateReply identifique a qual pedido cada resposta está associada. Se seus nós de saída não forem transacionais, a mensagem de resposta poderá chegar no fluxo de recepção antes da consolidação da atualização desse banco de dados. Para obter detalhes sobre como é possível utilizar tempos limites para evitar essa situação, consulte Definindo Tempos Limites para Agregação.