Tâches externes
Une External Task permet à un processus de déléguer une étape à un service extérieur à Ormuz, d’attendre durablement sa réponse, puis de poursuivre avec des sorties typées et, si nécessaire, une route dérivée de ce résultat.
Un contrat réutilisable, des occurrences indépendantes
Le processus matérialise une tâche à partir d’un contrat versionné. Le service externe traite cette occurrence ; Ormuz valide le résultat avant de reprendre le processus.
Le modèle distingue la Definition, qui donne une identité stable à une classe de travail, sa révision, qui fige le contrat typé, et l’occurrence créée lorsqu’une instance de processus atteint le node.
Une Definition telle que add_company_to_crm peut être partagée par plusieurs processus. Chaque processus pinne toutefois une révision exacte : déplacer le Working ou publier une nouvelle Release ne réinterprète jamais une instance déjà enregistrée.
Définir une classe de tâche
Dans la Console, une External Task Definition porte une clé stable, un nom, un contrat d’entrées, un contrat de sorties et éventuellement une sortie de routage. Comme les autres artefacts versionnés, ses snapshots sont immuables et peuvent être publiés en Releases. Voir Versions, Releases et déploiement pour le cycle et la rétention communs.
Le contrat utilise les types Ormuz. Une nouvelle révision peut donc ajouter ou modifier des champs sans changer rétroactivement les processus qui utilisent une ancienne révision. Plusieurs révisions incompatibles peuvent coexister pendant une migration.
Utiliser une External Task dans un processus
Le node sélectionne une Definition, une révision et mappe ses entrées comme n’importe quel autre node typé. La Console affiche les sorties de la révision comme sources disponibles pour les nodes suivants.
Le node porte aussi une politique bornée : nombre maximal de tentatives, délai avant une nouvelle tentative et deadline optionnelle. Cette politique est figée sur chaque occurrence.
Pour les règles générales de typage et de disponibilité des sources, voir Entrées, sorties et bindings.
Attendre sans garder une exécution occupée
Lorsque l’instance atteint le node, Ormuz résout et valide les entrées puis rend l’occurrence disponible. Le node passe en attente. Le service externe peut ensuite réclamer cette tâche, la traiter et restituer un résultat ou un échec.
Une réservation est temporaire. Si elle expire avant règlement, la même occurrence peut redevenir disponible selon sa politique. Une nouvelle tentative ne crée pas une nouvelle intention métier dans le processus.
L’arrêt de l’instance annule les External Tasks encore ouvertes. Un résultat tardif ne peut pas ressusciter le processus.
Sorties typées et routage dérivé
Sans sortie de routage, la continuation est linéaire. Avec une sortie Choicerequise, les valeurs de cette sortie deviennent les routes du node. Par exemple,created et existing peuvent mener vers deux branches différentes.
Le service externe renvoie la donnée métier ; il ne choisit jamais directement le prochain node. Ormuz valide le résultat contre la révision pinnée puis calcule la route.
normal. Une valeur secret n’est jamais copiée dans les métadonnées de contrôle.Retry technique et idempotence métier sont différents
Ormuz empêche qu’une même occurrence logique du node soit matérialisée plusieurs fois et rend les opérations de réservation et de règlement rejouables. Ces garanties protègent le protocole technique.
Elles ne fusionnent pas deux demandes métier distinctes. Si deux processus créent chacun une occurrence add_company_to_crm pour le même entreprise, les deux tâches existent. Le service externe reste responsable de la sémantique métier : effectuer l’action, répondre comme un succès sans nouvel effet, ou signaler un conflit selon son propre contrat.
Les garanties générales sont détaillées dans Erreurs, retries et idempotence.
Accès et données protégées
Un consommateur n’accède qu’aux classes de tâches qui lui sont explicitement autorisées. Les entrées et sorties conservent leurs classifications normal,sensitive et secret. Les valeurs protégées restent masquées dans les surfaces d’observabilité.
Pour une application web, ne placez pas une clé d’intégration large dans le navigateur. Faites porter le protocole par un backend autorisé, ou utilisez une surface serveur ciblée sur l’occurrence concernée.
Voir Protection des données pour les règles communes de classification et de masquage.
Observer les tâches et leurs tentatives
La Console sépare les Definitions, utilisées pour concevoir les contrats, des External Tasks, utilisées en exploitation. La vue Opérations permet de filtrer les occurrences par clé, statut ou Process Instance et d’inspecter leurs tentatives.
Depuis le détail d’une Process Instance, un node External Task renvoie vers son occurrence. Le détail affiche les entrées et sorties selon les règles de protection, l’état courant, les dates importantes, les tentatives, l’identifiant diagnostique du consommateur et les erreurs éventuelles.
Cette surface est volontairement observationnelle : elle ne propose pas de bouton générique pour fabriquer une complétion métier. Pour le contrat machine, consultez la Référence API.