Par exemple le composant tGoogleMapLookup qui valide des adresses via Google Map … Sympa, il fallait y penser.

Il y a aussi le composant Talend qui va créer des événements dans un agenda Google.

Ca change des ETL fermés où chacun va développer / bricoler de son côté.

Disponible chez Perget ou Talend

/* exemple **
with operations
as (  
select 1 idclient, sysdate dat, 4 val from dual union all
select 1 idclient, sysdate+1 dat, 8 val from dual union all
select 1 idclient, sysdate+2 dat, 7 val from dual union all
select 2 idclient, sysdate dat, 2 val from dual ) */
select idclient, max(dat) from operations group by idclient

Par contre si on veut récupérer d’autres informations de cet enregistrement, il faut passer par une sous-requête :

select idclient,  dat,  val
from operations a
where a.dat=(select max(b.dat) from operations b where b.idclient=a.idclient )

Le problème est ( entre autres ) qu’on passe 2 fois sur la table operations, ce qui dégrade les performances.

Oracle propose depuis la 9i les fonctions analytiques, ce qui est bien pratique pour gérer ce type de problème.
On utilisera par exemple la fonction row_number(), mais on aura toujours une sous-requête :

select idclient, dat, val from (
  select idclient, dat, val,
    row_number() over(partition by idclient order by dat desc) num
  from operations
)
where num=1

Cette solution n’est pas forcément simple à implémenter du fait de la sous-requête. Un ETL comme Sunopsis/ODI ne gère pas les sous-requêtes, il faut passer par des vues et du coup on perdra le lien dans l’analyse d’impact de l’outil.
Solution miracle, on a une requête en one-shot avec la clause keep :

select idclient,
  max(dat),
  max(val) keep (dense_rank last  order by dat) val
from operations
group by idclient

Cerise sur le gâteau, on peut aussi utiliser ce type de clause dans un univers Business Objects, cela évite de passer par une table dérivée ou du sql en dur.

Que du bonheur.

Les + :

• les performances ( mode ELT )
• les KM ( modules de connaissance ) qui définissent les process « standard » ETL comme la détection des doublons, des valeurs inconnues de tables de référence ( écartés dans une table d’erreur ),
  l’alimentation des tables ( en Insert pur, Insert en delta, en SCD … )
• pas besoin de connaitre un nouveau langage, le SQL du SGBD suffit généralement !
• debugage facile
• reprise d’un plantage à partir d’un certain point ( où ça s’est planté, ou depuis le début, ou 3 sql avant … )
• optimisation orientée SGBD donc facile ( un expert ETL n’est pas nécessaire, un DBA suffit )
• l’analyse d’impact très fine
• l’éditeur de requête sql qui permet de construire des requêtes assez complexes
• les contextes qui facilitent le déploiement d’un environnement à un autre
• la séparation modèle physique / modèle logique

Les – :

• traitements unitaires basiques ( plusieurs tables constituent une requête qui alimente une seule table ) : il faut généralement utiliser des tables temporaires, le flux de la donnée n’est pas visible en un seul job.
• nécessité de connaitre les SGBD … et des fonctions complexes dans certains cas
  comme pour les comparaisons relatives entre lignes,
  par ex pour comparer un statut par rapport au statut précédent
  –> fonctions analytiques oracle
• la perte des dépendances pour l’analyse d’impact sur certains traitements
• la prise en main – il faut bien décomposer ses traitements

L’éditeur de requête SQL permet d’élaborer des requêtes complexes tout en gardant les références aux objets. Ainsi il n’y a pas besoin de coder les clauses « where », « group by » ou « having » comme dans les autres ETL, et l’analyse d’impact se fait à la colonne …

Quelques astuces :

• simuler un MINUS – je vais faire un tuto dessus bientôt …

En conclusion :
Pour moi Sunopsis/ODI fait partie des meilleurs ETL du marché, il se démarque de ses concurrents principalement par ses performances et par l’intégration des process habituels d’alimentation dans l’outil.

La version max que je connais est la 7.5.2

Un exemple de job :

( Alimentation d’une table Oracle à partir d’une autre table Oracle en effectuant une jointure avec un fichier texte en référence )

Les + :

• graphiquement attractif – de jolis dessins en 3d
• on voit le cheminement/flux de la donnée ( sources/cibles, les différents traitements : tri, agrégation )
• pas besoin de connaitre le SGBD ( fonctions sql, procédures )
• les fichiers hash pour dédoublonner en ne gardant que le dernier enregistrement
• les variables dans les transformer pour comparer avec les valeurs de la ligne précédente

Les – :

• boîte noire – on ne sait pas trop comment il fonctionne
• un nouveau langage à apprendre même s’il est estampillé basic …
• les performances sont vite dégradées sur de grosses volumétries, car il fonctionne en mode curseur ( ligne par ligne )
• analyse d’impact peu poussée
• limites du basic

Le plus gros point faible pour moi concerne les performances. En effet on est vite amenés à tout coder en sql notamment pour les tris, les agrégations et les jointures. On se retrouve alors avec des jobs assez simples ( 3 stages : une source avec un sql complexe, un mapping et une cible )
Pour l’analyse d’impact, le lien avec les métadonnées est perdu lors du développement. Par exemple, on importe la structure d’une table T dans le référentiel, on crée un job et en source on prend la table T dont on importe la structure depuis le référentiel. Mais il n’y a pas de lien entre le job et la métadonnée dans le référentiel, si on change la structure de T dans les métadonnées il n’y a pas d’alerte sur le job qu’on a créé !!!
L’analyse d’impact se fait alors principalement par mot clé, ce qui pose problème avec des mots clés bateau qu’on retrouve partout !!!
Pour le basic, d’accord on est indépendant du SGBD mais on a un nouveau langage avec toutes ses subtilités.
Par exemple, pour extraire une chaine :
toto[4]  = les 4 derniers caractère du champ toto

pour avoir la date système au format DD/MM/YYYY HH24:MI:SS d’Oracle :
OCONV(Date(),"D-YMD[4,2,2]"):" ":Oconv(time(), "MTS")

D’autre part, certaines fonctions/opérateurs très pratiques ne sont pas écrites comme le NVL, BETWEEN, IN …
C’est dommage, car certains aspects du BASIC Datastage sont séduisants, comme l’utilisation indifférente des  » ou des ‘ pour définir une chaîne de caractères
( on peut écrire "toto", 'toto', "aujourd'hui" ou 'des "guillemets"' )

Pbs courants :

• obligation de trier les colonnes dans un stage Aggregate … sinon plantage …
• pbs de mémoire lorsqu’on utilise le stage de tri …
  –> on trie et on somme en sql
• le fichier hash dédoublonne sans prévenir …
  –> alertes non remontées
  Par exemple, on récupère les noms à partir d’un login, mais on a une évolution en source qui fait qu’on peut avoir différents noms pour 1 login
  En utilisant le fichier hash, on récupère un des noms … mais pas forcément le bon … et ce n’est pas remonté …
  En récupérant le nom via une requête, on aurait des doublons en entrée –> plantage
  Il faut donc toujours mettre une contrainte d’unicité en base sur les clés des fichiers hash pour éviter ce pb.
• pas de remontée/warning des lignes non mises à jour
  ex : un job traite une volumétrie de 100 000 lignes, mais aucune ligne n’est mise à jour
  –> il n’y a aucune remontée, le job semble avoir maj les 100 000 lignes
• pb ETL : il faut être vigilant qu’on fonctionne en mode curseur
  –> si on a un traitement qui met à jour les dossiers, et en entrée 10 fois le même dossier, on aura 10 mises à jour de la même ligne, sans remontée d’alerte !!!

Pbs énervants :

• renommage colonne en amont –> il faut tout changer en aval
• les messages d’erreur laconiques ( pb des phantom … ), où on passe des heures à débuguer ligne par ligne pour trouver ce qui ne va vraiment pas !
  –> notamment sur les routines, quand on a du null en argument …

Quelques conseils :

• résister à l’envie d’écrire un seul « gros » job qui fait tout ( même si c’est possible ). Il vaut mieux écrire des jobs « basiques », avec le minimum de stages – c’est plus simple à maintenir et à tester
• éviter les stages tri et agrégat, ils amènenent souvent leurs lots d’erreurs incompréhensibles
• les stages folder et rowsplitter donnent envie quand on a plusieurs fichiers à traiter, mais ils ne sont vraiement pas pratiques à débuguer – pensez à votre prochain, rester aux stages simples de fichier …

En conclusion :
Au début on trouve l’application géniale, c’est quand même plus sympa que les tristounets scripts sql lancés en batch… Et on déchante assez vite devant les performances et les problèmes rencontrés … Du coup on simplifie les jobs au maximum et on met tous les traitements dans les sql … en se demandant si on n’écrirait pas à la place des scripts sql qui seraient plus performants !!!

Pour moi Datastage fait partie des « anciennes » générations d’ETL qui n’ont pas vraiment su se renouveler.
La montée en version n’a pas apporté grand chose, à part un lifting graphique réussi.
La version 8 ne me semble pas plus innovatrice, IBM répondant au problème de performance avec du parralélisme … De plus l’offre devient plus floue, avec 2 versions de Datastage ( PX et Server ) dont celle correspondant à l’ancienne qui n’évolue plus !!!

Je lui préfère SunopsiS/ODI ou Talend pour les raisons que j’expliquerais plus tard dans un autre article ..

L’enquête Gartner incendie pour une fois les grands éditeurs comme SAP/BO, Oracle ou IBM sur les problèmes remontés par les utilisateurs …
Certes, on pourra critiquer ces résultats en supposant que le nombre de problèmes est aussi fonction du nombre d’utilisateurs – et comme peu de monde dans l’entreprise utilisent les produits gagnants de l’enquête – qui utilise Tableau Software ?
Mais c’est une avancée …

Les jobs simples ( 1 source, 1 cible et 1 transformer entre 2 ) sont bien convertis, mais les jobs plus complexes nécessitent certaines modifications …
Je n’ai ni le temps, ni la place pour exposer tout ça ici, mais je planche là-dessus pour donner plus de détails + tard !