DNATech :: 🔧 Performance no Protheus: o custo invisível de estender o sistema sem contexto

_Créditos das imagens: ChatGPT

## 🔧 Performance no Protheus: o custo invisível de estender o sistema sem contexto

> Quem atua em projetos no Protheus envolvendo processos de alto volume, regras complexas e grande impacto operacional — como Reajuste de Preços, Faturamento (SIGAPLS) ou cálculos fiscais — já ouviu a frase clássica do cliente:
>> “Depois da customização, ficou lento.”

E quase sempre a conclusão rápida é:

* “Tem query demais”
* “O banco não aguenta”
* “AdvPL é lento”

Spoiler: **não é isso**.

O problema está **no modelo de extensibilidade** do Protheus e em como os **Pontos de Entrada** são usados — e, principalmente, **no que eles não entregam**.

---

## 🧩 Pontos de Entrada entregam dados… mas pela metade

É importante ser justo:
os Pontos de Entrada **até fornecem informações**.

O problema é que, muitas vezes:

* não são as informações necessárias
* chegam incompletas
* chegam fora de contexto
* ou chegam “capengas” (só veio uma perna 🦵)

### Exemplo real: Reajuste de Preços

Por exemplo: Durante o processo de reajuste de preços:

* o Protheus **monta a estrutura do produto**
* calcula regras
* avalia composição
* processa item a item

Porém…

👉 Se o cliente quiser **gravar o histórico da estrutura do produto** usada no reajuste, ele **não enxerga a estrutura já montada pelo sistema**.

O que o analista faz?

* chama uma função pesada para **recriar a estrutura**
* dentro de um laço
* para cada produto

Resultado:

* reprocessamento
* duplicação de lógica
* gargalo de performance
* frustração geral

A estrutura **já existe**.
Mas não é acessível.

---

## 🔄 Reprocessar o que já foi processado é um anti-pattern

Esse é o ponto central.

Hoje o fluxo é, grosso modo:

1. O Protheus lê dados
2. Monta estruturas internas
3. Processa regras
4. Calcula valores
5. **Chama o Ponto de Entrada**
6. …sem expor todo o contexto do que já foi feito

O Ponto de Entrada não recebe:

* o estado do processo
* as estruturas intermediárias
* o contexto real da execução

Então o desenvolvedor é forçado a:

> “descobrir” como o sistema fez
> “adivinhar” qual função usar
> “recriar” o que já está pronto

Isso **não é extensão**, é **engenharia reversa em produção**.

---

## ⚙️ O agravante: processamento item a item

No caso de reajuste de preços, por exemplo:

* o Protheus monta a estrutura **produto a produto**
* dentro de um laço
* mesmo sabendo que vai processar **um conjunto fechado de produtos**

Pergunta simples, de engenharia:

> Se eu sei que vou reajustar 5.000 produtos
> e sei que todos precisarão da estrutura
> por que não montar **todas as estruturas uma vez**, em lote,
> e disponibilizar esse contexto?

Isso resolveria:

* performance
* reuso
* extensibilidade
* clareza

E evitaria que cada cliente:

* recrie função
* replique regra
* implemente soluções paralelas

---

## 🧠 O que deveria acontecer (e não acontece)

O cliente **não deveria**:

* saber qual função monta a estrutura
* entender detalhes internos 
* chamar funções lentas em loop
* fazer SELECTs adicionais 

O cliente **deveria receber pronto**.

Algo conceitualmente assim:

```text
Contexto do Reajuste:
- Produtos processados
- Estrutura de cada produto
- Regras aplicadas
- Valores calculados
```

E o Ponto de Entrada deveria apenas:

* consumir
* complementar
* persistir
* ajustar regra

Sem reprocessar.

---

## 🎯 Ponto de Entrada não é lugar para recriar o processo

Esse é o erro conceitual mais comum (e mais caro).

Pontos de Entrada:

* não deveriam ser usados para **refazer lógica**
* não deveriam ser usados para **reler dados**
* não deveriam ser usados para **recalcular o core**

Eles existem para **alterar comportamento**, não para substituir o motor.

Quando isso acontece, o problema não é o desenvolvedor.
É o desenho da extensão.

---

## 🧨 O impacto real nos projetos

Na prática, o que vemos é:

* processos lentos
* consumo excessivo de banco
* códigos complexos e frágeis
* dificuldade de manutenção
* clientes insatisfeitos

E a culpa acaba recaindo em:

* “customização ruim”
* “AdvPL não escala”
* “Protheus é pesado”

Quando, na verdade, o sistema:
👉 **já tinha a informação em memória, mas não expôs**.

---

## 📌 Conclusão

A informação:

* já foi carregada
* já foi processada
* já existe

O que falta é:

* **exposição de contexto**
* **contratos claros de extensão**
* **Pontos de Entrada conscientes do processo**

Enquanto isso não evoluir, continuaremos vendo:

* reprocessamento desnecessário
* gargalos artificiais
* soluções paralelas
* performance degradada

Não é falta de índice.
Não é excesso de SQL.
É arquitetura.

E quem trabalha com processo pesado no Protheus sabe exatamente do que estamos falando.

Porque esse problema não é pontual. Ele é estrutural.

---

#Protheus, #AdvPL, #Performance, #ArquiteturaDeSoftware, #Extensibilidade, #ERP, #BoasPraticas, #EngenhariaDeSoftware, #SistemasCorporativos

Torne-se um Sponsor: 🥊(дави)={0.5x[(Налдо)+(Алине)]}🥊