Um nó do fluxo de mensagens é uma etapa de processamento em um fluxo de mensagens.
Ele recebe uma mensagem, executa um conjunto de ações na mensagem e, opcionalmente, transmite a mensagem para o próximo nó no fluxo de mensagens. Um nó do fluxo de mensagens pode ser um nó interno , um nó definido pelo usuário, ou um nó de subfluxo.
Um nó do fluxo de mensagens contém um número fixo de pontos de entrada e saída conhecidos como terminais. Você pode estabelecer conexões entre os terminais para definir as rotas que uma mensagem poderá percorrer em um fluxo de mensagens.
Para obter informações sobre todos os nós internos fornecidos pelo WebSphere Message Broker, consulte Nós Internos.
Uma mensagem é recebida por um nó Input e processada de acordo com a definição do subfluxo. Isso pode incluir o armazenamento através de um nó Warehouse ou entrega em outro destino de mensagem, por exemplo, através de um nó MQOutput. Se necessário, a mensagem pode retornar através de um nó Output ao fluxo principal para processamento adicional.
O subfluxo, quando incorporado em um fluxo principal, é representado por um nó do subfluxo, que possui um ícone exclusivo. O ícone é exibido com o número correto de terminais para representar os nós Input e Output que foram incluídos na definição do subfluxo.
A utilização mais comum de um subfluxo é fornecer processamento requerido em muitos locais em um fluxo de mensagens ou é ser compartilhado entre vários fluxos de mensagens. Por exemplo, você pode codificar algum processamento de erros em um subfluxo ou criar um subfluxo para fornecer uma trilha de auditoria (armazenando toda a mensagem e gravando uma entrada de rastreio).
A utilização de subfluxos é demonstrada no Amostra Error Handler e no Amostra Coordinated Request Reply . A amostra Error Handler utiliza um subfluxo para captar informações sobre erros e armazenar as informações em um banco de dados. A amostra Coordinated Request Reply utiliza um subfluxo para encapsular o armazenamento dos valores ReplyToQ e ReplyToQMgr em uma mensagem do WebSphere MQ de forma que a lógica de processamento possa ser reutilizada em outros fluxos de mensagens para permitir que implementações alternativas sejam substituídas.
Um nó nem sempre produz uma mensagem de saída para cada terminal de saída: geralmente ele produz uma saída para um terminal único, dependendo da mensagem recebida ou do resultado da operação do nó. Por exemplo, um nó Filter geralmente envia uma mensagem no terminal verdadeiro ou no terminal falso, mas não em ambos.
Se mais de um terminal estiver conectado, o nó enviará a mensagem de saída em cada terminal, mas enviará somente no terminal seguinte, quando o processamento tiver sido concluído para o terminal atual. Atualizações de uma mensagem nunca são propagadas para nós executados anteriormente, apenas para aqueles que seguem os nós nos quais a atualização foi feita. A ordem de propagação da mensagem para terminais de saída diferentes é determinada pelo intermediário e não pode ser alterada. A única exceção à esta regra é o nó FlowOrder, no qual os terminais indicam a ordem na qual a mensagem é propagada para cada uma.
O fluxo de mensagens pode aceitar apenas uma nova mensagem para processamento quando todos os caminhos pelo fluxo de mensagens (ou seja, todos os nós conectados de todos os terminais de saída) tiverem sido concluídos.
A Amostra Airline Reservations utiliza variáveis de ambiente na amostra XML_Reservation para armazenar informações que foram obtidas em uma tabela de banco de dados e transmitir essas informações para um nó de recebimento de dados no fluxo de mensagens.