Translate

Mostrar mensagens com a etiqueta integração sistemas. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta integração sistemas. Mostrar todas as mensagens

sexta-feira, 13 de março de 2020

☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Bellacosa Mainframe introdução a API RestFul


☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Imagine a seguinte situação.

Você está em um banco em 1985. Um programa COBOL executando em um IBM Mainframe processa milhões de transações diariamente. Tudo funciona perfeitamente.

Agora avance para 2026.

O mesmo banco continua utilizando COBOL, CICS, DB2 e z/OS para movimentar bilhões de dólares todos os dias. Porém, existe um detalhe importante: os clientes não acessam mais o sistema através de terminais 3270.

Eles utilizam aplicativos móveis, internet banking, chatbots, APIs, inteligência artificial e até relógios inteligentes.

A pergunta é:

Como um aplicativo moderno conversa com um sistema desenvolvido há décadas?

A resposta, em grande parte dos casos, está em uma tecnologia chamada API RESTful.

Hoje vamos conhecer sua história, origem, criador, funcionamento, curiosidades e entender por que ela se tornou uma das tecnologias mais importantes da computação moderna.


O Que é uma API?

API significa:

Application Programming Interface

ou

Interface de Programação de Aplicações.

Uma API é um conjunto de regras que permite que dois sistemas conversem entre si.

Pense nela como um atendente de restaurante.

Você não entra na cozinha para preparar sua comida.

Você faz um pedido ao garçom.

O garçom leva o pedido.

A cozinha processa.

O garçom retorna o resultado.

A API faz exatamente isso.

Ela recebe solicitações.

Encaminha para o sistema responsável.

Obtém uma resposta.

Entrega o resultado ao solicitante.


O Que Significa REST?

REST significa:

Representational State Transfer

O termo surgiu oficialmente em:

Ano: 2000

Criado por:

Roy Thomas Fielding

Durante sua tese de doutorado na Universidade da Califórnia (UC Irvine).

O trabalho recebeu o nome:

Architectural Styles and the Design of Network-based Software Architectures

Nele, Fielding descreveu um conjunto de princípios para criar sistemas distribuídos mais simples, escaláveis e independentes.

Curiosamente, REST não é uma tecnologia.

Não é um produto.

Não é um software.

Não é um protocolo.

É um estilo arquitetural.


Quem é Roy Fielding?

Roy Fielding é uma das figuras mais importantes da história da Internet.

Além de criar o conceito REST, ele também participou da especificação de tecnologias fundamentais da Web.

Entre elas:

  • HTTP 1.0

  • HTTP 1.1

  • URI

  • Apache HTTP Server

Sim.

O mesmo protocolo HTTP que usamos diariamente para acessar sites recebeu contribuições diretas do criador do REST.

Poucas pessoas sabem disso.


Data de Criação

O conceito REST foi publicado oficialmente em:

2000

Portanto, em 2026, o REST possui:

26 anos de existência

Mesmo assim continua sendo a arquitetura dominante para integração de sistemas.

Algo raro em tecnologia.


Existe uma Versão do REST?

Não.

Esse é um detalhe interessante.

REST não possui:

  • Release 1

  • Release 2

  • Versão 10

REST é apenas um conjunto de princípios arquiteturais.

O que evolui são as tecnologias utilizadas ao seu redor:

  • HTTP

  • JSON

  • XML

  • OpenAPI

  • Swagger

  • OAuth

  • JWT

Por isso não existe algo como:

"REST versão 3.0"


Como Funciona uma API RESTful?

Uma API RESTful utiliza recursos identificados por URLs.

Exemplos:

/clientes
/contas
/cartoes
/emprestimos

Cada URL representa um recurso.

O cliente realiza operações utilizando métodos HTTP.


Os Principais Métodos HTTP

GET

Utilizado para consultar informações.

Exemplo:

GET /clientes/1001

Resposta:

{
  "codigo":1001,
  "nome":"João Silva"
}

POST

Utilizado para criar registros.

Exemplo:

POST /clientes

PUT

Atualiza um recurso existente.

Exemplo:

