Requête sql sur kettle

[fatima ezzahra]

Bonjour !!
je veux executer une requete sql avec kettle, j'ai choisi l'etape "executer script sql" mais ça marche pas, ma table est tjrs vide, y a kelk'un qui peut m'aider ?
Merci

[MattCasters]

Bonjour Fatima,

Peut-êtra vous avez oublié d'ajouter de l'input pour l'étappe "executer script sql"? (Row Generator)

Bonne chance,

Matt

[fatima ezzahra]

salut!

le problème est que je ne sais pas comment insérer le resultat dans une table tu vois?
quand je visualise le resultat au niveau de l'etape sql-query ça marche, mais quand j'edite l'etape "executer script sql" je ne trouve pas d'emplacement pour lui montrer la table cible où le resultat doit être stocké.

[MattCasters]

Salut Fatimma,

évidemment je vois pas.
Sans examples, images ou logs je peut faire rien de plus pour vous.

Bonne journée,
Matt

[said.bolba]

bjr,
tu clik sur l'etape insertion dans une table et tu vas trouver tout en bas un bouton "sql" tu clik la dessus pour éxecuter le script SQL ki vas te permettre d'inserer les données dans la table.
cordialment.

[taoufiqENSIAS]

ou bien quand tu va faire extraire depuis table dans le cadre tu met directement ta requête que tu veux exécuter
et après insérer dans une table ou la table contient exactement les même champs de résultats de la requête dans le même ordre
et je pense ça marche

[remy77]

Moi aussi j'utilise le composant "Exécution Script SQL" qui contient un SELECT et je n'arrive pas à envoyer le résultat vers une table, j'ai essayé "Selection de valeurs" puis "Inserer dans table" mais cela donne des messages d'erreurs sur toute la chaîne.

Mon objectif était de créer une table temporaire (TMP_DOSSIER) puis de faire un select à partir de ce résultat donc j'ai ajouté le composant "Bloquage de lignes" et ensuite le script SQL car malheureusement je n'ai pas réussi à faire marcher le composant "Extraction depuis Table" après le bloquage de lignes !

Ci-joint une copie d'écran de mon traitement Kettle actuel où j'ai désactiver les flux après le script SQL.

Avez-vous une idée de quoi faire après le "Exécution Script SQL" ?
Merci !!!

[samatar]

Bonjour,
l'étape ''exécution de script SQL'' ne renvoi pas de lignes !
Elle permet l'exécution de requêtes DDL (DELETE, UPDATE, ...).
Pour extraire des lignes, il faut utiliser l'étape 'Extraction depuis table'.

[remy77]

Bon ben c'est bon à savoir ! Je repars sur le composant "Extraction depuis Table" après mon bloquage de lignes puis j'enchainerai sur la selection de valeurs (mapping) et l'insertion en table...

Je vous tiens au courant si tout fonctionne !

[samatar]

Ou tu peux utiliser une étape de recherche (jointure, recherche).

Samatar

[remy77]

Savez-vous comment on peut gérer un "Extraction depuis table" après un "Bloquage de lignes" ? Aucune ligne ne passe de l'une à l'autre.

Cf copie d'écran ci-joint dans Kettle.
Pensez-vous que mon schéma est correct ?

Merci pour votre aide !

[remy77]

Cf la copie d'écran du post précédent.

Je souhaiterai ne récupérer que les lignes d'une table n'ayant pas de correspondance dans mes tables d'axes afin d'une part de pouvoir les mettre en rejet dans un fichier et d'autre part pouvoir les éliminer du flux avant leur insertion dans la table de fait finale. Ceci afin de pallier au problème de contraintes d'intégrité sur les FK entre table de fait et table d'axe.

Pour cela, je pensais :

