✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta REST. Mostrar todas as mensagens

terça-feira, 3 de fevereiro de 2026

🔥API NÃO É CICS! — O Guia PROIBIDO que Todo Coboleiro Precisa Ler Antes de Virar ‘Júnior’ em Python

Bellacosa Mainframe o mundo da APIs em Python e Mainframe

🔥 “API NÃO É CICS! — O Guia PROIBIDO que Todo Coboleiro Precisa Ler Antes de Virar ‘Júnior’ em Python”

☕ Introdução no estilo Bellacosa

Se você vem do mundo do COBOL, acostumado com CICS, MQ, VSAM e chamadas bem estruturadas… prepare-se:

👉 Em Python, o mundo gira em torno de APIs.

E não, não é exagero.

Se no mainframe você faz EXEC CICS LINK, no Python você faz requisições HTTP para APIs REST — e isso muda completamente o jogo.

Hoje você não consome arquivos.
Você consome serviços vivos.

🧠 Um pouco de história (porque raiz importa)

Antes de falarmos de Python, vamos entender o conceito:

Anos 70–90 → Integração via arquivos batch (hello JCL 👋)
Anos 90–2000 → RPC, CORBA, Web Services SOAP
Pós-2010 → REST APIs (HTTP simples + JSON)

👉 E aí entra Python como o “canivete suíço” dessa nova era.

A linguagem nasceu em 1991 com Guido van Rossum, mas só explodiu quando virou padrão para:

automação
integração
dados
e claro… consumo de APIs

🚀 O que é API (tradução COBOL)

Pensa assim:

COBOL	Python
CICS LINK	HTTP Request
Copybook	JSON
COMMAREA	Body da requisição
Program	Endpoint

👉 API = um programa remoto que você chama via rede.

🔥 As APIs mais usadas em Python (ESSENCIAIS)

1. 🌐 requests — o “EXEC CICS” do Python

A biblioteca mais famosa para consumir APIs.


import requests

response = requests.get("https://api.github.com")
print(response.json())

💡 Tradução Bellacosa:

Isso é basicamente um CALL 'API' USING COMMAREA… só que via internet.

2. ⚡ FastAPI — o “CICS moderno”

Se você quer criar APIs:


from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def home():
    return {"message": "Hello Mainframe!"}

🔥 Extremamente rápido, moderno e tipado.

👉 É tipo montar seu próprio CICS + transaction server, só que leve.

3. 🧱 Flask — o clássico minimalista


from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello COBOL world!"

💡 Muito usado em sistemas menores ou protótipos.

4. 🔐 httpx — o “requests turbo”

Assíncrono (não bloqueia execução)
Melhor performance


import httpx

response = httpx.get("https://api.github.com")
print(response.json())

👉 Ideal para alta concorrência.

5. 🤖 APIs famosas que você VAI usar

GitHub API
OpenAI API
Google Maps API
AWS APIs

Essas são as “bases de dados modernas”.

🧪 Exemplo prático (modo COBOL mindset)

Cenário:

Você quer consultar dados de usuário.


import requests

url = "https://jsonplaceholder.typicode.com/users/1"
response = requests.get(url)

if response.status_code == 200:
    data = response.json()
    print(data["name"])

💡 Pense assim:

status_code → retorno do programa
json() → estrutura de dados (tipo copybook dinâmico)

⚠️ Pecados capitais do coboleiro em APIs

❌ 1. Esperar estrutura fixa (copybook mental)

JSON muda.

👉 Use:


data.get("campo", "default")

❌ 2. Ignorar erro HTTP


if response.status_code != 200:
    print("ERRO!")

👉 Sem isso, você vai quebrar em produção. Certeza.

❌ 3. Fazer tudo síncrono (modo batch)

Python moderno usa async.

💡 Truques de veterano (ouro puro)

🔥 1. Timeout SEMPRE


requests.get(url, timeout=5)

👉 Evita travar igual job preso em spool.

🔥 2. Headers = identidade


