Votre chaîne de traitement fonctionne. Un premier pipeline extrait les commandes de la veille, un deuxième enrichit les clients, un troisième alimente le datamart. Vous les lancez à la main, dans le bon ordre, en surveillant la console. Puis vient le jour où le premier pipeline ne trouve pas son fichier source : les deux suivants s’exécutent quand même, sur des données incomplètes, et personne ne s’en aperçoit avant le comité de direction.
Le problème n’est pas dans vos pipelines. Il est dans le fait qu’il n’existe nulle part, dans votre projet, un objet qui dise : « d’abord ceci, puis cela, et si ceci échoue, alors préviens-moi et arrête tout ». Cet objet existe dans Apache Hop, c’est le workflow.
Prérequis
- Apache Hop 2.19.0, version stable publiée le 17 août 2026, et Java 21, requis par cette version.
- Un projet Hop configuré, avec au moins deux pipelines
.hplfonctionnels. - Un accès au terminal pour les exécutions en ligne de commande de la section 6.
1. Pipeline ou workflow : deux modèles d’exécution différents
La confusion la plus fréquente consiste à voir le workflow comme « un gros pipeline ». Le moteur n’est pourtant pas le même.
Dans un pipeline, la documentation est explicite : « a pipeline runs all of its transforms in parallel ». Tous les transforms démarrent en même temps et les lignes circulent entre eux au fil de l’eau. Il n’y a pas d’étape 1 puis d’étape 2.
Dans un workflow, c’est l’inverse : « Workflows work sequentially by default. Each action […] needs to wait before the previous actions have completed before it starts ». Et surtout : « Workflow actions do not pass data over hops » — les liaisons d’un workflow ne transportent pas de lignes de données, seulement un statut.
| Pipeline (.hpl) | Workflow (.hwf) | |
|---|---|---|
| Unité de base | Transform | Action |
| Exécution | Parallèle | Séquentielle |
| Ce qui circule sur les hops | Des lignes de données | Un statut succès / échec |
| Rôle | Le travail sur la donnée | L’orchestration |
La formule de la documentation résume la répartition des rôles : les pipelines font « the heavy data lifting », les workflows assurent « orchestration tasks ».
2. Créer votre premier workflow
Dans Hop GUI, passez par File → New → Workflow, ou par le bouton New de la barre d’outils horizontale puis l’option Workflow. Le fichier obtenu porte l’extension .hwf, là où vos pipelines portent l’extension .hpl.
Une action Start est ajoutée automatiquement au canevas. Elle n’est pas décorative : « Every workflow needs to have one and only one start action ». Une seule, ni zéro ni deux.
Ajoutez ensuite vos actions depuis le panneau latéral, puis reliez-les. Pour tracer un hop, maintenez la touche Shift et faites glisser d’une action vers l’autre, ou sélectionnez une action et utilisez le bouton Create hop. Un enchaînement minimal se compose de trois actions : Start, Pipeline, Success.
3. Router selon le succès ou l’échec
C’est ici que le workflow gagne son intérêt face à un simple script shell. Chaque action expose un statut de sortie : « each workflow action has a success or failure exit status ». Le type de hop que vous tracez décide de ce qui est suivi.
- Unconditional hop (icône cadenas, trait noir) : suivi « no matter what the exit code (true/false) of the previous action is ».
- Success hop (icône de validation, trait vert) : suivi uniquement si l’action précédente a réussi.
- Failure hop (icône d’erreur, trait rouge) : suivi uniquement si l’action précédente a échoué.
Le scénario de l’introduction se traite alors directement sur le canevas. Depuis l’action Pipeline qui charge les commandes, tracez un hop vert vers le pipeline d’enrichissement, et un hop rouge vers une action Mail suivie d’une action Abort workflow.
Cette dernière « immediately stops (aborts) a running workflow ». Elle expose un champ Message, ajouté au log au moment de l’arrêt, et un Log level of the message dont la valeur par défaut est Error. Abaisser ce niveau évite que le message apparaisse comme une erreur, mais la documentation prévient que « the workflow is marked as failed either way » : un workflow parent suivra donc son propre hop d’échec, ce qui est le comportement souhaité dans une chaîne imbriquée.
Les actions Checks if files exists, Evaluate rows number in a table et Simple evaluation complètent utilement ce dispositif : elles vérifient une condition avant de laisser la chaîne se poursuivre.
4. Configurer l’action Pipeline
L’action Pipeline est celle que vous utiliserez le plus. Ses options sont réparties sur quatre onglets.
L’onglet General contient Action name, le champ Pipeline — le chemin vers le fichier, converti automatiquement en chemin relatif ${PROJECT_HOME} — et Run Configuration, qui détermine où le pipeline sera exécuté.
L’onglet Options propose notamment Clear results rows before execution, Wait for remote pipeline to finish et Follow local abort to remote pipeline, ces deux dernières n’ayant de sens qu’avec une exécution distante. L’onglet Logging permet d’écrire un fichier de log dédié via Specify logfile, avec des options de nommage telles que Include date in filename.
L’onglet Parameters gère la transmission des valeurs vers le pipeline enfant, avec Pass parameter values to sub pipeline et le bouton Get Parameters. Attention : les paramètres doivent exister dans les propriétés du pipeline appelé, ou être déclarés ici.
5. Faire circuler des données entre deux pipelines
Puisque les hops de workflow ne transportent pas de lignes, comment passer un jeu de résultats d’un pipeline au suivant ? Historiquement, la réponse était le couple Copy rows to result / Get Rows from Result, associé à l’option Execute for every result row de l’action Pipeline.
Ne partez pas sur cette voie pour un nouveau développement. La documentation qualifie Copy rows to result de transform « mainly available for historical reasons », incompatible avec les moteurs Beam Spark, Beam Flink et Beam Dataflow. Le guide consacré aux boucles est encore plus net sur la combinaison avec Execute for every result row : « DO NOT use this option in new development », parce qu’elle rend le débogage et la maintenance difficiles.
Les trois approches recommandées aujourd’hui sont le transform Pipeline Executor, le transform Workflow Executor, et le couple d’actions Repeat / End repeat. L’action Repeat « repeats the pipeline or workflow of your choice until a certain condition is met » : vous désignez le fichier dans File to repeat, la variable d’arrêt dans Stop repeating when this variable is set, une valeur précise dans Optional variable value, et une temporisation dans Delay in seconds.
6. Exécuter le workflow hors de l’interface graphique
Un workflow n’a de valeur opérationnelle que lancé sans interface. L’outil hop-run accepte indifféremment un .hpl et un .hwf :
./hop-run.sh \
--project=commandes \
--environment=prod \
--file='${PROJECT_HOME}/workflows/chargement-quotidien.hwf' \
--runconfig=local \
--parameters=DATE_TRAITEMENT=2026-09-14 \
--level=BasicChaque option a une forme courte : -j, -e, -f, -r, -p, -l. Sous Windows, le script est hop-run.bat. Les niveaux acceptés par --level sont NOTHING, ERROR, MINIMAL, BASIC, DETAILED, DEBUG et ROWLEVEL.
Deux options sont particulièrement utiles en exploitation. -lf / --logfile redirige la sortie console vers un fichier. Et -a / --startaction, propre aux workflows, permet de reprendre l’exécution à partir d’une action donnée : précieux pour relancer une chaîne longue après correction d’une étape intermédiaire, sans rejouer ce qui a déjà abouti.
Le --runconfig renvoie à une workflow run configuration, une métadonnée créée avec le bouton New à côté du champ Workflow run configuration (champs Name, Description, Engine type). Deux moteurs existent : le Local workflow engine et le Remote workflow engine, qui délègue à un Hop Server.
7. Une mise en garde sur la planification
L’action Start expose des options de répétition : Repeat, Type of period, Interval, Start time. La tentation est grande d’y voir un ordonnanceur intégré.
La documentation précise que ces options conviennent pour du « basic scheduling » mais ne remplacent pas un ordonnanceur dédié comme cron ou Apache Airflow : activer la répétition maintient le processus Java vivant en permanence, avec la consommation de ressources correspondante.
La règle pratique : le workflow décrit quoi exécuter et dans quel ordre, l’ordonnanceur externe décide quand. Le point de rencontre entre les deux est la ligne hop-run de la section précédente.
Ce que vous avez gagné
Votre chaîne de traitement n’est plus une suite de lancements manuels dont l’ordre existe seulement dans votre tête. Elle est un fichier .hwf versionné, qui déclare les dépendances entre pipelines, se comporte de façon définie en cas d’échec, s’exécute d’une seule commande depuis un ordonnanceur et se reprend à mi-parcours avec --startaction. C’est aussi le point de départ naturel de l’exécution sur Hop Server et de l’intégration dans une chaîne CI/CD.