Mesurer les statistiques de connexion d’un site web est désormais devenu incontournable dans de nombreux domaines d’activités.
Comprendre les comportements, les profils et les caractéristiques des internautes sont des facteurs déterminants pour la visibilité, le succès et donc la longévité de nombreux sites.
Ceci est tout particulièrement vrai pour les sociétés dont le business model repose exclusivement sur une présence sur la toile : e-commerce, services en ligne…
Habituellement, pour récupérer les statistiques de connexion d’un serveur web, on utilise des outils spécifiques de mesure d’audience : Xiti, Piwik, Mint, Google Analytics…
Lorsque ce dernier est utilisé conjointement avec Google AdWords, il devient même possible de calculer le retour sur investissement (ROI) d’achats de mots clés par rapport au trafic généré.
Cet article vous propose de découvrir :
Comment récupérer simplement des statistiques de connexion Google Analytics avec l’ETL open source Pentaho Data Integration (PDI)
Comment analyser rapidement les données récupérées avec l’outil de modélisation intégré dans PDI
Comment publier efficacement les analyses sur un serveur décisionnel Pentaho
Ces derniers jours, la blogosphère francophone s’est enflammée concernant la pertinence de GWT. Florent Garin a ouvert les hostilités jeudi dernier en questionnant cette pertinence, avec une réponse nuancée mais néanmoins plutôt négative. Sami Jaber y a répondu vendredi par un vibrant “oui” (à la limite du fanatisme cependant). Et enfin Ludovic Borie seconde ce dernier avis tout en confirmant les défauts critiqués par le premier.
Je me devais de réagir, n’étant en accord complet avec aucun d’entre eux. Mais tout d’abord, il faut bien avouer que mon avis n’est pas celui d’un utilisateur lambda, étant très impliqué dans le développement même de GWT: outre de nombreux patchs, je suis l’un des rares à pouvoir faire le tri des bugs (les assigner, les fermer), et les bugs concernant RequestFactory me sont quasiment assignés d’office. D’autre part, je n’ai (à mon grand regret) jamais écrit (ou même lu : si vous avez des liens, je suis preneur) de grosse single-page application en JavaScript. Lire la suite »
Dans une suite décisionnelle, le tableau de bord (ou « dashboard ») est un élément clef pour fournir des informations synthétiques facilement accessibles.
Le pilotage stratégique, le pilotage opérationnel et les indicateurs de performances (KPIs) sont autant de cas d’utilisations des tableaux de bords. La plupart du temps, un dashboard présente un maximum d’informations dans un minimum de place, en faisant appel à une grande interactivité et à de multiples composants graphiques.
Mettre en place des tableaux de bords dans la version libre (Community) de Pentaho n’a pas été toujours une chose très aisée (ce n’est pas le cas de la version Enterprise qui propose un module WYSIWYG full Web à destination des utilisateurs métier).
Dans les premières versions de la plate-forme, les dashboards devaient être codés directement en langage JSP (Java Server Page), ce qui nécessitait une connaissance très avancée des classes Java internes, des libraires graphiques (JFreeChart) et du fonctionnement des séquences d’actions (Xactions).
Très difficile donc (voir impossible) de mettre en place des dashboards sans avoir un profil de développeur JAVA !!
C’est dans ce contexte qu’est né en 2009 le projet communautaire Pentaho CDF(Community Dashboard Framework), à l’initiative de Pedro Alves (de WebDetails)
Son objectif était simple: fournir une API complète permettant de s’affranchir de la complexité interne de Pentaho grâce au paradigme MVC (Modèle-Vue-Contrôleur)
Au fur et mesure, d’autres projets se sont greffés à Pentaho CDF, pour constituer ce qu’on appelle désormais les « C*tools » :
CDA (Community Data Access), pour accéder de manière simple et flexible à de multiples sources de données (en SQL, MDX, XML, PDI, Metadata, scripting…). CDA dispose notamment d’un mécanisme de mise en cache et permet d’effectuer des jointures entre des sources hétérogènes par simple configuration XML.
CCC (Community Charting Components), une très bonne librairie de visualisation graphique s’appuyant sur Protovis, un projet open source de data-visualization (Javascript+SVG)
CST (Community Startup Tabs), un plugin qui permet de paramétrer les onglets à afficher au lancement de la « Pentaho User Console », en fonction des droits de l’utilisateur connecté
CDE (Community Dashboard Editor), pour la création et la publication de tableaux de bords directement depuis l’interface web de Pentaho.
Les C*tools permettent de délivrer des tableaux de bord d’une qualité professionnelle, en minimisant la complexité liée à de l’écriture de code. Jetez plutôt un œil sur cette présentation afin d’en prendre pleinement la mesure :
Nous venons de réaliser une nouvelle extension pour TYPO3 « TYMIS » qui est la contraction de TYPO3 et CMIS. Cette extension permet à TYPO3 d’interagir avec tout entrepôt conforme avec le protocole CMIS.
Cette nouvelle extension va permettre aux entreprises utilisant des solutions d’ECM comme Alfresco, Sharepoint, Documentum, FilNet, Nuxeo, Vignette, etc., d’ouvrir leurs contenus aux utilisateurs de TYPO3. Les contenus de ces solutions pourront être accessible au travers d’un site intranet, extranet, internet ou d’un portail réalisé avec TYPO3.
Un rappel du protocole CMIS
L’accès et le partage des documents sont des enjeux stratégiques pour les entreprises et les collectivités, mais la multiplicité des outils stockant/contenant leurs documents ne leur facilite pas le travail. Il n’est pas rare d’avoir dans une même entreprise (voir un même service) des solutions différentes permettant la gestion, l’archivage et l’accès aux documents. Chaque solution (ECMs, GED, Outil Collaboratif…) gère bien des entrepôts de documents, mais chacune offre des moyens d’y accéder totalement différents.
L’idée de CMIS est de standardiser l’accès aux documents et aux d’informations les décrivant (métadonnées / métatags), et ainsi de pouvoir offrir l’accès à ces données de manière identique à partir de solutions différentes. Lire la suite »
Depuis peu, la Release Candidate de Geokettle 2.0 est disponible en téléchargement sur Sourceforge . Pour rappel, cet ETL basé sur Pentaho Data Integration ajoute à ce dernier des fonctionnalités dédiées à la manipulation de l’information géographique. Si les premières versions de GeoKettle proposaient déjà des fonctionnalités intéressantes (cf. billet précédent), il faut bien reconnaître que pour cette version, les équipes de Spatialytics ont clairement mis le paquet afin de proposer une version corrigée et très enrichie de Geokettle. Cette dernière, encore basée sur un coeur PDI 3.2 fonctionne en 32 ou 64bits ; des réflexions sont en cours pour porter les fonctionnalités spatiales vers les versions 4.x de PDI.
Premières impressions
Un installateur dédié
Geokettle dispose désormais d’un script d’installation dédié. L’installation par décompression d’un zip reste bien entendu possible mais désormais, les géomaticiens n’auront plus d’excuses pour ne pas installer cet outil sur leur poste.
Une prévisualisation cartographique des données
Un mécanisme de prévisualisation cartographique est désormais disponible pour toutes les étapes. Un onglet « Vue géographique » permet de visualiser la représentation des différentes colonnes géométriques présentes dans le flux. Les actions de zoom, de centrage, d’interrogation d’objets et de personnalisation des styles cartographiques sont également proposées. A l’usage, cet onglet se révèle bien pratique pour vérifier sur des jeux de données restreints que les traitements à réaliser sont corrects avant de lancer ces derniers sur des gros volumes.
Ces dernières années ont vu l’arrivée de nouveaux terminaux mobiles dont les interfaces se sont de plus en plus adaptées aux contraintes de leur environnements. Nous allons tenter dans cet article d’identifier ces contraintes et voir quelles réponses apporter dans les applications web via l’utilisation du framework Sencha Touch.
Nous recevons un nombre croissant de demandes de nos clients qui concernent la génération d’un fichier PDF ou d’une image à partir d’une page web issue d’une application métier, un extranet ou encore un intranet.
Facile me direz-vous : il suffit d’installer une imprimante PDF telle que PDF Creator ou encore doPDF. Effectivement… Sauf que cette opération nécessite une installation sur le PC de l’utilisateur et que c’est justement ce qu’on essaie d’éviter avec une application web !
Le besoin est réel et il n’existe pas aujourd’hui de solution générique qui fournisse des résultats concluants.
Bien souvent, le réflexe reste de développer un nouveau module pour l’occasion qui traite le cas spécifique de l’impression des informations avec une présentation connue à l’avance.
Partant de ce constat, nous avons décidé de mettre en œuvre une solution générique de capture de pages web côté serveur, avec un fichier produit qui soit le plus fidèle possible au résultat obtenu avec un navigateur classique.
Dans ce billet, je détaille mes pistes de réflexion en exposant ma démarche par étapes et j’expose les résultats obtenus : de l’impression rapide côté client à l’adaptation d’une librairie utilisée côté serveur.
L’utilisation du format GML est aujourd’hui courante dans les fichiers d’échanges XML. Parallèlement, les outils ETL procurent de réels avantages pour mettre en place les chaines de traitements liées à ces besoins d’échanger (changements de format et/ou de structure de la données, échanges entre plateformes, etc.). Aujourd’hui, et à moins de disposer d’un ETL spatial évolué ou de faire appel à des librairies externes comme OGR, il faut bien reconnaitre que la manipulation du GML dans les ETL Open source non spatiaux peut s’avérer fastidieuse, ce format étant par nature assez verbeux (emboitement de nœuds successifs). Pour les amateurs de Kettle (Pentaho Data Integration), il existera pourtant prochainement une solution : Exploiter conjointement la librairie JTS et la future brique améliorée de lecture XML disponible dans la prochaine version PDI 4.2 (en cours de développement). Les paragraphes suivants expliquent la démarche à suivre pour réaliser ce genre de traitements.
2. Mise en pratique
Pour notre exemple, nous disposons des outils suivants :
L’ETL Pentaho Data Intégration 4.2 en cours de développement (ne pas utiliser en production avant l’apparition d’une version stable). http://ci.pentaho.com/job/Kettle/
Une base de données PostgreSQL disposant des fonctionnalités de PostGIS
Pentaho Data Intégration permet nativement de faire appel à des librairies Java au sein des étapes « Appel script interprété Rhino ». Pour pouvoir exploiter la librairie JTS à travers ces étapes, il faut déposer au préalable les jars « jts-1.11.jar » et « jtsio-1.11.jar » dans le dossier libext de PDI.
2.1. Principe
Les transformations proposées ci-après correspondent à deux besoins simples :
Comment lire un contenu GML pour pouvoir l’intégrer en base de données spatiale ?
Comment produire un fichier XML avec du contenu au format GML à partir d’une base de données spatiale ?
2.2. Intégrer un contenu GML en base de données spatiale
Dans cet exemple, nous disposons d’un fichier XML regroupant des îlots agricoles (entité administrative utilisée par les agriculteurs dans le cadre de la Politique Agricole Commune pour prétendre au versement d’aides européennes) et des parcelles culturales (limites d’une même culture = les « champs »).
Un îlot peut contenir une ou plusieurs parcelles culturales et possède une géométrie de type « polygone » équivalente à l’union géométrique des parcelles qui le compose,
Une parcelle possède une géométrie de type « polygone » et ne peut être rattachée qu’a un seul îlot.
Il y a quelques temps déjà, je suis tombé sur un plugin très intéressant pour le serveur Pentaho, à savoir le MetadataSample Plugin.
Ce petit plugin développé par Andy Grohe, démontre comment on peut interagir avec le Web Service utilisé par le WAQR de Pentaho(Web Ad Hoc Query Reporting) afin de proposer d’autres possibilités de présentation pour l’interface utilisateur (GUI).
Pour rappel, le WAQR, c’est le module web disponible dans Pentaho (versions CE & EE) qui permet de construire un rapport à partir de la couche de métadonnées, sans aucune connaissance du SQL par l’utilisateur final. C’est assez pratique (par exemple) pour réaliser des exports Excel en manipulant simplement des vues et des colonnes métier. Je détaillerai tout ceci dans des prochains articles…
Après avoir développé cet été le plugin« BIRT ODA Pentaho Metadata Plugin », je me suis dit qu’il était finalement intéressant de mixer le travail d’Andy et le mien pour permettre à ce bon vieux Kettle de récupérer lui aussi des données depuis des domaines de métadonnées « Pentaho Metadata ».
Quel intérêt ?
Prenons un exemple simple, sur la base de données SampleData embarquée dans le serveur Pentaho de démo.
Imaginez que vous souhaitiez générer avec Kettle un fichier Excel synthétisant le montant total des ventes par gamme de produit (ProductLine) et par client (CustomerName), tout ça pour la France.
Votre traitement va ressembler à ceci :
L’ordre SQL à cela (3 jointures, un GROUP BY, une clause WHERE) :
SELECT
CUSTOMER_W_TER.TERRITORY,
CUSTOMER_W_TER.COUNTRY,
CUSTOMER_W_TER.CUSTOMERNAME,
PRODUCTS.PRODUCTLINE,SUM(ORDERDETAILS.QUANTITYORDERED * ORDERDETAILS.PRICEEACH)AS TOTAL
FROM
PRODUCTS INNERJOIN ORDERDETAILS ON PRODUCTS.PRODUCTCODE = ORDERDETAILS.PRODUCTCODE
INNERJOIN ORDERS ON ORDERDETAILS.ORDERNUMBER = ORDERS.ORDERNUMBER
INNERJOIN CUSTOMER_W_TER ON ORDERS.CUSTOMERNUMBER = CUSTOMER_W_TER.CUSTOMERNUMBER
WHERE
CUSTOMER_W_TER.COUNTRY ='France'GROUPBY
CUSTOMER_W_TER.TERRITORY,
CUSTOMER_W_TER.COUNTRY,
PRODUCTS.PRODUCTLINE,
CUSTOMER_W_TER.CUSTOMERNAME
Avec le plugin d’extraction depuis une source Pentaho Metadata, cela va être un peu plus simple, puisque tout se gère dans une interface spécifique :
Dans ce cas, il suffira juste de sélectionner les 5 colonnes métiers utiles, et selon le type d’agrégateur pour le champ « Total » défini dans la couche de métadonnées, la consolidation sera automatique…
Bien sûr les colonnes métiers peuvent être traduites en français, italien, espagnol, etc… Pentaho Metadata gère le i18n.
Dans la vidéo qui suit, vous allez vous rendre compte que selon l’utilisateur avec qui on se connecte, l’accès aux modèles métiers est sécurisé: seul « Joe » accède aux 3 modèles (mais pas Suzy ou Pat). Cela serait valable également pour les colonnes métiers (sauf que dans le metadata de démo ce n’est pas configuré). On pourrait également dicter des règles filtrage au niveau des lignes retournées et non plus des colonnes (« row-level filtering ») : par exemple Joe ne pourrait voir que les données pour la France, Suzy pour les USA et Pat pour l’Italie…
Démonstration
Rien de telle qu’une vidéo pour mieux appréhender le fonctionnement du plugin :
Installation
Le plugin est disponible en version beta (v0.8) sur labs.atolcd.com, où vous trouverez d’ailleurs d’autres contributions plutôt intéressantes dans le domaine de l’OSBI, mais aussi de l’ECM, des SIG et des CMS :
Un plugin Kettle pour écrire directement dans des DataList Alfresco via le standard CMIS
La version 1.0 de Geo Analysis Tool(portée sous GWT). J’en reparlerai ici bientôt également…
Pour que le plugin fonctionne, vous devez utiliser obligatoirement Kettle 4.0 ou 4.1 et un serveur Pentaho 3.6 ou 3.7.
Guide d’installation :
Décompresser le fichier « PentahoMetadata_Kettle_Plugin-0.8.zip » dans le répertoire d’installation de Kettle \plugins\steps. Un répertoire « MetadataPlugin » est créé. Celui-ci contient la librairie java, l’icône de la brique au format png ainsi qu’un fichier « mqlQuery.xaction »
Copier le fichier « mqlQuery.xaction » dans le répertoire \pentaho-solutions\system du serveur Pentaho
Démarrer votre serveur Pentaho , lancer Kettle puis tester cette nouvelle étape, vous la trouverez dans le dossier « Extraction »
Pourquoi une version beta ?
Ce plugin a été finalement développé en très peu de temps, surtout pour le « fun ».
Bien sûr il y a des améliorations à apporter :
Pouvoir ajouter simplement une condition de filtrage dans l’étape via une interface « user friendly » et non une contrainte MQL (dont il faut connaître la syntaxe XML)
Rajouter des contrôles d’erreurs (ajout d’exceptions Java) notamment lorsqu’il y a des soucis d’accès au web service et/ou au serveur Pentaho (ça manque)
Et surtout, adapter le plugin aux évolutions de la plate-forme afin d’attaquer d’ici peu l’API prévue dans Pentaho 4. James Dixon a déjà fourni quelques éléments sur ce sujet fin 2010 dans son « JimmyLabs », de la doc techniquement fortement intéressante !
Si jamais vous trouvez des bugs, vous pouvez les notifier dans le gestionnaire de bugs afin qu’une version stable 1.0 voie le jour
Ah j’oubliais, lors du développement du plugin Kettle pour Alfresco, nous avons commencé à rédiger un document assez détaillé (merci Vincent) pour vous aider à coder vous-même vos propres plugins Kettle. A suivre donc, celui-ci sera bientôt disponible sur notre blog technique !
Pentaho est une suite décisionnelle open source commerciale très ouverte dont les différences fonctionnelles entre la version libre gratuite (CE=Community Edition) et la version payante (EE=Enterprise Edition) sont limitées.
Le degré d’ouverture est d’ailleurs bien plus élevé que chez Actuate BIRT ou JasperSoft.
Voici un document de synthèse qui présente dans le détail les différences fonctionnelles entre les 2 versions de Pentaho. Bien sûr, n’oubliez pas que la version Enterprise permet en outre de bénéficier du support directement auprès de l’éditeur !
Ce document, valable pour Pentaho 3.7, vous permettra de constater que la version gratuite de Pentaho permet de déployer une plate-forme décisionnelle complète, et ceci avec une grande qualité d’intégration.
