Translate

Mostrar mensagens com a etiqueta Workflow. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Workflow. Mostrar todas as mensagens

quarta-feira, 1 de maio de 2024

☕💣 OPERADOR, O TRELLO ACABOU DE RECEBER ORDENS DE UM AGENTE PYTHON! — Construindo um Organizador Inteligente de Tarefas do Zero e Entendendo Como Nasce um Agente de IA

Bellacosa Mainframe crie um agente organizador Trello com o Python


☕💣 OPERADOR, O TRELLO ACABOU DE RECEBER ORDENS DE UM AGENTE PYTHON! — Construindo um Organizador Inteligente de Tarefas do Zero e Entendendo Como Nasce um Agente de IA

Imagine a seguinte cena.

São 2 horas da manhã.

O operador monitora dezenas de sistemas.

Há tarefas para acompanhar, chamados para abrir, solicitações para registrar, atividades para priorizar e uma equipe inteira esperando informações.

De repente surge uma pergunta:

"Por que ainda estamos criando tarefas manualmente?"

Foi exatamente essa pergunta que levou ao nascimento dos primeiros sistemas de automação, dos workflows corporativos e, mais recentemente, dos Agentes de Inteligência Artificial.

Hoje vamos construir um projeto extremamente importante para quem está entrando no universo dos agentes: um Organizador de Tarefas em Python integrado ao Trello.

Mas não vamos apenas escrever código.

Vamos entender arquitetura, dependências, APIs, tratamento de erros, segurança, evolução para IA e como tudo isso se conecta ao mundo corporativo e até ao universo Mainframe.

Pegue seu café.

O job acabou de entrar na fila.


O Que Estamos Construindo?

Nosso projeto será um agente capaz de:

  • Conectar-se ao Trello

  • Criar tarefas automaticamente

  • Consultar tarefas existentes

  • Mover tarefas entre listas

  • Organizar fluxos de trabalho

  • Servir como base para futuros agentes inteligentes

Visualmente teremos algo assim:

Python Agent
      ↓
API REST
      ↓
Trello
      ↓
Cards
      ↓
Workflow

Parece simples.

Mas essa mesma arquitetura é utilizada em:

  • Jira

  • ServiceNow

  • Salesforce

  • SAP

  • Zendesk

  • GitHub

  • Azure DevOps

E até em plataformas de automação como N8N.


O Que é um Agente?

Muita gente acredita que um agente é sinônimo de IA.

Não necessariamente.

Um agente é um software que:

  • Observa

  • Analisa

  • Decide

  • Executa

Nosso primeiro agente ainda não terá inteligência artificial.

Mas ele já será capaz de agir sozinho.

Isso é exatamente o primeiro estágio da evolução.


O Trello Como Ambiente de Trabalho

Antes de escrever uma linha de código precisamos preparar o Trello.

Crie uma conta.

Depois crie um Board.

Exemplo:

Projeto DIO

Agora crie três listas:

To Do

Doing

Done

Quem já trabalhou com Kanban reconhecerá imediatamente o modelo.

O fluxo é simples:

Pendente
    ↓
Executando
    ↓
Concluído

Obtendo as Credenciais

Assim como um terminal CICS exige autenticação, a API do Trello também exige.

Você precisará obter:

  • API Key

  • API Token

Essas informações funcionam como usuário e senha para seu agente.

Sem elas o Trello recusará todas as solicitações.


Instalando o Python

Verifique a instalação:

python --version

ou

python3 --version

Resultado esperado:

Python 3.10+

Se aparecer erro:

python não é reconhecido

Significa que o Python não está instalado ou não foi adicionado ao PATH.


Criando o Ambiente Virtual

Uma das melhores práticas modernas.

Crie:

python -m venv venv

Ative:

Windows

venv\Scripts\activate

Linux

source venv/bin/activate

Quando ativado:

(venv)

aparecerá antes do prompt.


Instalando Dependências

Nosso agente precisa conversar com APIs.

Instalaremos:

pip install requests python-dotenv

Essas bibliotecas possuem funções importantes.

Requests:

Consumir APIs REST

Dotenv:

Carregar variáveis seguras

Estrutura do Projeto

Organização é fundamental.

Criamos:

agente_trello/

├── app.py
├── trello.py
├── view.py
├── .env
├── requirements.txt
└── README.md

Observe que estamos separando responsabilidades.

Essa é uma prática muito valorizada em ambientes corporativos.


O Papel do app.py

Ele funciona como o maestro.

Controla:

  • Menus

  • Fluxo principal

  • Chamadas ao agente

Em Mainframe seria semelhante ao programa principal que coordena outros módulos.


O Papel do trello.py

Aqui fica toda a comunicação com a API.

Esse módulo:

  • Cria Cards

  • Consulta Cards

  • Move Cards

  • Testa conexão

Em uma analogia com COBOL:

Programa Principal
      ↓
Sub-rotina de acesso
      ↓
Banco/API

O Papel do view.py

Responsável pela apresentação.

Separar interface da lógica é uma prática extremamente importante.

Isso permite futuramente trocar:

Terminal

por

Web

ou

Dashboard

sem alterar a lógica do agente.


Variáveis de Ambiente

Nunca coloque credenciais no código.

Use:

TRELLO_KEY=
TRELLO_TOKEN=
TODO_ID=
DOING_ID=
DONE_ID=

Isso protege informações sensíveis.

É o equivalente moderno de esconder senhas em datasets protegidos por RACF.


Primeiro Teste

Execute:

python app.py

Escolha:

1 - Testar conexão

Se tudo estiver correto:

Conexão OK

Problemas Comuns

Erro 401

Unauthorized

Significa:

  • Token inválido

  • Chave inválida


Erro 404

Not Found

Significa:

  • Lista inexistente

  • ID incorreto


Erro de Importação

ModuleNotFoundError

Normalmente:

pip install requests

resolve.


Criando Seu Primeiro Card

Selecione:

Criar tarefa

Digite:

Estudar Agentes

O agente enviará:

{
  "name":"Estudar Agentes"
}

para o Trello.

Resultado:

Card criado

Instantaneamente.


Listando Tarefas

O agente consulta a API.

Recebe:

[
 {
   "name":"Estudar Python"
 }
]

e exibe:

Estudar Python

Simples.

Mas extremamente poderoso.


Movendo Tarefas

Imagine:

To Do

Ao iniciar:

Doing

Ao terminar:

Done

Nosso agente realiza isso automaticamente.

Na prática ele apenas altera um identificador interno do Trello.

Mas para o usuário parece mágica.


O Que Está Acontecendo nos Bastidores?

Quando você cria um card:

Python
   ↓
HTTP POST
   ↓
API Trello
   ↓
Banco de Dados Trello
   ↓
Resposta JSON

Isso é exatamente o mesmo conceito utilizado por:

  • APIs bancárias

  • APIs governamentais

  • APIs corporativas


Transformando em um Agente Inteligente

Agora vem a parte interessante.

Suponha que uma tarefa seja criada:

Sistema parado em produção

Uma IA pode analisar.

Resultado:

Prioridade Alta

O agente decide:

Mover para Urgente

sem intervenção humana.

Nesse momento ele deixa de ser apenas automação.

Passa a tomar decisões.


Integrando OpenAI

Exemplo conceitual:

prioridade = analisar_tarefa(descricao)

Resposta:

ALTA

O agente pode então:

if prioridade == "ALTA":
    mover_para_urgente()

Agora temos comportamento inteligente.


Integrando Ollama

Nem sempre você quer depender da nuvem.

Com Ollama é possível executar modelos locais.

Exemplos:

  • Llama

  • DeepSeek

  • Mistral

Tudo rodando em sua máquina.


Integração com N8N

Imagine:

Novo E-mail
       ↓
Webhook
       ↓
N8N
       ↓
Agente Python
       ↓
Trello

Nenhum ser humano participa.

O processo inteiro acontece sozinho.


E o Mainframe?

Agora vem a parte favorita do Bellacosa.

Imagine um JOB.

BILLJOB

executa.

