Existe uma conversa perigosa acontecendo silenciosamente em muitas empresas que utilizam TOTVS Datasul®.
Uma conversa que normalmente começa assim:
- “o banco está lento”
- “precisamos aumentar servidor”
- “o PASOE está pesado”
- “o OpenEdge não escala”
- “o ERP trava em horário de pico”
E quase sempre termina com:
- mais CPU;
- mais memória;
- mais VM;
- mais infraestrutura.
O problema?
Na maioria das vezes…
isso não resolve a causa raiz.
Porque o gargalo frequentemente não está no banco.
Também não está necessariamente no PASOE.
Nem na quantidade de usuários.
O gargalo costuma estar em algo muito mais invisível: arquiteturas modernas rodando em lógica procedural sequencial criada para um mundo que não existe mais.
O modelo antigo funcionava. O problema é que o cenário mudou.
Durante muitos anos, o modelo clássico do Progress OpenEdge fazia sentido.
RUN piFiscal.
RUN piFinanceiro.
RUN piEstoque.
RUN piCRM.
Processamento linear.
Organizado.
Previsível.
E honestamente?
Para a realidade daquela época… funcionava muito bem.
Porque o cenário era outro:
- poucas integrações;
- baixo volume simultâneo;
- desktop local;
- baixa concorrência;
- pouca API;
- quase nenhum mobile;
- praticamente inexistência de analytics em tempo real.
Mas o ambiente corporativo mudou drasticamente.
Hoje, um único processo do Datasul® pode precisar simultaneamente:
- consultar estoque em múltiplas empresas;
- integrar WMS;
- sincronizar CRM;
- alimentar BI;
- responder app mobile;
- atualizar ecommerce;
- chamar API fiscal;
- consolidar pedidos;
- alimentar DWH.
Tudo ao mesmo tempo.
E principalmente: com baixa latência.
O problema não é “ficar lento”.
O problema é colapsar sob concorrência.
Aqui existe um ponto extremamente importante.
Muitos ambientes parecem saudáveis em homologação.
Poucos usuários.
Baixa carga.
Quase nenhum acesso simultâneo.
Então a arquitetura parece “boa”.
Até entrar em produção.
E aí começam sintomas clássicos:
- filas;
- travamentos;
- lock table overflow;
- APIs lentas;
- timeout;
- consumo excessivo de CPU;
- saturação de agentes PASOE;
- workers presos;
- lentidão “aleatória”.
O mais perigoso?
Muitos desses sintomas aparecem gradualmente.
O sistema não explode imediatamente.
Ele degrada lentamente.
O erro arquitetural mais caro do mundo Progress®
Existe um padrão extremamente comum: usar o PASOE apenas como um “RUN ON SERVER”.
E isso é um desperdício gigantesco.
Porque o PASOE não é apenas um servidor remoto.
Ele é um motor de processamento concorrente.
Mas a maioria dos projetos continua usando:
- processamento síncrono;
- chamadas bloqueantes;
- integrações sequenciais;
- ETLs diretos no banco;
- APIs esperando uma rotina terminar para chamar outra.
Resultado:
o ambiente inteiro vira um funil.
O ponto que quase ninguém percebe:
performance não é apenas velocidade individual
A maioria dos desenvolvedores mede: “quanto tempo essa rotina demora?”
Mas arquiteturas modernas precisam medir outra coisa: throughput.
Ou seja:
- quantas operações o ambiente suporta simultaneamente;
- quantas integrações consegue processar;
- quantos requests consegue absorver;
- quantos workers consegue manter saudáveis.
E isso muda tudo.
Porque muitas vezes:
✔ uma rotina individual continua “rápida”
❌ mas o ambiente inteiro colapsa sob concorrência.
O verdadeiro papel do paralelismo
Muita gente acha que paralelismo serve para: “fazer mais rápido”.
Não.
Isso é consequência.
O verdadeiro objetivo do paralelismo moderno é:
- distribuir carga;
- reduzir bloqueio;
- desacoplar processamento;
- evitar gargalos sequenciais;
- melhorar elasticidade;
- aumentar throughput.
É arquitetura.
Não apenas performance.
O erro mais perigoso: paralelizar sem governança
Agora vem a parte mais importante.
Paralelismo mal implementado pode piorar tudo.
E muito.
Porque paralelismo sem:
- callback;
- timeout;
- controle;
- logging;
- correlation-id;
- tratamento de erro;
- fila;
- observabilidade;
vira apenas: caos executando mais rápido.
Esse talvez seja um dos pontos mais maduros da arquitetura moderna no Progress®.
Não basta disparar:
RUN worker ASYNCHRONOUS.
Você precisa controlar:
- quem iniciou;
- quem terminou;
- quanto demorou;
- quem falhou;
- qual empresa;
- qual payload;
- qual request;
- qual retorno.
Sem isso, debugging em produção vira pesadelo.
O problema invisível dos ETLs diretos no banco
Essa é uma das discussões mais sensíveis do universo Datasul® moderno.
Muitas empresas continuam permitindo:
- Power BI;
- ETL;
- integrações;
- ferramentas externas;
acessando banco Progress® diretamente.
E sim…
funciona.
Até o dia que deixa de funcionar.
Porque normalmente essas ferramentas:
- ignoram regras de negócio;
- bypassam triggers;
- fazem leitura massiva;
- geram contenção;
- criam lock indireto;
- degradam throughput.
A sensação inicial é: “ficou mais simples.”
Mas arquiteturalmente isso costuma virar dívida técnica operacional.
O futuro do Datasul® já começou
O ponto mais importante de toda essa transformação é simples:
o Progress OpenEdge não está desaparecendo.
Ele está mudando de papel.
Antes:
- GUI procedural.
Agora:
- motor transacional;
- APIs;
- processamento distribuído;
- integração corporativa;
- serviços;
- orquestração.
E isso muda completamente o perfil do desenvolvedor valorizado no mercado.
O novo profissional do ecossistema Progress®
O profissional que continuará relevante nos próximos anos não será apenas quem “sabe sintaxe”.
Será quem entende:
- concorrência;
- arquitetura;
- filas;
- APIs;
- observabilidade;
- paralelismo;
- governança;
- escalabilidade.
Porque o mercado está deixando lentamente de procurar apenas: programadores de rotina.
E começando a procurar: arquitetos de sistemas distribuídos dentro do ecossistema Datasul.
O ponto que quase ninguém fala
Existe uma frase muito importante aqui: “o PASOE não corrige arquitetura ruim.”
Ele apenas amplifica.
Se o sistema é bem desenhado:
- escala.
Se é mal desenhado:
- colapsa mais rápido.
Conclusão
A discussão sobre paralelismo no Progress OpenEdge vai muito além de performance.
Ela fala sobre:
- maturidade arquitetural;
- sustentabilidade;
- governança;
- futuro do Datasul;
- capacidade de crescimento.
E talvez a maior mudança de mentalidade seja essa:
o problema moderno do ERP não é apenas processamento.
É arquitetura de concorrência.
Quem entender isso cedo vai construir ambientes muito mais:
- escaláveis
- estáveis
- modernos
- sustentáveis
E principalmente:
mais preparados para o futuro inevitável das integrações corporativas.
Toda quarta-feira, às 19:30, acontece nossa live técnica sobre:
- TOTVS Datasul®
- Progress OpenEdge
- PASOE
- APIs
- arquitetura
- performance
- integração
- engenharia corporativa
O acesso completo e os materiais ficam disponíveis no grupo VIP:
👉 [Participar da Comunidade Datasul]
Material técnico complementar da Live 097:
