Feeds:
Articles
Commentaires

Pentaho Data integration

Depuis quelques jours, j’ai commencé à lire un livre consacré à l’ETL Pentaho Data Integration. Ce livre écrit par Maria Carina Roldan (twitter, blog) s’intitule « Pentaho 3.2 Data Integration : Beginner’s Guide » (amazon, Packt) et est consacré comme son titre l’indique à l’exploration des capacités de l’ETL open source Kettle.

En effet, c’est le livre à recommander pour tous les débutants car il couvre non seulement des sujets comme l’installation, la création de la première transformation avec l’extraction de données depuis un fichier texte ou Excel mais également les référentiels ou encore l’alimentation des entrepôts de données. D’autre part, ce livre bien qu’écrit dans la langue de Shakespear est vraiment accéssible car tout au long des 493 pages, il y a le soucis permanent d’expliquer les choses le plus simplement possible. Au bout de quelques pages, on fait donc abstraction de la langue🙂 C’est donc le livre à avoir près de son clavier en ce moment.  Son auteur est un consultant décisionnel et un membre actif de la communauté Kettle, vous pouvez consulter le tutorial écrit par ses soins ici . Notons également que ce livre est préfacé par l’excellent Matt Casters (blog, twitter) fondateur et architecte en chef  du projet Kettle.

A tous donc une bonne lecture.

Samatar

Kill Windows process

Comment peut-on « tuer » (ou plutôt terminer brusquement l’exécution) un processus sur un système Windows?

Cette problématique revient « me hanter » régulièrement car si cela est simple sur un système Gnu Linux, elle s’avère impossible dans Windows sans utilisation d’un composant externe. Il existe un outil sur Windows qui permet de Killer des processus : PsKill. Pour mettre fin à l’exécution d’un process, il suffit de connaitre son nom ou Identifiant (PID) et d’écrire en ligne de commande PsKill nom ou PID

Vraiment pratique car il permet également de tuer un processus sur une machine distante :

Utilisation : pskill [-] [-t]\\ordinateur[-u nom d’utilisateur] [-p mot de passe]] <[nom de processus | ID de processus>

 

Partant de ce constant, j’ai crée un composant dans l’ETL PDI. Ce composant permet de Killer un processus Windows (par le nom ou le PID) et est utilisable dans une tâche.

killprocess

 Voila si cela intéresse des personnes, n’hésitez pas🙂

Bonne Année à tous …

Samatar

PDI 3.1.0

Pentaho Data Integration 3.1.0 est disponible. 

Cette version introduit un grand nombre de nouveautés qui portent tant sur l’interface utilisateur que sur la couverture fonctionnelle.

Une très belle version qu’il faut à tout prix essayer pour ceux qui n’ont pas encore effectué le saut :

Samatar

Validation d’email

Lors des campagnes Marketing, il est primordial d’avoir une base d’adresses mail valides. Par validation, j’entends que l’adresse est correcte dans la structure (toto@tata.com par exemple) mais également qu’elle est défini et active sur un serveur.

Le premier niveau de contrôle (également le niveau le plus simple) c’est de valider la structure de l’adresse avec une expression régulière ou en utilisant la lib apache.commons-validator

EmailValidator emailValidator = EmailValidator.getInstance();
boolean valid=emailValidator.isValid(sEmail);

Ce premier niveau vous dira seulement si la structure de l’adresse est bonne (cela permettra de faire dèjà un premier tri), si vous souhaitez savoir si l’adresse est valide c’est un peu plus compliqué🙂

J’ai passé un peu de temps sur la recherche d’une solution (en Java) et une approche consiste à intérroger un serveur SMTP en lui envoyant un mail lui disant COUCOU je souhaiterais valider l’adresse suivante. Comment on s’y prend ? En ouvrant un socket vers le serveur SMTP :

1- on lui envoi un « ECHLO » + domain (extrait de l’adresse mail, @tata.com)

2- On valide l’envoyeur « MAIL FROM: <«  + senderAddress + « > »

3- On valide le destinataire « RCPT TO: <«  + address + « > »

4- Enfin, on quitte proprement « RSET » puis « QUIT »

Bien sur, à chaque niveau on teste le retour.

Pour le code java, c’est plutôt ici.

Le serveur SMTP que l’on interroge est soit renseigné par défaut soit « récupéré » depuis le domaine.

A partir de ces informations, j’ai créé une étape dans PDI. Voila à quoi ressemble le résultat:

A@

Samatar

J’ai personnellement eu besoin d’une solution de reporting lorsque j’ai mis en place des tâches PDI.

En effet, il est impératif de monitorer les tâches pour avoir un état de la situation (erreurs, durée d’exécution, nombre de lignes insérées dans les tables,…) et comme je manquais de temps, c’est tout naturellement que je me suis vers des solutions existantes pas trop compliquées à prendre en main🙂

L’idée c’est de créer rapidement des rapports basés sur les données enregistrées dans la table de trace par PDI.

C’est en cherchant sur le net que j’ai découvert la solution LogiXML. Bien plus qu’un outil de reporting, c’est une offre globale de business intelligence à un coût que je j’estime abordable. C’est qui m’impresionne c’est la rapidité et la simplicité avec laquelle on créé des rapports…vraiment déconcertant.

Aucune connaissance technique n’est requise, tout se fait pas sélection de briques (par exemple les labels, les textbox, les graphs,…)

J’ai ainsi élaboré mon site de supervision des tâches PDi (par exemple) et cela sur la version gratuite:-)

