GUIDE COMPARATIF ETL. www.viseo.com

GUIDE COMPARATIF ETL www.viseo.com

Table des matières Généralités... 2 L enjeu... 2 A qui s adresse ce guide?... 2 Préambule... 2 Les outils d alimentation : «générateur» ou «moteur», 2 concepts... 3 Les générateurs... 3 Les moteurs... 4 Conclusion... 6 ETL et EAI... 7 Les outils d alimentation, introduction... 7 Les ETL, généralités... 7 Les EAI, généralités... 8 ETL versus EAI... 9 Architecture... 10 Questionnaire opérationnel... 14 Contexte projet... 15 Architecture générale... 16 Plateformes et connectivités supportées... 17 Complexité, montées en charge & dimensionnement... 19 Fonctions de transformation et de programmation... 19 Données... 21 Gestion de référentiel et Documentation associée... 22 Exploitation... 23 Intégration avec de grands progiciels du marché... 24 Solutions pré-configurées... 25 Données commerciales et économiques... 26

Généralités L enjeu Les entreprises ne doivent plus disposer d un Système d Information avec une vocation de production mais d un Système d Information Décisionnel (SID) dont la vocation est véritablement le pilotage de l entreprise. La vocation d un ETL (Extract Transform Load) dépasse désormais le cadre de la notion de SID pour devenir un système d échange inter applicatifs. A qui s adresse ce guide? Ce guide s adresse aux maîtrises d ouvrage, aux responsables de projets et aux maîtrises d œuvre. L objectif de ce document est de fournir une information claire et suffisamment détaillée pour comprendre et appréhender les problématiques de choix d une solution de type ETL. Préambule Le triple objectif assigné au système d information décisionnel est : Connaître Mesurer Prévoir Les moyens pour y parvenir sont les suivants : Une information riche, pertinente, détaillée, historisée, fiable et non volatile Des outils d analyse et de restitution puissants et adaptés à chacun des métiers concernés Une forte capacité d évolution (architecture, flux, outils). Une analyse faite par le Gartner Group démontre que le budget alloué aux problématiques d intégration de données représente souvent plus de 50% d un projet informatique. Etant donné le nombre sans cesse croissant d applications hétérogènes, l intégration des données est un enjeu stratégique pour les entreprises. Le choix de l outil d alimentation est un facteur déterminant pour la réalisation de ces plateformes d intégration de données et, d une façon générale, pour tout projet informatique basé sur des mouvements de données. Les mouvements des données sont de 3 types : L acquisition, Le stockage (SGBD, ODS, Data WareHouse, Data Mart, etc.), L exploitation (restitution, reporting, etc). L acquisition des données se décompose en 3 étapes : L extraction des données, La préparation / transformation des données,

Le chargement des données. La préparation des données est une phase particulièrement importante : elle conditionne la qualité et la quantité des données à traiter. C est effectivement au cours de cette phase que vont se dérouler les opérations de dédoublonnage, de normalisation et de reformatage des données, de contrôle d intégrité. C est également l occasion de s interroger sur la fiabilité des données («Cette valeur est-elle correcte?») et sur la pertinence des données («Ai-je besoin de cette information?»). L extraction des données peut être réalisée via l utilisation de : Programmes spécifiques, Outils de réplication, Outils d alimentation. Remarques : Le terme «outil d alimentation» englobe les ETL et les EAI. ETL est quelquefois utilisé comme terme générique pour «outil d alimentation». Les outils d alimentation se décomposent en 2 catégories : les «générateurs» et les «moteurs». Les outils d alimentation : «générateur» ou «moteur», 2 concepts Parmi la diversité des outils d alimentation, on distingue 2 familles distinctes d outils : Les générateurs, Les moteurs. Les générateurs Les générateurs sont des outils d alimentation qui génèrent du code source (C, Cobol, etc.) via des bibliothèques appelées «grammaires» ou «Data System Langage» ou «modules de connaissance» selon les outils. Le choix de ces bibliothèques est défini lors de l installation du produit. Le code généré est fonction de l environnement dans lequel le traitement est réalisé. Ainsi, l ETL génèrera du Cobol en environnement MVS/DB2 et du Pro*C en environnement Unix/Oracle (codes natifs). Un développement fait avec un «générateur» s appelle un job ou une conversion. Chaque développement réalise plusieurs traitements en source et/ou en cible (exemples : tris de fichiers, jointure puis agrégation). Dans le cas d environnements sources et cibles différents, l ETL génère 2 codes source spécifiques : «Query» «Populate».

Remarque : Le code généré doit être compilé puis exécuté pour réaliser le traitement attendu. Si le traitement se déroule sur une seule et même plateforme (ex : Unix-Unix) et selon les possibilités de l ETL, il génèrera un unique code source pour le «Query» et le «Populate». Les générateurs de code offrent l avantage de générer un code standard qui peut être consulté et modifié à volonté. Ce code sera directement utilisé et intégré dans les chaînes d alimentation par les équipes d exploitation. Il est possible d intervenir manuellement (ou de façon automatique via une customisation) sur n importe quelle ligne de code. Tous types de transformation et de traitement sont alors possibles. Le code généré étant spécifique à l environnement, les temps de traitements sont optimums. Ce code peut bien entendu être customisé et optimisé selon les besoins ou selon des contraintes techniques particulières. Un générateur de code est donc un outil d alimentation particulièrement adapté aux problématiques de fortes volumétries et aux transformations complexes. L inconvénient majeur de ce type d outil est le manque de souplesse. Une fois installé, il nécessite une période de paramétrage assez lourde (plusieurs semaines) et des périodes de customisation pour définir certains paramètres récurrents et adapter l outil au contexte du client (normes, serveurs, variables, etc.). Par ailleurs, il nécessite de bonnes compétences en programmation : il faut être en mesure de comprendre le code généré pour éventuellement l optimiser. Enfin, un générateur de code ne fait que délivrer un programme prêt à être compilé et exécuté. Il reste à la charge du client toutes les tâches d exploitation classiques : Ordonnancement de l enchaînement des traitements (scheduling), Gestion des rejets, Actions à tenir sur incidents, Console d administration, Monitoring, Passage des développements en environnements de recette ou de production, Etc. Un des principaux avantages de ces générateurs est de pouvoir déployer «gratuitement» à l infini les programmes. Les moteurs Les outils d alimentation de type «moteurs» sont répertoriés selon 2 catégories : Les moteurs de transformation embarqués Les moteurs de transformation non embarqués Les «moteurs de transformation embarqués» signifient que les traitements sont effectués par l outil. En effet, les moteurs de la seconde catégorie ne disposent pas

de possibilités de transformation de données : ils utilisent les fonctionnalités, et donc les ressources, des systèmes sources et cibles. NB : Ce principe de fonctionnement peut avoir un impact non négligeable pour d autres transactions sur ces plateformes sources/cibles. Un moteur ne disposant pas de moteur de transformation utilisera, par exemple, le moteur Oracle et donc les possibilités offertes (fonctions disponibles) par le moteur du SGBDR. Ce type d outil d alimentation permet de ne pas disposer de serveur dédié au moteur de transformation puisque la charge est répartie. La machine qui héberge l ETL n a donc pas besoin d être surdimensionnée. Les moteurs de transformation génèrent un code propriétaire (généralement non accessible). Ce code n a pas besoin d être compilé : il est interprété et donc directement exécuté par le moteur. Ce concept a l avantage de simplifier le travail des développeurs car ils n ont pas besoin de connaître ni de savoir debugger des langages de programmation. Ils ne font qu utiliser une panoplie de fonctions proposées par l outil. Par conséquent, les possibilités de transformations sont limitées à cette liste de fonctions proposées par l outil en natif. Le gros avantage de ce type d outil d alimentation est sa souplesse d utilisation. Rapides en termes d installation et de prise en main, ces outils offrent également des cycles relativement courts de mise à disposition de l information du fait de : Temps de développements courts, Possibilités d évolution rapide et de réutilisation des développements, Interfaces conviviales et ergonomiques (interfaces sous forme de modules, clic-souris, raccourcis clavier de type Microsoft, etc.), Etc. D autre part, parmi les moteurs de transformation, certains permettent de répartir la charge sur plusieurs serveurs afin de paralléliser certains traitements par exemple. Un moteur d alimentation est une solution intégrée. Ce sont des outils qui offrent (en option ou pas) des possibilités plus ou moins riches en termes d administration et d exploitation avec des Scheduler intégrés, la gestion native des rejets, la génération de logs spécifiques, etc. D autres fonctionnalités intéressantes sont parfois disponibles selon les outils : Data Quality ou nettoyage des données à traiter, Génération de documentation automatique avec les sources, les cibles et les règles de gestion, Envoi d alertes, Envoi de mails, Décompression à la volée de fichiers source, Possibilité de simuler les process, Possibilité de lancer des routines externes avant et/ou après le traitement, Analyse d impact (permet d analyser l impact de la modification sur un développement),

Etc. Certains outils offrent également la possibilité d ajouter des modules capable de prendre en charge la gestion des processeurs. Ainsi, il est possible d optimiser les traitements au niveau le plus fin et d avoir une adéquation traitement/matériel particulièrement performante. Remarque : Ces possibilités d administration des processeurs ne sont pas dédiés aux traitements développés via le moteur, ils sont également utilisables par des programmes externes de l entreprise (C, C++, etc.). Conclusion Le choix de la technologie est la première étape dans le choix d un ETL : «moteur» ou «générateur». Une fois ce choix fait, il faut s orienter vers une solution de type ETL ou de type EAI. Attention : c est le besoin qui doit conditionner le choix de l outil et non l inverse. Parmi les EAI, on ne retrouve que des moteurs. Par contre, parmi les ETL, il existe des «moteurs» ou des «générateurs».

ETL et EAI Les outils d alimentation, introduction Sous la dénomination «ETL» ou «outil d alimentation», se retrouvent en fait 2 familles d outils : Les ETL : Extract Transform Load Les EAI : Enterprise Application Integration Si le concept de ces 2 types d outils est proche (extraire et transformer des données), les périmètres d intervention sont relativement distincts de par leurs fonctionnalités. Les ETL, généralités Les outils ETL sont de plus en plus présents dans nos systèmes d information, compte tenu de notre besoin de faire communiquer nos différentes applications, d une part et, d autre part, de la multiplicité de nos supports et structures de données : fichiers plats délimités, fichiers XML, bases de données relationnelles, bases de données multidimensionnelles,... Bien souvent, les données stockées dans une ou plusieurs sources doivent être liées, transformées et chargées dans une ou plusieurs cibles. Les outils d ETL permettent de générer facilement des mappings entre les sources et les cibles, en transformant, si nécessaire, les données avec un ensemble de fonctions mises à disposition. Les outils d ETL permettent donc de structurer les différentes sources, cibles, transformations au sein du référentiel unique de l outil. Enfin, la possibilité d ordonnancer les différents transferts (fonction scheduler) est également possible avec les principaux outils du marché. En résumé, les outils d ETL permettent : D extraire des données à partir de sources hétérogènes : bases de données, fichiers plats, fichiers XML... De les transformer, les filtrer, les mapper de façon simple et souvent graphique De les charger dans une ou plusieurs cibles hétérogènes : bases de données, fichiers plats, cubes OLAP, fichiers XML... Ils facilitent l industrialisation des flux de l entreprise par : La conception aisée des flux L administration de l ensemble des flux : droits associés à chaque utilisateur L exploitation des flux : planification, traitement des rejets, gestion de logs, relances,... La maintenance des flux : modification rapide, gestion des versions,... L ensemble des métadonnées (définition des sources et cibles, transformations, logs,...) est stocké dans un référentiel unique de l outil L analyse d impact permet d analyser l impact d une modification d un système sur les autres.

Enfin, les outils d ETL sont destinés au traitement de flux de type batch à forte volumétrie, contrairement aux outils d EAI orientés process et business. Les EAI ont pour caractéristique de traiter de faibles volumes de données : ils alimentent des applications en quasi temps réel, d où des mises à jour portant généralement sur quelques milliers d enregistrements. Ils offrent également moins de possibilités de transformations que les ETL. Leur intérêt réside principalement dans la rapidité à mettre à disposition l information grâce à des cycles courts de développement. D autre part, les EAI sont des outils adaptés au business et les principaux utilisateurs sont les opérationnels ayant des compétences informatiques. Nous pouvons distinguer plusieurs types d offres ETL : Les suites intégrées Les «suites intégrées» sont des outils intégrés à : o Un SGBD o Une suite logicielle décisionnelle o Un portail Ces outils ne sont pas le cœur de métier de l éditeur concerné ; ils sont souvent proposés dans le cadre d un package. C est pour l éditeur la volonté de proposer une offre complète, globale et unique. Les ETL universels Parmi les outils universels, nous retrouvons les grands noms des outils d alimentation : éditeurs dont le cœur de métier se focalise sur les problématiques de traitements des données. Les ETL spécialisés Il s agit des outils d alimentation dont les spécialités sont : o Un environnement source ou cible particulier hors BD standard (MVS, VSAM, ERP, etc.) o Un type de traitement (extraction seulement,...) o La gestion des fortes volumétries o Les EAI, généralités Une «plateforme d intégration» signifie la mise en place d un logiciel qui prend en charge le dialogue inter applications. Sans ces plateformes d intégration, les nombreuses applications de l entreprise échangent beaucoup d informations. On voit apparaître «l effet spaghettis» : une multitude d applications qui communiquent une à une (on parle de «point à point») via des interfaces qui doivent bien souvent être paramétrées et maintenues séparément. Différentes études démontrent une explosion annoncée du nombre des applications au sein des entreprises (SCM, CRM, pilotage, etc.). Ce phénomène de «point à point» va donc s amplifier.

Faire communiquer des applications non initialement prévues pour échanger des informations (données fournisseurs, données de la chaîne logistique, etc.), c est là tout l enjeu des outils d intégration appelés Enterprise Application Integration (EAI). Mettre en place une plateforme d intégration de données, c est donner la possibilité à une entreprise d industrialiser et de rationaliser l échange de ses informations. Pour remplir cette fonction, un EAI doit assumer 4 fonctions : Routage Transformation Connexion aux applications Transport. En effet, suite à un événement précis, un EAI récupère les données d une application, les transforme puis les route vers leur destination (une autre application). Pour cela, il est nécessaire de disposer : d un serveur d intégration pour la transformation des données de connecteurs pour la communication avec les applications d un MOM (Middleware Oriented Messages) pour le transport des messages. Rappel : un ETL ne fait qu extraire et appliquer des transformations à des données. Il ne peut en aucun cas appliquer des règles de routage complexes. La confusion entre ETL et EAI vient du fait que ces 2 outils peuvent répondre à des besoins d échanges de données. D autre part, les EAI sont capables d intégrer des processus métier : Business Process Management (BPM). Ce concept ajoute une couche d abstraction : l information manipulée n est plus une donnée ou un flux vers une autre application mais véritablement un processus métier. ETL versus EAI Les outils d ETL proviennent historiquement du monde de la base de données ; ils proposent d ailleurs en standard une multitude de connecteurs standard et natifs aux principales bases du marché. Les outils d EAI proviennent plutôt du monde du «messaging» et sont composés généralement de plusieurs couches, allant du simple paquet de messages à des niveaux d abstraction beaucoup plus importants pouvant inclure les process fonction

Résumé ETL EAI Avantages : Avantages : Faire communiquer des systèmes hétérogènes, Prendre en charge des traitements complexes, Paralléliser des traitements et répartir les flux, Volumes importants de données, Requêtes ensemblistes, Gestion évoluée des métadonnées, Nombreux types de stockage de données (SGBDR, OLTP, ERP, OLAP, etc.), Nombreux types d accès aux données (ODBC, JDBC, API, etc.), Robustesse de la solution, Alimentation bidirectionnelle, Réutilisation et évolution des développements (ROI). Inconvénients : Inconvénients : Alimentation désynchronisée (batch), Nécessite de bonnes compétences techniques, Mauvais routeurs, Intervention du Service Informatique. Faire communiquer des applications hétérogènes, Souplesse, réutilisation et évolution, Cycles courts de mise à disposition de l information, Alimentation en temps réel, ou quasi temps réel, d applications depuis d autres application ou systèmes opérationnels (ERP, CRM, etc.), Intégration des applications via des API ou des connecteurs dédiés, Routage intelligent (synchrone & asynchrone), Alimentation bidirectionnelle, Fin de la communication point à point, Peu d intervention du Service Informatique. Volumes restreints de données, Transformations peu complexes, Bonnes connaissances de l outil (connaître les limites d utilisation). Remarques importantes : Les exigences techniques liées aux applications définiront le choix Les environnements sont aujourd hui complémentaires Les ETL sont de plus en plus des clients EAI Les outils d EAI n offrent pas de solution globale packagée. Ils sont généralement constitués de trois grandes briques fonctionnelles d abstraction de plus en plus élevée à savoir : o La couche basse, de type middleware (MOM) o La couche intermédiaire de routage des messages o La couche supérieure intégrant les métiers de l entreprise. Architecture En règle générale, un outil d ETL est composé de : Un ou plusieurs «moteurs de transformation» qui vont traiter l ensemble des données à transférer et se connecter aux sources et cibles ; le transport s appuyant sur des connexions natives sources et cibles

Un référentiel où est stocké l ensemble des métadonnées (description des sources et cibles, transformations, schedules, logs, sécurité) Un ou plusieurs postes clients pouvant servir : o A la conception des flux o A l administration de l outil o A l exploitation et au suivi des flux Figure 1 : Architecture classique d'un SI

Figure 2 : Implémentation classique des ETL et des EAI Pour un DataWareHouse Figure 3 : Architecture de type moteur

Remarque : Les moteurs de transformation Certains outils d ETL n ont pas de moteur de transformation et s appuient sur les systèmes sources ou cibles Impact sur l activité & la disponibilité des systèmes concernés Les ETL se divisent en 2 groupes : o Générateurs de code : ils génèrent un code standard, natif et adapté selon la plateforme concernée (Cobol, ProC, etc.). Le code doit donc être compilé avant d être exécuté o Interpréteurs : ils génèrent un code propriétaire qui est directement interprété (pas de compilation) et exécuté par un «runtime» Les moteurs de transformation peuvent être répartis sur plusieurs machines Certains outils proposent du tuning de leur propre moteur pour l amélioration des performances Les plateformes d accueil peuvent être de type UNIX ou NT (voire mainframe ou As400 pour quelques-uns comme AB Initio, Sunopsis) Les connections aux sources et cibles Les connections entre sources, moteur et cibles se font par transport de type natif ou ODBC, JDBC. Le référentiel Il peut être déposé sur la plupart des bases de données du marché Certains ETL ont un référentiel propriétaire et parfois non mutualisé : dédié au moteur, dédié à la gestion des métadonnées, etc. D autres, au contraire, disposent d un référentiel commun pour toutes les briques logicielles qui composent leur offre. Le scheduler La plupart des outils d ETL proposent un scheduler intégré mais laissent la possibilité d utiliser l ordonnanceur du client Les événements déclencheurs d un traitement sont multiples : o Détection de la présence ou de l arrivée d un ou plusieurs fichiers o Action externe o Arrivée d un mail o Déclenchement programmé o Etc. La gestion des rejets La plupart des ETL proposent des fonctionnalités avancées pour traiter les rejets : stockage dans un fichier plat (en mode replace ou append) ou dans une table. Les postes clients Les plateformes d accueil sont généralement sous NT/2000 Attention : tous les outils d alimentation n offrent pas de possibilités de développement partagé (multi-user) car pas de versionning, de verrou, etc.

Questionnaire opérationnel Les tableaux suivants visent à réunir les critères essentiels devant être validés avant la mise en place d un outil de transfert de données (ETL). Ces tableaux constituent les bases d un cahier des charges et permettent de comparer, de manière objective, les différents produits du marché. Certaines caractéristiques utilisées dans des contextes peu courants ne seront pas présentées dans ce guide. De même, d autres critères peuvent apparaître nécessaires en fonction de besoins spécifiques liés au projet ou à l entreprise. Enfin, en toute logique, la pertinence et la pondération respectives de chacun de ces critères varient systématiquement selon les paramètres de métier, de besoins et d environnement. Il est indispensable de considérer de manière spécifique, les aspects volumétrie et délais (combien de données à transférer, en combien de temps). Ceci a une influence certaine sur l architecture à mettre en place.

Contexte projet Contexte fonctionnel Environnement Technique Serveurs (OS) Pré-requis techniques? Nombre de sources Nombre de destinations Possibilité de jointure hétérogène? (plusieurs instances de base, base/fichier plat) Type de sources (ERP, Progiciels, applications spécifiques) Bases de données et origines (SGBDR, Fichiers, XML ) Volumétries estimées des bases LAN/WAN? Volumétries estimées à transférer par traitement Temps maximum de traitement Les serveurs impliqués dans le projet sont-ils surchargés? (Il conviendra de privilégier des solutions impactant le moins possible les serveurs). Environnement Fonctionnel Degrés de complexité des sources (Cf. nombre de tables) Degrés de fiabilité et de qualité des sources (une bonne part des traitements est induite par des données ne répondant pas aux règles de gestion)

Architecture générale Composants du produit et mode d administration de ses composants (C/S, Web) Moteur, Planificateur, sécurité, logs... Architecture logique du produit Différentes interfaces / différents modules en client/serveur? Différentes interfaces / différents modules en client Web? Facilité d utilisation Durée moyenne de prise en main Aide en ligne Assistants de prise en main Peut-on poser des annotations liées à des traitements, des règles de calcul ou de gestion? Existence d assistants pour les opérations les plus courantes (Cf. Office) Conception graphique? Documentation Manuel d autoformation La documentation livrée couvre-t-elle l ensemble des opérations? Documentation papier ou électronique 1 2 3 Pertinence

Plateformes et connectivités supportées Portage sur plusieurs plates-formes ou OS (NT, W2000, AIX, HP-UX, LINUX ) 1 2 3 Pertinence Pour chaque configuration supportée : Configuration matérielle recommandée (développement & productions, serveurs & poste de travail) Logiciels requis et numéro de version OS Pré-requis sur les systèmes cibles et sources (Connectivité, Mise à jour de machine Java.) Pré-requis sur la machine supportant le moteur ETL (Services pack, Web, ) Nécessité d Add-On / Add-in? (MDAC, MMC, JRE, etc.) Accès aux données Bases relationnelles, multidimensionnelles Oracle, DB2, SQL Server, Teradata Mode d accès natif ou ODBC? via les Bulk Loader? Support ODBC, OLEDB Moteurs OLAP Hyperion Essbase Oracle Express Microsoft Analysis SAPBW Mainframes Fichiers cobols, Cobols Copybooks VSAM IMS DL/1 Fichiers Fichiers plats (txt, spool, CSV (DOS et Unix),..), avec séparateurs ou fixes Fichiers Excel, Word Structures complexes multi-lignes (de type EDI) XML (en lecture, en écriture)

Applications spécifiques Applications développées en C, VB, etc. EAI (MQSERIES, TIBCO, MSMQ) Disponibilité de ces modes d accès selon les plateformes? Les accès sont-ils bidirectionnels?

Complexité, montées en charge & dimensionnement 1 La charge de traitement est-elle supportée par le moteur ETL ou par les bases de données source et destination? 2 3 Pertinence Volumétrie acceptable Répartition de charges sur plusieurs moteurs (équilibrage de charges), mécanisme et limites Le moteur supporte-t-il le parallélisme des bases de données? En natif? Le moteur de l ETL est-il capable de paralléliser un même flux sur N processeurs et quels en sont les mécanismes? Mode de synchronisation des processus? Plateformes supportées (SMP, MPP, Cluster) Fonctions de transformation et de programmation 1 Gestion des process de transformations, ouverture et flexibilité 2 3 Pertinence Un process de transformation génère-t-il du code? Langage (Basic, VB, ) Y a-t-il une phase de compilation? Le code est-il accessible et non modifiable? Le code est-il accessible et modifiable? Peut-on simuler un process? Mode de débogage Mode pas à pas (points d arrêts) Code SQL Le code généré pour l accès aux données est-il accessible? Modifiable? Optimisable? Peut-on y inclure des spécificités liées aux bases de données? (Cf. les

Connect by ou Decode des SGBDR Oracle, les Case ou top de SQL Server) Modification du SQL généré pour optimisation des performances Portabilité si les systèmes changent Données multi sources Comment est géré le mixage de sources hétérogènes en entrée? (Cf. comment mixer des données DB2 et oracle dans un flux unique en entrée) Quelles en sont les limitations? Fonctions de transformations Nombre de fonctions de transformation disponibles Possibilité de définir des fonctions personnalisées (et réutilisation de ces fonctions) Définition au niveau du moteur (DLL, VB, ) Définition sur les bases de données cibles ou sources (référencement de fonctions UDF stockées en base de données) Transformations complexes, tâches, systèmes Existe-t-il en standard des transformations complexes appliquées au niveau du moteur? Appel de transformations internes (Pivots, Agrégations, Fusions, Tris) Appel de tâches diverses (FTP, MAIL, etc.) Peut-on ajouter des transformations ou des tâches spécifiques? Dans quel langage? Possibilités de lancer des routines externes (SQL, de type OS, des programmes spécifiques, etc.) avant et/ou après transformation?

Données Alimentation Modes de chargement disponibles (Ajout, Annule et remplace, etc. ) Gestion de tables de lookup en mémoire 1 2 3 Pertinence Visualisation Peut-on visualiser les données sources et cibles en étant dans l outil? Peut-on visualiser, simuler le résultat de transformations lors de la création de process? Qualité Support de nettoyage de données et capacité de recyclage des données en anomalies (envoi vers des fichiers tampon ) Format de sortie des rapports d erreurs?

Gestion de référentiel et Documentation associée Collecte et préparation des données 1 Les référentiels Où sont stockées les métadonnées (fichiers, SGBDR) Quels sont les SGBDR supportés pour contenir le référentiel? (Versions?) Peut-on accéder aux données en outrepassant le référentiel? Peut-on importer des référentiels existants? (Erwin, Power Amc,.) Peut-on historiser les chargements, les mises à jours et les changements? (versionning) Peut-on retrouver le processus de calcul d une donnée? Comment et quand a été calculée une donnée? Indépendance des métadonnées visà-vis de l environnement. (Cf. changement de bases lors du passage de l environnement de développement à l environnement de production) Implication d un changement dans une donnée source ou destination Implication d un changement dans les outils externes (outils de modélisation et outils de reporting) Mise à disposition de l information Possibilité de fournir une documentation et des commentaires relatifs au référentiel Personnalisation de cette documentation en fonction de différents profils (développeur, administrateur, utilisateurs) Génération de documentation Web (HTML) Génération de documentation relative au flux : transformations, enchaînements,...? Sous quelle forme? 1 2 2 3 3 Pertinence Pertinence

Exploitation Mise en production et Suivi de l exploitation Possibilité d utiliser un planificateur externe 1 2 3 Pertinence Capacité à planifier sur événement Arrivée d un fichier nommé, non nommé? modification, suppression... Quel type d événement? Surveillance d un répertoire? Déclencheur externe Mode de récupération après erreur Peut-on gérer de manière fine les commit sur les bases de données et de quelle façon? Quelles sont les possibilités de ROLLBACK offertes par le produit? Mode trace ou debug sur les chaînes d exploitation Fonctions de surveillance des traitements Gestion centralisée de plusieurs moteurs (Log, ) Modalités de mise en place d un traitement unitaire d un environnement de développement sur un ou plusieurs environnements de production Sécurité et confidentialité Identification des utilisateurs (login) 1 2 3 Pertinence Mode d identification (annuaire LDAP, base de données), unicité des mots de passes (réseau) Paramétrage des droits (production, développement, référentiel, procédures stockées ) Séparation des environnements développements et production