O WebSphere MQ é o backbone universal de sistema de mensagens líder de mercado. Ele é usado para descomplicar a complexidade de TI através da integração e conectividade ponto a ponto. Aumenta a agilidade de negócios e reduz os custos de integração e manutenção de TI. Neste artigo estaremos apresentando quais são as melhores práticas de uso do WMQ.

PAULO AUGUSTO HUGGLER DA SILVA, Especialista Técnico WebSphere em Conectividade e Ferramentas de Determinação de Problemas.

Experiência em Infraestrutura e integração de aplicações, desenvolvimento de software e gerência de projetos. Atuação há 37 anos em Informática, com foco na plataforma mainframe, nas áreas de desenvolvimento de software, direcionamento estratégico em soluções de integração de aplicações. Formação universitária em Matemática e em Engenharia Civil. Certified IT Specialist pela IBM



MARCELO GIANINI NOVAES, Especialista Técnico WebSphere em Soluções de BPM, Conectividade e Infraestrutura de Aplicações., IBM

Experiência em Infraestrutura e integração de aplicações, modelagem de processos e desenvolvimento de software. Atuação há 23 anos direta junto à empresas, envolvendo-se diretamente no direcionamento estratégico e metas corporativas, através da utilização de técnicas como BPM, SOA, ESB e JEE. Experiência acadêmica em cursos de pós-graduação nas disciplinas ligada a Análise e Design de Serviços e BPM. Coordenei curso de pós-graduação em Arquitetura de J2EE e Objetos Distribuídos e suporte no Curso de Engenharia de Software SOA. Sou Formado em Engenharia e com pós-graduação em Projeto de Aplicações Orientadas a Objetos com Ênfase em Java, e MBA Executivo de Negócios.
Membro do Technology Leadership Council da IBM Brasil
Membro do Technology Leadership Council Worldwide da IBM
Master Certified IT Specialist do Open Group



02/Nov/2012

AbreviaçõesDescrição
BD Database
WMQ WebSphere MQ
MQ WebSphere MQ
DB2 IBM DB2 Database Relacional
APPC Advanced Program to Program Communications
CPI-C Common Programming Interface - Communications
TCP/IP. Transmission Control Protocol / Internet Protocol
SNA Systems Network Architecture
RPC Remote Procedure Call
API Application Programming Interface
MQI Message Queue Interface
JMS Java Message Services
LU6.2 Logical Unit type 6.2
NetBIOS Network Basic Input/Output System
MCAs Message Channel Agents
SPX/IPX Internetwork Packet Exchange/Sequenced Packet
FIFO First In First Out
SSL Secure Sockets Layer
Infocenter Site dos manuais dos produtos
HTTP Hypertext Transfer Protocol
CICS Customer Information Control System
XA O termo XA, em ciência da computação, é uma referência ao padrão para processamento de transação distribuída especificado pelo consórcio X/Open.
2PC Two Phase Commit
SupportPacs São materiais para ser usado por especialistas técnicos, por exemplo, trabalhos de ajuste de migração de aplicações, gerenciamento de sistemas e desempenho.

1. Introdução

O IBM WebSphere MQ (também chamado de MQ) é um middleware da IBM orientado a mensagem. Ele permite que aplicações independentes e potencialmente não concorrentes, rodando em sistemos heterogêneos, se comuniquem entre si. É suportado em mais de 20 plataformas de ambientes diferentes.

Um dos pontos fortes do MQ é sua capacidade de ser altamente configurável e customizável para ambientes distintos e para as diferentes necessidades de transmissão de dados. No entanto, esta característica pode facilitar a existência de sistemas mal configurados que podem não suportar uma futura expansão, mudanças nos padrões de desenvolvimento e protocolos, ou então uma segurança mais robusta. As discussões a seguir descrevem as melhores práticas mais comuns na concepção, construção, execução e manutenção de soluções MQ, a fim de alcançar os melhores benefícios do produto.

É preciso ter em mente que nem todas as recomendações são apropriadas para todas as situações, e que elas são oferecidas apenas como diretrizes não como regras. Grandes instalações podem, muitas vezes, ter boas razões para se desviar de algumas das recomendações.


2. Conceitos Gerais

2.1 Três estilos de comunicação

Figura 1. Três estilos de comunicação – Curso WM100 / VM1001.0

A comunicação Conversacional ou orientada a transação é caracterizada por dois ou mais programas em execução simultânea de forma cooperativa, a fim de executar uma transação. Eles se comunicam entre si através de uma interface conhecida. Enquanto um programa espera por uma resposta do outro programa com o qual ele está cooperando, pode continuar com outros processamentos. São exemplos deste estilo de comunicação APPC, CPI-C, e a interface sockets TCP/IP.

O estilo de Chamada e Retorno é semelhante, mas quando um programa chama outro programa, o primeiro fica bloqueado e não pode executar qualquer outro processamento até que o segundo programa retorne o controle a ele. Remote Procedure Call (RPC) é um exemplo deste estilo de comunicação.

No estilo Mensageria, os programas que se comunicam podem ser executados de forma independente uns dos outros. Um programa recebe a entrada na forma de mensagens e também produz os seus resultados como mensagens. Uma mensagem, que é a saída de um programa, torna-se a entrada para outro programa, mas não há qualquer exigência de que este último deva estar sendo executado quando o primeiro gera a mensagem. Este modelo contrasta com o Conversacional e o Chamada e Retorno, onde todos os parceiros em cooperação devem estar sendo executados ao mesmo tempo. O MQ usa esse estilo de processamento.

2.2 Comunicações Programa-Programa

Figura 2. Comunicação Programa com Programa – Curso WM100 / VM1001.0

O WebSphere MQ é um meio na comunicação entre programas.

A Figura 2 ilustra o mecanismo básico pelo qual esta comunicação se realiza. O programa A prepara uma mensagem e a coloca em uma fila. O Programa B, em seguida, lê a mensagem da fila e a processa.

Tanto o Programa A como o Programa B usam uma interface de programação de aplicativo (API) para colocar as mensagens em uma fila e para ler as mensagens de uma fila. A API do MQ é chamada de Message Queue Interface (MQI).

É importante notar que quando o Programa A coloca uma mensagem na fila, o Programa B pode não estar sendo executado. A fila armazena a mensagem com segurança até que o Programa B seja iniciado e esteja pronto para receber a mensagem. Da mesma forma, no momento em que Programa B lê a mensagem da fila, o Programa A pode não estar mais sendo executado. Usando o MQ, não é necessário que programas que se comunicam entre si estejam sendo executados ao mesmo tempo.

O MQ provê várias funções que são obrigatórias para o transporte de mensagem com sucesso:

  • Entrega Garantida
  • Entrega uma única vez
  • Entrega assíncrona

2.3 Modelo de desenho de aplicações Síncronas

Figura 3. Modelo de desenho de aplicações sincronas – Curso WM100 / VM1001.0

A Figura 3 mostra como o Programa B pode enviar uma mensagem para o Programa A usando o mesmo mecanismo. A mensagem pode ser uma resposta a uma mensagem que o Programa B recebeu do Programa A. Normalmente, o Programa B usa uma fila diferente para enviar mensagens para o Programa A. Usar uma fila separada não é estritamente necessário, mas isso leva a um desenho de aplicação mais simples e a uma lógica de programação também mais simples.

Se o Programa A envia uma mensagem para o Programa B e espera uma resposta, uma opção é o Programa A colocar uma mensagem na Fila (Queue) 1 e aguardar até que a resposta apareça na Fila 2. Esta forma é chamada de modelo síncrono para uma comunicação bidirecional entre programas.

Utilizando o modelo síncrono, o Programa A e o Programa B estariam normalmente sendo executados ao mesmo tempo. No entanto, se o programa B falhar, o Programa A pode ter que esperar muito tempo por uma resposta. Quanto tempo o Programa A deve esperar antes de continuar com o processamento é um item de desenho das aplicações.

2.4 Modelo ampliado de projeto de aplicações assíncrono

Figura 4. Modelo ampliado de projeto de aplicações assincronas – Curso WM100 / VM1001.0

Na Figura 4 usando o modelo assíncrono ampliado, o Programa A coloca mensagens na Fila 1 para o Programa B processar, mas é o Programa C, atuando de forma assíncrona em relação ao Programa A, que recebe as respostas de Fila 2 e as processa. Tipicamente, o Programa A e Programa C seriam parte da mesma aplicação.

O modelo assíncrono é um modelo natural para MQ. O Programa A pode continuar a colocar mensagens na Fila 1 e não é bloqueado por ter que esperar por uma resposta para cada mensagem. Ele pode continuar a colocar mensagens na Fila 1, mesmo se o Programa B falhar. Nesse caso, a Fila 1 guarda as mensagens de forma segura até que o Programa B seja reiniciado.

Em uma variação do modelo assíncrono, o Programa A poderia colocar uma sequência de mensagens na Fila 1, opcionalmente continuar com outro processamento, e depois retornar para ler e processar as respostas da Fila 2.

2.5 O gerenciador de filas

