Organisation des classes

Le projet est articulé autour de Maven. Maven permet de construire le projet en gérant les dépen- dances, les artéfacts et les instructions de constructions. Les configurations des Maven sont décrites

dans un fichier POM (Modèle Objet de Projet). e-Vision est organisé en module, cette arborescence en donne l’organisation du projet :

1. dk-Saiku : C’est le projet principal, la racine du projet.

(a) saiku-core est le module qui sert de conteneur à toute l’intelligence du logiciel

i. Saiku-web est le module qui contient tous les web-service REST de l’application. C’est cette couche qui va être appelée par l’interface.

ii. Saiku-service est le module contient l’intélligence du logiciel. Il permet de faire les requêtes, de les traiter et de rendre les résultats. C’est dans ce module que l’on retrouve la dépendance de Mondrian.

(b) saiku-webapp est un module qui contient tous les fichiers de configuration et de connexion. C’est le module qui est déployé en tant qu’application web. Il admet dans ses dépendances saiku-web et saiku-service.

(c) saiku-ui est le seul module qui ne soit pas du Java. Maven se contente ici de fournir les instructions de construction. Ainsi, le projet est archivé au format zip lors de la compila- tion du projet.

(d) saiku-server est un module que l’on n’utilise pas dans e-Vision. Ce module embarque les modules saiku-webapp et saiku-ui ainsi qu’un serveur apache-tomcat. De cette façon, on fournit une solution tout-en-un qui est prête à être déployée sur les serveurs.

Saiku-ui

Saiku-ui est responsable de toute la couche de présentation de l’application. C’est une application qui se base sur les technologies javascript backbone.js, underscore.js et JQuery.

BackboneJs se présente comme un cadre logiciel de type Modèles, Vues, Collections. Les modèles et les collections de modèles sont synchronisés directement avec les données provenant de l’application coté serveur. La synchronisation des modèles se fait grâce à une API REST. Il suffit d’ailleurs de lier les modèles à une URL qui pointent vers les services e-Vision pour faire la synchronisation

UnderscorJs est une librairie présente dans les dépendances de BackboneJs. Elle offre la possibilité de manipuler des objets, des collections ainsi que des tableaux. Elle offre aussi des fonctions d’aides aux développements.

JQuery permet aussi de se servir de templates pour pouvoir gérer le rendu. Chaque élément pré- sent dans le rendu de e-vision provient d’un template JQuery qui sont tous centralisés dans l’index.html. Il permet aussi de gérer dynamiquement le DOM de la page.

Saiku-web

Ce module est responsable de tous les services REST de l’application. Touts les services sont construits autour d’URL dans des classes Java. Il n’y a pas de difficulté particulière sur ce module. Les principaux services sont listés ci-dessous.

BasicRepositoryResource2 : Cette ressource regroupe toutes les actions qui sont utiles pour la ges- tion des rapports. On trouve ainsi les services pour supprimer, renommer, déplacer des rapports ou des répertoires. En ce qui concerne la création, on ne peut pas créer de rapport via service, juste les dossiers. La création de rapport dépend du webservice QueryResource.

DataSourceResource Cette ressource gère les connections aux différentes bases de données. Ce service a accès aux fichiers de configuration disponible dans le module webApps.

EppkSessionResource : Cette ressource sert à récupérer les informations de l’utilisateur connecté de manière à les afficher à l’écran. C’est l’un des rares services à avoir un lien direct avec e-Paprika e-Paprika.

EppkResource : C’est le second service qui a accès à e-Paprika pour récupérer la liste des réseaux. On retrouve aussi dans ce module les dates de dernières mises à jour et les numéros de version de l’application.

OlapDiscoverResource : Cette ressource permet de récupérer toutes les informations sur les cubes qui ont été configurés dans Mondrian. On peut ainsi y trouver la liste des dimensions, des hiérarchies et la description de tous les membres. Il n’y a pas de requête de mise à jour ou de création. En effet, les cubes de Mondrian sont fixés et ne sont pas modifiables par l’utilisateur. QueryResource : Cette ressource permet toutes les actions sur les requêtes. Toutes les actions que l’on peut faire à l’IHM on une url associée dans cette classe. On pourra ainsi y trouver la création et la sauvegarde de requête, l’ajout et la suppression des dimensions, des mesures ou de filtres ou encore l’exécution en vue d’obtenir un tableau de résultats.

Saiku-service

Aucune des ressources évoquées dans la section précédente ne fait directement de traitement. Chacune d’entre elles délègue les actions à des services. Nous ne faisons pas ici la liste des services associés aux différentes ressources. Cependant, nous expliquons plus en détail le fonctionnement du service qui gère les requêtes.

En effet, ce service est le point central de l’application puisqu’il permet de générer les tableaux. Dans ce service, on utilise une interface iQuery qui est implémentée par les objets de requêtes. Les deux objets qui implémentent cette interface sont OlapQuery et MdxQuery. Celui qui nous intéresse ici est l’OlapQuery qui sert à gérer les requêtes construites par l’interface. L’objet MdxQuery sert pour l’éditeur MDX de saiku qui n’est pas utilisé ou uniquement à des fins de développement.

L’objet OlapQuery est donc l’objet que l’on manipule lorsque l’on veut ajouter ou modifier des comportements dans la requête. Tout comme Mondrian, cet objet utilise l’api Olap4j pour manipuler et générer le MDX. Cet objet se présente comme une surcouche de la requête Olap4J pour accepter les manipulations qui sont faites à l’écran. On trouve ainsi des méthodes qui changent les dimensions d’axes, qui ajoutent ou suppriment des filtres ou des mesures. L’exécution de la requête est quant à elle déléguée à Mondrian. C’est Mondrian qui prend la requête MDX générée dans le service pour la transformer en requêtes SQL et retourner le tableau.

Dans le développement, on essaie de ne pas modifier en profondeur les comportements du logiciel de référence. On préférera ajouter des comportements que modifier ceux existants dans la mesure du possible. Ceci permet de faciliter les montées de versions du logiciel. Un autre point d’attention concerne Mondrian. Initialement, ce projet est une simple dépendance Maven. J’ai du importer le projet pour corriger certains bugs présent dans la version que l’on utilisait. Cependant, cette applica- tion a une logique interne très complexe pour générer les requêtes SQL à partir du MDX. J’ai donc

fait le choix de ne pas intervenir sur le code sauf pour corriger des bugs, je n’apporte jamais de mo- dification aux fonctionnalités de Mondrian. Toutes les nouvelles fonctionnalités sont donc intégrées au niveau de Saiku