Este tópico explica como modificar o fluxo de agregação simples fornecido para ajustar diferentes requisitos. Você também poderá achá-lo útil se estiver transportando fluxos de agregação existentes da Versão 5 e anterior do produto.
O terminal Controle do nó Aggregate Control é utilizado para propagar a mensagem de controle que contém as informações de status e rastreio para uma operação de agregação específica. Você pode utilizá-lo de três maneiras:
Os fatores que você deve ter em mente ao escolher uma das opções são:
Em releases anteriores do produto, a opção 1 era permitida apenas se a definição de configuração do tempo limite do nó Aggregate Control estivesse definida como zero,
ou seja, as operações de agregação nunca excediam o tempo limite. Na Versão 6 do produto, a opção 1 é a solução ideal em todos os casos - independente dos tempos limites de agregação serem utilizados ou não. Ela utiliza a menor quantidade de CPU para armazenar o estado de agregação e simplifica o fluxo de fan-out.
Também na Versão 6 do produto, os fluxos que utilizam as opções 2 e 3 de forma transparente
padronizarão para a opção 1. Em outras palavras, qualquer conexão para o Terminal de
Controle do nó Aggregate Control será ignorada. Isto serve para maximizar a eficiência
de fluxos de agregação das versões anteriores do produto, sem ser necessário regravar novamente estes fluxos. Este comportamento pode ser revertido, de modo que as mensagens de controle sejam enviadas para o terminal de controle, se ele estiver conectado, ao exportar a seguinte variável de ambiente para o ambiente de inicialização do intermediário:
MQSI_AGGR_COMPAT_MODE=ON
A opção 2 é funcionalmente equivalente à opção 1 com relação ao processamento de tempo limite, mas há um código extra de processamento adicional na propagação da mensagem a partir do terminal Controle e o processamento subseqüente no nó Aggregate Reply. Você pode evitar esse código extra não conectando o terminal Controle do nó Aggregate Control, como na opção 1.
A opção 3 é a mais complexa das opções disponíveis e você deve estar ciente que a escolha dessa opção tem implicações relacionadas ao desempenho e ao comportamento da agregação de mensagem. Para o processamento no mecanismo de agregação ser mais eficiente, o nó Aggregate Reply no fluxo de mensagens Fan-in deve ter recebido informações do nó Aggregate Control no fluxo de mensagens Fan-out antes de receber quaisquer mensagens em seu terminal Entrada.
Em algumas situações esse poderá não ser o caso, por exemplo, quando o processamento executado em uma mensagem de pedido com fan-out é muito rápido e, ao mesmo tempo, a entrega da mensagem a partir do terminal Controle do nó Aggregate Control é atrasada pelo processamento no nó Compute.
Isso pode causar potencialmente um problema no processamento do nó Aggregate
Reply.
No entanto, a agregação ainda será concluída corretamente se o Tempo Limite Desconhecido da Mensagem no nó Aggregate Reply não for zero. Nesse caso, as respostas desconhecidas são armazenadas e processadas novamente após o número do período de tempo limite e, nesse ponto, elas são consolidadas nas informações de estado de controle. A operação de agregação ainda é concluída corretamente após o retardo causado pela expiração do tempo limite desconhecido da mensagem.
Se você definir o Tempo Limite Desconhecido da Mensagem como zero, as respostas que vierem na frente da mensagem de controle serão propagadas diretamente para o terminal Desconhecido do nó Aggregate Reply e não serão consolidadas com o restante dos dados de agregação.
A opção 3 será semelhante a esta imagem truncada:
O nó AddMqmd Compute conterá ESQL similar a este para permitir que a mensagem de controle seja gravada em uma fila:
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;
Você deve definir o Modo de Transação do nó MQInput no fluxo de fan-out para Sim a fim de evitar a possibilidade que mensagens de resposta sejam recebidas pelo fluxo de fan-in antes das informações de controle serem armazenadas pelo nó Aggregate Control.
Quando o fluxo de fan-out não é executado sob o controle de transação, cada mensagem de pedido de fan-out agregada gravada pelos nós MQOutput é qualificada para ser processada imediatamente pelo aplicativo que está sendo chamado. Dependendo da resposta desse aplicativo, a resposta poderá ser recebida pelo nó Aggregate Reply antes das informações de controle serem armazenadas.
O mesmo problema poderá ocorrer se o terminal Controle do nó Aggregate Control for conectado a um nó Compute e a um nó MQOutput, ou seja, os fluxos de fan-in e fan-out estiverem em fluxos de mensagens diferentes. Mesmo que o fan-out seja executado sob uma transação, a extensão da transação será a gravação da mensagem pelo nó MQOutput, portanto, as respostas ainda poderão ser processadas como desconhecidas enquanto a ramificação Controle do fluxo de fan-in estiver em processamento. Isso é discutido na opção 3 da seção acima.
Em ambos os casos, a agregação ainda será concluída corretamente se Tempo Limite Desconhecido da Mensagem no nó Aggregate Reply não for zero. As respostas desconhecidas são armazenadas e processadas novamente após o número de segundos especificados e, nesse ponto, elas são consolidadas nas informações de estado de controle. A operação de agregação ainda será concluída corretamente após o retardo causado pela expiração do tempo limite desconhecido da mensagem. Se você definir o Tempo Limite Desconhecido da Mensagem como zero, as respostas que vierem na frente da mensagem de controle serão propagadas diretamente para o terminal Desconhecido do nó Aggregate Reply e não serão consolidadas com o restante dos dados de agregação.
Para resumir esta seção e a anterior, o design mais eficiente para um fluxo de fan-out de Agregação deve assegurar que:
Se você adotar essas duas recomendações de design, assegurará que os problemas de tempo limite do tipo descrito acima não ocorrerão. No entanto, se por alguma razão não for possível seguir essas recomendações, você ainda poderá definir o parâmetro Tempo Limite Desconhecido da Mensagem no nó Aggregate Reply para um valor diferente de zero, a fim de assegurar-se de que as operações de agregação sejam concluídas com êxito.
O nó Aggregate Reply tem três terminais de saída sem erro: Saída, Desconhecido e Tempo Limite. É importante entender quando e por quê as mensagens são enviadas desses terminais diferentes, prestando atenção especial ao contexto transacional. O contexto transacional pode pertencer ao nó MQInput (isso ocorrerá quando uma mensagem de resposta acionar a saída do nó Aggregate Reply) ou pode pertencer ao próprio nó Aggregate Reply.
Na situação em que ele pertence ao nó Aggregate Reply, o contexto da transação tem a semântica usual, mas o controle transacional é centralizado no nó Aggregate Reply em vez de no nó MQInput. As implicações disso são que um erro produzido posteriormente no fluxo de mensagens fará com que o nó Aggregate Reply seja revertido e propague uma mensagem para seu terminal Captura, em vez de para o nó MQInput. As mensagens propagadas a partir do nó Aggregate Reply dentro do contexto de suas próprias transações não são diretamente fornecidas do nó MQInput; o nó Aggregate Reply é o nó de entrada para essa chamada de fluxo.
O comportamento transacional do nó Aggregate Reply é controlado por seu parâmetro de configuração Modo de Transação. Você deve se certificar de que essa configuração e a configuração no nó MQInput sejam iguais, a fim de assegurar-se de que toda a saída do nó Aggregate Reply esteja no mesmo nível do controle transacional.
As seguintes situações estão sob controle transacional do nó MQInput:
As seguintes situações estão sob o controle transacional do nó Aggregate Reply:
O nó Aggregate Reply tem dois terminais de entrada: Entrada e Controle.
Se você utilizar esses dois terminais, lembre-se de que o uso do terminal Controle é opcional; a forma mais eficiente de fornecer dados para o nó Aggregate Reply é
ter um único nó MQInput para o fluxo de fan-in seguido por um nó Filter.
O nó Filter é utilizado para rotear uma mensagem de entrada para os terminais Entrada ou Controle do nó Aggregate Reply, conforme adequado. Utilize essa abordagem em vez de utilizar dois nós MQInput no fluxo de mensagens: um para o terminal Entrada e outro para o terminal Controle. O fluxo de fan-in precisa ficar semelhante a isto:
O nó Filter precisará de um módulo ESQL similar àquele mostrado abaixo para assegurar-se de que as mensagens sejam roteadas para o terminal adequado do nó 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;
Você deve utilizar um único nó MQInput, porque não há nenhum meio de especificar como todos os encadeamentos adicionais (disponíveis pelo uso de instâncias adicionais) devem ser distribuídos entre os dois nós MQInput. O tráfego no terminal Entrada do nó Aggregate Reply provavelmente será maior, portanto, será mais útil ter mais encadeamentos em execução em seu nó de entrada, mas não há nenhuma forma de configurar isso. Portanto, é possível que o nó fique sem encadeamentos, fazendo backup de mensagens de resposta e parando o mecanismo de agregação.
Essa discussão aplica-se apenas se o terminal Controle do nó Aggregate Control estiver conectado para saída em uma fila. Ao não conectar o terminal Controle, você pode superar os problemas discutidos nesta seção.
Em último caso, se a solução acima não puder ser implementada por alguma razão, você poderá forçar o nó MQInput que está lendo mensagens de controle a executar com encadeamento único. Você pode realizar isso no painel Avançado da configuração do nó MQInput, definindo Modo de Ordem para Por Ordem de Fila e selecionando Ordem Lógica. Isso libera todas as instâncias adicionais configuradas para serem utilizadas por outro nó MQInput. Você deve fazer isso apenas em último caso, porque o desempenho do primeiro nó MQInput ficará gravemente limitado.