Oftmals spielt die Aufbereitung der Daten in der Entwicklungsphase einer Anwendung eine untergeordnete Rolle, denn Entwickler-Teams kümmern sich zunächst um die Entwicklung der Applikation. Wenn es abschließend um Reportfunktionen geht, programmieren Java-Entwickler sie entweder manuell selbst oder sie verwenden JavaServer Pages (JSP). Das aber schränkt die Vollständigkeit und Vielfalt der Berichte deutlich ein. Erst wenn das Produkt auf den Markt kommt oder bei Tests zur Akzeptanz stellen die Anwender fest, dass die Berichtsfunktionalität bestenfalls rudimentär ist. Nutzer verlangen denn auch häufig Verbesserungen bei den Reporting-Funktionalitäten sowie zusätzliche Ausgabeformate wie Spreadsheets, PDF oder Druck. Außerdem wollen Anwender bessere Layouts, Gliederungen, Sortierkriterien und die Möglichkeit, Reportparameter zu bestimmen oder Bilder und Grafiken einzufügen. Darüber hinaus wünschen sich die Nutzer Änderungen in bestehenden Berichten und die Zahl der Änderungswünsche steigt schließlich mit dem Erfolg einer Applikation.

Entwickler von Anwendungen merken schnell, dass es effizienter ist, eine geeignete Infrastruktur zu Reportingzwecken zu entwickeln, anstelle vieler einzelner Berichte. Das führt zur Arbeitsteilung zwischen Content-, Applikations- und Reportentwicklern. Die Reportentwickler konzentrieren sich darauf, Berichte auf der Grundlage von Komponenten und Infrastrukturen zu entwickeln, die die Applikationsentwickler ihnen bereitstellen. Sie brauchen leicht anwendbare Tools. Werden bei Anlage der Applikationsarchitektur geeignete Frameworks ausgewählt, können die Anforderungen leicht erfüllt werden. Aber selbst bei ausführlicher Planung wird es nicht immer gelingen, alle Anforderungen der späteren Nutzer vorauszusehen und alle Änderungsanfragen vorherzusagen. So entstehen häufig instabile Systeme, in denen die Pflege der reportingspezifischen Codes viel Zeit kostet. Auch die Zahl der erstellbaren Reporttypen bleibt begrenzt.

Ein gutes Reporting-Framework sollte die folgenden Anforderungen erfüllen:

Zugriff auf eine Vielzahl von strukturierten und unstrukturierten Datenquellen Eine große Bandbreite von Ausgabeformaten für Reports Eine einfach erweiterbare Architektur, um besondere Anforderungen von Unternehmen zu berücksichtigen Einfach anwendbare Layout- und Integrations-Funktionen Sortierung, Aggregation und Berechnungen mit Daten Integrierte Funktionen für Charts und Diagramme

Ein Lösungsansatz für die genannten Reporting-Probleme ist der Einsatz von BIRT. Es bietet Anwendungs- und Berichtsentwicklern ein Reporting-Framework, mit dem die Reporting-Funktionen in die Applikationen eingebunden werden können, ohne dass manuell kodiert werden muss. BIRT ist in die Open-Source-Entwicklungsumgebung Eclipse integriert und ermöglicht die effiziente Erstellung von komplexen, integrierten und flexiblen Reportdesigns. Die Reports können auf eine Vielzahl von Datenquellentypen zugreifen und Informationen in verschiedenen gängigen Formaten aufbereiten. Zentrales Tool für diese Aufgabe ist der BIRT Report Designer. Es handelt sich um ein Eclipse Plug-In Set.

Die Berichte werden im XML-Format erstellt und gespeichert. Das XML-Design kann auch über die Design-Engine-API (DE API) angelegt oder verändert werden. Wenn das Report-Design vollständig ist, wird die XML-Datei an die Report-Engine-API (RE API) weitergegeben, die den Output berechnet und rendert. Die Report-Engine unterstützt die Output-Formate PDF und HTML. Die RE-API kann genutzt werden entweder als alleinstehende Lösung , eingebettet in ein Servlet oder aufgerufen von einer RCP-Applikation.

Für das Report-Rendering bringt BIRT außerdem den Viewer mit. Er basiert auf AJAX und ist verfügbar als Eclipse-Plugin oder als alleinstehendes Servlet. Zusätzlich zur DE API und RE API enthält BIRT die Chart-Engine-API (CE API). Sie ist in den Designer integriert, um umfassende Charting-Funktionen innerhalb der BIRT-Reportdesign-Perspektive zu bieten. Darüber hinaus kann die CE-API auch unabhängig genutzt werden.

Zur Erleichterung der Arbeit bietet „Designer Perspective“ eine Vielzahl verschiedener Ansichten, in denen die Reports erstellt werden können. Sie dienen im Wesentlichen als „Wrapper“ für die Design-Engine-API und erstellen die XML-Datei mit dem Report-Design. Die Ansicht „Data Explorer“ hilft bei der Verbindung mit den Datenquellen und der Festlegung der zu berichtenden Daten. Dazu werden Datensätze zusammengefasst. Als Datenquellen für die Reports können XML-Dateien und Streams, JDBC-basierte RDBMS und CSV-Dateien herangezogen werden. Mithilfe einer entsprechenden Erweiterung können aber auch kundenindividuelle Datenquellen eingebunden werden. In der Data-Explorer-Ansicht werden außerdem Reportparameter festgelegt, die dafür sorgen, dass exakt die gewünschten Dateninhalte ausgegeben werden. Die Palette „View“ enthält die entsprechenden Berichtselemente.

Um ein Report-Element zu nutzen, wird es aus der Palette „View“ in den Report Editor gezogen. Alle Report-Elemente tragen Eigenschaften, die in der „Property Editor View“ eingestellt werden können und durch das „Report Object Model“ (ROM) beschrieben werden. Das ROM ist ein definiertes Schema für das Report Design, das im Internet im Detail beschrieben wird [1]. Außerdem stehen Eclipse Extension Points zur Verfügung, mit denen der Designer um zusätzliche Report-Elemente ergänzt werden kann. In Verbindung mit dem Callisto Release [2] der Eclipse IDE wurde BIRT auf Version 2.1 aktualisiert und um einige Verbesserungen und Erweiterungen ergänzt. Zu den wichtigen Neuerungen gehören Joint Data Sets, Charting und Report-Parametrisierung.

Datensätze gehören zu den grundlegenden Elementen für die Datenabfrage. Sie enthalten tabellarische Daten aus Datenquellen, die innerhalb der Containerelemente für BIRT-Daten wie Tabellen und Listen genutzt werden können. Diese Elemente sind mit einem Data Set verknüpft. Wenn der Reportentwickler Daten aus mehreren Datenquellen innerhalb einer bestehenden Tabelle anzeigen lassen wollte, wurde es bisher kompliziert. BIRT 2.1 bietet nun die Möglichkeit, ein spezielles Joint Data Set zu erstellen. Damit können zwei vorhandene Datensätze kombiniert werden, indem Inner und Outer Joints genutzt werden.

BIRT 2.1 führt viele Verbesserungen beim Charting ein. Zu den wichtigsten Neuerungen gehören ein neuer Subtyp für Stock Charts namens „Bar Stick“, automatisches Wrapping für Legenden, verbesserte Interaktivität und Scripting. Markierungslinien, eine weiterentwickelte Achsenskalierung, Textrotation für Legenden und ein zusätzlicher Y-Achsen-Support kommen ebenso hinzu wie zusätzliche Markierungen für Datenpunkte sowie Tortendiagramme nach Prozentwerten. Die Darstellung von Torten-, Feld- und 3D-Diagrammen wurde verbessert und die Charting Engine hat jetzt Zugriff auf eine neue Rendering-Funktion für PDF.

BIRT besitzt ein sehr flexibles Modell für die Parametererfassung. Damit kann ein Reportdesigner einfache, aber auch sehr komplexe Parameter definieren. Mit kaskadierten Parametern wird eine Parametergruppe so eingestellt, dass jede Auswahl eines bestimmten Parameterwertes automatisch die wählbaren Werte des nächsten Parameters in der Gruppe beeinflusst. Wenn beispielsweise in einem Report Verkaufsdaten geografisch dargestellt werden sollen, kann ein Anwender im Report eine bestimmte Region eines ausgewählten Landes darstellen. Das ist möglich durch die Anlage einer kaskadierten Parametergruppe mit den Parametern Land und Region. Bei der Darstellung für den Endanwender würde dann eine Länderauswahlliste alle Länder anzeigen. Nachdem das gewünschte Land ausgewählt wurde, stehen beim zweiten Parameter allerdings nur noch die Regionen innerhalb des gewählten Landes zur Verfügung.

In den vorherigen Versionen konnte der Berichtsentwickler nur einen Datensatz nutzen, um beide Parameter in dieser kaskadierten Gruppe zu steuern. BIRT 2.1 überwindet diese Beschränkung. Auf jedem nachfolgenden Level der Kaskadenparametergruppe ist eine vollkommen neue Abfrage möglich, sogar aus einer anderen Datenquelle. Die verschachtelte Abfrage kann so vorherige Parameter innerhalb der Abfrage nutzen, um die Ergebnissätze herauszufiltern.

BIRT bietet verschiedene Möglichkeiten für den Einsatz. Einige Applikationsentwickler wollen BIRT-Reports in einer J2EE-Umgebung einsetzen, andere könnten Reporting-Funktionen in eine RCP-Applikation integrieren oder einen Thick Client um Berichte erweitern wollen. Und wieder andere Entwickler möchten vielleicht nur Teilbereiche der Reporting-Funktionalitäten innerhalb einer der genannten Applikationstypen einsetzen. Das BIRT-Framework eignet sich für all diese Szenarien.

Reports, Libraries und Templates werden mit dem Report Designer oder der Design-Engine-API erstellt. Sobald die Reports vollständig sind, können sie durch den Web Viewer oder die Report Engine gerendert werden. Der Einsatz des Viewers erfordert einen J2EE Application Server. Der Viewer kann in eine vorhandene J2EE-Applikation integriert werden oder wird per URL aufgerufen. Soll der Web Viewer als Eclipse-Plugin verwendet werden, ist ein Eclipse Tomcat-Plugin nötig, das dem Web Viewer als Servlet/JSP-Engine dient. Dabei erfordert die Report Engine, dass BIRT Zugang zu einer Java Virtual Machine (JVM) hat. API Calls eröffnen die Möglichkeit, Reports zu öffnen, Ausführungsoptionen zu definieren und Reports als PDF, HTML oder seitenweises (paginated) HTML zu rendern.

Der Viewer ist als „Wrapper“ für die Report-Engine-API umgesetzt und eingebettet in ein Eclipse-Plugin. Er verfügt über zwei Betriebsarten, die den beiden Servlet Mappings – Run und Frameset – entsprechen. Frameset Mapping wird verwendet, um einen AJAX-basierten Viewer anzuzeigen, der Steuerungselemente für das Inhaltsverzeichnis, die Parameter-Eingabe, den Export in das CSV-Format und den Ausdruck des Berichts enthält. Darüber hinaus unterstützt das Mapping seitenweises HTML und bietet eine Reihe von Steuerungselementen für die Navigation im Berichtsdokument. Wenn Run Mapping genutzt wird, werden die Reports als PDF oder HTML ausgegeben. Mit diesem Mapping ist das HTML im Output nicht im Seitenformat gelayoutet und nutzt keine interaktiven Features wie Inhaltsverzeichnis und Export in CSV. Der Designer verwendet dieses Mapping, wenn der „Preview“-Tab im Report Editor angeklickt wird.

Im BIRT Designer kann der Viewer in einem separaten Fenster geöffnet werden. Das ermöglicht eine iterative Reportentwicklung und beschleunigt die Phase des Berichtsdesigns.

Die APIs von BIRT werden genutzt, um Designzeit- oder Laufzeitfeatures in Applikationen einzubinden. Die bei weitem am häufigsten eingesetzte API ist die Report-Engine-API (RE API), mit der Anwender BIRT in eine Applikation integrieren können, um Reports auszugeben und zu rendern. Die Chart-Engine-API (CE API) wird verwendet, um Applikationen mit einer eigenständigen Rendering-Funktion für Diagramme auszustatten. Die Design-Engine-API (DE API) wiederum kann von einer Applikation genutzt werden, um Reportbibliotheken und Designs programmatisch zu erstellen. Zusätzlich bieten Erweiterungsmöglichkeiten OEM-Anbietern und Unternehmen die Chance, besondere Anforderungen an Datenquellen und Formatierungen in ihren Applikationen zu berücksichtigen.

Einige Eclipse-Erweiterungen für BIRT:

Erstellung von neuen Reportbestandteilen für den Designer, wie zum Beispiel neue Diagrammtypen. Zusätzliche Datenquellen, um spezifische Anforderungen einer Organisation zu erfüllen. Emitter für das Rendering von Berichten in zusätzlichen Ausgabeformaten.

Eine Integration von BIRT mit PHP kann auf verschiedenen Gebieten vorkommen. Zum einen kann eine Java-Bridge genutzt und die BIRT-Engine aufgerufen werden, um Inhalte zu generieren und zurückzusenden. Momentan ist das BIRT-Team dabei, gemeinsam mit Zend ein Beispiel für diese Integration zu entwickeln. Auf ähnliche Art und Weise könnten die Chart- und Design-Engine-APIs aufgerufen werden. BIRT kann außerdem auf einem Application Server eingerichtet und von PHP mit gewöhnlichen URL-Befehlen aufgerufen werden. Darüber hinaus kann PHP für die dynamische Generierung von Berichtsdesigns genutzt werden. Wie bereits erwähnt, sind die Report Designs im Grunde nur XML-Dokumente. Ein Beispiel für diesen Ansatz ist auf der BIRT-Website zu finden [3].

Die Zend-/BIRT-Integration verwendet die Java Bridge der Zend-Plattform und bietet Java- und PHP-Klassen, um Parameter zu erfassen, Reports auszuführen und Report Designs mit der verfügbaren JVM zu rendern. Diese Vorgehensweise ist noch in der Entwicklung. Weitere Informationen über die Zend-Plattform-Java-Bridge finden Sie auf der Zend-Website [4].

Die Anbindung von BIRT an PHP prädestiniert die Reporting-Tools für den Einsatz in TYPO3-Projekten, die dynamische Reports benötigen. Folgende Funktionalitäten können TYPO3-Entwicklern nützlich sein:

• BIRTs „Point-and-Click“- und „Drag-and-Drop“-Funktionen machen es Anwendern leicht, Reports schnell zu entwerfen und langfristig zu pflegen.
• Templates fungieren als Ausgangspunkte für die Reportentwicklung und reflektieren den in Websites üblichen „Look and Feel“. Entwickler können ihre eigenen Templates erstellen und für andere Teammitglieder zugänglich machen.
• BIRT folgt der Eclipse-Philosophie in Sachen Erweiterbarkeit und bietet Entwicklern einfache Möglichkeiten, das Featureset zu ergänzen und an die eigenen Anforderungen anzupassen.
• BIRT unterstützt die Erstellung von Reportbibliotheken, die als Archive für Reportelemente dienen. Eine Library kann zum Beispiel Standard-Layoutelemente wie Kopfzeilen mit Unternehmenslogo oder komplexe Diagramme enthalten. Einmal erstellt, können Libraries allen BIRT-Entwicklern zugänglich gemacht werden. Wenn die Library geändert wird, aktualisiert BIRT automatisch alle Reports, die sich darauf beziehen.
• BIRT bietet ein integriertes Chartingmodul, das ein umfangreiches Set erweiterbarer Charts enthält.

Die Entwicklung von Berichtsfunktionalitäten für Java-Applikationen kann eine schwierige Aufgabe sein, wenn der Auswahl des richtigen Frameworks nicht genügend Aufmerksamkeit geschenkt wurde. Die Anforderungen an das Reporting gehen oft schnell über das hinaus, was zu Beginn eines Projekts geplant war. Erweiterbarkeit ist also ein Schlüsselkriterium für ein Framework.

Das Eclipse-BIRT-Projekt hat sich mit dem 2.1-Release weiterentwickelt und bietet nun umfangreiche Features, die die Einfachheit der Anwendung, die Skalierbarkeit und die Erweiterbarkeit verbessern und dabei eine breitere Nutzergruppe ansprechen. BIRT ist ein offenes Framework mit ausreichenden Funktionen, um mit einer großen Bandbreite von Berichten umgehen zu können. Applikationen, die sowohl unstrukturierte als auch strukturierte Daten verarbeiten, profitieren davon. Content Management Systeme können strukturierte Fragmente einfügen, die aus ansprechenden Grafiken und Texten bestehen. Darüber hinaus ist BIRT gut für die Integration mit führenden CMS wie TYPO3 geeignet.

Der Trend hin zu wachsender Akzeptanz und verstärktem Einsatz von Open-Source-Technologien innerhalb von Unternehmen verspricht auch Gutes für BIRT. Es bietet ein leistungsstarkes Feature-Set für unterschiedliche Anforderungen. Darüber hinaus ist BIRT in vielen Sprachen verfügbar und kann leicht international angepasst werden.