 |
| Bellacosa Mianframe cobol conversando com o sap |
☕ Um Café no Bellacosa Mainframe
COBOL Conversando com SAP sem Mistérios para Programadores Padawan
Quando um Programa COBOL Descobre que o SAP Não é um Planeta Distante — É Apenas Outro Sistema Esperando uma Mensagem no Formato Certo
Imagine o seguinte cenário.
De um lado da galáxia corporativa existe um programa COBOL executando tranquilamente em um mainframe. Ele lê arquivos VSAM, consulta tabelas Db2, processa milhões de registros durante a madrugada e acredita sinceramente que controla todo o universo conhecido.
Do outro lado existe o SAP.
O SAP administra clientes, materiais, pedidos, notas fiscais, estoque, pagamentos, recursos humanos e praticamente qualquer outra coisa que uma empresa consiga transformar em processo, tabela ou reunião.
Em algum momento, alguém entra na sala e anuncia:
“Precisamos integrar o COBOL com o SAP.”
O programador Padawan olha para o terminal 3270, respira fundo e pergunta:
“Mas como um programa escrito para processar registros EBCDIC conversa com um sistema que trabalha com APIs, RFCs, IDocs, XML, JSON e nomes de campos que parecem feitiços alemães?”
A resposta é: por meio de uma camada de integração.
Na maioria dos projetos sérios, o COBOL não “entra” diretamente no SAP. Ele envia uma mensagem, chama um serviço ou grava informações em um canal intermediário. Esse canal traduz, valida, protege e entrega os dados ao SAP.
O segredo não está apenas em fazer a conexão funcionar.
O verdadeiro desafio é garantir que:
os dados tenham o formato correto;
os caracteres sejam convertidos corretamente;
o SAP não receba duplicidades;
os erros possam ser rastreados;
a transação seja segura;
o processamento tenha boa performance;
uma falha não deixe metade do pedido no COBOL e metade no SAP.
Este é o ponto em que integração deixa de ser apenas “mandar dados” e se transforma em arquitetura.
1. O que significa um programa COBOL conversar com SAP?
“Conversar com SAP” pode significar várias coisas.
Um programa COBOL pode precisar:
consultar um cliente cadastrado no SAP;
enviar um pedido de venda;
receber informações de materiais;
atualizar uma posição de estoque;
enviar lançamentos financeiros;
solicitar a criação de uma ordem;
transmitir dados de folha de pagamento;
receber o resultado de uma contabilização;
verificar se uma nota fiscal foi processada;
iniciar um processo de negócio dentro do SAP.
Portanto, antes de escolher a tecnologia, é necessário responder a algumas perguntas.
A chamada será síncrona ou assíncrona?
Comunicação síncrona
O COBOL envia uma solicitação e fica esperando uma resposta.
Exemplo:
COBOL → CONSULTAR CLIENTE → SAP
COBOL ← CLIENTE ENCONTRADO ← SAP
É semelhante a uma chamada de subprograma:
CALL 'CONSULTA'
A diferença é que o programa chamado pode estar em outro servidor, em outra plataforma e talvez em outro continente.
Essa modalidade é usada quando o COBOL precisa da resposta imediatamente para continuar.
Exemplos:
consultar limite de crédito;
validar material;
verificar disponibilidade;
obter preço;
confirmar uma transação.
Comunicação assíncrona
O COBOL envia uma mensagem e continua seu processamento sem esperar que o SAP termine imediatamente.
Exemplo:
COBOL → FILA MQ → MIDDLEWARE → SAP
O SAP pode processar a mensagem alguns segundos ou minutos depois.
Essa modalidade é muito utilizada para:
grandes volumes;
processamento batch;
pedidos;
movimentos de estoque;
atualizações financeiras;
integração de dados em lote;
cenários em que uma indisponibilidade temporária do SAP não pode interromper o mainframe.
A comunicação assíncrona costuma ser mais resiliente.
Se o SAP estiver indisponível, a mensagem pode permanecer em uma fila aguardando o retorno do sistema.
2. Os principais caminhos entre COBOL e SAP
Existem diversas formas de realizar essa integração. A escolha depende da arquitetura da empresa, da versão do SAP, das ferramentas disponíveis, do volume e da criticidade do processo.
Os caminhos mais comuns são:
Arquivos batch;
Banco de dados ou staging area;
IBM MQ;
Web Services SOAP;
APIs REST;
RFC e BAPI;
IDoc;
SAP PI/PO;
SAP Integration Suite;
Middleware corporativo;
Eventos e mensageria.
Vamos explorar cada rota.
3. Integração por arquivos: a velha nave cargueira que nunca abandona a frota
A integração por arquivos é uma das formas mais antigas e ainda muito utilizadas.
O programa COBOL gera um arquivo com registros de tamanho fixo ou variável. Esse arquivo é transferido para uma plataforma intermediária ou diretamente para um ambiente acessível pelo SAP.
Exemplo de fluxo:
Programa COBOL
|
v
Arquivo sequencial
|
v
SFTP / Connect:Direct
|
v
Servidor de integração
|
v
SAP
Exemplo de layout COBOL
01 REGISTRO-PEDIDO.
05 RP-TIPO-REGISTRO PIC X(01).
05 RP-NUMERO-PEDIDO PIC 9(10).
05 RP-CODIGO-CLIENTE PIC X(10).
05 RP-CODIGO-MATERIAL PIC X(18).
05 RP-QUANTIDADE PIC 9(07)V99.
05 RP-DATA-PEDIDO PIC 9(08).
05 RP-VALOR PIC 9(11)V99.
O programa grava milhares de registros e, ao final, pode gerar um registro de trailer:
01 REGISTRO-TRAILER.
05 RT-TIPO-REGISTRO PIC X(01) VALUE '9'.
05 RT-QTDE-REGISTROS PIC 9(09).
05 RT-VALOR-TOTAL PIC 9(13)V99.
O trailer funciona como um controle de integridade.
O SAP ou middleware pode verificar:
quantidade de registros;
valor total;
data de geração;
nome do arquivo;
identificador do lote;
checksum;
sequência do arquivo.
Vantagens
Simplicidade;
fácil auditoria;
bom para grandes volumes;
reinício relativamente simples;
não exige resposta imediata;
funciona bem em processamento batch.
Desvantagens
não é tempo real;
pode haver arquivos duplicados;
erros só aparecem depois;
exige controle de sequência;
exige definição rigorosa de layout;
conversão de caracteres pode causar problemas.
Erro clássico
O COBOL envia um arquivo em EBCDIC, mas o ambiente intermediário espera ASCII ou UTF-8.
Resultado:
CLIENTE JOSÉ
pode virar:
CLIENTE JOS?
ou algo ainda mais exótico, digno de um idioma falado apenas por droids de manutenção.
Solução
Defina claramente:
encoding de origem;
encoding de destino;
página de código;
tratamento de acentos;
delimitadores;
formato de campos numéricos;
formato de data;
representação de sinal;
uso de packed decimal.
Nunca envie diretamente um campo COMP-3 para um sistema que espera texto.
Converta:
MOVE CAMPO-COMP-3 TO CAMPO-NUMERICO-EDITADO
4. Integração por IBM MQ: o hiperpropulsor corporativo
Uma das formas mais robustas de conectar COBOL e SAP é por meio do IBM MQ.
O programa COBOL publica uma mensagem em uma fila. Um middleware consome essa mensagem, transforma o conteúdo e envia ao SAP.
Fluxo típico:
Programa COBOL
|
| MQPUT
v
Fila de Requisição
|
v
Middleware
|
v
SAP
|
v
Fila de Resposta
|
| MQGET
v
Programa COBOL
Essa arquitetura reduz o acoplamento.
O COBOL não precisa conhecer todos os detalhes internos do SAP. Ele precisa conhecer apenas:
nome da fila;
formato da mensagem;
identificador da transação;
timeout;
estrutura da resposta.
Exemplo conceitual usando MQ
IDENTIFICATION DIVISION.
PROGRAM-ID. ENVIASAP.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-MQ-COMPCODE PIC S9(9) COMP VALUE ZERO.
01 WS-MQ-REASON PIC S9(9) COMP VALUE ZERO.
01 WS-BUFFER-LENGTH PIC S9(9) COMP VALUE ZERO.
01 WS-MENSAGEM.
05 WS-TIPO PIC X(10) VALUE 'PEDIDO'.
05 WS-ID-PEDIDO PIC X(20).
05 WS-CLIENTE PIC X(10).
05 WS-MATERIAL PIC X(18).
05 WS-QUANTIDADE PIC 9(07)V99.
PROCEDURE DIVISION.
MOVE 'PED00000000000012345' TO WS-ID-PEDIDO
MOVE 'CLI0009876' TO WS-CLIENTE
MOVE 'MAT000000000012345' TO WS-MATERIAL
MOVE 15.00 TO WS-QUANTIDADE
MOVE LENGTH OF WS-MENSAGEM TO WS-BUFFER-LENGTH
CALL 'MQPUT'
USING
WS-MQ-COMPCODE
WS-MQ-REASON
WS-BUFFER-LENGTH
WS-MENSAGEM
IF WS-MQ-COMPCODE NOT = ZERO
DISPLAY 'ERRO MQPUT'
DISPLAY 'COMPCODE: ' WS-MQ-COMPCODE
DISPLAY 'REASON : ' WS-MQ-REASON
PERFORM TRATA-ERRO
END-IF
GOBACK.
Esse código é simplificado. Em um programa real, o MQPUT usa estruturas como:
MQOD;
MQMD;
MQPMO;
identificador de conexão;
identificador de objeto;
opções de persistência;
correlator;
message ID.
Mensagem persistente ou não persistente?
Persistente
A mensagem deve sobreviver a uma falha do queue manager.
Use em:
transações financeiras;
pedidos;
estoque;
faturamento;
processos críticos.
Não persistente
Pode ser usada quando perder a mensagem não causa impacto grave.
Exemplos:
telemetria;
dados temporários;
consultas descartáveis;
notificações não críticas.
Dica Jedi
Não escolha mensagens não persistentes apenas porque são mais rápidas.
Performance sem confiabilidade pode se transformar em um sistema veloz para perder dados.
5. Integração por REST API
APIs REST são cada vez mais utilizadas em ambientes SAP modernos.
Nesse modelo, o programa COBOL envia uma requisição HTTP para uma API.
Exemplo:
POST /api/pedidos
Content-Type: application/json
Authorization: Bearer <token>
Corpo:
{
"pedido": "12345",
"cliente": "9876",
"material": "MAT-001",
"quantidade": 15
}
O SAP ou uma camada intermediária retorna:
{
"status": "SUCESSO",
"documentoSap": "4500012345"
}
Como um COBOL chama uma API REST?
No mainframe, algumas opções incluem:
z/OS Connect Enterprise Edition;
CICS Web Support;
cliente HTTP em COBOL;
Java intermediário;
API gateway;
middleware;
programas USS;
bibliotecas HTTP fornecidas pela empresa.
Uma arquitetura moderna pode ser:
COBOL
|
v
z/OS Connect
|
v
API Gateway
|
v
SAP Integration Suite
|
v
SAP S/4HANA
O z/OS Connect pode expor serviços COBOL como APIs ou permitir que aplicações z/OS consumam APIs externas, dependendo da configuração e arquitetura adotada.
Exemplo de JSON criado pelo COBOL
01 WS-JSON.
05 FILLER PIC X(12) VALUE '{"pedido":"'.
05 WS-JSON-PEDIDO PIC X(10).
05 FILLER PIC X(13) VALUE '","cliente":"'.
05 WS-JSON-CLIENTE PIC X(10).
05 FILLER PIC X(14) VALUE '","material":"'.
05 WS-JSON-MATERIAL PIC X(18).
05 FILLER PIC X(02) VALUE '"}'.
Entretanto, montar JSON manualmente pode gerar erros.
Problemas comuns:
aspas não escapadas;
campos truncados;
espaços indesejados;
caracteres inválidos;
tamanho incorreto;
vírgula sobrando;
encoding incorreto.
Uma alternativa melhor é utilizar recursos do Enterprise COBOL, como JSON GENERATE, quando disponíveis e adequados ao ambiente.
Exemplo conceitual:
JSON GENERATE WS-JSON-TEXT
FROM WS-DADOS-PEDIDO
COUNT IN WS-JSON-LENGTH
ON EXCEPTION
DISPLAY 'ERRO AO GERAR JSON'
END-JSON
6. Integração por SOAP Web Service
Antes da popularização de REST, muitas integrações SAP eram implementadas com SOAP.
SOAP utiliza XML e contratos WSDL.
Exemplo simplificado:
<soapenv:Envelope>
<soapenv:Body>
<CriarPedido>
<Cliente>0000123456</Cliente>
<Material>MAT001</Material>
<Quantidade>10</Quantidade>
</CriarPedido>
</soapenv:Body>
</soapenv:Envelope>
Vantagens
contrato formal;
boa padronização;
suporte corporativo;
segurança avançada;
validação por esquema;
ainda muito comum em ambientes SAP.
Desvantagens
XML verboso;
mensagens maiores;
processamento mais pesado;
configuração mais complexa;
namespaces podem causar erros difíceis de encontrar.
Erro clássico
O campo existe no XML, mas está no namespace errado.
Para um humano, o XML parece correto.
Para o serviço:
ELEMENTO OBRIGATÓRIO AUSENTE
A lição é simples:
Em SOAP, o nome é importante, mas o namespace é parte do nome.
7. RFC e BAPI: falando a língua nativa do SAP
RFC significa Remote Function Call.
É um mecanismo tradicional do SAP para executar funções remotamente.
Uma BAPI é uma interface de negócio padronizada, normalmente construída sobre funções SAP.
Exemplos conceituais:
consultar cliente;
criar pedido;
obter material;
contabilizar documento;
alterar fornecedor.
O fluxo pode ser:
COBOL
|
v
Middleware ou SAP Connector
|
v
RFC/BAPI
|
v
SAP
Normalmente, o programa COBOL não implementa diretamente o protocolo RFC sem uma biblioteca ou componente intermediário.
É comum usar:
SAP Java Connector;
SAP .NET Connector;
middleware corporativo;
SAP PI/PO;
SAP Integration Suite;
produto de integração instalado no mainframe.
Uma armadilha importante: commit no SAP
Algumas BAPIs criam ou alteram dados, mas exigem uma chamada posterior de confirmação.
Por exemplo, conceitualmente:
1. Chamar BAPI de criação
2. Verificar mensagens de retorno
3. Executar commit
Sem o commit, a função pode responder aparentemente bem, mas a alteração não permanecer.
É como executar um programa COBOL, alterar dados e esquecer o:
EXEC SQL
COMMIT
END-EXEC
O universo SAP também respeita a velha lei:
Sem commit, a certeza é apenas uma variável temporária.
8. IDoc: o mensageiro oficial do Império SAP
IDoc significa Intermediate Document.
É uma estrutura padronizada de troca de dados usada amplamente pelo SAP.
Um IDoc possui:
registro de controle;
segmentos de dados;
registros de status.
Exemplos de uso:
pedidos;
materiais;
clientes;
fornecedores;
notas;
movimentos;
informações financeiras.
Fluxo típico:
COBOL
|
v
Arquivo ou MQ
|
v
Middleware
|
v
IDoc
|
v
SAP
O middleware transforma o layout COBOL no formato esperado pelo IDoc.
Status de IDoc
O SAP registra estados durante o processamento.
Conceitualmente, o documento pode estar:
recebido;
aguardando processamento;
processado com sucesso;
processado com erro;
pronto para reprocessamento.
Esses status são fundamentais para suporte.
Quando alguém disser:
“O mainframe enviou, mas não chegou ao SAP.”
Não aceite a frase como diagnóstico.
Pergunte:
O COBOL gravou o registro?
O MQPUT terminou com sucesso?
A mensagem saiu da fila?
O middleware consumiu?
A transformação funcionou?
O IDoc foi criado?
Qual é o status do IDoc?
Houve erro funcional?
Houve erro técnico?
O retorno foi enviado ao mainframe?
Integração precisa de evidência, não de adivinhação.
9. SAP PI/PO e SAP Integration Suite
Em muitas empresas, o COBOL não se conecta diretamente ao SAP.
Ele conversa com uma plataforma de integração.
Entre as tecnologias conhecidas estão:
SAP Process Integration;
SAP Process Orchestration;
SAP Integration Suite;
Enterprise Service Bus;
API Management;
brokers de mensageria.
Essa camada pode:
converter EBCDIC para UTF-8;
transformar copybooks em XML;
transformar XML em JSON;
validar campos;
aplicar regras;
autenticar chamadas;
rotear mensagens;
executar retry;
registrar logs;
controlar duplicidade;
monitorar falhas.
Arquitetura:
COBOL
|
| Arquivo, MQ, API ou SOAP
v
Plataforma de Integração
|
| Transformação e roteamento
v
SAP
Essa camada funciona como um tradutor universal.
O COBOL fala em:
PIC X(10)
PIC 9(07)V99
COMP-3
EBCDIC
O SAP fala em:
BAPI
IDoc
OData
XML
JSON
RFC
O middleware fica no meio dizendo:
“Calma, eu traduzo.”
10. Passo a passo completo de uma integração COBOL–SAP
Agora vamos construir mentalmente um processo real.
Cenário
Um programa COBOL processa pedidos recebidos no mainframe e precisa criar pedidos no SAP.
Passo 1 — Identificar o evento de negócio
O evento é:
PEDIDO APROVADO NO MAINFRAME
Não comece pela tecnologia.
Comece pelo negócio.
Defina:
quando o pedido está pronto;
quais campos são obrigatórios;
quem é o sistema proprietário;
o que significa sucesso;
o que significa rejeição;
como corrigir erros;
quem pode reenviar.
Passo 2 — Criar um identificador único
Cada transação deve possuir um identificador único.
Exemplo:
MF20260721000001234567
Esse identificador deve acompanhar todo o fluxo:
COBOL
MQ
MIDDLEWARE
SAP
LOG
RESPOSTA
Sem um identificador de correlação, investigar erros vira arqueologia digital.
Passo 3 — Definir o contrato da mensagem
Exemplo lógico:
ID_TRANSACAO
TIPO_OPERACAO
NUMERO_PEDIDO
CLIENTE
MATERIAL
QUANTIDADE
VALOR
DATA
HORA
ORIGEM
VERSAO_LAYOUT
A versão do layout é essencial.
VERSAO_LAYOUT = 001
Quando um novo campo for criado, talvez a versão passe para:
VERSAO_LAYOUT = 002
Isso permite evolução controlada.
Passo 4 — Validar dados no COBOL
Antes de enviar:
pedido está preenchido?
cliente é numérico?
quantidade é maior que zero?
material está informado?
data é válida?
valor está dentro do limite?
campos possuem caracteres permitidos?
Exemplo:
IF WS-CLIENTE = SPACES
MOVE '001' TO WS-CODIGO-ERRO
MOVE 'CLIENTE NAO INFORMADO'
TO WS-MENSAGEM-ERRO
PERFORM GRAVA-ERRO
GO TO FINALIZA
END-IF
Não envie lixo esperando que o SAP o transforme em ouro.
Passo 5 — Criar a mensagem
Pode ser:
copybook fixo;
XML;
JSON;
mensagem MQ;
arquivo delimitado;
estrutura intermediária.
Passo 6 — Enviar
Exemplo com MQ:
MQPUT REQUEST.QUEUE
Exemplo com API:
HTTP POST /pedidos
Exemplo com arquivo:
WRITE REGISTRO-PEDIDO
Passo 7 — Registrar o envio
Grave:
ID da transação;
data e hora;
pedido;
destino;
status;
tentativa;
retorno técnico;
retorno funcional.
Exemplo:
ID=MF20260721000001234567
STATUS=ENVIADO
TENTATIVA=01
Passo 8 — Receber a resposta
Resposta de sucesso:
{
"idTransacao": "MF20260721000001234567",
"status": "SUCESSO",
"documentoSap": "4500012345"
}
Resposta funcional:
{
"status": "ERRO",
"codigo": "CLIENTE_BLOQUEADO",
"mensagem": "Cliente bloqueado para vendas"
}
Resposta técnica:
{
"status": "ERRO_TECNICO",
"codigo": "TIMEOUT",
"mensagem": "SAP indisponível"
}
Passo 9 — Atualizar o sistema de origem
O COBOL deve marcar o pedido como:
enviado;
processado;
rejeitado;
pendente;
em retry;
intervenção manual.
Passo 10 — Implementar reprocessamento
Toda integração séria precisa responder:
“Como reprocessamos uma transação que falhou?”
Nunca dependa exclusivamente de alguém editar um arquivo manualmente às três da manhã.
Crie mecanismos como:
fila de erro;
tabela de pendências;
programa batch de retry;
tela de consulta;
comando de reenvio;
limite de tentativas;
trilha de auditoria.
11. Tipos de erros e suas soluções
11.1 Erro de conectividade
Exemplos:
host inacessível;
porta fechada;
DNS incorreto;
firewall bloqueando;
TLS falhando;
queue manager indisponível;
API gateway fora do ar.
Solução
testar rede;
validar host e porta;
verificar firewall;
confirmar certificado;
validar configuração do canal MQ;
consultar logs;
verificar timeout;
testar fora do programa COBOL.
Não altere o programa antes de confirmar que a estrada existe.
11.2 Timeout
O COBOL envia uma solicitação, mas a resposta demora demais.
Causas
SAP sobrecarregado;
consulta pesada;
lock;
middleware lento;
timeout muito curto;
rede degradada;
grande volume de dados.
Solução
definir timeout realista;
usar processamento assíncrono;
reduzir tamanho da resposta;
otimizar consulta;
usar cache quando permitido;
separar transações longas;
criar retry controlado.
Cuidado: repetir automaticamente uma transação pode gerar duplicidade.
11.3 Erro de autenticação
Exemplos:
HTTP 401
INVALID USER
INVALID TOKEN
CERTIFICATE ERROR
Solução
renovar token;
validar usuário técnico;
verificar senha;
conferir certificado;
validar client ID;
verificar escopo;
confirmar autorização no SAP.
Nunca grave senha diretamente no fonte COBOL.
Use mecanismos protegidos, como:
RACF;
cofre de segredos;
certificados;
configuração externa;
credenciais gerenciadas.
11.4 Erro de autorização
A autenticação funcionou, mas o usuário não pode executar a operação.
Exemplo:
HTTP 403
NOT AUTHORIZED
Solução
Verificar:
perfil do usuário;
objeto de autorização SAP;
função atribuída;
escopo da API;
ambiente correto;
operação permitida.
Autenticação responde:
“Quem é você?”
Autorização responde:
“O que você pode fazer?”
11.5 Erro de layout
Exemplos:
campo deslocado;
tamanho incorreto;
campo obrigatório ausente;
valor truncado;
decimal errado;
sinal inválido;
copybook desatualizado.
Solução
versionar copybooks;
validar comprimento;
comparar layout enviado e recebido;
usar testes automatizados;
criar amostras de mensagem;
documentar posições;
conferir redefinições;
evitar mudanças silenciosas.
Um campo aumentado de PIC X(10) para PIC X(12) pode deslocar todo o restante do registro.
11.6 Erro de conversão EBCDIC/ASCII/UTF-8
Sintomas
acentos incorretos;
caracteres estranhos;
JSON inválido;
XML não parseável;
campos preenchidos com símbolos.
Solução
Definir explicitamente:
CCSID;
página de código;
UTF-8;
conversão no MQ;
conversão no middleware;
origem e destino do arquivo.
Nunca confie em “conversão automática” sem teste.
Automático significa apenas que alguém configurou algo e talvez não tenha contado para você.
11.7 Erro de dados inválidos
Exemplos:
cliente inexistente;
material bloqueado;
quantidade negativa;
centro inválido;
moeda não permitida;
período contábil fechado.
Solução
Classifique como erro funcional.
Não adianta repetir cinquenta vezes um pedido cujo cliente está bloqueado.
Retry serve para falhas transitórias, não para regras de negócio.
11.8 Duplicidade
O COBOL envia uma transação, ocorre timeout e não sabe se o SAP processou. Então envia novamente.
Resultado: dois pedidos.
Solução
Implementar idempotência.
O SAP ou middleware deve verificar o identificador único.
Exemplo:
ID_TRANSACAO = MF20260721000001234567
Se esse ID já foi processado, o sistema retorna o mesmo resultado em vez de criar outro documento.
Idempotência é uma das palavras mais importantes em integração.
11.9 Erro de commit ou rollback
O SAP processa parcialmente uma transação.
Solução
usar unidade lógica de trabalho;
definir fronteira transacional;
executar commit apenas após sucesso;
executar rollback em falha;
evitar atualizações parciais;
compensar operações quando necessário.
Em sistemas distribuídos, não existe um único commit mágico resolvendo tudo.
Às vezes é necessário usar:
confirmação;
compensação;
eventos;
status intermediários;
reconciliação.
11.10 Fila cheia ou mensagem parada
No IBM MQ, uma fila pode atingir sua profundidade máxima.
Sintomas
MQPUT falha;
mensagens acumuladas;
consumidor parado;
processamento atrasado.
Solução
monitorar profundidade;
validar consumidor;
revisar
MAXDEPTH;analisar dead-letter queue;
avaliar backout queue;
criar alertas;
ajustar taxa de produção e consumo.
Aumentar o tamanho da fila pode aliviar o sintoma, mas não resolve um consumidor quebrado.
12. Retry: repetir sem criar um monstro
Um retry bem desenhado deve possuir:
número máximo de tentativas;
intervalo crescente;
classificação do erro;
registro de cada tentativa;
idempotência;
destino de erro final.
Exemplo:
Tentativa 1: após 10 segundos
Tentativa 2: após 30 segundos
Tentativa 3: após 2 minutos
Tentativa 4: após 10 minutos
Esse mecanismo é conhecido como backoff.
Não use:
PERFORM UNTIL SUCESSO
TENTA-DE-NOVO
END-PERFORM
Isso pode criar um loop infinito, consumir CPU e transformar o LPAR em uma churrasqueira tecnológica.
13. Exemplo de programa COBOL conceitual
Abaixo temos uma estrutura simplificada de integração.
IDENTIFICATION DIVISION.
PROGRAM-ID. PEDSAP01.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CONTROLES.
05 WS-STATUS PIC X(10).
05 WS-TENTATIVA PIC 9(02) VALUE ZERO.
05 WS-MAX-TENTATIVAS PIC 9(02) VALUE 03.
05 WS-RETURN-CODE PIC 9(04) VALUE ZERO.
01 WS-PEDIDO.
05 WS-ID-TRANSACAO PIC X(24).
05 WS-NUMERO-PEDIDO PIC X(12).
05 WS-CLIENTE PIC X(10).
05 WS-MATERIAL PIC X(18).
05 WS-QUANTIDADE PIC 9(07)V99.
05 WS-VALOR PIC 9(11)V99.
01 WS-RESPOSTA.
05 WS-RESP-STATUS PIC X(10).
05 WS-RESP-CODIGO PIC X(20).
05 WS-RESP-MENSAGEM PIC X(100).
05 WS-DOCUMENTO-SAP PIC X(20).
PROCEDURE DIVISION.
0000-PRINCIPAL.
PERFORM 1000-INICIALIZAR
PERFORM 2000-LER-PEDIDO
PERFORM 3000-VALIDAR-PEDIDO
IF WS-RETURN-CODE NOT = ZERO
PERFORM 9000-FINALIZAR
END-IF
PERFORM 4000-GERAR-ID
PERFORM 5000-ENVIAR-SAP
IF WS-RESP-STATUS = 'SUCESSO'
PERFORM 6000-ATUALIZAR-SUCESSO
ELSE
PERFORM 7000-TRATAR-ERRO
END-IF
PERFORM 9000-FINALIZAR.
1000-INICIALIZAR.
MOVE ZERO TO WS-RETURN-CODE
MOVE SPACES TO WS-RESPOSTA.
2000-LER-PEDIDO.
MOVE 'PED000012345' TO WS-NUMERO-PEDIDO
MOVE '0000987654' TO WS-CLIENTE
MOVE 'MAT000000000123456' TO WS-MATERIAL
MOVE 10.00 TO WS-QUANTIDADE
MOVE 1500.00 TO WS-VALOR.
3000-VALIDAR-PEDIDO.
IF WS-CLIENTE = SPACES
MOVE 8 TO WS-RETURN-CODE
MOVE 'CLIENTE NAO INFORMADO'
TO WS-RESP-MENSAGEM
END-IF
IF WS-QUANTIDADE <= ZERO
MOVE 8 TO WS-RETURN-CODE
MOVE 'QUANTIDADE INVALIDA'
TO WS-RESP-MENSAGEM
END-IF.
4000-GERAR-ID.
MOVE 'MF-20260721-0000012345'
TO WS-ID-TRANSACAO.
5000-ENVIAR-SAP.
ADD 1 TO WS-TENTATIVA
CALL 'SAPINT01'
USING WS-PEDIDO
WS-RESPOSTA
WS-RETURN-CODE.
6000-ATUALIZAR-SUCESSO.
DISPLAY 'PEDIDO PROCESSADO'
DISPLAY 'DOCUMENTO SAP: ' WS-DOCUMENTO-SAP.
7000-TRATAR-ERRO.
EVALUATE WS-RESP-CODIGO
WHEN 'TIMEOUT'
WHEN 'CONNECTION_ERROR'
IF WS-TENTATIVA < WS-MAX-TENTATIVAS
PERFORM 5000-ENVIAR-SAP
ELSE
PERFORM 7100-GRAVAR-PENDENCIA
END-IF
WHEN 'CLIENTE_BLOQUEADO'
WHEN 'MATERIAL_INVALIDO'
PERFORM 7200-GRAVAR-ERRO-FUNCIONAL
WHEN OTHER
PERFORM 7300-GRAVAR-ERRO-TECNICO
END-EVALUATE.
7100-GRAVAR-PENDENCIA.
DISPLAY 'TRANSACAO PENDENTE: '
WS-ID-TRANSACAO.
7200-GRAVAR-ERRO-FUNCIONAL.
DISPLAY 'ERRO FUNCIONAL: '
WS-RESP-MENSAGEM.
7300-GRAVAR-ERRO-TECNICO.
DISPLAY 'ERRO TECNICO: '
WS-RESP-MENSAGEM.
9000-FINALIZAR.
MOVE WS-RETURN-CODE TO RETURN-CODE
GOBACK.
Em produção, o SAPINT01 poderia ser:
wrapper para MQ;
cliente de API;
chamada a um módulo C;
chamada Java;
transação CICS;
serviço z/OS Connect;
componente de middleware.
Separar a lógica de negócio da lógica de comunicação facilita manutenção e testes.
14. Configurações importantes
Timeouts
Defina timeouts diferentes para:
conexão;
envio;
leitura;
processamento total.
Um timeout infinito não é robustez.
É apenas uma forma educada de dizer que o programa ficará esperando até o próximo IPL.
Tamanho de mensagem
Verifique:
tamanho máximo no MQ;
tamanho permitido pela API;
tamanho do JSON;
tamanho do XML;
limite do middleware;
limite de memória do programa.
TLS
Use criptografia em trânsito.
Validar:
certificado;
autoridade certificadora;
validade;
hostname;
protocolo;
cipher suite.
Credenciais
Não armazene:
01 WS-SENHA PIC X(08) VALUE 'SAP12345'.
Isso é praticamente deixar a chave da Enterprise debaixo do tapete.
Filas MQ
Configure e monitore:
request queue;
reply queue;
dead-letter queue;
backout queue;
persistência;
prioridade;
expiração;
profundidade máxima.
Logging
Registre o suficiente para investigar, mas não exponha:
senhas;
tokens;
dados pessoais;
números sensíveis;
conteúdo completo de documentos confidenciais.
15. Performance
15.1 Evite chamada por registro
Imagine um batch com um milhão de registros.
Fazer uma chamada síncrona ao SAP para cada registro pode ser extremamente lento.
Melhorias possíveis:
agrupar registros;
enviar lotes;
usar processamento assíncrono;
comprimir mensagens quando apropriado;
reduzir chamadas;
reutilizar conexões;
executar paralelismo controlado.
15.2 Use conexão persistente
Abrir e fechar uma conexão para cada transação aumenta custo.
Quando suportado:
reutilize sessão;
use connection pool;
mantenha canal;
evite autenticações repetidas.
15.3 Não envie campos desnecessários
Uma mensagem com 200 campos quando apenas 20 são necessários:
consome rede;
aumenta parsing;
dificulta manutenção;
amplia risco de erro;
cria acoplamento.
15.4 Controle o paralelismo
Mais threads ou tasks não significam automaticamente mais performance.
Paralelismo excessivo pode:
saturar SAP;
aumentar lock;
encher filas;
provocar throttling;
consumir CPU;
aumentar contenção.
A regra Jedi é:
Paralelize até o ponto em que o sistema fica mais rápido, não até o ponto em que ele começa a emitir fumaça.
15.5 Faça commit em intervalos adequados
Em batch:
commits muito frequentes aumentam overhead;
commits muito espaçados aumentam locks e dificultam restart.
Escolha o intervalo com base em:
volume;
criticidade;
tempo de reprocessamento;
capacidade de rollback;
política transacional.
16. Monitoramento
Uma integração precisa de observabilidade.
Monitore:
quantidade enviada;
quantidade processada;
quantidade rejeitada;
tempo médio;
percentil de resposta;
fila acumulada;
quantidade de retry;
erros por tipo;
indisponibilidade;
divergência entre sistemas.
Exemplo de painel:
Pedidos enviados: 125.000
Pedidos processados: 124.950
Erros funcionais: 35
Erros técnicos: 15
Fila pendente: 10
Tempo médio: 1,8 s
Maior tempo: 12,4 s
Sem métricas, a integração pode estar falhando silenciosamente.
17. Reconciliação
Mesmo com todos os controles, compare periodicamente os sistemas.
Exemplo:
Mainframe:
1000 pedidos enviados
SAP:
998 pedidos criados
Diferença:
2 pedidos
A reconciliação ajuda a localizar:
mensagens perdidas;
duplicidades;
falhas parciais;
respostas não processadas;
alterações manuais;
erros de status.
Uma boa integração não confia apenas no fluxo em tempo real.
Ela também verifica depois se a realidade corresponde ao esperado.
18. Dicas e truques do Mestre Jedi do COBOL
Dica 1 — Crie um copybook de integração
Centralize:
códigos de retorno;
status;
estrutura da mensagem;
versão;
campos de auditoria.
Dica 2 — Não misture erro técnico com erro funcional
Erro técnico:
SAP indisponível
Erro funcional:
Cliente bloqueado
O primeiro pode merecer retry.
O segundo exige correção de negócio.
Dica 3 — Grave o payload original
Quando permitido pela política de segurança, preserve o conteúdo enviado ou ao menos uma representação auditável.
Isso ajuda a provar o que realmente saiu do mainframe.
Dica 4 — Use correlation ID
O mesmo ID precisa aparecer em todos os logs.
Dica 5 — Teste caracteres especiais
Inclua nos testes:
José
Ação
São Paulo
João D'Ávila
Comércio & Serviços
Dica 6 — Teste campos no limite
Teste:
valor máximo;
campo vazio;
campo completo;
zero;
número negativo;
data inválida;
mensagem máxima;
caracteres inesperados.
Dica 7 — Teste indisponibilidade
Desligar o serviço em ambiente de teste pode ensinar mais do que cem testes de sucesso.
Verifique:
comportamento do timeout;
retry;
rollback;
fila de erro;
mensagem ao operador;
retomada após recuperação.
Dica 8 — Não use DISPLAY como estratégia completa de observabilidade
DISPLAY ajuda durante o desenvolvimento.
Produção exige:
log estruturado;
SMF quando aplicável;
registros de auditoria;
monitoramento de MQ;
métricas de API;
rastreamento distribuído.
Dica 9 — Versione o contrato
Nunca altere uma mensagem produtiva sem controlar compatibilidade.
Dica 10 — Planeje o restart antes do primeiro erro
O melhor momento para desenhar o reprocessamento é antes da produção.
O segundo melhor momento é antes de o diretor financeiro descobrir que faltam documentos no SAP.
19. Easter eggs para quem chegou até aqui
Easter egg 1 — O SAP também tem seus próprios ABENDs espirituais
Eles podem não se chamar S0C7, mas aparecem como:
dumps;
falhas de RFC;
erros de autorização;
documentos incompletos;
locks;
status de IDoc;
exceções de serviço.
Todo sistema possui uma maneira particular de dizer:
“Algo impossível aconteceu, embora alguém tenha programado exatamente essa possibilidade.”
Easter egg 2 — O verdadeiro vilão é a duplicidade
Em muitas integrações, perder uma mensagem é grave.
Criar duas transações financeiras idênticas pode ser ainda pior.
Por isso, o identificador único é o sabre de luz da idempotência.
Easter egg 3 — O copybook é o pergaminho sagrado
Uma alteração de duas posições em um copybook pode derrubar uma integração mais rápido que um disparo no reator principal da Estrela da Morte.
Easter egg 4 — “Funcionou no teste” não é uma certificação galáctica
O teste provavelmente usou:
um cliente válido;
um material válido;
uma quantidade pequena;
um SAP disponível;
nenhum acento;
nenhuma duplicidade;
nenhuma falha de rede.
Produção conhece todos os lados sombrios que o teste ignorou.
20. Arquitetura recomendada
Uma arquitetura robusta pode ser:
┌───────────────────────────────┐
│ Programa COBOL │
│ Validação + ID da Transação │
└───────────────┬───────────────┘
│
│ MQPUT
v
┌───────────────────────────────┐
│ IBM MQ │
│ Persistência + Buffer │
└───────────────┬───────────────┘
│
v
┌───────────────────────────────┐
│ Middleware │
│ Conversão EBCDIC/UTF-8 │
│ Validação │
│ Transformação │
│ Retry │
│ Segurança │
└───────────────┬───────────────┘
│
│ IDoc / BAPI / API
v
┌───────────────────────────────┐
│ SAP │
│ Processamento do Negócio │
└───────────────┬───────────────┘
│
│ Resposta
v
┌───────────────────────────────┐
│ Fila de Retorno │
└───────────────┬───────────────┘
│
v
┌───────────────────────────────┐
│ COBOL Atualiza Status │
│ Sucesso / Erro / Pendência │
└───────────────────────────────┘
Essa arquitetura oferece:
desacoplamento;
tolerância a falhas;
escalabilidade;
auditoria;
rastreabilidade;
reprocessamento;
segurança;
controle de performance.
Conclusão
Um programa COBOL pode conversar com SAP de diversas maneiras:
arquivos;
IBM MQ;
APIs REST;
SOAP;
RFC;
BAPI;
IDoc;
middleware;
plataformas de integração.
O método escolhido importa, mas não é o único fator decisivo.
Uma boa integração precisa possuir:
contrato claro;
identificador único;
validação;
segurança;
tratamento de erros;
retry controlado;
idempotência;
monitoramento;
auditoria;
reprocessamento;
reconciliação.
O programador Padawan talvez comece pensando:
“Só preciso mandar um pedido para o SAP.”
Depois de conhecer o universo da integração, ele percebe:
“Preciso garantir que o pedido seja enviado, recebido, processado, confirmado, auditado, protegido, rastreado e nunca duplicado.”
E nesse momento nasce um verdadeiro arquiteto de integração.
Porque conectar dois sistemas não significa apenas fazer com que eles troquem mensagens.
Significa garantir que ambos contem a mesma história sobre o que aconteceu.
E quando COBOL e SAP finalmente concordam sobre clientes, materiais, valores, pedidos e commits, o equilíbrio retorna à galáxia corporativa.
Pelo menos até alguém alterar o layout sem avisar.
Sem comentários:
Enviar um comentário