Présentation
ETI*Extract est un ETL : il extrait des données d’une source, et
les intègre à une cible. Le principe de fonctionnement est
le suivant : l’utilisateur spécifie les traitements, et les
spécifications serviront à générer du code
source pour réaliser la t&acric;che.
Le premier objectif d’ETI*Extract était de permettre la migration
de bases de données. Si par exemple une application Cobol est
réécrite en C et utilise une base Oracle, ce produit
permettait d’initialiser la nouvelle base Oracle à partir des
données de l’ancienne base Cobol. Les programmes
générés par ETI*Extract ont donc à ce niveau
pour vocation de ne s’exécuter qu’un nombre réduit de fois,
et n’évolueront quasiment jamais : le code généré
est jetable.
Quelques années plus tard, ETI*Extract a connu une seconde jeunesse
avec l'essor des projets décisionnels. Toutefois, la
maintenance et l’évolutivité demeurent délicats.
Il n’en reste pas moins vrai que cet ETL est très puissant et,
l’utilisateur ayant la main sur la génération du code, n’a pas
de limite (règles de gestion complexes et très
particulières, etc).
Vocabulaire
Les termes utilisés ici sont souvent ceux d’origine (en Anglais) car
il n’existe pas toujours de traduction évidente pour certains d’entre eux.
Le Conversion Specialist ou CS (encore appelé spécialiste
d'intégration) spécifie les traitements dans des Conversions.
Pour cela, il va essentiellement :
- établir des Mappings entre données sources et cibles
pour indiquer une relation de dépendance
- poser des Filtres sur les données pour exprimer des
opérations de contrôle, sélection, transformation, ...
Le Master User ou MU (appelé aussi architect d'intégration)
va travailler principalement sur deux types d’objets :
- les Grammaires, qui définissent les Filters que pourra
utiliser le CS ainsi que leur traduction en variables contextuelles
- les Templates, qui permettent de transformer les Conversions en
code quelconque
Templates
ETI*Extract est livré avec des librairies de Templates et Grammaires,
que l’éditeur appelle DSL. Les utiliser est tentant car elles
permettent de développer rapidement des traitements d’extraction et
d’intégration de données. Si votre projet nécessite un
traitement qui récupère des données dans une base DB2
pour les intégrer dans une base Oracle, vous pouvez ainsi utiliser les
DSL COBOL/DB2 et C/ORACLE. Néanmoins, leur utilisation n’est pas
toujours économique :
- les Grammaires contiennent de nombreux Filtres qui ne seront jamais
utilisés dans le projet : le travail des CS en sera ralenti
- l’environnement de développement des Templates est très
pauvre : l’implémentation de fonctionnalités propres à
votre projet ou l’optimisation de certaines opérations exige un
développement long et fastidieux
- les mises à jour des DSL ne peuvent prendre en compte les
modifications du MU : les mises à jour d’ETI ne sont pas utilisables
- les aspects techniques des traitements sont localisés dans les
Templates : à chaque évolution technique, il faut
regénérer et relivrer tous les codes
Librairies dynamiques
Une alternative efficace consiste à utiliser des librairies dynamiques
partagées par tous les programmes dont le code a été
généré par ETI*Extract ; le code généré
devient très simple (il se contente d’appeler des fonctions des librairies),
et on peut donc écrire ses propres Templates et Grammaires pour se passer
complètement des DSL d’ETI :
- les Filtres sont adaptés au projet, et donc facilement utilisables
par les CS, qui peuvent d’ailleurs avoir un profil davantage fonctionnel que
technique lors de leur recrutement
- le coût d’implémentation de nouvelles fonctionnalités
ou d’optimisation est fortement réduit car les environnements de
développement de librairies sont très riches, les développeurs
plus faciles à trouver que des MU (on n’a alors besoin que d’un seul MU
pour modifier les Templates)
- les modifications d’ordre technique ne nécessitent que la relivraison
de la librairie : c’est plus rapide, et il y a possibilité d’optimiser les
procédures de test. Seules les modifications fonctionnelles imposeront de
regénérer le code à partir des Conversions et de le relivrer
Mise en oeuvre
Une bonne démarche pour l’utilisation des librairies est la suivante :
- recensement des fonctionnalités de base à implémenter
- développement d’un prototype composé d’un programme le plus
déclaratif possible, et d’une ou plusieurs librairies utilisée par
ce programme
- écriture des templates pour générer, à partir
des spécifications, des fichiers comparables au source du prototype
Conclusion
Cette approche a été testée sur le projet BDM (Base de
Données Marketing) de la Société Générale.
Nous avons vu qu’un traitement repose sur deux DSL : une pour accéder
aux données sources, et une pour alimenter le système cible.
Initialement, la DSL C/Oracle et une DSL spécifique ont été
utilisées. Il s’est avéré que la maintenance et
l’évolution de la DSL C/Oracle coûtait beaucoup plus cher que celle de
notre DSL maison.
Par la suite, des optimisations techniques pour l’accès aux bases Oracle
à l’aide des OCI Oracle impactant plus de 200 Conversions ont conduit à
réfléchir à une externalisation du code dans des librairies ;
parallèlement, un nouveau MetaStore ETI*Extract a été mis en
place pour réaliser des extractions du Datawarehouse vers d’autres
systèmes d’information de la Société Générale ;
bien entendu, l’usage de librairies partagées a été retenu
dès le départ de ce sous-projet.
L’externalisation du code a posteriori a été très coûteuse.
En revanche, la mise en place du MetaStore d’extraction a été
très rapide, et s’est révélée très
intéressante en coûts de maintenance et évolution :
- recensement des fonctionnalités de base et prototypage = 5 jours
- écriture des grammaires et templates = 2 jours
Une évolution qui demandait 5 jours avec les DSL d’ETI ne demande plus qu’une
seule journée avec l’utilisation de librairies.
De plus, cette architecture s’est révélée très profitable
lors des migrations Oracles successives (8.0 vers 8i et 8i vers 9i), ainsi que lors
de la montée en version de l’OS (SunOS 5.4 vers Solaris 8) et du
compilateur (Sun Workshop 4 vers Forte 7).
Retour