headers = {"Authorization": "Bearer TOKEN"}
requests.get(url, headers=headers)

👉 Sem isso, muitas APIs nem respondem.

🔥 3. Logging é vida


print(response.text)

👉 Debug de API = olhar payload.

🔥 4. Use Postman antes de codar

👉 Teste a API antes. Igual testar JCL antes do PROD.

🧠 Curiosidades que poucos sabem

O termo REST foi criado por Roy Fielding em 2000
JSON substituiu XML porque é mais leve
APIs hoje substituem bancos inteiros
Muitas empresas nem expõem mais DB — só API

👉 Ou seja:
Você não acessa dados.
Você negocia com serviços.

🥚 Easter Eggs (pra você brilhar na roda)

🐍 Python tem API embutida para web


import webbrowser
webbrowser.open("https://google.com")

🎯 requests aceita JSON direto


requests.post(url, json={"nome": "Bellacosa"})

👉 Sem precisar serializar manualmente.

💣 Dá pra mockar API (testes)


from unittest.mock import patch

👉 Igual simular programa no batch.

🔥 Conexão com o mundo Mainframe

Você não precisa abandonar COBOL.

👉 Você pode:

Criar API em Python
Consumir do COBOL via HTTP (CICS Web Services)
Integrar legado com cloud

💡 Isso é o futuro real:
Mainframe + APIs + Python

🎯 Conclusão estilo Bellacosa

Se você ainda está pensando em arquivo sequencial…

👉 você já está atrasado.

APIs são o novo VSAM.
JSON é o novo copybook.
HTTP é o novo CICS.

E Python?

👉 É a linguagem que cola tudo isso.

☕ Frase final pra guardar

“Quem domina API não precisa migrar do mainframe… ele domina o mundo ao redor dele.”

quinta-feira, 26 de dezembro de 2024

📮 O CARTEIRO E O POETA — QUANDO UMA POSTMAN COLLECTION APRENDEU A ENTREGAR CARTAS AO MAINFRAME

Bellacosa Mainframe apresenta o postman

☕ Um Café no Bellacosa Mainframe

📮 O CARTEIRO E O POETA — QUANDO UMA POSTMAN COLLECTION APRENDEU A ENTREGAR CARTAS AO MAINFRAME

Postman, Collections, HTTP, REST, JSON, variáveis, autenticação, scripts, testes positivos e negativos, contratos, Runner, CI/CD, z/OS Connect, CICS, COBOL, Db2 — e o dia em que um jovem programador descobriu que receber `200 OK` não significava que a carta havia chegado à pessoa certa.

Sob a tutela de O Carteiro e o Poeta, porque uma API também vive de mensagens. Algumas precisam chegar rápido. Outras precisam chegar com segurança. Todas precisam chegar ao destinatário correto.

🎬 PRÓLOGO — TODA API TEM UM CARTEIRO

Imagine uma pequena ilha.

Todas as manhãs, o carteiro percorre as mesmas ruas carregando cartas. Ele conhece os caminhos, as casas, os moradores e os horários.

Até que encontra um poeta.

O poeta não quer simplesmente que uma carta seja transportada.

Ele quer que ela seja compreendida.

Essa pequena diferença explica uma parte enorme do que significa testar APIs.

Quando começamos a usar o Postman, normalmente fazemos algo parecido com um carteiro iniciante:

GET /clientes/123

Clicamos em Send.

Recebemos:

200 OK

E comemoramos:

Funcionou!

Calma, jovem padawan do COBOL.

O servidor respondeu. Isso é tudo que sabemos até agora.

Talvez tenhamos pedido o cliente 123 e recebido o cliente 999.

Talvez o JSON esteja incompleto.

Talvez o saldo esteja errado.

Talvez uma pessoa sem autorização tenha conseguido consultar informações que não deveria.

Talvez o backend tenha consultado o Db2 errado.

Talvez o COBOL tenha devolvido um código de negócio indicando falha e alguma camada intermediária tenha convertido tudo em HTTP 200.

O carteiro entregou alguma coisa.

