Éditeur de jobs
Un job Nomaflow se crée et se modifie depuis Paramètres → Jobs. La page liste chaque job du catalogue ; cliquer sur une ligne ouvre l'éditeur de jobs — un formulaire avec la planification, la grille de paramètres, la politique de relance et le pipeline d'étapes (glisser-déposer). L'enregistrement recharge le job dans l'ordonnanceur en cours d'exécution.
Cette page documente chaque champ de l'éditeur.
Vue d'ensemble
La maquette montre les sections Général, Planification et Étapes. En dessous, l'éditeur expose aussi Paramètres, Politique de relance, Dépendances et Notifications — chacune est documentée plus bas.
Général
| Champ | Effet |
|---|---|
| Nom | Identifiant unique du job. Apparaît dans l'historique d'exécution, la CLI (liberty-admin job run <name>) et le code de permission (job:<name>). Convention : minuscules + tirets. Le renommage est pris en charge — l'opération Renommer réécrit chaque référence en une seule transaction. |
| App | Liste déroulante des apps enregistrées sur l'installation. Le job est regroupé sous cette app dans le catalogue et la clé de permission job:<app>:*. Défaut _default (transverse au framework). |
| Description | Texte libre affiché dans la liste du catalogue. Aide l'opérateur suivant. |
| Activé | Interrupteur. Les jobs désactivés restent dans le catalogue mais ne se déclenchent jamais depuis cron. Les déclencheurs manuels (le bouton ▶ Exécuter maintenant, l'endpoint REST) continuent de fonctionner. |
Planification
| Champ | Effet |
|---|---|
| Cron | Expression cron standard à 5 champs. L'éditeur l'analyse en direct ; l'affichage 5 prochains déclenchements en dessous confirme ce que l'opérateur a tapé (rattrape une lecture erronée 0 2 * * * « 02:00 tous les jours » par rapport à 2 0 * * * « 00:02 tous les jours »). Alias reconnus : @daily, @hourly, @weekly, @monthly, @yearly. |
| Fuseau horaire | Fuseau IANA (Europe/Paris, UTC, America/New_York). Les heures cron sont interprétées dans ce fuseau. Les transitions d'heure d'été sont gérées automatiquement. |
| 5 prochains déclenchements | Aperçu en lecture seule des cinq prochains horaires de déclenchement, dans le fuseau de l'opérateur. |
| Instance unique | Interrupteur. Quand activé (défaut), un horaire de déclenchement qui chevauche une exécution encore en cours est ignoré (consigné avec reason = "single-instance"). Quand désactivé, la nouvelle exécution démarre et les deux s'exécutent en parallèle. |
| Délai maximum | Plafond optionnel sur la durée totale d'une exécution. Une exécution qui le dépasse est abandonnée. Les délais par étape se règlent dans l'éditeur d'étape. |
Les jobs qui ne doivent se déclencher qu'à la main ou par API laissent Cron vide.
Sélecteur cron
Pour les opérateurs moins à l'aise avec la syntaxe cron, un bouton Sélecteur cron à côté du champ d'expression ouvre une boîte de dialogue avec des modèles préétablis — Toutes les X minutes, Tous les jours à HH:MM, Chaque semaine le(s) jour(s) à HH:MM, Chaque mois le jour N à HH:MM. Le sélecteur écrit l'expression résultante dans le champ ; les opérateurs avancés peuvent toujours taper l'expression directement.
Paramètres
Une table de paramètres au niveau du job disponibles pour chaque étape sous l'espace de noms params. Utile pour partager une valeur entre étapes — typiquement la période sur laquelle tourne un job nocturne.
| Champ | Effet |
|---|---|
| Nom | Nom du paramètre (par exemple period, dry_run). |
| Type | string / int / float / bool / date / datetime. Pilote le widget de la boîte de dialogue Exécuter maintenant. |
| Défaut | Valeur utilisée quand aucun remplacement n'est fourni. Prend en charge les jetons spéciaux ${today}, ${yesterday}, ${week.monday}, ${month.first}, ${month.previous}, etc. |
| Description | Apparaît comme info-bulle du champ dans la boîte de dialogue Exécuter maintenant. |
Cliquer sur ➕ Ajouter paramètre pour étendre la liste. Le bouton Exécuter maintenant (en haut de la page) ouvre une boîte de dialogue avec une saisie par paramètre déclaré — les déclenchements manuels peuvent remplacer les valeurs par défaut pour une seule exécution.
Politique de relance
| Champ | Effet |
|---|---|
| Tentatives max | Total de tentatives, première incluse. 1 désactive les relances. Défaut 3. |
| Backoff | None / Constant / Exponential. Pilote le délai entre les tentatives. |
| Délai initial | Premier délai entre tentatives. Constant l'utilise pour chaque relance ; Exponential le double à chaque fois. |
| Délai maximum | Plafond du backoff exponentiel. Défaut 600 secondes. |
| Relancer sur | Multi-sélection des catégories d'échec — Erreur (toute exception), Délai dépassé, Connexion. Liste vide = aucune relance (synonyme de Tentatives max = 1). |
| Ajouter du jitter | Interrupteur. Ajoute jusqu'à 25 % de jitter aléatoire à chaque délai — évite les rafales de relances simultanées. Activé par défaut. |
La politique de relance par étape remplace celle au niveau du job ; l'éditeur d'étape expose les mêmes champs.
Étapes
Le pipeline d'étapes est une liste en glisser-déposer — une ligne par étape, exécutée de haut en bas. La poignée ⋮⋮ à gauche réordonne ; ✏️ ouvre l'éditeur d'étape ; ✕ supprime.
| Champ de l'éditeur d'étape | Effet |
|---|---|
| Nom | Unique au sein du job. Apparaît sur la page de détail d'exécution. |
| Type | Un des sql_query, sql_copy, python, http, ldap_sync. Chaque type déploie un formulaire spécifique — voir Types d'étape. |
| Condition | Expression optionnelle — l'étape ne s'exécute que quand elle est vraie. Référence ${params.*} et ${previous_step.*}. Faux → étape skipped, le job continue. |
| Continuer en cas d'erreur | Quand activé, une étape en échec marque l'exécution comme partial-success et les étapes suivantes s'exécutent. Désactivé par défaut. |
| Politique de relance | Remplacement par étape de la politique au niveau du job. Même structure que ci-dessus. |
| Délai maximum | Plafond par étape. |
Le corps de l'éditeur d'étape change avec le sélecteur Type — voir Types d'étape pour chaque variante.
Dépendances
Une multi-sélection d'autres jobs qui doivent avoir réussi le plus récemment pour que ce job s'exécute.
| Statut le plus récent de chaque dépendance | Effet sur le job courant |
|---|---|
succeeded | L'exécution se déroule normalement. |
failed / aborted | L'exécution est skipped avec reason = "dependency-failed: <name>". |
| N'a jamais tourné | L'exécution est skipped avec reason = "dependency-never-ran: <name>". |
running | L'exécution est skipped avec reason = "dependency-still-running: <name>". |
Les cycles sont refusés à l'enregistrement — l'éditeur rejette « le job A dépend de B, B dépend de A ».
À utiliser avec parcimonie ; les longues chaînes s'expriment généralement mieux comme un seul job à plusieurs étapes.
Notifications
Routage léger du résultat d'exécution.
| Champ | Effet |
|---|---|
| En cas de succès | Multi-sélection de canaux notifiés quand le job se termine succeeded. |
| En cas d'échec | Multi-sélection de canaux notifiés quand le job se termine failed / aborted. |
| En cas d'ignorement | Multi-sélection de canaux notifiés quand le job est skipped. |
Canaux disponibles :
| Canal | Configuré dans |
|---|---|
Slack #channel | Paramètres → Framework → Notifications → Slack — coller l'URL du webhook une fois, chaque job choisit dans la liste des canaux. |
Email addr@… | Paramètres → Framework → Notifications → Email — informations de connexion du relais SMTP. |
Webhook <url> | URL personnalisée par job. POST un corps JSON avec l'id d'exécution, le nom, le statut et la durée. |
Interne <role> | Dépose une notification dans le centre de notifications intégré pour chaque utilisateur qui porte le rôle. |
Pour des payloads plus riches (la queue du log d'échec dans un message Slack), ajouter une étape http explicite à la fin du job plutôt que de s'appuyer sur le bloc de notifications.
Exécuter maintenant
Le bouton ▶ Exécuter maintenant en haut de l'éditeur déclenche une exécution manuelle ponctuelle. Quand le job déclare des paramètres, une boîte de dialogue demande les valeurs (avec les valeurs par défaut déclarées pré-remplies). La confirmation envoie l'exécution dans le même ordonnanceur qu'un déclenchement cron — même moteur d'étapes, même politique de relance, même persistance.
Le bouton est filtré par la permission job:<name> ; révoquer job:*:run pour un rôle d'audit qui doit voir les jobs sans pouvoir les déclencher.
Enregistrer
L'enregistrement valide le formulaire :
- La syntaxe cron s'analyse.
- Les références connecteur / requête / endpoint de chaque étape se résolvent contre le catalogue chargé.
- Les références
callablePython s'importent proprement — une fonction manquante fait échouer l'enregistrement. - Les dépendances existent.
- Aucun cycle dans
Dépendances.
Un enregistrement en échec affiche le diagnostic en ligne ; le catalogue reste sur la version précédente. Un enregistrement réussi recharge le job dans l'ordonnanceur en cours d'exécution — le prochain tick cron récupère la nouvelle définition.
Permissions
L'onglet Jobs est filtré par settings:jobs. Les actions par job héritent de job:<name>. Les opérateurs qui ont seulement besoin de voir les exécutions sans modifier les jobs obtiennent jobs:read + job:<name> sans settings:jobs.
Sous le capot
Les définitions de jobs sont enregistrées sous liberty-apps/plugins/<app>/jobs.toml. Les opérateurs n'éditent pas ce fichier à la main en fonctionnement normal ; l'éditeur de jobs est l'interface canonique. Le fichier est analysé au démarrage et à chaque Enregistrer et recharger ; les opérateurs avancés utilisent l'onglet Raw TOML quand une limite de l'éditeur les bloque.
Pour les scripts CI et les orchestrateurs externes, la même surface est accessible via les endpoints REST sous /admin/jobs/* — voir REST API → Jobs.
Pour aller plus loin
- Types d'étape — ce que fait chaque étape et les champs que son éditeur expose.
- Exécutions et supervision — la page d'historique d'exécution, la queue de log en direct, le flux d'abandon.
- Apps et Plugins → Plugins — écrire les callables Python derrière les étapes
python.