ormuz
Orchestration/Subworkflows

Composer des processus avec les subworkflows

Un subworkflow délègue une responsabilité à un autre processus tout en conservant un contrat typé entre le parent et l’enfant. Le parent crée une instance enfant, attend sa résolution, puis reprend avec les outputs déclarés par le processus enfant.

Une vraie instance enfant, pas une macro de graphe

Le node Subworkflow ne copie pas les nodes du processus enfant dans le parent. Il ouvre une exécution distincte, avec sa propre révision, son propre graphe observable et son propre statut. Le parent reste suspendu sur le node jusqu’à ce que cette exécution produise un résultat ou échoue.

Instance parente
Subworkflow inputs mappés
Instance enfant révision sélectionnée
Parent reprend outputs enfant

Le parent délègue une responsabilité complète à une instance enfant et reprend uniquement à la frontière de son contrat de sortie.

Quand créer un sous-processus ? Utilisez un subworkflow lorsqu’une séquence possède une responsabilité métier réutilisable, un contrat d’entrée/sortie clair ou mérite une observabilité autonome. Si vous cherchez seulement à rendre le graphe plus joli, une séparation en sous-processus ajoute probablement une frontière inutile.

Sélectionner le processus et sa révision

Le designer sélectionne la définition enfant puis la révision à exécuter. Une révision pinée garantit qu’une évolution ultérieure du processus enfant ne modifie pas silencieusement le comportement d’un processus parent déjà publié.

Dans un environnement de test, le Process Builder peut également cibler la version de travail afin d’itérer rapidement sur les deux graphes. Cette facilité d’authoring ne change pas le principe de production : une exécution reproductible doit identifier le snapshot enfant qu’elle exécute.

La frontière de versionnement est réelle Modifier le contrat d’entrée ou de sortie de l’enfant peut invalider les mappings du parent. Traitez l’adoption d’une nouvelle révision enfant comme une modification du processus parent et revérifiez ses bindings.

Inputs et outputs suivent le contrat de l’enfant

Les paramètres du node sont dérivés de l’input_schema du processus enfant. Chaque input requis doit être alimenté par une source compatible du parent. Les outputs visibles après résolution sont, eux, dérivés de l’output_schema de l’enfant.

Cette frontière évite les échanges de contexte opaques : le sous-processus ne reçoit pas automatiquement tout l’état du parent. Il reçoit les valeurs que le designer a explicitement mappées, puis restitue uniquement son contrat de sortie.

Pour comprendre les règles de typage et de compatibilité utilisées par ces mappings, voir Entrées, sorties et bindings.

L’inspecteur d’un sous-processus permet de choisir le processus enfant et la révision à exécuter.
L’inspecteur d’un sous-processus permet de choisir le processus enfant et la révision à exécuter. Agrandir

Choisir la continuité des participants

Un processus enfant peut déclarer ses propres participants. Par défaut, ces participants restent indépendants de ceux du parent. Le designer peut toutefois mapper explicitement un participant de l’enfant vers un participant du parent lorsqu’il s’agit réellement de la même personne ou du même rôle dans l’expérience.

Plusieurs participants enfants peuvent être reliés au même participant parent, mais ce choix doit être intentionnel : ils partageront alors la même identité de participant à cette frontière du parcours. L’absence de mapping conserve au contraire une séparation explicite.

La protection des données traverse la frontière

Mapper une valeur vers le sous-processus ne supprime pas sa classification. Les politiques de protection associées aux inputs sont transportées vers l’instance enfant. Lors du retour, les outputs sont reclassifiés selon le contrat de sortie de l’enfant tout en conservant les protections héritées qui restent applicables.

Un subworkflow n’est pas une frontière de déclassification Décomposer un processus ne doit jamais être utilisé pour transformer implicitement une donnée sensitive ou secret en donnée normale. Une baisse explicite de classification reste soumise aux mêmes règles de consentement que dans le graphe parent.

Voir Protection des données.

Échecs, warnings et observabilité

L’instance enfant est consultable comme toute autre instance de processus. Depuis le node parent, l’utilisateur peut descendre vers cette exécution pour comprendre son chemin, ses inputs, ses outputs et ses diagnostics.

Si l’enfant échoue avant de produire une résolution exploitable, le node Subworkflow échoue à son tour et le parent suit sa politique d’échec. Si l’enfant termine avec des warnings, le parent reçoit un warning de synthèse plutôt qu’une copie de tous les diagnostics internes : le détail reste dans l’instance enfant.

Warning enfant ≠ échec du parent Un warning indique qu’une investigation peut être utile ; il ne transforme pas automatiquement un résultat enfant valide en failure. Ouvrez l’instance enfant pour consulter les warnings à leur source.

Voir Observabilité pour la lecture des exécutions imbriquées.