O componente do WebSphere MQ que gerencia as filas é chamado de Gerenciador de Filas (Queue Manager). Ele também provê uma interface para interagir com os programas, chamada de Message Queue Interface (MQI). Essa interface efetivamente protege as aplicações de ter de entender como o gerenciador de filas manipula mensagens e filas.

Além de filas, há outros objetos gerenciados pelo Gerenciador de Filas MQ, tais como processos. Cada objeto MQ tem um conjunto de atributos. Cada atributo tem um nome e um valor associado a ele. A definição de um objeto MQ especifica os valores de seus atributos.

O MQ tem duas interfaces adicionais de programação: interface JAVA para uso em aplicações JAVA, e Java Message Services (JMS) que permite aos programadores escrever aplicações de mensageria baseadas em eventos.

2.6 A comunicação entre gerenciadores de filas

Figura 5. Comunicação entre gerenciadores de filas – Curso WM100 / VM1001.0

Na Figura 5 o estilo conversacional de comunicação programa-programa depende de uma conexão de comunicação existente através de uma rede para cada par de aplicações. Na realidade, uma conexão desse tipo se manifesta como uma ligação TCP, conversação SNA LU6.2 (system network architecture logical unit), uma sessão NetBIOS, e assim por diante.

No MQ, um aplicativo envia uma mensagem para outro aplicativo usando as funções do Message Queue Interface (MQI), disponibilizadas pelo gerenciador de filas ao qual o aplicativo está conectado. No caso da aplicação destino estar conectada a outro gerenciador de fila, a conexão requerida é entre um par de Message Channel Agents (MCAs), dispositivos de comunicação entre gerenciadores de filas, cada ligado ao seu gerenciador de fila respectiva, não entre um par de aplicações.

É importante notar como o Message Queue Interface (MQI) protege as aplicações e seus desenvolvedores das complexidades da rede. Os Message Channel Agents fornecidos pelo MQ contêm toda a programação necessária para as comunicações.

2.7 Conceito de filas locais e remotas

Figura 6. Conceito de filas locais e remotas – Curso WM100 / VM1001.0

Na Figura 6 quando um aplicativo abre uma fila, o gerenciador de filas determina se a fila de destino final pertence ao próprio gerenciador de filas ao qual o aplicativo está conectado (fila local), ou se pertence a outro gerenciador de filas (fila remota).

Quando o aplicativo, em seguida, grava uma mensagem em uma fila local, o gerenciador de filas coloca a mensagem diretamente nessa fila. No entanto, se a fila é remota, o gerenciador de filas coloca a mensagem em uma fila local especial chamada fila de transmissão.

É então tarefa dos Message Channel Agents (MCAs), componentes do MQ, ler a mensagem da fila de transmissão e enviá-la através da rede para um Message Channel Agent no destino da mensagem. O MCA receptor coloca a mensagem na fila de destino. Uma vez que a mensagem foi seguramente gravada na fila de destino, ela é removida da fila de transmissão.

Se o MCA receptor não puder colocar a mensagem na fila de destino por alguma razão, a mensagem será colocada na fila Dead Letter associada a aquele gerenciador de filas, ou a mensagem será descartada, dependendo das opções especificadas pela aplicação de envio no descritor da mensagem.

2.8 Chamadas MQI

Figura 7. Chamadas MQI – Curso WM100 / VM1001.0

  • Principais chamadas: MQCONN – MQCONNX – MQDISC – MQOPEN – MQCLOSE – MQPUT – MQPUT1 – MQGET – MQSUB – MQSUBRQ
  • Outras chamadas: MQBEGIN – MQCMIT – MQBACK – MQINQ – MQSET

Na Figura 7 o componente do MQ que faz a gerência das filas é chamado de gerenciador de filas (queue manager). Um gerenciador de filas também provê o Message Queue Interface (MQI) para permitir que um aplicativo possa acessar suas filas e as mensagens que elas contêm.

Um aplicativo deve primeiro se conectar a um gerenciador de filas antes de poder acessar qualquer um dos seus recursos. Para isso, ele emite uma chamada MQCONN ou MQCONNX. Quando o aplicativo não mais precisa estar conectado ao gerenciador de filas, ele emite uma chamada MQDISC.

Para acessar uma fila, um aplicativo deve primeiro emitir uma chamada MQOPEN. Quando ele não mais requer o acesso à fila, o aplicativo emite uma chamada MQCLOSE.

Uma vez que a fila é aberta, o aplicativo usa uma chamada MQPUT para colocar uma mensagem na fila, e uma chamada MQGET para ler uma mensagem da fila. Um MQPUT com uma String Topic também é utilizado para publicar informações que podem ser distribuídas para os assinantes da informação publicada. A chamada MQCLOSE encerra o acesso à fila.

A chamada MQPUT1 permite a um aplicativo abrir uma fila, colocar uma mensagem, e fechar a fila, tudo em uma única chamada.

A chamada MQPUT1, MQCMIT e MQBACK habilita um aplicativo a colocar e ler mensagens como parte de uma unidade de trabalho.

Uma fila é um exemplo de um objeto do MQ. No entanto, existem outros tipos de objetos do MQ, como uma definição de processo, uma lista de nomes e objetos do gerenciador de filas.

A partir do MQ V7, o MQPUT, usado com tópicos ou strings de tópicos, permite a publicação de informações. O MQ permite a subscrição da informação publicada através das chamadas MQSUB e MQSUBR.

Todos os objetos do MQ têm um conjunto de atributos que descrevem o objeto. Cada atributo tem um nome e um valor. A definição de um objeto do MQ especifica os valores de seus atributos. Cada objeto MQ também tem um nome, que é considerado um dos seus atributos. Um aplicativo pode usar uma chamada MQINQ para consultar os valores dos atributos de um objeto. Ele pode usar uma chamada MQSET para definir os valores de alguns atributos de uma fila.

2.8.1 Modelo de Programação - MQI

  • Conjunto muito pequeno de verbos API
  • Chamadas procedurais para C, C++, COBOL
  • Chamadas OO para Java, VB, C++,. NET
  • Um paradigma de programação muito simples, fácil de aprender e usar.

2.8.2 Protocolos e Linguagens

  • TCP/IP, SNA, NetBios, SPX/IPX
  • Java, C, C++, COBOL, PL/1, RPG, Visual Basic, .NET

2.8.3 Detalhes dos Principais Verbos da API

1) Constantes

O MQ provê uma série de valores (constantes) a serem usados em parâmetros das chamadas da MQI, para facilitar os trabalhos dos desenvolvedores. Esses valores encontram-se definidos em elementos que podem ser incluídos nos programas, como o COPY para a linguagem Cobol, ligados a nomes mnemônicos. Dessa forma, o desenvolvedor não precisa saber os valores, mas pode usá-los através dos nomes de variáveis definidas nesses elementos.

Como exemplo, para programas em Cobol, existe o elemento CMQV que pode ser definido no programa através do comando COPY, provendo a definição das constantes como campos do programa com os seus respectivos valores.

A descrição das estruturas pré-definidas para programas com MQ, bem como dos valores, pode ser encontrada no Infocenter no produto, no seguinte endereço:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Ffccontop.htm

2) Códigos de Retorno (Return Codes)

Para cada chamada do MQ Interface (MQI) e MQ Administration Interface (MQAI), o gerenciador de filas ou uma rotina de saída (exit) retornam um código de conclusão e um código de razão, para indicar o sucesso ou o insucesso da chamada.

Os aplicativos, para a sequência de processamento posterior ao tratamento de erros, não devem depender da ordem em que os erros são verificados, exceto quando especificamente recomendado. Se mais de um valor para código de conclusão ou código de razão podem ocorrer a partir de uma chamada, o erro reportado pelo programa depende de como foi feita a implementação da rotina de tratamento de erros.

As aplicações, ao verificarem a execução bem sucedida de uma chamada da MQ API, devem sempre verificar também o código de conclusão. Não se deve assumir o valor do código de conclusão, com base no valor do código de razão.

a) Código de Conclusão (Completion codes)

O parâmetro código de conclusão (CompCode) permite ao programador ver, rapidamente, se a chamada foi concluída com êxito, concluída parcialmente, ou falhou. São os seguintes os códigos de conclusão:

MQCC_OK - A chamada foi completada com sucesso, todos os parâmetros de retorno do MQ foram preenchidos. O código de razão tem sempre o valor MQRC_NONE neste caso.

MQCC_WARNING - A chamada foi completada parcialmente. Alguns parâmetros de retorno do MQ podem ter sido preenchidos, além do código de conclusão e código de razão. O código de razão dá informações adicionais sobre a causa da conclusão parcial.

MQCC_FAILED - O processamento da chamada não foi concluída. O estado do gerenciador de filas é inalterado, exceto quando especificamente indicado. Os parâmetros código de conclusão e código de razão são preenchidos; outros parâmetros permanecem inalterados, exceto onde indicado.

A razão pode ser uma falha no programa de aplicação, ou pode ser o resultado de uma situação externa ao programa, por exemplo, a autoridade do usuário poderia ter sido revogada. O código de razão fornece informações adicionais sobre o erro.

b) Código de Razão (Reason codes)

