Fluxos: ao salvar ou pelo agendador?
- Fluxos ao salvar executam na mesma requisição de gravação; relacionamentos e objetos posteriores muitas vezes ainda não foram estabelecidos.
- Fluxos pelo agendador separam interface e processamento, mas exigem cron, observação e idempotência.
- Modelagem incorreta aparece como e-mails vazios, requisições travadas ou ações duplicadas, não como uma falha teórica abstrata.
Fluxos no SuiteCRM, historicamente Advanced Open Workflow, permitem ações condicionais por módulo. Na prática, falham menos pelo mecanismo e mais por premissas incorretas sobre o momentoem que os dados estão completos e os relacionamentos definidos. Este artigo torna concreta a decisão arquitetural, com orientação, comparação de ciclos de vida e checklist de testes.
Qual tipo de fluxo é adequado ao seu caso?
Duas perguntas, uma recomendação. Não substitui testes em homologação, mas ajuda a evitar a decisão errada mais comum.
Adequado para cálculos ou mudanças de status no mesmo registro, sem relacionamentos dependentes e sem espera perceptível.
1. Dois ciclos de vida: síncrono e assíncrono
Em vez de definições abstratas, observe a sequência que usuário e sistema realmente vivenciam:
Ciclo de vida ao salvar
- 1 Usuário clica em Salvar
- 2 A requisição HTTP executa — o navegador aguarda
- 3 Validação e hooks antes do salvamento
- 4 Gravação no banco: INSERT/UPDATE
- 5 Fluxo ao salvar: e-mails, webhooks e outras gravações
- 6 Resposta ao navegador
Ciclo de vida do agendador
- 1 Usuário salva — resposta rápida
- 2 A interface volta a responder
- 3 Depois, de forma independente: cron ou processo de trabalho
- 4 A tarefa lê o estado atual do banco, com os relacionamentos geralmente disponíveis
- 5 Ações em lote sem bloquear a interface
- 6 Definir sinalizador de status ou idempotência
2. Orientação resumida para decidir
| Pergunta de design | Preferir ao salvar | Preferir agendador |
|---|---|---|
| O registro relacionado é criado somente após salvar? | desfavorável | adequado |
| O usuário precisa ver um campo ou retorno imediatamente? | adequado | adiado |
| API externa com latência perceptível? | arriscado na requisição | melhor |
| Grandes volumes ou execuções noturnas? | inadequado | planejar com filtros |
3. Três armadilhas de arquitetura
A ilusão do subpainel
O ID do registro principal pode já existir durante o salvamento enquanto registros vinculados, como relacionamentos de subpainéis, só são gravados em uma etapa posterior da transação ou depois dela. Um fluxo ao salvar que espera o contato da proposta então não encontra nada, embora o usuário tenha acabado de definir o vínculo na interface. Contramedida: Usar o agendador ou uma segunda etapa deliberada quando houver garantia de leitura do relacionamento.
O ciclo infinito recursivo
O fluxo altera um campo → dispara outro salvamento → executa novamente → até atingir o tempo limite ou o limite de memória. É especialmente traiçoeiro quando condição e destino da gravação envolvem o mesmo campo. Contramedida: Usar um sinalizador explícito de processamento, definir condições para que a segunda execução não faça nada e evitar salvamentos desnecessários na cadeia.
A execução descontrolada do agendador
Após anos de operação, um fluxo agendado sem filtros restritos de data ou status pode tocar enormes volumes históricos a cada cron. O sistema parece ficar lento de repente, embora o fluxo sempre tenha funcionado assim. Contramedida: Usar critérios de seleção restritos e status de já processado; observar tempo de execução e carga.
4. Prontidão para implantação: protocolo de testes para marcar
Entrar em produção sem estas cinco comprovações é operar às cegas, independentemente do tipo de gatilho escolhido.
Checklist de homologação
O Workflow Engine no AgenticUltimate utiliza modelagem visual, simulação e aprovação versionada para que os fluxos não entrem em produção sem revisão. A escolha entre salvar e agendador continua sendo uma decisão arquitetural; a simulação não substitui nenhuma das cinco verificações acima.
Workflow Engine ↗5. Limites deste artigo
Não há garantia para toda versão de correção do SuiteCRM ou todo conjunto de hooks personalizados. As recomendações são heurísticas de arquitetura baseadas em falhas típicas; testes em homologação na sua instância continuam sendo decisivos.