Déclencheurs
Un déclencheur démarre un workflow : il n'a pas d'entrée et émet un signal
sur sa sortie out (Execute) quand sa condition de démarrage est remplie.
Tout workflow commence par (au moins) une brick de cette famille.
La brick Déclencheur est le point d'entrée recommandé : elle déclare des déclencheurs dont le runtime se configure par environnement. Les autres bricks de cette page sont des variantes spécialisées.
Déclencheur
Déclencheur d'orchestration : exécution manuelle, planification cron ou webhook.
| Catégorie | Trigger |
| Entrées | — |
| Sorties | out (Execute) |
La brick ne porte aucune valeur de planification. Son panneau liste les déclencheurs déclarés du workflow, chacun étant décrit par :
| Champ | Description |
|---|---|
| Clé | Clé stable, générée une fois ; elle survit aux renommages et aux montées de version. |
| Nom | Libellé affiché (« Déclencheur 1 »…). |
| Type | manual (à la demande), cron (planifié) ou webhook (appel HTTP entrant). |
Le fonctionnement effectif de chaque déclencheur (expression cron, fuseau, dates ponctuelles, secret webhook, activation, cible runner) se règle par environnement, dans le sous-onglet Workflows de l'environnement, voir Configurer les déclencheurs.
Webhook Trigger
Démarre le workflow quand l'endpoint HTTP entrant est appelé. URL signée + secret généré par Fluhoms.
| Catégorie | Trigger |
| Entrées | — |
| Sorties | out (Execute) |
| Paramètre | Type | Défaut | Description |
|---|---|---|---|
secret_required | booléen | true | Si activé, la requête doit inclure le header X-Fluhoms-Secret. |
allowed_ips | liste de chaînes | vide | Whitelist d'IPs/CIDR ; vide = pas de filtre. |
Manual Trigger
Démarrage manuel du workflow depuis l'interface ou l'API, avec paramètres saisis à l'exécution.
| Catégorie | Trigger |
| Entrées | — |
| Sorties | out (Execute) |
| Paramètre | Type | Défaut | Description |
|---|---|---|---|
run_params | liste d'objets | vide | Variables publiées dans la charge de sortie du déclencheur. |
Chaque champ déclaré ressort dans la charge run_params du port de sortie,
rempli par la variable d'environnement FH_RUN_PARAMS si le lanceur en pose
une, sinon par son default déclaré, sinon null. La déclaration fixe donc la
forme de la charge, stable d'un lancement à l'autre.
Le serveur ne propose aujourd'hui aucun formulaire au lancement, et rien ne pose
FH_RUN_PARAMS. Un champ required laissé vide produit donc un
avertissement, pas un échec — faire échouer condamnerait tout workflow qui
déclare un champ obligatoire sans lui offrir le moyen de le renseigner.
Chaque entrée de run_params décrit une variable :
| Champ | Type | Défaut | Description |
|---|---|---|---|
name | chaîne | — | Nom de la variable. |
type | string · integer · boolean · date | string | Type de la valeur saisie. |
default | chaîne | — | Valeur par défaut proposée. |
required | booléen | false | La saisie est-elle obligatoire ? |
File Watcher
Démarre le workflow quand un nouveau fichier correspond à un pattern dans une connexion storage (polling, ou event-based si supporté).
| Catégorie | Trigger |
| Entrées | — |
| Sorties | out (Execute) |
| Paramètre | Type | Défaut | Description |
|---|---|---|---|
connection_id | chaîne (requis) | — | Connexion storage à surveiller. |
file_pattern | chaîne (requis) | * | Glob, par exemple incoming/*.csv. |
polling_interval_sec | entier | 60 | Fréquence de scan en secondes (minimum 10). |
move_after_trigger | booléen | true | Déplace le fichier dans processed/ après correspondance, pour éviter les redéclenchements. |
Voir aussi
- Configurer les déclencheurs : le guide pas à pas.
- Contrôle de flux : enchaîner après le déclenchement.