O agente monitora o JES2.

Detecta:

ABEND S0C7

Automaticamente:

Lê SYSOUT

Depois:

Cria Card Trello

Em seguida:

Notifica equipe

E finalmente:

Abre incidente

Tudo sozinho.

Percebe o potencial?


O Caminho da Evolução

Nível 1:

Script

Nível 2:

Automação

Nível 3:

Workflow

Nível 4:

Agente

Nível 5:

Multiagentes

É exatamente essa trilha que está sendo seguida pela indústria.


Conclusão

Muitos enxergam esse projeto apenas como um exercício simples da DIO.

Mas ele é muito mais que isso.

Você está aprendendo:

  • Python

  • APIs REST

  • Integração entre sistemas

  • Variáveis de ambiente

  • Automação

  • Arquitetura de agentes

  • Fundamentos de IA

  • Boas práticas corporativas

O Organizador de Tarefas é apenas o começo.

A mesma arquitetura pode evoluir para:

  • Assistentes corporativos

  • Agentes DevOps

  • Agentes FinOps

  • Agentes Mainframe

  • Agentes de atendimento

  • Agentes de monitoramento

E talvez, em um futuro não muito distante, você veja uma mensagem parecida com esta aparecendo no terminal:

☕💣 OPERADOR!

Detectei um problema no sistema.

Já analisei os logs.
Já consultei incidentes anteriores.
Já criei o Card no Trello.
Já notifiquei a equipe.

Deseja apenas acompanhar... ou quer que eu resolva o problema também?

sexta-feira, 5 de agosto de 2022

☕💥 IBM BPM: O Reino dos Fluxos, Aprovações e Processos

 

Bellacosa Mainframe apresenta o ibm bpm

☕💥 IBM BPM: O Reino dos Fluxos, Aprovações e Processos

Ou como um Padawan COBOL descobre que existe um CICS para humanos preencherem formulários

"Se CICS conversa com terminais 3270, IBM BPM conversa com pessoas, departamentos inteiros e regras de negócio espalhadas pelo planeta."

Bellacosa Mainframe


Introdução

Uma das maiores descobertas que um desenvolvedor COBOL faz ao sair do mundo Batch, CICS, VSAM e DB2 é perceber que muitas aplicações corporativas não processam apenas dados.

Elas processam algo muito mais complicado.

Elas processam pessoas.

E pessoas são extremamente difíceis de programar.

Arquivos VSAM obedecem.

DB2 obedece.

MQ obedece.

JCL obedece.

Usuários?

Nunca.

Um gerente pode aprovar em cinco minutos.

Outro pode levar três dias.

Compliance pode devolver.

Jurídico pode rejeitar.

Diretoria pode pedir ajustes.

É justamente para organizar esse caos corporativo que surgiu o BPM.

Business Process Management.

Ou simplesmente:

IBM BPM.


O que é IBM BPM?

IBM BPM significa:

Business Process Manager.

É uma plataforma destinada à modelagem, execução, monitoramento e automação de processos de negócio.

Pense nele como:

Um CICS para departamentos.

Um JES2 para aprovações.

Um Workflow Engine corporativo.

Um coordenador digital.


A origem do BPM

Década de 1980.

Empresas começaram a perceber algo curioso.

Automatizar programas não bastava.

Era preciso automatizar decisões.

Exemplo.

Solicitação de empréstimo.

Analista.

Supervisor.

Compliance.

Diretor.

Liberação.

Antes.

Tudo papel.

Depois.

Email.

Depois.

Workflow.


Década de 1990.

Surge o conceito BPM.

Business Process Management.


Aquisições importantes da IBM

A IBM percebeu o potencial.

Adquiriu duas empresas importantes.

Lombardi Software

Produto:

Teamworks

Especialidade:

Processos humanos


FileNet

Especialidade:

ECM

Documentos

Workflow

Case Management


Da união surgiu.

IBM BPM.


Primeiros releases

IBM BPM 7.5

2011


IBM BPM 8.0

2013


IBM BPM 8.5

2014


IBM BPM 8.6

2016


