Skip to main content

Orchestrer des pipelines

Ce guide passe en revue les briques d'orchestration les plus utiles pour construire un workflow : exécuter des pipelines, brancher, boucler, paralléliser, réessayer et alerter. Les paramètres exhaustifs sont dans la référence des composants d'orchestration.

Un workflow d'orchestration Un enchaînement type : déclencheur → sous-pipelines → condition → notification.

Exécuter des sous-pipelines​

La brick Exécuter un pipeline lance un pipeline de données du projet depuis le workflow. Elle expose deux sorties :

  • Success : le sous-pipeline s'est terminé sans erreur ;
  • Fail : il a échoué ; branchez-y votre gestion d'erreur ou une alerte.

Enchaîner plusieurs bricks Exécuter un pipeline (la sortie Success de l'une vers l'entrée de la suivante) construit une séquence : chaque pipeline attend la fin du précédent.

Transmettre des variables​

La brick accepte une liste de variables transmises au sous-pipeline. Dans le pipeline appelé, elles se lisent via ${var.workflow.NOM}. Les valeurs supportent l'interpolation ${...} : vous pouvez donc propager une variable du workflow ou une valeur calculée en amont.

Poser des valeurs dans le contexte

La brick Définir variable stocke une valeur dans le contexte du workflow (${var.workflow.NOM}), réutilisable en aval et transmise aux sous-pipelines déclenchés.

Borner la durée​

Le paramètre Timeout limite la durée du sous-pipeline (une heure par défaut). Au-delà, le sous-pipeline et sa descendance sont arrêtés, et la brick sort par Fail avec timed_out à vrai. Mettre 0 retire la limite.

Un sous-pipeline sans limite qui se bloque bloque le workflow entier : gardez une valeur cohérente avec la durée réellement attendue plutôt que de désactiver le garde-fou.

Diagnostic d'un échec

Quand le sous-pipeline échoue sans produire de log d'erreur exploitable, la brick remonte les dernières lignes de sa sortie d'erreur dans le champ stderr — c'est là qu'apparaissent les erreurs d'import ou les plantages survenus avant que la journalisation ne démarre.

Brancher avec des conditions​

La brick Condition évalue une expression booléenne (syntaxe Python) sur les variables du workflow, sur le résultat d'un appel de pipeline (${(Nom de l'appel).format} == "xml", voir Interface de pipeline) ou sur les résultats des bricks amont (par exemple ${prev.row_count} > 1000) et émet le signal sur sa sortie True ou False. Chaque branche continue son propre chemin.

Boucler avec Pour chaque​

La brick Pour chaque itère sur une liste et exécute la séquence branchée sur sa sortie Pour chaque item pour chaque élément ; la sortie Terminé émet quand toutes les itérations sont finies. L'élément courant est exposé via ${item}.

Trois sources de liste :

  • Variable workflow : un chemin comme ${prev.results} ou ${prj.country_list} ;
  • Fichiers d'une connexion : les fichiers d'une connexion storage qui correspondent à un pattern ;
  • Réponse API.

Les itérations sont séquentielles par défaut ; activez Itérations en parallèle (avec une concurrence max) pour les lancer simultanément. Un plafond Max itérations protège contre les listes accidentellement énormes.

Paralléliser puis synchroniser​

  • Parallèle lance simultanément toutes les branches connectées à sa sortie (fan-out), avec une concurrence maximale optionnelle ;
  • Synchronisation referme l'éventail : elle attend les branches entrantes avant de poursuivre, selon sa condition de passage : all (toutes), any (la première terminée) ou count (un nombre minimum).

Le motif classique : Parallèle → n bricks Exécuter un pipeline → Synchronisation → suite du workflow.

Réessayer en cas d'échec​

La brick Réessayer ré-exécute la branche aval en cas d'échec :

  • Essais max : nombre total de tentatives ;
  • Stratégie de délai : fixed (délai constant) ou exponential (délai doublé à chaque essai) ;
  • Délai initial en secondes.

Elle émet sur Succès dès qu'une tentative aboutit, sur Abandon après épuisement des essais.

Capturer les erreurs​

La brick Gestion d'erreur protège une branche : si tout va bien, le signal sort par OK ; en cas d'échec amont, elle bascule sur Sur erreur au lieu d'interrompre le workflow. Le paramètre Erreurs capturées cible toute erreur, les seuls timeouts ou les échecs d'assertion.

La brick Assertion complète le dispositif côté contrôle qualité : elle évalue une expression (ex. ${var.workflow.row_count} > 0) et, si elle est fausse, stoppe le workflow, route sur sa sortie Échec ou émet un simple avertissement, selon le réglage.

Temporiser​

La brick Attendre suspend le flux : durée fixe (N secondes), jusqu'à une heure donnée (HH:MM) ou jusqu'à un événement (signal webhook entrant, avec secret et timeout optionnel).

Notifier​

La brick Alerte envoie une notification sur le canal de votre choix (email, Slack, Teams ou webhook), avec un niveau (info, warning, erreur). Branchez-la typiquement sur la sortie Fail d'un sous-pipeline ou la sortie Abandon d'un Réessayer. Elle s'appuie sur une connexion (SMTP, Slack, endpoint), dont la valeur peut différer par environnement.

Notifications dans un pipeline de données

Pour notifier depuis un pipeline DATA (rapport de fin d'exécution, stats du DataFrame), utilisez plutôt la brick Notification côté chargeurs.

Et ensuite ?​