Qu’est ce que BIRT?
Non BIRT n’est pas le nom d’un cratère d’impact sur la face visible de la Lune, du moins ce n’est pas notre sujet aujourd’hui. BIRT est le petit nom du projet Business Intelligence and Reporting Tools porté par la fondation Eclipse. Il s’agit, comme son nom l’indique, d’une plateforme de business intelligence et de reporting basée sur Eclipse qui offre un socle de production de rapports très orientés web. BIRT est né en septembre 2004 et sa dernière version stable 2.5.1 est disponible depuis fin septembre. Il est souvent vu comme un « Yet Another Java Reporting Tool », mais au delà de son outil de conception et son moteur d’exécution des rapports, BIRT est avant tout un véritable framework de reporting JEE basé sur une architecture modulaire et des API puissantes qui permettent d’intégrer et d’étendre ses fonctionnalités à souhait. BIRT est certes jeune mais a su apprendre de ses ainés (JasperReport, Pentaho …etc.).
J’ai eu l’occasion de jouer avec BIRT dans différents projets JEE, de la conception des rapports et leur déploiement jusqu’à l’intégration de fonctionnalités BIRT à des applications JEE. Je vous propose dans cette série d’articles de découvrir la puissance de cette plateforme en présentant les différents composants BIRT ainsi que le cycle de vie d’un rapport (Partie 1), les différentes manières de créer un rapport (Partie 2), les choix d’intégration et de déploiement (Partie 3) et enfin les possibilités d’extension de BIRT (Partie 4).
- Partie 1 : BIRT, une plateforme et un véritable framework de reporting.
- Partie 2 : Tout le monde peut créer un rapport BIRT.
- Partie 3 : Intégration et déploiement : BIRT se plie à vos envies.
- Partie 4 : Extension : Tout peut être étendu dans BIRT.
Partie 1 : BIRT, une plateforme et un véritable framework de reporting
Construite autour de plusieurs composants, BIRT est tout d’abord une plateforme basée sur Eclipse et s’appuie sur les frameworks de ce dernier pour ses couches de données (DTP) et de modélisation graphique (EMF) mais aussi pour sa GUI (GEF).
Les composants de la plateforme BIRT
Les applications BIRT
Les BIRT Designers
L’outil de design graphique de BIRT ouvre la voie à différents profils de développeurs. Dans sa version RCP basée sur la plateforme Eclipse du même nom, la connaissance du langage Java et/ou de l’IDE Eclipse devient optionnelle. Il s’agit d’une version allégée du BIRT Report Designer qui lui, permet de rester dans notre Eclipse favori (Galileo depuis la 2.3) grâce à une perspective nommée Report Design et donc de rester proche de notre Java et nos plug-ins adorés. La version RCP simplifiée et la version Eclipse sur-vitaminée de plug-ins BIRT (les BIRT core component plugins) permettent d’utiliser une large palette d’éléments de rapports pour une conception presque WYSIWYG (Datasources, Datasets, Cubes, Grids, Tableaux, Tableaux croisés, Charts grâce au puissant Chart Builder, Labels …etc.). Tous ces éléments forment le modèle du rapport ou ROM que je détaillerai plus bas et peuvent être formatés et stylisés (possibilité d’utiliser des CSS externes). En plus des opérations classiques de tri, regroupements, agrégations…etc., de la programmation peut être ajoutée assez facilement à ces éléments grâce notamment à l’Expression Builder ou aux éditeurs de code qui, comme je le présenterai plus loin, permettent de développer du Java ou du faire du scripting (code JavaScript s’appuyant sur le moteur Mozilla Rhino) afin de modifier le rapport tout au long de son cycle d’exécution.
La prise en main du designer est assez rapide. Habitué à l’environnement Eclipse, je me suis senti vraiment à l’aise en développant mes rapports. J’ai particulièrement apprécié le niveau de productivité qu’offre BIRT grâce entre autres à la notion de librairies. Ces composants utilisables par n’importe quel rapport permettent de factoriser dans un seul fichier n’importe quel élément de la palette et ainsi de le réutiliser dans plusieurs rapports. L’exemple typique est une source de données ou une feuille de style partagés. Imaginez un projet avec une centaine de rapports et dont la source de données a changé (réf. JNDI ou URL JDBC), il suffirait de modifier cette source de données dans la librairie et la modification sera automatiquement propagée à tous les rapports qui la référencent. Un gain de temps appréciable sachant que n’importe quel élément, allant du simple label jusqu’aux templates de rapports en passant par les datasets scriptés, peuvent être placés dans une librairie.
Le designer permet donc le développement end-to-end de rapport, de la mise en place des sources de données jusqu’au packaging pour une intégration web JEE (via le plugin WTP pour Eclipse) en passant par les tests. Pour ces derniers le designer permet d’exécuter les rapports directement depuis la perspective Eclipse grâce à l’intégration d’une autre application BIRT : le BIRT Viewer.
Le BIRT Viewer
Le BIRT Viewer est une sorte de lecteur de rapports BIRT qui permet d’interpréter un fichier .rptdesign ou .rptdocument (j’expliquerai plus loin la différence entre les deux formats et les étapes nécessaires à l’exécution et au rendu de rapports BIRT) et de les restituer sous format HTML et HTML avec pagination (les graphiques pouvant être générés en PNG, JPG, BMP ou SVG, ce dernier format permettant une grande interactivité avec les graphiques : infobulles, liens, data drill-down …etc. ). Le BIRT Viewer donne accès via une toolbar à des fonctionnalités d’impression, d’export des données présentées au format CSV mais aussi d’export du rapport complet en Postscript, Excel, Word, PowerPoint et PDF. Pour ce dernier format BIRT génère automatiquement (via l’API iText) des signets et une table de contenu correspondant par exemple aux regroupements dans un tableau, ce qui permet une navigation plus aisée dans les rapports de plusieurs pages. Enfin, l’utilisateur peut saisir les paramètres du rapport via un formulaire du Viewer.
Le BIRT Viewer se décline en deux versions : un Web Viewer et un plugin Eclipse.
La version web est à l’origine un exemple d’application JEE embarquant le moteur BIRT. Fortement basée sur AJAX, c’est une véritable « boîte à outils » qui contient tous les éléments nécessaires pour un déploiement sur n’importe quel app server JEE mais aussi pour une intégration dans une votre propre web app JEE. Son déploiement est aussi rapide que celui d’un module web basique. Le WAR ainsi déployé expose toutes les fonctionnalités que j’ai présentées au dessus et permet via de simples URLs de désigner les rapports à exécuter et de leur passer les bons paramètres, on parle d’intégration par URLs et c’est vraiment trivial. Les choses se gâtent un peu dès qu’il s’agit d’intégrer le BIRT Viewer dans une autre web app JEE et sur un app server autre que Tomcat. J’ai personnellement eu du mal avec un Weblogic 9.2 et les versions 2.3.1 et 2.5 de BIRT et notamment à cause d’assertions Java mal utilisées dans BIRT (ou finement gérées par Weblogic?). Mais après avoir déactivé les assertions pour les packages de BIRT et jonglé avec les conflits de dépendances (Les joies des bibliothèques XML…) le comportement et les fonctionnalités attendus étaient au rendez-vous.
Cette version web est construite autour de deux principales Servlets BIRT : la ViewerServlet et la BirtEngineServlet (toutes les deux étendent les servlets AxisServlet qui gèrent les communications SOAP) mais aussi de fragments JSP, de classes JavaScript et de feuilles de styles CSS. Le framework JavaScript Prototype est utilisé pour implémenter les communications AJAX entre les servlets et le Web Viewer. Ces communications sont basées sur le modèle d’Events et de Handlers de Prototype. Je présenterai plus en détail l’architecture de cette webapp dans la Partie 3 : Intégration et déploiement.
Le plug-in Eclipse intègre le Viewer à la perspective Report Design ou à n’importe quelle application basée sur Eclipse. Il embarque le serveur Tomcat sous forme de plug-in Eclipse (org.eclipse.tomcat) et permet d’exécuter le rapport dans la version web du Viewer (qui est donc exécutée à la demande au sein du Tomcat embarqué) ou directement sous format Excel, Word et PowerPoint. Ce même plug-in ajoute des cibles d’exécution à Eclipse « Run Report » ou encore « Debug Report » permettant ainsi, à l’image d’un « Run as Java Application », de tester les rapports en cours de développement.
Avec son designer puissant et intuitif, son viewer packagé prêt à être déployé, BIRT permet de mettre en place assez rapidement une plateforme de développement, de test et de déploiement. Une combinaison BIRT Report Designer et BIRT Viewer sous Tomcat pour une intégration par URL permet de développer un premier rapport et de le déployer en moins de deux heures. Qui dit mieux?
Derrière ces applications BIRT se cachent des APIs puissantes que je vous propose de découvrir dans ce qui suit.
Le framework de reporting
Des moteurs et des services
Les moteurs BIRT constituent le cœur du système. Il s’agit d’un ensemble d’APIs Java regroupées en trois fonctionnalités principales :
- la conception et la modification de rapports : Design Engine API (DE API),
- le charting ou reporting graphique : Chart Engine API (CE API),
- l’intégration, l’exécution et l’export : Report Engine API (RE API).
Les services se composent de classes Java issues des différentes API :
- Generation Services
- Presentation Services
- Data Services
Pour faire plus ample connaissance avec ces moteurs et ces services, regardons de plus près comment construire un rapport et comment le restituer.
Comment fonctionne un rapport BIRT?
Chaîne d’exécution et de restitution
Les tâches du Report Engine
Un rapport BIRT change de peau tout le long de son cycle de vie. Je parlais plus haut de .rptdesign et de .rptdocument, il s’agit de deux types de fichiers manipulés par BIRT à différentes phases du cycle de vie d’un rapport. Tout part d’un fichier XML généré par le Report Designer ou par développement via la DE API (Design Engine API) : le Report Design, qui porte l’extension .rptdesign. Ce fichier contient, sous forme de balises XML, tous les éléments nécessaires à la construction du rapport (datasources, datasets, éléments graphiques, scripts…etc.) et sera exploité par le Report Engine pendant les phases de « Generation » et de « Presentation » dans des tâches ou « Tasks ».
En fonction de la tâche appelée et exécutée par le Report Engine, un fichier .rptdocument poura être généré à partir du .rptdesign. Il s’agit d’un cliché des données du rapport qui pourra être persisté ou utilisé pour exporter le rapport sous différents formats (PDF, HTML…etc.).
Un .rptdesign peut être exécuté et restitué à la volée (sans passer par un .rptdocument) par la tâche RunAndRenderTask. Même si cela est gourmand en ressources, cette démarche est nécessaire dans une application d’indicateurs temps réel, dans laquelle il faut s’appuyer sur les données présentes en base à chaque restitution demandée par l’utilisateur. Par contre, le passage par un .rptdocument est intéressant lorsque cette contrainte temps réel n’est pas obligatoire. Dans une application de reporting mensuel par exemple, où typiquement, un batch passe une fois par mois pour générer un .rptdocument à partir d’un .rptdesign. Le document est stocké et utilisé par le Report Engine dans une tâche RenderTask (ou DataExtractionTask pour un export CSV) à chaque fois qu’un utilisateur désire sortir le rapport de tel ou tel mois dans le format de son choix.
BIRT Scripting
J’ai parlé dans le paragraphe consacré au Report Designer des possibilités de scripting dans BIRT et je disais que ces fonctionnalités sont basées sur le moteur Mozilla Rhino. Donc je peux écrire des scripts dans mes rapports et ces scripts seront exécutés sur le serveur (Server Side Scripting); Chouette! Mais à quel niveau du cycle de vie du rapport mes scripts sont exécutés, dans quelle phase et dans quel ordre?
Je reprends le schéma des phases du Report Engine en introduisant la notion d’Events (JavaScript Events et Java Events).
Modèle d’évènements
Pendant les phases de génération et de présentation, le Report Engine déroule un certain nombre d’évènements sur les différents objets du rapport. Ces événements sont déclenchés dans un ordre bien précis et correspondent plus ou moins au cycle de vie de l’élément (ou de l’objet) concerné. Les propriétés de l’objet peuvent alors être modifiées via des Event Handlers codés en JavaScript ou Java (uniquement dans le Designer Eclipse pour le langage Java). Un point de plus pour BIRT : ces scripts peuvent être débuggés dans le Designer Eclipse.
Les propriétés disponibles en modification dépendent de la phase exécutée par le Report Engine (Generation Phase ou Presentation Phase) et de l’objet manipulé lui-même. Mais on peut imaginer les possibilités quasi illimitées.
Récupérer un objet dans mon rapport et manipuler ses propriétés… Ce principe ne vous rappelle pas celui du DOM? Récupérer en JavaScript un élément dans ma hiérarchie HTML et jouer avec ses attributs, ou encore récupérer en Java ou n’importe quel autre langage un élément de ma hiérarchie XML. Et là vous vous rappelez que je disais plus haut qu’un rapport BIRT (un .rptdesign) est un fichier XML. Bingo! Laissez moi vous présentez le Report Object Model aka le ROM.
Anatomie d’un rapport : Le Report Object Model
Tous les éléments d’un rapport peuvent être manipulés mais aussi étendus à tout moment, allant des étapes de construction jusqu’au rendu via une hiérarchie d’objets ou d’éléments de rapport à la manière d’un document XML. Cette hiérarchie constitue le modèle du rapport : Le Report Object Model ou ROM avec un modèle d’évènements propre à chaque élément du ROM.
Pour finir cette première partie, retenez bien cette équation : {ROM + Event Model + BIRT APIs} ou comment tout faire à tout moment dans un rapport.