Ce n’est pas un outil open source mais je tenais à en parler car c’est sincèrement un très bon produit.

A@

Samatar

Export référentiel PDI

L’utilisation de référentiel dans Pentaho Data Integration (PDI) amène une grand flexibilité dans le développement de transformations et de tâches. Le travail partagé et la maintenance sont grandement facilités. Sauvegarder le référentiel revient à sauvegarder la base de données mais la restauration du référentiel sera complète. J’ai organisé mon référentiel par projet (1 projet dans 1 dossier).

Un dossier « contiendra » ainsi plusieurs transformations et tâches et c’est donc tout naturellement que j’ai recherché à réaliser une sauvegarde par dossier du référentiel. Cette sauvegarde consiste à exporter les transformations et tâches vers un fichier XML facilement restorable:-)

J’ai commencé à travailler sur une entrée tâche qui me simplifierait la vie. Voici le résultat :

Je suis en train de définir les divers options et voila à quoi va ressembler cette entrée tâche.

@+

Samatar

Il m’arrive d’intervenir sur le forum developpez.net et j’ai remarqué que la différence entre une transformation et une tâche dans PDI ne paraissait pas évidente pour les débutants. J’ai décidé donc de réaliser un petit papier sur cette question🙂

Pentaho Data Integration manipule 2 sorte de traitements :
–> les flux (streams en anglais) qui correspondent par exemple aux enregistrements dans une base de données, liste de fichiers,etc. Ces flux sont gérés dans une transformation.
Exemple d’une transformation classique:

Extraction depuis une BdD –> Filtrage –> Alimentation fichier Excel

Dans cet exemple, les lignes sont extraites d’une base de données grâce à l’étape « Extraction depuis table ». Cette étape est la source du flux. Dans la suite ces lignes seront manipulées pas une étape filtrage qui va ne va diriger vers l’étape « Alimentation fichier Excel » (étape cible du flux) que certaines lignes. Notons que dans mon exemple, une seule étape produit du flux.

Dans une transformation, toutes les étapes ne peuvent produirent de lignes, il existe des étapes dédiées à cela. Ceux sont les étapes dans la catégorie « Extraction ».

Si vous n’avez donc pas des étapes productrices de flux, votre transformation ne marchera pas (ou plutôt finira sans avoir commencé🙂 ).

