Vous avez jeté votre dévolu sur la suite Talend et êtes maintenant prêt à soulever des montagnes en intégration de données ? Bravo. Cependant la mise en place de ce bel outil nécessite quelques bonnes pratiques à connaître avant que vos projets ne prennent l’eau et que vos ressources ne désertent.
J’avais envie d’écrire un article moins technique et de raconter des expériences vécues chez différents clients, retenez juste que le succès ou l’échec peuvent dépendre de ces quelques règles, cependant il ne faut pas se formaliser, considérez ceci comme étant un retour d’expériences personnelles de plusieurs années d’utilisation.
Erreur n°1 – Engager ou dédier exclusivement des développeurs java
Le coup classique, Talend étant un générateur de code java qui s’appuie sur le projet Eclipse Modeling Framework (EMF), il est logique pour beaucoup de personne d’impliquer des développeurs java afin de pouvoir lire et comprendre ce code. C’est une grossière erreur, le code peut effectivement être copié collé et intégré dans un autre application, mais il ne doit en aucun cas être maintenu ou modifié à la main. Talend est comme un langage à part entière, il faut donc penser Talend en premier lieu et surement pas java, connaître java est évidemment un plus bienvenu et peut aider à la compréhension d’une erreur de compilation lorsque l’on ouvre l’onglet « Code ».
Ce qu’il va se passer: Vos développeurs java vont s’insurger et prétendre qu’ils peuvent faire mieux avec leur propre code, pire, ils ne feront pas l’effort d’apprendre à utiliser les différents composants et utiliseront un composant paramétrable (tJava) avec 1000 lignes de code. Résultat: des jobs qui, certes, fonctionneront mais seront très difficilement maintenables graphiquement parlant.
Mon conseil: Talend est un langage de programmation à lui seul et fort heureusement certains développeurs sont de bonne volonté et curieux, demander leur comment ils voient la chose et s’ils veulent ajouter une corde à leur arc mais éviter de leur forcer la main, j’ajouterai que la flexibilité à plutôt tendance à décroître avec leur expérience 😉
Erreur n°2 – Croire que l’on va pouvoir tout faire avec la version communautaire
La version communautaire est juste « un client » qui permet de développer des jobs, vous devrez donc les sauvegarder, les déployer et les ordonnancer vous même à l’ancienne c’est-à-dire avec des outils tiers genre rundeck ou via l’installation manuelle d’un plugin git. Vous aurez besoin de plus de connaissances techniques ce qui n’est pas le cas lorsque l’on débute sur l’outil, à moins d’avoir sous la main quelqu’un qui puisse vous aider comme mes réponses à vos questions ou commentaires en bas de mes articles 😉
Ce qu’il va se passer: Si vous ne prenez pas soin de sauvegarder manuellement le code source Talend qui je rappelle est basé sur une syntaxe xml maison, vous risquez de voir tourner des jobs en production sans retrouver la trace de ce code source, le support étant inexistant vous serez tenté de vous tourner vers la version professionnelle sans vous y attendre et vous vous retrouverez avec une dépense supplémentaire non prévue dans votre budget. Résultat: Une grosse perte de temps et peut être l’obligation de refaire certains jobs avec tout le cycle de test par environnement qui s’impose.
Mon conseil: Entourez-vous de personnes qui connaissent déjà Talend pour la version communautaire, le support sera fourni en cas de version professionnelle.
Erreur n°3 – Avoir un administrateur système hermétique aux nouveautés
Ceci s’applique spécialement pour ceux qui utilisent la version professionnelle mais encore plus pour la version ESB. Voici une liste non exhaustive: TAC (Talend administration console), CommandLine, Karaf (ESB Conductor), JobServer, Référentiel de librairies Nexus, serveur SVN (ou Git), Elastic Search, Kibana, Service locator (ZooKeeper), Webservices CXF, etc… Autant dire qu’il risque d’ajouter pas mal d’outils gravitant autour de Talend dans un environnement déjà surchargé par vos applications et serveurs existants.
Ce qu’il va se passer: Un administrateur système déjà bien chargé comme un mulet bottera en touche, il ne voudra pas se former et arguera que Talend n’est pas dans son giron. Résultat: Vos développeurs étant les plus techniques, l’un d’entre eux sera désigné pour veiller sur la TAC et le reste de l’équipe finira par déployer leurs jobs et scruter leurs logs eux-mêmes avec les risques que cela comporte.
Mon conseil: Pareil que pour les développeurs java, poser la question à votre administrateur ne vous coutera rien, voyez s’il a du temps à consacrer et prévoyez aussi du temps pour qu’il puisse se former aux nouveaux outils qui sont susceptibles de débarquer.
Erreur n°4 – Redévelopper la roue
Talend propose beaucoup de fonctionnalités annexes avec la version professionnelle, ces solutions sont parfois peu, voir pas du tout exploitées à 100%, la documentation n’est pas lue car abondante et vous aurez le sentiment qu’il manque des choses ou que celles-ci sont incomplètes ou négligées par Talend, vous aurez comme un goût de trop peu.
Ce qu’il va se passer: Des fonctionnalités annexes ou des bonnes pratiques vont être repensées et re-développées avec évidemment de la nouvelle documentation qui les accompagnera, pire cette documentation sera propre à votre projet et votre environnement. Résultat: Une grosse perte de temps pour vos développeurs qui vont devoir se concentrer sur de nouvelles règles inconnues au bataillon, la lourdeur en résultant risque de leur faire baisser les bras.
Mon conseil: Dans le cas d’un besoin spécifique, ne pas hésiter à déposer un ticket au support ou demandez conseil à quelqu’un de plus technique, comme dis plus haut la documentation est abondante et elle est surtout accessible gratuitement sur le net.
Erreur n°5 – Pas de revue de code
Les nouveaux développeurs Talend avec un peu de pratique vont se lancer corps et âme et avec la meilleur volonté du monde dans la création de jobs que vous avez imaginés. Tout fonctionnera dans la meilleur des monde et puis un jour, c’est l’horreur, la mémoire commence à saturer dû à une volumétrie exacerbée, de nouveaux besoins beaucoup plus pointus apparaissent comme la reprise sur erreurs ou l’analyse des logs
Ce qu’il va se passer: Des jobs qui deviendront de véritables usines à gaz et beaucoup trop lourds à maintenir, les temps d’exécution risquent d’exploser et vous finirez par remettre tout à plat par manque d’analyse.
Mon conseil: Cette pratique est un peu couteuse mais essayez de déléguer une ressource à la vérification des développements, le test unitaire étant un peu compliqué, il est préférable de suivre une liste de bonnes pratiques à respecter (Exemple: Utiliser plus de composants et moins de code, construire de gauche à droite et de haut en bas, privilégiez les requêtes SQL au mapping de 50.000 composants sur un tMap, etc…), refusez de déployer et renvoyez les mauvaises pratiques vers vos développeurs afin qu’ils corrigent, ils seront évidemment frustrés dans un premier temps mais finiront par évoluer rapidement et sainement, ils vous remercieront plus tard 😉
Conclusion
Voila quelques idées théoriques et pratiques pour s’en sortir plus facilement avec l’adoption de Talend, j’espère qu’elle pourront vous servir à ne pas reproduire des erreurs souvent rencontrées et difficile à solutionner car une fois le projet lancé et faute de ne pas en avoir eu connaissance, il est souvent trop tard pour revenir en arrière.
