Migration ODI vers Stambia

Une migration technologique est un projet complexe qui pose toujours de nombreuses problématiques. Les technologies source, ODI (Oracle Data Integrator), et cible, Stambia ou Semarchy xDI doivent être maitrisées. Il faut conduire une importante phase d'analyseet de reflexion pré-migration, et enfin la migration et l’apprentissage du nouvel outil doivent s’effectuer en parallèle de l’existant et de façon à ne pas interrompre l’exploitation quotidienne. De plus, il faut également être en mesure de tester, maintenir et/ou rétablir l’intégrité du patrimoine une fois migré.

Il faut également prendre en compte que la solution Stambia est dorénavant rattachée à l’éditeur Semarchy, sous le nom de « Semarchy xDI ». La migration peut donc tout aussi bien s’effectuer de ODI vers « l’ancienne version » Stambia ou de ODI vers Semarchy xDI.

Les points clés à connaître concernant la migration ODI vers Stambia ou Semarchy xDI

Le point essentiel à prendre en compte lors d’une migration ODI vers Stambia / Semarchy xDI est que l'outil de migration Stambia / Semarchy xDI permet de transformer à 99% un patrimoine ODI en patrimoine Stambia / Semarchy xDI viable. Toutefois, certaines subtilités présentes dans les interfaces et procédures ODI ne soient pas parfaitement retranscrites dans Stambia. De ce point va donc découler l’étape la plus importante et complexe de la migration : la recette, qui sera détaillée un peu plus bas dans cet article.

Exemple de mapping sous ODI :

Le même mapping migré sous Stambia :

Le contexte de la migration ODI vers Stambia offre également une très grande modularité des enchaînements de traitements, permettant une migration et une mise en exploitation au fil de l'eau (mixité progressive entre ODI et Stambia). Nous conservons donc une grande flexibilité et maîtrise tout au long de ce processus, avec une transition en douceur, contrôlée et sans interruption.

Autre point important, la philosophie de conception est identique entre ODI et Stambia (ELT orienté données et règles de mapping), y compris sur l'ergonomie du poste de développement. Cela permet une prise en main rapide pour les développeurs, qui peuvent recycler leurs connaissances et conserver leurs habitudes de développement.

Il faut aussi logiquement se préparer à un changement de terminologie entre les deux outils. Concernant cette problématique, et comme expliqué dans le paragraphe précédent, un grand nombre de concepts ODI sont migrables en 1 pour 1 sur Stambia, ce qui simplifie encore l'appréhension de la migration.

ODI / STAMBIA

Interface / Mapping

Procédure / Process

Modèle / Metadata

Package / Process

KM / Template

Contexte / Configuration

Scenario / Delivery

Agent / Runtime

Comment s’effectue une migration depuis ODI vers Stambia ?

Nous allons donc voir le déroulement de la migration de ODI vers Stambia et la principale difficulté de la migration.

Les prérequis pour la migration ODI vers Stambia

Une migration de ODI vers Stambia peut s’effectuer à partir des versions suivantes de Oracle Data Integrator / Sunopsis :

• ODI 10.x, ODI 11.x, ODI 12.x
• Sunopsis 3.x

Pour pouvoir réaliser cette migration, il faut aussi préalablement préparer / posséder un environnement avec les caractéristiques suivantes :

• Au moins 8Go de mémoire vive, et 10Go disponibles sur le disque dur
• Système d’exploitation Windows 7 ou +
• Excel version 2010 ou +

Le déroulement de la migration ODI vers Stambia

Une fois les prérequis techniques vérifiés et complétés, nous pouvons passer à la migration en elle-même. Pour cela, il existe un outil mis à disposition par l’éditeur Stambia : l’outil de migration, qui comprend lui-même plusieurs « sous-outils », dont l’outil d’extraction de l’existant, qui va être indispensable pour la première étape de la migration. En tant que partenaires de Stambia, les équipes de Next Decision peuvent vous accompagner dans l'obtention de ces outils.

