WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Como a Árvore de Mensagem É Preenchida

A árvore de mensagens é inicialmente preenchida 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árvore 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:

Protocolo WebSphere MQ Enterprise Transport
Se seu aplicativo se comunicar com o broker nesses protocolos e seu fluxo de mensagens incluir o nó MQInput correspondente, todas as mensagens recebidas deverão ser iniciadas com um cabeçalho Message Queue Message Descriptor (MQMD). 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 Formato 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 Formato for um analisador reconhecido, esse valor sempre terá precedência sobre os dados de nome e valor.

O broker 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 cabeçalho único são analisados em uma ordem que é governada pelo analisador. Não é possível predizer a ordem que é escolhida, mas a ordem na qual os campos são analisados não afeta a ordem na qual os campos são exibidos no cabeçalho.

O broker 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 Formato 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 subsequente 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 broker identifica essa sequência para você.

O broker conclui esse processo para assegurar que os campos Formato nos cabeçalhos identifiquem corretamente cada parte da mensagem. Se o broker 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 pelo WebSphere MQ e por essa razão o broker substitui esse valor no campo Formato dos últimos cabeçalhos pelo valor MQFMT_NONE. O valor original desse campo é armazenado no campo Domínio no cabeçalho MQRFH ou MQRFH2 para reter as informações sobre o conteúdo do corpo da mensagem.

Por exemplo, se o cabeçalho MQRFH2 preceder 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 de MQRFH2 será definido como XMLNSC, e seu campo Formato será reconfigurado 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.

Os campos CodedCharSetId e Encoding não são preenchidos da mesma maneira que o campo Formato. Particularmente, o corpo da mensagem é usado para determinar os valores CodedCharSetId e Encoding. Esses valores afetam a forma na qual o corpo da mensagem é gravado. Isso poderá causar resultados inesperados se um cabeçalho intermediário (por exemplo, MQRFH2) for removido sem atualizar o cabeçalho precedente na cadeia com os valores de cabeçalho removidos.

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 específico com o corpo da mensagem. Especifique o analisador que deve ser associado com o 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 Formato ou nos dados de nome e valor) determinará o analisador associado a essa mensagem.
  • 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. Esta abordagem "analisar quando necessário primeiro" também é referida como "análise parcial" ou "análise on-demand" e, no 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 Broker File Transport, WebSphere Broker Adapters Transport, WebSphere MQ Web Services Transport e WebSphere Broker JMS Transport
Se o seu aplicativo se comunica com o broker 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 é associado ao corpo da mensagem pelo nó de entrada (da mesma forma que é para o protocolo WebSphere MQ Enterprise 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 você quiser que o fluxo de mensagens aceite mensagens de um protocolo de transporte para o qual o WebSphere Message Broker não fornece suporte interno ou quiser que ele forneça um processamento específico no recebimento de uma mensagem, use a interface de programação em linguagem Java ou C para criar um novo nó de entrada 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 usando um nó de entrada definido pelo usuário, você deverá criar, você mesmo, 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 ou de processamento de mensagem 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ê usa.

Quando o fluxo de mensagens é originado por um nó MQInput, você possui um MQMD para analisar. Neste caso, a pasta Propriedades é originada pelos valores de MQMD e, portanto, a pasta MQMD tem precedência sobre a 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 de um nó de entrada que não é o nó MQInput (tal como o nó HTTPInput ou um nó de entrada definido pelo usuário), nenhum MQMD é analisado. Neste cenário, a pasta Propriedades não é originada de um MQMD de entrada; ela é criada e preenchida com valores de transporte fornecidos a partir de outros cabeçalhos específicos de transporte. 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 precedência sobre a 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, quando você inclui uma pasta MQMD em uma árvore que foi criada pelo Transporte HTTP, esta pasta MQMD não possui controle sobre a pasta Propriedades e a direção da propagação do valor não é de MQMD para Propriedades, é de Propriedades para MQMD. A abordagem correta é configurar o campo replyIdentifier da pasta Propriedades e usá-lo para preencher o MQMD:
 SET OutputRoot.Properties.ReplyIdentifier = X' ..... '; 
O comportamento não é exclusivo apenas aos campos de CorrelId a ReplyIdentifier. Aplica-se a todos os campos semelhantes entre MQMD e a pasta Propriedades:
  • CorrelId
  • Encoding
  • CodedCharSetId
  • Persistence
  • Expiração
  • Priority
Em resumo:
  1. Quando seu fluxo de mensagens é originado por um nó MQInput, o MQMD tem precedência sobre a pasta Propriedades nos termos da 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, esse MQMD não possui controle sobre a pasta Propriedades e a direção da propagação de valor não é de MQMD para Propriedades; é de 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 mudanças terá efeito e a saída MQMD do nó Compute será:
(0x01000000):MQMD       = (
    (0x03000000):Version        = 2
    (0x03000000):CorrelId       = X'000000000000000000000000000000000000000000000000'
    (0x03000000):Encoding       = 546
    (0x03000000):CodedCharSetId = 1208
    (0x03000000):Persistence    = FALSE
    (0x03000000):Expiry         = -1
    (0x03000000):Priority       = 0
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:25


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac18520_