Como a Árvore de Mensagem É Ocupada

A árvore de mensagens é inicialmente ocupada pelo nó input do fluxo de mensagens.

Quando o nó de entrada recebe a mensagem de entrada, ele cria e completa a árvore Propriedades (a primeira subárovre da árvore de mensagens). Consulte o Estrutura em Árvore de Mensagens.

O nó então examina o conteúdo do fluxo de bits da mensagem de entrada e cria o restante da árvore de mensagens para refletir esse conteúdo. Esse processo depende, até certo ponto, do próprio nó input, que é controlado pelo transporte através do qual a mensagem é recebida:

Protocolos WebSphere MQ Enterprise Transport e WebSphere MQ Telemetry Transport
se seu aplicativo se comunicar com o intermediário através desses protocolos e seu fluxo de mensagens incluir o nó MQInput ou SCADAInput correspondente, todas as mensagens recebidas devem ser iniciadas com um cabeçalho MQMD (Message Queue Message Descriptor). Se um MQMD válido não estiver presente no início da mensagem, ela será rejeitada e não ocorrerá nenhum processamento adicional.

O nó input primeiro chama o analisador MQMD e cria a subárvore para esse cabeçalho.

Uma mensagem poderá ter zero ou mais cabeçalhos adicionais que se seguem ao MQMD. Esses cabeçalhos juntos formam uma cadeia, com o campo Formatar de um cabeçalho definindo o formato do cabeçalho seguinte, até e incluindo o último cabeçalho, que define o formato do corpo da mensagem. Se um cabeçalho MQRFH e um MQRFH2 existirem na cadeia, os dados de nome e valor em qualquer um desses dois cabeçalhos também podem conter informações sobre o formato dos dados a seguir. Se o valor especificado em Formatar for um analisador reconhecido, esse valor sempre terá precedência sobre os dados de nome e valor.

O intermediário chama o analisador apropriado para interpretar cada cabeçalho, após a cadeia na mensagem. Cada cabeçalho é analisado de forma independente. Os campos em um único cabeçalho são analisados em uma ordem, que é controlada pelo analisador. Não é possível prever a ordem escolhida, mas a ordem em que os campos são analisados não afeta a ordem em que os campos são exibidos no cabeçalho.

O intermediário assegura que a integridade dos cabeçalhos que precedem uma corpo de mensagem seja mantida. O formato de cada parte da mensagem é definido, seja pelo campo Formatar no cabeçalho imediatamente precedente (se a parte seguinte for um formato reconhecido do WebSphere MQ) ou pelos valores definidos no cabeçalho MQRFH ou MQRFH2:

  • O formato do primeiro cabeçalho é conhecido porque deve ser MQMD.
  • O formato de qualquer cabeçalho subseqüente na mensagem é definido no campo Formato no cabeçalho precedente.
  • O formato do corpo corresponde ao domínio de mensagem e ao analisador que deve ser chamado para o corpo de mensagens (por exemplo, XMLNSC). Essas informações são definidas no cabeçalho MQRFH ou MQRFH2, ou na propriedade Domínio de Mensagem do nó de entrada que recebe a mensagem.

Esse processo é repetido quantas vezes forem necessárias pelo número de cabeçalhos que precedem o corpo da mensagem. Você não precisa preencher esses campos; o intermediário identifica essa seqüência para você.

O intermediário conclui este processo para assegurar que os campos Formato nos cabeçalhos identifiquem corretamente cada parte da mensagem. Se o intermediário não concluir esse processo, o WebSphere MQ talvez não possa entregar a mensagem. O analisador do corpo da mensagem não é um formato de cabeçalho reconhecido do WebSphere MQ e por essa razão o intermediário substitui esse valor no campo Formatar do último cabeçalho pelo valor MQFMT_NONE. O valor original nesse campo é armazenado no campo Domínio no cabeçalho MQRFH ou MQRFH2 para manter as informações sobre o conteúdo do corpo da mensagem.

