Surveiller ce forum | Commencer une nouvelle discussion

Hiérarchisé À plat Fils de discussion Ultime

Montrer 25 Montrer 50 Montrer 75 Montrer 100

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-03-23 14:38

[forum:52590]

Mes remarques, rapidement : - ok pour "frameworker" plus avant le BirtWrapper avec des pools de tâches, - ok pour mettre la conf dans un ficher de propriétés comme pour le JdbcWrapper. Attention au format du fichier de propriétés : il ne me semble pas pertinent de lier la configuraition du ActionHandler aux rapports. Le plus utile me semble de proposer plusieurs configurations du BirtWrapper, qui correspondent à plusieurs pools de tâches. Quand on initie une tâche, on pourrait préciser dans quel pool piocher (comme pour le JdbcWrapper), indépendamment du rapport à exécuter : on pourrait ainsi avoir un pool pour les utilisateurs "physiques", un pool pour les batches, un pool pour les utilisateurs "middleware" etc. sans devoir répéter les définitions de rapport. La liste des rapports dans le fichier birt.properties me semble d'ailleurs peut-être de trop. Il faut en tous cas pouvoir créer une tâche en fournissant directement le contenu du fichier .rptdesign dans un InputStream (qu'il soit lu sur le disque, en base, généré à la volée ou autre), en plus de la possibilité d'utiliser une clé pour identifier le rapport comme dans la proposition. Je propose aussi de rendre paramétrable les classes qui implémentent les interfaces ActionHandler et ResourceHandler : (nom du pool).actionHandler.className=... (optionnel) (nom du pool).actionHandler.propriété1=... (propriétés de la classe choisie) (nom du pool).actionHandler.propriété2=... pour la classe GramHtmlActionHandler (à renommer, voir plus bas), le plus simple serait d'utiliser des url avec des variables : (nom du pool).actionHandler.className=acube.birtwrapper.GramHtmlActionHandler (nom du pool).actionHandler.drillDown=http://...?ID=$(ITEM_ID) (nom du pool).actionHandler.drillThrough=http://...?REPORT=$(REPORT)&$(PARAMS) Plutôt que de faire des copies des Gram*Handler, les renommer. Ceci dit, comme elles restent très liées aux actions Gram (les paramètres sont encodés dans l'url, qui est ensuite relue par l'action GRaM), je ne sais pas si c'est une excellente idée. Les implémentations par défaut devraient être complètement neutres : par exemple, remplacer les url pour les images et les actions par "#" (une url qui ne fait rien). De toute façon, elles ne sont utilisées qu'en mode HTML, et je ne vois pas comment utiliser ce mode indépendamment d'une couche client (GRaM, par exemple), qui utilisera forcément son propre jeu d'URL. Pour chipoter : la propriété "stop" ne devrait-elle pas s'appeler "stopped" ? "isStop", ça me choque un petit peu :) Qu'en pensez-vous ? BL

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Xavier PRINCE on 2007-03-15 10:35	[forum:52564]
Une note rapide contenant la spécification des évolutions que nous nous proposons de faire est à présent disponible dans les features.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Cyril Rocheteau on 2007-03-15 10:16

[forum:52563]