O parâmetro código de razão (Reason) qualifica o parâmetro código de conclusão (CompCode).

O valor MQRC_NONE é retornado neste parâmetro se não há nenhum motivo especial para ser informado. Uma chamada bem-sucedida retorna MQCC_OK e MQRC_NONE.

Se o código de conclusão é MQCC_WARNING ou MQCC_FAILED, o gerenciador de filas sempre informa uma razão de qualificação; detalhes são apresentados em cada descrição de chamadas.

As rotinas de saída de usuário (exits) que definirem códigos de conclusão e de razão deve aderir a estas regras. Além disso, sugere-se que valores especiais para retornos da exit sejam menores que zero, para garantir que eles não entrem em conflito com os valores definidos pelo gerenciador de filas. As exits podem também definir códigos de razão já definidas pelo gerenciador de filas, quando for apropriado.

Os códigos de razão também ocorrem em:

  • Campo Reason da estrutura MQDLH
  • Campo Feedback da estrutura MQMD

3) Comandos da interface MQI

  • MQCONN – Conecta um programa ao gerenciador de filas

    MQCONN(Qmname, Hconn, CompCode, Reason)

    - Qmname = nome do gerenciador de filas ao qual se quer conectar
    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - CmpCode = código conclusão: OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode: NONE ou descrição da razão
  • MQOPEN – Abre a fila (seja para entrada ou saída)

    MQOPEN(Hconn, ObjDesc, Options, Hobj, CompCode, Reason)

    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - ObjDesc = descrição do objeto: descreve os atributos, recebe feedback
    - Options = opções que controlam a ação de abertura da fila
    - Hobj = identificador da fila retornado pela chamada MQOPEN
    - CompCode = código de conclusão: OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode: NONE ou descrição da razão
  • MQPUT – Grava mensagem em uma fila

    MQPUT(Hconn, Hobj, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)

    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - Hobj = identificador da fila retornado pela chamada MQOPEN
    - MsgDesc = descritor de Mensagem: descreve os atributos, recebe feedback
    - PutMsgOpts = opções que controlam a ação de gravação da mensagem
    - BufferLength = comprimento da mensagem
    - Buffer = dados da mensagem
    - CompCode = código conclusão; OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode; NONE ou descrição da razão
  • MQGET – Lê mensagem de uma fila

    MQGET(Hconn, Hobj, MsgDesc, GetMsgOpts, BufferLength, Buffer, DataLength, CompCode, Reason)

    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - Hobj = identificador da fila retornado pela chamada MQOPEN
    - MsgDesc = descritor de Mensagem: descreve os atributos, recebe feedback
    - GetMsgOpts = opções que controlam a ação de leitura da mensagem
    - BufferLength = comprimento da mensagem
    - Buffer = dados da mensagem
    - CompCode = código conclusão; OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode; NONE ou descrição da razão
  • MQCLOSE – Fecha uma fila

    MQCLOSE(Hconn, Hobj, Options, CompCode, Reason)

    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - Hobj = identificador da fila retornado pela chamada MQOPEN
    - Options = opções que controlam a ação de fechamento da fila
    - CompCode = código conclusão; OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode; NONE ou descrição da razão
  • MQDISC – Desconecta o programa do gerenciador de filas

    MQDISC(Hconn, Hobj, CompCode, Reason)

    - Hconn = identificador do gerenciador de filas retornado pelo MQCONN
    - CompCode = código conclusão: OK, WARNING, ou FAILED
    - Reason = razão que descreve o código CompCode; NONE ou descrição da razão

2.9 Transações

O MQ também pode participar do processamento de transações. Mensagens que são lidas de uma fila, processadas e, em seguida, gravadas em uma ou mais filas, podem ser processadas ​​sob controle transacional. Isto significa que se algo der errado durante o processamento destas mensagens, será como se elas não tivessem sido lidas ou gravadas.

Assim, os dados movidos através de mensagens podem ser manipulados de forma segura com integridade completa de dados. Além disso, o gerenciamento das filas do MQ também é totalmente compatível com protocolo XA, que significa que aplicativos que realizam atividades com banco de dados, bem como atividades com mensagens, podem ter ambas as atividades incluídas na mesma unidade transacional. Em resumo:

  • Mensageria pode ser realizada sob controle de transações
  • Mensagem pode ser processada em uma unidade lógica de trabalho
  • As mensagens podem ser confirmadas ou revertidas como uma unidade atômica
  • Transações distribuídas são suportadas
  • MQ pode ser gerenciador de recursos XA
  • MQ pode ser gerenciador de transações XA

2.10 Formato da mensagem MQ

Uma mensagem MQ consiste de duas partes: informações de controle e dados de aplicação. A parte com os dados de aplicação, também chamada de corpo da mensagem, são providos pela aplicação que gerou a mensagem, e o MQ nunca interfere no seu conteúdo, desde a gravação da mensagem em uma fila até a entrega da mensagem na fila destino. A parte com as informações de controle, também chamada de cabeçalho, são providas pelo MQ bem como pelo programa que gerou a mensagem. É possível ao programa gerar ou alterar o conteúdo de alguns campos do cabeçalho das mensagens.

Em diferentes versões do MQ, o cabeçalho e o corpo podem variar em seu conteúdo. No entanto, desde a primeira versão do MQ, o formato da mensagem foi pouco alterado. A partir do MQ Versão 7, o formato da mensagem mudou significativamente para aumentar a compatibilidade com o Java Message Service (JMS).

Formato da mensagem no MQ Versão 6

Os dois componentes de mensagens do MQ V6 são os seguintes, conforme ilustrado na figura abaixo:

  • Descritor de mensagem (cabeçalho da mensagem)
  • Dados de Aplicação (corpo da mensagem)

Figura 8. Formato da mensagem MQ

Na Figura 8 um descritor de mensagem é associado a cada mensagem que reside em uma fila dentro de um gerenciador de filas. Ele identifica a mensagem e contém informações de controle, tais como o tipo de mensagem e a sua prioridade, conforme atribuídos pelo programa de envio.

O MQ não aplica quaisquer restrições sobre o conteúdo dos dados de aplicação, exceto um comprimento máximo, que varia de 4 até 100 MB, dependendo da versão do MQ. O comprimento máximo da mensagem também pode ser definido pelo gerenciador de filas, um canal, ou uma fila individual.

Mensagem de diferentes versões tem a mesma estrutura e composição, exceto nesses casos:

  • Os atributos do descritor da mensagem alterada a partir do MQ V5 - veja os detalhes abaixo.
  • Os tipos de cabeçalhos adicionais prefixados para os dados da mensagem foram enriquecidos. Por exemplo, a adição de extensão no descritor de mensagem (MQMDE) começando na V5, e no cabeçalho PCF (MQEPH) começaram na V6.

1. Descritor de mensagem

O descritor de mensagem é definido por uma estrutura MQMD que contém um número de campos que fornecem informação sobre a mensagem.

  • Versão

Há duas versões do descritor de mensagem. A partir do MQ versão 5, as mensagens podem ser segmentadas ou agrupadas. Para esta nova função, campos adicionais no descritor da mensagem foram necessários para manter as informações para a segmentação e agrupamento. Esta estrutura é chamada versão V2, que é a versão atual do descritor de mensagem. O descritor de mensagem V2 é o mesmo V1, mas tem campos adicionais definidos por uma estrutura MQMDE: GroupId, MsgSeqNumber, Offset, MsgFlags, e OriginalLength.

Outros gerenciadores de filas que não suportam essas funções (chamados gerenciadores de filas V1) tratam as informações adicionais como dados. Um descritor de mensagem V2 é geralmente equivalente a usar um descritor de mensagem V1 e prefixar os dados da mensagem com uma estrutura MQMDE. Os gerenciadores de filas que suportam segmentação e agrupamento de mensagens são referidos como os gerenciadores de filas V2. Veja a Figura 9 abaixo:

Figura 9. Formato da mensagem MQ comparação de versões

  • Formato

Formato é um nome que o remetente da mensagem usa para indicar ao receptor sobre a natureza dos dados de uma mensagem. O gerenciador de filas tem uma série de formatos pré-definidos com nomes começando com MQ, como MQFMT_STRING. O formato pode também ser usado para indicar que existe um cabeçalho adicional (extensão). Por exemplo, se o valor do campo Formato de um descritor de mensagem é MQFMT_CICS, indica que os dados da mensagem começam com a informação de cabeçalho CICS MQCIH seguido pelos dados de carga útil. Veja a Figura 10 abaixo:

Figura 10. Formato da mensagem MQ

2. Dados de Aplicação

A mensagem, na seção de dados, contém os dados reais enviados a partir de um programa para outro, e seu conteúdo e estrutura são definidos pelas aplicações que a utilizam. Geralmente, os dados de aplicação contêm apenas a informação que é significativa para as aplicações, uma vez que as informações de controle no descritor de mensagem podem ser suficientes.

