Workflows : à l'enregistrement ou par planificateur ?
- Les flux à l'enregistrement s'exécutent dans la requête de sauvegarde ; relations et objets suivants sont souvent encore absents.
- Les flux du planificateur séparent interface et traitement, mais nécessitent Cron, supervision et idempotence.
- Une mauvaise modélisation produit des e-mails vides, des requêtes bloquées ou des actions en double, pas seulement une erreur théorique.
Les workflows SuiteCRM, historiquement Advanced Open Workflow, permettent des actions conditionnelles au niveau des modules. En pratique, ils échouent moins à cause du moteur que de mauvaises hypothèses sur le momentoù les données sont complètes et les relations établies. Cet article concrétise le choix architectural avec aide à la décision, comparaison des cycles de vie et contrôles de test.
Quel type de workflow convient à votre cas ?
Deux questions, une recommandation. Sans remplacer les tests en préproduction, elles évitent l'erreur de choix la plus courante.
Adapté aux calculs ou changements de statut sur la même fiche, sans relations dépendantes ni attente notable.
1. Deux cycles de vie : synchrone ou asynchrone
Au lieu de définitions abstraites, examinons le parcours réellement vécu par l'utilisateur et le système :
Cycle de vie à l'enregistrement
- 1 L'utilisateur clique sur « Enregistrer »
- 2 La requête HTTP s'exécute ; le navigateur attend
- 3 Validation et hooks avant enregistrement
- 4 Écriture en base (INSERT/UPDATE)
- 5 Workflow à l'enregistrement : e-mails, webhooks ou écritures supplémentaires éventuels
- 6 Réponse au navigateur
Cycle de vie du planificateur
- 1 L'utilisateur enregistre ; réponse rapide
- 2 L'interface est de nouveau utilisable
- 3 Exécution différée : Cron / traitement
- 4 La tâche lit l'état actuel de la base, relations généralement présentes
- 5 Actions par lots sans bloquer l'interface
- 6 Définir un indicateur de statut ou d'idempotence
2. Aide à la décision abrégée
| Question de conception | Plutôt à l'enregistrement | Plutôt par planificateur |
|---|---|---|
| La fiche liée apparaît-elle seulement après l'enregistrement ? | défavorable | adapté |
| L'utilisateur a-t-il besoin d'un champ ou retour immédiatement visible ? | adapté | différé |
| API externe avec latence notable ? | risqué dans la requête | préférable |
| Gros volumes ou exécutions nocturnes ? | inadapté | planifier avec des filtres |
3. Trois pièges d'architecture
L'illusion des sous-panneaux
L'identifiant principal peut déjà exister pendant l'enregistrement alors que les fiches liées sont écrites plus tard dans la transaction ou après celle-ci. Un flux attendant le contact du devis ne trouve alors rien, même si l'utilisateur vient de créer le lien dans l'interface. Contre-mesure : Planificateur ou seconde étape explicite dès que la relation est assurément lisible.
La boucle récursive fatale
Un workflow change un champ, redéclenche un enregistrement, puis le workflow recommence jusqu'au délai maximal ou à la limite mémoire. Particulièrement trompeur si condition et écriture visent le même champ. Contre-mesure : Indicateur explicite de traitement, conditions rendant la seconde exécution sans effet, aucun enregistrement inutile dans la chaîne.
Le planificateur sans limites
Un flux sans filtres stricts de dates ou statuts peut parcourir d'immenses volumes historiques à chaque passage de Cron après des années. Le système semble soudain lent alors que le flux a toujours été ainsi. Contre-mesure : Critères de sélection stricts, statut « déjà traité », suivi des durées et de la charge.
4. Prêt au déploiement : protocole de test à cocher
Mettre en production sans ces cinq preuves revient à avancer à l'aveugle, quel que soit le déclencheur.
Liste de contrôle de préproduction
Le Workflow Engine d'AgenticUltimate repose sur modélisation visuelle, simulation et validation versionnée afin d'éviter la mise en production sans examen. Le choix métier entre enregistrement et planificateur reste architectural ; la simulation ne remplace aucun des cinq contrôles ci-dessus.
Workflow Engine ↗5. Limites de l'article
Aucune garantie pour chaque correctif SuiteCRM ni ensemble de hooks spécifiques. Ces recommandations sont des repères architecturaux tirés d'erreurs courantes ; les tests sur votre instance restent déterminants.