Introduction au modèle des processus
Un processus Ormuz est une séquence typée d'étapes qui applique les règles d'un marchand et produit un résultat observable. Il accumule de l'état au fil de son exécution, peut brancher selon les conditions rencontrées, et peut s'interrompre pour attendre une action humaine ou un signal externe avant de reprendre.
Ce qu'est un processus
Un processus est la traduction exécutable d'une logique métier. Au lieu de coder une suite d'appels API dans votre système, vous décrivez les étapes et leurs connexions dans Ormuz. La plateforme exécute ces étapes, maintient l'état, émet des événements à chaque transition significative, et expose le résultat à travers son modèle d'objets publics.
Les étapes d'un processus ne s'exécutent pas toutes en même temps. Elles progressent selon les connexions que vous définissez : un node ne démarre que lorsque ses prédécesseurs ont produit leurs sorties. Certains nodes peuvent décider de ne pas continuer vers certaines branches, ce qui permet de modéliser des parcours conditionnels sans écrire de code de routage dans votre système.
Cette page introduit les concepts essentiels. La référence complète — exécution, bindings avancés, timers, idempotence — est dans la section Orchestration.
Définitions et instances
Un processus Ormuz distingue deux niveaux : la définition et l'instance.
La définition est le schéma réutilisable. Elle décrit les nodes, leurs connexions, le schéma des entrées attendues, et les variables typées qui s'accumulent au fil de l'exécution. Une définition peut être modifiée puis publiée sous une nouvelle révision. Les instances créées après une publication utilisent la révision active.
Une instance est une exécution concrète d'une révision publiée. Elle est créée par un déclencheur — appel API, événement plateforme ou timer — et progresse de node en node jusqu'à ce que tous les chemins atteignent une fin. Plusieurs instances de la même définition peuvent s'exécuter en parallèle sans interférer.
Une définition est publiée sous une révision. Chaque déclencheur crée une instance indépendante de cette révision.
Familles de nodes
Un node est une capacité composable. Il reçoit des entrées typées, effectue une opération, et produit des sorties typées exploitables par les nodes suivants. Cinq familles couvrent l'ensemble des besoins d'orchestration.
| Famille | Rôle | Exemples |
|---|---|---|
| Helpers | Exécutent une action atomique : charger un objet, créer une entité, vérifier une condition, mettre à jour un statut, envoyer un email. | fetch_company, create_buyer, credit.check_credit_availability, reconcile_payment |
| Routeurs | Évaluent un résultat métier et sélectionnent une branche de sortie nommée. Chaque route est une connexion distincte vers un node suivant. | resolve_contact (found / not_found), credit.check_credit_availability (approved / declined) |
| Actions utilisateur | Ouvrent un parcours utilisateur et mettent l'instance en attente jusqu'à ce qu'un utilisateur complète l'étape. La réponse alimente les nodes suivants comme n'importe quel output. | collect_user_email, collect_choice, sirene.search_sirene_company, stripe.collect_sepa_debit_mandate |
| Intégrations | Appellent un provider externe (PSP, ERP, comptabilité, open banking) et renvoient des objets ou statuts typés vers le reste du processus. | stripe.ensure_customer, stripe.trigger_sepa_debit, stripe.create_bank_transfer_payment_intent |
| Subworkflows | Délèguent une partie du parcours à une autre définition de processus. Le processus parent attend la complétion du sous-processus avant de continuer. | subworkflow (configure la définition cible et les entrées) |
Le catalogue des nodes Core documente les nodes natifs d’Ormuz. Les nodes installés avec une extension sont disponibles dans la section Intégrations.
Entrées, sorties et bindings
Chaque node déclare ses entrées (les valeurs qu'il attend) et ses sorties
(les valeurs qu'il produit). Les types couvrent les scalaires (string, integer,
boolean, datetime), les objets plateforme (platform.company,
platform.checkout_session, etc.), les tableaux, et les brouillons d'objets en attente de
création.
Un binding connecte la sortie d'un node à l'entrée d'un node suivant. Par exemple, le
node create_buyer produit un objet platform.company. Ce même objet peut être
directement câblé comme entrée du node resolve_contact, qui attend lui aussi un
platform.company. Il n'est pas nécessaire de manipuler un identifiant ni d'écrire du code
pour transmettre cet objet.
La sortie company du premier node devient l'entrée company du suivant via un binding typé. Le type est vérifié à la définition.
Une entrée peut également être liée à l'entrée globale du processus, à une valeur statique, ou à une variable de processus accumulée par un node précédent. La page Entrées, sorties et bindings décrit toutes les formes de liaison disponibles ; les calculs sont détaillés dans Expressions.
Routes et branches
Les nodes de la famille Routeurs et certains nodes Actions utilisateur exposent des sorties nommées appelées routes. Au lieu d'une seule connexion sortante, ces nodes en proposent plusieurs — une par issue possible — et en sélectionnent une seule à l'exécution selon le résultat obtenu.
Les nodes situés sur une branche non sélectionnée passent à l'état skipped et n'exécutent rien. Plusieurs branches peuvent converger vers un même node aval : celui-ci attend simplement qu'une branche active ait complété le node qui le précède.
Le routeur sélectionne la route found ou not_found selon le résultat de résolution. Les deux branches convergent ensuite vers le node de finalisation.
Déclencheurs
Une instance est créée par l'un des trois types de déclencheurs suivants.
Trois sources peuvent créer une instance : un appel API direct, un événement plateforme, ou un timer.
Appel API — votre système appelle directement l'API Ormuz pour créer une instance en fournissant les entrées requises par la définition.
Événement plateforme — un événement émis par Ormuz (création d'un objet, changement de statut, réception d'un webhook provider) déclenche automatiquement les processus abonnés à ce type d'événement.
Timer — un processus s'exécute selon une planification récurrente ou après un délai, en scannant les objets éligibles et en créant une instance par objet concerné.
Interactions humaines
Un node Action utilisateur déclenche l'ouverture d'un parcours utilisateur par Ormuz — une page interactive accessible depuis votre produit — et met l'instance en état waiting. L'exécution reprend automatiquement lorsque l'utilisateur complète l'étape demandée.
Les réponses saisies par l'utilisateur (email, nom, choix, données de formulaire, mandat) deviennent les sorties du node et alimentent les nodes suivants exactement comme le ferait un helper. Le processus ne distingue pas la source d'une valeur — qu'elle vienne d'un appel API, d'un provider ou d'un utilisateur.
La page Parcours utilisateurs explique comment intégrer ces interactions dans votre produit et comment en personnaliser l'apparence.
États d'exécution
Chaque node d'une instance possède un état qui évolue au fil de l'exécution. L'instance elle-même
est observable depuis la console et depuis l'API via son process_instance.
| État | Signification |
|---|---|
pending | En attente que tous les prédécesseurs soient complétés. |
running | En cours d'exécution. |
completed | Terminé avec succès. Les sorties sont disponibles pour les nodes suivants. |
waiting | En pause sur une action utilisateur ou un signal externe. L'instance reste active. |
skipped | Non sélectionné par le routeur de la branche active. Sans effet sur l'exécution. |
Une instance reste active tant qu'au moins un node est en état running ou waiting. Elle est considérée terminée quand tous les nodes sur les branches actives ont atteint l'état completed ou skipped.
L'état de chaque node et l'historique de l'instance sont accessibles en temps réel depuis la console et via l'API. La page Observabilité décrit comment suivre et diagnostiquer une instance.