PUT /clientes/1001

DELETE

Remove um recurso.

Exemplo:

DELETE /clientes/1001

Uma Analogia Mainframe

Imagine um sistema CICS.

No passado, um terminal 3270 enviava uma transação.

Hoje um aplicativo celular faz uma chamada REST.

Fluxo:

App Mobile
      |
      v
API REST
      |
      v
CICS
      |
      v
COBOL
      |
      v
DB2

Para o programa COBOL, pouco muda.

Ele continua processando regras de negócio.

A diferença está na forma de acesso.


Por Que REST Ficou Tão Popular?

Antes do REST, muitas integrações utilizavam:

  • RPC

  • CORBA

  • DCOM

  • SOAP

Essas tecnologias eram poderosas, porém complexas.

REST trouxe:

  • Simplicidade

  • Escalabilidade

  • Facilidade de implementação

  • Menor consumo de recursos

O resultado foi uma adoção massiva.


O Papel do JSON

Embora REST não exija JSON, ambos praticamente cresceram juntos.

JSON significa:

JavaScript Object Notation

Exemplo:

{
  "conta":"12345",
  "saldo":1500.75
}

Comparado ao XML:

<conta>
   <numero>12345</numero>
   <saldo>1500.75</saldo>
</conta>

JSON é menor, mais simples e mais rápido de processar.

Por isso tornou-se o padrão de mercado.


Características Obrigatórias do REST

Roy Fielding definiu restrições importantes.


Cliente-Servidor

Cliente e servidor são independentes.

O aplicativo não precisa conhecer detalhes internos do sistema.


Stateless

Cada requisição deve conter todas as informações necessárias.

O servidor não depende de estados anteriores.

Essa característica facilita escalabilidade.


Cache

Respostas podem ser armazenadas temporariamente.

Isso reduz processamento e tráfego.


Interface Uniforme

Todas as APIs seguem padrões semelhantes.

Isso facilita aprendizado e manutenção.


Sistema em Camadas

O cliente não sabe quantos componentes existem entre ele e o servidor.

Pode haver:

  • Firewalls

  • Gateways

  • Balanceadores

  • Proxies

Tudo permanece transparente.


REST e o Mundo Mainframe

Muitos profissionais acreditam que REST e Mainframe são mundos diferentes.

Nada poderia estar mais distante da realidade.

Hoje encontramos APIs REST acessando:

  • COBOL

  • PL/I

  • Natural

  • CICS

  • IMS

  • DB2

  • VSAM

Praticamente todos os grandes bancos utilizam essa arquitetura.


Exemplo Real

Imagine um aplicativo bancário.

Quando o cliente consulta saldo:

GET /contas/123456/saldo

A API recebe a solicitação.

Ela chama um serviço no CICS.

O CICS executa um programa COBOL.

O COBOL consulta DB2.

O resultado retorna em JSON.

O cliente vê o saldo instantaneamente.

Tudo em poucos milissegundos.


REST no z/OS

Atualmente existem diversas tecnologias IBM para expor aplicações como APIs.

Entre elas:

  • z/OS Connect

  • CICS Web Services

  • CICS REST APIs

  • IBM API Connect

  • IMS Connect

  • MQ REST Gateway

Essas ferramentas transformam aplicações legadas em serviços modernos.


Curiosidade Histórica

Muitos dos sistemas considerados "modernos" dependem diretamente de aplicações desenvolvidas há décadas.

Quando você:

  • Faz um PIX

  • Passa cartão

  • Compra passagem aérea

  • Faz saque bancário

Existe uma grande chance de um programa COBOL estar envolvido.

E frequentemente o acesso ocorre através de APIs REST.


REST vs SOAP

Uma comparação clássica.

RESTSOAP
SimplesComplexo
LevePesado
JSONXML
Fácil adoçãoConfiguração extensa
Mais popular atualmenteMuito usado em legado corporativo

Apesar disso, SOAP continua presente em diversos ambientes bancários.


Segurança em APIs REST

Uma API aberta seria extremamente perigosa.

Por isso existem mecanismos de proteção.