Ces outils sont en fait des projets / processus Stambia qui fonctionnent et s’exécutent sur un Designer en version 19, qui viendra se connecter au référentiel ODI. Il y aura donc une étape préalable de paramétrage de ces processus pour les faire pointer sur les bonnes ressources.

Les projets / processus qui composent l'outil de migration : 

Une fois ces différents éléments paramétrés et mis en place sur l’environnement, la migration va se dérouler en 4 étapes :

Étape 1 : Faire tourner l’outil d’extraction de l’existant, dont le contenu sera récupéré dans une base de travail. Ce dernier va générer un fichier excel (userparameters) qui contiendra l’existant ODI : Knowledge modules (KMs), interfaces, procédures, contextes, etc.

Étape 2 : Paramétrer le fichier excel de configuration de migration ainsi généré. Cela va nous permettre, entre autres, à faire les correspondances entre les KMs ODI et les Templates Stambia, ainsi qu’à indiquer quels sont les objets à migrer.

Aperçu du fichier Excel généré suite à l'extraction :

Étape 3 : Lancer l’outil de migration, puis récupérer les objets migrés pour les déposer dans le répertoire de travail de Stambia souhaité (soit par exemple vers un Workspace intermédiaire pour effectuer le transfert des objets recettés au fur et à mesure, soit vers le Workspace « final » et recetter directement dessus).

La principale difficulté de la migration ODI vers Stambia : le recettage

La dernière étape de la migration, la plus complexe et chronophage, va être le débogage puis le recettage des objets migrés dans Stambia. Logiquement, cette étape va donc être particulièrement « lourde » si l’existant ODI est conséquent.

Car comme énoncé précédemment, bien que l’outil de migration soit très puissant, Stambia et ODI restent des outils différents. Il est donc nécessaire de passer par cette étape essentielle du recettage pour valider / corriger toutes les conversions effectuées par l’outil, ou en d’autres termes, pour s’assurer de l’intégrité de l’existant migré.

La difficulté provient effectivement du fait qu’un objet ODI migré en Stambia doit donner les mêmes résultats que l'exploitation ODI quotidienne. Cela nécessite souvent la mise en œuvre d'un environnement de double run comme le montre le schéma ci-dessous : 

Cela demande également la mis en place d'outils et procédures, afin d'identifier les divergences entre la "Cible(Production)" et la "Cible(Stambia)"
Toute cette charge, qui peut s’effectuer petit à petit comme exposé dans les points clés de la migration ODI vers Stambia, va donc nécessiter une certaine organisation : un suivi des éléments à déboguer, à recetter, à mettre en production côté Stambia, avec peut-être un journal des modifications ou un outil de versionning, ou un découpage des éléments en lot à passer en production si l’existant est trop conséquent par exemple.

De plus, cette dernière étape, qui nécessite l’exécution des procédures et interfaces migrés, ne peut être effectuée que si l’environnement de travail Stambia a été préalablement configuré : rajout des JDBCs éditeur pour les accès aux différentes bases de données, création et connexion à un Runtime (équivalent Agent dans ODI) pour permettre le lancement des flux, etc.

Toutes ces étapes peuvent être résumées et illustrées par le schéma suivant :

Enfin, pour ouvrir une petite parenthèse, le fait d’effectuer une migration peut également être l’occasion de se (re)mettre à suivre certaines bonnes pratiques et règles, comme par exemple :

• Instaurer ou mettre à jour vos conventions de nommage
• Revenir sur le tri et l’organisation des projets, des metadatas, des serveurs de fichiers…
• Créer et variabiliser les metadatas précédemment renseignées « en dur » dans les traitements ODI, notamment pour le travail avec les fichiers plats

Retour page précédente Retour au Wiki

Next Decision est Diamond Partner et intégrateur de Stambia. Vous avez un projet de migration ODI vers Stambia ? Contactez-nous !