Définitions, révisions, instances
Une définition de processus porte l’identité durable de votre processus. Son état de travail pointe vers une révision immuable, une Release marque explicitement une révision publiée, et chaque instance conserve la révision exacte qu’elle exécute. Ces niveaux permettent de modifier le futur sans réécrire l’historique des exécutions.
Pour le contrat commun aux artefacts déployables — Working, snapshots, Releases, déploiement live et rétention — voir Versions, Releases et déploiement.
Définition de processus
La définition est l’identité durable. Working choisit le snapshot actuellement édité ; une Release publie un snapshot ; une instance exécute un snapshot précis.
Une process_definition est identifiée par un ID prd_…. Son contenu exécutable comprend notamment le schéma d’entrée, le schéma de sortie, le graphe, la configuration de l’expérience hébergée et les launchers associés.
input_schemadéfinit ce que l’instance accepte au démarrage.flow_configdécrit les nodes, leurs paramètres et les edges du graphe.output_schemadéfinit les valeurs produites à la complétion.activeautorise ou interdit la création de nouvelles instances depuis la définition.
Working et révisions immuables
La définition expose working_revision_id et revision_number. Le pointeur Working désigne le snapshot actuellement retenu par l’éditeur et par les nouveaux lancements de cette définition. Le snapshot lui-même est une révision immuable identifiée par pdr_….
Lorsqu’un enregistrement modifie réellement le contenu exécutable, Ormuz calcule un nouveau content_hash et crée une nouvelle révision numérotée. Si le contenu exécutable est identique, le snapshot existant est réutilisé au lieu de produire une révision artificielle.
Une révision capture le contrat nécessaire à une exécution reproductible : inputs, outputs, graphe, dépendances d’environnement, parcours utilisateur et snapshot des launchers. Les dépendances Agent et Decision utilisées par le processus sont également résolues au niveau de cette révision.
pdr_42 : une nouvelle révision est créée et la définition déplace son working_revision_id. Une instance déjà créée continue donc d’exécuter son snapshot d’origine.Releases : publier une révision explicitement
Une process_definition_release (prl_…) est un jalon de publication qui référence une révision précise. Elle possède son propre release_number et conserve le hash du contenu publié. Publier sans préciser de révision promeut le snapshot Working courant.
La même révision n’est pas publiée deux fois sous deux Releases distinctes : une nouvelle demande de promotion de ce même snapshot retrouve la Release existante. Une définition conserve par ailleurs son dernier jalon publié, distinct de son pointeur Working.
Révisions des sous-processus
Un node sous-processus ou Foreach choisit comment il référence la définition enfant. Le contrat actuel expose deux modes : working et pinned.
| Mode | Comportement | Usage |
|---|---|---|
working | La révision Working de la définition enfant est résolue lorsque l’enfant est lancé. | Conception et test lorsque parent et enfant doivent évoluer ensemble. |
pinned | Le node conserve explicitement l’ID de la révision enfant à exécuter. | Contrat reproductible et déploiement contrôlé. |
Une instance enfant reste toujours liée à la révision effectivement choisie lors de sa création. Les comptes live n’acceptent pas de référence enfant working dans une révision de processus : le déploiement doit y figer les dépendances sur des révisions précises.
Voir Sous-processus pour le contrat parent/enfant complet.
Instances
Une process_instance (pci_…) représente une exécution concrète. Elle conserve sonprocess_definition_id, le snapshot process_definition_revision utilisé, son input, son état courant, sa sortie éventuelle et sa provenance de démarrage.
Les états publics actuels sont :
running— exécution active ;waiting— attente d’un timer, d’une interaction, d’un événement ou d’un enfant ;stopping— arrêt demandé pendant qu’une exécution doit encore céder la main ;completed— contrat de sortie produit avec succès ;failed— échec terminal de cette tentative ;retry_exhausted— budget de reprise automatique épuisé ;superseded— une continuation corrective a remplacé cette tentative dans la lignée ;stopped— instance arrêtée explicitement.
Les relations retry_of, fork_of et parent_process_instance_id rendent la lignée observable sans mélanger les états de plusieurs instances. Voir Observabilité et Erreurs, retries et idempotence.
Source de démarrage
start_source conserve la provenance d’une instance. Sa structure dépend de l’opération qui l’a créée ; ne le traitez pas comme un enum fermé à quelques valeurs historiques.
| Mode courant | Signification |
|---|---|
api | Lancement direct de la définition via `POST /v1/processes/:id/runs`. |
event | Launcher événementiel ; la provenance conserve notamment le type d’événement et le launcher. |
subworkflow | Instance enfant créée par un node sous-processus ou Foreach d’une instance parent. |
retry | Continuation corrective d’une instance existante. |
rerun | Nouvelle exécution volontaire créée depuis une instance antérieure avec le Working courant. |
fork | Branche corrective créée à partir d’un point précis d’une instance source. |
Une provenance événementielle peut conserver l’ID et le type de l’événement ; une provenance de sous-processus conserve le contexte parent ; retry, rerun et fork conservent leur relation avec l’instance source. Ces données servent à reconstruire pourquoi une exécution existe, pas à modifier son contrat de révision.
Sortie d’une instance
Une instance complétée résout son output_schema à partir des sources autorisées du processus. La sortie persistée est celle de la révision exécutée, pas celle d’une version plus récente de la définition.
Pour un sous-processus en attente, cette sortie devient la sortie du node parent lorsque l’enfant se termine. Un schéma de sortie vide est valide pour un processus terminal qui effectue uniquement des effets métier.
Les valeurs sensitive et secret conservent leur protection dans l’input, l’état, les steps et l’output. Voir Protection des données.
Dupliquer un processus
POST /v1/processes/:id/duplicate crée une nouvelle définition avec sa propre identité et son propre historique. Le contenu exécutable courant est copié ; les instances et l’historique de révisions de la définition source ne le sont pas.
copy_launchers vaut true par défaut et la nouvelle définition est inactive par défaut. Les permissions nécessaires aux nodes doivent être explicitement accordées dans le contexte de la copie plutôt que supposées héritées de la définition source.
Activation
active contrôle la création de nouvelles instances depuis une définition. Un lancement direct d’une définition inactive est refusé, et les résolutions de launchers système ignorent les définitions inactives.
Désactiver une définition ne réécrit pas les instances déjà existantes ni leur snapshot. Utilisez cette option pour empêcher de nouveaux démarrages, pas comme mécanisme d’arrêt rétroactif des instances en cours.