IBM BPM 8.6 CF

2017-2019


Posteriormente evoluiu para:

IBM Business Automation Workflow

BAW

Atualmente é o sucessor.


Filosofia

IBM BPM trabalha com:

Processos

Pessoas

Regras

Eventos

Integrações


Componentes

Process Designer

Desenha fluxos.


Process Center

Repositório.


Process Server

Executa.


Integration Designer

Integra sistemas.


Process Portal

Interface usuário.


Como funciona

Exemplo.

Solicitar cartão.

Cliente

Abrir pedido

Gerente

Análise crédito

Compliance

Emitir cartão

Fim


Cada etapa.

Pode esperar.

Horas.

Dias.

Semanas.


BPMN

IBM BPM usa.

BPMN 2.0

Business Process Model Notation


Elementos.

Evento

Tarefa

Gateway

Timer

Mensagem


Parece um fluxograma.

Só que muito mais poderoso.


Exemplo BPM

Solicitação de férias.

Start

Funcionário

Preencher formulário

Gestor aprova?

Gateway

Sim

RH

Fim

Não

Retorna funcionário


Gateway

É praticamente.

Nosso velho losango.


COBOL


IF APROVADO='S'

BPM

Gateway.


Como um desenvolvedor COBOL deve enxergar IBM BPM

Pense assim.

COBOL

Processa registros.

IBM BPM

Processa pessoas.


COBOL

PERFORM

IBM BPM

Human Task


COBOL

IF

IBM BPM

Exclusive Gateway


COBOL

JCL

IBM BPM

Scheduler


COBOL

COMMIT

IBM BPM

Milestone


Exemplo integrando Mainframe

Cliente solicita empréstimo.

IBM BPM

API

zOS Connect

CICS

COBOL

DB2

Resposta

BPM

Gerente

Aprovação


Passo a passo

Instalação

Necessário.

Linux

Windows

AIX


WebSphere Application Server


DB2

Oracle

SQL Server


Java


Deployment Manager


Cluster opcional.


Instalação resumida

Instalar WAS

Instalar BPM

Criar Profiles

Criar Deployment Manager

Criar Nodes

Configurar DB

Deploy

Subir ambiente


Técnicas importantes

SLA

Prazo.

Exemplo.

24 horas.


Escalation

Aprovação atrasou.

Enviar email.


Timer

Esperar 2 dias.


Human Task

Atividade humana.


Integration Service

Consumir API.


Coach

Tela Web.


Curiosidades

Easter Egg 1

BPM nasceu para substituir muitos workflows em Lotus Notes.


Easter Egg 2

Muitos bancos usam BPM apenas para aprovações.


Easter Egg 3

Boa parte dos usuários nem sabe que usa BPM.

Só recebem tarefas.


Easter Egg 4

O losango do fluxograma continua vivo.

Só ganhou nome novo.

Gateway.


Easter Egg 5

Muitos arquitetos IBM brincam:

"CICS fala com terminais."

"BPM fala com pessoas."


Vantagens

Excelente visibilidade.

KPIs.

Dashboards.

Auditoria.

SLA.

Escalabilidade.

Integração.

Baixo código.


Desvantagens

Curva aprendizado.

Infraestrutura pesada.

Licenciamento.

Dependência WebSphere.

Pode ser excessivo para processos simples.


Quando usar

Aprovações.

RH.

Compliance.

Jurídico.

Compras.

Contratos.

Onboarding.

KYC.

LGPD.

Fraude.


Quando não usar

Calcular juros.

Ordenar arquivos.

Batch noturno.

DFSORT.

ETL simples.


O futuro

IBM BPM praticamente se transformou.

Hoje falamos.

IBM BAW.

Business Automation Workflow.

Integrado com.

RPA.

IA.

OCR.

Watson.

Decision Server.

Process Mining.


Conclusão

Para um Padawan COBOL, IBM BPM é uma descoberta curiosa.

Passamos décadas modelando fluxos em papel.

Depois desenhamos fluxogramas.

Depois surgiram UML e BPMN.

E então alguém teve uma ideia brilhante:

