Il existe de nombreuses versions de Sunopsis et d’Oracle Data Integrator sur le marché. Chacune s’utilise et s’administre différemment. Depuis le rachat de Sunopsis par Oracle, nombreuses sont les entreprises qui souhaitent migrer vers la dernière version d’ODI désormais intégrée dans l’ensemble des outils Oracle. ODI offre des possibilités de plus en plus larges et intéressantes en terme de productivité. Une migration de Sunopsis vers Oracle Data Integrator demande un certain nombre de vérifications. Il faut en particulier s’assurer qu’après la migration des scenarii, parfois par centaines, l’activité de production n’est pas altérée.Avant la migration, il est nécessaire de créer des nouveaux utilisateurs sur l’instance des référentiels et de leur attribuer les bons droits. Voici un exemple de script à exécuter pour créer un utilisateur prêt à accueillir un référentiel :
create user myuser
temporary tablespace tmptab;
grant connect, resource to myuser;
grant CREATE ANY TABLE to myuser;
grant DROP ANY TABLE to myuser;
grant SELECT ANY TABLE to myuser;
grant INSERT ANY TABLE to myuser;
grant UPDATE ANY TABLE to myuser;
grant DELETE ANY TABLE to myuser;
grant CREATE ANY INDEX to myuser;
grant DROP ANY INDEX to myuser;
grant CREATE ANY VIEW to myuser;
grant DROP ANY VIEW to myuser;
grant CREATE ANY TRIGGER to myuser;
grant DROP ANY TRIGGER to myuser;
grant CREATE ANY DIRECTORY to myuser;
Il existe 2 façons de procéder à une migration de version : une migration par export/import des référentiels (via des dumps), ou une migration par export/import des composants via des fichiers XML.
La migration par export/import XML
Cette méthode n’est pas forcément intéressante. En effet, il peut y avoir des écarts entre la version originale des composants et la nouvelle version. Plus concrètement, si l’ordre de migration de chaque export n’est pas respecté ou si par exemple certains projets ont des liaisons transversales avec d’autres projets, l’import peut être mal réalisé.
Puisque l’architecture d’ODI a évolué par rapport à Sunopsis, la conversion des objets de l’ancienne architecture vers la nouvelle se fait au moment de l’import XML. ODI parse les fichiers et interprète leur contenu pour les transposer dans la nouvelle architecture.
La migration par export/import des dumps de référentiels :
Cette méthode semble la plus sûre, la plus efficace et la plus rapide. Elle consiste à exporter les schémas des référentiels Sunopsis via la commande exp d’Oracle puis de les réimporter dans le nouvel environnement. Cette pure et simple copie des référentiels permet d’assurer l’intégralité des composants et des liens entre eux.
Commande d'export :
exp loguserid=system/pwd@new_SID file=save_path log=log_path fromuser=old_user touser=new_user
Commande d'import :
imp userid=new_SID/pwd file=path/filename.dmp log=path/filename.log
Ces commandes sont à exécuter pour chacun des différents référentiels présents dans ODI. Généralement ce “couple” export/import est donc exécuté à 3 ou 4 reprises, c’est à dire une fois pour le référentiel maître, et une fois pour chaque référentiel de travail (développement, qualification, production…).
ODI permet ensuite une mise à jour de chaque référentiel :
Pour le référentiel maître : dans le menu “Démarrer” il y a une partie “Repository Management” dans laquelle se trouve un outil nommé “Master Repository Upgrade” qui permet de mettre à niveau le référentiel.
Pour les autres référentiels, il faut ouvrir le module Topology, dans la partie Référentiels, en sous-éléments du référentiel maître apparaissent les référentiels de travail migrés. Vous pouvez alors les “mettre à jour”. Une fois l’opération terminée, parfois après plusieurs dizaines de minutes selon la quantité d’éléments à mettre à jour, les référentiels respectent alors la nouvelle architecture d’ODI mise en place par Oracle.
Vérifications après la migration
Rares sont encore aujourd’hui les migrations qui se font sans encombre, c’est pourquoi il est préférable de vérifier que tous les composants migrés de Sunopsis n’ont pas été altérés. Il faut en particulier vérifier le paramétrage des modules de connaissance au sein des interfaces. Il faut également vérifier les contextes d’optimisation. Pour cela, utilisez les schémas des référentiels ODI qui représentent le méta-modèle de données et qui hébergent tous les composants présents dans ODI.
Remarque :
il n’y a pas de vérification particulière à faire s’il s’agit d’un référentiel d’exécution, à contrario du référentiel de développement. Celui-ci contient uniquement les scénarii compilés et prêts à l’exécution.
Supposons que l’on souhaite migrer un référentiel d’une instance A vers une instance B, et supposons que l’on a à disposition un DBLink dblA qui permet d’accéder à A depuis B. Alors une vérification possible pour s’assurer du bon paramétrage des modules de connaisance après la migration est la suivante ; il faut que la requête ne retourne aucune ligne :
select tt.i_folder,
p.project_name,
sue1.i_user_exit,
sue1.i_trt,
sue1.ue_name,
sue1.ue_sdesc,
suu1.i_instance,
suu1.short_value,
suu2.short_value
from snp_user_exit sue1
join snp_ue_used suu1
on suu1.i_user_exit=sue1.i_user_exit
join snp_trt tt
on tt.i_trt=sue1.i_trt
left join snp_project p
on p.i_project=tt.i_project
left join snpwd_upg.snp_user_exit@dblA sue2
on sue1.i_user_exit=sue2.i_user_exit and sue2.ue_name=sue1.ue_name
left join snpwd_upg.snp_ue_used@dblA suu2
on sue2.i_user_exit=suu2.i_user_exit and suu1.i_instance=suu2.i_instance
where nvl(suu1.short_value,'a')<>nvl(suu2.short_value,'a')
union all
select tt.i_folder,
p.project_name,
sue1.i_user_exit,
sue1.i_trt,
sue1.ue_name,
sue1.ue_sdesc,
suu1.i_instance,
suu1.short_value,suu2.short_value
from snpwd_upg.snp_user_exit@dblA sue1
join snpwd_upg.snp_ue_used@dblA suu1
on suu1.i_user_exit=sue1.i_user_exit
join snp_trt tt
on tt.i_trt=sue1.i_trt
left join snp_project p
on p.i_project=tt.i_project
left join snp_user_exit sue2
on sue1.i_user_exit=sue2.i_user_exit and sue2.ue_name=sue1.ue_name
left join snp_ue_used suu2
on sue2.i_user_exit=suu2.i_user_exit and suu1.i_instance=suu2.i_instance
where nvl(suu1.short_value,'a')<>nvl(suu2.short_value,'a');
Si par ailleurs dans les interfaces les contextes d’optimisation sont remis par défaut à “non défini”, c’est sans doute que les valeurs des contextes n’ont pas été correctement modifiées, un update peut alors s’avérer efficace :
update SNP_POP
set opt_ctx_code='newCTX'
where opt_ctx_code='oldCTX';
Plus la version de Sunopsis est ancienne, et plus la migration vers ODI est susceptible de faire apparaître des anomalies. Néanmoins, chaque nouvelle version d’ODI apporte d’importantes corrections qui font qu’après la migration, l’utilisation et l’administration d’ODI est de plus en plus sûre et simple.
