Mq conceitos melhores_praticas_parte_ii

© Copyright IBM Corporation 2012. Todos os direitos reservados. Marcas Registradas
WEBSPHERE MQ MELHORES PRÁTICAS – PARTE II Página 1 de 20
WEBSPHERE MQ MELHORES PRÁTICAS – PARTE II
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. Melhores Práticas
Muitos artigos e livros de diferentes fontes oferecerem recomendações para a concepção de enfileiramento
de mensagens e sua integração com aplicações. Este capítulo tem a intenção de simplificar esse conjunto
de informações, listando algumas das melhores práticas amplamente reconhecidas do uso do MQ para
implementar o enfileiramento de mensagens, seja na concepção, construção e manutenção de soluções MQ.
1.1 Uso de nomes curtos para os gerenciadores de filas e objetos MQ
Muitas vezes, nomear uma fila é um desafio. Frequentemente, criar filas e outros objetos seguindo a
convenção de nomenclatura da instalação fere as regras do MQ ou não é tão descritivo quanto se gostaria.
Em geral, nomes de objetos MQ podem ter até 48 caracteres, com exceção de nomes dos canais, que podem
ter no máximo 20 caracteres. Pode-se usar maiúsculo e minúsculo A-Z, numérico 0-9, sublinhado (_),
período, e dois caracteres especiais: Barra (/) e porcentagem (%). Se qualquer um destes dois caracteres
especiais é utilizado, os nomes devem ser colocados entre aspas duplas.
Além das normas gerais, aqui estão algumas diretrizes recomendadas para nomeação de gerenciadores de
filas e objetos MQ:
• Uso de MAIÚSCULAS para o nome todo de todos os objetos, incluindo o gerenciador de filas, para
evitar problemas de portabilidade em ambientes heterogêneos.
• O nome do gerenciador de filas deve ser único na rede MQ e refletir a localização, função e ambiente
do gerenciador de filas (dev, teste, etc).
• Mantenha os nomes dos gerenciadores de filas curto, não mais que 8 caracteres. Para gerenciadores em
z/OS, o limite máximo é 4 caracteres.
• Embora a barra (/) e porcentagem (%) - caracteres especiais - sejam permitidos, é melhor evitá-los, para
permitir, de forma fácil, a portabilidade para outras plataformas.
• Os nomes dos canais devem refletir a sua função e origem/destino do fluxo de conexão, por
exemplo, FROMQUEUEMANAGERNAME.TOQUEUEMANAGERNAME para canais sender
e receiver, e TO.QUEUEMANAGERNAME para os canais de cluster. Se existir mais de um
canal ligando dois gerenciadores de filas, é aconselhável adicionar ao nome algo que seja a
característica do canal, como prioridade ou protocolo. Outra prática comum é usar nomes no modelo
SOURCEQUEUEMANAGERNAME.TO.DESTQUEUEMANAGERNAME.
• As filas não devem ter a palavra QUEUE em seu nome (já que está implícito), nem devem ter a
topologia em seu nome (local, remoto, alias).

ibm.com/developerWorks/br/ developerWorks®
• Filas que atendem aplicações devem ter um qualificador de alto nível que consiste em alguns
caracteres, seguido por algum delimitador (como um ponto), de modo que o tipo de serviço e finalidade
da fila sejam fácilmente identificáveis (tais como APPXYZ.SERVICE1.REQUEST).
• É aconselhável não usar espaços nos nomes de objetos MQ, incluindo nomes de host do sistema.
• Para as autorizações MQ, embora o comprimento máximo de nomes de grupos e IDs de usuário sejam
de 20 caracteres, é melhor mantê-los com menos de 12 caracteres.
1.2 Atribuição de uma fila Dead Letter (DLQ) ao gerenciador de filas
A DLQ é uma fila local que também é conhecida como a fila de mensagens não entregues. É uma boa
prática criá-la e atribuir uma para cada gerenciador de filas e usá-la para capturar as mensagens que
não são entregues devido a problemas de rede ou de destino. Caso a DLQ não esteja definida, erros nos
programas de aplicação podem causar parada nos canais. Nesse caso, não somente a fila destino não recebe
as mensagens, mas as operações normais do MQ são afetadas - por exemplo, comandos administrativos
podem não ser recebidos e executados.
Sob ambientes de aplicações restritivas, onde o processamento exato de mensagens em ordem precisa deve
ser garantido, uma DLQ pode ser omitida para forçar o desligamento do processamento em caso de erros.
Recomenda-se que as aplicações sejam concebidas especialmente para evitar este cenário.
A DLQ deve ser monitorada, uma vez que as mensagens que chegam a esta fila representam erros. Ela
deverá ser definida, estar disponível e dimensionada para as maiores mensagens que o sistema manuseia.
Em ambientes mais robustos, pode-se criar um manipulador da DLQ como um trigger, para que haja
uma nova tentativa de entrega para as mensagens, sem intervenção. Se a nova tentativa falhar, então
regras personalizadas para a DLQ devem ser usadas para transmitir ou remover as mensagens, conforme
necessário. O MQ fornece um manipulador DLQ amostra (runmqdlq / amqsdlq) para a sua aprendizagem e
experimentação. Em z/OS, há um utiulitário especial para a administração da DLQ.
O comando ALTER MQSC pode ser usado para adicionar uma DLQ a um gerenciador de filas.
1.3 Evitar o uso de nomes fixos de objetos em programas
É aconselhável evitar o uso de definições de objetos MQ de forma fixa nos programas (hard-code),
para permitir uma maior flexibilidade e portabilidade das aplicações. Estas características podem ser
implementadas usando-se filas alias, filas modelo, juntamente com as variáveis de ambiente MQ. A adesão
a essas regras permite que as aplicações possam ser implantadas em diferentes ambientes (redes complexas,
sistemas operacionais e protocolos de comunicação diferentes e mixados, e ambientes de linguagem mistos),
sem serem alterados.
1.4 Quando possível, usar cluster nos servidores MQ
Se a infraestrutura do ambiente puder suportar, hardware e software de clustering fornecerão uma ótima
maneira de aumentar a resiliência, escalabilidade e desempenho das soluções que envolvem MQ. Abaixo
estão algumas recomendações ao considerar cluster em MQ:
• Os gerenciadores de filas MQ não reiniciam automaticamente depois de uma queda, e em geral, nem
cluster em MQ nem cluster baseado em hardware como HACMP, SUNCLUSTER, etc., fornece esse