Nous avons fait une rapide évaluation de BIRT en deux temps : - une vue d’ensemble de BIRT - puis une évaluation par rapport à deux projets Acube. Voici un petit CR. Sur la solution : Il serait intéressant d’évaluer BIRT conjointement avec les solutions complètes d’Actuate (www.actuate.com), la société à l’origine du projet BIRT. Sur la productivité : - la création de rapports simples, comportant des tableaux avec tri et regroupements, via l'interface wysiwyg est réellement plus productive que l'adaptation d'un fichier word ou excel au format HTML dans une feuille xsl. - on peut passer beaucoup de temps à se rapprocher du rendu demandé par la MOA, qui est souvent du sur-mesure, non réutilisable (donc pas d'amortissement de l'effort fourni) Sur la maintenabilité : - un rapport BIRT est beaucoup plus maintenable qu'un document word/excel html (où on doit synchroniser les changements avec la feuille xsl) Sur les performances : - BIRT n'est pas capable de construire une requête SQL optimisée pour le filtrage, les tris et les agrégations. Ces opérations sont effectuées en java, après récupération des données, d'où une consommation de mémoire potentiellement élevée ou un temps de génération plus long. Par contre il est possible de fournir une requête SQL lors de la construction du dataset, mais toutes les opérations seront figées. Sur la volumétrie : BIRT gère bien les documents volumineux, et ne nécessite pas de contournement contrairement à FOP pour éviter une consommation mémoire excessive (ex. nb de page total – référence arrière). Sur les besoins utilisateurs : -Il est parfois difficile, voire impossible, d'obtenir le même rendu que certains documents demandés par la MOA. Du moins à partir de l'interface wysiwyg (qui est le principal intérêt de BIRT). Exemple 1 : BIRT gère les regroupement dans un tableau unique, or nous avons un exemple de rapport possédant une structure arborescente, avec un tableau différent pour chaque rupture, ce qui donne schématiquement cette structure : + Titre Groupe1 +Titre Groupe2 Tableau +Titre Groupe3 Tableau Exemple 2 : Rapport Excel : BRIT peut créer un rapport csv. Cependant la plupart des exports exigeaient le rappel des critères saisis dans l'interface. De plus le format csv ne contient aucune information de style. -Pas de génération Word ou Excel, même au format HTML Microsoft comme utilisé dans Acube avec les transfo xslt.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-03-02 20:36

[forum:52553]

Effectivement, il faudrait modifier légèrement la classe BirtWrapper pour pouvoir à la fois : 1) créer facilement des instances configurables indépendamment (sur le modèle du JDBCWrapper), pour pouvoir générer des rapports indépendamment de GRaM (avec des jobs Quartz ?) 2) garantir que ces instances utilisent la même instance de BIRT -- la plateforme OSGi fait certainement le gros du travail sur le sujet, mais il reste quelques détails à vérifier. 3) généraliser les "catch" pour rattraper toutes les erreurs : BIRT ne renvoie pas d'erreurs typées, il faut donc s'attendre au pire dans le wrapper, quitte à en rattraper un peu trop (les RuntimeException) Il faudra s'assurer qu'on conserve bien une utilisation complètement "intégrée" avec GRaM, pour les utilisations standard (chargement d'un rapport, choix des paramètres et affichage du résultat avec le client ACube) : un unique fichier de config pour définir la liste des rapports et les droits associés. Les paramètres techniques de BIRT (paramétrage des ActionHandler et ImageHandler), qui sont aujourd'hui dans le même fichier, pourront être mis dans un fichier séparé, pour autoriser le paramétrage de plusieurs instances (cf point 1). Le fichier de GRaM se contenterait alors de faire référence à l'instance définie dans le fichier de configuration "technique". Un point important dans l'architecture de GRaM est son indépendance vis-à-vis de l'outil de génération de rapport (BIRT, Reporting Services, JFreeReport ou autre), : il faudra s'assurer qu'on peut toujours utiliser le SSRSWrapper fourni en changeant simplement de configuration. Il faudra donc refaire un gabarit complètement fonctionnel autour de GRaM. Sur la gestion du pool d'exécutions BIRT : c'est une très bonne idée, il faut à mon avis proposer deux modes, un "synchrone" et un "asynchrone" : dans le premier cas, on fait attendre le thread jusqu'à ce qu'une exécution se termine, et dans le deuxième cas, on renvoie immédiatement une erreur.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Xavier PRINCE on 2007-02-28 03:21	[forum:52543]
Comme convenu, nous avons placé un post contenant nos remarques concernant la mise en place d'un intégration BIRT dans le Framework J2EE ACube et la mise en oeuvre d'une application métier GRaM de gestion de rapport. Sur les différents points nous sommes prés dès maintenant à approfondir les spéfications pour appel à commentaire avant d'entamer la facon de réalisation.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Xavier PRINCE on 2007-02-28 03:19

[forum:52542]

Après avoir analysé ce qui a été fournit par Benjamin est qui donne déjà une très bonne première base. Nous avons constaté les points suivants : - il semble important de bien dé corréler la partir GRaM qui sera une application en soit intégrable et interrogeable depuis d'autre application d'une couche Frameworkisé d'appel à des outils de génération de rapports. - pour la partie Framework de gestion des appels à la génération de rapports BIRT, nous avons identifié plusieurs points : - la refonte de la gestion de la déclaration de l'Engine BIRT qui est un singleton, - la refonte de la gestion des erreurs, - la mise en place d'un système de gestion des tâches permettant de limiter le nombre de rapport simultanée gérer par BIRT, ce qui n'est pas actuellement prévu. Cette limitation est d'autant plus importante sur un environnement internet ou un trop grand nombre de demande de rapport simultanée pourrait créer un débordement sur le nombre de thread java. De plus, pour permettre de rendre le Framework BIRT utilisable en dehors de tout contexte GRaM. Il faut pouvoir appeler, de facon plus standard (même mode que le SGBDWRapper), au sein d'un delegate le BIRTWrapper. Cette mise en place n'empêchant en aucun cas de conserver dans le cadre de GRaM la génération d'un delegate via le fichier de configuration GRaM)

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Xavier PRINCE on 2007-02-28 03:04	[forum:52541]
Je pense aussi que la solution est celle offrant le plus de possibilité dans le cadre d'une infrastructure de SI urbanisé

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Arnaud MAZIER on 2007-02-10 13:10