"Se conseguimos desenhar processos, por que não executá-los?"

IBM BPM nasceu justamente dessa pergunta.

No mundo Bellacosa Mainframe, a analogia é simples:

  • JCL orquestra jobs.

  • CICS orquestra telas.

  • DB2 orquestra dados.

  • MQ orquestra mensagens.

  • IBM BPM orquestra pessoas.

E descobrir isso é perceber que o verdadeiro desafio da computação corporativa nunca foi apenas programar máquinas.

Sempre foi organizar seres humanos.

quinta-feira, 29 de julho de 2021

☕💥 Por que os Fluxogramas Caíram em Desuso?

 

Bellacosa Mainframe e um teoria sobre o desuso dos fluxogramas

☕💥 Por que os Fluxogramas Caíram em Desuso?

Ou como um Padawan COBOL descobriu que o vilão não era o losango, mas a pressa do mercado

A resposta curta é:

Fluxogramas não morreram.
Eles foram substituídos, fragmentados, escondidos dentro de outras ferramentas e vítimas da pressão por velocidade de entrega.

E isso aconteceu por vários motivos.


1. O software ficou monstruosamente grande

Na década de 70, um programa COBOL típico poderia ter:

2.000 linhas
5 arquivos
20 IFs

Um fluxograma cabia em duas folhas.

Já um sistema bancário atual pode possuir:

35.000 linhas COBOL

120 tabelas DB2

50 programas chamados

MQ

CICS

Webservices

Kafka

APIs

z/OS Connect

Imagine desenhar isso.

Seriam dezenas de páginas.

Exemplo:

Login

↓

Menu

↓

Consulta

↓

CICS

↓

COBOL

↓

DB2

↓

MQ

↓

API PIX

↓

Anti-fraude

↓

Core Banking

Vira praticamente uma planta industrial.


2. O Waterfall perdeu força

Antigamente.

Projeto:

Meses de análise

Meses de desenho

Meses documentação

Meses codificação


Hoje:

Sprint

5 dias

10 dias

Deploy

Produção


No Agile.

Muitos pensam:

"Melhor codar do que desenhar."

E aí morre o fluxograma.


3. UML roubou espaço

Anos 90.

Chega UML.

E aparece:

Use Case

Sequence Diagram

Activity Diagram

Class Diagram

State Diagram


Activity Diagram praticamente é.

Fluxograma Premium™.

Exemplo.

Login

Validar

[Conta válida]

Consultar


Mesmo conceito.

Outra roupa.


4. Ferramentas BPM surgiram

Hoje temos:

Camunda

IBM BPM

ServiceNow

Power Automate

Bizagi


Você não desenha.

Você modela.


Exemplo.

Fluxograma clássico.

Solicitar Crédito

↓

Análise

↓

Gerente

↓

Compliance

Camunda.

Já executa.

Workflow vivo.


5. Código passou a ser documentação

Essa é a maior mudança cultural.

Dev moderno diz:

O código é a documentação.

Exemplo.

EVALUATE STATUS

WHEN 1
   PERFORM INSERIR

WHEN 2
   PERFORM ALTERAR

WHEN 3
   PERFORM EXCLUIR

WHEN OTHER
   CONTINUE

END-EVALUATE

Ele acredita que isso basta.


Analista antigo pensa:

"Sim."

"Mas eu levei 15 segundos olhando um desenho."

"Você levou 20 minutos lendo o programa."

😂


6. CASE Tools fracassaram

Anos 80.

Grande promessa.

Desenhar.

Gerar COBOL.


Ferramentas.

IEF

CoolGen

Pacbase

Excelerator

ADW


Promessa:

Desenhe.

Clique.

Compile.


Realidade.

Sistema gerado.

Gigantesco.

Difícil manutenção.


Mercado perdeu confiança.


7. Diagramas ficaram desatualizados

Problema clássico.

Fluxograma.

Lindo.

Aprovado.


Programador faz:

Mais 10 IFs.

Mais 5 EVALUATE.

Mais 2 SELECT.


Ninguém atualiza.

Diagrama.

Versão 2017.

