Mq conceitos melhores_praticas

© Copyright IBM Corporation 2012. Todos os direitos reservados. Marcas Registradas
WEBSPHERE MQ CONCEITOS – PARTE I Página 1 de 39
WEBSPHERE MQ CONCEITOS – PARTE I
PAULO AUGUSTO HUGGLER DA SILVA
Especialista Técnico WebSphere em Conectividade e
Ferramentas de Determinação de Problemas.
MARCELO GIANINI NOVAES
Especialista Técnico WebSphere em Soluções de BPM,
Conectividade e Infraestrutura de Aplicações.
IBM China
02/Nov/2012
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.
Abreviações Descriçã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

developerWorks® ibm.com/developerWorks/br/
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.

ibm.com/developerWorks/br/ developerWorks®
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)
- 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)
- 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)
- 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

• MQCLOSE – Fecha uma fila
MQCLOSE(Hconn, Hobj, Options, CompCode, Reason)
- Options = opções que controlam a ação de fechamento da fila
• MQDISC – Desconecta o programa do gerenciador de filas
MQDISC(Hconn, Hobj, CompCode, Reason)
- CompCode = código conclusão: OK, WARNING, ou FAILED
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çalho Descrição do Cabeçalho Nome 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:
Campo Descriçã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:
Campo Descriçã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:

Campo Descriçã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 Contexto Campos 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?
2. 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:
a. 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.
b. 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.
c. 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)

Sobre os autores
PAULO AUGUSTO HUGGLER DA SILVA
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
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
© Copyright IBM Corporation 2012. Todos os direitos reservados.
(www.ibm.com/legal/copytrade.shtml)
Marcas Registradas
(www.ibm.com/developerworks/br/ibm/trademarks/)

Mq conceitos melhores_praticas

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mq conceitos melhores_praticas

Semelhante a Mq conceitos melhores_praticas (20)

Mais de MoisesInacio

Mais de MoisesInacio (8)

Mq conceitos melhores_praticas