[forum:52485]

La production de rapports actuellement est très cohérente d'un point de vue architectural dans ACube. Elle manque néanmoins de productivité et de facilité de développement. Des discussions internes au ministère des Affaires étrangères, il ressort que nous souhaiterions améliorer et simplifier la gestion des rapports du fwk J2EE au plus tôt. Cela nous semble également fondamental de trouver une solution qui corresponde aux besoins de la communauté. Nous vous proposons d'échanger dans ce forum et d'y recueillir toutes les propositions ou orientations afin que nous revenions vers la communauté avec une proposition de spécifications (les propositions de Benjamin sont déjà une quasi-solution ??) début mars 2007 suivie d'un appel à commentaires pendant 15j. Qu'en pensez-vous ?

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-29 17:03	[forum:52460]
Les sources sont dans le feature request. Les JARs font une archive trop volumineuse pour être uploadées, désolé : il faut compléter avec les JARs ACube, et les fichiers du viewer web BIRT (contenu de /WEB-INF/lib et /WEB-INF/platform)

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-25 19:59

[forum:52454]

A minima (execution de rapports livrés dans le war, pas de déploiement à chaud) : Dans la partie client : - une page HTML et un JS pour la visualisation (définition des paramètres et navigation) - les URL génériques qui vont bien (moins d'une dizaine) Dans la partie serveur : - un repertoire /WEB-INF/reports pour stocker les rapports - un fichier reports.xml qui définit la liste des rapports, leurs noms et les droits associés (au même endroit ou ailleurs), - un paquet de JAR et un runtime OSGI (dans /WEB-INF/platform) pour BIRT - des classes pour GRaM (frontière à définir entre le framework et le gabarit) - une balise <plugin> dans struts-config pour initialiser GRaM (lecture de reports.xml etc.) - une feuille de style pour les paramètres avec la définition dans strutscx-config.xml, ou un fichier dictionnaire pour StrutsACube A ajouter aux fichiers de conf : les URLs pour les actions GRaM et la page cliente, le code Javascript à appeler en cas d'action utilisateur sur un rapport (drill up, drill down, drill through etc.) Ca pourrait faire l'objet d'un fichier de configuration séparé (pas reports.xml, qui doit être transitoire en attendant de stocker les rapports dans une base et de gérer les droits avec une interface ACube) J'en oublie sans doute. Mais le principal est là. Par contre, je ne vois pas de tache Ant sur le sujet. Je posterai un "gabarit" dans le feature-request un de ces jours. A maxima, en plus des points précédents : - d'autres pages HTML et JS (gestion des fichiers, gestion des droits, gestion de l'arborescence) - plein d'actions Struts en face - de la conf pour le stockage des rapports et des droits en base

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Thierry RIGAL on 2007-01-25 13:06	[forum:52453]
quelles sont les modifications du GabaritProjetJ2EE à prévoir (package java supplémentaire, fichiers de conf, tâches ant, propriétés, fichiers statiques html ou autre) ?

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-23 19:30

[forum:52449]

J'ai mis dans le feature-request des documents de présentation d'une proposition d'architecture de GRaM, avec un diagramme de flux pour expliquer précisément ce que fait chaque brique. Pour résumer, il y trois parties distinctes : le front-end (actions Struts + classes qui génèrent des URL vers ces actions pour les images et les interactions), le Delegate (règles métier, filtrage des paramètres etc.) et le backend (interface standard pour un service de rapport, avec des implémentation pour Reporting Services, BIRT etc) Le front-end est plutôt du domaine du gabarit (pages client+classes Java), réutilisables telles quelles dans la plupart des cas (ie tous sauf pour les clients autres que ACube). Le delegate est à implémenter en surchargeant/remplaçant une version par défaut pourrait être proposée (persistance en JDBC + pas de règle métier spécifique). Le backend est technique, donc dans le framework. Le diagramme des flux précise le rôle de chaque partie : 1) à l'initialisation du rapport (avec loadReport), le backend crée un "contexte d'exécution" qui encapsule toutes les actions liées au rapport : liste des paramètres, définition des paramètres, exécution dans divers formats, drill up/down etc. Nota : cette notion est claire dans Reporting Services, pas dans BIRT. Ce contexte serait placé dans la session, en lui donnant un identifiant pour le récupérer (si on navigue entre rapports, on veut pouvoir revenir sur un rapport précédent, donc il faut conserver les différents contextes) 2) toutes les opérations clientes font référence à cet identifiant, et appellent la méthode correspondante du contexte d'exécution. 3) pour la production de rapports HTML, les images et actions utilisateur (liens, drill up/down) sont implémentées par des URL. Les deux classes ActionHandler et ResourceHandler créent les URL à partir de la définition des images/actions. ActionHandler se contente de créer une URL, mais ResourceHandler doit stocker la ressource (l'image) avant de renvoyer une URL. Le plus simple me semble encore une fois de le mettre dans la session et de lui donner un identifiant unique pour y accéder ensuite. Ces deux notions sont claires dans BIRT, mais pas dans Reporting Services : il faut scruter le HTML renvoyé, trouver les URL, les décoder et les remplacer... mais ça marche à la fin. 4) pour le PDF, pas de problème, on récupère un flux directement. Je termine une première implémentation et je la poste. En attendant, tous les commentaires sont les bienvenus.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-22 16:48