Os principais:

  • HTTPS

  • OAuth 2.0

  • JWT

  • API Keys

  • OpenID Connect

Eles garantem:

  • Autenticação

  • Autorização

  • Criptografia

  • Auditoria


REST e a Era da Inteligência Artificial

A explosão da IA aumentou ainda mais a importância das APIs.

Quando um chatbot consulta informações de um sistema corporativo, normalmente utiliza APIs.

Quando um assistente virtual consulta saldo bancário, utiliza APIs.

Quando aplicações integram modelos de IA com sistemas empresariais, utilizam APIs.

REST tornou-se o idioma universal da integração digital.


O Futuro do REST

Novas tecnologias surgiram.

Entre elas:

  • GraphQL

  • gRPC

  • AsyncAPI

Mesmo assim, REST continua dominante.

O motivo é simples.

Bilhões de aplicações já utilizam esse modelo.

Sua simplicidade continua sendo sua maior vantagem.


Conclusão

APIs RESTful representam uma das maiores revoluções silenciosas da computação moderna.

Criadas por Roy Fielding em 2000, elas permitiram que sistemas de diferentes gerações passassem a conversar de maneira simples, eficiente e padronizada.

Graças ao REST, aplicativos móveis conseguem acessar programas COBOL.

Plataformas de IA conseguem consultar sistemas bancários.

Empresas integram milhares de aplicações diariamente.

E o mais curioso:

Enquanto muita gente acredita que o Mainframe ficou preso ao passado, ele continua movimentando a economia mundial utilizando tecnologias modernas de integração.

Afinal, por trás de muitos aplicativos considerados revolucionários existe algo extremamente familiar para nós, mainframeiros:

um programa COBOL processando regras de negócio com a mesma confiabilidade de décadas atrás.

A diferença é que agora ele conversa com o mundo através de APIs RESTful.

☕💣 Moral da história: REST não substituiu o Mainframe. Pelo contrário. Tornou-se uma das principais pontes que conectam a robustez do COBOL, CICS e DB2 ao universo de aplicativos, nuvem, microsserviços e inteligência artificial. 

quinta-feira, 14 de maio de 2015

☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Bellacosa Mainframe e o IBM Integration Bus (Broker)


 ☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Quando alguém fala em Integration Bus, Broker, Message Broker ou até no antigo MQSeries Integrator… estamos falando de uma das tecnologias mais importantes da integração corporativa moderna.

E no mundo mainframe isso teve — e ainda tem — um impacto gigantesco.


📌 O QUE É O INTEGRATION BUS (BROKER)?

De forma simples:

O IBM Integration Bus (IIB) é um middleware de integração criado pela IBM para:

  • conectar sistemas diferentes

  • transformar dados

  • rotear mensagens

  • integrar aplicações legadas e modernas

  • fazer “sistemas conversarem”

Ele funciona como um:

✅ tradutor
✅ roteador
✅ orquestrador
✅ mediador
✅ transformador de protocolos


📜 EVOLUÇÃO HISTÓRICA

A IBM mudou o nome várias vezes:

NomeÉpoca
MQSeries Integratoranos 90
WebSphere Message Broker (WMB)anos 2000
IBM Integration Bus (IIB)2010+
IBM App Connect Enterprise (ACE)atual

Muita gente no mercado ainda chama tudo de:

👉 “Broker”

Porque o nome ficou eternizado no ambiente corporativo.


🧠 O PROBLEMA QUE ELE RESOLVE

Imagine isso:

Sistema A

Mainframe COBOL
fala:

  • EBCDIC

  • Copybook COBOL

  • MQ

Sistema B

Java/Linux
fala:

  • JSON

  • REST

  • UTF-8

Sistema C

SAP
fala:

  • IDoc

  • XML

Sistema D

Cloud/API
fala:

  • HTTPS

  • OAuth

  • SOAP/REST

Sem um barramento de integração…

🔥 vira caos.

Cada sistema teria que entender diretamente todos os outros.


🎯 O BROKER ENTRA COMO INTERMEDIÁRIO

Ele recebe dados de um lado e entrega no formato correto do outro.