Por exemplo, se o cabeçalho MQRFH2 precede imediatamente o corpo da mensagem, e seu campo Formato estiver definido como XMLNSC, que indica que o corpo da mensagem deve ser analisado pelo analisador XMLNSC, o campo Domínio MQRFH2 é definido como XMLNSC, e seu campo Formato é redefinido para MQFMT_NONE.

Essas ações podem resultar em informações que são armazenadas explicitamente por uma expressão ESQL ou Java sendo substituída pelo intermediário.

Quando todos os cabeçalhos tiverem sido analisados e as subárvores correspondentes tiverem sido criadas na árvore de mensagens, o nó de entrada associará o analisador especificado ao corpo da mensagem. Especifique o analisador que será associado ao conteúdo do corpo da mensagem, em um cabeçalho na mensagem (por exemplo, a pasta <mcd> no cabeçalho MQRFH2) ou nas propriedades do nó de entrada (se a mensagem não incluir cabeçalhos. O nó de entrada faz a associação, conforme descrito na lista a seguir:

  • Se a mensagem tiver um cabeçalho MQRFH ou MQRFH2, o domínio identificado no cabeçalho (em Formatar ou nos dados de nome e valor) determinará o analisador associado a essa mensagem.

    O nó SCADAInput cria as mensagens de formato WebSphere MQ com os cabeçalhos MQRFH2 a partir das mensagens de entrada que o listener recebe na porta TCP/IP.

  • Se a mensagem não tiver um cabeçalho MQRFH ou MQRFH2 ou se o cabeçalho não identificar o domínio, a propriedade Domínio de Mensagem do nó de entrada indica o domínio da mensagem e o analisador que deve ser utilizado. Você pode especificar um domínio e um analisador definido pelo usuário.
  • Se o domínio de mensagem não puder ser identificado pelos valores de cabeçalho ou pela propriedade Domínio de Mensagem do nó de entrada, a mensagem será manipulada como um objeto binário (BLOB). O analisador BLOB está associado à mensagem. Um BLOB pode ser interpretado como uma cadeia de caracteres hexadecimais, e conseqüentemente pode ser modificado ou examinado no fluxo de mensagens, especificando a localização do subconjunto da cadeia.

Por padrão, o corpo da mensagem não é analisado de modo linear por motivos de desempenho. O corpo da mensagem poderá não precisar ser analisado durante o fluxo de mensagens. Ele só será analisado quando uma referência for feita a seu conteúdo.

Por exemplo, o corpo da mensagem é analisado quando você faz referência a um campo no corpo da mensagem, por exemplo: Root.XMLNSC.MyDoc.MyField. Dependendo dos caminhos que são percorridos no fluxo de mensagens, essa análise pode ocorrer em diferentes pontos. Essa abordagem "analisar na primeira necessidade" também é chamada de 'análise parcial' ou 'análise on demand' e, em processamento típico, não afeta a lógica de um fluxo de mensagens. Entretanto, há algumas implicações para cenários de manipulação de erros; consulte Tratando Erros em Fluxos de Mensagens.

Se você quiser que um fluxo de mensagens aceite mensagens de mais de um domínio de mensagem, inclua um cabeçalho MQRFH2 na mensagem a partir da qual o nó de entrada extrai as informações de domínio de mensagem e de definição de mensagem relacionada (conjunto de mensagens tipo de mensagem e formato de mensagem).

Se você configurar os cabeçalhos de mensagem ou as propriedades do nó de entrada para identificar um domínio e analisador definido pelo usuário, a forma como ele interpreta a mensagem e constrói a árvore lógica pode diferir daquelas descritas aqui.

Protocolos WebSphere MQ Multicast Transport, WebSphere MQ Real-time Transport, , , WebSphere MQ Web Services Transport e WebSphere Broker JMS Transport
Se o seu aplicativo se comunica com o intermediário por meio desses protocolos suportados, e seu fluxo de mensagens inclui os nós de entrada correspondentes, as mensagens que são recebidas não terão que incluir um cabeçalho específico. Se forem incluídos cabeçalhos reconhecidos, o nó input chamará os analisadores apropriados para interpretar os cabeçalhos e para construir as partes relevantes da árvore de mensagens, conforme descrito para os outros protocolos suportados.

Se não houver cabeçalhos, ou eles não especificarem o analisador para o corpo da mensagem, configure as propriedades do nó de entrada para definir o analisador do corpo da mensagem. Se você não definir as propriedades do nó dessa forma, a mensagem será tratada como um BLOB. Você pode especificar um analisador definido pelo usuário.

O analisador especificado está associado ao corpo da mensagem pelo nó de entrada (da mesma forma que que ele é para o protocolos WebSphere MQ Enterprise Transport e WebSphere MQ Telemetry Transport) e, por padrão, o corpo da mensagem não é analisado imediatamente.

Se você configurar os cabeçalhos de mensagem ou as propriedades do nó de entrada para identificar um domínio e analisador definido pelo usuário, a forma como ele interpreta a mensagem e constrói a árvore lógica pode diferir daquelas descritas aqui.

Todos os Outros Protocolos
Se desejar que seu fluxo de mensagens aceite mensagens de um protocolo de transporte para o qual o WebSphere Message Broker não fornece suporte interno ou se desejar que ele forneça algum processamento específico durante o recebimento de uma mensagem, poderá utilizar a interface de programação em linguagem Java ou C para criar um novo nó input definido pelo usuário.

Essa interface não gera automaticamente uma subárvore Propriedades para uma mensagem (essa subárvore é discutida em Estrutura em Árvore de Mensagens). Uma mensagem não precisa ter uma subárvore Propriedades, mas você poderá achar útil criar uma para fornecer uma estrutura em árvore de mensagens consistente, independentemente do nó de entrada. Se você estiver utilizando um nó de entrada definido pelo usuário, você mesmo deverá criar uma subárvore Propriedades na árvore de mensagens.

Para processar mensagens que não estão de acordo com nenhum dos domínios de mensagens definidos, utilize a interface de programação em linguagem C para criar um novo analisador definido pelo usuário.

Você deve consultar a interface do nó para entender como ele utiliza analisadores e se é possível configurá-lo para modificar seu comportamento. Se o nó utilizar um analisador definido pelo usuário, a estrutura em árvore criada para a mensagem poderá ser um pouco diferente da criada para analisadores internos. Um nó input definido pelo usuário pode analisar totalmente uma mensagem de entrada ou pode participar da análise parcial na qual o corpo da mensagem é analisado apenas quando necessário.

Você também pode criar seus próprios nós de saída e de processamento de mensagens em C ou Java.

Propriedades versus Comportamento da Pasta MQMD para Diversos Transportes

Existem diferenças na maneira como a pasta Propriedades e a pasta MQMD são tratadas em relação a qual pasta tem prioridade para os mesmos campos. Esse tratamento é caracterizado pelo tipo de transporte (por exemplo, HTTP ou WebSphere MQ) que você utiliza.

Quando o fluxo de mensagens é originado em um nó MQInput, então, você tem um MQMD para analisar. Nesse caso, a pasta Propriedades é originada dos valores MQMD e, portanto, a pasta MQMD tem prioridade em relação à pasta Propriedades em termos de propagação de valor entre as pastas. Esse cenário significa que é possível executar ESQL, por exemplo, SET OutputRoot.MQMD.CorrelId e esse comando atualiza o valor da pasta Propriedades.

Quando o fluxo de mensagens é originado em um nó de entrada diferente do nó MQInput (como o nó HTTPInput ou um nó de entrada definido pelo usuário), então, nenhum MQMD é analisado. Esse cenário significa que a pasta Propriedades não é originada a partir de um MQMD de entrada, é criada e preenchida com valores de transporte vindos de cabeçalhos específicos de transportes. Ao criar uma pasta MQMD em um fluxo de mensagens que não foi originado no transporte do WebSphere MQ, o cabeçalho MQMD não tem prioridade em relação à pasta Propriedades, pois o transporte do WebSphere MQ não preencheu a pasta Propriedades. Portanto, nesse caso, a pasta Propriedades substitui quaisquer valores em MQMD.

A pasta Propriedades é construída e representa uma mensagem recebida no transporte. Nesse cenário, dois transportes inteiramente diferentes estão sendo utilizados, tendo diferentes significados e, portanto, diferentes requisitos da pasta Propriedades. Quando originados de um nó HTTPInput, os cabeçalhos HTTP têm controle sobre a pasta Propriedades para campos semelhantes. Quando originado de um nó MQInput, o MQMD tem controle sobre a pasta Propriedades para campos semelhantes.

Portanto, segue isso quando você inclui uma pasta MQMD em uma árvore que foi criada pelo Transporte HTTP, então, essa pasta MQMD não tem controle sobre a pasta Propriedades e a direção da propagação de valores não é MQMD para Propriedades, é Propriedades para MQMD. A abordagem correta aqui é configurar o campo replyIdentifier das pastas Propriedades e utilizar isso para preencher o MQMD:
 SET OutputRoot.Properties.ReplyIdentifier = X' ..... '; 
O comportamento não é exclusivo somente dos campos CorrelId a ReplyIdentifier. Aplica-se a todos os campos semelhantes entre MQMD e a pasta Propriedades:
  • CorrelId
  • Encoding
  • CodedCharSetId
  • Persistence
  • Expiry
  • Priority
Em resumo:
  1. Quando o fluxo de mensagens é originado em um nó MQInput, então, o MQMD tem prioridade em relação à pasta Propriedades em termos de propagação de valor entre as pastas.
  2. Quando seu fluxo de mensagens é originado em um nó de entrada que não é o nó MQInput (como o nó HTTPInput ou um nó de entrada definido pelo usuário), o cabeçalho MQMD não tem prioridade em relação à pasta Propriedades.
  3. Quando uma pasta MQMD é incluída em uma árvore que foi criada pelo Transporte HTTP, então, esse MQMD não tem controle sobre a pasta Propriedades e a direção de propagação de valores não é MQMD para Propriedades, é Propriedades para MQMD.

Exemplo

SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD.Version = 2;
SET OutputRoot.MQMD.CorrelId = X'4d454e53414a453320202020202020202020202020202020';
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Persistence = 1;
SET OutputRoot.MQMD.Expiry = 10000;
SET OutputRoot.MQMD.Priority = 9;
SET OutputRoot.BLOB.BLOB = X'01';
Quando originado de um nó HTTPInput, nenhuma dessas alterações terão efeito e a saída MQMD do nó Compute é:
(0x01000000):MQMD       = (
    (0x03000000):Version        = 2
    (0x03000000):CorrelId       = X'000000000000000000000000000000000000000000000000'
    (0x03000000):Encoding       = 546
    (0x03000000):CodedCharSetId = 1208
    (0x03000000):Persistence    = FALSE
    (0x03000000):Expiry         = -1
    (0x03000000):Priority       = 0
Conceitos relacionados
Estrutura de Árvore Lógica
Estrutura em Árvore de Mensagens
Estrutura em Árvore Environment
Estrutura em árvore do ambiente local
Estrutura em Árvore da Lista de Exceções
Nomes de Correlação
Tarefas relacionadas
Tratando Erros em Fluxos de Mensagens
Desenvolvendo Fluxos de Mensagens
Referências relacionadas
Nós Internos
Nós Definidos pelos Usuários
Cabeçalho do MQRFH2
Analisando On Demand
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:50

ac18520_