Paramétrages des bases de données à l'éxécution pour Talend et Pentaho

[Scorpio85]

Bonjour,

Je réalise actuellement un comparatif entre Talend et Pentaho et je voulais avoir quelques précisions.
Je dois réaliser un Datamart pour un client dont je ne connais pas le type de DB (MySQL, Oracle ...) , l'url de la DB ... car le produit qu'on lui livre est paramétrable et multibase. Je veux donc savoir comment peut se gérer ce problème sous Talend et Pentaho.
Sous Pentaho j'ai l'impression que c'est assez simple et qu'il suffit juste de remplacer les bonnes valeurs dans les balises correspondant à la connexion. ça peut être un programme qui demandera aux clients les paramètres et les complétera dans le fichier au format XML. Pensez-vous que ce soit une bonne idée ?
Pour Talend je ne vois pas d'autres solutions que de modifier le code généré ce qui m'a l'air plus couteux et compliqu".
Pensez-vous qu'il y ait une solution plus simple pour ce cas ?

J'espère avoir été le plus clair possible et vous pourrez m'aider.
Merci d'avance pour vos réponses.

[Benoit_Durand]

Pour talend le plus simple doit être de mettre tous tes donnes de connexion dans un fichier de conf. Et au début de tes jobs maitre tu lis ces fichiers de conf et chage ces paramètres dans des variables de contexte que tu transmets ensuites a tes jobs fils.

Il y a d'autres méthode en stockant les données dans une table de paramétrages....

[Scorpio85]

Merci pour ta réponse.
Mais comment tu lirais les données de ton fichier de conf grâce à un tJava ?
Je n'ai pas trop compris ce que tu veux dire par tables de paramétrages ?

Sinon personne n'a une idée pour Pentaho Kettle ?

[Benoit_Durand]

Tu lis le fichier avec un tDelimitedFileInput ave ":" pour separator
le fichier doit être sous la forme :

server : 172.92.80.23
port : 1569
...

Tu envois le contenu de ce fichier directement dans un tContextLoad

Pour la table de paramétrage en bd c'est strictement la même chose sauf que tu mets les données dans une table au lieu d'un fichier.

[MattCasters]

Sous Pentaho j'ai l'impression que c'est assez simple et qu'il suffit juste de remplacer les bonnes valeurs dans les balises correspondant à la connexion. ça peut être un programme qui demandera aux clients les paramètres et les complétera dans le fichier au format XML. Pensez-vous que ce soit une bonne idée ?

Mieux c'est de créer des boucles dans un job. (samples/jobs/run_all/)
Comme ça on peut utiliser des variables, crées dans un job.
Les connections seront complètement dynamique.

Matt

[smallet]

J'avais fait un petit post expliquant comment charger les contexts depuis un fichier dans Talend.
http://stefeclipse.free.fr/blog/?p=21

Par contre, tu dois déjà savoir quelle type de base de données tu vas utiliser car les composants sont par exemple tMysqlInput, tOracleInput, etc...
De toute façon, les requêtes d'entrée ne sont pas forcement identiques d'une base à l'autre.

De manière générale je déconseille de modifier le code généré par Talend. Pour la bonne raison que comme il n'a pas de reverse, ce n'est vraiment idéal en terme de maintenance.

[Scorpio85]

Merci pour vos explications, à moi maintenant de tester tout ça.
Je vous tiendrais au courant.

[Scorpio85]

Envoyé par smallet

Par contre, tu dois déjà savoir quelle type de base de données tu vas utiliser car les composants sont par exemple tMysqlInput, tOracleInput, etc...
De toute façon, les requêtes d'entrée ne sont pas forcement identiques d'une base à l'autre.

Mais si j'utilise des tJDBCInput , est-ce-que je règle le problème que tu soulèves ?

[smallet]

Le JDBCInput n'est pas l'idéal. Pour plusieurs raisons :
-perf
-syntaxe un peu différentes d'un bd à l'autre (exemple : limit en mysql, where numrows>? en oracle)
-les types ne sont pas les mêmes (ce qui te privent des fonctionnalités de création de tables dans les composants d'output)

Ce que tu peux faire avec Talend c'est aussi utiliser les joblets.
C'est un moyen de factoriser les traitements dans plusieurs jobs. Par exemple tu factorise le traitement et chaque job récupère les données à ca façon (mysql , oracle ou autre) et les envois à la joblet.

N'hésite pas si je ne suis pas très clair.

[Scorpio85]

Envoyé par smallet

N'hésite pas si je ne suis pas très clair.

Merci

En gros ce que tu me dis c'est que le mieux c'est de connaitre quel type de connexion je vais utiliser et que le tJDBCInput/Output me limite dans la création de table.
C'est un problème car en fonction du client je ne sais pas si celui utilise Oracle, MSSql ou autre.

Avec la factorisation dont tu parles, tu veux dire que je dois prévoire tout les cas de base de données possibles ?

[Scorpio85]

En gros avec ce que vous me dites j'ai l'impression que je ne peux pas avoir un code multibase avec talend. Et que donc il me faut savoir forcément le type de la base.
Est-ce la même chose avec Pentaho ?

[Scorpio85]

Encore une question
Je vois qu'avec Kettle on peut aussi utiliser le "generic database". Ai-je les même problèmes que vous citez avec Talend avec le tJDBC ou bien est-ce meilleur ?
Merci de vos réponses.

[Benoit_Durand]

Envoyé par Scorpio85

En gros avec ce que vous me dites j'ai l'impression que je ne peux pas avoir un code multibase avec talend. Et que donc il me faut savoir forcément le type de la base.
Est-ce la même chose avec Pentaho ?

Il doit y avoir un moyen d'y arriver en utilisant les composants DB Generic et DB JDBC de Talend et en ne faisant que du sql générque accepté par tous les SGBD (ce qui ne va pas loin) de plus les fonctionalités de ces composants sont limitées.

Je ne connais pas Kettle

[Scorpio85]

Merci pour ta réponse.
Pour avoir essayer le composant générique que propose Pentaho , c'est vrai que l'on se retrouve aussi vite limiter avec les scripts SQL. Il faut donc trouver une parade.

[MattCasters]

C'est a dire, quand on utilise ANSI SQL, on aura typiquements pas des problèmes dans Kettle.

[Scorpio85]

Merci pour la précision