Exemplo:

COBOL + MQ + EBCDIC
        ↓
   Integration Bus
        ↓
JSON + REST + UTF-8

Ou:

CICS → MQ → Broker → API REST → Cloud

🏦 ONDE ELE É MUITO USADO?

Principalmente:

  • bancos

  • seguradoras

  • bolsas financeiras

  • telecom

  • governo

  • varejo

  • empresas gigantes

Porque quase todas possuem:

✅ sistemas legados
✅ mainframe
✅ aplicações distribuídas
✅ cloud
✅ APIs modernas

E alguém precisa integrar tudo isso.


⚙️ COMO ELE FUNCIONA?

O Integration Bus trabalha com:

📦 Message Flows

Fluxos gráficos que definem:

  • entrada

  • transformação

  • regras

  • roteamento

  • saída

Visualmente parece um pipeline.


🧩 COMPONENTES PRINCIPAIS

🔹 Input Node

Recebe mensagens:

  • MQ

  • HTTP

  • File

  • Kafka

  • SOAP

  • REST

  • TCP/IP


🔹 Compute Node

Onde fica a lógica.

Normalmente usando:

  • ESQL

  • Java

  • Mapping

Aqui ele:

  • transforma campos

  • converte layouts

  • altera dados

  • toma decisões


🔹 Mapping Node

Transformação visual:

COPYBOOK COBOL
   ↓
JSON/XML

🔹 Output Node

Entrega para:

  • MQ

  • API

  • banco

  • arquivo

  • Kafka

  • SAP

  • cloud


🧠 O QUE É O ESQL?

O ESQL é a linguagem clássica do Broker.

Parece mistura de:

  • SQL

  • procedural

  • manipulação de mensagem

Exemplo:

SET OutputRoot.JSON.Data.nome =
    InputRoot.XMLNSC.cliente.nome;

Ele transforma estruturas de dados em tempo real.


🔥 O MAINFRAME E O BROKER

Aqui está o ponto interessante.

Muitos ambientes z/OS usam:

  • CICS

  • IMS

  • DB2

  • MQ

  • COBOL

Mas aplicações modernas querem:

  • REST

  • JSON

  • APIs

  • microserviços

O Broker virou a ponte entre esses mundos.


💥 EXEMPLO REAL

Cenário bancário

Mainframe

COBOL envia:

000123JOAO      0000500

Formato fixo EBCDIC.


Broker recebe

Ele:

  • decodifica EBCDIC

  • interpreta copybook

  • converte para UTF-8

  • monta JSON

Resultado:

{
  "conta": 123,
  "nome": "JOAO",
  "saldo": 500
}

API REST recebe

Aplicação cloud consome normalmente.

Tudo transparente.


🚀 O QUE FEZ O BROKER FICAR GIGANTE?

Porque ele resolveu o maior problema corporativo:

integração entre mundos incompatíveis

Ele conecta:

Mundo antigoMundo moderno
COBOLJava
MQREST
VSAMJSON
EBCDICUTF-8
CICSAPIs
BatchCloud

🔥 RELAÇÃO COM IBM MQ

Muita gente confunde.

IBM MQ

transporta mensagens

Broker/IIB

processa e transforma mensagens

Exemplo:

Sistema A
   ↓ MQ
Broker
   ↓ MQ/API
Sistema B

MQ = estrada
Broker = inteligência do tráfego


📦 PRINCIPAIS PROTOCOLOS SUPORTADOS

O Broker suporta praticamente tudo:

  • MQ

  • JMS

  • REST

  • SOAP

  • HTTP

  • HTTPS

  • FTP

  • SFTP

  • Kafka

  • TCP/IP

  • SAP

  • JDBC

  • Files

  • XML

  • JSON

  • CSV

  • FIX

  • SWIFT


🧠 POR QUE ISSO FOI REVOLUCIONÁRIO?

Antes dele:

❌ integrações ponto a ponto
❌ spaghetti architecture
❌ milhares de interfaces manuais
❌ manutenção infernal

Depois dele:

✅ centralização
✅ transformação padronizada
✅ governança
✅ desacoplamento
✅ reutilização


