Einsatz von OpenOffice zur Dokumentengenerierung für Web-Anwendungen

Entwickelt man Web-Anwendungen, steht man immer, wenn es um das Erstellen von komplexeren Ausgaben von Dokumenten geht, vor einigen Herausforderungen. Je nach Anspruch und notwendigem Funktionsumfang der Druckausgabe bieten sich verschiedene Möglichkeiten an, die Erzeugung der Dokumente zu realisieren.

Ein wichtiges Entscheidungskriterium für die Wahl der Technologie ist das Zielformat. Soll das Dokument als PDF- oder als Word-Datei ausgegeben werden? Soll der Druck direkt aus dem Browser heraus erfolgen? Häufig scheint die Ausgabe des PDF-Formats sinnvoll, da es sehr weit verbreitet ist und das Erscheinungsbild auf dem Rechner des Nutzers exakt dem zuvor festgelegten entspricht.

Anforderungen an die auszugebenden Dokumente:

  • Es soll verschiedene Repräsentationen der gleichen Inhalte in verschiedenen Layouts geben.
  • Die Dokumente sind in sich flexibel, Texte können also mal länger, mal kürzer ausfallen, Listen können zum Einsatz kommen (aber auch fehlen), die Anzahl der Elemente in der Liste kann stark variieren.
  • Gefordertes Zielformat ist PDF.
  • Optimalerweise gibt es die Möglichkeit, das gleiche Dokument auch als Word-File auszugeben.
  • Die Generierung muss live geschehen.
  • Es sollen einzelne Seiten auch als Previews in der Web-Anwendung ausgegeben werden.

Die Web-Anwendung wurde in Java entwickelt, alle verwendeten Links und Libraries sind deshalb ebenfalls Java-spezifisch.

Idealvorstellung von der Technologie

Die Idealvorstellung einer solchen Technologie: Die Dokumente werden gelayoutet und mit entsprechenden Platzhaltern versehen. (Diese Arbeit führt am besten ein Designer durch.) Die Anwendung überträgt die gesammelten Daten in das Dokument, anschließend kann der Nutzer ein Ausgabeformat wählen.

Technologiewahl

Leider sind die meisten verfügbaren Technologien weit von einer solchen Idealvorstellung entfernt. Die direkte Erstellung eines PDF-Dokuments ist nicht trivial. Es gibt unzählige APIs zu Erzeugung in allen möglichen Programmiersprachen, die oft jedoch „Low-Level“ sind. Der Entwickler beschäftigt sich mit dem Zeichnen von Linien, der genauen Positionierung von Elementen und der Zerlegung von Texten. Daran zeigt sich, dass die Erstellung sehr aufwändig und das Ergebnis recht unflexibel ist. Ist das Layout für das Dokument einmal programmiert, bedarf es neuerlichem Programmieraufwand, um Änderungen vorzunehmen. Gerade also die Erstellung verschiedener Layouts wird damit sehr aufwändig. Die Flexibilität der Inhalte tut ihr übriges.

Anstatt auf eine PDF-API kann man alternativ auf FOP (Formatting Objects Processor) setzen. Dabei handelt es sich um ein XML-Format, das darauf ausgelegt ist, Inhalte in alle möglichen Ausgabeformate zu überführen. Die Stärken liegen eher bei größeren, sich gleichenden Inhalten, also beispielsweise Dokumentationen. Schwächen sind in der exakten Bestimmung des Layouts zu sehen. Außerdem ist die Erstellung eines Layouts mit FOP recht aufwändig. Die verfügbaren Tools sind nicht besonders schnell und sehr ressourcenhungrig. Zur Live-Generierung ist die Technologie also nur bedingt geeignet.

Eine weitere Möglichkeit ist der Einsatz von Tools, die es ermöglichen, an bestimmten Stellen eines vorhandenen PDF-Dokuments Inhalte einzusetzen. Eine solche Lösung ist z.B. iText. Diese Technik ist geeignet für vorgefertigte Formulare, in denen ein bestimmter Platz pro Inhaltselement garantiert werden kann. Ist der Inhalt jedoch flexibel und müssen andere Elemente bei Bedarf nach unten rutschen, ist auch diese Lösung nicht geeignet.

