 |
| Bellacosa Mainframe uma carona nos meandros dos ibm mq |
☕ Um Café no Bellacosa Mainframe
IBM MQ sem Mistérios para Programadores COBOL
Quando um Programador Descobre que a Mensagem Não Precisa Viajar de Carona pela Galáxia — Ela Pode Entrar numa Fila, Sobreviver ao Fim do Mundo e Chegar ao Destino com Protocolo de Entrega
Existe uma frase muito conhecida entre os viajantes experientes da galáxia computacional:
Não entre em pânico. Verifique primeiro se a mensagem ainda está na fila.
Naturalmente, essa frase não aparece em nenhum manual oficial da IBM, talvez porque os manuais técnicos normalmente preferem expressões menos tranquilizadoras, como:
AMQ9208E: Error on receive from host.
Ainda assim, o princípio permanece válido.
Em algum ponto da carreira, todo programador COBOL descobre que escrever o programa é apenas uma parte relativamente pequena do problema. A outra parte consiste em convencer o restante do universo corporativo a receber os dados produzidos pelo programa.
Você pode calcular corretamente o valor de uma transferência bancária.
Pode atualizar o saldo no Db2.
Pode montar um registro de 500 bytes com precisão quase artística.
Pode validar datas, CPFs, códigos de agência e números de conta.
Mas surge então a pergunta que assombra arquitetos, programadores, analistas de produção e operadores desde os primórdios da computação distribuída:
Como enviar essa informação para outro sistema sem depender de ele estar funcionando exatamente naquele momento?
É aqui que entra o IBM MQ.
Ele é o carteiro confiável da arquitetura corporativa.
Não é o carteiro que toca a campainha, espera vinte segundos, joga o pacote por cima do muro e marca no sistema que ele foi recebido por “Morador”.
O IBM MQ é mais parecido com um mensageiro interestelar que guarda a encomenda em um cofre, atravessa panes, reinicializações, falhas de rede, indisponibilidades, atualizações de sistema e mudanças de turno até conseguir realizar a entrega.
Para o programador COBOL iniciante, compreender MQ significa aprender uma das ideias mais importantes da integração de sistemas:
O sistema que envia uma mensagem não precisa esperar pelo sistema que vai recebê-la.
Essa pequena ideia sustenta bancos, companhias aéreas, seguradoras, redes varejistas, órgãos públicos, sistemas de cartões, plataformas logísticas e uma considerável quantidade de computadores que, por razões administrativas, ainda acreditam estar vivendo em fusos horários diferentes.
Prepare seu café, localize sua toalha, abra o editor COBOL e embarque. A fila está pronta.
Capítulo 1 — O problema de conversar diretamente
Imagine dois sistemas.
O primeiro será chamado de Sistema A, porque arquitetos gostam de começar pelo A.
O segundo será chamado de Sistema B, porque chamar o segundo sistema de Sistema Faria Lima exigiria mais documentação.
O Sistema A precisa enviar uma solicitação ao Sistema B.
Sem MQ, a comunicação poderia acontecer diretamente:
SISTEMA A --------------------> SISTEMA B
O Sistema A abre uma conexão.
Envia uma requisição.
Espera a resposta.
O Sistema B processa.
Retorna o resultado.
Quando tudo funciona, essa arquitetura parece perfeita.
Também parece perfeita uma viagem de carro em uma estrada vazia, durante o dia, com combustível suficiente, motor revisado e nenhuma criatura de três cabeças atravessando a pista.
O problema é que sistemas corporativos raramente operam em condições perfeitas.
O Sistema B pode estar:
indisponível;
reiniciando;
em manutenção;
congestionado;
com a CPU elevada;
esperando uma tabela Db2 ser liberada;
sofrendo timeout;
preso em um loop;
com o certificado expirado;
acessível pela rede, mas incapaz de responder;
funcionando normalmente, segundo o painel de monitoramento, embora ninguém consiga utilizá-lo.
Quando A fala diretamente com B, A depende da disponibilidade imediata de B.
Isso é chamado de acoplamento temporal.
Os dois sistemas precisam estar ativos ao mesmo tempo.
O emissor precisa aguardar.
O receptor precisa responder dentro de determinado prazo.
A rede precisa permanecer estável durante a comunicação.
Em um processo simples, isso pode ser aceitável.
Em uma operação crítica, pode ser perigoso.
Considere uma transferência bancária de R$ 5.000.
O sistema envia a operação.
A conexão cai antes de receber a confirmação.
Agora surge o maior terror da computação distribuída:
A transferência aconteceu ou não?
Tentar novamente pode duplicar o pagamento.
Não tentar novamente pode perder a transação.
A tela do cliente permanece girando.
O usuário clica outra vez.
O operador abre um chamado.
O analista examina os logs.
O gerente pergunta se já existe previsão.
A previsão depende de descobrir se a primeira tentativa chegou.
Nesse momento, alguém pronuncia uma frase ancestral:
“Parece que foi problema de comunicação.”
Essa frase é tecnicamente possível, socialmente conveniente e praticamente inútil.
Capítulo 2 — A chegada do mensageiro confiável
O IBM MQ muda o desenho da comunicação.
Em vez de A entregar diretamente para B, A entrega a mensagem para uma fila administrada pelo MQ:
SISTEMA A ---> FILA MQ ---> SISTEMA B
O Sistema A não precisa conversar diretamente com o Sistema B.
Ele conversa com o Queue Manager.
Se a operação de colocação da mensagem for concluída com sucesso, A sabe que o MQ assumiu a responsabilidade por ela.
A mensagem permanece na fila até que B esteja disponível para consumi-la.
Se B estiver offline, a mensagem espera.
Se B estiver lento, a mensagem espera.
Se B estiver processando outras solicitações, a mensagem espera.
Se B estiver passando por manutenção porque alguém decidiu atualizar 47 componentes em uma sexta-feira, a mensagem também espera, embora provavelmente faça isso com certa desaprovação.
Essa espera não é um erro.
Ela faz parte do projeto.
Essa é uma mudança fundamental para quem está acostumado apenas com chamadas diretas.
No modelo síncrono:
A chama B
A espera B
B responde
A continua
No modelo assíncrono:
A entrega a mensagem ao MQ
A continua trabalhando
B consome a mensagem quando puder
O MQ introduz uma camada intermediária.
Essa camada reduz a dependência entre os sistemas.
O emissor não precisa saber exatamente quando o receptor processará a mensagem.
O receptor não precisa estar disponível no momento do envio.
É o início do desacoplamento.
Capítulo 3 — O que é uma mensagem?
Uma mensagem é uma unidade de informação transportada pelo MQ.
Ela pode representar:
um pedido;
uma autorização de pagamento;
uma transferência bancária;
uma reserva;
uma solicitação de emissão de nota fiscal;
uma atualização cadastral;
uma movimentação de estoque;
uma notificação;
um lote de registros;
um evento de negócio;
uma instrução para outro sistema.
Para o programador COBOL, a mensagem frequentemente se parece com uma área de dados comum:
01 WS-MENSAGEM.
05 WS-TIPO-OPERACAO PIC X(02).
05 WS-NUMERO-CONTA PIC 9(10).
05 WS-VALOR PIC S9(11)V99 COMP-3.
05 WS-DATA-OPERACAO PIC 9(08).
05 WS-HORA-OPERACAO PIC 9(06).
05 WS-CODIGO-ORIGEM PIC X(08).
Mas existe uma diferença importante.
O receptor precisa conhecer o formato.
Se o emissor enviar:
TIPO + CONTA + VALOR + DATA
e o receptor interpretar:
CONTA + TIPO + DATA + VALOR
a mensagem chegará perfeitamente, mas o resultado será um desastre de alta qualidade.
O MQ garante o transporte.
Ele não adivinha o significado do conteúdo.
Essa distinção é essencial:
MQ garante que os bytes sejam entregues. A aplicação garante que os bytes façam sentido.
Por isso, integrações baseadas em MQ precisam de contratos de mensagem.
Esses contratos devem definir:
tamanho;
campos;
tipos;
codificação;
versão;
obrigatoriedade;
valores válidos;
tratamento de erros;
compatibilidade entre versões.
No mundo COBOL, isso pode ser documentado por meio de copybooks compartilhados.
Exemplo:
COPY PEDIDO01.
O emissor usa o copybook.
O receptor usa o mesmo copybook.
O problema começa quando o emissor altera o copybook e esquece de avisar o receptor.
A partir desse instante, nasce uma entidade conhecida como incidente de integração, que se alimenta de campos deslocados e costuma aparecer fora do horário comercial.
Capítulo 4 — O Queue Manager, gerente da estação espacial
O principal componente do IBM MQ é o Queue Manager.
Ele administra os objetos, a segurança, a recuperação e o fluxo das mensagens.
Pense nele como o administrador de uma estação espacial dedicada ao transporte de pacotes.
O Queue Manager controla:
filas;
canais;
logs;
conexões;
transações;
persistência;
segurança;
recuperação;
entrega de mensagens;
comunicação com outros Queue Managers.
Uma aplicação não coloca mensagens aleatoriamente no universo.
Ela se conecta a um Queue Manager e solicita acesso a uma fila.
Conceitualmente:
APLICAÇÃO
|
v
QUEUE MANAGER
|
v
FILA
No z/OS, o Queue Manager é uma infraestrutura robusta, integrada ao ambiente operacional, aos mecanismos de segurança e aos recursos de alta disponibilidade.
Ele mantém registros necessários para recuperar mensagens persistentes após falhas.
Também controla transações e acessos concorrentes.
É por isso que uma fila MQ não deve ser confundida com uma simples tabela improvisada contendo status “N”, “P” e “E”.
Uma tabela pode até implementar um mecanismo semelhante, mas você terá de construir:
bloqueios;
concorrência;
confirmação;
recuperação;
retry;
controle transacional;
ordenação;
segurança;
expiração;
gerenciamento;
monitoramento;
tratamento de mensagens problemáticas.
Depois de alguns meses, você terá criado um pequeno sistema de mensageria.
Provavelmente pior.
Talvez mais caro.
Certamente acompanhado por uma documentação chamada fluxo_novo_final_v7_corrigido_definitivo.pptx.
Capítulo 5 — O que é uma fila?
Uma fila é uma estrutura onde as mensagens são armazenadas até serem consumidas.
Em sua forma mais simples:
ENTRADA
|
v
+-----------------------------+
| MSG 001 |
| MSG 002 |
| MSG 003 |
+-----------------------------+
|
v
SAÍDA
Normalmente, pensamos em uma fila como FIFO:
First In, First Out.
A primeira mensagem a entrar tende a ser a primeira a sair.
Entretanto, a ordem real de recuperação pode ser influenciada por fatores como:
prioridade;
critérios de seleção;
múltiplos consumidores;
agrupamento;
sincronização;
comportamento da aplicação.
Portanto, dizer que “MQ sempre garante a ordem absoluta em qualquer arquitetura” seria uma simplificação perigosa.
Em uma fila simples, com um consumidor e mensagens de mesma prioridade, o comportamento FIFO é natural.
Mas imagine três consumidores lendo simultaneamente:
FILA
|
+--> CONSUMIDOR 1
|
+--> CONSUMIDOR 2
|
+--> CONSUMIDOR 3
As mensagens podem ser retiradas em ordem, porém o término do processamento pode acontecer em outra sequência.
A mensagem 2 pode terminar antes da mensagem 1.
Isso não significa que o MQ falhou.
Significa que processamento paralelo produz resultados paralelos.
Quando a ordem de negócio é obrigatória, a arquitetura precisa considerar:
um único consumidor;
grupos de mensagens;
afinidade;
particionamento por chave;
controle de sequência na aplicação;
confirmação do passo anterior.
A regra é simples:
Ordem técnica e ordem de negócio não são necessariamente a mesma coisa.
Capítulo 6 — Persistência: a mensagem que se recusou a morrer
Uma mensagem pode ser persistente ou não persistente.
Mensagem persistente
É projetada para sobreviver a falhas e reinicializações, conforme a configuração e o comportamento do ambiente.
É adequada para operações críticas:
pagamentos;
transferências;
pedidos;
emissão fiscal;
autorizações;
atualizações financeiras.
Mensagem não persistente
Pode ser usada quando desempenho é mais importante e a perda ocasional é aceitável.
Exemplos possíveis:
telemetria descartável;
atualização temporária;
informação de baixa criticidade;
eventos que podem ser recriados.
O erro clássico é escolher mensagem não persistente porque ela é mais rápida, sem perguntar se a empresa aceita perder a informação.
Imagine a seguinte reunião:
— Conseguimos melhorar o desempenho em 18%.
— Excelente. Como?
— As mensagens agora podem desaparecer durante uma falha.
Essa reunião tende a terminar com uma breve pausa contemplativa.
A persistência envolve gravação e uso de logs de recuperação.
Existe um custo de desempenho.
Mas esse custo compra confiabilidade.
Em sistemas críticos, a pergunta não deve ser apenas:
Quantas mensagens por segundo conseguimos processar?
Também deve ser:
Quantas mensagens podemos perder?
Em muitas aplicações financeiras, a resposta aceitável é:
Nenhuma.
Capítulo 7 — Unidade de trabalho e sincronização
Uma das partes mais importantes do MQ é o suporte transacional.
Considere um programa que precisa:
ler uma mensagem;
atualizar uma tabela Db2;
colocar uma nova mensagem em outra fila;
confirmar tudo.
Se o programa retirar a mensagem e falhar antes da atualização, existe risco de perda.
Se atualizar o banco, mas falhar antes de enviar a próxima mensagem, existe inconsistência.
Por isso, essas operações podem participar de uma unidade lógica de trabalho.
A ideia é:
INÍCIO DA TRANSAÇÃO
MQGET
UPDATE DB2
MQPUT
COMMIT
Se tudo funcionar:
COMMIT
As operações são confirmadas.
Se algo falhar:
ROLLBACK
As alterações são desfeitas.
A mensagem original pode voltar a ficar disponível para reprocessamento.
Em COBOL, a lógica conceitual poderia ser:
PERFORM LER-MENSAGEM
IF WS-REASON-CODE = ZERO
PERFORM PROCESSAR-NEGOCIO
PERFORM ATUALIZAR-DB2
PERFORM ENVIAR-RESPOSTA
IF WS-PROCESSAMENTO-OK
EXEC SQL
COMMIT
END-EXEC
ELSE
EXEC SQL
ROLLBACK
END-EXEC
END-IF
END-IF
A implementação exata depende da integração, do ambiente e da coordenação transacional.
O princípio, porém, é universal:
A mensagem só deve desaparecer da fila quando o processamento associado estiver realmente confirmado.
Esse é um dos pilares da confiabilidade do MQ.
Capítulo 8 — “Exactly once” e a verdade menos confortável
A imagem afirma que nada chega duas vezes.
Essa é uma forma didática de apresentar o objetivo do MQ.
Entretanto, em sistemas distribuídos, “exatamente uma vez” exige atenção.
O MQ fornece mecanismos robustos para entrega confiável e processamento transacional, mas a aplicação também precisa ser desenhada corretamente.
Uma mensagem pode ser reapresentada em situações como:
rollback;
falha antes do commit;
recuperação;
reconexão;
incerteza na confirmação;
lógica inadequada da aplicação;
reenvio feito pelo produtor.
Por isso, aplicações críticas devem considerar idempotência.
Idempotência significa que processar novamente a mesma solicitação não produz um efeito duplicado.
Exemplo: cada transferência recebe um identificador único.
ID-TRANSACAO = 202607260000123456
Antes de processar, o sistema verifica:
SELECT STATUS
FROM TRANSACOES
WHERE ID_TRANSACAO = ?
Se já existe como concluída, não debita novamente.
Assim, mesmo que a mensagem seja reapresentada, o efeito financeiro não é duplicado.
Portanto, uma arquitetura confiável combina:
transação MQ;
commit adequado;
identificador único;
idempotência;
validação de duplicidade;
auditoria.
O MQ é um excelente mensageiro.
Mas até o melhor mensageiro da galáxia não pode impedir que o destinatário registre duas vezes o mesmo pacote se a recepção tiver sido programada por alguém que considerou duplicidade uma superstição.
Capítulo 9 — MQPUT e MQGET
Duas operações fundamentais são:
MQPUT: colocar uma mensagem;
MQGET: recuperar uma mensagem.
De maneira simplificada:
PRODUTOR --MQPUT--> FILA --MQGET--> CONSUMIDOR
O produtor cria a mensagem.
O consumidor processa.
Em um programa COBOL com a API MQI, aparecem estruturas e chamadas como:
MQCONN ou MQCONNX;
MQOPEN;
MQPUT;
MQGET;
MQCLOSE;
MQDISC.
Fluxo típico do produtor:
CONECTAR
ABRIR FILA
COLOCAR MENSAGEM
FECHAR FILA
DESCONECTAR
Fluxo típico do consumidor:
CONECTAR
ABRIR FILA
LER MENSAGEM
PROCESSAR
FECHAR FILA
DESCONECTAR
Conceitualmente:
CALL 'MQCONN'
CALL 'MQOPEN'
CALL 'MQPUT'
CALL 'MQCLOSE'
CALL 'MQDISC'
Cada chamada retorna:
completion code;
reason code.
O completion code indica a categoria geral:
sucesso;
aviso;
falha.
O reason code explica o motivo específico.
Nunca ignore esses códigos.
Uma chamada MQ que “aparentemente funcionou” não constitui evidência técnica.
O programador deve registrar informações como:
nome do Queue Manager;
nome da fila;
operação;
completion code;
reason code;
Message ID;
Correlation ID;
data e hora;
identificador de negócio.
Esses dados transformam uma investigação de cinco horas em uma investigação de vinte minutos.
Ou, pelo menos, em uma investigação de cinco horas com melhor documentação.
Capítulo 10 — Message ID e Correlation ID
O MQ possui identificadores importantes no cabeçalho da mensagem.
Message ID
Identifica tecnicamente uma mensagem.
Pode ser gerado pelo Queue Manager.
Correlation ID
Permite relacionar mensagens.
Imagine o modelo request/reply.
O Sistema A envia uma solicitação:
PEDIDO 784512
O Sistema B processa e devolve uma resposta.
Como A saberá qual resposta pertence a qual pedido?
Usando correlação.
SOLICITAÇÃO
MESSAGE-ID = ABC123
RESPOSTA
CORREL-ID = ABC123
Assim, o consumidor pode procurar a resposta relacionada à solicitação original.
Em aplicações de alto volume, isso é essencial.
Sem correlação, receber respostas seria semelhante a entrar em um terminal espacial, ouvir alguém gritar “seu transporte chegou” e embarcar no primeiro veículo disponível.
Pode funcionar.
Mas talvez você termine em um planeta dedicado à contabilidade tributária intergaláctica.
Capítulo 11 — Request/Reply
Embora MQ seja assíncrono, ele também pode implementar solicitação e resposta.
Fluxo:
SISTEMA A
|
| solicitação
v
FILA.REQUEST
|
v
SISTEMA B
|
| resposta
v
FILA.REPLY
|
v
SISTEMA A
A mensagem de solicitação pode indicar:
fila de resposta;
Queue Manager de resposta;
identificador para correlação.
Esse modelo é útil quando A precisa de retorno, mas deseja manter os benefícios da mensageria.
No entanto, é necessário definir timeout.
O Sistema A não pode esperar eternamente.
Em algum momento, ele precisa decidir:
continuar aguardando;
consultar depois;
gerar pendência;
tentar novamente;
informar processamento assíncrono;
encaminhar para intervenção humana.
A ausência de resposta não significa necessariamente que a operação falhou.
Pode significar que a resposta está atrasada.
Esse é outro motivo para utilizar identificadores únicos e consultas de status.
Capítulo 12 — Dead Letter Queue: o setor de achados e perdidos
Nem toda mensagem consegue chegar ao destino.
A fila pode não existir.
O caminho pode estar incorreto.
O destino pode rejeitar.
A mensagem pode expirar.
A configuração pode estar inconsistente.
Nesses casos, mensagens podem ser encaminhadas para a Dead Letter Queue, também chamada de fila de mensagens não entregues.
Pense nela como o setor de bagagens extraviadas da integração.
A mensagem não é simplesmente abandonada.
Ela é armazenada com informações que ajudam a explicar o problema.
A Dead Letter Queue deve ser monitorada.
Criar uma DLQ e nunca verificá-la é como instalar um alarme de incêndio dentro de um armário à prova de som.
O alarme funciona perfeitamente.
Apenas ninguém percebe.
Uma boa operação de MQ deve definir:
quem monitora a DLQ;
com que frequência;
quais alertas são gerados;
como analisar o motivo;
quando reenviar;
quando corrigir dados;
quando descartar;
como registrar evidências.
Capítulo 13 — Backout Queue: a mensagem amaldiçoada
Imagine uma mensagem com conteúdo inválido.
O consumidor lê.
Tenta processar.
Falha.
Faz rollback.
A mensagem volta para a fila.
O consumidor lê novamente.
Falha novamente.
Rollback.
A mensagem volta.
Esse ciclo pode continuar indefinidamente:
LER
FALHAR
ROLLBACK
LER
FALHAR
ROLLBACK
Essa é a chamada poison message, ou mensagem venenosa.
Ela bloqueia ou prejudica o fluxo.
Para tratar esse cenário, pode-se usar controle de backout.
Depois de determinado número de tentativas, a mensagem é movida para uma Backout Queue.
Assim, o restante do processamento continua.
A mensagem problemática fica isolada para investigação.
É o equivalente operacional a retirar da nave uma caixa que emite luz verde, produz ruídos desconhecidos e possui uma etiqueta dizendo:
NÃO ABRIR EM PRODUÇÃO
Capítulo 14 — Filas locais, remotas e de transmissão
O MQ possui diferentes tipos de objetos.
Local Queue
É uma fila real no Queue Manager.
Armazena mensagens localmente.
Remote Queue Definition
É uma definição que representa uma fila localizada em outro Queue Manager.
Ela orienta o MQ sobre o destino remoto.
Transmission Queue
Armazena temporariamente mensagens que serão enviadas para outro Queue Manager.
Fluxo simplificado:
QM_A
|
| Remote Queue
v
Transmission Queue
|
| Channel
v
QM_B
|
v
Local Queue
Esse desenho permite comunicação distribuída.
A aplicação em A não precisa administrar diretamente os detalhes de rede.
Ela coloca a mensagem em uma definição apropriada.
A infraestrutura MQ cuida do encaminhamento.
Essa é uma das razões pelas quais MQ é tão poderoso em grandes empresas: ele fornece uma malha confiável entre plataformas, datacenters e sistemas heterogêneos.
Capítulo 15 — Canais: as rotas entre os mundos
Os channels permitem a comunicação entre Queue Managers ou entre clientes e servidores MQ.
Existem diferentes tipos de canais, cada um com finalidade específica.
Em uma comunicação entre Queue Managers, canais enviam mensagens pelas rotas configuradas.
Uma arquitetura pode envolver:
z/OS
|
| MQ Channel
v
Linux
|
| MQ Channel
v
Cloud
O canal precisa ser:
configurado;
autenticado;
protegido;
monitorado;
recuperado em caso de falha.
A existência de uma fila não significa que a rota esteja saudável.
É possível ter:
mensagens acumuladas na transmission queue;
canal parado;
erro de conexão;
certificado expirado;
endereço incorreto;
bloqueio de firewall;
falha de autenticação;
incompatibilidade de configuração.
Por isso, o analista precisa olhar o fluxo completo.
Não basta perguntar:
A mensagem foi colocada na fila?
Também é necessário perguntar:
Em qual Queue Manager?
Em qual fila?
Foi encaminhada?
O canal estava ativo?
A fila de transmissão acumulou mensagens?
O destino recebeu?
O consumidor retirou?
O processamento confirmou?
Capítulo 16 — IBM MQ no mundo COBOL, CICS e z/OS
No mainframe, o MQ aparece integrado a diferentes tipos de aplicação.
COBOL batch
Um programa batch pode gerar mensagens a partir de:
arquivos sequenciais;
VSAM;
tabelas Db2;
processamento diário;
fechamento contábil;
lote de pagamentos.
Exemplo:
ARQUIVO DE PEDIDOS
|
v
PROGRAMA COBOL
|
v
FILA MQ
|
v
SISTEMA LOGÍSTICO
COBOL CICS
Uma transação CICS pode colocar mensagens sem precisar aguardar todo o processamento posterior.
Exemplo:
CLIENTE CONFIRMA PEDIDO
|
v
CICS VALIDA
|
v
MQPUT
|
v
RESPOSTA AO TERMINAL
A emissão fiscal, separação de estoque e integração logística podem acontecer posteriormente.
Isso melhora a experiência do usuário e reduz dependências.
IMS
Aplicações IMS também podem participar de fluxos integrados via MQ.
Db2
MQ e Db2 podem ser coordenados em transações, dependendo da arquitetura.
Java e sistemas distribuídos
Uma aplicação COBOL pode enviar uma mensagem consumida por Java em Linux.
O receptor não precisa saber que o emissor é COBOL.
O emissor não precisa saber que o receptor roda em contêiner.
Ambos precisam respeitar o contrato.
É assim que tecnologias de gerações diferentes trabalham juntas sem transformar o datacenter em uma guerra civil tecnológica.
Capítulo 17 — MQ não é apenas para sistemas antigos
Algumas pessoas acreditam que MQ é legado.
Essa conclusão costuma vir de duas fontes:
desconhecimento;
apresentações com muitos hexágonos coloridos.
MQ continua relevante porque os problemas que ele resolve continuam existindo.
Redes ainda falham.
Sistemas ainda ficam indisponíveis.
Aplicações ainda precisam de transações.
Pagamentos ainda não podem desaparecer.
Pedidos ainda não devem ser duplicados.
Empresas modernas utilizam IBM MQ com:
containers;
Kubernetes;
Red Hat OpenShift;
APIs;
microserviços;
cloud híbrida;
Java;
Node.js;
Python;
.NET;
aplicações mainframe.
Tecnologia antiga é uma ferramenta que deixou de resolver problemas relevantes.
Tecnologia madura é uma ferramenta que continua resolvendo problemas importantes depois de décadas.
O IBM MQ pertence à segunda categoria.
Capítulo 18 — MQ versus REST
REST é excelente para comunicação síncrona.
Exemplo:
CLIENTE SOLICITA SALDO
|
v
API REST
|
v
RESPOSTA IMEDIATA
O usuário precisa do saldo naquele momento.
MQ é excelente quando o processamento pode ou deve ser desacoplado:
CLIENTE ENVIA PEDIDO
|
v
MQ
|
v
PROCESSAMENTO POSTERIOR
REST e MQ não são inimigos.
Uma arquitetura pode usar os dois:
APP
|
| REST
v
API
|
| MQPUT
v
FILA
|
v
BACKEND
A API recebe a requisição, valida e publica a mensagem.
O backend processa de forma assíncrona.
A resposta inicial pode ser:
{
"protocolo": "784512",
"status": "RECEBIDO"
}
Depois, o cliente consulta o resultado.
Isso é comum em operações que não precisam terminar durante a chamada inicial.
Capítulo 19 — MQ versus Kafka
Kafka e MQ são frequentemente comparados como se somente um pudesse existir.
Na prática, eles resolvem problemas parcialmente diferentes.
IBM MQ
Muito forte em:
entrega confiável de mensagens;
filas de trabalho;
transações;
request/reply;
integração corporativa;
processamento ponto a ponto;
operações críticas.
Kafka
Muito forte em:
streaming de eventos;
retenção de histórico;
replay;
múltiplos consumidores;
pipelines de dados;
grande escala de eventos;
analytics.
Uma empresa pode usar MQ para autorizar um pagamento e Kafka para distribuir o evento de pagamento autorizado para analytics, fraude, marketing e relatórios.
Exemplo:
PAGAMENTO
|
v
IBM MQ
|
v
CORE FINANCEIRO
|
v
EVENTO PUBLICADO
|
v
KAFKA
A pergunta correta não é:
Qual tecnologia é melhor?
A pergunta correta é:
Qual problema estamos tentando resolver?
Essa pergunta, embora simples, tem o curioso efeito de reduzir em 73% o número de diagramas inúteis em reuniões de arquitetura.
Capítulo 20 — Passo a passo mental para investigar problemas
Quando uma integração MQ falhar, não comece culpando a rede.
Também não comece culpando o COBOL.
E, por razões diplomáticas, não comece culpando o fornecedor.
Siga o caminho da mensagem.
Passo 1 — A aplicação gerou a mensagem?
Verifique:
log;
retorno do MQPUT;
completion code;
reason code;
data e hora;
identificação da transação.
Passo 2 — A mensagem entrou na fila?
Verifique a profundidade da fila e os registros de aplicação.
Passo 3 — A mensagem era persistente?
Isso importa em caso de falha ou reinicialização.
Passo 4 — O canal estava funcionando?
Se o destino é remoto, confira:
status do canal;
fila de transmissão;
erros de conexão;
autenticação;
TLS;
rede.
Passo 5 — A mensagem chegou ao Queue Manager de destino?
Verifique a fila local de destino.
Passo 6 — O consumidor estava ativo?
Pode haver mensagens disponíveis, mas nenhuma aplicação consumindo.
Passo 7 — O consumidor leu a mensagem?
Confirme por logs, Message ID, Correlation ID ou identificador de negócio.
Passo 8 — Houve commit?
A mensagem pode ter sido lida e devolvida por rollback.
Passo 9 — Ela foi para uma Backout Queue?
Uma mensagem problemática pode ter sido isolada.
Passo 10 — O negócio foi concluído?
Entrega técnica não significa conclusão funcional.
A mensagem pode ter chegado, mas sido rejeitada por:
cadastro inexistente;
valor inválido;
formato incorreto;
versão incompatível;
regra de negócio;
duplicidade;
data fora do período.
Essa distinção é fundamental:
ENTREGA TÉCNICA ≠ PROCESSAMENTO DE NEGÓCIO
Capítulo 21 — Boas práticas para o Padawan COBOL
1. Verifique todos os retornos
Nunca ignore completion code e reason code.
2. Registre identificadores
Guarde:
Message ID;
Correlation ID;
protocolo de negócio;
fila;
Queue Manager;
timestamp.
3. Defina um contrato de mensagem
Documente:
layout;
versão;
campos;
codificação;
regras;
tamanho máximo.
4. Planeje duplicidades
Use identificadores únicos e processamento idempotente.
5. Trate poison messages
Configure estratégia de backout.
6. Monitore profundidade das filas
Fila crescendo continuamente pode indicar:
consumidor parado;
consumidor lento;
volume inesperado;
erro de processamento.
7. Defina expiração quando fizer sentido
Nem toda mensagem precisa viver para sempre.
Uma cotação válida por cinco minutos talvez não deva ser processada três dias depois.
8. Não use uma única fila para tudo
Separar fluxos facilita:
monitoramento;
segurança;
prioridade;
capacidade;
resolução de problemas.
9. Não coloque senha ou dado sensível sem proteção
Segurança não desaparece porque a mensagem está dentro do datacenter.
10. Teste falhas deliberadamente
Desligue consumidores em homologação.
Interrompa canais.
Simule rollback.
Reinicie componentes.
Observe o comportamento.
Um sistema confiável não é aquele que nunca falhou.
É aquele cujo comportamento durante a falha foi planejado.
Curiosidades do setor galáctico de mensageria
O IBM MQ surgiu originalmente como MQSeries na década de 1990.
Depois foi chamado de WebSphere MQ.
Mais tarde, voltou a uma identidade mais direta: IBM MQ.
O produto atravessou várias eras tecnológicas:
cliente-servidor;
arquitetura distribuída;
SOA;
web services;
APIs;
microserviços;
containers;
cloud híbrida.
Enquanto nomes, padrões e modas mudavam, o problema central permanecia:
Como entregar uma informação importante com confiança?
MQ também é multiplataforma.
Ele permite integrar aplicações rodando em ambientes muito diferentes.
Essa neutralidade tecnológica é valiosa.
Uma mensagem não se importa se foi criada por COBOL, Java ou Python.
Ela apenas deseja ser tratada com respeito, processada corretamente e não abandonada em uma fila sem monitoramento por sete anos.
Easter egg: a resposta fundamental da integração
Segundo uma conhecida tradição literária galáctica, a resposta para a vida, o universo e tudo mais é 42.
No mundo da mensageria, porém, a resposta correta depende do Reason Code.
Se o retorno foi diferente de zero, consultar apenas a filosofia talvez não resolva.
Ainda assim, o número 42 pode aparecer em seu programa:
IF WS-MQ-REASON-CODE = 42
DISPLAY 'A RESPOSTA FOI ENCONTRADA'
END-IF
Não há garantia de que o Queue Manager considere isso uma prática recomendada.
Outro easter egg importante:
Sempre carregue uma toalha.
Mas, em uma sala de servidores, evite colocá-la sobre a saída de ventilação.
Conclusão — Do “espero que tenha chegado” ao “sei onde está”
IBM MQ não é apenas uma fila.
É uma infraestrutura de confiança.
Ele permite que sistemas diferentes troquem informações mesmo quando:
um deles está indisponível;
a rede apresenta falhas;
o processamento demora;
os componentes operam em velocidades diferentes;
existe necessidade de transação;
o ambiente precisa recuperar mensagens após falhas.
Para o programador COBOL, aprender MQ significa ampliar a visão além do programa individual.
Você deixa de pensar apenas em:
ENTRADA
PROCESSAMENTO
SAÍDA
e começa a pensar em:
PRODUTOR
MENSAGEM
FILA
TRANSPORTE
CONSUMIDOR
COMMIT
RECUPERAÇÃO
AUDITORIA
Esse é um passo importante na formação de um profissional mainframe.
O programa COBOL pode estar perfeito.
O JCL pode terminar com MAXCC=0000.
A atualização Db2 pode estar correta.
Mas, se a informação precisa chegar a outro sistema, alguém deve garantir a viagem.
O IBM MQ assume esse papel.
Ele não exige aplausos.
Não aparece para o usuário final.
Não recebe crédito quando tudo funciona.
Permanece silenciosamente transportando pagamentos, pedidos, reservas, autorizações e eventos entre sistemas.
Quando algum componente fica offline, o MQ não entra em pânico.
Ele guarda a mensagem.
Espera.
Tenta novamente.
E, quando o receptor finalmente retorna, entrega o conteúdo como se dissesse:
“Você demorou. Mas eu trouxe o pacote.”
É por isso que grandes empresas confiam no IBM MQ.
Não porque falhas nunca acontecem.
Mas porque, quando acontecem, a mensagem não precisa desaparecer no vazio interestelar da integração.
Ela fica na fila.
Segura.
Persistente.
Rastreável.
Esperando o momento certo de continuar sua viagem.
E essa é a diferença entre:
“Acho que o pagamento foi enviado.”
e:
“A transação está registrada, a mensagem está protegida e sabemos exatamente onde ela está.”
No universo dos sistemas críticos, essa diferença vale mais que ouro, mais que créditos galácticos e, em certos fechamentos bancários, possivelmente mais que uma nave inteiramente abastecida com café.
Sem comentários:
Enviar um comentário