WEBSPHERE MQ MELHORES PRÁTICAS – PARTE II

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

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

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



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

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



02/Nov/2012

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

1. 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).
  • 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>\tools\samples
  • 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)

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

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

 


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

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

Elija su nombre para mostrar



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=843891
ArticleTitle=WEBSPHERE MQ MELHORES PRÁTICAS – PARTE II
publish-date=11022012