Atol CD est désormais le 1er intégrateur français d’Apache Hop, fort d’une expertise acquise grâce à de nombreux projets de migration et d’industrialisation de chaînes de traitements data.

Apache Hop est un fork de Pentaho Data Integration (PDI), dont il reprend les fondations tout en apportant une approche plus moderne et modulaire. Pour une présentation complète de l’outil, vous pouvez consulter notre article dédié à Apache Hop

La conséquence de ce fork est que HOP et PDI ont un fonctionnement similaire, avec notamment des formats de stockage des traitements qui sont très proches. 

Par principe, il est donc assez simple de migrer de PDI à Apache HOP ! 

La migration vers HOP peut représenter un changement important, en particulier depuis des ETL comme Talend, basé sur un générateur de code Java. Dans ce contexte, certains traitements devront être repensés sous Apache HOP. Bonne nouvelle : notre équipe Data travaille déjà sur un convertisseur Talend2HOP, capable de faciliter la reprise des traitements simples à intermédiaires, afin d’alléger significativement l’effort de transition.

(1) Un fork (“fourche” en anglais) dans le domaine des logiciels est une copie du code source d’un projet qui est ensuite modifiée et développée indépendamment du projet original. Cela permet de créer une nouvelle version ou un logiciel dérivé, souvent avec des objectifs ou des orientations différentes.

# 1. Migration de versions récentes de PDI (v8 et v9)

Apache HOP est un fork de la version 8.2 de PDI. 

Si vous souhaitez migrer vers HOP des traitements PDI à partir d’une version 8 ou 9, un utilitaire de migration est disponible dans HOP, et la migration sera assez facile à réaliser :

Hop propose une fonction d’import qui convertit les fichiers Kettle (.ktr/.kjb) en pipelines/workflows Hop via File → Import from Kettle/PDI dans HOP-GUI ou via le script hop-import 

Référence : https://hop.apache.org/tech-manual/latest/hop-vs-kettle/import-kettle-projects.html

Cet outil permet une conversion efficace de la majorité de vos transformations et jobs. 

Certaines étapes, plugins ou options avancées peuvent nécessiter une intervention manuelle. Il existe des issues connues sur des conversions incomplètes (ex. certains types de jointures, Google Sheets, mappings, etc.). Il faut donc anticiper une phase de correction post-migration, mais de façon générale, l’outil de migration est très efficace. 

# 2. Migration d’anciennes versions PDI (<v8)

Pour la migration d’anciennes versions de PDI, la migration devra être réalisée en 2 phases, avec un passage obligatoire par une version 9 (ou 8) de PDI

# Mise à niveau préalable sous PDI/Kettle

Il n’est pas rare de trouver encore de nombreux projets PDI en production qui reposent sur d’anciennes versions de PDI (7.x, 6.x et parfois 5.x ou 4.x ! ). 

Il est important de noter que les formats générés par ces versions ne sont pas directement exploitables par Apache Hop avec l’outil de migration intégré.

Une première étape consiste donc à mettre à jour les projets vers une version récente et stable de PDI, comme la 9.3. Cette montée de version intermédiaire facilite l’export et sécurise l’ensemble du processus de migration.

# Export des projets depuis le référentiel PDI/Kettle

Lorsque les projets sont stockés dans un référentiel PDI (stockage en base de données), la migration doit obligatoirement passer par une étape intermédiaire d’export :

• Dans PDI, l’opération se fait via le menu :  Outils → Référentiel → Export du référentiel.
  Cette action génère un fichier unique au format XML, qui regroupe l’ensemble des jobs et des transformations.
  
• Ce fichier XML peut ensuite être importé dans une version plus récente de PDI (par exemple la 9.3) au moyen du menu :  Outils → Référentiel → Import du référentiel.

En complément, il existe des outils open source (comme l’outil KREX) permettant d’exporter directement les jobs et transformations depuis un référentiel vers des fichiers indépendants au format .ktr et .kjb. 

Il est aussi possible de faire cette extraction au moyen d’un script python directement sur le fichier XML exporté du référentiel. Cette dernière approche offre plus de contrôle et permet aussi de gérer d’éventuels problèmes d’encodage. 

Un point d’attention important concerne la gestion des chemins absolus : dans de nombreux projets historiques, les appels entre jobs et transformations reposent sur des chemins fixes. Après migration, ces références doivent être adaptées, sans quoi certains enchaînements ne fonctionneront plus correctement.

# Import et adaptation sous Apache Hop

Une fois les traitements importés dans une version PDI 9.x, l’utilitaire de migration d’Apache HOP peut être utilisé.