Código.

Versão 2026.


Caos.


8. O Git substituiu parte da documentação

Hoje.

Git.

Pull Request.

Merge.

Comentários.

Exemplo.

PR-4523


Adicionada regra PIX noturno

Muitos usam isso.

Como histórico.


9. A geração atual prefere ferramentas visuais modernas

Antigamente.

Visio

PowerPoint

Papel

Caneta


Hoje.

Miro

Draw.io

LucidChart

Figma


Mesmo conceito.

Nova embalagem.


Mas Mainframe ainda ama fluxogramas

Aqui está a grande ironia.

No mundo Mainframe.

Fluxogramas nunca morreram.

Estão escondidos.


CICS

Mapas BMS

Fluxo PF3

PF5

ENTER


Batch

Arquivos

Balance Line

Merge


DB2

Cursores

Commit

Rollback


VSAM

READ

REWRITE

DELETE


JES2

JOB

STEP

COND

RC


Exemplo real

Imagine receber.

Programa:

FINA0321

42 mil linhas.

Criado.

Autor.

Aposentado.

Documentação.

Zero.


Você abre.

PERFORM P0010

PERFORM P0020

PERFORM P0030

PERFORM P0040

O que faz?

Ninguém sabe.


Você desenha.

START

↓

LER VSAM

↓

CLIENTE EXISTE?


◇



SIM


↓

ATUALIZA DB2


↓

GERA RELATÓRIO




NÃO


↓

INCLUI DB2




↓

END

Em 10 minutos.

Entendeu o programa.


Então por que deveríamos voltar a usar?

Porque ele resolve problemas caros.

Comunicação

Analista

Desenvolvedor

Tester

Usuário

Todos entendem.


Onboarding

Padawan COBOL chega.

Primeiro dia.

Recebe.

Fluxograma.

Aprende.

Em horas.

Sem.

Fluxograma.

Leva semanas.


Auditoria

Banco Central

SOX

PCI

LGPD

Adoram.

Fluxos.


Engenharia Reversa

Legados.

Sem documentação.

Fluxograma é ouro.


Minha visão para o Mainframe moderno

Eu diria que o fluxograma não morreu.

Ele evoluiu.

Hoje ele reaparece como:

  • Activity Diagram

  • BPMN

  • Camunda

  • Miro

  • Draw.io

  • Mermaid

  • Workflow IBM BPM

  • State Machines

  • Fluxos conversacionais

  • Orquestração de APIs

  • Pipelines DevOps

Mas para nós, habitantes do Reino IBM Z, existe uma verdade quase filosófica:

Um fluxograma bem desenhado é a forma mais rápida de transformar 30 mil linhas de COBOL em uma história compreensível.

O compilador entende COBOL. O ser humano entende narrativas. O fluxograma é a ponte entre os dois.

Bellacosa Mainframe ☕💥🚀

 

domingo, 15 de março de 2020

☕💥 Fluxogramas no Mundo Mainframe

 

Bellacosa Mainframe e o fluxograma no mundo mainframe

☕💥 Fluxogramas no Mundo Mainframe

Ou como um Padawan COBOL descobre que antes do IF WS-SALDO > ZERO, existia um desenhinho que salvava projetos milionários

"Um programa COBOL sem fluxograma é como um JCL sem JOB CARD. Talvez execute. Talvez funcione. Mas ninguém vai entender daqui seis meses."

— Mestre Bellacosa Mainframe


Introdução

Uma das maiores diferenças entre um desenvolvedor COBOL júnior de hoje e um analista de sistemas da década de 1970, 1980 ou 1990 não está na linguagem.

Não está no z/OS.

Não está no DB2.

Não está no CICS.

Está na forma de pensar software.

Hoje aprendemos:

  • Fazer código

  • Testar

  • Commitar

  • Fazer Pull Request

Antigamente aprendíamos:

  • Analisar

  • Modelar

  • Desenhar

  • Revisar

  • Aprovar

  • Codificar

E neste mundo existia um personagem muito poderoso.

O Fluxograma.


O nascimento dos fluxogramas

