La guerre des générateurs de rapport aura bien lieu : rapide présentation du champ de bataille !

Pour ce premier billet, je souhaite aborder avec vous une question chère à tous nos clients actuellement : "Comment générer une édition (comme un courrier ou une facture) prête à être imprimée depuis une application métier ?"

Aujourd'hui il existe une multitude de solutions concurrentes et modernes pour répondre à cette problématique avec en règle générale une stratégie simple : "la solution retenue doit être cohérente avec la technologie de l'application métier ou du moins y être facilement intégrable". Sans être exhaustif, je citerai :

  • Sql Server Reporting Service sur technologie .NET ;
  • JasperReport côté Java ;
  • BIRT toujours côté Java ;
  • POI (et plus précisément HWPF pour la manipulation de documents Word) ;
  • Serveur Open Office ;
  • FPDF pour générer un PDF en PHP ;
  • Plus une longue liste d'API disponibles et plus ou moins performantes.

La liste est donc longue ... trop longue même ... chaque produit étant supporté par sa communauté.

Si on creuse un peu plus le besoin de l'utilisateur final, la question se complique encore un peu car la solution doit aussi :

  • S'appuyer sur un modèle comportant des zones dynamiques insérées entre des zones statiques ;
  • Permettre à un non informaticien de modifier ce modèle ou au moins les zones statiques de ce modèle.

Et c'est précisément ce deuxième point qui, assez rapidement, démontre les limites des solutions actuelles.

Ce cas concret (il fallait que je le place pour ce premier billet) a été rencontré récemment par une équipe NETAPSYS sur un projet Java / J2EE : la solution d'édition devait être capable de générer un courrier à partir d'un modèle RTF comportant des zones statiques, des zones dynamiques mais aussi des conditions d'affichage du type "si la victime est hospitalisée alors affiche l'adresse de l'établissement de santé".

Après plusieurs prototypes et quelques déceptions, l'équipe a finalement retenu le couple technique "RtfTemplate / Velocity" pour répondre à cette question.

Dans mes prochains billets, j'aborderai avec vous les points suivants :

  1. Description technique du prototype mis en place ;
  2. Avantages et inconvénients mis en évidence par ce prototype ;
  3. Retours d'expérience liés à la mise en œuvre de cette solution.

3 commentaires

  1. C’est dommage d’être resté côté API pour gérer des éditions. Il existe pourtant des sociétés spécialisées dans l’éditique. Pour n’en citer qu’une (et même si je trouve que leur solution technique n’est pas terrible), il y a StreamServe. En plus suivant le volume à réaliser, vous avez tout intérêt à sélectionner ce type de solution.

  2. Je partage votre vision concernant ce type de solution plus ou moins « clé en main » à paramétrer surtout quand le volume de document est important. Nous avons aussi creusé des solutions d’externalisation complète de ces éditions avec la gestion par un prestataire spécialisé. Par contre il faut toujours s’attacher à valider que la solution technique n’est pas intrusive par rapport au cadre normatif du client (en tout cas quand il existe !). Si vous souhaitez détailler un peu plus vos retours d’expérience sur ce type de besoin fonctionnel, n’hésitez pas à me le faire savoir : nous sommes toujours intéressés.

  3. Cette solution reporte une partie des contraintes du processus global (afficher à l’écran le document, protéger le document contre la modification, l’imprimer) sur le format RTF… Comment arrivez vous à l’imprimer en masse par exemple ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.