Temps, attentes et événements temporels
Ormuz utilise le temps de deux façons différentes : un node Wait peut suspendre une instance existante jusqu’à une échéance, tandis que certains événements plateforme sont émis lorsqu’un objet métier atteint une condition temporelle et peuvent démarrer de nouvelles instances.
Deux usages du temps à ne pas confondre
| Besoin | Primitive | Effet |
|---|---|---|
| Reprendre le même processus plus tard | Wait | L’instance courante passe en attente puis reprend au même node. |
| Réagir à une échéance métier | Événement temporel + launcher | La plateforme émet un événement ; un processus abonné peut démarrer une nouvelle instance. |
Suspendre une instance avec Wait
Le node Wait accepte soit une durée, soit une date et heure absolues. Si l’échéance est dans le futur, l’instance passe en statut d’attente puis reprend lorsque l’échéance est atteinte. Une durée nulle ou une date déjà passée se termine immédiatement sans créer d’attente durable.
Wait conserve la même instance : le contexte d’exécution reste celui du processus déjà commencé.
Les durées peuvent être exprimées en secondes, minutes, heures ou jours. La borne produit maximale est de 366 jours pour une attente unique ; une valeur au-delà est refusée plutôt que transformée silencieusement.
Wait lorsque la suite logique appartient à la même instance. Si le besoin est « lancer un nouveau processus quand une facture devient en retard », préférez l’événement temporel correspondant.Déclencher depuis un événement temporel métier
Certains objets plateforme exposent des événements dont la condition dépend du temps et de l’état métier, par exemple invoice.overdue, invoice.due_date_stage_reached, receivable.overdue ou supplier_invoice.overdue.
L’événement exprime une condition métier devenue vraie. Un launcher peut l’utiliser comme déclencheur d’un processus indépendant.
Ces événements ne signifient pas simplement « la date est passée ». La plateforme tient compte du contrat métier associé. Par exemple, une facture ne doit pas continuer à produire un événement de retard si son solde n’est plus dû.
Le catalogue des événements documente les conditions et données propres à chaque événement : Catalogue des événements plateforme.
Déduplication et réarmement
Un événement temporel n’est pas réémis à chaque vérification tant que le même épisode métier reste actif. La plateforme mémorise qu’une condition a déjà déclenché son événement et évite les doublons pour cette combinaison d’événement et de ressource.
Lorsque la ressource redevient inéligible, cette mémoire peut être réarmée. Si elle entre plus tard dans un nouvel épisode éligible, l’événement peut alors être émis à nouveau. C’est ce qui permet de distinguer un second vrai retard d’une répétition technique du premier.
Choisir le bon modèle
- Attente dans un parcours : utilisez
Waitpour reprendre la même instance après un délai ou à une date précise. - Relance liée à un objet : utilisez un événement temporel plateforme et un launcher lorsque l’échéance appartient au lifecycle de l’objet métier.
- Retry d’une opération : configurez la politique de retry du processus plutôt que d’ajouter manuellement un
Waitautour d’un node défaillant. - Calendrier métier : préférez les événements de palier lorsqu’ils existent plutôt que de dupliquer le calcul de dates dans plusieurs processus.
Voir Erreurs, retries et idempotence pour la politique de reprise sur erreur.
Observer une attente ou un déclenchement
Une instance suspendue sur Wait apparaît en statut d’attente avec le node concerné. Lorsqu’elle reprend, le graphe conserve cette étape dans son historique. Pour un événement temporel, l’événement reste consultable comme les autres événements plateforme et la nouvelle instance indique sa source de déclenchement.
Cette distinction aide au diagnostic : si une relance n’a pas eu lieu, vérifiez d’abord si l’événement métier a été émis ; si une instance existante n’a pas repris, inspectez le node Wait et son échéance.
Voir Observabilité.