Workflow: al salvataggio o tramite scheduler?
- I flussi al salvataggio vengono eseguiti nella richiesta che salva; relazioni e oggetti successivi spesso non sono ancora impostati.
- I flussi scheduler separano interfaccia e lavoro, ma richiedono cron, osservazione e idempotenza.
- Una modellazione errata si manifesta con email «vuote», richieste bloccate o azioni duplicate, non come un errore teorico astratto.
I workflow in SuiteCRM, storicamente Advanced Open Workflow, consentono azioni condizionali a livello di modulo. In pratica falliscono meno spesso per «il motore» che per ipotesi errate sul momentoin cui i dati sono completi e le relazioni impostate. Questo articolo rende concreta la decisione architetturale con supporto decisionale, confronto dei cicli di vita e checklist di test.
Quale tipo di workflow è adatto al tuo caso?
Due domande, una raccomandazione. Non sostituisce i test di staging, ma aiuta a evitare la scelta errata più frequente.
Adatto a calcoli o modifiche di stato nella stessa scheda, senza relazioni dipendenti e senza tempi di attesa percepibili.
1. Due cicli di vita: sincrono e asincrono
Invece di definizioni astratte, osserviamo il processo effettivamente vissuto da utente e sistema:
Ciclo di vita al salvataggio
- 1 L'utente fa clic su «Salva»
- 2 La richiesta HTTP è in corso, il browser attende
- 3 Validazione e hook prima del salvataggio
- 4 Scrittura nel database (INSERT/UPDATE)
- 5 Workflow al salvataggio: eventuali email, webhook e altre scritture
- 6 Risposta al browser
Ciclo di vita dello scheduler
- 1 L'utente salva, la risposta è rapida
- 2 L'interfaccia è nuovamente utilizzabile
- 3 Separato nel tempo: cron/worker
- 4 L'attività legge lo stato attuale del database (relazioni di norma presenti)
- 5 Azioni in blocco senza bloccare l'interfaccia
- 6 Impostare un flag di stato/idempotenza
2. Supporto decisionale sintetico
| Domanda progettuale | Preferibilmente al salvataggio | Preferibilmente scheduler |
|---|---|---|
| La scheda collegata nasce solo dopo il salvataggio? | sfavorevole | adatto |
| L'utente ha bisogno di un campo o riscontro immediatamente visibile? | adatto | ritardato |
| API esterna con latenza percepibile? | rischioso nella richiesta | meglio |
| Grandi volumi / esecuzioni notturne? | non adatto | pianificare con filtri |
3. Tre insidie architetturali
L'illusione del pannello secondario
L'ID della scheda principale può già esistere durante il salvataggio, mentre le schede collegate (relazioni dei pannelli secondari) vengono scritte solo in una fase successiva della transazione o dopo. Un flusso al salvataggio che attende il «contatto nel preventivo» non trova quindi nulla, anche se l'utente ha appena impostato il collegamento nell'interfaccia. Contromisura: scheduler oppure un secondo passaggio deliberato, non appena la relazione è sicuramente leggibile.
Il ciclo ricorsivo senza fine
Il workflow modifica un campo → attiva un altro salvataggio → il workflow riparte → fino al timeout o al limite di memoria. Particolarmente insidioso quando condizione e destinazione di scrittura riguardano lo stesso campo. Contromisura: flag esplicito di elaborazione, condizioni formulate in modo che la seconda esecuzione non produca effetti, nessun salvataggio inutile nella catena.
L'esecuzione scheduler senza limiti
Un flusso scheduler senza filtri stretti di data e stato può, dopo anni di utilizzo, toccare enormi quantità storiche a ogni esecuzione cron. Il sistema sembra «improvvisamente lento» anche se il flusso «è sempre stato così». Contromisura: criteri di selezione stretti, stato «già elaborato», monitoraggio di tempi e carico.
4. Prontezza alla distribuzione: protocollo di test da spuntare
La messa in produzione senza queste cinque prove procede alla cieca, indipendentemente dal tipo di attivazione scelto.
Checklist di staging
La Workflow Engine in AgenticUltimate punta su modellazione visuale, simulazione e approvazione con versioni, affinché i flussi non arrivino in produzione senza essere esaminati. La scelta funzionale tra salvataggio e scheduler resta una decisione architetturale; la simulazione non sostituisce nessuno dei cinque controlli precedenti.
Workflow Engine ↗5. Limiti di questo articolo
Nessuna garanzia per ogni livello di patch SuiteCRM o insieme di hook personalizzati. Le raccomandazioni sono criteri architetturali ricavati da errori tipici; resta decisivo lo staging sulla tua istanza.