Ainda precisamos descobrir se entregou a carta correta para a pessoa correta.

E é aqui que nossa história realmente começa.

📬 CAPÍTULO 1 — POSTMAN NÃO É APENAS UM BOTÃO SEND

Para quem começa a trabalhar com APIs, Postman parece uma ferramenta para escrever uma URL, selecionar GET ou POST e apertar Send.

Isso seria como dizer que ISPF serve para editar texto.

Tecnicamente não está completamente errado.

Mas estamos ignorando quase todo o universo existente atrás da ferramenta.

Uma requisição HTTP pode possuir:

Método
URL
Headers
Parâmetros
Autenticação
Body
Scripts
Testes
Variáveis

Por exemplo:

POST /orders
Content-Type: application/json
Authorization: Bearer {{token}}

Body:

{
  "customerId": "12345",
  "productId": "A100",
  "quantity": 2
}

O Postman permite construir essa requisição, enviá-la e analisar a resposta.

Mas o salto de maturidade acontece quando paramos de pensar em requests isolados e começamos a pensar em Collections.

Uma Collection não deveria ser apenas uma pasta cheia de requisições.

Ela pode representar um verdadeiro sistema automatizado de testes da API.

E isso muda completamente o jogo.

🗃️ CAPÍTULO 2 — COLLECTION: A BOLSA DO CARTEIRO

Imagine a bolsa do nosso carteiro.

Não faria sentido jogar dentro dela milhares de cartas aleatoriamente.

Ele organiza:

Distrito
 ├── Rua
 │    ├── Número
 │    └── Destinatário

Uma Collection bem construída também precisa possuir estrutura.

Por exemplo:

Orders API
│
├── 01 - Authentication
│
├── 02 - Customers
│   ├── Create Customer
│   ├── Get Customer
│   └── Update Customer
│
├── 03 - Orders
│   ├── Create Order
│   ├── Get Order
│   ├── Update Order
│   └── Cancel Order
│
└── 04 - Negative Tests
    ├── Invalid Token
    ├── Customer Not Found
    ├── Invalid Quantity
    └── Forbidden User

Perceba uma coisa importante.

Estamos começando a transformar a Collection em algo parecido com uma especificação executável.

Ela documenta o sistema.

Ela executa o sistema.

Ela testa o sistema.

Ela pode ser compartilhada.

E posteriormente poderá entrar em um pipeline.

Isso é muito diferente de guardar meia dúzia de URLs.

✉️ CAPÍTULO 3 — PRIMEIRO ENTENDA A CARTA

Antes de criar uma request, precisamos entender o contrato.

Suponha:

POST /orders

Pergunte:

O que devo enviar?

{
  "customerId": "C123",
  "productId": "P987",
  "quantity": 2
}

O que espero receber?

{
  "orderId": "O456",
  "status": "CONFIRMED"
}

Qual status HTTP deveria aparecer?

Talvez:

201 Created

Agora temos uma expectativa.

Entrada:

customerId
productId
quantity

Saída:

orderId
status

Esse conceito deveria soar extremamente familiar para quem programa COBOL.

Pense em:

01 WS-REQUEST.
   05 WS-CUSTOMER-ID PIC X(10).
   05 WS-PRODUCT-ID  PIC X(10).
   05 WS-QUANTITY    PIC 9(03).

01 WS-RESPONSE.
   05 WS-ORDER-ID    PIC X(10).
   05 WS-STATUS      PIC X(10).

Mudou a tecnologia.

O princípio continua parecido:

existe uma estrutura de entrada e existe uma estrutura esperada de saída.

O programador COBOL chama isso de layout.

O desenvolvedor moderno talvez chame de contrato.

O carteiro chama de endereço.

Se qualquer um deles estiver errado, alguém receberá a correspondência errada.

🌐 CAPÍTULO 4 — `200 OK` NÃO SIGNIFICA “TUDO CERTO”

Este talvez seja o conceito mais importante de toda a conversa.

Considere:

GET /customers/123

Resposta:

200 OK