Mas, em algumas circunstâncias, a informação e seu controle são necessários e são prefixados para os dados de carga sob a forma de cabeçalhos adicionais, como mostrado na Figura 1 acima. Os cabeçalhos adicionais podem ser acrescentados pelos pedidos de um uso específico, como a adição de um cabeçalho de informações IMS (MQIIH) para os dados do aplicativo ao enviar uma mensagem a uma ponte de IMS. Além disso, os cabeçalhos são adicionados às vezes pelo MQ, como descritos abaixo.

A Tabela abaixo lista os cabeçalhos do WebSphere MQ definidos que podem ser prefixados com os dados do aplicativo, com seus nomes de formato.

Tabela - Outras estruturas de cabeçalho definidos pelo MQ

CabeçalhoDescrição do CabeçalhoNome do Formato
MQCIH Cabeçalho da CICS Bridge MQFMT_CICS
MQDLH Cabeçalho da Dead-Letter MQFMT_DEAD_LETTER_HEADER
MQDH Cabeçalho da lista de distribuição MQFMT_DIST_HEADER
MQEPH Cabeçalho de estrutura PCF MQFMT_EMBEDDED_PCF
MQIIH Informação da IMS bridge MQFMT_IMS
MQMDE Estensão da descrição da mensagem (V2) MQFMT_MD_EXTENSION
MQCFH Cabeçalho PCF (comando ou resposta) MQFMT_ADMIN / MQFMT_EVENT / MQFMT_PCF
MQRMH Cabeçalho de referência da mensagem MQFMT_REF_MSG_HEADER
MQRFH Cabeçalho (regras e formatação) MQFMT_RF_HEADER
MQRFH2 Cabeçalho (regras e formatação) V2 MQFMT_RF_HEADER_2
MQWIH Cabeçalho (p/Workload Manager) MQFMT_WORK_INFO_HEADER
MQXQH Cabeçalho da fila de transmissão MQFMT_XMIT_Q_HEADER

Os cabeçalhos adicionais podem ser encadeados, isto é, os dados de aplicação podem conter opcionalmente um ou mais cabeçalhos antes dos dados reais de aplicação. Considere-se, por exemplo, a mensagem para aplicações de publicação / assinatura antes do MQ Versão 7 - os dados da mensagem podem começar com os cabeçalhos MQRFH1 e MQRFH2 juntos. Se mais de um cabeçalho é prefixado aos dados reais de aplicação, eles são encadeados da mesma maneira como mostrados na Figura 3 acima pelo campo de formato.

Formato da Mensagem no MQ V7

MQ V7 (daqui em diante chamado V7) introduziu o conceito de propriedades da mensagem (a partir de JMS), e, por conseguinte, os dois componentes de uma mensagem de MQ são os seguintes:

  • Propriedades da mensagem (cabeçalho da mensagem)
  • Dados de Aplicação (corpo da mensagem)

O formato da mensagem da V7 é mostrado na figura abaixo, bem como as correspondências entre as propriedades da mensagem e descritor de mensagem, veja a Figura 11 abaixo:

Figura 11. Formato da mensagem MQ V7

1. Propriedades da Mensagem

Propriedades da mensagem é um novo recurso da V7 como parte do Message Queue Interface (MQI). Chamadas de funções novas da MQI são usadas para definir, consultar e excluir propriedades da mensagem (MQSETMP, MQINQMP e MQDLTMP). Você também pode usar propriedades da mensagem para incluir dados ou informações de negócio, sem ter de armazená-lo nos dados de aplicação. O uso de propriedades da mensagem no MQ é semelhante ao uso de propriedades em JMS, permitindo que se definam as propriedades em um aplicativo de JMS e os recupere em um procedimento de aplicação MQ, ou vice-versa.

É possível prover propriedades da mensagem em todas as mensagens do gerenciador de filas do MQ, cada uma consistindo de um nome textual e um valor de um tipo particular. O tamanho das propriedades de mensagem não pode exceder a configuração MaxPropertiesLength para um gerenciador de filas. Propriedades da mensagem não são consideradas para o comprimento da mensagem para a fila e o gerenciador de filas. Há um limite de comprimento de 100 MB para propriedades de mensagem, excluindo o descritor de mensagem ou extensão de cada mensagem.

2. Propriedades das mensagens representadas como MQRFH2

As propriedades das mensagens podem ser representadas como elementos MQRFH2. A figura abaixo mostra a estrutura de um cabeçalho MQRFH2, veja a Figura 12 abaixo:

Figura 12. Propriedades das mensagens representadas como MQRFH2

A sequência colocada no campo NameValueData consiste em uma única pasta que contém zero ou mais propriedades. O conteúdo da pasta é tratado como propriedades de mensagem se "conteúdo = elemento de propriedades" é incluído na marca de início da pasta. Se todas as pastas no cabeçalho contêm propriedades, os campos de cabeçalho MQRFH2 próprios são adicionados ao comprimento das propriedades da mensagem e pertencem à seção de propriedades da mensagem. Caso contrário, os campos de cabeçalho são considerados no comprimento da mensagem e fazem parte dos dados da aplicação. Assim, uma aplicação pode colocar uma mensagem com uma parte maior do que o valor de MaxMsgLength quando essa parte inclui propriedades.

3. Campos do descritor da Mensagem como propriedades

A maioria dos campos no descritor de mensagem, exceto StructId e versão, podem ser tratados como propriedades. O nome da propriedade é construído através da adição de um prefixo ao nome do campo descritor de mensagem, como no exemplo Root.MQMD.Priority. Aqui Priority é um campo no descritor de mensagem. Campos do descritor de mensagem nunca são representados em um cabeçalho MQRFH2 como outras propriedades. Se os dados da mensagem começam com uma MQMDE que é aceito pelo gerenciador de filas, os campos MQMDE podem ser acessados usando a mesma sintaxe descrita acima. Neste caso, os campos MQMDE são tratados logicamente como parte do MQMD a partir de uma perspectiva de propriedades.

4. Mensagem enviada para gerenciadores em versão anterior à V7

Quando uma mensagem é enviada para um gerenciador de filas anterior à V7, as propriedades da mensagem, exceto aquelas no descritor de mensagem, são tratadas como dados de mensagem e contam para o comprimento da mensagem, veja a Figura 13 abaixo:

Figura 13. Propriedades das mensagens enviadas comparação de versão

Portanto, o valor do atributo MaxMsgLength de canais que vão para um sistema anterior à V7 deve ser aumentado, para compensar o fato de que mais dados possam ser enviados em cada mensagem.

Alterações das mensagens durante o enfileiramento de mensagens

Enquanto a mensagem viaja a partir de um programa para o outro através do MQ, alterações podem ser feitas na mensagem para transportá-lo para o seu destino. Esta seção explora diferentes formas que uma mensagem pode ser alterada pelo MQ durante a transmissão. As alterações são feitas automaticamente por gerenciadores de filas, agentes do canal de mensagens, ou outras infra-estruturas do MQ, e são transparentes para as aplicações.

Como dito acima, uma mensagem MQ é composta de um cabeçalho de mensagem, que contém informações de controle, e dados de mensagem, que contém dados de aplicação. Esses dados não são alterados por um gerenciador de filas, com exceção no caso de conversão de dados. Na maioria dos casos, as alterações em mensagens são feitas para a informação de controle (cabeçalhos), tais como a inclusão de cabeçalhos adicionais ou modificação dos já existentes.

Incluindo informação de controle adicional

Sob certas circunstâncias, o MQ acrescenta informações de controle extra para uma mensagem, prefixando cabeçalhos adicionais para os dados da mensagem e alterando o campo Formato do descritor de mensagem. O MQ adiciona informações de cabeçalho às mensagens nas quatro seguintes situações:

Situação 1. Quando uma mensagem é colocada em uma fila remota

Quando uma mensagem é colocada em uma fila remota, o MQ adiciona uma estrutura de cabeçalho de transmissão (MQXQH) para a mensagem antes de colocá-lo na fila de transmissão. O cabeçalho de transmissão contém o nome da fila de destino (RemoteQName) e seu gerenciador de filas (RemoteQMgrName), isto é, a informação de endereçamento. Esta informação é utilizada para encaminhar a mensagem para o seu destino correto na rede.

A tabela abaixo apresenta alguns campos principais do MQXQH:

CampoDescrição
RemoteQName Nome da fila de destino
RemoteQMgrName Nome do gerenciador de filas de destino
MsgDesc Descritor da mensagem original (Embutido)

Além da informação de endereçamento, um descritor de mensagem (MsgDesc) é armazenado no interior da estrutura MQXQH como parte dos dados da mensagem. É o que veio com o put original do aplicativo. Outro descritor da mensagem é gerado pelo gerenciador de filas quando a mensagem é colocada na fila de transmissão, armazenados separadamente a partir dos dados da mensagem. Assim, uma mensagem na fila de uma transmissão tem dois descritores de mensagens, como mostrado na Figura 14 abaixo:

Figura 14. Propriedades das mensagens fila remota

O descritor de mensagem incorporado (embedded) é sempre uma estrutura V1 MQMD. Se a mensagem gravada pela aplicação tem valores não-padrão para um ou mais dos campos V2 no MQMD, uma estrutura MQMDE segue o MQXQH, e é por sua vez seguido pelos dados de aplicação, como mostrado na figura acima.

