Solution de fusion côté serveur

[lbois]

Salut

je travaille sur l'architecture d'un système , qui permettrait la fusion de documents OpenOffice (données XML + Modèles OTT) coté serveur.

Actuellement , notre solution de fusion de documents s'appuie sur MS Office (avec fortes dépendances a Word 97) , piloté depuis un ERP maison (la fusion est faite au moyen de librairies OLE2 en PLSQL Oracle),et se fait coté poste utilisateur (l' ERP étant une application Client/Serveur).

L'idée générale est donc :
- Supprimer toutes dépendances à MS Office (OpenOffice étant la suite bureautique retenue pour l'avenir dans notre compagnie)
- Désolidariser la fusion de l'ERP Client/serveur, puisque nous nous orientons peu à peu vers du SOA avec des clients Web.

Mes considérations sont :
- le moteur serait logé coté serveur, exposant des interfaces (SOAP/REST) afin d'être piloté de facon remote (depuis un web browser ou mêmes des scripts sur une machine distante).
- Les modèles OOo pourraient être stockés sur un FileSystem ou dans un ECM ala Alfresco/eXo (avec partage WebDAV)
- les fichiers de données XML seraient construits à partir de requêtes SQL contre une base de données
- Le "delivery" des fichiers en sortie de fusion pourrait se faire sur un FileSystem, ou nu ECM (WebDAV).. on pourrait envisager un envoi par email , fax, printer à terme.

Pour le coeur du moteur de fusion, plusieurs solutions sont envisagées , sous réserve de leur faisabilité :
- Travailler directement sur le fichier content.xml du modèle OpenOffice OTT : ca me semble plutot ressembler à du hack, mais l'idée serait de dezipper le modèle, puis faire le recherche/remplace dans dans ce fichier content.xml file, puis rezipper vers un fichier ODT tout le contenu du OTT original, en incluant le content.xml mis à ajour. Cette solution permettrait aussi de ne pas dépendre du SDK OOo, ni d'une instance OpenOffice coté serveur, tournant en mode -headless.
- utiliser l'API OOo UDK depuis un programme Java , client d'une instance OpenOffice coté servezr : bootstrapper OpenOffice (headless) et envoyer les ordres UNO pour la fusion
- Considérer que le processus de fusion est fait dans OpenOffice (serveur) , soit au moyen de la fonction Publipostage, soit au moyen d'une Macro starbasic : le programme externe, aussi sur le serveur, lancerait l'exécution de la macro en passant en argument le fichier de données XML ainsi que le chemin d'accès au modèle OTT.

Enfin autour de ce module de fusion quelques briques :
- Module d'extraction de données depuis la base de données et formattage du XML
- Module pour récupérer les modèles OTT sur le filsystem ou depuis un share WebDAV
- Un module de delivery qui posterait le document généré vers le filesystem ou un share WebDAV
- des interfaces publiques sous forme de WebServices SOAP et REST

Créer le client web pour déclencher cette fusion à distance.

On pense aussi à l'éventualité de génération de documents en masse coté serveur : cela revient a avoir multiple records dans le XML, et générer un unique document ou plusieurs documents (un par record), et évidemment pouvoir les archiver sur Filesystem ou Share WebDAV

je voudrais savoir si parmi vous certains ont déja été face à cette problématique , si éventuellement des projets OpenSource existent autour d'une solution similaire avec OpenOffice , et parmi les solutions de moetru de de fusion envisagées ci plus haut quelle serait la meilleure stratégie (en considérant aussi les problèmes de performances et de montée en charge)

D'avance merci pour votre réponse

Laurent

[Pierre-Yves Samyn]

Bonjour et bienvenue sur ce forum

quelle serait la meilleure stratégie (en considérant aussi les problèmes de performances et de montée en charge)

Je dirais :

Travailler directement sur le fichier content.xml

et j'ajoute que :
- manipuler des fichiers xml ne me semble pas du hack
- le publipostage via OOo est trèèèèèèès leeeeeeeeeeeeeeennnnnnnnnnnnt

[Bidouille]

Bonjour,

Des termes comme "problème" ou "openoffice" sont bien sûr implicites et n'ont pas besoin d'être mentionnés.

J'ai déplacé votre question dans la section Projet car il ne s'agit pas à proprement parlé d'un problème spécifique de fonctionnement du traitement de textes.