Body:

{
  "customerId": "999",
  "name": "Mario"
}

A camada HTTP funcionou perfeitamente.

Mas a aplicação falhou.

Você pediu:

e recebeu:

Portanto precisamos testar diferentes níveis.

No Postman podemos escrever:

pm.test("HTTP status is 200", function () {
    pm.response.to.have.status(200);
});

Mas podemos continuar:

const customer = pm.response.json();

pm.test("Customer ID is correct", function () {
    pm.expect(customer.customerId).to.eql("123");
});

Agora não estamos apenas perguntando:

O servidor respondeu?

Estamos perguntando:

O servidor respondeu corretamente?

Essa diferença separa um teste superficial de um teste realmente útil.

🧠 CAPÍTULO 5 — O CARTEIRO DESCOBRE AS REGRAS DE NEGÓCIO

Imagine que criamos um pedido.

A resposta é:

{
  "orderId": "4711",
  "status": "REJECTED"
}

E recebemos:

200 OK

O transporte funcionou.

Mas talvez nossa expectativa fosse:

status = CONFIRMED

Portanto:

const order = pm.response.json();

pm.test("Order must be confirmed", function () {
    pm.expect(order.status).to.eql("CONFIRMED");
});

Isso é extremamente importante em sistemas mainframe.

Porque muitas aplicações antigas possuem códigos internos de retorno.

Um programa pode devolver algo conceitualmente semelhante a:

RETURN-CODE = 04
MESSAGE     = CUSTOMER BLOCKED

Enquanto uma camada REST pode responder:

200 OK

Se testarmos somente HTTP, podemos declarar sucesso para uma transação que o negócio considera fracasso.

O teste precisa conhecer o significado da resposta.

O poeta não quer saber apenas se a carta chegou.

Ele quer saber se Beatrice leu o poema certo.

📐 CAPÍTULO 6 — TESTANDO O CONTRATO

Agora podemos subir outro degrau.

Não queremos verificar somente valores.

Também queremos verificar estrutura.

Imagine que nossa API deveria responder:

{
  "orderId": "4711",
  "status": "CONFIRMED",
  "amount": 150.00
}

Mas depois de uma alteração recebemos:

{
  "id": 4711,
  "state": "OK"
}

O serviço respondeu.

Mas o contrato mudou completamente.

Isso pode quebrar consumidores.

Imagine um aplicativo esperando:

response.orderId

e alguém muda para:

response.id

Boom.

Não houve necessariamente ABEND no backend.

Mas houve um ABEND conceitual no consumidor.

Schema validation ajuda a detectar mudanças estruturais desse tipo.

Ela pode verificar coisas como:

campo obrigatório
tipo
formato
estrutura

Mas há uma sutileza.

Schema não prova que o conteúdo está correto.

Isto:

{
  "orderId": "9999",
  "status": "CONFIRMED"
}

pode estar estruturalmente perfeito e ainda pertencer ao cliente errado.

Portanto:

Schema Validation
        +
Business Assertions

são complementares.

🔤 CAPÍTULO 7 — VARIÁVEIS: O WORKING-STORAGE DO POSTMAN

Agora começa uma das partes mais interessantes para quem vem do COBOL.

Em vez de escrever:

https://qa.company.com/api/orders/123

podemos utilizar:

{{baseUrl}}/orders/{{orderId}}

E definir:

baseUrl = https://qa.company.com/api
orderId = 123

Podemos possuir ambientes diferentes:

DEV
QA
STAGING

Mudamos o ambiente.

A Collection continua igual.

Isso é poderosíssimo.

Para um programador COBOL, pense nas variáveis como uma espécie de combinação entre parâmetros, configuração e WORKING-STORAGE.

Mas existe uma armadilha.

Variáveis podem existir em diferentes escopos.

Se houver valores duplicados em locais diferentes, podemos executar um teste utilizando um valor que não imaginávamos.

É o equivalente moderno de perguntar:

Quem alterou essa variável?

E descobrir que existem quatro lugares diferentes onde ela poderia ter sido definida.