Quando a mensagem chega à sua fila de destino, o cabeçalho de transmissão e o descritor de mensagem separado são removidos, e o descritor da mensagem incorporado torna-se então o descritor de mensagem única da mensagem - ele não faz mais parte dos dados da mensagem.

Situação 2. Quando um gerenciador de filas não pode entregar uma mensagem

Neste caso, o MQ adiciona uma estrutura de cabeçalho da dead-letter (MQDLH) à mensagem, e coloca-a na fila dead-letter (por mensagem não entregue). Além disso, o campo Format do descritor de mensagem (MQMD) é alterado para indicar que a mensagem contém uma estrutura MQDLH. Esta estrutura inclui o nome da fila de destino e o motivo pelo qual a mensagem foi colocada na fila dead-letter.

A tabela abaixo lista os principais campos em MQDLH:

CampoDescrição
Reason Razão pela qual a mensagem chegou na fila dead-letter
DestQName Nome da fila de destino original
DestQMgrName Nome do gerenciador de filas da fila de destino
Format Nome do formato de dados que segue MQDLH
PutApplType Tipo de aplicação que colocou a mensagem na fila dead-letter
PutApplName Nome da aplicação que colocou a mensagem na fila dead-letter

As mensagens podem ser colocadas na fila de dead-letter pelos gerenciadores de filas, agentes de mensagens de canal (MCAS) e aplicações. Todas as mensagens nesta fila devem ser prefixadas com um MQDLH, e as mensagens podem ser truncadas se forem demasiado longas para esta fila por causa da adição do cabeçalho MQDLH.

As aplicações que lêem as mensagens da fila dead-letter devem verificar se as mensagens começam com uma estrutura MQDLH. O aplicativo pode determinar se uma estrutura MQDLH está presente examinando o campo Format no descritor de mensagem. Se o campo tem o valor MQFMT_DEAD_LETTER_HEADER, os dados da mensagem começam com uma estrutura MQDLH.

Situação 3. Ao enviar uma mensagem para as filas de múltiplos destinos

Neste caso, o MQ adiciona uma estrutura de cabeçalho da mensagem de distribuição (MQDH), e coloca-a na fila de transmissão adequada. Assim, os dados de mensagens das aplicações são prefixados com estruturas MQXQH e MQDH. MQDH descreve os dados adicionais em uma mensagem quando ela é uma mensagem da lista de distribuição, armazenadas em uma fila de transmissão. Uma mensagem de lista de distribuição é uma mensagem enviada para as filas de múltiplos destinos. Os dados adicionais consistem na estrutura MQDH seguido por uma matriz de registos MQOR e uma matriz de registos MQPMR.

A tabela abaixo relaciona os principais campos em MQDH:

CampoDescrição
StrucLength Comprimento da estrutura MQDH mais registros seguintes
Format Nome do format de dados que segue o conjunto de registros MQPMR
PutMsgRecFields Flags que indicam quais campos da MQPMR estão presentes
RecsPresent Número de registros objeto presentes
ObjectRecOffset Deslocamento do primeiro registro objeto a contar do início da MQDH
PutMsgRecOffset Deslocamento do primeiro registro de mensagem a contar do início da MQDH

Os dados de uma mensagem da lista de distribuição, em uma fila de transmissão têm a seguinte sequência:

  • Estrutura MQXQH
  • Estrutura MQDH mais matrizes de MQOR e registros MQPMR
  • Dados da mensagem da aplicação (dados de carga)

A estrutura de uma mensagem de lista de distribuição em uma fila de transmissão é mostrada na Figura 15 abaixo:

Figura 15. Propriedades das mensagens múltiplos destinos

StrucLength é o número de bytes desde o início da estrutura MQDH até o início dos dados de mensagem, que seguem os registros de MQOR e MQPMR. ObjectRecOffset dá o deslocamento em bytes do primeiro registro na sequência de registros objeto de MQOR que contém os nomes da filas de destino. PutMsgRecOffset dá o deslocamento em bytes do primeiro registro na sequência dos registros de mensagens gravadas de MQPMR que contém propriesdades de mensagem.

Situação 4. Quando a mensagem é um segmento ou uma mensagem em um grupo

Nesta situação, o MQ pode adicionar a estrutura extensão descritor da mensagem (MQMDE).

A segmentação da mensagem pode ser transparente para os aplicativos. Se for permitido, o gerenciador de filas segmenta uma mensagem grande, quando ela não se encaixa em uma fila. Se o aplicativo está usando um MQMD V1, o gerenciador de filas irá adicionar uma estrutura MQMDE para os dados da mensagem automaticamente. Como já foi discutido acima, a estrutura MQMDE contém esses campos MQMD que existem no MQMD V2, mas não no MQMD V1, onde a informação de segmentação e agrupamento são armazenados.

Mudanças nos campos de cabeçalhos existentes

Além de adicionar cabeçalhos extras a uma mensagem, o MQ pode também alterar alguns campos específicos de cabeçalhos existentes em uma mensagem durante suas transferências entre as aplicações de envio e recebimento, nos seguintes casos:

1. Campo de format em todos os cabeçalhos anteriores

Como mencionado acima, o MQ adiciona informações de cabeçalho da mensagem em circunstâncias específicas. Uma vez que um cabeçalho extra é adicionado, o campo Format na estrutura de cabeçalho precedente também é atualizado pelo MQ para indicar o tipo de novo cabeçalho. Por exemplo, quando o MQ adiciona um cabeçalho de transmissão seguindo o descritor de uma mensagem, o campo Format de MQMD é alterado para MQFMT_XMIT_Q_HEADER.

2. Campos contendo informações de endereçamento no cabeçalho de transmissão

Durante a intercomunicação (no MQ, a intercomunicação significa enviar mensagens de um gerenciador de filas para outro), quando um gerenciador de filas passa uma mensagem completamente, ele pode alterar as informações de endereçamento (RemoteQName, RemoteQMgrName) do cabeçalho de transmissão transmitidos juntamente com a mensagem, se um alias do gerenciador de filas é usado.

As mensagens que chegam de um sistema adjacente contêm no cabeçalho de transmissão o nome físico (após a resolução de nomes) do gerenciador de filas de destino e a fila. Se um gerenciador de filas definido pelo alias existe com o mesmo nome do gerenciador de filas, como referenciado no cabeçalho de transmissão, então o gerenciador de filas local, através do qual a mensagem é passada, substitui o campo RemoteQMgrName com o RQMNAME da definição de alias.

3. ReplyToQ, ReplyToQMgr no descritor da mensagem

As mudanças desses dois campos são feitas antes de uma mensagem ser colocada em uma fila de pedidos. Se um aplicativo coloca uma mensagem para uma fila e fornece o nome de uma fila (ReplyToQ) para mensagens de resposta, mas com o nome do gerenciador de filas (ReplyToQMgr) em branco, o gerenciador de filas local responde ao nome em branco do gerenciador de filas, procurando um definição de fila remota com o mesmo nome que a fila de resposta (para resposta alias de fila):

  • Se nada for encontrado, o gerenciador de filas coloca o seu próprio nome no campo ReplyToQMgr do descritor de mensagem, com a ReplyToQ inalterada.
  • Se a definição existir, o gerenciador de filas extrai o nome da fila e nomes de gerenciador de filas a partir da definição e os coloca na resposta para os campos do descritor de mensagem – ou seja, ele substitui os valores de ReplyToQ e ReplyToQMgr.

4. Campos de contexto no descritor da mensagem

As informações de contexto da mensagem são armazenadas em campos de contexto do descritor da mensagem. Existem dois tipos de contexto de mensagem: contexto identidade e contexto origem. Um novo tipo de informação de contexto é adicionado na V7 para as propriedades da mensagem: contexto do usuário.

A tabela abaixo lista os campos de contexto no descritor de mensagem:

Tipo de ContextoCampos e Descrição
Contexto de Identidade UserIdentifier: identificador do usuário do aplicativo que originou a mensagem

AccountingToken: informações de accounting geradas pelo gerenciador de filas

ApplIdentityData: informações geradas pela aplicação.
Contexto Origem PutApplType: tipo de aplicação que colocou a mensagem.
PutApplName: nome da aplicação que colocou a mensagem
PutDate: data em que a mensagem foi colocada.
PutTime: hora em que a mensagem foi colocada.
ApplOriginData: informações geradas pela aplicação
Contexto Usuário Todas as propriedades identificadas por aplicativos como contexto do usuário.

A maioria dos campos do contexto identidade e origem são normalmente fornecidas pelo gerenciador de filas. As aplicações que rodam com autoridade suficiente podem fornecer seu próprio contexto:

  • Informações de contexto identificam o usuário do aplicativo que gravou pela primeira vez a mensagem em uma fila. O gerenciador de filas preenche os campos UserIdentifier e AccountingToken com base no ambiente em que o aplicativo está sendo executado.
  • Informações de contexto de origem descrevem o aplicativo que coloca a mensagem na fila em que a mensagem está armazenada atualmente. Os seguintes campos são geralmente especificados pelo gerenciador de filas: PutApplType, PutApplName, PutDate, PutTime.
  • Contexto do usuário não é definido pelo gerenciador de filas automaticamente.

