Votre pipeline tourne. Il lit vos fichiers, alimente votre base, et vous l’avez même rendu portable en externalisant ses variables dans un environnement. Reste une question désagréable : il s’exécute encore dans Hop GUI, sur votre machine, quand vous cliquez sur le bouton d’exécution. Or le chargement doit partir chaque nuit à 2 h, sur un serveur, que votre portable soit ouvert ou non.
C’est le rôle de Hop Server, que la documentation officielle décrit comme « a lightweight web server that hosts a Hop runtime for remote execution » : un serveur léger qui héberge un moteur Hop, expose une interface web et un jeu de services HTTP pour lancer des traitements et suivre leur état. Cet article vous fait passer de l’exécution locale à l’exécution distante, puis planifiée.
Prérequis
- Apache Hop 2.19.0 (version stable publiée le 17 août 2026) ou une version récente
- Java 21 installé, sur votre poste comme sur le serveur : la page de téléchargement d’Apache Hop indique explicitement « Apache Hop requires Java 21 to be installed on the system »
- Un projet Hop et au moins un environnement fonctionnel
- Un pipeline qui s’exécute correctement en local
1. Démarrer le serveur
Hop Server n’est pas un composant à installer séparément : il fait partie de la distribution que vous avez déjà décompressée. Dans le dossier d’installation, vous trouvez hop-server.sh sous Linux et macOS, hop-server.bat sous Windows.
La forme la plus simple prend une adresse d’écoute et un port :
./hop-server.sh 127.0.0.1 8080Sur un serveur qui doit être joignable depuis d’autres machines, écoutez sur toutes les interfaces :
./hop-server.sh 0.0.0.0 8080Un point à connaître avant d’aller plus loin : l’authentification est activée par défaut, et les identifiants livrés sont cluster pour le nom d’utilisateur comme pour le mot de passe. C’est confortable pour un premier essai, et évidemment à changer avant toute mise en production.
Les options de la ligne de commande les plus utiles au quotidien :
| Option | Forme longue | Rôle |
|---|---|---|
-a |
--auth |
Permet de désactiver l’authentification (valeur par défaut : true) |
-u |
--userName |
Utilisateur, pour les opérations d’administration |
-p |
--password |
Mot de passe, pour les opérations d’administration |
-j |
--project |
Projet à activer au démarrage |
-e |
--environment |
Environnement de cycle de vie à activer au démarrage |
-n |
--server-name |
Nom de l’objet de métadonnées serveur à démarrer, à utiliser avec -e |
-s |
--system-properties |
Propriétés système, sous forme de paires CLE=VALEUR séparées par des virgules |
-gs |
--general-status |
Affiche l’état général du serveur |
-swt |
--shutdown-timeout |
Nombre de secondes d’attente des exécutions en cours lors de l’arrêt (0 par défaut : arrêt immédiat) |
Retenez particulièrement --shutdown-timeout : avec sa valeur par défaut de 0, un redémarrage du service interrompt sans ménagement les pipelines en cours. La même valeur se pilote par la variable d’environnement HOP_SERVER_SHUTDOWN_TIMEOUT, ce qui est plus pratique dans une unité systemd ou un conteneur.
2. Passer par un fichier de configuration
Dès que la configuration dépasse deux arguments, on la déporte dans un fichier XML que hop-server.sh accepte directement à la place du couple adresse/port :
./hop-server.sh /foo/bar/hop-server-config.xmlL’ossature du fichier est la suivante :
<hop-server-config>
<hop-server>
<name>server-8181</name>
<hostname>localhost</hostname>
<port>8181</port>
<username></username>
<password></password>
</hop-server>
<max_log_lines>0</max_log_lines>
<max_log_timeout_minutes>1440</max_log_timeout_minutes>
<object_timeout_minutes>1440</object_timeout_minutes>
</hop-server-config>Trois réglages comptent sur un serveur qui tourne en continu. max_log_lines borne le nombre de lignes de log conservées en mémoire ; laissé à 0, le serveur s’appuie sur la variable HOP_MAX_LOG_SIZE_IN_LINES, dont le comportement par défaut est de tout garder. max_log_timeout_minutes fixe la rétention de ces lignes et object_timeout_minutes la durée pendant laquelle une exécution terminée reste visible dans l’état du serveur ; les deux valent 1440 minutes, soit une journée. Le fichier accepte aussi un bloc <sslConfig> avec <sslMode>Y</sslMode> pour passer en HTTPS, et un bloc <jetty_options> puisque le serveur repose sur Jetty.
Enfin, le serveur sait démarrer directement dans un environnement de projet. La documentation donne cette forme :
./hop-server.sh -e graph-aws hop-server.xmlL’environnement apporte au serveur ses fichiers de variables et le dossier racine du projet. Le fichier de configuration est alors retrouvé automatiquement dans ce dossier par son chemin relatif : vous n’avez plus de chemin absolu à maintenir dans votre script de démarrage.
3. Déclarer le serveur dans le projet
Le serveur tourne, votre poste doit maintenant savoir le joindre. Dans Hop GUI, créez un objet de métadonnées Hop Server. Ses champs : le nom du serveur, le nom d’hôte ou l’adresse IP, le port — attention, s’il est laissé vide la valeur retenue est 80 —, un nom d’application web optionnel, l’utilisateur, le mot de passe, et une case Use https protocol, désactivée par défaut.
Cet objet vit dans les métadonnées du projet, donc dans Git. Ne saisissez pas les identifiants en clair : reprenez le réflexe de l’environnement et renseignez ${HOP_SERVER_HOST}, ${HOP_SERVER_USER}, ${HOP_SERVER_PASSWORD}, dont les valeurs vivront dans le fichier de configuration de l’environnement.
4. Une configuration d’exécution « Remote »
Un pipeline ne s’adresse jamais à un serveur directement : il passe par une pipeline run configuration. Créez-en une de type Remote. Ses options :
- Hop server — le serveur distant sur lequel exécuter le pipeline, c’est-à-dire l’objet créé à l’étape précédente
- Run configuration — la configuration à utiliser sur le serveur distant ; dans la majorité des cas une configuration locale, mais ce peut être une configuration Spark, par exemple
- Server poll delay (ms) — délai avant interrogation du serveur, 1000 ms si non renseigné
- Server poll interval (ms) — intervalle entre deux interrogations, 2000 ms si non renseigné
- Export linked resources to server? — envoie au serveur non seulement le pipeline courant, mais aussi les pipelines et workflows qu’il référence
- Named resources reference source folder / target folder — le dossier de référence côté source, typiquement
${PROJECT_HOME}, et son équivalent côté serveur
Cette dernière paire d’options règle la question du déploiement. Lorsque l’export des ressources liées est actif, Hop empaquette le pipeline et ses dépendances dans une archive envoyée au serveur et réécrit au passage les références de fichiers : un ${PROJECT_HOME}/mapping.hpl devient un ${Internal.Entry.Current.Folder}/mapping.hpl, résolu relativement côté serveur. Vous n’avez donc pas obligatoirement à déployer votre projet sur la machine cible pour l’y exécuter. Une configuration Remote équivalente existe pour les workflows, avec les mêmes options.
5. Lancer depuis la ligne de commande
Le déclenchement se fait avec hop-run, en désignant par -r la configuration d’exécution distante plutôt que local :
./hop-run.sh \
-j facturation \
-e facturation-prod \
-r remote-prod \
-f ${PROJECT_HOME}/pipelines/chargement-clients.hpl \
-l BASIC \
-lf /var/log/hop/chargement-clients.logL’option -lf (--logfile) écrit le log console dans le fichier de votre choix, ce qui est le minimum vital pour une exécution non surveillée.
6. Surveiller les exécutions
Le serveur expose une interface web sur l’adresse et le port de démarrage — http://localhost:8081 dans les exemples de la documentation. Elle liste les pipelines et workflows connus et leur état.
Pour l’automatisation, ce sont les services HTTP qui comptent. Les plus utiles :
| Service | Rôle |
|---|---|
/hop/status |
État général du serveur, en HTML, ou en XML avec ?xml=Y, ou en JSON avec ?json=Y |
/hop/pipelineStatus |
État d’un pipeline : exécution, transforms, aperçu |
/hop/workflowStatus |
État d’un workflow |
/hop/execPipeline |
Exécute un pipeline directement à partir d’un chemin de fichier |
/hop/execWorkflow |
Exécute un workflow directement à partir d’un chemin de fichier |
Le service d’exécution s’appelle en GET, le paramètre pipeline portant le chemin du fichier .hpl, avec résolution des variables ; level fixe le niveau de log, runConfig la configuration d’exécution, et tout paramètre supplémentaire de l’URL est transmis au pipeline :
curl "http://serveur:8081/hop/execPipeline?pipeline=/opt/hop/projets/facturation/pipelines/chargement-clients.hpl&runConfig=local&level=BASIC&DATE_TRAITEMENT=2026-09-07"La réponse est un bloc <webresult> contenant un élément <result> à OK en cas de succès, ou du JSON si vous ajoutez &json=Y.
7. Et la planification ?
Hop Server exécute à la demande : il ne remplace pas un ordonnanceur, il lui donne une cible propre à appeler. Trois montages tiennent la route selon votre contexte.
- cron ou le planificateur de tâches, qui appelle
hop-runou une URL/hop/execPipeline. Simple, sans dépendance supplémentaire, suffisant pour quelques traitements indépendants. - Apache Airflow, lorsque vous avez des dépendances entre traitements et besoin de reprises. La documentation d’Apache Hop consacre un guide à cette intégration et décrit trois voies : le DockerOperator avec l’image
apache/hop, le BashOperator pour appelerhop-rundirectement, ou l’opérateur HTTP « to run pipelines or workflows on a remote hop server ». - Votre serveur d’intégration continue, Jenkins ou GitLab CI, si vos traitements sont déjà couplés à des déploiements.
Dans les trois cas, le principe reste le même que pour les environnements : l’ordonnanceur ne connaît qu’un projet, un environnement et un nom de pipeline. Aucune valeur d’infrastructure ne remonte dans sa configuration.
Ce que vous avez gagné
Vos traitements ne dépendent plus d’une session Hop GUI ouverte. Ils s’exécutent sur une machine dimensionnée pour cela, avec des logs dans un fichier, un état consultable en HTTP et un point d’entrée unique pour l’ordonnanceur. Et comme le serveur démarre dans un environnement de projet, la bascule recette/production reste ce qu’elle était : un nom passé en argument.
Le prolongement naturel, une fois ce socle en place : fiabiliser ce qui s’exécute ainsi sans surveillance, avec les tests unitaires de pipelines et la gestion des lignes rejetées.
Pour aller plus loin
- Hop Server — démarrage, options et fichier de configuration
- Hop Server Web Services — la liste complète des services HTTP
- Remote Pipeline Engine — les options de la configuration d’exécution distante
- Hop Server (métadonnées) — les champs de l’objet serveur
- Run workflows and pipelines in Apache Airflow — le guide officiel d’intégration