Dica de sobrevivência:

sempre investigue o valor resolvido, não apenas o nome escrito na request.

🔐 CAPÍTULO 8 — O CARTEIRO PRECISA MOSTRAR O CRACHÁ

APIs modernas frequentemente utilizam tokens.

Por exemplo:

Authorization: Bearer {{accessToken}}

Em vez de configurar autenticação individualmente em cinquenta requests, podemos defini-la na Collection e permitir herança.

Isso reduz repetição.

Mas surge uma distinção fundamental:

Authentication ≠ Authorization

Authentication pergunta:

Quem é você?

Authorization pergunta:

Você pode fazer isso?

Um usuário pode estar perfeitamente autenticado e ainda não possuir autorização para cancelar um pedido.

Por isso os testes precisam explorar situações como:

token ausente
token inválido
token expirado
usuário autenticado sem permissão

E aqui aparece uma pegadinha maravilhosa.

Você cria um teste chamado:

NO TOKEN

remove o token da request...

...e o teste continua funcionando.

Por quê?

Porque a request herdou a autenticação da Collection.

Seu teste negativo acabou sendo positivo sem você perceber.

É o tipo de bug que faz um QA olhar para a tela durante alguns segundos e começar a reconsiderar suas escolhas profissionais.

⚙️ CAPÍTULO 9 — PRE-REQUEST SCRIPT: PREPARANDO A CARTA

Antes de uma request ser enviada, podemos executar scripts.

Por exemplo, gerar um identificador:

const requestId = pm.variables.replaceIn("{{$guid}}");
pm.collectionVariables.set("requestId", requestId);

Depois enviamos:

X-Request-ID: {{requestId}}

Agora cada transação possui uma identidade.

E aqui nossa história chega ao mainframe.

Imagine:

Postman
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Se o mesmo identificador puder ser correlacionado ao longo desse caminho, investigar um problema se torna muito mais poderoso.

Em vez de procurar:

aquela transação que aconteceu mais ou menos às 14:32...

podemos procurar:

Request-ID = 8f7a...

Isso aproxima teste de observabilidade.

E observabilidade é quando o carteiro não sabe apenas que saiu da agência: ele consegue descobrir por quais ruas a carta passou.

🔗 CAPÍTULO 10 — UMA CARTA LEVA À OUTRA

Agora criamos um pedido:

POST /orders

Resposta:

{
  "orderId": "4711"
}

Podemos capturar esse ID:

const body = pm.response.json();

pm.collectionVariables.set(
    "orderId",
    body.orderId
);

A próxima request utiliza:

GET /orders/{{orderId}}

Depois:

PUT /orders/{{orderId}}

Finalmente:

DELETE /orders/{{orderId}}

Criamos um workflow:

CREATE
   ↓
READ
   ↓
UPDATE
   ↓
DELETE

Isso é muito mais poderoso do que requests isoladas.

Estamos testando uma jornada.

💣 CAPÍTULO 11 — TESTE O QUE DEVERIA DAR ERRADO

Desenvolvedores naturalmente gostam de testar:

entrada correta → resultado correto

Mas sistemas reais vivem no território de:

entrada errada
campo ausente
valor máximo
valor mínimo
token expirado
registro inexistente
duplicidade
timeout
permissão insuficiente

Um excelente princípio é:

altere uma condição de cada vez.

Se você alterar cinco coisas simultaneamente e receber erro, não saberá qual delas provocou o comportamento.

Comece com um baseline válido.

Depois altere somente:

quantity = -1

Depois:

quantity = 0

Depois:

quantity = 1

E chegamos aos testes de fronteira.

📏 CAPÍTULO 12 — COBOL ADORA FRONTEIRAS

Suponha:

05 WS-AGE PIC 9(02).

O campo possui limitações claras.

Em APIs também precisamos pensar em limites.

Se uma regra aceita valores entre 1 e 100:

MIN - 1 = 0
MIN     = 1
MIN + 1 = 2