A ideia é muito antiga.

Vem dos trabalhos de engenharia industrial.

Frank Gilbreth

Henry Gantt

Por volta de 1921 começaram a desenhar processos industriais.

Exemplo:

Receber matéria-prima

Produzir

Inspecionar

Embalar

Enviar

Décadas depois os computadores apareceram.

E alguém percebeu:

"Programas são processos."

Logo...

Processos industriais

viraram

Processos computacionais.


O modelo Waterfall

Se você trabalha em Mainframe bancário provavelmente ainda verá isso.

Waterfall.

As fases clássicas:

Requisitos

Análise

Fluxogramas

Especificação Técnica

Codificação

Teste

Implantação


Documentos clássicos do Waterfall

Documento Funcional

O que o sistema faz.

Exemplo:

Pagamento de boleto

Regra:

Se vencido

cobrar multa

Se pago em dia

valor normal


Documento Técnico

Como será implementado.

Exemplo:

Programa:

PAGBOL01

Tabela:

TB_BOLETO

Transação:

PB01

Copybooks

CPBOLETO


Fluxograma

É a ponte entre os dois.

Negócio

Fluxograma

COBOL


Bellacosa Mainframe e os simbolos de fluxograma

O que é um Fluxograma?

É uma representação gráfica de um algoritmo.

Ao invés de escrever:

IF SALDO > ZERO
   DISPLAY "OK"
ELSE
   DISPLAY "NEGADO"
END-IF

Desenhamos.

        ◇
SALDO > 0 ?
   /    \
 SIM    NÃO
 ↓       ↓
OK    NEGADO

Nosso cérebro entende imagens mais rapidamente.

Por isso funcionam.


Símbolos principais

Oval

Significado:

Início

Fim

Exemplo

 _______
(START )
 -------

ou

 _______
( END  )
 -------

Retângulo

Processamento.

Fazer algo.

Exemplo:

Calcular juros

Atualizar cadastro

Mover campos


Exemplo COBOL

COMPUTE JUROS =
SALDO * 0.05

Fluxograma

□ Calcular juros


Losango

Decisão.

Pergunta.

Tem duas saídas.

SIM

NÃO

Exemplo

Cliente VIP?


COBOL

IF CLIENTE-VIP='S'

Paralelogramo

Entrada e saída.

DISPLAY

ACCEPT

RECEIVE

SEND


Batch

Ler arquivo

Online

Receber PFKEY


Seta

Fluxo.

Indica sequência.

Sem seta.

Existe caos.

Com seta.

Existe entendimento.


Círculo

Conector.

Liga páginas.

Muito usado em especificações gigantes.

Página 1

○A

Página 10

○A

continuação


Bellacosa Mainframe e um fluxograma cobol batch

Fluxograma de Batch COBOL

Imagine:

Pagar folha salarial.


Desenho

START

Abrir arquivo

Ler funcionário

Fim Arquivo?

Sim

Gerar relatório

END

Não

Calcular salário

Gravar saída

Ler próximo


COBOL

OPEN INPUT FUNCIONARIO

PERFORM UNTIL EOF='S'

 READ FUNCIONARIO

   AT END
      MOVE 'S' TO EOF

   NOT AT END

      PERFORM CALCULA

      WRITE REG-SAIDA

 END-READ

END-PERFORM

Bellacosa Mainframe exemplo de fluxograma cobol vsam


Fluxograma para VSAM

Abrir KSDS

READ

FOUND?

SIM

UPDATE

REWRITE

NÃO

WRITE

END


Bellacosa Mainframe exemplo de fluxograma online cics

Fluxograma Online CICS

Exemplo.

Consulta saldo.


START

Receber tela

ENTER?

SIM

Validar conta

Conta existe?

SIM

Ler DB2

Enviar tela

NÃO

Mensagem erro

END


COBOL

EXEC CICS RECEIVE MAP


EXEC SQL

SELECT SALDO

INTO :WS-SALDO

FROM CONTA


END-EXEC


EXEC CICS SEND MAP


END-EXEC

Bellacosa Mainframe exemplo de fluxograma db2