[forum:52432]

Sur l'interopéraibilité portail/application (ie accès à des rapports d'une application via un portail transverse), je vois plusieurs solutions : 1) publier et gérer les rapports sur les deux "sites" en parallèle, en utilisant des sources de données qui pointent vers la même base. Avantages : simplicité, sécurité sur-mesure. Désavantage : en cas de maintenance, les opérations sont à faire en double. Attention : avec BIRT, voir la possibilité de définir des sources de données partagées (c'est possible en utilisant JNDI, mais il faut modifier la configuration du portail à chaque nouvelle application) 2) laisser l'application gérer ses rapports, et y donner un accès à travers le portail. Avantages : maintenance réduite au minimum. Désavantage : besoin du SSO pour interroger directement l'application depuis le portail. 3) publier les rapports dans l'application, et gérer les accès aux deux endroits séparément. Avantages : maintenance réduite (l'upload et la MAJ des rapports sera mutualisée), sécurité sur-mesure. Désavantage : interface plus complexe à définir entre le portail et l'application. 4) publier les rapports hors de l'application, sur un serveur spécialisé, et y accéder à travers un service web. Avantages : mutualisation des ressources (hébergement des rapports de plusieurs applications), gestion plus rationnelle des droits applicatifs. Désavantage : complexité, un "serveur" de plus à administrer. Personnellement, je pense que le numéro 2 est préférable.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Steve PEGUET on 2007-01-18 12:26

[forum:52427]

Quelques éléments de réflexion sur le sujet pour faire avancer le débat. Point de vue fonctionnel sur l'objectif de GRaM : 1/ D'accord sur le principe que son objectif est bien de fournir une interface générique pour accéder à des rapports cliquables avec ou sans paramètres avec export PDF et CSV. Son corollaire est bien donc de soit ajouter GRaM dans une application existante pour fournir des rapports dans la sphère métier de l'application (aide à la décision dans un processus métier, reporting lié aux fonctionnalités dans l'application) ou dans une notion de portail de rapport. La problèmatique de gestion de droit dans chacune de ces deux sphères est un des coeurs du sujet d'où l'intérêt que GRaM soit vu comme un framework plugable dans une application (métier ou portail) proposant sa propre gestion de profil sur ces rapports et droits associés. 2/ Pouvoir utiliser indifféremment BIRT ou Reporting services pour produire ces rapports d'une manière transparente dans l'interface génrique d'un point de vue utilisateur. Son corollaire est bien de préférencier BIRT pour des rapports issus de base de données applicatives et Reporting Services pour des rapports issus d'un cube ou datamart. Par contre la consultation des rapports peuvent être accéder et publier indifféremment dans un portail ou dans une application dédiée. Ceci permet ainsi d'éviter de donner l'accès à un décideur à une application métier juste pour accéder à des rapports importants pour lui. Exemple : Rapport de gestion des stocks d'imprimés nationnaux pour la délivrance des passeports, visas, passeports d'urgence et laissez-passer réalisés dans les applications correspondantes avec BIRT. Rapport d'activité des postes dans la délivrance des passeports, visas, passeports d'urgence et laissez-passer réalisés par Reporting Services. Il peut être intéressant que ces deux rapports soient dans les applications correspondantes pour les agents utilisants ces applications limités au seul poste dont ils sont issus pour voir leur activité et l'état des stocks en cours. Il peut être intéressant que ces deux rapports soient fournis dans un portail indépendant de l'application pour des décideurs qui désirent benchmarker l'activité des postes ou le responsable du renouvellement des stocks d'imprimés nationnaux pour relancer et envoyer de nouveaux imprimés. Point de vue technique : 1/ Ok pour préférencier un équivalent light du FileWrapper et JDBCWrapper à fin d'avoir une rationnalisation de fonctionnement avec Reporting Services. 2/ GRaM doit être un framework mutualisé pour intégration dans une application (métier ou portail) incorporant BIRT ou Reporting Services pour permettre une évolutivité des besoins. 3/ Pas de service web pour BIRT mais bien une intégration dans l'application par contre avec possibilité de rechercher le rapport d'una application dans un portail à l'aide du HTTPWrapper. Voici quelques premiers avis sur le sujet certainement à débattre. Steve.

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-15 22:51

