Tâches externes
Une External Task délègue une étape à un service extérieur à Ormuz. Le processus peut attendre durablement une tâche Pull ou appeler une API Destination avec une échéance courte en Push, puis poursuivre avec des sorties typées.
Un contrat réutilisable, des occurrences indépendantes
En mode Pull, 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.
Un service externe peut s’abonner à une clé tout en limitant explicitement les révisions qu’il sait traiter. Ne supposez pas qu’un consommateur compatible avec le Working courant comprend automatiquement toutes les révisions historiques.
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.
Deux nodes utilisent ce contrat : external_task_pull pour une délégation durable
à un consommateur autorisé et external_task_push pour appeler une API Destination
et recevoir un résultat dans la réponse. Leurs politiques d’exécution sont distinctes et
figées sur chaque occurrence.
Pour les règles générales de typage et de disponibilité des sources, voir Entrées, sorties et bindings.
Choisir entre Pull et Push
En mode Pull, le service externe réclame une occurrence disponible, la traite, puis soumet son résultat ou son échec. Ce mode convient aux traitements longs. Sa politique fixe le nombre maximal de tentatives, le délai avant une nouvelle tentative et, si nécessaire, une deadline.
En mode Push, le processus sélectionne une API Destination autorisée en plus de la Definition et de sa révision. Ormuz envoie les entrées du contrat au service et attend une réponse synchrone typée. Le budget total est de 5 secondes par défaut, configurable jusqu’à 10 secondes ; la destination peut imposer un plafond plus court. Une réponse différée ne complète pas ce node.
Une réservation Pull est temporaire. Si elle expire avant règlement, la même occurrence peut redevenir disponible selon sa politique. Le mode Push n’applique aucun retry automatique : un échec ou un dépassement de délai suit la gestion d’erreur du 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 Choice
requise, 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.
La sortie utilisée pour choisir une branche doit être de classification 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. En Pull, les opérations de réservation et de règlement sont rejouables. En Push, le service appelé doit rendre le traitement du même identifiant de tâche idempotent : une réponse perdue peut laisser un effet externe déjà réalisé, même sans retry automatique.
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.
Utilisez l’identifiant de l’occurrence pour rendre le traitement de cette occurrence idempotent. Une déduplication couvrant plusieurs processus doit reposer sur une clé métier comprise par le système externe.
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.