⚠️ MAS EXISTEM DESAFIOS

Integration Bus também pode virar:

🔥 “monólito de integração”

Quando:

  • tudo passa por ele

  • todas regras ficam centralizadas

  • ninguém documenta

  • flows crescem demais

Resultado:

❌ complexidade absurda
❌ debugging difícil
❌ dependência gigante
❌ gargalos


🏗️ O QUE VEIO DEPOIS?

Hoje existe forte movimento para:

  • microservices

  • event streaming

  • Kafka

  • API Gateway

  • cloud integration

Mas…

🔥 o Broker continua fortíssimo em empresas enterprise.

Especialmente onde:

  • existe mainframe

  • há MQ pesado

  • integração crítica

  • alto volume transacional


📌 NO MAINFRAME MODERNO

O Broker/ACE virou peça estratégica para:

✅ expor APIs do CICS
✅ integrar COBOL com cloud
✅ transformar copybooks em JSON
✅ integrar DB2 com REST
✅ conectar Kafka ao z/OS
✅ modernização gradual


🎯 RESUMO FINAL

O IBM Integration Bus/Broker é:

“o sistema que faz sistemas incompatíveis conversarem.”

Ele foi — e continua sendo — um dos pilares da integração corporativa entre:

☕ legado
🔥 middleware
🚀 cloud
🏦 mainframe
🌎 APIs modernas

Sem ele, boa parte do mundo corporativo ainda estaria presa em integrações caóticas ponto a ponto.

sábado, 24 de março de 2007

Como Funciona o FTP no Ambiente Mainframe (Modo Batch e Modo Online)

 

Bellacosa Mainframe tranferindo arquivos com FTP

Como Funciona o FTP no Ambiente Mainframe (Modo Batch e Modo Online)

O FTP (File Transfer Protocol) é uma das formas mais tradicionais de transferir arquivos entre Mainframes, servidores Linux, Windows, Unix e plataformas Cloud.

No z/OS, o FTP pode ser executado de duas formas:

Modo Online (TSO)

Modo Batch (JCL)


O que é FTP?

FTP significa:

File Transfer Protocol

É um protocolo utilizado para:

  • Enviar arquivos

  • Receber arquivos

  • Trocar datasets

  • Integrar sistemas


Arquitetura Básica

Mainframe
     ↓
FTP
     ↓
Servidor Linux

ou

Mainframe A
      ↓
FTP
      ↓
Mainframe B

Modos de Transferência

ASCII

Converte caracteres.

Utilizado para:

JCL
COBOL
TXT
PROC

BINARY

Não converte conteúdo.

Utilizado para:

LOADLIB
XMIT
ZIP
PDF
Executáveis

FTP Online (TSO)

Executado diretamente no terminal TSO.


Passo 1 – Entrar no FTP

No prompt TSO:

FTP 192.168.1.100

ou

FTP servidor.empresa.com

Passo 2 – Informar Usuário

Name:

Digite:

USER01

Passo 3 – Informar Senha

Password:

Digite:

*******

Conexão Estabelecida

Connected to server.

Comandos Básicos


Listar Diretório

LS

ou

DIR

Mudar Diretório

CD /home/arquivos

Ver Diretório Atual

PWD

Enviando Arquivos

Exemplo

Dataset:

USER.CLIENTES

Comando:

PUT 'USER.CLIENTES' clientes.txt

Fluxo:

Dataset Mainframe
      ↓
PUT
      ↓
Arquivo Linux

Recebendo Arquivos

GET clientes.txt 'USER.CLIENTES'

Fluxo:

Linux
 ↓
GET
 ↓
Dataset z/OS

Definindo Modo ASCII

ASCII

Definindo Modo BINARY

BINARY

Exemplo Completo Online

FTP servidor.empresa.com

USER user01
PASS senha

ASCII

PUT 'USER.COBOL.SOURCE(MEUCOBOL)' programa.cbl

QUIT

Resultado:

programa.cbl

enviado para o servidor.


FTP Batch (JCL)

Muito utilizado em produção.


