Fluxo de execução principal
Figura 7 — Fluxograma completo do método run(), com 6 etapas e liberação do lock no finally.
Detalhamento de cada etapa
| # | Método | O que faz (simples) | O que faz (técnico) |
|---|---|---|---|
| 1 | verificaGetLock() |
Garante que só uma cópia rode por vez | flock exclusivo em arquivo temporário |
| 2 | getPonteiroExecucao() |
Pergunta: "desde quando devo buscar?" | MAX(execucao) em log onde procedure='franquia_1beat' |
| 3 | getPedidoUltimaVerificacao() |
Acha o pedido mais novo no período | MAX(data) em movimentação PEDIDO > ponteiro |
| 4 | getPedidosRecebidos() |
Copia e calcula quantidades | INSERT com CTEs + ON DUPLICATE KEY UPDATE |
| 5 | removePedidosStatus() |
Apaga pedidos cancelados/abertos | DELETE WHERE SITUACAO = 'DESATIVO' |
| 6 | atualizaPonteiroExecucao() |
Marca que terminou até tal data | INSERT/UPDATE em log |
Processamento incremental
O módulo não reprocessa tudo a cada execução. Ele usa um "marcador de página" (ponteiro) para buscar apenas pedidos alterados entre a última execução e a data do pedido mais recente.
Figura 8 — Apenas pedidos entre o ponteiro e a data mais recente são processados em cada execução.
Mensagens de erro comuns
- "Ja tem outro processo em execucao, aguarde o termino" — outra instância do
run()está ativa. - "Não foram encontrados pedidos para atualizar" — não há pedidos novos desde o ponteiro.
- "Nao foi possivel criar o arquivo de lock" — problema de permissão no diretório temporário.
Tratamento de erros: exceções no
run() são capturadas e enviadas a error_byexception(). Os métodos intermediários (getPedidosRecebidos, removePedidosStatus, atualizaPonteiroExecucao) também possuem try/catch interno que retorna null em falha sem interromper o fluxo principal.