[forum:52421]

Pour la compatibilité avec plusieurs back-ends : bien sûr, c'est déjà le cas, un simple fichier de config permet de changer d'implémentation (Reporting Services, Birt ou autre). Pour les sources, c'est un peu gros pour passer dans un forum... et avant de le mettre sur un CVS il faut en faire une version présentable, c'est-à-dire "minimale" et facile à installer -- aujourd'hui, GRaM est trop ciblé MAE, et toutes les docs font référence à Reporting Services. L'idée du message est bien d'échanger sur les desoins en matière de "reporting" pour cadrer les (re)développements de GRaM. En attendant, les sources sont dispo pour qui veut dans mon bureau :)

RE: Production d'états - Integration de BIRT [ Répondre ] Par : Steve PEGUET on 2007-01-15 19:14	[forum:52420]
Tout ceci est une approche fortement intéressante mais je pense que pour que la communauté puisse avoir toute la visibilité, il est nécessaire de fournir des informations complémentaires sur GRaM avec les sources de son implémentation. Merci d'avance. Sinon l'approche semble vraiement prometteuse mais est-ce que ce serait possible d'avoir un GRaM compatible BIRT et Offre BI SQL Server 2005?

Production d'états - Integration de BIRT [ Répondre ] Par : Benjamin Leperchey on 2007-01-15 18:26

[forum:52417]

