Interfaces applicatives avec OpenOffice.org Philippe Hemmel
Introduction De nombreuses applications métiers ont besoin de générer, voire lire des documents bureautiques (textes, classeurs) Bien souvent, elles ont résolu techniquement ce besoin par une interface avec MS Office peu d'applications génèrent nativement du.doc Comment assurer son remplacement par une interface avec OpenOffice.org? Le 3 février 2006, page 2
Quelques bénéfices Le 3 février 2006, page 3 OpenOffice.org peut offrir quelques avantages : Déploiement facilement généralisable (licence LGPL) Framework multi-plateforme (Linux, Solaris, Mac OS X, Windows...) Format de document natif XML Capacité à générer des formats multiples : OpenDocument MS Office PDF
Cas fonctionnels Usages les plus fréquents : Publipostage : génération de documents texte en série à partir de modèles et de données structurées Classeurs de données brutes, éventuellement mises en formes Moins fréquents : Génération de rapports (gestion des marchés...) Génération de graphiques Lecture de classeurs Le 3 février 2006, page 4
Remarques concernant le publipostage Impact du processus : qui créé les modèles, avec quel outil? Plus ou moins développé : champs conditionnel, publipostage secondaire... Objectif Génération de documents pour retouche manuelle Surtout impression De plus en plus, génération de fichiers PDF Le 3 février 2006, page 5
Architectures Application locale Application serveur 2 Application Visualisation Génération / visualisation 1 2 Application 1 2 Le 3 février 2006, page 6 Génération
2 grands types de solutions Utilisation de l'api OpenOffice.org (framework UNO : Universal Network Object) Génération directe d'un fichier OpenDocument Une nouvelle voie, rendue possible : par la normalisation et la pérennisation du format par l'oasis par l'utilisation de XML pour OpenDocument Le 3 février 2006, page 7
Solution API 1 : Framework UNO Modèle OOo Application Données composant UNO 1 OpenOffice.org 2 Langages : OLE automation (delphi, VB, python...) Java, C++ Utilisation possible de l'api publipostage Création des modèles par OOo Le 3 février 2006, page 8
Solution API 2 : Framework UNO serveur Application Données 1 Mode serveur possible Nécessité d'un serveur de traitement des requêtes pour prise en charge des requêtes des clients Modèle OOo Traitement des requêtes composant UNO OpenOffice.org 2 Le 3 février 2006, page 9
Solution API 3 : Macros OpenOffice.org Fichier CSV Modèle OOo 1 Application Données 2 2 OpenOffice.org Macro 3 Lancement OOo pour exécution d'une macro Fourniture des données par fichier texte formaté Langages : OOBasic Python JavaScript Le 3 février 2006, page 10
Solution OD 1 : création de fichiers OD Modèle OOo Données Application Création OD 1 Développement d'un outil complet de création de documents OpenDocument Éventuellement possibilité d'utiliser des modèles OOo et une méthode "Rechercher / Remplacer" Méthode XML Sax / DOM Quelques API de création de documents OOo existent : en PHP en Perl Le 3 février 2006, page 11
Solution 2 : scripts XSL Fichier XML Données Application 1 2 2 Moteur XSL Script XSLT 3 content.xml ZIP 4 Fourniture des données dans un format XML client Le script XSLT crée un fichier content.xml au format OpenDocument (OD) ZIP : fonction d'archivage pour création d'un fichier OD Le script XSLT correspond au modèle Le 3 février 2006, page 12
Création d'un modèle XSL avec OOoPubliXML Le 3 février 2006, page 13
Comparatif : points forts Le 3 février 2006, page 14 UNO Édition des modèles par OOo Modèle de développement (API) connu Création de fichiers OpenDocument Performances Édition des modèles par OOo XSL "Fusion" de classeurs (avec modèles et fichiers de données) facilement réalisable Bien adapté à une architecture serveur Édition des modèles avec OOoPubliXML
Points faibles Le 3 février 2006, page 15 UNO Apprentissage complexe Architecture complexe en mode serveur Performances (publipostage OOo) Création de fichiers OpenDocument Complexité du développement du moteur de création de documents Impression et création de PDF impliquent UNO XSL Complexe dans certains cas (application générique) Impression et création de PDF impliquent UNO
Conclusion La meilleure solution est variable Elle dépend du besoin fonctionnel du processus de création de documents (qui créé les modèles?) de l'architecture voulue Mais aussi des compétences acquises ou souhaitées des langages et systèmes utilisés des moyens d'accès aux données Le 3 février 2006, page 16