Vantagens

✅ Automação

✅ Execução noturna

✅ Integração Batch

✅ Sem intervenção humana


Estrutura Básica

//FTPJOB JOB ...
//STEP01 EXEC PGM=FTP
//SYSPRINT DD SYSOUT=*
//INPUT DD *
...
/*

Exemplo 1 – Enviar Arquivo

//FTPJOB JOB CLASS=A,MSGCLASS=X

//FTPSTEP EXEC PGM=FTP
//SYSPRINT DD SYSOUT=*
//OUTPUT   DD SYSOUT=*
//INPUT DD *

192.168.1.100

USER01
SENHA

ASCII

PUT 'USER.CLIENTES' clientes.txt

QUIT

/*

Fluxo

JCL
 ↓
FTP
 ↓
Servidor
 ↓
clientes.txt

Exemplo 2 – Receber Arquivo

//FTPJOB JOB CLASS=A

//FTPSTEP EXEC PGM=FTP
//SYSPRINT DD SYSOUT=*
//INPUT DD *

192.168.1.100

USER01
SENHA

ASCII

GET clientes.txt 'USER.CLIENTES'

QUIT

/*

Exemplo 3 – Transferindo XMIT

Arquivo:

USER.COBOL.XMIT

Sempre usar:

BINARY

JCL:

//FTPSTEP EXEC PGM=FTP
//INPUT DD *

192.168.1.100

USER01
SENHA

BINARY

PUT 'USER.COBOL.XMIT' COBOL.XMIT

QUIT

/*

Recebendo Arquivo XMIT

GET COBOL.XMIT 'USER.COBOL.XMIT'

Depois:

RECEIVE INDSN('USER.COBOL.XMIT')

FTP Entre Mainframes

Muito comum.


Mainframe A:

BANCO A

PUT 'PROD.CLIENTES'

BANCO B

Criando Dataset Remoto

Muitos servidores FTP do z/OS aceitam:

SITE

Exemplo:

SITE RECFM(F B) LRECL(80) BLKSIZE(8000)

Depois:

PUT CLIENTES.TXT 'USER.CLIENTES'

SITE Command

Muito importante.

Permite definir:

  • LRECL

  • BLKSIZE

  • RECFM

  • SPACE


Exemplo

SITE

RECFM(FB)
LRECL(80)
CYLINDERS
PRIMARY=5
SECONDARY=2

FTP Seguro

Atualmente utiliza-se:

FTPS

FTP com TLS.


SFTP

Via SSH.


Fluxo:

Mainframe
 ↓
SFTP
 ↓
Linux

Exemplos de Uso Real


Banco

PIX
 ↓
FTP
 ↓
Arquivo BACEN

Seguradora

Batch Noturno
 ↓
FTP
 ↓
Parceiro

Governo

Arrecadação
 ↓
FTP
 ↓
Receita

Erros Mais Comuns

Login Inválido

530 Login Incorrect

Dataset Não Encontrado

550 File Not Found

Permissão Negada

550 Access Denied

ASCII x BINARY

Erro clássico.

Enviar XMIT em ASCII:

Arquivo Corrompido

Correto:

BINARY

Boas Práticas

✅ XMIT → BINARY

✅ LOADLIB → BINARY

✅ Texto COBOL → ASCII

✅ Usar FTPS/SFTP

✅ Automatizar via JCL

✅ Validar retorno FTP


Resumo Rápido

ComandoFunção
FTP hostConectar
PUTEnviar
GETReceber
ASCIIModo texto
BINARYModo binário
DIRListar
CDTrocar diretório
QUITEncerrar
SITEDefinir atributos
RECEIVERestaurar XMIT

Exemplo Clássico de Produção

JOB Batch
      ↓
FTP
      ↓
Arquivo Remessa
      ↓
Banco Parceiro
      ↓
Processamento
      ↓
Arquivo Retorno
      ↓
FTP GET
      ↓
Mainframe

Esse é um dos cenários mais comuns em bancos, seguradoras, telecomunicações e órgãos governamentais que utilizam Mainframe para integração de arquivos em larga escala.