Jean-Pierre Riehl (de la société Azeo, connu sous le pseudo de djeepy1) présente cette session, en commençant par une revue rapide du principe de la BI : créer de la valeur en transformant de la donnée en information à teneur de décision.
ReportViewer et PivotView peuvent être utilisées comme viewers depuis PowerPivot. Par contre, en amont, PowerPivot ne fait que peu de nettoyage, agrégation, formatage, ajout de règles métiers en amont. Du coup, l’idée de Data Explorer est de combler ce manque pour avoir une ligne Data –> Data Explorer –> PowerPivot –> PowerView. Le tout forme la Self Service BI.
ETL va alors devenir plutôt ETP, car le chargement dans un cube sera plutôt découplé en publication d’un service de données, qui lui-même sera utilisé ensuite par un cube.
La CTP de Data Explorer devrait passer en release dans le courant de l’année. Tout se passe en version online, car c’est un outil qui est sur le Cloud. On peut demander un accès, il suffit d’un LiveID.
L’extraction peut se faire à partir de fichiers pas nécessairement parfaitement tabulaires. L’outil propose de choisir l’onglet, et permet de nettoyer en interactif le fichier. On peut par exemple ajouter dans le pipeline des actions de Skip des premières lignes, de suppression de colonnes, etc. Ensuite, on va mettre un FirstRowAsHeader, etc. Les actions sont décrites par une grammaire qui ressemble aux fonctions d’Excel (ou peut-être du DAX ?)
Il manque une action de merge intelligent, car le merge est une simple jointure, qui ne tient pas compte des accents, etc. Du coup, l’approche comme quoi un analyste peut se débrouiller sans capacité de développement est un peu biaisée.
Note : l’intervenant présente http://jsonformatter.curiousconcept.com, qui est un outil de formatage du JSON en ligne.
La récupération de l’adresse géolocalisée montre d’autant plus que seul un développeur peut réaliser cette approche. C’est d’ailleurs assez rassurant de voir que même Microsoft n’a pas réussi à inclure plus d’intelligence que dans des applications de pipeline normales. Par contre, ce qui est très intéressant est qu’on dispose d’un assistant, même s’il faudra bien sûr voir si on peut récupérer un format descriptif du contenu de l’ETP (apparemment, c’est le cas car on peut publier le format DE Mashup). Le langage de programmation est basé sur le métalangage M.
La publication se fait par défaut sur le site de DataExplorer lui-même (et pas dans Azure Data Market).
Le requêtage se fait de manière systématique. Par contre, on fait quand même des snapshots pour pouvoir figer le résultat d’un mashup. Le snapshot est alors au format DataExplorer, ou au format Base de données.
Il y a un add-in Excel pour publier de la donnée. Data Explorer existe également en version On Premise pour des serveurs locaux. Enfin, il est bien sûr possible d’exporter sur Azure Data Market. Certaines actions de transformation pourront être proposées de manière contextuelle en faisant de l’analyse de pattern (“Voulez-vous insérer la population de cette commune?”).
Il reste certaines questions : Comment ça se passe sur des gros volumes d’entrée ? Comment est-ce que le résultat tient compte des données qui ne changent pas lorsqu’il est rafraîchi lors de changement des fichiers sources ? Sur du contenu extérieur, il se remet automatiquement à jour, et ce de manière systématique, mais comment est-ce qu’on prend le cache en compte dans cette architecture ? Pour l’instant, il semble que le recalcul soit systématique, ce qui n’est vraiment pas bon du point de vue de l’utilisation des ressources.
