 |
| Bellacosa Mainframe e a historia da integracao corporativa sem misterios |
☕ Um Café no Bellacosa Mainframe
A História da Integração Corporativa sem Mistérios
Do arquivo sequencial ao IBM App Connect Enterprise: o guia definitivo para o programador COBOL Padawan entender como os sistemas aprenderam a conversar
“A tecnologia muda, os protocolos ganham novos nomes, mas a missão permanece: conectar, transformar e entregar valor.”
Imagine a seguinte cena.
Você está sentado diante de uma tela verde, analisando um programa COBOL que lê um arquivo sequencial, consulta uma tabela Db2 e grava registros em um dataset de saída. Até aí, tudo parece familiar.
Então alguém da arquitetura chega e diz:
— Precisamos publicar esses dados em uma API, enviar eventos para o Kafka, integrar com o Salesforce, consumir um serviço REST e encaminhar mensagens para uma aplicação que está rodando no OpenShift.
O programador COBOL Padawan olha para o terminal, respira fundo e pensa:
— Em que momento meu arquivo FB de 80 posições virou parte de uma arquitetura intergaláctica?
Calma, jovem aprendiz.
Apesar dos nomes modernos, dos diagramas coloridos e das apresentações carregadas de expressões como cloud-native, event-driven, API-led e composable integration, o problema central continua sendo o mesmo enfrentado pelos profissionais de tecnologia há décadas:
como fazer sistemas diferentes trocarem informações com segurança, confiabilidade e significado?
Esta é a história da integração corporativa.
Uma história que começou com arquivos, passou por conexões ponto a ponto, middleware, barramentos de serviço, SOA, APIs, nuvem, eventos e inteligência artificial.
E, ao contrário do que alguns imaginam, o mainframe não ficou assistindo a essa evolução de longe. Ele participou de praticamente todas as fases.
Prepare sua caneca, ajuste o brilho do terminal 3270 e venha conhecer a longa jornada que transformou arquivos em APIs, transações em eventos e sistemas isolados em ecossistemas digitais.
1. O que é integração corporativa?
Integração corporativa é o conjunto de técnicas, padrões, programas e plataformas utilizados para permitir que diferentes sistemas compartilhem dados e coordenem processos.
Esses sistemas podem estar:
no mesmo computador;
em servidores diferentes;
em sistemas operacionais diferentes;
em empresas diferentes;
em nuvens diferentes;
em tecnologias criadas com décadas de distância.
Imagine um banco.
O banco pode possuir:
um sistema de contas correntes em COBOL e CICS;
um sistema de cartões em Java;
um aplicativo móvel;
um sistema antifraude;
um CRM;
uma plataforma de investimentos;
um ambiente de análise de dados;
serviços de Pix;
aplicações em nuvem;
parceiros externos.
Nenhum desses sistemas vive completamente sozinho.
Quando um cliente altera seu endereço, essa mudança pode precisar chegar ao sistema de contas, cartões, seguros, investimentos, correspondência, prevenção a fraudes e atendimento.
Integração é justamente o mecanismo que permite que essa informação viaje entre os sistemas.
Podemos resumir a missão em quatro verbos:
conectar, transformar, transportar e controlar.
Conectar significa permitir a comunicação.
Transformar significa converter dados entre formatos.
Transportar significa entregar a informação ao destino.
Controlar significa garantir segurança, monitoramento, rastreabilidade e tratamento de erros.
2. A integração existia antes das APIs
Hoje é comum alguém associar integração diretamente a APIs REST.
Mas a integração corporativa nasceu muito antes da Web.
Ela já existia quando os dados eram transportados em:
cartões perfurados;
fitas magnéticas;
discos;
arquivos sequenciais;
relatórios impressos;
terminais;
redes proprietárias.
Um programa COBOL que gera um arquivo para outro programa consumir já está realizando integração.
Um job que extrai registros do Db2 e os envia por FTP também é integração.
Uma transação CICS que coloca uma mensagem em uma fila IBM MQ é integração.
Uma aplicação que publica um evento em Kafka é integração.
Uma API que recebe JSON e chama uma transação IMS é integração.
A tecnologia muda, mas o princípio permanece.
3. Primeira era: batch e arquivos
A integração por arquivos
Durante as décadas de 1970 e 1980, grande parte da troca de dados corporativos era realizada por arquivos.
O fluxo era simples:
Sistema de origem
|
v
Gera arquivo
|
v
Transporte ou disponibilização
|
v
Sistema de destino lê o arquivo
No mainframe, isso poderia ser implementado com:
COBOL;
JCL;
QSAM;
VSAM;
GDG;
SORT;
IDCAMS;
FTP;
fitas magnéticas.
Um sistema de folha de pagamento, por exemplo, poderia gerar um arquivo contendo os créditos dos funcionários.
O sistema bancário receberia esse arquivo, validaria os registros e efetuaria os depósitos.
Um layout hipotético poderia ser:
01 REGISTRO-PAGAMENTO.
05 NUMERO-CONTA PIC 9(10).
05 VALOR-PAGAMENTO PIC 9(11)V99.
05 DATA-PAGAMENTO PIC 9(08).
05 CODIGO-EMPRESA PIC X(10).
Cada linha do arquivo representaria uma instrução de pagamento.
Esse modelo ainda é amplamente utilizado, especialmente em processos de grande volume.
Por que o batch funcionava tão bem?
O batch possui vantagens importantes.
Ele permite processar milhões de registros de forma previsível.
Ele é eficiente para operações que não precisam acontecer imediatamente.
Também oferece boa capacidade de reinício, auditoria e controle.
Imagine o fechamento diário de um banco.
Não é necessário atualizar todos os relatórios financeiros a cada milissegundo. Muitas tarefas podem ser agrupadas e processadas em uma janela noturna.
O batch é perfeito para isso.
O problema da latência
A principal limitação da integração por arquivos é o tempo.
Considere esta sequência:
22:00 - Sistema A gera arquivo
23:00 - Arquivo é transferido
00:00 - Sistema B inicia processamento
01:30 - Sistema C recebe o resultado
A informação pode levar horas para percorrer toda a cadeia.
Se o arquivo estiver incorreto, atrasado ou incompleto, dezenas de jobs posteriores podem falhar.
No mainframe, isso cria uma verdadeira constelação de dependências no JES2.
Um job espera o outro.
O segundo espera o terceiro.
O terceiro depende de um GDG.
O quarto aguarda o arquivo chegar.
Quando algo falha, o operador vê a fila crescer como uma frota inimiga aproximando-se da estação espacial.
Curiosidade do mainframe
Muitas empresas modernas ainda dependem fortemente de integração por arquivos.
O formato pode ter mudado de fita para SFTP, de arquivo fixo para CSV ou de dataset para objeto em nuvem, mas a ideia continua igual:
um sistema produz um pacote de dados e outro sistema o consome posteriormente.
Não devemos tratar batch como tecnologia ultrapassada.
Ele é apenas um modelo diferente de integração.
O erro acontece quando tentamos utilizar batch em situações que exigem resposta imediata.
4. Segunda era: integração ponto a ponto
Com a expansão dos computadores distribuídos nas décadas de 1980 e 1990, as empresas começaram a adotar diferentes plataformas.
Agora havia:
mainframes;
servidores Unix;
AS/400;
computadores Windows;
bancos Oracle;
aplicações SAP;
sistemas departamentais;
clientes e servidores.
Cada sistema precisava se conectar diretamente a outros sistemas.
Nascia a integração ponto a ponto.
Sistema A ------ Sistema B
| |
| |
Sistema C ------ Sistema D
No início, parecia uma solução simples.
Se o sistema de vendas precisava enviar informações ao estoque, criava-se uma interface.
Se o estoque precisava falar com o financeiro, criava-se outra.
Se o financeiro precisava comunicar-se com o mainframe, surgia mais uma conexão.
O problema aparecia com o crescimento.
O espaguete de interfaces
Considere quatro sistemas:
Se todos precisarem se conectar entre si, teremos diversas interfaces.
Com dez sistemas, o número potencial de conexões cresce dramaticamente.
A quantidade máxima de conexões diretas entre n sistemas pode ser calculada por:
n × (n - 1)
------------
2
Para 10 sistemas:
10 × 9 / 2 = 45 conexões
Para 20 sistemas:
20 × 19 / 2 = 190 conexões
Para 100 sistemas:
100 × 99 / 2 = 4.950 conexões
Agora imagine manter 4.950 interfaces.
Cada uma possui:
Esse cenário ficou conhecido como spaghetti integration.
Era uma arquitetura que parecia um prato de macarrão: fios cruzando em todas as direções.
O impacto no programador COBOL
O programador COBOL poderia receber pedidos como:
gerar um arquivo para o sistema Unix;
criar uma chamada CICS para uma aplicação externa;
acessar uma fila MQ;
receber dados via socket;
adaptar um copybook para um novo consumidor;
criar uma rotina específica para cada parceiro.
Com o tempo, o mesmo programa acumulava diversas condições:
EVALUATE CODIGO-CANAL
WHEN 'WEB'
PERFORM TRATA-WEB
WHEN 'ATM'
PERFORM TRATA-ATM
WHEN 'MOBILE'
PERFORM TRATA-MOBILE
WHEN 'PARCEIRO-A'
PERFORM TRATA-PARCEIRO-A
WHEN 'PARCEIRO-B'
PERFORM TRATA-PARCEIRO-B
END-EVALUATE
A aplicação de negócio começava a conhecer detalhes de todos os consumidores.
Isso criava forte acoplamento.
Uma mudança em um canal poderia exigir alteração no sistema central.
5. Terceira era: o surgimento do middleware
Para resolver o caos ponto a ponto, surgiu o middleware.
Middleware pode ser entendido como uma camada intermediária entre sistemas.
Em vez de cada aplicação conhecer todas as demais, elas passam a utilizar uma infraestrutura comum.
Aplicação A
|
v
Middleware
|
v
Aplicação B
O middleware pode executar várias funções:
Uma analogia simples é o sistema postal.
O remetente não precisa conhecer todo o caminho da entrega.
Ele coloca o endereço no envelope e entrega a correspondência ao serviço postal.
O middleware cuida do transporte.
6. Mensageria e IBM MQ
Uma das formas mais importantes de middleware é a mensageria.
No modelo de mensageria, a aplicação de origem não precisa conversar diretamente com o destino.
Ela coloca uma mensagem em uma fila.
Programa COBOL
|
v
Fila MQ
|
v
Aplicação consumidora
A fila funciona como um intermediário confiável.
O produtor envia a mensagem.
O consumidor lê quando estiver disponível.
Essa separação gera desacoplamento.
Exemplo prático
Uma transação CICS recebe uma solicitação de pagamento.
Em vez de chamar diretamente o sistema antifraude, ela publica uma mensagem:
PAGAMENTO
CONTA=123456
VALOR=850.00
CANAL=MOBILE
O sistema antifraude consome a mensagem e realiza sua análise.
Se o antifraude estiver temporariamente indisponível, a mensagem pode permanecer na fila.
Isso é muito mais resiliente do que uma conexão direta que falha imediatamente.
Uma lição importante
IBM MQ não é apenas um “correio eletrônico para programas”.
Ele oferece recursos corporativos como:
Para um programador COBOL, compreender MQ abre uma enorme porta para a integração moderna.
O programa pode:
conectar-se a um queue manager;
abrir uma fila;
colocar ou obter uma mensagem;
confirmar ou desfazer a transação;
fechar os recursos.
Em termos conceituais:
MQCONN
MQOPEN
MQPUT ou MQGET
MQCMIT
MQCLOSE
MQDISC
Cada chamada deve ter seu código de retorno verificado.
Ignorar COMPCODE e REASON em MQ é equivalente a pilotar uma nave sem consultar os sensores.
Pode funcionar durante algum tempo, mas o asteroide chegará.
7. O Enterprise Service Bus
Com o amadurecimento do middleware surgiu o conceito de Enterprise Service Bus, ou ESB.
O ESB atua como um barramento central de integração.
CRM
|
SAP -----> ESB <----- Mainframe
|
Aplicativo
|
Parceiro
Todos os sistemas integram-se por meio do barramento.
O ESB pode receber uma mensagem, transformá-la e encaminhá-la ao destino correto.
O que o ESB faz?
Suponha que um sistema envie XML:
<cliente>
<codigo>123</codigo>
<nome>Leonard McCoy</nome>
</cliente>
Mas o destino espera JSON:
{
"customerId": 123,
"customerName": "Leonard McCoy"
}
O ESB pode realizar essa transformação.
Ele também pode decidir a rota:
Se país = BRASIL
enviar ao sistema nacional
Se país = ARGENTINA
enviar ao sistema regional
Caso contrário
enviar ao processamento internacional
Além disso, pode enriquecer a mensagem.
Por exemplo:
recebe o número do cliente;
consulta o Db2;
obtém a categoria;
acrescenta a categoria à mensagem;
encaminha o conteúdo ao destino.
8. A evolução dos produtos IBM de integração
A história dos produtos IBM de integração possui várias mudanças de nome e evolução tecnológica.
Entre os nomes que marcaram essa trajetória estão:
Esses nomes não representam simplesmente mudanças cosméticas.
Eles refletem a ampliação das capacidades da plataforma.
O produto deixou de ser apenas uma ferramenta de integração baseada em mensagens e evoluiu para uma plataforma capaz de trabalhar com:
IBM MQ;
arquivos;
bancos de dados;
XML;
JSON;
SOAP;
REST;
aplicações empresariais;
eventos;
ambientes em nuvem;
containers.
O IBM App Connect Enterprise, conhecido como ACE, é herdeiro direto dessa longa evolução.
9. Como funciona um fluxo de integração no ACE?
Um fluxo de integração pode ser visualizado como uma sequência de etapas.
Entrada
|
Validação
|
Transformação
|
Roteamento
|
Acesso a sistemas
|
Saída
Imagine uma API que recebe um pedido.
O fluxo pode realizar:
receber o JSON;
validar os campos obrigatórios;
converter o formato;
consultar o cadastro do cliente;
enviar uma mensagem para MQ;
registrar a transação;
responder ao solicitante.
Exemplo de entrada:
{
"customerId": 1001,
"productId": 502,
"quantity": 3
}
O ACE pode transformar isso em uma estrutura utilizada por um programa COBOL:
000000100100000050200003
Naturalmente, uma aplicação real usaria um layout formal, provavelmente definido por copybook.
O ponto importante é que o sistema COBOL não precisa entender JSON.
O ACE pode realizar a tradução entre o mundo web e o formato tradicional do mainframe.
Esse é um dos maiores valores da integração: preservar o sistema central sem obrigá-lo a conhecer todas as tecnologias externas.
10. Quarta era: SOA e serviços
Na década de 2000, ganhou força a Arquitetura Orientada a Serviços, conhecida como SOA.
A ideia principal era organizar capacidades de negócio como serviços reutilizáveis.
Em vez de cada sistema acessar diretamente tabelas ou arquivos de outro sistema, ele chamaria um serviço.
Exemplos:
ConsultarCliente
CalcularLimite
RegistrarPagamento
EmitirApólice
CriarPedido
Um serviço não deveria representar apenas uma função técnica.
Ele deveria representar uma capacidade significativa do negócio.
Por que isso foi importante?
Imagine três aplicações que precisam consultar dados de clientes.
Sem um serviço, cada uma pode desenvolver sua própria lógica de acesso.
Uma consulta diretamente o Db2.
Outra lê um arquivo.
A terceira replica uma tabela.
Com o serviço ConsultarCliente, todas utilizam a mesma capacidade.
Isso reduz duplicação e aumenta a consistência.
11. SOAP, XML e WSDL
SOA foi fortemente associada a Web Services SOAP.
SOAP utiliza mensagens estruturadas, geralmente em XML.
Uma solicitação simplificada poderia ser:
<soapenv:Envelope>
<soapenv:Body>
<ConsultarCliente>
<Codigo>123</Codigo>
</ConsultarCliente>
</soapenv:Body>
</soapenv:Envelope>
O serviço era descrito por um WSDL.
O WSDL funcionava como um contrato formal, informando:
operações disponíveis;
estruturas de entrada;
estruturas de saída;
tipos de dados;
endereços;
protocolos.
Para grandes empresas, isso era valioso porque contratos rígidos ajudam a controlar integrações complexas.
SOAP era ruim?
Não.
SOAP tornou-se alvo de críticas por sua verbosidade e complexidade, mas resolveu problemas importantes.
Ele oferece padrões robustos para:
contratos;
segurança;
confiabilidade;
transações;
interoperabilidade.
Muitos serviços corporativos ainda utilizam SOAP porque foram construídos para processos críticos e continuam atendendo bem às necessidades do negócio.
O erro é confundir “mais antigo” com “inútil”.
No mainframe aprendemos cedo que idade e irrelevância não são sinônimos.
12. Quinta era: APIs REST
Com o crescimento da Web, dos aplicativos móveis e das arquiteturas distribuídas, as APIs REST tornaram-se populares.
REST geralmente utiliza:
Exemplo:
GET /clientes/123
Resposta:
{
"id": 123,
"nome": "Hikaru Sulu",
"categoria": "GOLD"
}
Comparado ao SOAP, REST costuma ser mais simples para aplicações web e móveis.
Métodos HTTP
Os métodos mais conhecidos são:
GET Consultar
POST Criar ou executar uma ação
PUT Atualizar ou substituir
PATCH Atualizar parcialmente
DELETE Excluir
Porém, esses significados dependem do desenho da API.
Uma boa API não é apenas um conjunto de URLs.
Ela precisa possuir:
contrato claro;
autenticação;
autorização;
validação;
versionamento;
limites de consumo;
observabilidade;
tratamento de erros.
13. O programador COBOL e as APIs
Um programa COBOL não precisa ser substituído apenas porque a empresa deseja oferecer uma API.
A integração pode funcionar assim:
Aplicativo móvel
|
v
API Gateway
|
v
ACE ou z/OS Connect
|
v
CICS / IMS / Db2 / COBOL
A API recebe JSON.
A camada de integração converte a solicitação.
O programa COBOL executa a regra de negócio.
A resposta é transformada novamente em JSON.
Essa arquitetura permite preservar décadas de regras validadas enquanto se oferece uma interface moderna.
Dica importante
Não coloque regras de negócio importantes em todos os lugares.
Se a regra de cálculo de limite pertence ao sistema central, evite replicá-la no aplicativo, no ESB, na API e em um microsserviço.
A duplicação de regras produz divergência.
Depois de alguns meses, cada sistema calcula um resultado diferente.
A integração deve orquestrar e transformar, mas não deve tornar-se um depósito descontrolado de lógica.
14. API-led connectivity
Com o crescimento das APIs, surgiu o conceito de integração orientada por APIs.
Uma organização pode estruturar suas APIs em camadas.
APIs de sistema
Expõem sistemas internos.
Exemplo:
API do Db2
API do CICS
API do SAP
APIs de processo
Combinam várias fontes para executar uma função de negócio.
Exemplo:
API de análise de crédito
Essa API pode consultar cadastro, histórico, renda e risco.
APIs de experiência
São adaptadas a um canal.
Exemplo:
API para aplicativo móvel
API para portal
API para parceiros
Essa separação evita que cada canal acesse diretamente os sistemas centrais.
15. Sexta era: nuvem e integração híbrida
A maioria das grandes empresas não migrou tudo para uma única nuvem.
O cenário real costuma ser híbrido.
Há sistemas:
A integração híbrida conecta esses mundos.
IBM Z
|
ACE
|
OpenShift
|
Cloud
|
SaaS
O desafio não é apenas transportar dados.
Também é necessário lidar com:
redes;
identidade;
criptografia;
latência;
governança;
custos;
residência de dados;
disponibilidade.
16. Containers e OpenShift
As plataformas de integração passaram a ser executadas em containers.
Um container empacota a aplicação e suas dependências.
Kubernetes e OpenShift administram esses containers.
Isso permite:
O ACE pode participar desse modelo moderno.
Em vez de uma única instalação central contendo todos os fluxos da empresa, diferentes integrações podem ser empacotadas e implantadas conforme sua necessidade.
Porém, não confunda distribuição com ausência de controle.
Mil integrações em containers sem governança podem criar um novo espaguete — agora servido em pequenas tigelas de Kubernetes.
Esse é um dos easter eggs arquitetônicos da história: toda solução criada para eliminar complexidade pode produzir uma complexidade nova quando utilizada sem disciplina.
17. Sétima era: arquitetura orientada a eventos
Em sistemas tradicionais, uma aplicação pergunta repetidamente:
Existe pedido novo?
Existe pedido novo?
Existe pedido novo?
Isso é chamado de polling.
Na arquitetura orientada a eventos, o sistema publica um aviso quando algo acontece.
PedidoCriado
PagamentoAprovado
ClienteAtualizado
EstoqueReduzido
Os consumidores escutam os eventos relevantes.
+--> Estoque
PedidoCriado ---+--> Financeiro
+--> Logística
+--> Analytics
O produtor não precisa conhecer todos os consumidores.
Esse desacoplamento é poderoso.
18. Eventos, mensagens e comandos
Esses conceitos parecem semelhantes, mas não são idênticos.
Comando
Solicita que algo seja feito.
EfetuePagamento
Evento
Informa que algo aconteceu.
PagamentoEfetuado
Mensagem
É o envelope transportado pelo sistema de mensageria. Pode conter um comando, um evento ou outro tipo de informação.
Essa distinção ajuda no desenho de integrações.
Um evento geralmente é descrito no passado porque representa um fato ocorrido.
19. Kafka e IBM Event Streams
Kafka popularizou plataformas distribuídas de eventos.
Os eventos são organizados em tópicos.
Exemplo:
TOPIC: pagamentos-aprovados
Vários consumidores podem ler o mesmo fluxo.
Um consumidor atualiza o sistema contábil.
Outro alimenta uma plataforma analítica.
Outro detecta fraude.
Outro dispara uma notificação.
No ecossistema IBM, o Event Streams oferece capacidades baseadas em Kafka.
O ACE pode produzir e consumir eventos, atuando como uma ponte entre aplicações tradicionais e arquiteturas orientadas a eventos.
20. MQ versus Kafka
Essa comparação aparece frequentemente.
Mas não é correto pensar apenas em “qual é melhor?”.
A pergunta adequada é:
qual modelo atende melhor ao problema?
IBM MQ é excelente para mensageria corporativa confiável, filas de trabalho e processamento transacional.
Kafka é muito forte em fluxos de eventos, retenção de registros e consumo por múltiplas aplicações.
Em várias arquiteturas, ambos convivem.
Exemplo:
CICS
|
MQ
|
ACE
|
Kafka
|
Analytics e aplicações digitais
O MQ garante a integração transacional com o sistema central.
O Kafka distribui o evento para vários consumidores.
Não é uma guerra entre tecnologias.
É uma composição de capacidades.
Como diria o Sr. Spock:
“Insistir que uma única ferramenta resolve todos os problemas é uma conclusão pouco lógica.”
21. A era da integração componível
Integração componível significa construir soluções a partir de blocos reutilizáveis.
Em vez de criar uma integração monolítica gigantesca, a empresa combina:
É semelhante à montagem de uma nave modular.
Cada componente possui uma responsabilidade clara.
Um conector acessa o Salesforce.
Outro interage com o SAP.
Um fluxo transforma dados.
Uma API expõe o serviço.
Um evento comunica uma mudança.
A composição desses elementos forma um processo maior.
22. Inteligência artificial na integração
A inteligência artificial começa a assumir funções de apoio ao ciclo de integração.
Ela pode ajudar a:
Imagine dois formatos de dados.
Origem:
{
"cust_id": 123,
"full_name": "Nyota Uhura"
}
Destino:
{
"customerNumber": 123,
"customerName": "Nyota Uhura"
}
Uma ferramenta com IA pode sugerir que:
cust_id -> customerNumber
full_name -> customerName
Isso acelera o trabalho.
Mas a IA não conhece automaticamente todas as regras do negócio.
Ela pode não perceber que:
o código precisa ter zeros à esquerda;
nomes devem ser convertidos para EBCDIC;
determinados clientes exigem tratamento especial;
o valor monetário utiliza casas decimais implícitas;
campos precisam obedecer a regras regulatórias.
Por isso, a validação humana continua essencial.
23. O risco da integração “mágica”
Ferramentas low-code e no-code facilitam a criação de integrações.
Isso é positivo.
Mas existe um risco: criar fluxos sem arquitetura, governança ou documentação.
Uma integração criada rapidamente pode tornar-se crítica.
Depois de dois anos, ninguém sabe:
quem a criou;
qual sistema depende dela;
como reiniciá-la;
quais credenciais utiliza;
onde está documentada;
o que acontece quando falha.
A facilidade de construção não elimina a necessidade de engenharia.
Pelo contrário: quanto mais fácil criar, maior deve ser a disciplina de governança.
24. Passo a passo para analisar uma integração
Quando receber uma demanda de integração, não comece imediatamente escolhendo tecnologia.
Siga uma sequência lógica.
Passo 1: compreenda o processo de negócio
Pergunte:
qual evento inicia o processo?
quem envia os dados?
quem consome?
qual resultado o negócio espera?
qual é o impacto de uma falha?
A integração não existe por causa do JSON.
Ela existe por causa do negócio.
Passo 2: identifique a origem e o destino
Exemplo:
Origem: transação CICS
Destino: aplicação em nuvem
Descubra:
plataformas;
protocolos;
formatos;
volumes;
restrições.
Passo 3: determine a necessidade de tempo
A integração deve ser:
em tempo real?
quase em tempo real?
assíncrona?
batch?
orientada a eventos?
Não transforme tudo em API síncrona.
Um processamento com milhões de registros pode ser melhor em batch.
Passo 4: defina o contrato
Documente:
campos;
tipos;
obrigatoriedade;
tamanhos;
valores válidos;
regras;
versões.
Para COBOL, o copybook frequentemente representa parte do contrato.
Para APIs, pode existir OpenAPI.
Para eventos, pode haver JSON Schema ou Avro.
Passo 5: escolha o padrão
Algumas possibilidades:
Arquivo
Fila
API
Evento
Serviço SOAP
Acesso a banco
A escolha deve considerar a necessidade, não o modismo.
Passo 6: planeje falhas
Pergunte:
o que acontece se o destino estiver indisponível?
haverá retry?
haverá fila de erros?
a mensagem pode ser duplicada?
existe mecanismo de reconciliação?
como reiniciar o processo?
Passo 7: implemente observabilidade
Registre:
Passo 8: proteja os dados
Considere:
autenticação;
autorização;
criptografia;
mascaramento;
auditoria;
LGPD;
gestão de segredos.
Passo 9: teste cenários ruins
Não teste apenas o caminho feliz.
Teste:
campo ausente;
mensagem inválida;
destino indisponível;
timeout;
duplicidade;
volume alto;
resposta inesperada;
falha de rede.
Passo 10: documente a operação
A equipe de produção precisa saber:
25. Idempotência: a palavra estranha que evita duplicidade
Idempotência significa que repetir uma operação não produz efeitos indesejados adicionais.
Imagine uma solicitação de débito.
A aplicação envia a requisição, mas não recebe resposta por causa de um timeout.
Ela tenta novamente.
Sem proteção, o cliente pode ser debitado duas vezes.
Uma solução é utilizar um identificador único:
ID-TRANSACAO = ABC123456
Antes de efetuar o débito, o sistema verifica se aquele identificador já foi processado.
Esse conceito é fundamental em integrações distribuídas.
No batch, muitas equipes já aplicavam ideias semelhantes usando arquivos de controle, chaves de processamento e mecanismos de restart.
Mais uma vez, o mundo moderno reencontra princípios que os veteranos do mainframe conhecem há décadas.
26. Correlação de mensagens
Uma transação pode atravessar vários sistemas.
Aplicativo
|
API Gateway
|
ACE
|
MQ
|
CICS
|
Db2
Como rastrear toda a jornada?
Utilizando um identificador de correlação.
Exemplo:
CORRELATION-ID: 7F9A-2026-000123
Esse valor deve acompanhar a solicitação em todos os componentes.
Assim, ao investigar um problema, a equipe procura o mesmo identificador nos logs.
Sem correlação, cada sistema possui uma parte da história, mas ninguém consegue montar o episódio completo.
É como investigar o desaparecimento de uma nave sem possuir o registro de sua rota.
27. Transformação de dados: o detalhe perigoso
Transformar XML em JSON parece simples.
Mas a verdadeira dificuldade está na semântica.
Considere:
DATA = 01022026
Isso significa:
Agora pense em valores monetários.
COBOL:
05 WS-VALOR PIC S9(9)V99 COMP-3.
Em JSON:
{
"valor": 1500.75
}
A camada de integração precisa compreender:
sinal;
escala decimal;
formato packed decimal;
codificação;
tamanho;
arredondamento.
Um mapeamento incorreto pode não gerar erro técnico.
Ele pode gerar um valor de negócio errado.
Esse é o tipo mais perigoso de falha: o sistema funciona, mas produz informação incorreta.
28. EBCDIC, ASCII e a ponte entre mundos
O mainframe utiliza frequentemente EBCDIC.
Sistemas distribuídos geralmente utilizam ASCII ou Unicode.
Ao trocar dados, pode ser necessário converter codificações.
Caracteres acentuados, símbolos e campos binários merecem atenção especial.
Um arquivo que parece perfeitamente legível em um ambiente pode tornar-se uma coleção de caracteres estranhos em outro.
Dica do café:
Nunca assuma que um campo PIC X contém apenas texto simples.
Ele pode conter:
Analise o copybook e o processo que grava o campo.
29. O papel do IBM App Connect Enterprise
O ACE ocupa uma posição estratégica porque consegue ligar diferentes gerações de tecnologia.
Ele pode atuar entre:
aplicações COBOL;
CICS;
IMS;
Db2;
IBM MQ;
arquivos;
APIs;
sistemas SAP;
bancos distribuídos;
serviços em nuvem;
eventos Kafka;
aplicações SaaS.
O ACE não “substitui o mainframe”.
Ele permite que o mainframe converse com o restante do ecossistema.
Também não deve concentrar toda a inteligência da empresa.
Seu papel principal é conectar, transformar, rotear e orquestrar.
30. Um exemplo completo
Imagine um cliente solicitando um empréstimo pelo aplicativo.
Etapa 1: aplicativo
O aplicativo envia:
{
"customerId": 10001,
"amount": 20000,
"installments": 24
}
Etapa 2: API Gateway
O gateway:
Etapa 3: ACE
O ACE:
valida o JSON;
transforma os dados;
gera um identificador de correlação;
consulta dados complementares;
envia a solicitação ao mainframe.
Etapa 4: CICS e COBOL
O programa COBOL:
consulta o cliente;
verifica renda;
analisa restrições;
calcula juros;
define a aprovação.
Etapa 5: resposta
O resultado retorna:
{
"status": "APPROVED",
"approvedAmount": 20000,
"interestRate": 1.45,
"installmentValue": 987.31
}
Etapa 6: evento
Após a aprovação, um evento é publicado:
LoanApproved
Consumidores podem:
Observe como várias eras convivem:
COBOL;
CICS;
API REST;
ACE;
mensageria;
eventos;
aplicações móveis;
cloud.
Integração moderna não elimina o passado.
Ela organiza a convivência entre gerações.
31. Problemas comuns e soluções
Problema: tudo depende do ESB
Quando todas as regras e integrações são concentradas em um único barramento, ele pode tornar-se um gargalo.
Solução
Distribuir responsabilidades, modularizar fluxos e utilizar padrões adequados.
Problema: contrato muda sem aviso
Uma aplicação altera um campo e quebra consumidores.
Solução
Usar versionamento, testes de contrato e governança.
Problema: mensagens duplicadas
Uma aplicação repete o envio após um timeout.
Solução
Implementar idempotência e chaves únicas.
Problema: integração sem monitoramento
A mensagem desaparece e ninguém sabe onde.
Solução
Utilizar correlação, logs, métricas, tracing e alertas.
Problema: regra de negócio duplicada
Cada canal implementa sua própria versão.
Solução
Centralizar a regra no domínio correto e expô-la como serviço.
Problema: API para tudo
Processamentos massivos são transformados em milhares de chamadas síncronas.
Solução
Avaliar batch, mensageria ou eventos.
32. Curiosidades da longa jornada
Curiosidade 1: o arquivo nunca morreu
Mesmo em arquiteturas modernas, arquivos continuam sendo utilizados para grandes volumes, intercâmbio com parceiros e processamento analítico.
Curiosidade 2: o ESB não desapareceu
Muitos anunciaram a “morte do ESB”, mas suas funções continuam existindo, distribuídas entre plataformas de integração, gateways, brokers e serviços.
Curiosidade 3: APIs não eliminam mensageria
APIs e mensagens resolvem problemas diferentes.
Uma aplicação pode usar API para consulta e eventos para notificação.
Curiosidade 4: microserviços também precisam integrar
Dividir uma aplicação em dezenas de serviços não elimina a integração. Na verdade, pode aumentar sua necessidade.
Curiosidade 5: o mainframe sempre foi uma plataforma integrada
CICS, IMS, Db2, VSAM, MQ, JES2 e RACF formam há décadas um ecossistema de processamento, segurança e comunicação extremamente sofisticado.
33. Easter egg do Bellacosa Mainframe
Existe uma antiga lenda nos corredores do datacenter.
Dizem que, durante uma madrugada de processamento, um programador encontrou a seguinte mensagem gravada em um arquivo temporário:
INTEGRATION IS NOT ABOUT MOVING DATA.
IT IS ABOUT PRESERVING MEANING.
Ele procurou a origem da mensagem no programa COBOL, no JCL, na PROC, no SORT e no módulo de integração.
Nunca encontrou.
Alguns afirmam que era apenas um registro esquecido por um desenvolvedor.
Outros dizem que foi o fantasma de um arquiteto de sistemas tentando alertar as novas gerações.
A mensagem, porém, contém uma verdade.
Transportar bytes é fácil.
Garantir que o destino compreenda corretamente o significado desses bytes é o verdadeiro desafio.
34. O que o programador COBOL iniciante deve estudar?
Para entrar no mundo da integração, siga uma trilha progressiva.
Primeiro nível: fundamentos
Aprenda:
arquivos sequenciais;
copybooks;
JCL;
Db2;
CICS;
códigos de retorno;
tratamento de erros.
Segundo nível: comunicação
Estude:
IBM MQ;
filas;
mensagens;
sincronismo;
assincronismo;
commit;
rollback.
Terceiro nível: dados modernos
Conheça:
Quarto nível: plataformas
Explore:
Quinto nível: arquitetura
Compreenda:
SOA;
ESB;
APIs;
event-driven;
idempotência;
observabilidade;
segurança;
governança.
Não tente aprender tudo de uma vez.
Comece entendendo o fluxo completo de uma única transação.
Siga o dado desde a origem até o destino.
Depois repita o exercício com outro padrão.
Conclusão: a tecnologia muda, a missão permanece
A integração corporativa começou muito antes das APIs e da nuvem.
Ela começou quando um sistema precisou entregar dados a outro.
Primeiro utilizamos arquivos.
Depois criamos conexões diretas.
Quando as conexões viraram um espaguete, introduzimos middleware.
O middleware evoluiu para barramentos de serviço.
SOA organizou capacidades como serviços.
SOAP trouxe contratos formais.
REST simplificou o consumo por aplicações digitais.
A nuvem tornou o ambiente híbrido.
Kafka e plataformas de eventos popularizaram arquiteturas orientadas a acontecimentos.
Containers trouxeram novas formas de implantação.
A inteligência artificial agora começa a auxiliar na criação, operação e análise das integrações.
Porém, nenhum desses avanços alterou a missão fundamental:
Conectar sistemas
Transformar dados
Preservar significado
Controlar processos
Entregar valor
Para o programador COBOL Padawan, a maior lição é perceber que o mainframe não pertence a um universo separado.
Ele é uma peça central da arquitetura corporativa.
O arquivo gerado por um job pode chegar a uma plataforma analítica.
A mensagem publicada por uma transação CICS pode acionar um serviço em nuvem.
Uma regra COBOL pode ser exposta por uma API móvel.
Uma atualização no Db2 pode originar um evento consumido por dezenas de aplicações.
O código pode ter nascido em uma tela verde, mas seu impacto atravessa APIs, filas, eventos, containers, celulares e nuvens.
No fim, integração não é apenas fazer computadores conversarem.
É garantir que diferentes gerações de tecnologia cooperem sem perder a segurança, a consistência e o conhecimento acumulado pelo negócio.
E essa, jovem Padawan, é uma missão digna não apenas de um arquiteto de integração, mas de todo profissional que deseja compreender como uma empresa realmente funciona por trás das telas coloridas.
A próxima vez que alguém disser que “tudo agora é API”, tome um gole de café, olhe calmamente para o terminal e responda:
— Toda API possui uma história. E há uma boa chance de que, em algum ponto dessa história, exista um programa COBOL mantendo o universo em funcionamento.
