Discussion :

[rvwhiti]

Bonjour,

Hypothèses:
- Soit un rptdesign avec un main report et un sub report
- Le main report est constitué d'une table affichant 4 champs. Ces 4 champs proviennent d'une bdd. Le data set associé ne récupère que ces 4 champs texte.
- Le sub report inclus dans la table du main report est aussi constitué d'une table affichant 5 champs texte. Le data set associé ne récupère que ces 5 champs texte.
- Pour chaque ligne du tableau du main report, le sub report est constitué d'une seule ligne de données.
- Le rptdesign n'est constitué que des ces deux tableaux.

Scenario:
- Exécution du report pour une requête ramenant n lignes, n lignes prenant les valeurs 500, 6500 et 21000.

Taille des fichiers générés:
- pour 500 lignes:
rptdocument à 14 Mo pour 10 pages dans le viewer
export .doc: 3,25 Mo pour 39 pages dans Word
- pour 6500 lignes:
rptdocument à 195 Mo pour 132 pages dans le viewer
export .doc: 44 Mo pour 526 pages dans Word
- pour 21000 lignes:
rptdocument à 636 Mo pour 429 pages dans le viewer
export .doc: 144 Mo pour 1714 pages dans Word
J'ai aussi effectué des exports pdf: il faut compter 2,5 Mo pour 200 pages (même nombre de pages que dans le viewer): beaucoup plus léger et admissible.

Questions: pourquoi les rptdocument générés sont-ils si conséquents ? est-ce que cela vient du rptdesign mal designé (je peux le fournir) ? Problème identifié ? Mêmes questions pour les .doc

Bonus: Pour les .doc générés, si je les ouvre avec Word, insère un espace puis le sauvegarde, la taille du document est divisée par trois. Un commentaire ?

Merci pour vos commentaires (et la patience d'avoir lu ce post jusqu'ici ;-)

Remarques complémentaires sur les résultats d'exécution:
- Temps d'exécution très corrects quel que soit le volume (1'13 pour les 21000 lignes)
- Mesure effectuées avec le report engine 2.2.2 intégré à une servlet. J'ai ensuite effectué ces tests sur la 2.3.0 et enfin l'iserver 9.3 (intégrant report engine 2.2.2 je crois). Le report engine 2.3 divise les temps de réponse par 2 mais les fichiers générés ont la même taille. Le i server 9.3 ne change rien en temps de réponse et en taille de fichiers générés.

[Stefan C]

Bonjour,

BIRT c'est XML. Implictement c'est pas fameux pour le rendement des stockages des données , particulièrement si le nombre d'éléments imbriqués est grand. Ceci dit , je vais investiguer car ces tailles me paraîssent un peu grandes.

Disons tout simplement que les choses très imbriquées nuisent généralement à tout outil basé XML car ça augmente la complexité de son schéma.

Si un simple tableau génére un schéma XML à 10 lignes par exemple , 2 tableaux imbriqués vont générer plus de 20 ( car 10 lignes de 1 pour chaque ligne de 2 ). L'utilisation des tableaux imbriqués est donc à conseiller seulement quand vous ne pouvez pas utiliser les groupes dans un seul tableau.

Pour les emitters office , BIRT utilise des emitters vers le format XML de Office ( pour la facilité ), donc c'est le même problème que le rptdocument. Une fois le document ouvert avec Office et sauvegardé ( même sans espace ) , la taille est généralement diminuée sensiblement car Office utilise la compression depuis 2003. Et justement BIRT c'est conçu sur la base de Office 2003 et supérieur mais ne peut utiliser la compression ( propriétaire d'une version MS donc ça rendrait l'emitter non générique )

Si un rendu Excel / Word plus petit est souhaité vous avez 2 choix :

a). Utiliser les emitters Tribix pour BIRT , c'est moins stable mais ça exporte vers un format Office classique donc plus petit.

b) Utiliser l'export des données de BIRT ( CSV/TSV/PSV ) , mais vous perdez la mise en page.

b') Il existe un autre outil Actuate pour la génération d'Excel de masse : eSpreadsheet. Son intégration est payante mais il a une version engine pas chère du tout. Le designer est gratuit sur le site birt-exchange.com si vous voulez jeter un coup d'oeil. Les fichiers générés sont archi-optimisés, des fois même plus petits que le fichier Excel une fois sauvegardé. Compatible Excel 98 - 2007 , c'est fait pour :-)

Enfin , le Actuate iServer 9SP3 est surtout utile quand vous avez plus d'un seul rapport , pour paralleliser les tâches et augmenter les perfs globales , avoir un référentiel , sécurité ( AD / LDAP / RSSE / SSO ) , versioning , load-balancing , failover etc. Sinon , iServer 9SP3 inclut tous les engines de BIRT à partir de la 2.0 , donc il s'adaptera à la version du BIRT utilisée lors du design.

A votre dispo pour d'autres questions.

[rvwhiti]

Merci pour ces commentaires éclairés et éclairant
Sinon, concernant la suggestion sur les groupes à la place des tableaux imbriqués, je vais creuser cet aspect-là. Cependant, je crains que l'on perde en modularité, chacun des tableaux ayant son propre dataset.
Je ne ferme pas non plus le post en "résolu": le résultat de vos investigations m'intéresse !
a+