Um alle Anforderungen zu erfüllen, bietet sich OpenOffice an. OpenOffice ist im Desktop-Einsatz sehr verbreitet und die am häufigsten gewählte Alternative zu MS Office. Dabei ist die Office-Suite frei verfügbar und bietet Portierungen auf viele Betriebssysteme. Hinsichtlich des Funktionsumfangs muss sie sich keineswegs hinter kostenpflichtigen Anwendungen verstecken. OpenOffice ist insbesondere deshalb eine gute Lösung, da ein Designer die Layouts direkt in OpenOffice erstellen kann. Die Ausgabeformate sind flexibel, OpenOffice kann PDF-, Word-, ODF-Dokumente und  etliche andere Formate erzeugen, und das zudem recht schnell.

Zu lösende Herausforderungen

Einsatz auf einem Server mit Parallelität
Allerdings hat OpenOffice auch einige Schwachpunkte. OpenOffice ist dafür bekannt, hinsichtlich des Speichers sehr ressourcenhungrig zu sein. Außerdem wurde OpenOffice (wie schon erwähnt) für den Einsatz auf dem Desktop entwickelt und ist nicht dafür geschaffen, viele Anfragen gleichzeitig zu bearbeiten – auf einem Server ein unerlässliches Feature. Daher ist mit der Laufzeit ein wachsender Speicherbedarf zu beobachten (Speicherlöcher), gelegentlich erlebt man auch einen Absturz.

Vor dem Einsatz auf einem Server musste also eine Lösung für diese Herausforderung gefunden werden. Um diese Probleme zu beheben, kam die Software OODaemon zu Einsatz. Sie ist darauf ausgelegt, OpenOffice parallel in mehreren Instanzen zu starten und die anliegenden Anfragen auf die Instanzen zu verteilen. Die Anzahl der gleichzeitig ablaufenden Prozesse kann über die Konfiguration festgelegt werden. Außerdem überwacht der Daemon die Instanzen bezüglich der Responsivität und startet sie neu, wenn sie nicht mehr reagieren. Vorsorglich werden die Instanzen nach einer konfigurierbaren Anzahl von Anfragen neu gestartet, damit die Speicherlöcher keinen Anwuchs des Prozesses in unendliche Speicherhöhen verursachen können.

Der Daemon bietet dabei eine transparente API, d.h. der Programmierer kann die Schnittstelle so ansprechen, als würde er direkt mit einer OpenOffice-Instanz in Verbindung stehen. Wenn eine Anfrage gestellt wird, kümmert er sich jedoch erst einmal darum, eine geeignete Instanz auszuwählen und zu starten, und reicht erst danach die Anfrage durch. Leider hatte der Daemon noch einige weitere Probleme, die zunächst behoben werden mussten.

Verbindung zwischen Anwendung und OpenOffice
OpenOffice liefert von Haus aus die Schnittstelle UNO-API, mit der OpenOffice aus Programmen heraus gesteuert werden kann. Prinzipiell ist es damit möglich, alle Funktionen, die auch an der Oberfläche von OpenOffice zur Verfügung stehen, aus der Web-Anwendung heraus zu nutzen. Sie ist allerdings sehr komplex und nicht einfach zu lernen. Da man für die meisten Anwendungsfälle lediglich einen Bruchteil der Funktionen benötigt, bietet es sich an, auf den leichtgewichtigen Wrapper für die UNO-API NOA (Akronym für Nice Office Access) zu setzen. Er steht unter der LPLG-Lizenz und kann daher bedenkenlos eingesetzt werden.

Einsetzen der Daten in die Vorlagen
Die größte Herausforderung bildete das Befüllen der Vorlagen mit den Nutzdaten. Wie erwähnt bietet die UNO-API im Grunde die Möglichkeit, die Oberfläche fernzubedienen. Wenn man sich jedoch vorstellt, auf diesem Wege die Daten in die Vorlage zu befüllen, wird schnell klar, dass ein anderer Weg gewählt werden muss. Zwar ist es mit der UNO-API sehr wohl möglich, Steuerbefehle wie „Dokument als PDF“ auszugeben oder „Dokument speichern“ zu bedienen, die Navigation im Inhalt des Dokuments wird jedoch schnell sehr anstrengend und unterscheidet sich außerdem von Layout zu Layout stark.