comportamento por padrão. Se esta funcionalidade é um requisito, as soluções baseadas em hardware
de clustering e ferramentas de automação de sistema geralmente podem ser configuradas para fornecer
esse comportamento.
• Aplicações que tem afinidades de mensagerias podem levar a rotinas complicadas de gestão de carga de
trabalho do cluster e aquém do ideal. Remover afinidades de mensagem nos aplicativos pode aumentar
a disponibilidade dos aplicativos e as opções de escalabilidade.
• A menos que as afinidades de mensagens específicas dentro da sua aplicação sejam necessárias, é
desaconselhável o uso da opção MQOO_BIND_ON_OPEN em uma chamada MQOPEN para forçar as
mensagens serem enviadas para um destino específico. Se o gerenciador de filas de destino não estiver
disponível, as mensagens não são encaminhadas para outro gerenciador de filas no cluster.
• Não é aconselhável o uso de nomes genéricos, como CONNAME para o canal. É melhor especificar o
nome do host ou endereço IP do gerenciador de filas onde está o full repository do cluster.
• Com as permissões apropriadas, podem-se gravar mensagens em qualquer fila no cluster, porém só se
podem ler mensagens de uma instância local de uma fila do cluster.
• Deve-se escolher pelo menos um e preferencialmente dois gerenciadores de filas no cluster para servir
como repositório full. Adicionar mais de dois repositórios full muitas vezes degrada o desempenho
global, porque o cluster terá de gerar tráfego adicional e gastar mais tempo na manutenção de todos os
repositórios.
• Quando decidir quais servidores vai sediar os repositórios full, é aconselhável selecionar os servidores
que são altamente confiáveis, bem gerenciados, e tem um IP estático.
1.5 Infraestruturas com menos gerenciadores de fila com mais filas
Por razões de arquitetura, bem como de desempenho, é melhor, na maior parte dos casos, criar um
gerenciador de filas com 100 filas ao invés de 100 gerenciadores de fila com uma fila cada um, para dar um
exemplo deste conceito. Onde fizer sentido, deve-se tentar limitar o número de gerenciadores de filas em
um ambiente MQ. Um gerenciador de fila único por servidor normalmente pode atender as necessidades de
todas as filas e dos aplicativos no servidor. Enquanto o gerenciador de filas puder cumprir várias funções, a
segregação de responsabilidade deve ocorrer em nível de fila, de preferência com um identificador de função
no nome da fila.
1.6 Tratamento do Código de Conclusão e do Código de Razão em todas as chamadas
MQI
Para cada chamada MQI (MQOPEN, MQPUT, MQGET, etc), o MQ retorna dois valores: Código de
Conclusão (Completion Code - CC) e Código de Razão (Reason Code - RC) – indicando sucesso ou falha da
ação (Completion Code) e a causa da falha (Reason Code). Os Reason Codes oferecem um nível de detalhe
bom para a investigação da causa do erro. Fornecer esses valores a quem vai analisar os possíveis erros é
uma tarefa importante do programa.
Assim, a cada execução de MQI Call, o CC e o RC devem ser testados, e se diferentes de zero e signifiquem
erros, o programa deve emitir mensagens significativas com esses valores.
Quando for preciso acionar o Suporte IBM, códigos de conclusão e razão, juntamente com a descrição do
problema, podem acelerar a determinação da causa do problema e sua solução.

1.7 Codificação dos programas para processar continuamente as mensagens
Os programas devem ser codificados de forma a poder processar mais de uma mensagem da fila, quando
isso atender ao negócio endereçado pelas mensagens e for possível esse tipo de processamento. Um
programa que lê ou grava apenas uma mensagem por vez emite comandos de conexão e abertura de fila
e depois de fechamento e desconexão desnecessariamente, considerando todas as mensagens processadas
pelo programa ao longo do tempo. O programa deve prever que pode haver várias mensagens na fila e deve
processar todas até que a fila seja esgotada.
1.8 Para a gravação de apenas uma mensagem, usar a chamada MQI MQPUT1.
A chamada MQI MQPUT1 equivale a um open, put e close intrínsecos ao comando e evitará tanto a
codificação de todos esses comandos, quanto a sua eficiência é maior do que a soma desses comandos
emitidos separadamente. Assim, essa chamada é recomendada para a gravação de apenas uma mensagem.
Para gravação em lote de várias mensagens, o melhor é usar a chamada MQPUT, depois de abrir a fila para
gravação.
1.9 Uso da opção FAIL_IF_QUIESCING
Em algumas situações, é necessário fazer o shutdown do MQ. Quando o comando de shutdown é emitido, o
MQ entra em estado de quiescing, e não aceita conexões de novas aplicações. As aplicações que estão sendo
executadas deveriam terminar imediatamente para que o processo de shutdown possa terminar. Para que as
aplicações sejam notificadas que o sistema está em processo de shutdown, a opção FAIL_IF_QUIESCING
deve ser especificada para as APIs que aceitam essa opção. Aplicações que não tem essa opção especificada
continuarão o seu processamento até o seu término. Essa situação pode levar um período de tempo
relativamente longo e impedirá que o processo de shutdown do MQ termine. Se isso acontecer, o operador
poderia emitir um comando de immediate shutdown, para forçar o término imediato do MQ. Pode ser
necessário, nesse caso, cancelar as aplicações que não usam a opção FAIL_IF_QUIESCING, havendo então
a possibilidade de haver problemas de integridade de dados, tornando custosa a recuperação desses dados.
Assim, é altamente recomendável que as aplicações usem a opção FAIL_IF_QUIESCING pelo menos nas
APIs MQOPEN e MQGET.
1.10 Uso de unidades de trabalho (Local Units of Work - LUW).
O processamento de uma aplicação deve sempre ser feita dentro de uma unidade de trabalho. As alterações
que a aplicação faz em recursos do ambiente não são efetivadas até que a unidade de trabalho termine.
É possível efetivar as alterações em filas provocadas pelas APIs GET e PUT fora de uma unidade de
trabalho. Porém, para que a coordenação entre os outros recursos do ambiente e o MQ exista, é necessário
que as ações com o MQ contenham as opções referentes ao syncpoint:
• MQPMO_SYNCPOINT
• MQGMO_SYNCPOINT
1.11 Uso de Backout Count e fila para poder eliminar mensagens que ficam dando erro
quando processadas por problemas de campos.
É possível haver mensagens que contém erros de dados em seus campos, ocasionando um abend na
aplicação. Quando isso acontece numa unidade lógica de trabalho, há um rollback no processamento e a
mensagem retorna para a fila, para ser a próxima a ser lida. Quando a aplicação é restartada, a mensagem

é novamente lida e o abend acontece novamente, fazendo com que a mensagem volte para a fila para ser a
primeira a ser lida novamente. Isso pode se tornar um ciclo infinito.
Quando uma mensagem é lida em uma LUW e há um rollback, fazendo com que a mensagem volte para
a fila, o campo BackoutCount no cabecalho da mensagem (MD) é incrementado de 1. Isto indica que a
mensagem foi lida e foi retornada à fila.
Cada fila pode especificar um limite para o BackoutCount e uma fila para a qual as mensagens que
ultrapassarem esse limite devam ser movidas. Essas ações não são automáticas e devem ser executadas pelas
aplicações que usam as filas.
Após abrir uma fila para input, a aplicação deve emitir o comando Inquire para obter o limite do
BackoutCount e o nome da fila para a qual as mensagens devem ser movidas. Assim, ao ler uma mensagem
da fila, a aplicação deve comparar o valor do campo BackoutCount da mensagem com o valor limite da fila.
Se o valor do BackoutCount exceder o limite da fila, a aplicação deve gravar a mensagem na fila de Backout
para posterior processamento. Esse procedimento impede que uma mensagem com erro provoque o não
processamento das demais mensagens da fila.
1.12 Uso de mensagens persistentes apenas quando necessário.
Mensagens definidas como persistentes são também gravadas no log do MQ e assim podem sobreviver a
falhas do sistema ou a restarts do Queue Manager. Mensagens não persistentes não sobrevivem a um restart
do QM e são perdidas nessa situação.
Embora a definição de persistente para uma mensagem pareça ser a melhor situação, é preciso avaliar se
há a necessidade de se definir essa característica, uma vez que ela acarreta a sua gravação no log antes da
mensagem ser colocada na fila.
Assim, é recomendável que a opção pela persistência da mensagem seja codificada explicitamente na
aplicação, uma vez que o default é Queue_defined e dependerá de como a fila foi definida, podendo não
atender aos requisitos da mensagem, veja a Figura 29 abaixo:

Figura 29. Uso de mensagens persistentes – Curso WM100 / VM1001.0
O campo Persistência no cabeçalho de mensagem (MQMD) pode ser definido na programação do aplicativo
com as seguintes constantes providas pelo MQ:
• MQPER_NOT_PERSISTENT - para que a mensagem seja não persistente
• MQPER_PERSISTENT - para que a mensagem seja não persistente
• MQPER_PERSISTENCE_AS_Q_DEF – a mensagem herda a característica de persistência padrão da
fila (DEFPSIST), definido pelo administrador.
Quando as mensagens são colocadas em uma fila com persistência, no momento de reinicialização, o
gerenciador de filas recupera as mensagens pelos seus logs. Ao mesmo tempo, todas as mensagens que
foram colocadas como não-persistente são explicitamente excluídas na reinicialização. O MQ V6 introduziu
a opção para tentar recuperar mensagens não persistentes em filas designadas nos gerenciadores de filas
distribuídos (não para o z/OS). O parâmetro usado na definição da fila é NPMCLASS(HIGH).
Portanto, se uma mensagem é crítica e não há maneira simples de recriá-la, o desenvolvedor deve definir
explicitamente a persistência para a mensagem ou, se a fila foi definida com uma DEFPSIST (YES), o
programa pode permitir que o padrão de persistência, tal como definido para a fila, possa ser usado.
1.13 Uso de filas dinâmicas.
Filas dinâmicas é um recurso importante do WMQ, permitindo a criação dinâmica de filas por uma
aplicação. Elas podem ser permanentes ou temporárias.
Para as filas permanentes, é recomendável o uso de nomes padrões, para que o controle e manutenção delas
sejam facilitados.
Para as filas temporárias, a recomendação é que não se planeje gravar nelas mensagens persistentes.

1.14 Definição do tipo de mensagem.
O MQ não requer o uso do tipo de mensagem como atributo obrigatório ao se gravar uma mensagem.
Porém o uso explícito desse campo no MD pode ajudar a determinar como uma mensagem pode ser
processada, bem como o gerenciamento das mensagens de uma fila. Os tipos de mensagens podem ser
datagrama, request, reply e report, e como uma fila pode conter mais de um tipo, dependendo do desenho
das aplicações, o tipo de mensagem pode ajudar a determinar como a aplicação manipulará as mensagens
lidas.
1.15 Uso do período de expiração da mensagem.
Para mensagens cujo conteúdo perde o seu significado com o passar do tempo, é importante usar o recurso
do MQ para tornar a mensagem descartável, determinando o período de expiração da mensagem. Mensagens
expiradas são descartadas pelo Queue Manager. Essa informação é indicada na gravação, no MD da
mensagem.
1.16 Uso de índices para melhor performance numa leitura randômica de fila.
O MQ em z/OS permite que índices sejam criados em filas locais para que a leitura randômica de mensagens
numa fila tenha um melhor desempenho. Eles são criados pelo Administrador do WMQ segundo critérios de
leitura das aplicações que usam as filas.
Os índices podem ser criados por: MsgID, CorrelID, GroupID e MsgToken. Os índices mais comuns são os
para MsgID e CorrelID.
1.17 As conexões ao MQ devem ser fechadas e desligadas corretamente
É aconselhável que os aplicativos fechem as filas e desconectem as conexões antes de serem encerrados.
Não fazê-lo, especialmente quando as conexões de clientes estão em uso, pode resultar em queda das
conexões, provocando o aumento do consumo de recursos, podendo bloquear novas conexões.
1.18 Diferentes características dos diversos clientes MQ
Nem todos os clientes MQ fornecem a mesma funcionalidade. Ao decidir qual cliente MQ usar, é preciso ter
em mente os seguintes pontos:
• Compreender as opções de conexão, como cliente de ligação, de ligação de servidor, modos de clientes
geridos na ligação, e as limitações do cliente para C, JMS, Java ou aplicações do ,NET. Por exemplo,
cliente MQ para .Net não tem suporte a criptografia de canal SSL, transações XA, e compressão do
canal. Outro exemplo é que o cliente Java MQ suporta apenas o transporte TCP/IP e não lê nenhuma
das variáveis de ambiente MQ na inicialização. Nesta situação, todas as variáveis ambiente, incluindo a
informação de conexão são armazenados na classe MQEnvironment no arquivo qm.ini.
• Problemas de rede e de firewall podem causar a falha nas conexões MQ, e podem ser confundidos com
problemas de MQ.
• Atribuir conexões nas suas aplicações, definições de canais exclusivos, de modo que os
administradores podem facilmente determinar qual aplicativo está se conectando, bem como
implementar opções de segmentação de segurança adicionais.

• Em sistemas de produção, o canal SYSTEM.DEF.SVRCONN deve ter um utilizador sem o privilégio
adicionado ao campo MCAUSER e, potencialmente, ser colocado num estado stopped. Aplicativos não
devem ser configurados para usar este canal, e ao contrário, devem usar um próprio canal. Além de ser
uma boa prática não utilizar objetos do sistema, este canal é um risco de segurança conhecido.
• Na definição de um valor de atributo MCAUSER, é aconselhável colocar o valor entre aspas simples
para evitar problemas com maiúsculas e minúsculas em plataformas distribuídas.
1.19 Uso das melhores práticas de segurança
Em sistemas distribuídos, o grupo mqm fornece acesso administrativo a todos os recursos MQ em um
sistema. Assim, é aconselhável limitar a participação no grupo mqm.
Segurança em MQ pode ser dividida em duas grandes categorias: os consumidores do MQ e administradores
do MQ. Os consumidores normalmente tomam a forma de IDs usados para executar aplicações que se
conectam ao MQ. Administradores são os usuários que precisam de forma interativa consultar ou alterar
configurações do MQ através do ferramental provido pelo MQ (como runmqsc ou utilitários do z/OS). Em
alguns ambientes, as identificações de aplicação por conta (consumidores) às vezes são colocadas no grupo
mqm pela simplicidade. Nessas situações, essas identificações devem ser bloqueadas para que não possa ser
usado o login interativo, uma vez que qualquer usuário que tenha acesso a essas identificações terá controle
administrativo total sobre o MQ.
Uma alternativa é a utilização do WMQ OAM, facilidade setmqaut, para especificar níveis detalhados de
permissões para cada objeto ou recurso do MQ (tais como as filas). Esta técnica dá muito mais controle
granular e é aconselhável, quando viável.
Quanto à autoridade administrativa, onde a segurança e auditoria são uma preocupação, a segurança de
terceiros ou ferramentas de configuração, tais como SupportPac MS0E, deve ser usado para acessar e
alterar configurações do MQ. Na ausência desses controles, apenas os membros da equipe de administração
do MQ devem pertencer ao grupo mqm. Para os outros usuários, devem ser dados menores níveis de
autoridade, o que pode ser concedida através de comandos de OAM nível setmqaut ou através da utilização
de SupportPacs MQ, tais como MS0E.
1.20 Uso de SupportPacs para estender a funcionalidade MQ
O MQ oferece muitos plug-ins para download, chamados MQ SupportPacs, para estender a suas
funcionalidade:
• MS03: Fornece código que exporta todas as configurações do objeto de MQ runmqsc em um formato
que pode depois ser reutilizado para importar (e recriar) as configurações do gerenciador de filas.
Dependendo do ambiente considerado, pode ser vital para backup e recuperação.
• MS0E: Fornece um pacote administrativo que oferece acesso runmqsc e de nível administrativo para
usuários que não são membros do grupo mqm, permitindo-lhes conceder privilégios de uma maneira
muito mais granular.
• MA01: Permite procurar mensagens e, em seguida, movê-las entre filas.
• MO03: Permite mover mensagens para arquivos, e de arquivos, para o transporte de diferentes sistemas
ou para reutilização posterior.

• MS81: Um produto adicional que trabalha em conjunto com o MQ para conexões de túneis através de
firewalls via SSL ou HTTP (S).
• MC91: Alta disponibilidade - Fornece scripts e instruções para a configuração do MQ em sistemas de
alta disponibilidade disponíveis UNIX como HACMP e Sun Cluster.
1.21 Automatizar as mudanças através de scripts MQSC, quando não estiver usando
ferramentas de terceiros para configuração
É aconselhável ter como prática fazer quaisquer alterações nos gerenciadores de filas em comandos runmqsc
na forma de script. Todo o comando que pode ser digitado em um editor de runmqsc também pode ser
escrito em um arquivo para execução posterior. O script pode ser validado antes da sua execução, utilizando
o runmqsc -v <filename. No momento da execução, a saída dos scripts pode ser facilmente capturada em um
arquivo de log para posterior análise. Esta prática irá ajudar a evitar erros e acelerar a execução de mudanças
no tempo de execução.
Um comportamento semelhante é aconselhável também para a plataforma z/OS, para que as alterações feitas
a configurações dos gerenciadores de filas, ou a filas e outros recursos do MQ, possam ficar documentadas e
possam ser facilmente refeitas em caso de necessidade.
2. Programming Model - Exemplos de Uso das MQI
2.1 Exemplos de Programas
• Localizado - <install>toolssamples
• Programas fonts e dois executaveis
• amqsput – modo de ligação – colocar na fila
• amqsputc – modo Cliente
• amqsput qname qmgr.name – colocar a mensagem na fila
• amqsget qname qmgr.name – pegar a mensagem da fila
• amqsbcg qname qmgr.name – browse da fila
2.2 Programa de Envio
MQCONN(QueueManager)
MQOPEN(Queue)
/* Build message */
MQPUT(message, options)
MQCLOSE
MQDISC
2.3 Programa de Recebimento
MQCONN(QueueManager)
MQOPEN(Queue)
MQGET(message, options)
/* Process message */
MQCLOSE

MQDISC
3. Onde é que está? Onde posso encontrar? As informações sobre o MQ.
3.1 Arquivos do Gerenciador de Filas - Queue Manager
3.1.1 Código do MQ
• Código do MQ é mantido separado dos dados do MQ
• A localização varia um pouco de acordo com a plataforma
- AIX® - /usr/mqm
- HP-UX, Linux, Solaris - /opt/mqm
- Windows - O usuário escolhe o diretório onde ficará o código durante a instalação
• A estrutura de diretório é semelhante na maioria das plataformas:
/opt/mqm/
- READMES/
- bin/
- docs/
- eclipse/
- ibm_help/
- ies_30/
- inc/
- java/
- lib/
- lib64/
- licenses/
- maintenance/
- loc/
- samp/
- ssl/
- tivoli/
• Nos sistemas de 64 bits, o MQ fornece bibliotecas de 32 bits e 64-bit
- Muitos dos mesmos nomes de arquivo existem nos diretórios da lib e da lib 64
- As aplicações deverão seguir estritamente as instruções de construção e utilizar as bibliotecas certas
• Windows® apresenta pequenas diferenças
- Os exemplos de cabeçalhos são organizados pela linguagem no diretório tools
- Binários e bibliotecas (arquivos DLL) estão ambas no diretório bin
• Alguns SupportPacs podem adicionar arquivos ou diretórios na árvore
- Normalmente não tem recuros de install/uninstall
- Os clientes precisam acompanhar tais adições manualmente
3.1.2 Dados do MQ
• Em todos os sistemas UNIX® o diretório de dados é /var/mqm
/var/mqm/
mqs.ini

service.env
config/
conv/
errors/
exits/
exits64/
log/
qmgrs/
tivoli/
trace/
• Dados do gerenciador de filas estão em duas árvores de diretório separados
- O diretório log/ contém apenas os logs de recuperação
- O qmgrs/ contém todo o resto
• Informações da configuração do Gerenciador de Filas
• Todos os canais e outras definições de objectos
• Arquivos da fila de mensagens e dados de clientes
• O arquivo mqs.ini contém uma lista de todos os gerenciadores de filas
• O arquivo service.env contém variáveis de ambiente para os serviços iniciados pelo MQ
3.1.3 Logs do Gerenciador de Filas - Queue Manager
• Recuperação de registros de logs e todas as transações e de trabalho do gerenciador de filas
• Para um gerenciador de filas FRIES estes são normalmente encontrados em:
/var/mqm/log/FRIES/
amqhlctl.lfh
active/
S0000000.LOG
S0000001.LOG
S0000002.LOG
S0000002.LOG
S0000003.LOG
- amqhlctl.lfh
• Comumente referido no "cabeçalho do arquivo de log"
• Contém metadados crítico sobre os logs de recuperação
- S0000000.LOG - S9999999.LOG
• Essas extensões de arquivos de log contêm os registros de log
• O programa dmpmqlog pode exibir o seu conteúdo
3.1.4 Arquivos do Gerenciador de Filas - Queue Manager
• O diretório do gerenciador de filas contém vários arquivos:
-/var/mqm/qmgrs/FRIES/
qm.ini
qmstatus.ini
amqalchk.fil
- qm.ini

• Arquivo de configuração principal do usuário para o gerenciador de filas
• Documentado no System Administration Guide
• No Windows é mantida esta informação no Registro
- qmstatus.ini
• Automaticamente gerado o arquivo de configuração do gerenciador de filas
• Este arquivo é gerenciado pelo MQ e permite a auto-ajuste
• Não edite este arquivo, exceto sob a orientação da IBM
- amqalchk.fil
• O "arquivo de verificação" contém log de metadados recuperação
• Este arquivo fornece um link entre os dados gerenciador de filas e os logs
3.1.5 Diretórios de Objetos
• Alguns dos diretórios mais importantes incluem:
/var/mqm/qmgrs/FRIES/
authinfo/
channel/
clntconn/
listener/
namelist/
procdef/
queues/
qmanager/
QMANAGER
QMQMOBJCAT
services/
- qmanager
• Contém o catálogo de objetos, que lista todos os objetos no gerenciador de filas
- authinfo, namelist, procdef, queues
• Contêm arquivos para cada tipo de objeto MQ (ver o programa dspmqfls)
- channel, clntconn, listener, services
• Contém arquivos de objetos incluindo os canais e programas de serviço
3.1.6 Error Logs
• Logs de erro do Gerenciador de Filas
/var/mqm/qmgrs/FRIES/errors/
AMQERR01.LOG
AMQERR02.LOG
AMQERR03.LOG
• Erros
- Informações e mensagens de erro são anexados ao AMQERR01.LOG
- Quando estão cheios, os logs são é feito "roll over" e AMQERR03.LOG é descartado
3.2 Processos do Gerenciador de Filas
3.2.1 Comandos do Gerenciador de Filas

Figura 30. Detalhes das sintaxes do manual System Administration Guide
3.2.2 Lista de commandos:
• amqzxma0 – Execução e Controle
• amqzfuma - Object Authority Manager (OAM)
• amqzmuc0 - Processo de Utilidades Criticos
• amqzmur0 – Processo de Utilidade e Reniciavel
• amqrrmfa – Processo de Gerenciamento de Repositório
• amqzmgr0 – Gerenciamento de Processo de Serviço
• amqzlaa0 – Process Agente
• runmqchi – Iniciador de Canal
• amqpcsea – Servidor de Comando
• runmqlsr - Listener
• amqcrsta – Resposta TCP/IP
• amqrmppa – Processo de Pooling no Canal
3.2.3 Programas de Serviços
• amqldmpa – Gera dump dos blocos de controle internos do queue manager
- Este programa deve ser executado apenas sob direção da IBM
• amqoamd – Lista o conteúdo da SYSTEM.AUTH.DATA.QUEUE
- Pode gerar comandos setmqaut para os objetos do gerenciado de filas
• amqrdbgm – Debugger online para processos de canal MQ
• amqrfdm – Lista informações do cache do repositório do cluster
• ffstsummary – Gera um resumo cronológico dos arquivos FDC
• mqrc – Lista mensagens do MQ a partir dos códigos de retorno
• dspmqver – Mostra a versão do código MQ instalado no sistema
3.2.4 Programas Adicionais

• amqiclen – Limpa os recursos IPC depois do término do queue manager
• amqicdir – Verifica e corrige permissões nos diretórios de dados do MQ
• amqltmc0 – Transação para trigger monitor para o TXSeries® (ie. CICS®)
• amqsstop – Encerra todas as conexões para o MQ de um dado processo
• amqxmsg0 – Permite a programas sem privilégios gravar em MQ error logs
• amqzslf0 – Encerra todos os canais de um gerenciador de filas
• reset_iconv_table – Reinstala arquivos de conversão no HP-UX
- Algumas manutenções do HP-UX regravam o arquivo config.iconv
3.2.5 Programas Windows
• amqldbgn– Gera diagnósticos FDCs dos processos MQ
• amqmdain– Interface de linha de comando para a configuração de serviços MQ
• amqtcert– Transfere certificados SSL do Windows para GSKit
• amqtbrn– Executa o MQ task bar icon
• amqsvc– Daemon de serviço MQ
• amquregn – Programa para dump do Registry key
- Run it as: amquregn amquregn.ctl
• amqxssvn– Servidor do Common services subpool shared memory
• amqztrcn– Daemon do trace do MQ
• setmqscp– Permite a canais de clientes serem publicados no Active Directory
3.3 Queue Manager Shared Resources
3.3.1 O que é um Subpool?
• Um subpool é um grupo de recursos IPC (Interprocess Communication) compartilhado pertencentes ao
MQ
• O MQ organiza informações em subpools baseado em vários atributos
- Visibilidade – Os dados disponíveis são para todo o systema ou apenas para um gerenciador de filas?
- Persistência – Os dados desaparecem quando o gerenciador de filas é encerrado?
- Autoridade – Quais processos são permitidos para acessar os dados?
• Os processos podem se conectar a múltiplos subpools ao mesmo tempo
• Cada máquina tem um subpool não associado com qualquer gerenciador de filas
- System Subpool – Usado pelos processos de canais durante o startup
• Cada gerenciador de filas tem três subpools pertencentes a ele
- IPCC Subpool – Usado para comunicação com aplicações
- Queue Manager Subpool – Guarda dados privados do gerenciador de filas
- Persistent Queue Manager Subpool – Permanece mesmo depois do endmqm
3.3.2 Diretórios de Subpool
• O MQ cria arquivos num conjunto de diretórios para cada subpool
esem/ Event semaphores
isem/ Internal semaphores
msem/ Mutex semaphores
ssem/ Socket semaphores

shmem/ Shared memory
• Estes arquivos são usados para acessar os recursos IPC para o subpool
• Num sistema com gerenciador de filas FRIES estes diretórios estão em:
/var/mqm/qmgrs/@SYSTEM
/var/mqm/qmgrs/FRIES
/var/mqm/qmgrs/FRIES/@ipcc
/var/mqm/qmgrs/FRIES/@qmpersist
3.4 MQ e Java
• WMQ é apropriado de maneira ideal para OO
- Gerenciadores de fila aos quais se podem conectar desconectar
- Mensagens que podem ser postas em filas
- Filas, Gerenciadores de Filas, etc, tem propriedades que podem ser pesquisadas
• C++, COM, .NET e Java implementam interfaces levemente diferentes
- JMS (XMS) é completamente diferente
• As interfaces para .NET e Java são bem semelhantes
• A primeira letra (caixa alta e caixa baixa) difere entre Java e .NET
- myQmgr.connect() - myQmgr.Connect()
3.4.1 Conectando ao Gerenciador de Filas
• Requerido como primeiro passo
- A conexão ocorre quando um objeto MQQueueManager é construído
• Para uma aplicação no papel de Server essa ação deve ser comum
- O nome do gerenciador de filas é suprido com o um parâmetro
• Uma string vazia ("") ou nula indica o uso do gerenciador de filas default
• Opcionalmente, podem ser dadas opções
- Permite o uso de fastpath ou de conexão padrão
MQQueueManager myQmgr = new MQQueueManager("QM")
3.4.2 Conectando ao Gerenciador de Filas – Client
• O cliente precisa especificar as informações para a conexão
- Nome do Canal
- Tipo de Transporte
- Nome da conexão (ie, endereço ip)
ImqQueueManager myQmgr;
ImqChannel myChannel = new ImqChannel ;
myChannel.setChannelName("SYSTEM.DEF.SVRCONN");
myChannel.setTransportType( MQXPT_TCP );
myChannel.setConnectionName("bower.dfw.ibm.com");
myQmgr.setChannelReference(myChannel);
myQmgr.setName( "QM" );
myQmgr.connect();
3.4.3 Abrindo uma Fila

• Geralmente uma aplicação abre uma fila e então executa várias ações nesta fila
MQQueue myQueue = myQmgr.AccessQueue("QL", options)
• As seguintes opções controlam a abertura da fila
- MQC.MQOO_OUTPUT – abrir para gravação (put)
- MQC.MQOO_INPUT_SHARED – abrir para leitura compartilhada (get)
- MQC.MQOO_INPUT_EXCLUSIVE – abrir para leitura exclusiva
3.4.4 Construindo uma Mensagem
• Um objeto MQMessage contém todas as informações sobre uma mensagem individual
myMsg = new MQMessage()
• Constuída com o cabeçalho 'default' MQMD e sem dados
- myMsg.Persistence = MQC.MQPER_PERSISTENT
- myMsg.Priority = 5
- myMsg.expiry = 3600 (10ths of a second)
- myMsg.format = MQC.MQFMT_STRING
• Inserindo dados
- Os métodos Write* inserem dados na posição corrente na mensagem
myMsg.writeInt(1234)
myMsg.writeString("hello)
myMsg.writeByte(12)
myMsg.writeString("world")
• Os dados resultantes como dados da mensagem neste exemplo
000004D2 48656C6C6F 0C 576F726C64
3.4.5 Gravando uma Mensagem
• Há várias formas de gravar uma mensagem numa fila
- Numa fila aberta para gravação (output)
myQueue.put(myMsg, myPMO)
myQueue.put(myMsg)
- Numa fila não aberta (ie, PUT1)
myQmgr.put("QL", "", myMsg, myPMO)
3.4.6 Lendo uma Mensagem
• Quando uma mensagem de uma fila precisa ser lida, a aplicação deve prover as opções adequadas para
esta leitura
myGMO = new MQGetMessageOptions()
- A estrutura GMO aceita várias opções para a leitura. As mais comuns são:
MQC.MQGMO_FAIL_IF_QUIESCING
MQC.MQGMO_WAIT, MQC.MQGMO_NOWAIT
MQC.MQGMO_SYNCPOINT
MQC.MQGMO_ACCEPT_TRUNCATED_MSG
- Não é possível ler uma mensagem de uma fila que não foi aberta. A fila deve ser aberta para leitura
(input)

• Passos
- Criar um MQMessage para receber a mensagem
myMsg = new MQMessage()
- Criar as opções para o MQMessage
myGMO = new MQGetMessageOptions()
- Ler a mensagem
myQueue.get(myMsg, myGMO)
3.4.7 Extraindo dados de uma mensagem
• Os métodos Read* lêem dados da posição corrente na mensagem
• skipBytes e seek podem mover a posição corrente manualmente
• Usando como exemplo os dados da mensagem criada acima:
000004D2 48656C6C6F 0C 576F726C64
myMsg.readInt() returns an integer 1234
myMsg.readString(5) returns a string "hello"
myMsg.readUnsignedByte() returns an integer 12
myMsg.readString(5) returns a string "world"
3.4.8 Encerrando o trabalho
• Quando o trabalho com uma fila terminar, é uma boa prática fechá-la
myQueue.close
• Quando o trabalho com o Gerenciador de Filas terminarem, é sempre recomendável fazer a desconexão
da aplicação com o Gerenciador
myQmgr.disconnect()
4. 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_parte_ii

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mq conceitos melhores_praticas_parte_ii

Semelhante a Mq conceitos melhores_praticas_parte_ii (20)

Mais de MoisesInacio

Mais de MoisesInacio (8)

Mq conceitos melhores_praticas_parte_ii