AXOPEN

Migration d’une application avec l’ETL Talend

Cet article fait part de la solution TalenD, de ses tenants et aboutissants lors d'une démarche de Migration.

L'obsolescence d'un certain nombre de produits et d'applications maintenant trop anciens ou ne répondant plus aux besoins actuels, conduit le plus souvent les entreprises à changer d'environnement.
De ce fait, lors de de la migration vers ce nouveau système, ou encore du passage vers une nouvelle version d'une application dans son ensemble ou d'une base de données, les données doivent être préservées dans leur intégralité.
De même, dans le cas d'une acquisition ou d'une fusion,  un bon nombre d'applications redondantes sont la majeure partie du temps, délaissés, mais les renseignements qu'elles contiennent doivent être conservés dans le système persistant.
Transférer les données existantes dans le nouvel environnement tout en n'altérant pas la qualité de celles-ci est le but de la migration de données. Celles-ci doivent être transformées (d'ou le "T" de l'acronyme ETL) sous un format approprié pour le nouveau système et ce, tout en préservant l'information et l'intégrité stockée dans l'ancien système.

diagram_migration

Difficulté : La diversité des données et leurs traitements associés

Dans les contextes de migration d'applications ou de systèmes, la migration des données est souvent perçue comme la partie la plus annexe et simpliste. Cependant, effectuer une migration de données sans encombre et sans conséquences négative à la fois pour l'administrateur et pour l'utilisateur peut révéler du véritable challenge, suivant les environnements rentrant en jeux. 
Voici plusieurs points essentiels à garder en tête lors du démarrage et de l'analyse d'un projet migration.

  • La quantité de données impliquées lors de migrations est souvent de l'ordre d'un volume conséquent.
    La première erreur à ne pas produire est de sous estimer cette volumétrie. 
    Il faut aussi savoir que dans certains cas, la société souhaite ne pas effectuer de purge dans ses données, la migration concernant alors tout l'historique des transactions de l'entreprise.
    C'est pour cela que savoir distinguer le périmètre de reprise doit également faire partie des premiers réflexes à avoir. 
  • Les structures sources et cibles sont souvent différentes et se place dans des contextes hétérogènes. Ce qui se complexifie d'autant plus lorsque de nombreux Systèmes/Sous-systèmes sont en relation (père/fils,  héritage) avec l'application à migrer. Une absence ou une mauvaise documentation de tout cela engendre encore plus de difficultés lors des phase des chargements, mapping et transformations.
  • Après que les données aient été migrées, la notion de cohérence doit être de mise, dans de nombreux cas. Avoir un système implémenté de façon progressive auprès des utilisateurs en est un illustre exemple car il est nécessaire de lier les deux systèmes (l'ancien et le nouveau) par des synchronisations dîtes bidirectionnelles. Un autre exemple demandant un minimum de cohérence et de coordination est le fait d'avoir une base de donnée utilisée par de nombreuses applications qui dans le futur, ne seront pas migrées en même temps.

Réponse : Talend pour l'Intégration/la Migration de Données


La suite Talend complète offre toute une gamme de logiciels permettant de répondre à de nombreuse problématique : ESB, Big Data, BPM, MDM, Qualité de données et Intégration de données.
C'est ces deux dernières solutions qui montrent tout leur intérêt lors de la Migration d'applications.
Talend Open Studio étant le nom générique donné pour la version gratuite et Talend Integration Suite pour la version full professionnelle (application intranet de suivi des flux, développement partagés…etc.)


talend_logo
 

Les solutions Open Source d'intégration de données de Talend sont donc parfaitement adaptées pour les migrations de données d'entreprise.
Il se démarque de ces concurrents sur le nombreux points qui en fond de lui un des leader dans le domaine, autant du point de vue design que pour le développement et l'exécution de processus de migration de données :

  • Une exploitation poussée des architectures ETL (Extract-Transform-Load) et ELT (Extract-Load-Transform) grâce à une plateforme profondément évolutive et performante.
  • Plus de 450 systèmes (source et cible) reconnus grâce à une vaste gamme de connectivité.
  • Un coté métier fortement mis en avant grâce à une implication des intervenants dans un modèle orienté Business pour une coordination optimale lors de la migration des données.
  • L'ergonomie et la productivité sont améliorées de manière significative à l'aide de l'environnement de développement entièrement graphique, facilitant ainsi l'exécution des tests unitaires et permettant facilement la réutilisation/duplication des étapes de transformations et de mapping dans des cas de synchronisation applicable.
  • Un planificateur de tâches ordonnançant et gérant les processus et les flux de migration suivant les systèmes mis en œuvvre tout en prenant en compte la notion de logs, la détection, la gestion et les notifications/messages d’erreurs, selon le résultat du process migratoire de l'environnement source donné.​

Mise en situation du produit Talend for Data Integration

Sera utilisé ici Talend Open Studio for Data Integration (V5.2.1).  

La prise en main de l'outil y est simplifiée à l'extrême grâce à son interface globale. 
Dans le cas d'une migration basique d'une base source vers une base cible (appartenant à deux environnements distincts à la structure différente), le Repository principal permet de parcourir d'un coup d'
œil les jobs, contexte et métadonnées. Talend est ainsi capable d'extraire aussi bien les informations d'une base Oracle que d'un fichier Excel.
C'est dans cette partie Métadonnées que seront initialisées plus particulièrement les connections sources et cibles.

talend_menu_repository

Bien qu'il soit théoriquement possible de s'en sortir avec le Repository seul,  il est toutefois rare en pratique d'avoir à migrer des informations dans deux bases/deux fichiers similaires sans procéder à des transformations, conditions, jointures…

Talend dispose fort heureusement d'une très large palette permettant de sélectionner des composants de tous genres (types de bases de données, action sur des fichiers, regroupement de données…etc.)

talend_menu_palette

Le job ci-dessous présente donc un transfert de données d'une table source vers une table cible.
Le mapping et la transformation des champs sont effectués grâce au composant tMap (un des plus utiles).

talend_flux_test

S'il s'agit là d'un cas assez simpliste, il est bien évidement possible de décupler ces possibilités avec Talend en créant des jobs à l'échelle du système à migrer.
Le tout sera orchestré par des jobs pères/fils dispatchés en domaine.

Le scénario se déroulera alors de la sorte : 

  • Le job principal n'est composé que du lancement du job père global à la migration.
  • Le job père peut ensuite lancer une multitude de jobs fils (si nécessaire) en leur passant des paramètres
  • Les jobs fils peuvent à leur tour exécuter leurs propres fils et ainsi de suite.
  • Les informations des jobs sous-fils remontent a leur job père respectif (terminaison OK/KO, avertissement…)
    Suivant les conditions reçus et la planification prévue, le flux suit sont cours jusqu'a qu'il ne trouve plus rien à lancer.
  • Si tel est le cas, une base/application d'erreurs peut être mise en place afin de visualiser/corriger les lignes qui ne sont pas passées.

C'est dans cette dernière optique qu'il est conseillé d'implémenter une gestion des erreurs. Talend peut lui même, à l'aide de composants à ajouter à chaque fin d'une étape sensible, retourner un code d'erreur ou même un mail si le cas se présente.

Ci dessous un exemple de ce que donnerais le job précédent avec une gestion d'erreur de base.

talend_flux_test_error

Si une erreur survient sur un composant de l'étape,  un mail est envoyé à l'adresse spécifié. L'objet du mail et le corps sont bien sur personnalisables.
Un avertissement est mis en avant avec un code et un message là aussi spécifique à l'étape de l'erreur.
Cet avertissement est visible dans la console et dans les logs.

NB: Comme mentionné plus haut,  il est techniquement possible de procéder à une implémentation des erreurs plus poussées en récupérant les rejets, lors de l'alimentation de la table, et d'insérer ces rejets dans une base propre a la gestion des erreurs.