5. Campos do descritor de mensagem para Segmentação / Agrupamento (V2)

Se permitido, o gerenciador de filas segmenta uma mensagem para um número de mensagens menores quando ela é demasiado grande para ser enviada. Assim, o gerenciador de filas define a seguinte segmentação / agrupamento de campos no descritor de mensagem, se for V2: GroupId, MsgSeqNumber, Offset, MsgFlags, OriginalLength. Como discutido acima, uma estrutura MQMDE é adicionada pelo gerenciador de filas se o descritor de mensagem é V1.

2.11 Controle de recuperação de mensagens - MsgId e CorrelId

Figura 16. Controle de recuperação de Mensagem – Curso WM100 / VM1001.0

No Figura 16 acima, uma aplicação faz o papel de servidor, respondendo continuamente a pedidos de informação usando uma fila para entrada e outra para saída. Para análise desta situação, considere-se o seguinte:

  • Várias cópias desse aplicativo podem ser executadas simultaneamente.
  • O ReplyToQ é a mesma para todas as aplicações que solicitam resposta.

Considerando esse modelo, pode-se ter as seguintes alternativas para sua implementação:

  1. Uma fila de resposta para todas as solicitações de serviços

Figura 17. Fila de Reply comum – Curso WM100 / VM1001.0

Na Figura 17 este modelo, as seguintes questões são importantes:

  • Que resposta se correlaciona com que pedido?
  • Qual resposta pertence a que aplicativo?
  1. Uma fila resposta temporária para cada solicitação de serviço

Na Figura 18 abaixo, nesse modelo, as seguintes questões são importantes:

  • O que se pode dizer quanto ao uso de mensagens persistentes?

Figura 18. Fila de Reply dinâmica – Curso WM100 / VM1001.0

É possível utilizar uma ReplyToQ separada para cada aplicação que solicita respostas. Essas filas são geralmente filas dinâmicas para facilitar a administração. Quando filas dinâmicas são utilizadas para resposta, o uso de identificação de mensagem e identificação de correlação ainda pode ser necessário para correlacionar as respostas, quando o aplicativo solicitante envia vários pedidos antes de receber as respostas.

MsgId, CorrelId, e paralelismo de aplicação

No exemplo abaixo, pode-se ter o envio de solicitações para diferentes aplicações de informação (talvez saldo bancário de conta e uma verificação de crédito para um pedido de empréstimo). Será necessário ser capaz de coletar todas as respostas que estão relacionadas a um pedido especial entre as muitas respostas gravadas na fila resposta. Não se pode ter certeza sobre a ordem das respostas. Em uma das execuções, podem-se obter as informações de saldo da conta antes da informação de verificação de crédito. Da próxima vez, as respostas podem ser invertidas.

Ao emitir o MQGET usando identificação de mensagem ou ID de correlação ou de ambos, as mensagens corretas podem ser recuperadas, enquanto outras são deixadas intactas. O aplicativo que emite o MQPUT da mensagem inicial deve garantir a configuração de alguns valores exclusivos de um ou de ambos os campos. Um programa pode colocar qualquer valor desejado em um ou ambos os campos. No caso do CorrelId, qualquer valor neste campo no momento do MQPUT é inalterado pelo gerenciador de filas. No caso de identificação de mensagem, o conteúdo do campo no momento do MQPUT determina se o gerenciador de filas atribui um valor único e o coloca no campo ID da mensagem, veja na Figura 19 abaixo:

Figura 19. MsgId, CorrelId, e paralelismo de aplicação – Curso WM100 / VM1001.0

MQPUT e MQPUT1 – Msgid, Correlid

Para as chamadas MQPUT e MQPUT1, se MQMI_NONE ou MQPMO_NEW_MSG_ID é especificado pelo aplicativo, o gerenciador de filas gera um identificador de mensagem 2 exclusivo quando a mensagem é gravada, e o coloca no descritor de mensagem enviado com a mensagem. O gerenciador de filas também retorna este identificador de mensagem no descritor de mensagem pertencente ao aplicativo de envio. O aplicativo pode usar este valor para registrar informações sobre as mensagens particulares, e para responder a consultas de outras partes da aplicação, veja na Figura 20 abaixo:

Figura 20. MQPUT e MQ, PUT1 – Msgid, Correlid – Curso WM100 / VM1001.0

Um uso comum de MSGID gerado e CORRELID é relacionar mensagens colocadas com as suas respostas, como mostrado nos gráficos anteriores.

O aplicativo de envio também pode especificar um valor para o identificador de mensagem diferente de MQMI_NONE; isto impede do gerenciador de filas gerarem um identificador de mensagem exclusivo. Um aplicativo que está encaminhando uma mensagem pode usar isso para propagar o identificador da mensagem original.

O gerenciador de filas não utiliza este campo, exceto para:

  • Gerar um valor único se requerido, como descrito acima
  • Entregar o valor para o aplicativo que emite o pedido de leitura da mensagem
  • Copiar o valor para o campo CorrelId de qualquer mensagem de relatório que ele gera sobre esta mensagem (dependendo das opções do relatório)

Quando o gerenciador de filas, ou um agente de canal, gera uma mensagem de relatório, ele define o campo ID da mensagem da forma especificada pelo campo de relatório da mensagem original, MQRO_NEW_MSG_ID ou MQRO_PASS_MSG_ID. Aplicações que geram mensagens de relatório devem agir também dessa forma.

Porque os identificadores MSGID e CORRELID são considerados campos em bytes e não cadeias de caracteres, eles não são convertidos quando a mensagem flui de um gerenciador de filas para o outro.

No exemplo mostrado, pode-se ver o uso de constantes simbólicas para definir MSGID e CORRELID para valores nulos (low values). Note-se que no primeiro caso define-se a identificação de mensagem e identificação de correlação antes de entrar no loop para o MQPUT, enquanto o segundo caso tem a configuração de um desses campos dentro do ciclo.

Em todas as implementações, se um aplicativo define o campo ID da mensagem com nulos (low values), o gerenciador de filas atribui um valor único para a identificação da mensagem. Qualquer outro valor atribuído pela aplicação resulta em nenhuma ação tomada pelo gerenciador de filas, permitindo ao aplicativo poder especificar um ID de mensagem explicitamente.

Recuperação por MsgId e Correlid

Os exemplos abaixo, a Figura 21 mostra leituras de mensagens usando MSGID e CORRELID. Nestes exemplos, pode-se notar que em cada caso os campos na MQMD são inicializados antes do MQGET:

  1. O programa solicita a a primeira mensagem disponível, independentemente dos valores de identificação de mensagem e identificação de correlação (MQGET MSGID=MQMI_NONE e CORRELID=MQCI_NONE).
  2. Solicita uma mensagem que tem uma identificação de correlação igual a 3, independentemente do valor do campo ID mensagem (MQGET MSGID=MQMI_NONE e CORRELID=3)
  3. A leitura tem sucesso se é encontrada uma mensagem com ID de mensagem igual a 4, independentemente do valor na identificação de correlação (MQGET MSGID=4 e CORRELID=MQCI_NONE).
  4. A menos que uma mensagem com ID de mensagem igual a 4 e identificação de correlação igual a 2 é encontrada, esta chamada não teria sucesso (MQGET MSGID=4 e CORRELID=2).

Figura 21. MQPUT e MQPUT1 – Msgid, Correlid – Curso WM100 / VM1001.0

É preciso lembrar que filas com muitas mensagens podem causar um impacto no desempenho, se um aplicativo escolhe usar identificação de mensagem e identificação de correlação para um MQGET. Em geral, filas que possuem menos de cem mensagens não costumam ser causa de problemas. No entanto, se uma fila tem milhares de mensagens, o gerenciador de filas na verdade, varre a fila à procura de uma mensagem que satisfaça as condições. No z/OS, é possível para o administrador de MQ definir tanto a identificação de mensagem ou a identificação de correlação como um índice. Por exemplo, se a definição de Indextype de uma fila é a identificação de mensagem, um índice de todos os msgids na fila é mantido e a recuperação de mensagens por identificação de mensagem é mais rápida, mesmo se houver um grande número de mensagens na fila. Usando uma pesquisa por CorrelId resulta em processamento mais lento, uma vez que não é possível especificar Indextype para ambos.

É possível especificar MQMO_MATCH_MSG_ID e MQMO_MATCH_CORREL_ID no campo MatchOptions e evitar ter de reinicializar a identificação da mensagem e identificação de correlação. Isto significa que não especificar MQMO_MATCH_MSG_ID resulta na recuperação da próxima mensagem disponível seguinte, independentemente do valor em identificação de mensagem. O mesmo vale se o MQMO_MATCH_CORREL_ID não é especificado. Em outras palavras, se as opções de correspondência não são especificadas, o ID da mensagem e o ID de correlação são ignorados no MQGET, comportando-se da mesma forma como se fosse usado MQMI_NONE e MQCI_NONE, respectivamente. Isso faz com que aplicativos executados nessas plataformas sejam mais fáceis de serem codificadas.

