Problème de génération de rapports BIRT sous PDF

Bonjour,

Je travaille sur une application de transport (Infolog TMS) qui génère, à la demande, des documents via Birt et en .pdf.

La plupart du temps cela fonctionne correctement mais dans certains cas j'ai les rapports qui sortent vide et avec le masque tronqué (sans le masque du rapport : voir document joint). La plupart du temps en relançant le rapport une deuxième fois il sort correctement.

Quelqu'un a t'il déjà rencontré un problème identique ? Avez vous une idée sur la source possible de ce problème.

Merci de vos réponses.

Là tu nous donnes vraiment très peu d'éléments :? C'est sur le web viewer ou une appli maison? Le problème se produit il aussi dans le RCP designer? Que dit le log du Birt Engine quand le problème survient?

Birt est lancé via une application de gestion de transport (application de l'éditeur Infolog (Generix Group)). Birt est installé sur le serveur où est installé cette application ==> les rapports pointent sur une base DB2 As400.

Les rapports sont appelés à la demande via l'application de transport et sont lancés via un fichier reportconfig.xml avec des lignes de ce type :

Code:

---

1 2 3 4 5

<report name=".PACKING_LIST_WMS_NEW_PICKING" pdf="Deret_PackingList_Wms_New_Picking.rptdesign" > <parameters> <parameter name="code" type="N"/> </parameters> </report>

---

Le problème étant aléatoire je n'ai pas eu le cas avec le designer mais peut être est ce un hasard...(?)

Les logs que j'ai au niveau de mon applicatif me disent que le rapport a bien été lancé :

2012-03-26 09:13:12,922 INFO report.journal Rapport chargé : E:\infolog-solutions\TMS\infolog-report\reports\Deret_PackingList_Wms_New_Picking.rptdesign

Au niveau du report engine j'ai ce genre de message mais tout le temps et cela ne semble donc pas bloquer :

26 mars 2012 09:04:44 org.eclipse.birt.report.engine.layout.pdf.font.FontMappingManager createFont
ATTENTION: Identity-H

Cela peut concerner tous les rapports ou uniquement un ou deux rapports précis? Quelle est la version de Birt utilisée par l'appli? As tu déjà rencontré ce problème en travaillant seul sur un serveur de dév? Vu les symptômes et l'aspect aléatoire je mettrais quand même une grosse pièce sur un problème lié au parallélisme. Pas forcément systématiquement dés que plusieurs rapports sont lancés en même temps, mais de manière plus insidieuse, par exemple le même rapport et les mêmes paramètres lancés en même temps sur 2 postes.

Note bien que le moteur Birt en lui même supporte parfaitement un parallélisme massif, il est fait pour ça, en revanche les applications qui l'utilisent peuvent ne pas être "thread-safe" dans les sessions ou sur les entrées/sorties: des rptdocument qui s'écrasent mutuellement, des paramètres inversés etc.

Essaie d'écarter cette hypothèse en reproduisant le problème en contexte mono-utilisateur. Si c'est possible tente aussi de faire passer l'application à la version la plus récente de Birt, au moins pour des tests.

A+

Merci de tes réponses rapides.

Deux rapports précis sont concernés. Les requêtes de ces deux rapports ont la particularité de pointer sur une autre base DB2 que les autres.

La version de Birt designer est la suivante :
Version: 2.2.0.v20070604-7U7U-C-Qc-5jcp_VXDWwz-63
Build id: v20070626-0630

Pas de problème sur le serveur de dev, du moins pas reproduit. Ce problème intervient environ 5 à 6 fois par jour (sur une centaine de rapports édités environ).

J'avais déjà creusé la piste du parallélisme et les utilisateurs me confirment ne pas lancer deux fois le même rapports sur des sessions différentes.

C'est quand même difficile d'être certain que 2 utilisateurs différents ne lancent pas des rapports au même moment. J'insiste un peu car c'est à mon sens la cause la plus vraisemblable.

Sinon tu peux vérifier le log DB2 de la base de ces 2 rapports, ainsi que le nombre de connexions concurrentes autorisées dessus, mais à mon avis ce n'est pas la bonne piste je ne vois vraiment pas quelle genre d'erreur du SGBD pourrait ne pas être tracée dans le log du moteur Birt.

Je pense que le seul moyen de mieux qualifier le problème est de logger des informations à l'intérieur des 2 rapports: par exemple dans les évènements beforeFactory et beforeRender du rapport, logger les valeurs des paramètres et le nombre de lignes du dataset principal. Je n'ai malheureusement pas d'autres suggestions à faire!

A+