Fluxograma com DB2

Exemplo.

Transferência bancária.


START

Receber origem

Receber destino

Valor válido?

SIM

BEGIN UNIT OF WORK

SELECT

UPDATE

UPDATE

COMMIT

NÃO

ROLLBACK

END


Fluxograma das tabelas DB2

Tabela

CLIENTE

Tabela

CONTA

Tabela

MOVIMENTO

Fluxo

CLIENTE

CONTA

MOVIMENTO


Exemplo SQL

SELECT
C.NOME,
M.VALOR

FROM CLIENTE C

JOIN CONTA CT

ON...

JOIN MOVIMENTO M

Fluxograma ajuda a enxergar joins.


Workflow

Muitos confundem.

Fluxograma

não é

Workflow

Mas workflow pode usar fluxograma.


Exemplo

Solicitação crédito

Cliente

Análise

Aprovação gerente

Compliance

Liberação


Hoje isso está em:

IBM BPM

Camunda

ServiceNow

Power Automate


Fluxos de diálogo

Muito usado em CICS.

Tela login

Senha válida?

Sim

Menu

Não

Mensagem erro


Chatbots fazem isso.

ChatGPT faz isso.

URA faz isso.

PIX faz isso.


Boas práticas

1 Não cruzar linhas

Errado

Linhas embaralhadas.

Causa dor psicológica.


2 Usar nomes claros

Errado

Processo 1

Correto

Calcular IOF


3 Uma decisão por vez

Evita confusão.


4 Modularizar

Subfluxos.

Exemplo

Pagamento

Calcular imposto

Fluxograma separado


Curiosidades

Easter Egg 1

COBOL nasceu em 1959.

Fluxogramas já eram padrão.


Easter Egg 2

Muitos programadores COBOL dos anos 80 codificavam olhando apenas para fluxogramas.

Nem tinham acesso ao usuário.


Easter Egg 3

Ferramentas CASE prometiam gerar COBOL automaticamente.

Excelerator

ADW

CoolGen

IEF

Pacbase

A ideia era:

Desenhar

Gerar programa

Compilar


Easter Egg 4

IBM usou fluxogramas extensivamente na documentação do OS/360.

Centenas de páginas.


Easter Egg 5

DFSORT pode ser representado perfeitamente por fluxograma.

INPUT

SORT

SUM

OUTREC

OUTPUT


Por que ainda usamos em Mainframe?

Porque sistemas bancários possuem:

Centenas de regras

Milhares de IFs

Milhões de contas

Um código COBOL pode ter:

30000 linhas

500 parágrafos

200 IFs

Ler isso é cansativo.

Ver um desenho leva segundos.


O Fluxograma como ferramenta de sobrevivência do Padawan COBOL

Imagine receber:

Programa:

FINA0345

38 mil linhas.

Criado em 1994.

Sem documentação.

Sem analista.

Sem usuário.

Sem autor.

Você abre.

Encontra:

PERFORM P1120

PERFORM P1130

PERFORM P1140

PERFORM P1150

O que fazem?

Ninguém sabe.

Mas após desenhar:

START

↓

Validar Cliente

↓

Consultar DB2

↓

Calcular Limite

↓

Atualizar Histórico

↓

Gerar Extrato

↓

END

Tudo fica claro.

É por isso que arquitetos, analistas de sistemas, especialistas em CICS, DB2, IMS, MQ, BPM e até equipes DevOps continuam utilizando fluxogramas.

Eles não substituem COBOL.

Não substituem UML.

Não substituem documentação funcional.

Mas fazem algo extremamente valioso: transformam milhares de linhas de código em uma história visual que qualquer pessoa consegue seguir.

E, no universo Bellacosa Mainframe, talvez esta seja a melhor definição possível:

Fluxograma é o mapa da dungeon. COBOL é a espada. DB2 é o tesouro. CICS é o portal de entrada. E o programador júnior que aprende a desenhar processos deixa de ser apenas um codificador e começa a pensar como um verdadeiro Analista de Sistemas do Reino IBM Z. ☕🚀