O padrão para essas plataformas é MQMO_MATCH_MSG_ID e MQMO_MATCH_CORREL_ID. Isso significa que nenhuma alteração de programas é necessária para os programas que são migrados de versões anteriores. Se o programa estava procurando por uma correspondência, ele continua a fazê-lo. No entanto, os novos programas têm menos a considerar. Eles não têm de limpar o ID da mensagem e a identificação de correlação antes de cada MQGET, se não querem encontrar uma mensagem correspondente. Eles têm apenas que definir as MatchOptions para MQMO_NONE.

Recuperando todas as mensagens

A aplicação controla qual a mensagem que ele recupera com MQGET. Ao definir o ID da mensagem e identificação de correlação na MQMD com nulos (low values) antes do MQGET, a próxima mensagem disponível na fila será recuperada. No entanto, uma vez que o MQGET é completado, os valores na identificação de mensagem e identificação de correlação são inicializados para aqueles da mensagem que acabou de ser lida. Se não continuamente redefinidas para valores nulos (low values), o aplicativo pode receber um código de conclusão de erro, com a razão definida para MQRC_NO_MSG_AVAILABLE mesmo que haja mensagens na fila.

No exemplo mostrado abaixo, Figura 22, pode-se ver o uso de constantes simbólicas para definir ID de mensagem e identificação de correlação para valores nulos (low values). No primeiro caso, a definição da identificação de mensagem e identificação de correlação é feita antes de entrar no loop de leitura (MQGET), enquanto no segundo caso a configuração desses campos é feita dentro do ciclo.

Há um campo adicional disponível na versão 2 na estrutura de opção de leitura de mensagem, chamada matchoptions. É possível especificar MQMO_NONE e evitar ter de redefinir o ID da mensagem e identificação de correlação. Isto resulta na recuperação na próxima mensagem disponível independentemente dos valores de identificação de mensagem e identificação de correlação.

Figura 22. Recuperação de Mensagem – Curso WM100 / VM1001.0

MsgId, correlid, reports e replies

A Figura 23 abaixo relaciona os conceitos de identificação da mensagem, identificação de correlação, relatórios, respostas e MQGETs seletivos.

Figura 23. MsgId, correlid, reports e replies – Curso WM100 / VM1001.0

  1. A aplicação que pede uma resposta cria um MQMD novo, definindo o MsgType como pedido (request), a fila de resposta como Q2, o ID da mensagem para MQMI_NONE e pede ao gerenciador de filas para gerar relatórios COA e COD.
  2. Respondendo a MQMI_NONE no campo MQMD da identificação de mensagem, o gerenciador de filas cria um ID único para a nova mensagem - representado como 99 neste exemplo, e retorna este valor para o programa no MQMD.
  3. Quando a mensagem é gravada em Q1, o gerenciador de filas cria uma mensagem de relatório COA, conforme solicitado, enviando-a para a fila de resposta Q2. Por padrão, o ID de mensagem de pedido é copiado para o ID de correlação na mensagem de relatório.
  4. A aplicação que usa MQGET faz com que o gerenciador de filas gere outra mensagem de relatório, desta vez com um feedback de COD. O CorrelId desta mensagem é montado da mesma forma que para o relatório COA.
  5. Por convenção, quando o aplicativo de resposta cria sua mensagem de resposta, ele emula a ação do gerenciador de filas em copiar o ID da mensagem de entrada para a identificação de correlação de saída.
  6. Há agora três mensagens em Q2: dois relatórios gerados pelo gerenciador de filas, e uma resposta criada pela aplicação.
  7. A fim de obter apenas as respostas e relatórios que se relaciona com o pedido 99, a aplicação requerente define o campo MSGID para MQMI_NONE e o campo de correlação para 99.
  8. MQGETs subsequentes recuperam apenas mensagens relevantes. A aplicação que fez o pedido pode distinguir entre relatórios e respostas inspecionando o MsgType, e o tipo de relatório inspecionando o campo de feedback.

Responder (Replay) para filas

É possível a um aplicativo definir explicitamente o nome da fila e o nome do gerenciador de filas no descritor de objeto antes de um MQPUT. Estes valores podem ser codificados explicitamente, mas o exemplo abaixo mostra a situação mais comum onde esta técnica é utilizada. Ambos os campos são inicializadas com valores tomados a partir do descritor de mensagem recebida.

Subsequentes MQOPEN e MQPUT, ou um MQPUT1, enviam uma resposta para a fila de resposta no gerenciador de filas especificados no descritor da mensagem lida. Como o nome do gerenciador de filas foi especificado explicitamente, quaisquer definições de fila local são ignoradas, e o gerenciador de filas procura uma fila de transmissão com o mesmo nome do ObjectQMgrName (se não é o nome do gerenciador de filas local), constrói um cabeçalho de transmissão contendo a informação de endereçamento coloca a mensagem nessa fila de transmissão.

A fila de resposta assim acessada foi dinamicamente criada na aplicação que fez a solicitação, caso em que a definição de uma fila de pré-definida não poderia existir de qualquer maneira, veja na Figura 24 abaixo:

Figura 24. Replay das filas – Curso WM100 / VM1001.0

2.12 Expiry

O valor Expiry é o tempo de vida da mensagem. Este é um período de tempo, expresso em décimos de segundo, criado pelo aplicativo que coloca a mensagem na fila. A mensagem torna-se elegível para ser eliminada se não tiver sido removida da fila de destino antes de decorrido este período de tempo.

A mensagem é descartada quando uma leitura ou pesquisa (browse) é feita e que teria retornado a mensagem se ela não tivesse expirado.

O valor padrão é MQEI_UNLIMITED, que dá uma vida sem limite à mensagem, veja a Figura 25 abaixo:

Figura 25. Expire o tempo das filas – Curso WM100 / VM1001.0

2.13 Opções para pedidos de Report

Abaixo estão os valores a serem fornecidos por aplicações ao solicitar ao gerenciador de filas informações sobre o recebimento de mensagens, expiração, rotas, e outras informações referentes à entrega das mensagens.

  • Pedidos de relatório com comentários gerados pelo gerenciador de filas

    - MQRO_EXCEPTION
    - MQRO_EXPIRATION
    - MQRO_COA (confirmação de recebimento)
    - MQRO_COD (confirmação de entrega)
    - MQRO_ACTIVITY (informação sobre a rota da mensagem)
  • Requisição de relatório com comentários gerados por um programa de aplicação

    - MQRO_PAN (confirmação positiva)
    - MQRO_NAN (confirmação negativa)
  • Uso de MQRO_ requer que o campo reply-to-queue seja preenchido
  • Os pedidos de relatório EXCEPTION, EXPIRATION, COA e COD podem ser estendidos para se receber também parte ou a mensagem completa enviada originalmente, como parte do relatório. As opções são WITH_DATA (os 100 primeiros caracteres da mensagem original) ou WITH_FULL_DATA (os dados da mensagem original).

Observações:

  • Mensagem de Expiração - indica que um aplicativo tentou recuperar uma mensagem que havia chegado ao seu limite de validade e que a mensagem foi descartada.
  • Mensagem de confirmação de chegada (COA) - indica que a mensagem chegou na sua fila de destino.
  • Mensagem de confirmação de entrega (COD) - indica que a mensagem foi recuperada por um aplicativo.
  • Atividade - permite que a rota de qualquer mensagem possa ser rastreada ao longo de uma rede de gerenciadores de filas
  • Notificação de ação positiva (PAN) – implica em que um pedido foi completamente atendido.
  • Notificação de ação negativa (NAN) - implica em que o pedido não foi atendido com sucesso.

2.14 Prioridade

As mensagens podem ser recuperadas de uma fila usando o modelo FIFO, cujo significado é o primeiro a entrar é o primeiro a sair. É uma abordagem para lidar com solicitações de trabalho com filas a fim de que o mais antigo pedido seja tratado primeiramente.

A prioridade da mensagem é especificada no descritor de mensagem. Mensagens de igual prioridade são recuperadas no modelo FIFO.

A prioridade de uma mensagem pode ser definida em dois momentos, conforme Figura 26 e descrito abaixo:

  • O campo de prioridade no descritor de mensagem - usando este campo, pode-se definir a prioridade de uma mensagem quando ela é colocada em uma fila. Este valor pode estar no intervalo de 0-9, ou então ser -1, que faz com que a mensagem tenha o mesmo atributo de prioridade padrão da fila.
  • O atributo MsgDeliverySequence da fila - Esse atributo, definido pelo administrador, determina como a mensagem é armazenada na fila pelo gerenciador de filas. Se o valor deste atributo é MQMDS_FIFO, as mensagens são enfileiradas com a prioridade padrão da fila, independentemente da prioridade definida pela aplicação. Se este atributo é MQMDS_PRIORITY, o valor de prioridade no descritor de mensagem é honrado quando a mensagem é gravada.

