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