Il y a souvent une question qui renvient sur le forum de PDI à propos de l’exécution de procédure stockée. Typiquement, vous pouvez avoir une procédure qui ne nécéssite pas d’arguments; la logique voudra donc que l’on puisse utiliser directement l’étape « Appel Procédure Stockée (BDD) ». Mais cela ne marchera pas car comme on l’a précisé plutôt cette étape ne produit pas de flux (elle le modifie). Elle a besoin qu’au moins une ligne arrive à elle! Il suffit donc de placer une étape « Génération Lignes » juste avant🙂

Notons que l’étape « Appel Procédure Stockée (BDD) pourra s’exécutée toute seule à partir de la version 3.1.

 Ainsi, pour manipuler les flux, on utilise des étapes liées entre elles grâce à des liens (en vert dans notre exemple).
Chaque étape est dédiée à une fonction (extraction, alimentation, recherche,…). Il y a les étapes qui produisent des flux (Extraction depuis BdD, fichier,…), d’autres qui les manipulent (Ajout constante, agrégation, tri,…) , etc.

Les lignes seront donc « baladées » d’une étape à une autre et chacune des étape appliquera au flux d’entrée une action de transformation (filtrage, agrégation, ajout d’une constante, blocage du flux,…) pour finir vers une étape cible -ou destinatrice (étapes alimentation).

Toutes les étapes d’une transformation sont lancées en parallèle (multi thread). En effet, c’est une réalité très importante dans les transformations! Si votre étape n’est pas censée recevoir des lignes d’une autre étape, elle démarrera et s’exécutera indépendemment des autres étapes! Ce n’est pas le cas de notre exemple précédent (les étapes filtrage et alimentation fichier Excel attendra des lignes respectivement de l’étape « Extraction depuis table » et « Filtrages lignes »).

Un exemple typique pour illustrer mes propos c’est l’utilisation des étapes « Récupération Variables » et « Récupération Variables » dans la même transformation pour créer une variable et s’en servir.

En effet, imaginez que je souhaites créer une varible (Nom) et l’utiliser dans la même transformation. Toutes les étapes étant exécutées en parallèle, l’étape « Récupération Variables » va essayer de récupérer la valeur de la variable et ne trouvera dans la plupart des cas rien car l’étape « Création de variables  » s’est lancée juste après (mais elle peut se lancer avant aussi). Donc vous ne pouvez pas garantir l’ordre d’éxécution: dans ce cas, il est impératif de séparer la création et l’utilisation des variables dans des transformations séparées (on utilisera des entrées tâches pour cela – voir plus loin-. 

–> Les tâches elles permettent le séquencement des actions.
Exemple:
Je démarre –> je télécharge des fichiers via FTP — Si OK –> je traite les fichiers — Si NOK –> j’envoi un mail d’erreur.

Une tâche manipule des entrées tâches (équivalents des étapes dans les transformations), mais une entrée tâche a un résultat binaire, ou précisemment l’exécution d’une entrée tâche donne une résultat binaire. Ensuite, il suffit de gérer ces états :

-Succès (on poursuit avec les flèches vertes)

– Echec (on poursuit avec les flèches rouges).

A un instant , une seule entrée tâche est exécutée!! (ce qui diffère des transformations ). Notons toutefois que le version 3.1 permet l’exécution en parallèle.

Il existe une palette d’entrées tâches (récupération/envoi de fichiers via FTP, SFTP, envoi de courriels,etc.) et cette liste est constamment mise à jour. Une transformation peut être exécutée dans une tâche (voir exemple ci-dessus) et également une tâche peut être lancée depuis une autre tâche comme le décrit le modèle conceptuel simplifié de PDI.


 L’état final d’une tâche est le status (succès ou échec) de la dernière entrée tâche exécutée.

Voila j’ai un peu fait le tour. J’espère que j’ai été assez clair🙂

A+

Samatar

Suivre

Recevez les nouvelles publications par mail.