La production d'états imprimables n'est pas le point fort d'ACube... J'ai réalisé un prototype de back-end de GRaM --Gestion de Rapports Mutualisée-- développé à l'origine pour SQL Server Reporting Services, qui utilise BIRT, la plate-forme intégrée à Eclipse de création et de rapports. Le point positif, c'est que ça marche sans problèmes et sans devoir faire de bidouilles invraisemblables, en intégrant BIRT directement à l'application. Pour info, j'ai réutilisé à 90% le code Java de GRaM (qui était, c'est vrai, conçu pour être multi-backend) Bénéfice pour le développeur : une plateforme de développement de rapports en WYSIWYG. Les fonctions avancées se scriptent avec Javascript, avec ajout/modification de rapport à chaud et définition de la navigation dans les rapports au sein de l'application. C'est plus intéressant pour un portail décisionnel (c'est la cible d'origine de GRaM) que pour une appli de gestion, mais c'est gratuit. Le bénéfice pour l'utilisateur, c'est une interface générique pour accéder à des rapports "cliquables" (navigation, éléments affichés/cachés, liens vers d'autres url etc.) avec ou sans paramètres, avec export PDF et CSV (Excel formaté pour le back-end MS Reporting Services). Le point à creuser, c'est la consommation de ressources : en gros, on démarre une plate-forme Eclipse dans Tomcat... Pour info, Tomcat après que BIRT est lancé occupe 90 Mo, alors qu'avec le back-end Reporting Services (simple client Axis du service web Microsoft), il en occupait plutôt 50 -- mais on doit pouvoir limiter la casse, voir plus bas. Par contre, la consommation CPU semble très raisonnable : le démarrage est franchement long (une grosse minute en mode debug, 10s sinon), mais après ca va : pas d'impact sur le fonctionnement par ailleurs de l'application, et environ une demi seconde pour rafraîchir un rapport dynamique (tout ça sur mon PC) Si la consommation de ram est rédhibitoire, il faudra orienter vers un service web mutualisé mis en commun entre les différentes applis ACube, éventuellement sur un serveur dédié. Mais c'est *nettement* plus compliqué à mettre en oeuvre (développement d'un service web et d'un clent en plus du développement spécifique), et ça complique pas mal le schéma et la configuration de l'ensemble (en particulier pour le passage dev/prod). Embarquer BIRT et GRaM dans une appli ACube, ça pourrait à terme se limiter à ajouter : - quelques tables au modèle de données (pour GRaM, et eventuellement le stockage temporaire de BIRT), - quelques jar à WEB-INF/lib : une pour GRaM, une pour le back end BIRT (ces deux jar restent à faire) et une quinzaine pour BIRT, - quelques actions pour GRaM -- à reprendre telles quelles ou à customiser, - un bon gros fichier de configuration pour GRaM (tables, back-end etc) - un repertoire WEB-INF/platform avec les plugins OSGi nécessaires à BIRT (vérifier si c'est indispensable et ce qu'il faut y mettre) - quelques pages client standard. Quand même. Pour relativiser, avec un gabarit bien fait, il n'y aurait rien à faire d'autre que les tables et modifier ce qui les concernent dans le fichier de configuration. Si on s'oriente vers l'option "instance unique de BIRT en service web", on enlèverait WEB-INF/platform et les jars pour BIRT. Les points à étudier plus en détail : - GRaM permet de gérer à travers une interface ACube les fichiers de définition des rapports, ce qui permet l'ajout "à chaud" de nouveaux rapports. Reporting Services embarque son propre filesystem dans une base de données. Pour BIRT, on peut soit utiliser un répertoire de WEB-INF, soit faire un équivalent light avec le FileWrapper et le JDBCWrapper. La deuxième solution me semble préférable, pour un temps de développement somme toute raisonnable (quelques jours, vu les fonctions nécessaires). - il faut dégraisser au maximum la plateforme OSGi embarquée. En particulier, elle embarque par défaut une base de données Apache Derby (connaissait pas) qui ne sert que pour les exemples. A creuser. - le stockage des fichiers temporaires (images en mode HTML) est pour l'instant fait dans la session, ce qui accroît encore un peu la consommation de mémoire... On pourrait là encore s'orienter vers un stockage en base. En limitant la durée de vie des images qui par ailleurs ne sont pas grosses (quelques ko en général pour les images générées), ça devrait suffire. - accès à la base de données : pas de sources de données réutilisables, chaque rapport embarque les informations de connexion au SGBD. On peut utiliser JNDI, et donc passer de façon transparente de l'environnement en dev à la prod *tant que BIRT est embarqué*. Si on en fait un service web, on risque d'avoir un problème. BIRT 2.2 (prévu pour juin) devrait permettre les sources de données partagées, mais bien malin qui saura lui demander d'aller la chercher dans une base de données si on fait un filesystem avec JDBCWrapper... - découper GRaM, aujourd'hui simple application ACube, en morceaux réutilisables ou pas. Qu'en pensez-vous ?