MAX - 1 = 99
MAX     = 100
MAX + 1 = 101

Não teste apenas:

O valor 50 provavelmente funciona.

Os monstros costumam morar nas bordas.

Esse princípio aparece em praticamente todas as gerações de computação.

Cartão perfurado, COBOL, Db2, Java, REST ou JSON: limites continuam sendo lugares maravilhosos para encontrar bugs.

📚 CAPÍTULO 13 — UMA REQUEST, CEM CARTAS

Imagine testar:

quantity

com dezenas de valores.

Não queremos duplicar a mesma request cinquenta vezes.

Podemos usar dados externos.

Por exemplo:

quantity,expectedStatus
1,201
2,201
0,400
-1,400
101,400

No teste:

const expected =
    Number(pm.iterationData.get("expectedStatus"));

pm.test("Expected HTTP status", function () {
    pm.expect(pm.response.code).to.eql(expected);
});

Agora temos data-driven testing.

A lógica do teste permanece.

Os dados mudam.

Programadores COBOL deveriam reconhecer imediatamente a beleza disso.

É quase como um processamento batch:

READ INPUT
PERFORM PROCESS-RECORD
PERFORM VALIDATE
READ NEXT

O Postman Runner passa a executar diferentes iterações sobre a mesma lógica.

O velho batch está sorrindo discretamente no fundo da sala.

🏃 CAPÍTULO 14 — COLLECTION RUNNER: O BATCH DAS APIs

Chega uma hora em que clicar em Send deixa de fazer sentido.

Temos:

20 requests
50 datasets
30 assertions
4 workflows

Queremos executar tudo.

É aí que entra o Runner.

Conceitualmente:

Inicializa
   ↓
Carrega ambiente
   ↓
Executa request
   ↓
Executa testes
   ↓
Armazena variáveis
   ↓
Executa próxima request
   ↓
Gera resultados

Parece familiar?

Claro.

Isso é praticamente a filosofia batch reaparecendo em roupas modernas.

A tecnologia mudou.

A ideia de processamento repetível e automatizado continua conosco.

🧹 CAPÍTULO 15 — O FANTASMA DO ESTADO ANTERIOR

Um dos bugs mais traiçoeiros em testes automatizados é o estado residual.

Imagine que ontem:

orderId = 4711

Hoje o POST falha.

Mas a variável ainda contém:

A próxima request executa:

GET /orders/4711

e funciona.

Resultado?

Parece que o workflow passou.

Mas estamos consultando o pedido de ontem.

Esse é um falso positivo perigosíssimo.

Por isso suítes maduras precisam pensar em:

setup
execução
validação
cleanup

Teste repetível significa:

posso executá-lo novamente sem depender dos fantasmas deixados pela execução anterior.

🔦 CAPÍTULO 16 — DEBUGUE NA ORDEM CERTA

Quando algo falhar, não comece alterando JavaScript aleatoriamente.

Siga uma investigação disciplinada:

Endpoint
   ↓
Environment
   ↓
Variáveis resolvidas
   ↓
Authentication
   ↓
Headers
   ↓
Request body
   ↓
Response
   ↓
Scripts
   ↓
Dados
   ↓
Ordem do workflow

Se funciona individualmente mas falha no Runner, desconfie especialmente de:

ordem
estado
variáveis
dados
dependências

Essa disciplina lembra investigação de incidente no mainframe.

Você não começa culpando o COBOL.

Primeiro reconstrói o caminho.

📖 CAPÍTULO 17 — UMA COLLECTION DEVE SOBREVIVER AO SEU CRIADOR

Chegamos a uma pergunta excelente:

Se eu entregar minha Collection para outro desenvolvedor, ele consegue executá-la?

Se a resposta for:

“Sim, mas primeiro preciso explicar umas quinze coisas...”

a documentação ainda não está boa.

Explique:

objetivo
pré-requisitos
ambiente
autenticação
variáveis
ordem de execução
dados necessários
resultado esperado

Inclua exemplos.

Remova segredos.

Nunca transforme uma Collection compartilhada em cofre de:

password
API key
client secret
token permanente

Uma suíte de testes também é código.

Trate-a como tal.

🚂 CAPÍTULO 18 — A COLLECTION ENTRA NO CI/CD

Aqui acontece a grande transformação.

Antes:

Programador
   ↓
Postman
   ↓
Send

Depois:

Commit
   ↓
Build
   ↓
Deploy QA
   ↓
API Tests
   ↓
Resultado
   ↓
Pipeline continua ou falha

Agora o teste deixa de depender de alguém lembrar de apertar um botão.

Podemos executar smoke tests depois do deploy.

Podemos executar regressão.

Podemos impedir que uma mudança incompatível avance silenciosamente.

Em um ambiente mainframe moderno, podemos imaginar:

Git
 ↓
COBOL + COPYBOOK
 ↓
DBB / Build
 ↓
Deploy
 ↓
z/OS Connect
 ↓
Postman API Tests
 ↓
CICS
 ↓
COBOL
 ↓
Db2

O COBOL não deixou de ser COBOL.

O mainframe não deixou de ser mainframe.

Nós simplesmente construímos uma estrada moderna até ele.

🧬 CAPÍTULO 19 — O MAPA MENTAL DO PROGRAMADOR COBOL

Se você está começando em APIs, guarde esta tradução mental:

POSTMAN                    COBOL / MAINFRAME

Iteration Data       →     Arquivo de entrada
Variables            →     WORKING-STORAGE/configuração
Pre-request Script   →     Inicialização
HTTP Request         →     Chamada/transação
JSON Body            →     Estrutura de dados
Response             →     Estrutura retornada
pm.test              →     Validação
Collection           →     Conjunto organizado de processos
Runner               →     Batch automatizado
Environment          →     DEV / QA / PROD
Workflow             →     Sequência transacional
CI/CD                →     Esteira automatizada
Correlation ID       →     Identidade rastreável da transação

Não são equivalências tecnológicas perfeitas.

São pontes mentais.

E pontes são extremamente úteis quando estamos aprendendo um mundo novo.

🕵️ CAPÍTULO 20 — O NÍVEL QUE QUASE NINGUÉM ENSINA

Existe ainda um passo além.

Imagine que um teste falhou:

POST /payment

Resposta:

500 Internal Server Error

Uma suíte básica informa:

FAILED

Uma engenharia madura pergunta:

Por quê?

Imagine conseguir seguir:

Postman
   │
   │ correlation-id = POETA-0317
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
TRANSACTION ABCD
   ↓
COBOL PAYMENT01
   ↓
Db2
   ↓
SQLCODE -911

Agora não temos apenas automação.

Temos rastreabilidade.

O teste encontrou o sintoma.

A observabilidade mostrou o caminho.

Os logs forneceram evidência.

O mainframe revelou a causa.

🥚 EASTER EGG

Se algum dia encontrar nos exemplos do Bellacosa Mainframe uma transação executada exatamente às:

03:17

não tente corrigir o relógio.

O mainframe sabe perfeitamente que horas são.

Algumas transações simplesmente preferem trabalhar no turno da madrugada.

🎓 EPÍLOGO — O POETA FINALMENTE ENTENDEU O CARTEIRO

No começo de nossa história, tínhamos:

URL
 ↓
Send
 ↓
200 OK

Parecia suficiente.

Depois descobrimos um universo inteiro:

API CONTRACT
      ↓
COLLECTION
      ↓
ENVIRONMENT
      ↓
VARIABLES
      ↓
AUTHENTICATION
      ↓
PRE-REQUEST
      ↓
REQUEST
      ↓
RESPONSE
      ↓
ASSERTIONS
      ↓
SCHEMA
      ↓
BUSINESS RULES
      ↓
NEGATIVE TESTS
      ↓
BOUNDARIES
      ↓
WORKFLOWS
      ↓
DATA-DRIVEN TESTS
      ↓
RUNNER
      ↓
DEBUG
      ↓