- remplir une table temporaire T1 avec toutes les données nécessaires
- bloquer les lignes
- faire un select sur cette table temporaire T1 (avec un left join sur les tables d'axes) pour ne récuperer que les lignes n'ayant pas d'enregistrement dans mes tables d'axes
- les mettre dans un fichier et dans une autre table temporaire T2
- bloquer les lignes
- supprimer de la table T1 les lignes correspondant à T2 pour ne garder que les lignes OK
- inserer les lignes de la table T2 dans ma table de fait

Bon je n'en suis qu'à l'étape 3 (après le blocage des lignes) et c'est vrai que je tatonne pas mal avec Kettle alors qu'en requête PL/SQL je sais écrire tout ça d'un bloc !

Si vous pouviez me dire si je suis dans le vrai, ça m'aiderai bien !
Merci...

[samatar]

L'étape blocage ligne "boque" le flux jusqu'a réception de la dernière ligne qu'elle transmet à l'étape suivante.
Si cette étape ne transmet rien, ce qu'elle ne reçoit rien

Moi je te conseille d'utiliser une étape de recherche puis un filtrage pour différencier les lignes (cex ayanr un enregistrements, des autres).

Extraction --> recherche --> filtrage ...

Au niveau des étapes de recherche, tu as du choix:

- recherche dans BDd, recherche dans flux ou encore jointure de lignes (qui permet de spécifier librement ton SQL)

[remy77]

merci pour ces conseils ! par contre, mon blocage de lignes affiche bien des lignes lues et ecrites par contre à l'étape avant elles sont toutes en "Sorties" est-ce normal ? Ci-joint copie d'écran si tu pouvais regarder dans la trace...
qu'en penses-tu ?

[remy77]

En fait ma question est "Comment ne démarrer une étape que lorsque la précédente est terminée ?" c'est pour cela que j'ai utilisé "Blocage des lignes" car je ne peux pas faire de Select sur une table temporaire tant que celle-ci n'a pas été alimentée ! Pourant j'ai l'impression que mon étape d'extraction se termine avant même que celle précédent le blocage de lignes le soit, est-ce normal ? J'obtiens toujours 0 lignes en extraction...

NB : J'ai aussi essayé le composant "Prioirser les flux" sans succès !

[samatar]

Normal car dans une transformation tout se lance en parallèle
Dans ton cas, ton SELECT de la la temp va lancer dès le lancement de la transformation.
Comme la table est vide au démarrage..CQFD

[samatar]

Tu as 2 solutions.
Une propre et une moins propre

1- Utiliser une tâche :
START--> Trans1 (Extraction --> Insert temp) --> Trans 2 (Extraction table temp)

C'est la solution propre car elle permet l'isolation des transformations.

2- Forcer l'extraction depuis la table temp à attendre la fin du blocage de lignes. Tu conditionnes donc la lecture à la réception de la ligne depuis l'étape blocage :
SELECT .. FROM table_temp WHERE 1=? (une vérité quoi....)

Tu remplis ''insérer les données à partir de'' et tu sélectionne ''exécuter pour chaque ligne?''.

Tu ajoute un champ Un (valeur=1) dans ton flux et quand tu démarre,
le SELECT de la table temp attendra la ligne depuis blocage car il a une condition (WHERE).

Voila

Samatar

[remy77]

Quelle bonne surprise ta réponse à mon retour !
Cela me conforte dans l'idée de faire 1 transformation par étape chronologique en fait, merci !!! Je vais faire la solution 1 car pour moi qui débute, c'est la plus facile ! Juste une dernière question : dans quel cas utliser le composant "Blocage de lignes" alors ? Dans mon cas, est-ce que je pourrais utiliser le composant "Création relation parent/enfant" pour aller plus vite ? J'ai beau lire la doc je ne trouve pas d'infos sur quels composants utiliser dans quel cas, si tu en connais je veux bien ! Il y a les demos de pentaho mais ça ne dit pas tout donc j'y vais à par essai successif.
En tout cas bravo pour tes solutions, on voit que tu maîtrises l'outil !!!
Tu fais pas de la prestation par hasard, ça pourrait m'intéresser ?!

[samatar]

J'utilise l'étape blocage lignes lorsque j'ai besoin de ne récupérer que la dernière ligne (exemple que je construit un flux en cancaténant des champs..la dernière ligne contiendra toutes les infos).
Exemple:
ligne 1 : nom1
ligne 2: nom1+nom2
ligne n: nom1+nom2+...+nomn

L'étape "locage lignes" laissera passer que la dernière ligne puisqu'elle contient toutes les infos.
Remarques que cette exemple peut être aisement réalisé par une étape 'agrégation lignes'

Il faut juste savoir ce que font les étapes et après l'utilisation est au cas par cas.
c'est vraiment la logique de PDI :
- chaque étape doit faire une fonction précise ,ainsi la maintenance, la prévisualisation sont grandement facilitées.

L'étape ''Création relation parent/enfant'' permet de construire les relations hiérarchiques (je suis le ched de X, X est le chec de Y,...)

Dans ton cas tu ne complique bcp.
On peut faire simple avec une seule transformation.
Si j'ai compris, l'idée de base est d'identifier les enregistrements n'ayant pas
d'enregistrements dans les tables d'axe.

Dans ce cas une simple étape de recherche nous dira si la ligne en cours a un enregistrement dans la table d'axes.

Un petit article simpa:

http://wiki.pentaho.com/display/COM/...tion+in+Kettle

Ta transformation va être ainsi.

Extraction depuis table --> recherche --> Filtrage

Si ta requête de recherche dans les tables d'axes utilisent plusieurs tables, utilise l'étape ''Jointure Base de données'' (Db Join en anglais) et n'oubli pas de sélectionner ''Jointure externe'' pour laisser passer toute les lignes (Outer Join) même celle qui n'ont pas de lignes retournées dans ta requête.

C'est tout.

Si une ligne a une valeur dans un champ retourné par ta requête de recherche, alors elle a un enregistrement dans les tables d'axe, si la valeur est null, elle n'a pas d'enregistrement dans les tables d'axe.

Une solution encore plus simple et l'insertion directe dans la table cible.
Comme tu t'attends à avoir des erreurs (enregistrements nob présents dans les tables d'axe), tu active la gestion d'erreur sur l'étape d'insertion (http://www.ibridge.be/?p=32).

Voila

Prends soin de toi.

Samatar

[remy77]

Tout ça a l'air merveilleux effectivement donc je serai tentée d'opter pour la dernière solution de Matt par contrej'ai pas l'impression qu'il ya ait de gestion d'erreur quand on passe de l'étape "Extraction depuis table" (où il y a tout) à mon étape "Insertion dans table de fait" (avec la foreign key et les constraintes d'integrités). As-tu la solution miracle ?

Ton idée de composant "Jointure base de données" est peut-être bien mais là je ne vois pas non plus comment la mettre en oeuvre ! Trop compliqué...

Je dois mettre la condition "left join" + "champ is null" avec les axes pour récupérer mes lignes en erreur dans un fichier et les supprimer ensuite de mon flux, vois-tu ?

Pourtant en effet, je pense que ça doit être une problématique fréquente de vouloir contrôler à l'insertion de sa table de fait les enregistrements par rapport aux axes mais bon...pas évident de trouver la solution à la sauce "Kettle" !!!