# 3. Points d’attention lors d’une migration vers HOP

Même si Apache Hop facilite la reprise des projets PDI, certaines contraintes techniques apparaissent fréquemment lors des migrations. L’expérience montre que les deux points suivants méritent une attention particulière.

# La gestion des chemins absolus : le cas des projets stockés dans un référentiel PDI

Dans de nombreux projets historiques stockés dans un référentiel PDI, on constate que les appels entre jobs et transformations reposent sur des chemins absolus et non relatifs.

 Lors d’une migration, ces références deviennent obsolètes et ne correspondent plus aux nouveaux emplacements des fichiers, ce qui entraîne des erreurs d’exécution et des enchaînements interrompus.

• Pour un projet de taille réduite, la correction peut être effectuée manuellement en ajustant les chemins directement dans les jobs et transformations concernés.
  
• En revanche, dans des environnements comportant plusieurs centaines de jobs et transformations, cette approche ne peut plus être mise en œuvre.

Pour éviter des adaptations manuelles fastidieuses, nous avons donc développé des scripts Python capables d’analyser automatiquement les fichiers (.ktr et kjb) et de réécrire dynamiquement les chemins. Grâce à cette automatisation, il devient possible de traiter efficacement des projets de grande taille – certains dépassant des centaines de jobs et transformations – et de garantir la cohérence de l’ensemble avant l’import dans Apache Hop.

# La gestion des paramètres de connexion aux sources de données définis en dur

Dans certains projets historiques développés sous PDI, il n’est pas rare de retrouver les paramètres de connexion aux bases de données (JDBC) directement renseignés en dur dans chaque job ou transformation. 

Dans ce cas précis, les bonnes pratiques de développement n’ont pas été respectées, car il aurait fallu variabiliser les définitions de ces connexions (à minima dans le fichier kettle.properties)

Cette pratique, bien que fonctionnelle, pose plusieurs problèmes sur le long terme :

• À chaque modification des informations de connexion (changement d’hôte, d’utilisateur, de mot de passe, etc.), il est nécessaire de mettre à jour manuellement l’ensemble des jobs et transformations concernés.
  
• Sur un projet de petite taille, la correction peut être réalisée assez simplement ou remplacée par une factorisation des connexions JDBC au travers de variables ou de fichiers de configuration.
  
• Mais dans un projet d’envergure, comportant plusieurs centaines de jobs et transformations, cette opération devient extrêmement fastidieuse et source potentielle d’erreurs.

Pour ce cas de figure, le pôle Data Atol CD a également développé des scripts Python permettant d’identifier et de corriger systématiquement les connexions définies en dur. 

# 4. Réussir sa migration Apache HOP

1. Pour des versions anciennes de PDI (antérieures à 8) : prévoir une montée de version intermédiaire
   Passer d’une ancienne version de PDI directement à Hop comporte des risques. Il est préférable de mettre d’abord à jour les projets sous une version récente de PDI (comme la 9.3) afin de faciliter l’export et la conversion.
   
2. Automatiser les ajustements à effectuer
   Dans les cas qui le nécessitent, les scripts pour corriger les chemins absolus et vérifier la cohérence des fichiers ktr/kjb sont indispensables dans les projets de grande taille. L’automatisation réduit le temps de migration et limite les erreurs humaines.
   
3. Documenter et tester progressivement
   Avant la mise en production, il est recommandé de documenter les workflows et transformations migrés, de réaliser des tests unitaires et fonctionnels, et de valider les processus critiques étape par étape.
   
4. Former les équipes et adapter les environnements
   L’interface d’Apache Hop diffère de celle de PDI, et certains concepts ont été modernisés (gestion des projets, métadonnées, environnements). Chez Atol Conseils et Développement, nous accompagnons nos clients en leur proposant des formations personnalisées sur Apache Hop, afin de sécuriser l’adoption, faciliter la prise en main et maximiser l’efficacité des équipes.

Lien vers offre formation :

 : https://www.atolcd.com/fileadmin/Formations/Formation_Apache_HOP.pdf

En suivant ces bonnes pratiques, la migration devient plus prévisible, rapide et fiable, tout en tirant pleinement parti des atouts d’Apache Hop.

Si vous souhaitez approfondir le sujet, plusieurs ressources expliquent pas à pas comment réussir votre migration de PDI vers Apache Hop, à commencer par cette vidéo : 

upgrade from Pentaho Data Integration to Apache Hop

N’hésitez pas à contacter notre équipe data pour toute demande d’accompagnement sur votre migration PDI vers HOP !