DOCUMENTATION
      ↓
CI/CD
      ↓
OBSERVABILITY

Essa é a verdadeira evolução.

Você começa testando uma API.

Depois constrói uma suíte.

Depois transforma essa suíte em regressão.

Depois conecta a regressão ao pipeline.

Finalmente conecta os testes à observabilidade e consegue seguir uma transação desde o mundo distribuído até o programa COBOL que executou a regra de negócio.

E então acontece algo curioso.

A tecnologia mais moderna da arquitetura encontra uma das mais antigas.

JSON encontra COPYBOOK.

REST encontra CICS.

OAuth encontra RACF.

CI/CD encontra COBOL.

Postman encontra z/OS.

E nenhum deles precisa destruir o outro.

Porque modernizar mainframe não significa necessariamente arrancar o coração da aplicação e reescrevê-lo.

Às vezes significa simplesmente construir melhores caminhos para chegar até ele.

É justamente aí que O Carteiro e o Poeta se torna uma metáfora perfeita.

O carteiro domina o transporte.

O poeta domina o significado.

Uma boa API precisa dos dois.

Não basta entregar bytes.

Precisamos entregar os bytes certos, ao serviço certo, com a identidade certa, na sequência certa, respeitando o contrato certo e produzindo o resultado de negócio esperado.

Da próxima vez que o Postman mostrar:

200 OK

não feche o teste.

Olhe para aquele verde bonito e pergunte:

“Muito bem, carteiro. Você entregou a carta. Agora me prove que entregou a carta certa.”

☕ Porque no Bellacosa Mainframe, até uma API precisa apresentar evidências antes de sair da War Room.

sábado, 21 de setembro de 2024

A História da Integração Corporativa sem Mistérios

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:

formato próprio;
protocolo próprio;
lógica própria;
segurança própria;
tratamento de erros próprio;
documentação própria — quando existe documentação.

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:

transporte de mensagens;
transformação de formatos;
roteamento;
segurança;
controle transacional;
registro de eventos;
monitoramento;
tratamento de falhas.

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:

entrega garantida;
persistência;
unidades de trabalho;
controle de filas;
segurança;
recuperação;
integração entre diferentes plataformas.

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:

MQSeries Integrator;
WebSphere Message Broker;
IBM Integration Bus;
IBM App Connect Enterprise.

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:

HTTP;
URLs;
métodos como GET, POST, PUT e DELETE;
JSON.

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:

no mainframe;
em datacenters;
em nuvens públicas;
em SaaS;
em ambientes de parceiros;
em containers.

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:

implantação automatizada;
escalabilidade;
recuperação;
isolamento;
atualização controlada;
integração com pipelines de CI/CD.

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:

APIs;
eventos;
conectores;
serviços;
fluxos;
funções;
regras;
componentes de segurança.

É 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:

sugerir mapeamentos;
gerar documentação;
analisar logs;
detectar anomalias;
explicar erros;
identificar gargalos;
recomendar rotas;
criar testes;
auxiliar no desenvolvimento de fluxos.

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:

identificador da transação;
horário;
origem;
destino;
resultado;
código de erro;
tempo de processamento.

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:

como monitorar;
como reiniciar;
como identificar mensagens presas;
como tratar erros;
quem deve ser acionado.

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:

1º de fevereiro de 2026?
2 de janeiro de 2026?
um código sem significado de data?

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:

caracteres;
números formatados;
flags;
bytes especiais;
dados binários tratados como área alfanumérica.

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:

autentica o cliente;
valida o token;
controla o limite de chamadas;
encaminha a requisição.

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:

enviar notificação;
atualizar CRM;
gerar contrato;
alimentar analytics;
iniciar o processo contábil.

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:

XML;
JSON;
UTF-8;
REST;
HTTP;
métodos e códigos de resposta.

Quarto nível: plataformas

Explore:

IBM App Connect Enterprise;
z/OS Connect;
API gateways;
Kafka;
IBM Event Streams.

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.

Translate

terça-feira, 3 de fevereiro de 2026