Der saubere Weg
Für ein anspruchsvolles Reporting benötigt man nicht unbedingt teure Software. Professionelle Ergebnisse sind dank der offenen Standards XSL und SVG selbst mit einfachen Open-Source-Werkzeugen zu erzielen. Benutzerfreundlichkeit fügt der kommerzielle Digiforms Designer hinzu.
- Markus Karg
- Sebastian Krebs
Viele Unternehmen binden sich an ein proprietäres Produkt, um Reports zu erstellen. Die dadurch entstehende Herstellerunabhängigkeit kann sich mittelfristig als technisch unflexibel herausstellen. Eine Hinwendung zu offenen Standards und freien Werkzeugen ist in diesem Zusammenhang nicht zuletzt eine betriebswirtschaftlich getriebene Entscheidung.
Für das Berichtswesen erforderliche Software besteht üblicherweise aus einem Designwerkzeug zur Erstellung von Berichtsvorlagen sowie einer Runtime-Engine, die mit diesen Berichtsvorlagen aus Rohdaten-Dateien Berichte auf dem Bildschirm sowie auf dem Drucker ausgeben kann. Als nachteilig kann sich erweisen, wenn das Designwerkzeug nur mit beschränkten WYSIWYG-Fähigkeiten ausgestattet ist und die Runtime-Engine nur für Windows zur Verfügung steht. Außerdem müssen in solchen Fällen Druckvorlagen und der Eingangs-Datenstrom in einem proprietären Format vorliegen.
Ein Tausch des Designwerkzeugs oder der Runtime-Engine gegen Produkte konkurrierender Hersteller kann schwierig sein. Im Rahmen der Portierung der betriebswirtschaftlichen Rahmenanwendung auf die Java-Plattform und des damit einhergehenden Paradigmenwechsels (Plattformunabhängigkeit und Unterstützung allgemein akzeptierter Standards) stellte sich für die Autoren die Frage der Nachfolge. Der Anspruch an die künftige Software klang zunächst relativ einfach:
- Ein Endanwender kann mit einem für Laien einfach zu bedienenden WYSIWYG-Editor eigene Berichtsvorlagen generieren.
- Die betriebswirtschaftliche Anwendung ruft zur Laufzeit Vorlagen auf und wandelt sie mit einem Rohdaten-Strom in Bildschirmansichten und Ausdrucke.
- Eingangsdatenstrom und die Druckvorlagen entsprechen einem Standardformat, um einen späteren Tausch einzelner Komponenten sowie die Interoperabilität mit Drittsystemen zu gewährleisten.
Allerdings schränkten diese Kriterien die Auswahl der infrage kommenden Produkte stark ein.
Standards, wo immer möglich
Nach eingehender Recherche fiel die Entscheidung für XML als Format für die Inhaltsdaten, kodiert in UTF-8. Dies erleichtert die Bereitstellung der eigentlichen Daten durch die betriebswirtschaftliche Anwendung ungemein, da die verwendete Java-Plattform XML-Syntax und -Kodierung von Haus aus unterstützt, eine aufwendige und fehleranfällige Eigenentwicklung des Datenexports deshalb weitgehend entfallen konnte. Umlaute und andere Sonderzeichen zu verarbeiten, wie sie im internationalen Geschäftsverkehr zunehmend eine Rolle spielen, war mit der alten Software nicht machbar; das ist mit UTF-8 ebenfalls passé.
Statische Bilder wie JPGs für Logos et cetera sollten als Referenz im Datenstrom vorkommen, während aus dem Inhalt berechnete Informationen, beispielsweise Balkendiagramme, nicht die Anwendung selbst, sondern ein externer Renderer, sozusagen on the fly, erstellen sollte. Seine Aufgabe war es, aus den XML-Daten anhand von zuvor gestalteten Berichtsvorlagen eine druckbare Zieldatei in einem Standardformat, etwa PDF, zu erzeugen. Das ist mit dem Datenformat XML/UTF-8 gegeben. Mehrfach vorhandene Elemente, beispielsweise ein wiederkehrendes Logo, müssen im Datenstrom nicht zwingend immer wieder auftauchen, sondern man kann sie dank XML einmal definieren und später mehrfach referenzieren. Das verkleinert den zu verarbeitenden Datenstrom und fördert die Performance.
Für die Berichtsvorlagen wünschten sich die Autoren ebenfalls XML, in Gestalt von XSL (Extensible Stylesheet Language). Die Sprache erfüllt mit XSLT (XSL Transformations) für die Transformation und XSL-FO (XSL Formatting Objects) für das Layout professionelle Ansprüche. Hinter der Entscheidung für XSL stand der Wunsch, sowohl dem Endanwender die freie Wahl des Bearbeitungswerkzeugs als auch den Programmierern die freie Wahl der Rendering-Engine zu lassen. Das Erzwingen einer bestimmten Produktkombination sollte auf jeden Fall vermieden werden – hauptsächlich aufgrund schlechter Erfahrungen.
Jeder kennt es, keiner kann es
Zum Zeitpunkt der Recherche (Anfang 2006) waren im Bereich XML-basierter Reporting-Werkzeuge unter anderem bekannte Produkte: Stylus Studio, Xultation Designer, Antenna House Designer, Syntax Serna, Intelliview, XFDesigner, XSLfast sowie Altova Stylevision. Bei genauerer Betrachtung zeigte sich, dass sie sich nur bedingt für den gewünschten Anwendungszweck eigneten. Entweder waren sie zu komplex, was die Kenntnisse der Mehrzahl der Anwender überstiegen hätte, oder es fehlten echte WYSIWYG-Fähigkeiten.
Grund hierfür ist, dass die Hersteller eher Programmierer und weniger „unbedarfte“ Anwender im Blick haben. Ebenso erfüllte nicht jedes Werkzeug den Wunsch, dass Druckvorlagen und Datenstrom auf freien Standards aufsetzen sollten. Viele Produkte können zwar XML verarbeiten, speichern Druckvorlagen jedoch in einem proprietären Format. Ein Austausch von Druckvorlagen zwischen verschiedenen Mitarbeitern mit unterschiedlichen Gestaltungswerkzeugen wäre somit unmöglich, da nicht jeder Hersteller eine Anleitung seines XSD-Schemas beilegt, was für eine Transformation als einzigen Ausweg nötig wäre.
Zu guter Letzt erzwangen eine ganze Reihe von Werkzeugen bestimmte, wiederum proprietäre Rendering-Produkte, wodurch das Kriterium der freien Austauschbarkeit der Rendering-Engine nicht mehr erfüllt war. Überraschend war zudem, dass die Hersteller überwiegend zwar mit den Worten XML oder sogar XSL-FO werben, damit aber keineswegs meinen, dass die Berichtsvorlage selbst in diesem offenen Standard vorliegt. Einige Produkte benutzen XSL-FO nur intern, andere eine proprietäre Formatierungssprache zur Ansteuerung des hauseigenen Renderers (der kostenpflichtig ist).
Unter dem viel zitierten Strich blieb lediglich ein einziges Produkt, das alle genannten Kriterien erfüllte: Der Xultation Designer des norwegischen Softwarehauses Metafocus AS, das dieses Produkt inzwischen unter dem geänderten Namen Digiforms Designer vertreibt. Die Produktbeschreibung deckte sich vollständig mit der Liste der geforderten Standards. Die Frage war nur, ob dies in der Praxis zutrifft.
Ehrenrettung aus Norwegen
Version 3.0 des Digiforms Designer ist in erster Linie ein vollwertiges WYSIWYG-Werkzeug zur Erstellung von Vorlagen jeglicher Art, wobei die zu verarbeitenden Eingangsdaten in einem beliebigen XML-Schema vorliegen müssen und das Format der Druckvorlagen den Standards XSLT 1.0, XSL-FO 1.0 sowie XPath 1.0 entspricht. Intern benutzt das Tool Apache FOP 0.20.5 zur PDF-Voransicht, ist zur Laufzeit jedoch keineswegs auf diesen speziellen Renderer angewiesen, da keinerlei proprietäre Erweiterungen zum Einsatz kommen.
Anwendern dürfte als Erstes auffallen, dass die Benutzung stark an ein Malprogramm erinnert: Sie können ohne Vorkenntnisse innerhalb weniger Minuten einen einfachen Bericht mit Tabellen, Textfeldern et cetera gestalten. Ein besonderes Highlight stellt der sogenannte Trace-Mode dar: Ein eingescanntes Formular stellt Digiforms Designer beim Bearbeiten als Hintergrundgrafik dar. Mit einem Klick in die Grafik erkennt der Designer Position und Größe von Datenfeldern im Scan automatisch und fügt entsprechende Eingabefelder in die Druckvorlage ein. Die Umsetzung von papiernem Berichtswesen auf elektronische Berichte ist dadurch ein Kinderspiel. Im Test hat das reibungslos funktioniert.
Der eingebaute XML-Browser ermöglicht eine XPath-Adressübernahme bestimmter XML-Knoten per Mausklick in das gewünschte Berichtsfeld, sodass keine tiefgehenden XPath-Kenntnisse nötig sind. Man klickt einfach auf die Baumdarstellung der Daten und zieht die Information an die gewünschte Stelle in der WYSIWYG-Ansicht der Vorlage. Darüber hinaus kann man sämtliche in XPath 1.0 definierten Funktionen benutzen, sofern man sie kennt. Hierzu ist jedoch das manuelle Schreiben von XPath-Ausdrücken innerhalb des Eigenschaften-Dialogs des Feldes notwendig, was angesichts der Einfachheit von XPath jedoch keinen unangemessenen Lernaufwand nach sich zieht. Darüber hinausgehend stellt das Produkt viele weitere Features zur Verfügung, die jedoch den Rahmen dieses Artikels sprengen würden.
XML rein, SVG raus
Onlinequellen
Üblicherweise gestaltet sich der Einstieg in die beschriebene Prozesskette etwa so, dass der Anwender per Maus anhand der XML-Struktur ein meist tabellenlastiges Layout gestaltet. Um aber zu einem wirklich anspruchsvollen Druckergebnis zu gelangen, kommt man sicherlich in der Mehrzahl der Anwendungsfälle nicht um das dynamische Generieren von Vektorgrafiken herum, beispielsweise um Balkendiagramme zu erzeugen. Zwar bietet Digiforms Designer hierzu vorgefertigte, rudimentäre Unterstützung der Scalable Vector Graphics (SVG) an – aus XML-Daten generiert er zur Laufzeit eine SVG-Grafik –, jedoch dürfte sich der professionelle Anwender nicht mit diesen Ergebnissen zufriedengeben. Das Produkt ist daher in jeglicher Richtung offen, das heißt, man kann beliebige, in XSLT geschriebene Template-Bibliotheken einbinden und von jedem Feld des Berichts aus aufrufen. Beispielsweise könnte die bekannte Bibliothek XSLTSL zum Einsatz kommen (siehe „Onlinequellen“).
Technisch gesehen läuft die Prozesskette wie in Abbildung 3 dargestellt ab: Die Anwendung übergibt einen XML/UTF-8-Strom mit den Rohdaten an einen beliebigen XSLT-Prozessor. Der Prozessor wandelt unter Nutzung der in XSL (XSLT und XSL-FO) definierten Vorlage und eventuell weiteren, von dieser referenzierten XSLT-Bibliotheken und statischen JPG- oder PNG-Bildern den Datenstrom in ein statisches XSL-FO-Dokument. Hierbei kann die Anwendung eingebettete SVG-Grafiken aus den Daten errechnen.
Da das von den Autoren entwickelte Anwendungssystem in Java programmiert war, entfiel eine Recherche zu alternativen Prozessoren, da die Java Runtime Engine schon einen XSLT 1.0 kompatiblen Prozessor mitbringt. Die Java-VM erlaubt es jedoch, den Prozessor auszutauschen, um beispielsweise einen besonders schnellen zu verwenden. Dementsprechend hat der Anwender die freie Wahl aus einer großen Menge an Produkten.
Per Pipe – ohne Zwischenspeicherung auf der Festplatte – reicht der Designer das XSL-FO-Dokument sodann an einen nachgeschalteten Renderer weiter, der daraus das gewünschte Zielformat erstellt. Durch die offenen Schnittstellen ist es einfach, nicht nur den Vorlagen-Editor und den XSLT-Prozessor zu tauschen, sondern außerdem den XSL-FO-Renderer. Je nach Aufgabe kann man in verschiedene Zielrichtungen optimieren (Ablaufgeschwindigkeit, Speicherverbrauch, zusätzliche Features oder Zielformat).
Als erste Wahl für eine Rendering-Engine kam Apaches FOP ins Spiel, der Default-Renderer des Digiforms Designer. Wie sich herausstellte, arbeitet FOP zwar bei Weitem nicht vollständig fehlerfrei und benötigt viel Arbeitsspeicher, dennoch ist die Software schon in vielen anderen Projekten erfolgreich im Einsatz und liefert mehr als akzeptable Ergebnisse. Da alle benötigten Funktionen erfüllt waren, erübrigte sich die Evaluierung weiterer Engines.
Fazit
Sieht man vom WYSIWYG-Designer ab, sind für ein professionelles Reporting keine proprietären Formate oder kommerziellen Werkzeuge notwendig. Es ist bedauerlich, dass es anscheinend nur ein einziges Hilfsmittel auf dem Markt gibt, das seine Dateivorlagen als standardkonforme XSL-Dateien ablegt. Doch immerhin ist es relativ günstig und erfüllt alle gestellten Anforderungen.
Entwicklungspotenzial gibt es in zwei Richtungen. Zum einen ist die FOP-Engine relativ langsam und verbraucht viel Hauptspeicher. Je nach Druckvolumen könnte der Wechsel auf ein alternatives Produkt Vorteile mit sich bringen. Nach Beendigung der Arbeit an diesem Artikel erschien ein neues Release von FOP, die schneller arbeitet und weniger RAM benötigt.
Wer komplexe Berichte benötigt, mit vielen Berechnungen und dynamischen Elementen, könnte zum anderen XSL 2.0 sinnvoll finden, das das W3C nach Beendigung des Projekts zum Standard erhoben hat. Jedoch unterstützen diese Version momentan nur die wenigsten Transformer/Renderer, was sich vermutlich jedoch bessern dürfte.
Sollen ausschließlich allgemein akzeptierte Standards zum Einsatz kommen, stellt die gefundene Kombination einen günstigen Umsetzungsweg dar. Es ist zwar noch Verbesserungspotenzial vorhanden, jedoch ist mit FOP 1.0 sowie XSL 2.0 Abhilfe in Sicht.
Markus Karg
ist staatlich geprüfter Informatiker und verantwortet Implementierung & Design bei der Quipsy Quality GmbH & Co. KG in Pforzheim.
Sebastian Krebs
ist IT-Fachinformatiker in der Anwendungsentwicklung, als Quality Engineer bei der Uniserv GmbH in Pforzheim tätig und studiert Wirtschaftsinformatik.
