Estendendo a Amostra Aggregation

Descubra como modificar o fluxo de agregação que é fornecido para ajustar diferentes requisitos. Você também pode descobrir que essa amostra é útil se estiver portando fluxos de agregação existentes a partir da Versão 5 do produto e da anterior.

Controle de estado de agregação em fan-out

O terminal de Controle do nó AggregateControl é usado para propagar a mensagem de controle contendo as informações de status e de rastreamento para uma operação de agregação específica. Você possui as seguintes opções para o cabeamento do terminal de Controle:

  1. Deixá-lo desconectado.
  2. Conectá-lo diretamente ao terminal de entrada Controle do nó AggregateReply. Cabeamento direto é aplicável apenas se ambos os nós estiverem no mesmo fluxo de mensagens.
  3. Conectá-lo a um nó MQOutput e utilizar um nó Compute para incluir um MQMD, que grava a mensagem de controle em uma fila definida pelo usuário. O nó correspondente AggregateReply, o qual está provavelmente em um fluxo separado, possui um nó MQInput lendo a partir dessa fila com cabo em seu terminal de Controle. Fluxos de agregação existentes a partir da Versão 5 do produto e anterior pode funcionar nesse modo.

Os fatores que você deve considerar ao escolher uma das opções são:

Gerenciando Transações em Fan-out

Você deve configurar o Modo de Transação do nó MQInput no fluxo fan-out para Sim para evitar a possibilidade de que mensagens de resposta sejam recebidas pelo fluxo fan-in antes das informações de controle terem sido armazenadas pelo nó AggregateControl.

Quando o fluxo de fan-out não é executado sob o controle de transação, cada mensagem de pedido de fan-out agregada que é gravada pelos nós MQOutput é elegível para ser processada imediatamente pelo aplicativo que está sendo chamado. Dependendo da resposta a partir desse aplicativo, a resposta pode ser recebida pelo nó AggregateReply antes das informações de controle terem sido armazenadas.

O mesmo problema pode ocorrer caso o terminal de Controle do nó AggregateControl esteja conectado a um nó Compute e um nó MQOutput, ou seja, os fluxos fan-in e fan-out situam-se 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 Control do fluxo de fan-in estiver em processamento. Esse cenário é discutido na opção 3 da seção precedente.

Em ambos os casos, a agregação ainda conclui-se corretamente caso o Tempo Limite Desconhecido da Mensagem no nó AggregateReply não seja zero. Respostas desconhecidas são armazenadas e em seguida 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 atraso causado pelo vencimento do Tempo Limite Desconhecido da Mensagem. Caso você configure o Tempo Limite Desconhecido da Mensagem para zero, respostas que vierem na frente da mensagem de controle serão propagadas diretamente para o terminal Unknown do nó AggregateReply e não serão consolidadas com o resto dos dados de agregação.

Para resumir ambas as seções, esta e a anterior, o projeto mais eficiente para um fluxo fan-out de Agregação assegura que:

Se você adotar as opções com design mais eficiente, isto garantirá que os problemas de tempo limite do tipo descrito no texto anterior não ocorram. No entanto, caso ele esteja impossibilitado de usar essas opções, você ainda pode configurar o parâmetro Tempo Limite Desconhecido da Mensagem no nó AggregateReply para um valor diferente de zero para assegurar que as operações de agregação concluam-se com êxito.

Contexto Transacional em Fan-in

O nó AggregateReply possui três terminais de saída sem erro: Out, Unknown e Timeout. É importante entender quando e por que as mensagens são enviadas desses terminais diferentes, prestando atenção especial ao contexto transacional. O contexto transacional pode ou pertencer ao nó MQInput, o que ocorre quando uma mensagem de resposta de entrada aciona a saída a partir do nó AggregateReply, ou ele pode pertencer ao próprio nó AggregateReply.

Quando o contexto de transação pertencer ao nó AggregateReply, o contexto de transação possuirá as semânticas típicas, mas o controle transacional será centrado no nó AggregateReply ao invés do nó MQInput, o que possui a implicação de que um erro produzido posteriormente no fluxo de mensagens pode causar ao nó AggregateReply que se reverta e propague uma mensagem para seu terminal de Captura, ao invés do nó MQInput. Mensagens propagadas a partir do nó AggregateReply dentro do contexto de suas próprias transações não são diretamente fornecidas a partir do nó MQInput; o nó AggregateReply é o nó de entrada para essa chamada de fluxo.

O comportamento transacional do nó AggregateReply é controlado pelo seu parâmetro de configuração Modo de Transação. Você deve se assegurar de que essa configuração e a configuração no nó MQInput sejam as mesmas, para assegurar que todas as saídas do nó AggregateReply estejam no mesmo nível do controle transacional.

As seguintes situações estão sob controle transacional do nó MQInput:

As situações a seguir estão sob o controle transacional do nó AggregateReply:

Evitando Falta de Encadeamento em Fan-in

O nó AggregateReply possui dois terminais de entrada: Entrada e Controle. Caso você use ambos esses terminais, lembrando-se que o uso do terminal de Controle é opcional, o modo mais eficiente para fornecer dados ao nó AggregateReply é ter um único nó MQInput para o fluxo fan-in seguido por um nó Filtro. O nó Filtro é usado para enviar uma mensagem que chega para os terminais de Entrada ou de Controle do nó AggregateReply conforme apropriado. Utilize essa abordagem em vez de utilizar dois nós MQInput no fluxo de mensagens: um para o terminal In e outro para o terminal Control. O fluxo fan-in deve se parecer com o seguinte diagrama:
Fluxo de Fan-in Truncado com Filtragem
O nó Filtro necessita de um módulo ESQL similar ao seguinte exemplo para assegurar que as mensagens são enviadas para o terminal apropriado do nó 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;

Você deve utilizar um único nó MQInput porque não é possível especificar como quaisquer encadeamentos adicionais (disponibilizados pelo uso de instâncias adicionais) devem ser distribuídos entre os dois nós MQInput. O tráfego no terminal In do nó AggregateReply é provavelmente maior, portanto, é mais útil ter mais encadeamentos em execução em seu nó de entrada, mas não é possível configurar este cenários. Portanto, é possível que o nó fique sem encadeamentos, fazendo backup de mensagens de resposta e parando o mecanismo de agregação.

Esta situação é aplicável apenas se o terminal Control do nó AggregateControl estiver conectado à saída em uma fila. Ao não conectar o terminal Control é possível superar estes problemas.

Se a solução anterior não puder ser implementada, é possível forçar o nó MQInput que está lendo mensagens de controle para executar o encadeamento único:

  1. No painel Avançado da configuração do nó MQInput, configure Modo de Ordem com Por Ordem de Fila.
  2. Selecione Ordem Lógica, que libera todas as instâncias adicionais configuradas para que elas possam ser utilizadas por outro nó MQInput.

Entretanto, o desempenho do primeiro nó MQInput está extremamente limitado como um resultado desta configuração.

Voltar para Home da Amostra