O parâmetro para definir a prioridade numa fila é o MSGDLVSQ e é suportado apenas em filas locais e modelo. Pode assumir os seguintes valores:

  • PRIORITY - As mensagens são entregues (em resposta a chamadas MQGET API) na ordem FIFO no âmbito da sua prioridade. Este é o padrão fornecido com o WebSphere MQ.
  • FIFO - As mensagens são entregues (em resposta a chamadas MQGET API) em ordem FIFO. A prioridade é ignorada para as mensagens nesta fila.

Figura 26. Prioridade das filas – Curso WM100 / VM1001.0

2.15 Implementando Trigger no MQ

É possível especificar para o gerenciador de filas certas condições para prover disparos de eventos (trigger events). Se o disparo (triggering) é habilitado para uma fila e um evento de disparo (trigger) ocorrer, o gerenciador de filas envia uma mensagem de trigger para uma fila chamada fila de iniciação. A presença da mensagem de trigger nessa fila indica que um evento de disparo ocorreu.

Mensagens de trigger geradas pelo gerenciador de filas não são persistentes. Isto tem o efeito de redução da logging (melhorando assim o desempenho), e de minimizar duplicidades de mensagens durante a reinicialização, para melhorar o tempo de reinício.

O programa que processa a fila de iniciação recebe o nome de aplicação monitor de trigger, e sua função é ler a mensagem de trigger e tomar as medidas adequadas, com base na informação contida na mensagem de trigger. Normalmente, essa ação é começar alguma outra aplicação para processar a fila que gerou a mensagem de trigger. Do ponto de vista do gerenciador de filas, não há nada especial sobre a aplicação de monitor de trigger, ela é considerada simplesmente outro aplicativo que lê mensagens de uma fila (a fila de iniciação).

Processo

Se o triggering está habilitado para uma fila, é necessário criar um objeto de definição de processo associado. Este objeto contém informações sobre o aplicativo que processa a mensagem que causou o evento de trigger. Se o objeto de definição de processo é criado, o gerenciador de filas extrai essas informações e coloca-as na mensagem de trigger, para uso do aplicativo monitor de trigger. O nome do processo de definição associado a uma fila é dado pelo atributo ProcessName de uma fila local. Cada fila pode especificar uma definição de processo diferente, ou diversas filas podem compartilhar o mesmo processo de definição.

Se for conveniente usar o triggering para iniciar um canal, não é necessário definir um objeto de definição do processo. A definição da fila de transmissão é usada.

Um aplicativo executado em um ambiente cliente é o mesmo que um executado em um ambiente de MQ, exceto pelo uso das bibliotecas de cliente. No entanto, o monitor de trigger e a aplicação a ser iniciada devem estar ambos no mesmo ambiente.

Fila de Inicialização (Initiation)

Uma fila de iniciação é uma fila local na qual o gerenciador de filas coloca as mensagens de trigger. Um gerenciador de filas pode possuir mais de uma fila de iniciação, e cada uma está associada com uma ou mais filas de aplicação.

Monitor Trigger

Um monitor de trigger é um programa de execução contínua que serve uma ou mais filas de iniciação. Quando uma mensagem de trigger chega a uma fila de iniciação, o monitor do trigger recupera a mensagem e verifica o seu conteúdo, extraindo os dados necessários para iniciar a aplicação que lerá os dados da fila de dados. Ele emite um comando para iniciar a aplicação que é para recuperar as mensagens que chegam à fila de pedido, passando as informações contidas no cabeçalho da mensagem de trigger, que inclui o nome da fila de aplicação.

Em todas as plataformas, há um monitor de trigger especial, conhecido como o iniciador de canal, responsável por iniciar canais. No z/OS, o iniciador de canal é normalmente iniciado manualmente, ou pode ser feito automaticamente. Em outras plataformas, ele é automaticamente iniciado quando o gerenciador de filas começa ou pode ser iniciado manualmente com o comando runmqchi.

Triggering envolve:

  1. Fila de Aplicação - Uma fila de aplicação é uma fila local com as definições de triggering, e quando as condições forem satisfeitas faz com que o gerenciador de filas grave as mensagens de trigger.
  2. Definição de Processo - Uma fila de aplicação pode ter um objeto de definição do processo associado a ela que contém os detalhes da aplicação que irá receber mensagens da fila de aplicação.
  3. Fila de transmissão – Será necessária uma fila de transmissão, para um trigger iniciar um canal.

Os atributos relevantes são:

TriggerMSGPriority – Esse atributo é definido para a fila a partir da qual se quer disparar eventos de triggering. Ele define o valor mínimo da prioridade da mensagem que pode disparar um evento. Se uma mensagem de prioridade inferior a triggerMSGPriority é gravada na fila do aplicativo, o gerenciador de filas ignora a mensagem quando se determina se deve criar uma mensagem de trigger. Se TriggerMsgPriority está definido para zero, todas as mensagens são consideradas para um evento de trigger.

Tipo de Trigger

Além do tipo NONE (que desativa o trigger, assim como definir o controle de trigger para OFF), pode-se usar os tipos de trigger a seguir para alterar a sensibilidade de uma fila para disparo de eventos:

EVERY – o evento de trigger ocorre toda vez que chega uma mensagem na fila de aplicação. Este tipo de trigger pode ser utilizado por programas que esperam processar apenas uma mensagem por ciclo.

FIRST – o evento de trigger ocorre somente quando ocorre a mudança do número de mensagens da fila de zero para um. Este tipo de trigger pode ser utilizado para iniciar um programa que processa várias mensagens de uma fila, processando a primeira que fez o disparo do programa e esperando as demais para processamento.

DEPTH – o evento de trigger ocorre apenas quando o número de mensagens na fila de aplicação atinge o valor do atributo Profundidade de trigger. Uma utilização típica deste tipo de trigger é para iniciar um programa que processa todas as respostas de um conjunto de pedidos.

Para melhor entender como o trigger trabalha, considere-se a Figura 27 abaixo, que é um exemplo de trigger tipo FIRST (MQTT_FIRST).

Figura 27. Tipos de Triggers – Curso WM100 / VM1001.0

Nessa Figura 27, a sequência dos eventos é:

  1. A aplicação A, que pode ser local ou remota para o gerenciador de filas, coloca uma mensagem na fila de aplicação.
  2. O gerenciador de filas verifica se estão reunidas as condições sob as quais ele deve gerar um evento de trigger. Nesse exemplo, as condições estão satisfeitas, e então um evento de trigger é gerado. As informações constantes do objeto de definição do processo associado são usadas ao criar a mensagem trigger.
  3. O gerenciador de filas cria uma mensagem de trigger e coloca-a na fila de iniciação associada a esta fila de aplicação. Um aplicativo (trigger monitor) tem a fila de iniciação aberta para entrada.
  4. O monitor de trigger recupera a mensagem da fila de iniciação.
  5. Com base nas informações da mensagem, o monitor de trigger emite um comando para iniciar o aplicativo B (o servidor de aplicação).
  6. Aplicativo B abre a fila do aplicativo e recupera a mensagem.

Observações:

  1. Se a fila do aplicativo é aberta para entrada, por qualquer programa, e tem trigger estabelecido como FIRST ou DEPTH, os eventos de trigger não vão ocorrer porque a fila já está sendo servida.
  2. Se a fila de iniciação não é aberta para entrada, o gerenciador de filas não gera mensagens de trigger; ele espera até que um aplicativo abra a fila de iniciação para entrada.
  3. Ao utilizar trigger de canais, usar o tipo de trigger FIRST ou DEPTH.

É possível usar o conceito de triggering quando se trabalha com várias aplicações gravando mensagens em diversas filas para as quais estão definidos processos de triggering. O gerenciador de filas pode usar apenas uma fila de iniciação para disparar várias aplicações, tendo em vista que estas informações pertencem aos processos ligados às filas de disparo, como se pode ver na Figura 28 abaixo.

Figura 28. Tipos de Triggers – Curso WM100 / VM1001.0


3. Fonte e Recursos

Site do WMQ -http://www.ibm.com/software/integration/wmq

IBM WebSphere MQ Quick Tour -http://www.ibm.com/software/integration/wmq/quicktour

SupportPacs -http://www-1.ibm.com/support/docview.wss?uid=swg27007197

InfoCenter – Manuais dos Produtos

http://www.ibm.com/software/integration/wmq/library/

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzao.doc/mi11030_.htm

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp

DeveloperWorks – Site com informações técnicas publicadas por profissionais da IBM e não IBM

http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html

http://www.ibm.com/developerworks/websphere/library/techarticles/0807_hsieh/0807_hsieh.html

http://www.developer.ibm.com/tech/sampmq.html

http://www.ibm.com/developerworks/websphere/library/techarticles/1001_xiao/1001_xiao.html

Guia Programação Aplicação
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzal.doc%2Ffg10120_.htm

Referências Programação de Aplicação
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzak.doc%2Ffr10120_.htm

Constantes
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaq.doc%2Ffc10120_.htm

Usando Java
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaw.doc%2Fuj10120_.htm

Curso Technical Introduction to IBM WebSphere MQ (Course code WM100 / VM100)

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=843890
ArticleTitle=WEBSPHERE MQ CONCEITOS – PARTE I
publish-date=11022012