Neben der UNO-API gibt es mehrere Ansätze, um die Erstellung von OpenOffice-Dokumenten in einer Schnittstelle abzubilden. Man hätte damit die Möglichkeit, auch ohne laufendes OpenOffice Inhalte im Dokument zu verändern und die Daten einzusetzen. Leider waren diese Schnittstellen zum Betrachtungszeitpunkt nicht sehr weit fortgeschritten und damit nicht für den produktiven Einsatz geeignet.

Mangels Alternativen wurde eine Lösung gewählt, die sich die Dokumentenstruktur von OpenOffice zunutze macht. Ein Writer-Dokument wird in einer Datei mit der Endung ODT gespeichert, die – wie auch die anderen von OpenOffice erzeugbaren Dokumente (Calc, Impress usw.) – aus einer ZIP-Datei besteht.

Diese lässt sich entpacken und man erhält die einzelnen Bestandteile des Dokuments in Form von Einzeldokumenten. Dabei ist der eigentliche Inhalt des Dokuments als XML-Datei unter dem Namen content.xml zu finden. (Bilder, Formatierungsdetails und weitere Informationen finden sich in anderen Dateien.) In diese Datei kann mithilfe von XML-Libraries oder aber durch die Verwendung eines Template-Parsers wie Velocity der auszugebende Inhalt an der richtigen Stelle eingesetzt werden. Dabei ist darauf zu achten, dass das Encoding korrekt ist und keine nicht XML-tauglichen Zeichen eingesetzt werden. Beispielsweise führt das Einsetzen eines ungequoteten &-Zeichens zu einer korrupten XML-Datei, da das Zeichen zum Quoten von Sonderzeichen verwendet wird.

Ist die content.xml-Datei befüllt, wird sie in das ZIP-Archiv gepackt und das auszugebende Dokument ist fertiggestellt.

Ausgabe als PDF-Datei
Die ODT-Datei ist nun befüllt, die Ausgabe als PDF-File kann erfolgen. Zunächst ist dabei der Zugriff von OpenOffice auf das auszugebende Dokument zu gewährleisten. Die UNO-API bietet nicht die Möglichkeit, das Dokument über ein Netzwerk an OpenOffice zu schicken, es muss vielmehr von dem Rechner, auf dem OpenOffice ausgeführt wird, über das Dateisystem erreichbar sein.

Läuft der Web-Server auf dem gleichen Server wie OpenOffice, ist das natürlich kein Problem. Handelt es sich aber um verschiedene Server, muss das Dokument über ein Netzlaufwerk erreichbar sein oder aber durch Kopieren der Datei auf den OpenOffice-Server erreichbar gemacht werden. Die gleiche Fragestellung ergibt sich auch für das fertig generierte PDF-Dokument.

Die Ausgabe als PDF-Datei ist im Listing dargestellt.

Vorschaubild erstellen
Ist das Dokument einmal erstellt, ist die Ausgabe eines Vorschaubildes unproblematisch. Mit dem PDF-Renderer von Sun lässt sich das in wenigen Schritten erledigen und der Entwickler hat eine PNG-Grafik erzeugt, die er ausliefern kann.

Fazit

Der Einsatz von OpenOffice für die Konvertierung von Dokumenten auf dem Server bietet Möglichkeiten, die auf anderen Wegen nur mit sehr viel höherem Aufwand zu erreichen sind. Es ist möglich, eine stabile Produktionsumgebung aufzubauen und in Echtzeit Konvertierungen durchzuführen. An der einen oder anderen Stelle hat man mit Layout-Problemchen zu kämpfen, etwa wenn das Layout beim Einsetzen von Inhalten verrutscht. Diese Herausforderungen sind aber in den Griff zu bekommen.


Mehr über die Creative-Commons-Lizenz erfahren

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar