Evaluierung von Reporting-Frameworks am Beispiel der ausgewählten Open-Source-Anwendungen.

Transkript

1 Evaluierung von Reporting-Frameworks am Beispiel der ausgewählten Open-Source-Anwendungen. Diplomarbeit vorgelegt an der Fachhochschule Köln Campus Gummersbach im Studiengang Allgemeine Informatik ausgearbeitet von: Andrej Doumack Erster Prüfer: Prof. Dr. Heide Faeskorn-Woyke Zweiter Prüfer: Dipl.-Kfm. Kai Lehmann Gummersbach, im Oktober 2008

2 S e i t e 1 Abstrakt In der vorliegenden Arbeit werden ausgewählte Business Intelligence Reporting- Frameworks aus dem Open Source Bereich verglichen. Dabei wird eine idealtypische Architektur von Business Intelligence aufgezeigt und eine Einordnung vom Berichtswesen durchgeführt. In diesem Zusammenhang werden einige theoretische Eigenschaften von Berichten aufgezeigt. Um einen Überblick über die Vor- und Nachteile der ausgewählten Frameworks zu geben, muss ein Kriterienkatalog erarbeitet werden, der eine Bewertung nach unterschiedlichen Gesichtspunkten ermöglichen soll. Es wird ein besonderer Schwerpunkt auf die Kriterien aus der Programmierersicht und der Anwendersicht gelegt. Auf den Kriterienkatalog werden anschließend die ausgewählten Reporting- Frameworks angewendet, und die Ergebnisse in einer Gesamtübersicht präsentiert, die eine objektive Empfehlung für das Unternehmen darstellen soll. Die Evaluierung wurde für das Unternehmen Ikom Unternehmensberatung GmbH durchgeführt, damit eines der ausgewählten Reporting-Anwendungen später in die hauseigene Entwicklung integriert werden kann.

3 S e i t e 2 Inhaltsverzeichnis Abbildungsverzeichnis... 5 Tabellenverzeichnis... 6 Listingverzeichnis... 8 Abkürzungs- und Symbolverzeichnis... 9 Glossar Einleitung Problembeschreibung Zielsetzung Inhalt der Diplomarbeit Business Intelligence und Reporting Business Intelligence theoretische Grundlagen Begriffsdefinition Architektur Einordnung des Berichtswesens Berichtsgestaltung Open Source Vorbereitung der Evaluierung Evaluierungs-Model Kriterienkatalog Kriterien für Vorbewertung Kriterien für Hauptbewertung Testberichte Einleitung Übersicht Benchmarkanwendung Beschreibung Architektur Auswahl und Vorstellung der Frameworks Softwareauswahl... 38

4 I n h a l t s v e r z e i c h n i s S e i t e Pentaho Reporting Einführung Funktionsweise Architektur JasperReports Einführung Funktionsweise Architektur BIRT Einführung Funktionsweise Architektur Durchführung der Evaluierung Verteilung der Gewichtungen bei Kategorien Gewichtungen unter der Kategorie Functionality Gewichtungen unter Kategorie Usability Gewichtungen unter Kategorie Documentation Gewichtungen unter Kategorie Quality Gewichtungen unter Kategorie Architecture Gewichtungen unter Kategorie Scalability Gewichtungen unter Kategorie Community Bewertung der Frameworks Bewertung in der Kategorie Functionality Bewertung in der Kategorie Usability Bewertung in der Kategorie Documentation Bewertung in der Kategorie Quality Bewertung in der Kategorie Architecture Bewertung in der Kategorie Scalability Bewertung in der Kategorie Community Ergebnisse der BRR-Bewertung Zusatzbewertung der Benutzeroberfläche Ergebnisse der Zusatzbewertung der Benutzeroberfläche Performance und Speicherauslastung Testumgebung Ergebnisse JasperReports Ergebnisse Birt... 81

5 I n h a l t s v e r z e i c h n i s S e i t e Ergebnisse Pentaho Reporting Gegenüberstellung der Performance und Speicherauslastung Entscheidungsmatrix Zusammenfassung Literaturverzeichnis Anhang... 96

6 S e i t e 5 Abbildungsverzeichnis Abbildung 1, unterschiedliche Facetten und Abgrenzungen von Business Intelligence Abbildung 2, BI-Schichtenmodell Abbildung 3, Prozesse des betrieblichen Berichtswesens Abbildung 4, Merkmale zur Kennzeichnung und Gestaltung von Berichten Abbildung 5, 4 Phasen des BRR-Models Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung Abbildung 7, Pentaho-Reporting High-Level-Architektur Abbildung 8, Pentaho Reporting Architektur Abbildung 9, JasperReports High-Level-Architektur Abbildung 10, Jasper-Reporting-Engine Abbildung 11, BIRT High-Level Architektur Abbildung 12, BIRT Komponenten als Plug-ins für die Eclipse-Platform...48 Abbildung 13, BIRT Report Designer: Beziehung zwischen Standard- und Spezialkomponenten..49 Abbildung 14, BIRT Report Viewer: Beziehung zwischen Standard- und Spezialkomponenten Abbildung 21, Designer-Oberfläche Birt Abbildung 22, Designer-Oberfläche Pentaho Report Designer Abbildung 23, Designer-Oberläche IReport

7 S e i t e 6 Tabellenverzeichnis Tabelle 1, Umrechnung für die Endbewertung in der Kategorie Functionality...25 Tabelle 2, Metriken aus der Kategorie Usability Tabelle 3, Metriken aus der Kategorie Quality Tabelle 4, Metriken aus der Kategorie Security...29 Tabelle 5, Metriken aus der Kategorie Performance Tabelle 6, Metriken aus der Kategorie Scalability Tabelle 7, Metriken aus der Kategorie Architecture Tabelle 8, Metriken aus der Kategorie Support Tabelle 9, Metriken aus der Kategorie Documentation Tabelle 10, Metriken aus der Kategorie Adoption Tabelle 11, Metriken aus der Kategorie Community Tabelle 12, Metriken aus der Kategorie Professionalism Tabelle 13, Übersicht: Testberichte...36 Tabelle 14, Übersicht von Open Source BI-Lösungen...38 Tabelle 15, Kategorien mit Gewichtungen...53 Tabelle 16, Übersicht: Gewichtungen von Funktionalitäten Tabelle 17, Übersicht: Gewichtungen von Metriken unter Kategorie Usability Tabelle 18, Übersicht: Gewichtungen von Metriken unter Kategorie Documentation Tabelle 19, Übersicht: Gewichtungen von Metriken unter Kategorie Quality Tabelle 20, Übersicht: Gewichtungen von Metriken unter Kategorie Architecture Tabelle 21, Übersicht: Gewichtungen von Metriken unter Kategorie Scalability Tabelle 22, Übersicht: Gewichtungen von Metriken unter Kategorie Community Tabelle 23, Bewertungstabelle für die Kategorie Functionality Tabelle 24, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Usability Tabelle 25, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Documentation Tabelle 26, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Quality Tabelle 27, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Architecture Tabelle 28, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Scalability Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community Tabelle 30, Übersicht: Ergebnisse der BRR-Bewertung Tabelle 31, Metriken zum Bewerten von der Benutzeroberfläche Tabelle 32, Bewertung der Metrik Z Tabelle 33, Bewertung der Metrik Z Tabelle 34, Bewertung der Metrik Z

8 T a b e l l e n v e r z e i c h n i s S e i t e 7 Tabelle 35, Bewertung der Metrik Z Tabelle 36, Bewertung der Metrik Z Tabelle 37, Bewertung der Metrik Z Tabelle 38, Bewertung der Metrik Z Tabelle 39, Bewertung der Metrik Z Tabelle 40, Bewertung der Metrik Z Tabelle 41, Bewertung der Metrik Z Tabelle 42, Bewertung der Metrik Z Tabelle 43, Übersicht: Ergebnisse der Zusatzbewertung Tabelle 44, Übersicht der Test-Systeme Tabelle 45, Performance und Speicherauslastung von JasperReports Tabelle 46, Performance und Speicherauslastung von BIRT Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting Tabelle 48, Gegenüberstellung von Performanceergebnissen Tabelle 49, Gegenüberstellung von Speicherauslastungsergebnissen Tabelle 50, durchschnittliche Performance nach Formaten Tabelle 51, durchschnittliche Speicherauslastung nach Formaten Tabelle 52, Entscheidungsmatrix....88

9 S e i t e 8 Listingverzeichnis Listing 1, Quellcode der Klasse BenchmarkRunner Listing 2, Quellcode der Klasse ReportEngineFactory Listing 3, Quellcode der Klasse AReportingEngine Listing 4, Quellcode der Klasse ReportingEngineBirt Listing 5, Quellcode der Klasse ReportingEngineJasperReports Listing 6, Quellcode der Klasse ReportingEnginePentaho

10 S e i t e 9 Abkürzungs- und Symbolverzeichnis BI CSV DOC ETL HTML J2EE JDBC MDX ODA ODT OLAP PDF POJO Business Intelligence Comma Separated Values Dateiendung der Dateien des Textverarbeitungsprogramms Microsoft Word Extract, Transform, Load Hypertext Markup Language Java 2 Enterprise Edition Java Database Connectivity Multi-dimensional Expressions Open Data Access Open Document Text On-Line Analytical Processing Portable Document Format Plain Old Java Object PPT Dateiendung der Dateien des Präsentationsprogramms Microsoft PowerPoint RCP ROM RTF SVG TXT XMI XML XMLA Rich Client Platform Report Object Model Rich Text Format Scalable Vector Graphics Abkürzung für Text XML Metadata Interchange Extensible Markup Language XML for Analysis

11 S e i t e 10 Glossar Drill-Down: Engine: Framework: Platform: Rich-Client: Mit Drill-Down wird eine Funktionalität bezeichnet, mit der der Detailierungsgrad der vorhandenen Daten erhöht werden kann, um diese in unterschiedlicher Detailtiefe zu betrachten. In der Informationstechnologie wird mit Engine (von engl. Antrieb) ein eigenständiger Teil eines Computerprogramms bezeichnet, der komplexe Berechnungen oder Simulationen durchführt. Ein Framework (engl. für Rahmenwerk ) in der Softwaretechnik stellt ein wiederverwendbares Architekturgerüst für einen Anwendungsbereich (Domäne) dar und unterstütz das Zusammenspiel von einzelnen Komponenten. Außerdem bietet ein Framework Schnittstellen und Konfigurationsmöglichkeiten an, um dieses an die Bedürfnisse und Anforderungen einer konkreten Anwendung anzupassen. 1 Mit Platform (engl. für Plattform ) wird eine Softwarebasis bezeichnet, auf der eine modul- oder plug-in-orientierte Anwendung aufgebaut werden kann, z.b. Eclipse. Mit Rich-Client (engl. für Reicher Klient ) werden in der Client- Server-Architektur die Clients bezeichnet, die reichhaltige Problemlösungen anbieten. Rich Client ist meistens ein Framework, der durch Module und Plug-ins erweiterbar ist. Sub-Reports: Sub-Reports (engl. für Unter-Berichte ) sind Berichte, die in einen Hauptbericht eingebunden werden. Die Unter-Berichte können detailliertere Informationen oder Daten enthalten, die thematisch verwandt sind. 1 Vgl. Griffel (1998).

12 S e i t e Einleitung Die ikom Unternehmensberatung GmbH entwickelt mit smartidee.com eine Softwarelösung für den Bereich Ideenmanagement. Diese Softwarelösung ist für den Einsatz in Groß- und Mittelstandunternehmen konzipiert Problembeschreibung Die Grundlage der Arbeit wurde durch folgende Feststellung umrissen: 1. Die angebotenen Reports 2 in der Software sind fest definiert, und die Kunden haben somit keine Möglichkeit zusätzliche Reports selbst zu definieren. 2. Es besteht zwar die Möglichkeit parametrisierte Reports zu erzeugen, aber die Konfiguration hierfür ist zu komplex. 3. Die erzeugten Berichte stellen die Informationen nur als Tabelle dar, d.h. es besteht keine Möglichkeit die Informationen in Diagrammen darzustellen. 4. Das Design der Berichte ist nicht an das Corporate-Design des jeweiligen Unternehmens anpassbar. 5. Es besteht keine Möglichkeit Drill-Down-Reports zu erzeugen, somit sind die Ergebnisse bei komplexen Kennzahlen nicht nachvollziehbar Zielsetzung Zur Verbesserung des vorhandenen Reporting-Systems in der angebotenen Softwarelösung soll eine Evaluierung von Reporting-Frameworks 3 durchgeführt werden. Das ausgewählte Framework wird später in die Anwendung integriert und somit das alte Reporting-System ersetzen. Die Anforderungen des Unternehmens an das Reporting-Framework sind: 1. Das Framework muss Open Source 4 sein. 2. Das Framework muss die Erzeugung des Reports grafisch unterstützen. 3. Unterstützung von mehreren Datenquellen innerhalb eines Reports. 4. Das Framework muss die Konfiguration von Datenquellen unterstützen. 5. Der Bericht muss die Informationen in Tabellenform darstellen können. 6. Das Framework muss u.a. Säulen-, Kuchen-, Flächen- und Linien-Diagramme unterstützen. 2 Die Begriffe Report und Bericht werden in dieser Arbeit synonym verwendet, sowie die Begriffe Reporting und Berichtswesen. 3 Siehe hierzu Glossar. 4 Siehe hierzu Kapitel 2.5.

13 1 E i n l e i t u n g S e i t e Das Framework muss kombinierte Diagramm-Arten unterstützen. 8. Das Framework muss eine kombinierte Darstellung von Tabellen und Diagrammen unterstützen. 9. Das Framework muss parametrisierte Berichte unterstützen. 10. Das Framework muss Sortierung und Gruppierung von Daten unterstützen. 11. Das Framework muss Aggregation von Daten unterstützen. 12. Das Framework muss freidefinierbares Layout für die Berichte unterstützen. 13. Das Framework muss die Integration von Grafiken in einen Report unterstützen. 14. Das Framework muss den Report in HTML ausgeben können. 15. Das Framework muss den Report in PDF ausgeben können. 16. Das Framework muss den Report in MS Excel ausgeben können. 17. Das Framework muss den Report in MS Word ausgeben können. 18. Das Framework muss den Report in CSV ausgeben können Inhalt der Diplomarbeit Die vorliegende Arbeit gibt einen Überblick über ausgewählte Reporting-Frameworks, die nach unterschiedlichen Kriterien bewertet werden. Da einige der Reporting-Frameworks Business Intelligence Funktionalitäten beinhalten und in Business Intelligence Suiten eingesetzt werden, wird in Kapitel 2 ein Überblick über Business Intelligence gegeben. Es wird eine idealtypische Architektur zu Business Intelligence gezeigt. Darüberhinaus wird eine Einordnung vom betrieblichen Berichtswesen in die Business Intelligence Architektur vorgenommen und eine Klassifizierung von Berichten durchgeführt. Anhand der Klassifizierung von Berichten in Kapitel 2 werden in Kapitel 3 Kriterienkatalog, Bewertungssystem und Testberichte beschrieben, die der Durchführung der Evaluierung und der Bewertung der Reporting-Frameworks zugrunde liegen. Die Auswahl der Frameworks wird in Kapitel 4 getroffen. Die ausgewählten Frameworks werden kurz vorgestellt. Es werden die Architektur und einige Besonderheiten der Frameworks aufgezeigt. Die Durchführung der Evaluierung wird in Kapitel 5 beschrieben. Es werden drei ausgewählte Frameworks untersucht und deren Vor- und Nachteile beschrieben. Darüberhinaus werden Performance- und Speicherauslastungstests durchgeführt. Die gewonnenen Ergebnisse werden in einer Entscheidungsmatrix dargestellt.

14 1 E i n l e i t u n g S e i t e 13 Zum Abschluss der Diplomarbeit wird in Kapitel 6 eine Handlungsempfehlung ausgesprochen und ein Ausblick hinsichtlich der getesteten Frameworks gegeben.

15 S e i t e Business Intelligence und Reporting 2.1. Business Intelligence theoretische Grundlagen Begriffsdefinition Am Anfang der 90er entstand der Begriff Business Intelligence, der durch die Gartner Group geprägt wurde. Der Begriffsteil Intelligence bedeutet in diesem Zusammenhang nicht Intelligenz, sondern wird im Sinne von Verständnis, Einsicht, Aufklärung und Suche interpretiert. 5 Im früheren Stadium wurde die Bezeichnung Business Intelligence als Oberbegriff von Anbietern und Beratern für ihr Angebot an Softwarewerkzeugen für die Managementunterstützung verwendet. Erst später konnte dieser Begriff aus der Praxis in wissenschaftlichen Diskussionen etabliert werden. Deswegen gibt es keine eindeutige wissenschaftliche Definition zu diesem Begriff. 6 In der Fachliteratur wurden einige Versuche unternommen eine Definition herzuleiten: Grothe (2000): Business Intelligence (BI) bezeichnet den analytischen Prozess, der fragmentierte Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen über die Fähigkeit, Positionen, Handlungen und Ziele der betrachteten internen oder externen Handlungsfelder (Akteure und Prozesse) transformiert. Strauch u. Winter (2002): ( ) Business Intelligence (kann) als Sammelbegriff für die aufgrund neuer Integrationsmechanismen wie Data Warehouse und Applikationsintegration konvergierenden, ursprünglich isolierten und nacheinander entwickelten Konzeptionen Management Information System, Decision Support System und Executive Information System interpretiert werden ( ) Chamoni/Gluchowski (2004): Business-Intelligence (BI) kennzeichnet Systeme, die auf der Basis interner Kostenund Leistungsdaten sowie externer Marktdaten in der Lage sind, das Management in seiner planenden, steuernden und koordinierenden Tätigkeit zu unterstützen. 5 Vgl. Mertens (2002); Chamoni/Gluchowski (2004); Strauch/Winter (2002); Grothe (2000), S. 19; Gluchowski/Gabriel/Dittmar (2008), S Vgl. Kemper/Lee (2001); Gluchowski/Kemper (2006); Gluchowski/Gabriel/Dittmar (2008), S. 89; Strauch/Winter (2002)

16 2 Business Intelligence und Reporting S e i t e 15 Dittmar/Schulze (2006): Eine Vielfalt unterschiedlichster Systeme zur Analyse und Auswertung von Daten mit dem Ziel der Gewinnung nicht-trivialer Erkenntnisse zu den relevanten Wirkungszusammenhängen in Unternehmen werden aktuell unter dem Sammelbegriff Business Intelligence (BI) entwickelt und eingesetzt Gluchowski/Kemper (2006): Unter Business Intelligence (BI) wird ein integriertes IT-Gesamtkonzept verstanden, das für die unterschiedlichen Ausprägungen der Anforderungen an geeignete Systeme zur Entscheidungsunterstützung tragfähige und miteinander verknüpfte Lösungen anbietet. Die zitierten Definitionen weichen voneinander ab. Dennoch besitzen sie eine Gemeinsamkeit: Business Intelligence soll das Management bei der Entscheidung und Analyse unterstützen. Gluchowski verfolgt einen anderen Ansatz, indem er eine Annäherung an den Begriff versucht durch Aufzeigen und Erörtern von Konzepten und Technologien, die er in einem strukturierten Ordnungsrahmen darstellt (vgl. Abbildung 1). Die vertikale Achse stellt die zentralen Phasen des analytischen Datenverarbeitungsprozesses dar. Die horizontale Achse veranschaulicht die Perspektive sowie die zugehörige Systemkategorie des jeweiligen Themas, das heute schwerpunktmäßig diskutiert wird. Es lassen sich hierbei drei gängige Typen von Definitionsansätzen abgrenzen: Enges BI-Begriffsverständnis Zum engen Begriffsverständnis gehören Anwendungen und Produkte, die eine Aufbereitung und Präsentation von organisierten Daten unterstützen. Diese verwenden solche Techniken wie Slice und Dice oder Color Coding (farbliche Hervorhebung). Herstellerspezifische Clientlösungen, Briefing-Books, Excel-Add-ins oder Browsererweiterungen kommen hier als BI-Tools in Betracht. Front-End-Produkte, die für Reporting-Anwendungen genutzt werden oder Data Mining ermöglichen, gehören nicht zu diesem Segment. 7 Analyseorientiertes BI-Begriffsverständnis Hierzu gehören analyseorientierte Konzepte und Anwendungen bzw. ihre Komponenten, die eine modell- und methodenbasierte Analyse von vorhandenen Daten ermöglichen. Zu den BI-Tools zählen On-Line Analytical Processing (OLAP)- 7 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 90; Gluchowski (2001), S. 7.

17 2 Business Intelligence und Reporting S e i t e 16 Werkzeuge, Data Mining-Produkte und Generatoren zur Erstellung von Ad-Hoc- Berichten sowie darauf basierenden Anwendungen. 8 Weites BI-Begriffsverständnis Dazu werden alle Systemkomponenten gezählt, die operatives Datenmaterial zur Informations- und Wissensgenerierung aufbereiten und speichern sowie Auswertungsund Präsentationsfunktionalitäten anbieten. 9 Abbildung 1, unterschiedliche Facetten und Abgrenzungen von Business Intelligence. 10 Durch diese Annäherung leitet Gluchowski eine treffendere Definition von Business Intelligence her: Zusammenfassend lässt sich Business Intelligence damit (zumindest nach dem weiten BI-Begriffsverständnis ( )) als begriffliche Klammer verstehen, die unterschiedliche Technologien und Konzepte im Umfeld der entscheidungsunterstützenden Systeme zusammenführt und dabei eine entscheidungsorientierte Sammlung und Aufbereitung von Daten über das Unternehmen und dessen Umwelt sowie deren Darstellung in Form von geschäftsrelevanten Informationen für Analyse-, Planungs- und Steuerungszwecke zum Gegenstand hat. Im Einzelnen handelt es sich hierbei um Komponenten zur Extraktion, Bereinigung, Transformation, Integration, Speicherung und entscheidungsorientierten Aufbereitung 8 Vgl. Gluchowski/Gabriel/Dittmar (2008),S. 90; Gluchowski (2001), S Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 91; Gluchowski (2001), S Übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 92 in Anlehnung an Gluchowski (2001), S. 7.

18 2 Business Intelligence und Reporting S e i t e 17 relevanter Informationen sowie um die Bausteine zur Präsentation und Analyse dieser Inhalte Architektur Die idealtypische Architektur von BI-Systemen lässt sich in drei Schichten aufteilen: Datenbereitstellung, Analyse (Datenauswertung) und Präsentation (vgl. Abbildung 2). Zugriff und Ausgabe Präsentationsschicht Untersuchung und Auswertung (Analysesysteme) Analyseschicht Speicherung (Data Warehouse) Aufbereitung (ETL-Systeme) Datenbereitstellungsschicht -Operative Vorsysteme -Externe Daten Abbildung 2, BI-Schichtenmodell. 12 Die Basis von BI-Architekturen bildet die Datenbereitstellungsschicht. Diese Schicht stellt die Daten zur Verfügung, die in den darauf aufbauenden Schichten verwendet werden. Die Datenbereitstellung wird in zwei weitere Unterschichten aufgeteilt: Speicherungs- und Aufbereitungsschicht. In der Aufbereitungsschicht werden die Daten aus unterschiedlichen Quellen extrahiert, transformiert und anschließend an die Speicherungsschicht weitergegeben, wo die Daten abgelegt werden. Die Speicherungsschicht wird durch den Einsatz von Datenbanken realisiert, die eine analytische Orientierung aufweisen. Solche Datenbanklösungen werden als Data 11 Gluchowski/Gabriel/Dittmar (2008), S Abgeändert übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 109, vgl. u.a. Kemper/Mehanna/Unger (2006), S. 10.

19 2 Business Intelligence und Reporting S e i t e 18 Warehouse 13 bezeichnet. In der Analyseschicht werden die Daten aus der Bereitstellungschicht nach verschiedenen Kriterien untersucht und ausgewertet. Die Präsentationsschicht ist für die Darstellung der abgerufenen Informationen durch den Endbenutzer zuständig. Die einzelnen Werkzeuge lassen sich nicht immer trennscharf der Analyse- oder Präsentationsschicht zuordnen. Die Werkzeuge aus der Analyseschicht verfügen auch über Präsentationsmöglichkeiten, wobei aber der Schwerpunkt auf den Analysetechniken liegt. Sowie die Werkzeuge aus der Präsentationsschicht über rudimentäre Analysetechniken (z.b. Summation) verfügen können, der Schwerpunkt hier aber auf der Präsentation liegt. 14 Als Beispiel lassen sich die Reporting-Werkzeuge in die Präsentationsschicht einordnen. Die Reporting-Werkzeuge sind sehr auf die Darstellung der Informationen ausgelegt. Dabei wird ein sehr großer Wert auf die Gestaltungsmöglichkeiten der Berichte gelegt. Die Gestaltungsoptionen in heutigen Reporting-Anwendungen reichen von statischem Text über Kopf- und Fußzeilen bis hin zu freiplatzierbaren und formatierbaren Tabellenfeldern sowie grafischen Objekten Einordnung des Berichtswesens Unter dem Begriff des betrieblichen Berichtswesens wird die Erzeugung und Bereitstellung der Berichte zusammengefasst. Dazu gehören auch alle Personen, Organisationseinheiten, Vorschriften, Daten und Prozesse, die an der Erzeugung und Bereitstellung beteiligt sind. Wobei man unter dem Begriff Berichte Dokumente versteht, die unterschiedliche Informationen in aufbereiteter und kombinierter Form enthalten. 16 Die Abbildung 3 zeigt aus welchen Prozessen das betriebliche Berichtswesen sich zusammensetzt. Diese Prozesse werden in unterschiedlicher Art und Weise von den BI- Werkzeugen und Technologien (Data Warehouse, Reporting- und Analyse-Systeme) unterstütz Die Data Warehouse-, OLAP- und ETL-Konzepte werden in dieser Arbeit nicht näher erläutert, diese werden in folgender Fachliteratur beschrieben: Chamoni (2003); Chamoni/Gluchowski (2006); Gluchowski/Chamoni (2006); Gluchowski/Kemper (2006); Grothe (2000); Kemper/Mehanna/Unger (2006); Mertens (2002); Mucksch (2006); Schelp (2006); Gluchowski/Gabriel/Dittmar (2008); Strauch/Winter (2002); Kemper/Lee (2001); Gluchowski (2001). 14 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 108; Kemper/Mehanna/Unger (2006), S. 10; Gluchowski/Kemper (2006). 15 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 205, 212; Heine/Wende (2004), S. 340 ff. 16 Vgl. Kemper/Mehanna/Unger (2006), S. 110; Gluchowski (2006), S Kemper/Mehanna/Unger (2006), S. 110; Gluchowski (2006), S. 209; Heine/Wende (2004), S. 331 ff.

20 2 Business Intelligence und Reporting S e i t e 19 Berichtsgestaltung und -erstellung Berichtsverteilung Berichtsverwaltung Berichtsaufnahme und -diskussion Abbildung 3, Prozesse des betrieblichen Berichtswesens. 18 Bei dem Prozess Berichtsgestaltung werden Layout und Platzhalter für die Daten in einem Bericht definiert. Sie werden bei Berichtserstellung mit Daten ausgefüllt. Der fertige Bericht wird an die Empfänger verteilt. Wobei der Bericht für spätere Nutzung in der Berichtsverwaltung aufgenommen wird. Somit kann der Empfänger die Informationen aus dem Bericht direkt aufnehmen oder später abrufen Berichtsgestaltung Die Berichte lassen sich nach bestimmten Kriterien kennzeichnen und einordnen. Dazu gehören die Kriterienklassen wie Zweck, Inhalt, Form, Zeit sowie die Instanz. Der Berichtszweck hat die zentrale Bedeutung bei der Gestaltung der Berichte. Ist der Zweck des Berichtes nicht bestimmbar, so kann seine Existenzberechtigung in Frage gestellt werden. Die enthaltenen Sachverhalte der Realität werden mit dem Berichtsinhalt klassifiziert. Die Einteilung kann hier entlang der einzelnen Funktionalbereiche oder vergleichbarer thematischer Kriterien erfolgen. Für die Nützlichkeit eines Berichts ist die geeignete Detaillierung der vorliegenden Informationen wichtig. Das Informationsspektrum sollte dabei angemessen breit ausgelegt werden. Bei den dargebotenen Informationen sollte man drauf achten, dass diese möglicherweise ungenaue Angaben haben können Modifiziert übernommen aus Kemper/Mehanna/Unger (2006), S Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 207; Gluchowski (2006), S. 210.

21 2 Business Intelligence und Reporting S e i t e 20 Abbildung 4, Merkmale zur Kennzeichnung und Gestaltung von Berichten. 20 Die Berichte unterscheiden sich durch Informationen, die in unterschiedlicher Weise dargestellt werden können. Die Informationen lassen sich in grafischer und textlicher Berichtsform einzeln oder gemischt darstellen. Bei der grafischen Darstellung werden Geschäftsgrafiken wie Kreis-, Balken- oder Säulendiagramme verwendet. Zu der textlichen Form gehören die tabellarische Präsentationsform von Informationen, sowie auch ausformulierte Langtexte. Wegen der Übersichtlichkeit und Verständlichkeit sollten die Berichtsobjekte strukturiert angeordnet werden. Dies wird üblicherweise mit den Adressaten abgestimmt, um ein einheitliches Aufbau zu erreichen. Bei der Wahl des Präsentationsmediums kann die Unterscheidung zwischen elektronischer und papiergebundener Ausgabeform vorgenommen werden. Von dieser Unterscheidung ist auch der Übertragungsweg abhängig. 21 Wenn die Berichte in bestimmten Berichtsintervallen erzeugen werden, so spielt hier der zeitliche Gesichtspunkt eine Rolle. Werden die Berichte in regelmäßigen Intervallen erzeugt, so handelt es sich um periodische Berichte. Solche Berichte beziehen sich zumeist auf abgelaufene Perioden. Berichte, die in unregelmäßigen Intervallen erzeugt werden, werden als aperiodische Berichte bezeichnet. Diese Berichte werden bei einer 20 Gluchowski/Gabriel/Dittmar (2008), S. 208; Gluchowski (2006), S Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 208; Gluchowski (2006), S. 211.

22 2 Business Intelligence und Reporting S e i t e 21 bestimmten Abweichung in den Sollwerten erstellt. Solche Berichte lassen sich für die Früherkennung bzw. Frühwarnung nutzen, da diese auf kurzfristige Ereignisse hinweisen und mit einem dringenden Handlungsbedarf verknüpft sind. 22 Aufbau und Inhalt des Berichtes hängen von den Anforderungen des Empfängers bzw. der Empfängergruppen ab, dabei sollte der genaue Informationsbedarf erhoben werden, um die Berichte an die Bedürfnisse der Verwender auszurichten. Wichtig ist auch zu klären, welche Mitarbeiter für die zeitgerechte Anfertigung der Berichte verantwortlich sind. Hierbei kann zwischen der inhaltlichen und technischen Verantwortung unterschieden werden Open Source Open Source ist aus dem unternehmerischen Umfeld nicht mehr wegzudenken. In den letzten Jahren ist der Marktanteil von Open Source kontinuierlich gestiegen. Dies ergab eine Studie der Europäischen Kommission 24. Die offizielle Definition von Open Source lautet: Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria 25. Das bedeutet, dass nicht nur die Verfügbarkeit des Quelltextes, sondern auch die Lizenzbestimmungen für die Weitergabe wichtig sind, unter denen eine Software als Open Source Software vertrieben oder angeboten werden darf. Die Lizenzbestimmungen müssen den charakteristischen Merkmalen der Open Source Definition (OSD) entsprechen Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 209; Gluchowski (2006), S Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 209; Gluchowski (2006), S MERIT (2006) 25 Open Source Definition (2008) 26 Open Source Definition (2008)

23 S e i t e Vorbereitung der Evaluierung 3.1. Evaluierungs-Model Um ein methodisches Vorgehen zu gewährleisten, wurde für die Evaluierung das Business Readiness Rating Model (BRR) 27 zur Bewertung von Open Source Software verwendet 28. Dieses Model wurde von Carnegie Mellon West Center for Open Source Investigation, O'Reilly CodeZoo, SpikeSource und Intel Corporation entwickelt. Das Model ist in 4 Phasen gegliedert (Abbildung 5). Abbildung 5, 4 Phasen des BRR-Models. Phase 1 Quick assessment: In dieser Phase werden die Komponenten ausgewählt, die evaluiert werden sollen. Nach der Auswahl werden KO-Kriterien für die Vorbewertung (engl. quick assessment ) definiert, die auf die ausgewählten Komponenten angewendet werden. Zum Schluss der Phase werden die Komponenten aussortiert, die nicht die Kriterien erfüllen. Phase 2 Target usage assessment: In dieser Phase werden die Gewichtungen für die Kategorien und Metriken bestimmt. In dem Model gibt es zwölf Kategorien: Functionality, Usability, Quality, Security, 27 BRR (2005) 28 Anhand der Evaluierung in Deprez/Alexandre (2008).

24 3 Vorbereitung der Evaluierung S e i t e 23 Performance, Scalability, Architecture, Support, Documentation, Adoption, Community und Professionalism. (Die einzelnen Kategorien werden in einem späteren Kapitel näher erläutert.) Bei der Bestimmung werden zunächst die einzelnen Kategorien nach Wichtigkeit sortiert. Dazu wird eine Zahl von 1 bis 12 zugewiesen. Dabei steht die 1 für sehr wichtig bis 12 nicht wichtig. Danach werden die Top 7 Kategorien (oder weniger) ausgewählt und diesen Kategorien die Gewichtung in Prozent zugewiesen. Die Gewichtungen müssen in der Summe 100% ergeben. In jeder Kategorie befinden sich eine oder mehrere Metriken, die mit Gewichtungen versehen werden. Als Metrik wird in diesem Zusammenhang ein Kriterium verstanden, welches zur Bewertung herangezogen wird. Die Summe der Gewichtungen für die Metriken in einer Kategorie muss 100% ergeben. Es besteht die Möglichkeit, die nicht benötigten Metriken mit 0% zu gewichten. Phase 3 Data collection and processing: Für die ausgewählten Anwendungen werden Daten gesammelt. Die gesammelten Daten werden auf die einzelnen Metriken in ausgewählten Kategorien angewendet. Jede Metrik besitzt eine Bewertung von 1 bis 5, dabei ist 1 die schlechteste Note und 5 die beste. Nach der Notenvergabe werden die gewichteten Werte für die einzelnen Metriken berechnet. Phase 4 Data translation: In dieser Phase werden die gewichteten Werte der einzelnen Kategorien aus den gewichteten Werten der Metriken berechnet. Abschließend wird aus den gewichteten Werten der Kategorien die BRR-Punktezahl berechnet Kriterienkatalog Kriterien für Vorbewertung Für die Vorbewertung (engl. quick assessment ) wurden folgende KO-Kriterien ermittelt: 1. Nach dem ersten Release ist mehr als ein Jahr vergangen. 2. Release-Zyklus liegt unter sechs Monaten. 3. Projekt wurde in der Programmiersprache Java entwickelt. 4. Projekt besitzt eigene Reporting-Engine.

25 3 Vorbereitung der Evaluierung S e i t e Kriterien für Hauptbewertung Functionality-Kategorie In dieser Kategorie werden diejenigen Funktionalitäten der Anwendung ausgewählt und bewertet, die den Anforderungen der Anwender entsprechen. Dabei werden die Funktionalitäten in zwei Arten unterteilt: Standardfunktionalitäten und Zusatzfunktionalitäten. Alle Funktionalitäten werden mit einer Gewichtung von 1 bis 3 versehen, dabei steht 1 für weniger Wichtig und 3 für sehr Wichtig. Bei der Bewertung der Standardfunktionalitäten bekommt die Funktionalität einen positiven Gewichtungswert als Bewertung, wenn sie von der Anwendung unterstützt wird. Wird die Funktionalität hingegen nicht unterstütz, so wird eine negative Gewichtung als Bewertung abgegeben. Beispielsweise hat eine bestimmte Funktionalität die Gewichtung 3, wird diese von Software A unterstützt, so bekommt diese Software als Bewertung eine 3. Die Software B unterstützt diese Funktionalität nicht, deswegen wird als Bewertung eine -3 vergeben. Die Zusatzfunktionalitäten werden etwas anders bewertet. Ist eine Funktionalität vorhanden, bekommt diese die gleiche Bewertung wie die Gewichtung. Wird die Funktionalität nicht unterstützt, wird als Bewertung eine 0 vergeben. Beispielsweise hat eine bestimmte Funktionalität die Gewichtung 2. Die Software A unterstützt diese Funktionalität, deswegen bekommt diese Software die Bewertung 2. Die Software B unterstützt diese Funktionalität nicht, deswegen wird bei dieser Software als Bewertung 0 eingetragen. Bei der Endbewertung in dieser Kategorie wird die Summe der Bewertung aller Funktionalitäten durch die Summe der Gewichtungen der Standardfunktionalitäten dividiert und mit 100 multipliziert, um die Bewertung in Prozent zu erhalten. A= B= C= Der Prozentwert wird in eine Bewertung von 1 bis 5 umgerechnet, dazu wird folgende Zuweisung verwendet: 29 Vgl. BRR (2005).

26 3 Vorbereitung der Evaluierung S e i t e 25 Prozentgrenzwerte Bewertung Mangelhaft 0% 1 Ausreichend 65% 2 Befriedigend 80% 3 Gut 90% 4 Sehr gut 96% 5 Tabelle 1, Umrechnung für die Endbewertung in der Kategorie Functionality Vorteil bei dieser Bewertung ist, dass eine Anwendung nicht bestraft wird, weil diese nicht alle oder nur wenige Standardfunktionalitäten unterstützt, dafür aber viele Zusatzfunktionalitäten anbietet Usability-Kategorie In der Usability-Kategorie wird die Benutzerfreundlichkeit der Software bewertet. Dabei wird geprüft, ob die Benutzeroberfläche einfach für den Endbenutzer zu verwenden ist. Außerdem wird die Zeit, die benötigt wird, um die Software zu installieren und zu konfigurieren, gemessen und bewertet. Metrik: Endbenutzer UI-Erfahrung Beschreibung: Hier wird gemessen, wie gut die UI durch den Endbenutzer akzeptiert wird. Es werden die Navigation, die intuitive Bedienbarkeit des Interfaces und das Steuerungssystem bewertet. Bewertung: 5 - Einfach und Intuitiv, die Informationen sind gut organisiert, das Handbuch wird nicht benötigt. 3 - Benötigt ein wenig Einarbeitungszeit, die Informationen sind etwas organisiert, das Handbuch wird benötigt. 1 - Komplex, zu viele Informationen, keine offensichtliche Organisation, kann ohne Handbuch nicht verwendet werden. Metrik: Zeit für Installation der erforderlichen Software, die die Open- Source-Software voraussetzt. Beschreibung: Mit dieser Metrik wird gemessen, wie viel Zeit/Anstrengung man benötigt, um die erforderliche Software zu installieren, die zum Installieren und Ausführen von der Open-Source-Software benötigt wird. Die Messung beinhaltet nicht das Einspielen des Betriebssystems. Bewertung: 5 - < 10 Minuten

27 3 Vorbereitung der Evaluierung S e i t e Minuten 3-30 min - 1 Stunde Stunden 1 - > 4 Stunden Metrik: Zeit für die Installation und Konfiguration von der Software. Beschreibung: Hier wird gemessen, wie viel Zeit man für die Installation und Konfiguration benötigt, damit die Software so schnell wie möglich lauffähig ist. Bewertung: 5 - < 10 Minuten Minuten 3-30 min - 1 Stunde Stunden 1 - > 4 Stunden Tabelle 2, Metriken aus der Kategorie Usability Quality-Kategorie Bei dieser Kategorie wird die Qualität der Software gemessen. Dazu werden mehrere Metriken angewendet, die die Code- und Design-Qualität bewerten. Außerdem wird bewertet, wie vollständig und fehlerfrei die Software ist. Metrik: Anzahl der Minor Releases in den letzten 12 Monaten. Beschreibung: Diese Metrik misst die geplanten Updates und Fehlerkorrekturen. Typische Minor Releases sind Services Packs in den kommerziellen Produkten. Bewertung: 5-2 Releases 3-1 oder 3 Releases 1-0 oder >3 Releases Metrik: Anzahl der Point/Patch Releases in den letzten 12 Monaten. Beschreibung: Typische, offizielle Poin/Patch Releases beinhalten Korrekturen für P1 Fehler, wie Deadlock-, Speicher- und Sicherheitsschwachstellen. Bewertung: Releases oder 5 6 Releases

28 3 Vorbereitung der Evaluierung S e i t e oder > 6 Releases Metrik: Anzahl der offenen Fehler in den letzten 6 Monaten. Beschreibung: In dieser Metrik wird die Qualität der Produkt-Nutzung gemessen. Bewertung: 5 - < 50 Fehler Fehler Fehler Fehler 1 - > 1000 Fehler Metrik: Anzahl der behobenen Fehler in den letzten 6 Monaten Beschreibung: Mit dieser Metrik wird gemessen, wie schnell die Fehler behoben werden im Vergleich zu den geöffneten Fehlern. Bewertung: 5 - > 75% 4-60% - 75% 3-45% - 60% 2-25% - 45% 1 - < 25% Metrik: Anzahl der geöffneten P1/kritischen Fehler. Beschreibung: Diese Metrik misst die Schwere der gefundenen Qualitätsmängel. Bewertung: 5-0 Fehler Fehler Fehler Fehler 1 - > 20 Fehler Metrik: Durchschnittliches Alter eines P1 Fehlers in den letzten 6 Monaten Beschreibung: Wie lange das Team braucht, um einen kritischen Fehler zu beheben, wird mit dieser Metrik gemessen. Bewertung: 5 - < 1 Woche

29 3 Vorbereitung der Evaluierung S e i t e Wochen Wochen Wochen 1 - > 4 Wochen Tabelle 3, Metriken aus der Kategorie Quality Security-Kategorie Die Security-Kategorie befasst sich mit der Sicherheit der Software. Hier werden Metriken verwendet, um die Sicherheit der Software zu bestimmen und den Umgang mit den Sicherheitsproblemen der Projekte zu bewerten. Metrik: Anzahl der Sicherheitslücken in den letzten 6 Monaten, die als extrem kritisch eingestuft wurden. Beschreibung: Diese Metrik misst die Qualität bezogen auf die Sicherheitslücken. Wie anfällig ist die Software für die Sicherheitslücken? Bewertung: 5-0 Sicherheitslücken Sicherheitslücken Sicherheitslücken Sicherheitslücken 1 - > 6 Sicherheitslücken Metrik: Anzahl der Sicherheitslücken, die noch offen sind (ungepatcht). Beschreibung: Hier wird gemessen, ob das Projekt in der Lage ist die Sicherheitsmängel zu beseitigen. Bewertung: 5-0 Sicherheitslücken 4-1 Sicherheitslücken 3-2 Sicherheitslücken Sicherheitslücken 1 - > 5 Sicherheitslücken Metrik: Gibt es bestimmte Informationen (Webseite, Wiki, etc.) für die Sicherheit? Beschreibung: Diese Metrik misst, ob die Sicherheitsprobleme bewusst und ernst von dem

30 3 Vorbereitung der Evaluierung S e i t e 29 Projekt-Team wahrgenommen werden. Bewertung: 5 - Ja, sehr gut gepflegt 3 - Ja 1 - Nein Tabelle 4, Metriken aus der Kategorie Security Performance-Kategorie Wie die Bezeichnung der Kategorie schon sagt, werden in dieser die Geschwindigkeit und die Optimierungsmöglichkeiten der Software bewertet. Metrik: Performance Tests und Benchmark-Berichte vorhanden. Beschreibung: Diese Metrik misst, ob Performance Tests und Benchmarks veröffentlicht wurden, die diese Software mit anderer äquivalenter Software vergleichen. Bewertung: 5 - Ja, mit sehr guten Ergebnissen 3 - Ja 1 - Nein Metrik: Performance Tuning und Konfiguration Beschreibung: Hier wird ermittelt, ob Dokumentationen oder Tools gibt, um die Performance der Komponenten zu optimieren(informationen über CPU, Festplatte, Netzwerk). Bewertung: 5 - Ja, sehr umfangreiche 3 - Ja, einige 1 - Nein Tabelle 5, Metriken aus der Kategorie Performance Scalability-Kategorie In dieser Kategorie wird die Skalierbarkeit der Software bewertet. Metrik: Referenz-Deployment Beschreibung: Diese Metrik misst, ob die Software in der Praxis getestet und skaliert wurde. Bewertung: 5 - Ja, mit veröffentlichten Benutzeranzahl 3 - Ja

31 3 Vorbereitung der Evaluierung S e i t e Nein Metrik: Konzipiert für Skalierbarkeit Beschreibung: Hier wird gemessen, ob die Komponente hinsichtlich der Skalierbarkeit konzipiert wurde. Ist es Thread-Sicher? Läuft es in einer Cluster- Umgebung? Kann die Hardware die Performance-Probleme lösen? Bewertung: 5 - Ja, umfangreich 3 - Ja, etwas 1 - Nein Tabelle 6, Metriken aus der Kategorie Scalability Architecture-Kategorie Diese Kategorie bewertet die Architektur der Software. Es werden unter anderem die Modularität, Portierbarkeit, Flexibilität, Erweiterbarkeit und Integration der Software bewertet. Metrik: Gibt es irgendwelche Drittanbieter Plug-ins? Beschreibung: Diese Metrik misst die Konzeption für die Erweiterbarkeit durch die Drittanbieter Plug-ins. Bewertung: 5 - >10 Plug-ins 4-6 bis 10 Plug-ins 3-2 bis 5 Plug-ins 2-1 Plug-in 1-0 Plug-ins Metrik: Öffentliche API/ externe Dienste Beschreibung: Hier wird gemessen, ob es möglich ist die Erweiterung über eine öffentliche API durchzuführen, und ob die Software für die Anpassung entworfen wurde. Bewertung: 5 - Ja, umfangreich 3 - Ja 1 - Nein Metrik: Ein- und Ausschalten von Funktionen durch Konfiguration

32 3 Vorbereitung der Evaluierung S e i t e 31 Beschreibung: Hier wird gemessen, ob ein Benutzer die Funktionalitäten durch die Konfiguration ein- und ausschalten kann. Bewertung: 5 - Ja, während der Laufzeit 3 - Ja, während der Kompilierung 1 - Nein Tabelle 7, Metriken aus der Kategorie Architecture Support-Kategorie In dieser Kategorie wird der Support der Firmen oder der Community bewertet, die hinter dieser Software stehen. Metrik: Durchschnittliches Volumen der Hauptmailinglist in den letzten 6 Monaten. Beschreibung: Die Hauptmailinglist ist der erste Anlaufpunkt für Benutzer, die kostenlose Hilfe benötigen. Bewertung: 5 - > 720 Nachrichten pro Monat 4 - [ ) Nachrichten pro Monat 3 - [ ) Nachrichten pro Monat 2 - [30 150) Nachrichten pro Monat 1 - < 30 Nachrichten pro Monat Metrik: Qualität von dem professionellen Support. Beschreibung: Professioneller Support, der bei der Optimierung der lokalen Installation und Problemen hilft. Bewertung: 5 - Installation-, Problemlösung-, Integration-/Anpassung- Support 3 - Nur Installationssupport 1 - Kein professioneller Support Tabelle 8, Metriken aus der Kategorie Support Documentation-Kategorie Die Qualität der Dokumentation, die die Firma oder die Community zu dieser Software anbieten, wird in dieser Kategorie bewertet.

33 3 Vorbereitung der Evaluierung S e i t e 32 Metrik: Vorhandensein von verschiedenen Dokumenten. Beschreibung: Eine gute Dokumentation sollte Dokumente für jede Nutzerschicht enthalten. Bewertung: 5 - Installations-/Veröffentlichungs-, Benutzer-, Administrations-, Optimierungs(Tuning)-, Aktualisierungs- und Entwickleranleitung sind in mehreren Formaten verfügbar (HTML Einzeldatei, HTML mehrere Dateien, PDF). 4 - Installations-/ Veröffentlichungs-, Benutzer-, Administrations- und Aktualisierungsdokumentation sind in mehreren Formaten verfügbar. 3 - Installations-/ Veröffentlichungs- und Benutzeranleitung ist verfügbar 2 - Nur ein textbasiertes Installationsdokument existiert. 1 - Keine echten Dokumente. Eine Readme-Datei wird nicht beachtet. Metrik: Framework für Benutzerbeiträge Beschreibung: Die besten Anleitungen werden von den Benutzern erstellt. Dies ist ein Feedback von den Benutzern, die das Produkt verwenden. Hier wird überprüft, ob es eine Möglichkeit besteht die Anleitung auf der Webseite des Projekts zu veröffentlichen und ob die veröffentlichte Anleitung von den Projektmitgliedern überprüft wird. Bewertung: 5 - Die Benutzer dürfen eigene Beiträge veröffentlichen und diese werden von den Experten kontrolliert. 3 - Die Benutzer dürfen eigene Beiträge veröffentlichen 1 - Die Benutzer dürfen keine Beiträge veröffentlichen Tabelle 9, Metriken aus der Kategorie Documentation Adoption-Kategorie Diese Kategorie bewertet den Einsatz der Software, durch die Community, Markt und die Industrie. Metrik: Wie viele Bücher gibt Amazon.com bei der Suche aus? Beschreibung: Die Verfügbarkeit von den Büchern zeigt, wie gut das Projekt angenommen wurde. Für die Messung wird von Amazon.com die

34 3 Vorbereitung der Evaluierung S e i t e 33 Advanced Search mit folgenden Suchkriterien verwendet: subject:computer und title:komponentenname. Bewertung: 5 - >=15 Bücher 4 - [6 15) Bücher 3 - [3 6) Bücher 2 - [1 3) Bücher 1-0 Bücher Metrik: Referenz-Deployment Beschreibung: Diese Metrik misst, ob die Software in der Praxis getestet und skaliert wurde durch einen praktischen Einsatz. Bewertung: 5 - Ja, mit veröffentlichten Benutzeranzahl 3 - Ja 1 - Nein Tabelle 10, Metriken aus der Kategorie Adoption Community-Kategorie Die Aktivität und die Lebhaftigkeit der Community, die hinter der Software steht, werden in dieser Kategorie bewertet. Metrik: Durchschnittliches Volumen einer Hauptmailinglist in den letzten 6 Monaten. Beschreibung: Die Hauptmailinglist ist der Platz, wo die Community-Mitglieder einander helfen. Bewertung: 5 - > 720 Nachrichten pro Monat 4 - [ ) Nachrichten pro Monat 3 - [ ) Nachrichten pro Monat 2 - [30 150) Nachrichten pro Monat 1 - < 30 Nachrichten pro Monat Metrik: Anzahl von eindeutigen Quellcode-Beitragenden in den letzten 6 Monaten. Beschreibung: Normalerweise fördern die Quellcode-Beitragenden den Community- Aufbau rund um das Projekt. Je mehr Quellcode-Beitragenden, desto besser

35 3 Vorbereitung der Evaluierung S e i t e 34 ist der Community-Support. Bewertung: 5 - >= 50 Beitragenden 4 - [20 50) Beitragenden 3 - [10 20) Beitragenden 2 - [5 10) Beitragenden 1 - <5 Beitragenden Tabelle 11, Metriken aus der Kategorie Community Professionalism-Kategorie Die Professionalität, die hinter Entwicklungsprozess und Projektorganisation steht, wird in dieser Kategorie bewertet. Metrik: Projekt Treiber Beschreibung: Der Projekt Treiber übernimmt das Projektmanagement, Ressourcenverteilung, usw. Bewertung: 5 - Unabhängige Gemeinschaft, die von Kapitalgesellschaften unterstütz wird (z.b. Apache, Eclipse) 4 - Kapitalgesellschaften (z.b. MySQL) 2 - Gruppen 1 - Personen Metrik: Schwierigkeit, um in das Kernentwicklerteam zu kommen. Beschreibung: Um die Softwarequalität zu gewährleisten, müssen ausgereifte Projekte selektiv bei der Akzeptanz von neuen Committern vorgehen. Bewertung: 5 - Erst wenn man nach außen ein aktiver Committer für eine Weile war. 3 - Ziemlich schwierig, man muss eine Zeit lang Patches ausgeliefert haben, die akzeptiert wurden 1 - Jeder kann rein Tabelle 12, Metriken aus der Kategorie Professionalism.

36 3 Vorbereitung der Evaluierung S e i t e Testberichte Einleitung Um die Performance- und Speicherauslastungsmessungen durchzuführen, wurden einige Testberichte entworfen, die von der Benchmarkanwendung als Vorlage verwendet werden. Die Testberichte stellen dabei die sinnvollen Kombinationsarten von Elementen in einem Bericht dar, die in einem Unternehmen angewendet werden können. Die Tabelle 13 gibt eine Übersicht über die Testberichte. Es wurden keine Drill-Down-Berichte entworfen, da einige der getesteten Reporting- Frameworks diese Art von Berichten in der Open-Source-Version nicht unterstützten Übersicht Name Berichtsbezeichnung Erläuterung Tabellen-Bericht Bericht 1 Eine Tabelle Dieser Bericht besitzt nur eine einzige Tabelle, die vorformatiert ausgegeben wird. Bericht 2 Mehrere Tabellen Es werden mehrere Tabellen in einem Bericht platziert. Beide Tabellen haben unterschiedliche Informationen, die dargestellt werden. Zusammengesetzte Berichte Bericht 3 Tabelle und Diagramm Bei einem zusammengesetzten Bericht werden eine Tabelle und ein Diagramm verwendet. Berichte mit Aggregation oder Gruppierung Bericht 4 Aggregation Dieser Bericht enthält eine Tabelle, bei der eine Zeile durch Aggregationen(Summation) berechnet wird. Dabei werden mehrere Aggregationen angewendet. Bericht 5 Gruppierung In diesem Bericht wird die Gruppierung verwendet, dabei wird eine bis zwei Spalten gruppiert. Sonstige Berichte Bericht 6 Sub-Berichte In diesem Bericht wird eine äußere Tabelle mit einer verschachtelten (inneren) Tabelle

37 3 Vorbereitung der Evaluierung S e i t e 36 Name Berichtsbezeichnung Erläuterung verwendet. Dabei generiert die innere Tabelle Daten durch einen Parameter, der von der äußeren Tabelle übergeben wurde. Tabelle 13, Übersicht: Testberichte Die entsprechenden Abbildungen zu den oben aufgeführten Berichten befinden sich im Anhang A Benchmarkanwendung Beschreibung Zur Performance- und Speicherauslastungmessung wurde eine Benchmarkanwendung entwickelt. Die Anwendung verwendet die vorgefertigten Testreports, die in dem jeweiligen Designer von den getesteten Reporting-Frameworks erstellt wurden. Die Testreports werden von der Anwendung in den Speicher geladen und an die ausgewählte Reporting-Frameworks übergeben. Die Frameworks beziehen die benötigten Daten aus der Datenbank und exportieren die Berichte in unterschiedliche Formate. Bei der Messung werden mehrere Durchläufe gemacht, damit die Messung genauer ist. Dabei werden die Zeit und der Speicherverbrauch ermittelt und gespeichert Architektur ReportBenchmark Klassendiagramm «uses» BenchmarkRunner +main(ein args : String[]) ReportingEngineFactory +createreportingengine(ein engine : String) : AReportingEngine «uses» «create» MemUtils +usedmemory() : long Stopwatch +start() : Stopwatch +stop() : Stopwatch +reset() : Stopwatch +getelapsedtime() : long «uses» «uses» AReportingEngine +computeperformanceresult() : String +initengine() #createhtmlreport(ein inputfile : File, ein count : int) #createpdfreport(ein inputfile : File, ein count : int) #createxlsreport(ein inputfile : File, ein count : int) +stopengine() Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung.

38 3 Vorbereitung der Evaluierung S e i t e 37 Die Architektur von der Anwendung wurde so aufgebaut, dass es möglich ist mehrere Reporting-Frameworks zu testen, ohne den kompletten Quellcode zu ändern. Dazu muss für das zu testende Framework eine Klasse implementiert werden, die von der abstrakten Klasse AReportingEngine erbt BenchmarkRunner Die BenchmarkRunner-Klasse ist die Hauptklasse der Anwendung und steuert diese. Für die Initialisierung der Reporting-Frameworks werden die übergebenen Parameter geparst und an die ReportingEngineFactory-Klasse weiter gegeben. Danach wird die Reporting-Engine initialisiert und die Berechnungen durchgeführt, abschließend wird die Reporting-Engine wieder gestopt ReportingEngineFactory Die ReportingEngineFactory-Klasse erzeugt anhand des übergebenen Parameters die entsprechende ReportingEngine-Klasse AReportingEngine Diese Klasse implementiert die Methode computeperformanceresult(). Diese Methode führt die Performance- und die Speicherauslastungstests durch. Außerdem kann diese Methode von den einzelnen Implementierungen nicht überschrieben werden. Bei der Erzeugung der einzelnen ReportingEngine-Klassen, muss man darauf achten, dass die Methoden initengine(), createhtmlreport(), createpdfreport(), createxlsreport() und stopengine() implementiert werden. Die Methode initengine() ist für die Initialisierung der Reporting-Engine zuständig. Die drei Methoden createhtmlreport(), createpdfreport() und createxlsreport() sind für die Erzeugung der Berichte zuständig, die in den Formaten HTML, PDF und XLS exportiert werden. Die Methode stopengine() führt die abschließenden Arbeiten durch und beendet die Reporting-Engine. Quellcode der Benchmarkanwendung befindet sich im Anhang B.

39 S e i t e Auswahl und Vorstellung der Frameworks 4.1. Softwareauswahl Nach der Internet- und Literaturrecherche 30 wurde eine Übersicht von verfügbaren Open Source BI-Lösungen aufgestellt, Tabelle 14. Dabei wurde darauf geachtet, dass die BI- Lösungen die Kriterien für die Vorbewertung aus dem Kapitel erfüllen. Projekt Aktuelle Version Erstes Release Designer Reporting- Engine Pentaho-BI Pentaho ReportDesigner JFreeReport BIRT BIRT Designer BIRT JasperIntelligence IReport JasperReports SpagoBI SpagoBIStudio JasperReports, BIRT openi JasperReports OpenReports JasperReports, JFreeReport, BIRT Tabelle 14, Übersicht von Open Source BI-Lösungen Aus der Übersicht geht hervor, dass einige der ausgewählten BI-Lösungen keine eigene Reporting-Engine benutzen, sondern eine vorhandene Reporting-Lösung aus anderen Open Source-Projekten verwenden. Die führenden Reporting-Projekte sind dabei JFreeReport von der Firma Pentaho, JasperReports von der Firma JasperSoft und BIRT von Eclipse Foundation initiiert und vorangetrieben von der Firma Actuate. Im weiteren Verlauf der Arbeit werden diese drei Reporting-Frameworks betrachtet und bewertet Pentaho Reporting Einführung Pentaho-Reporting ist ein Modul zum Erstellen von Berichten und ist ein Bestandteil von der Pentaho-BI-Suite. Dieses Modul wurde unter der Verwendung der Open Source 30 Held (2007); Kleijn (2006); Wayner (2008); Verity (2005)

40 4 Auswahl und Vorstellung der Frameworks S e i t e 39 Java-Bibliothek JFreeReport entwickelt. Die JFreeReport-Daten basieren auf dem Swing-TableModel-Interface. JFreeReport ist seit 2002 auf sourceforge registriert und wurde von der Firma Object-Refinery Ltd. bis 2006 gesponsert. Ab 2006 wurde JFreeReport von Pentaho übernommen. Der Projektleiter von JFreeReport Thomas Morgner wurde von Pentaho als Chief Architect of Reporting Solutions eingestellt. JFreeReport wurde daraufhin in Pentaho-Reporting-Engine umbenannt und wird jetzt von Pentaho weiterentwickelt. Bis zur Version gab es bei dieser Engine keine integrierte Unterstützung der Datenbanken, d.h. die Daten aus der Datenbank mussten manuell geladen und in TableModel umgewandelt werden, damit die Reporting-Engine mit ihnen arbeiten konnte Funktionsweise Die Reportentwicklung unter Pentaho-Reporting unterteilt sich in zwei Stufen: Designtime und Runtime, Abbildung 7. Pentaho Report Designer *.xml Extended Report Definition Pentaho Report Design Wizard Pentaho Reporting Engine HTML PDF Print XML... *.xaction Action Sequence Designtime Data JFreeReport Runtime Abbildung 7, Pentaho-Reporting High-Level-Architektur. Bei Pentaho-Reporting besteht die Möglichkeit in der Designtime einen Bericht durch den Pentaho-Report-Designer oder durch den Report-Design-Wizard zu entwerfen. Der Bericht kann dabei in eine einfache XML-Template-Datei (*.report) gespeichert werden. Da diese aber von der Reporting-Engine nicht akzeptiert wird, muss der Bericht exportiert werden. Nach dem Export erstellt der Designer zwei XML- Dateien (*.xaction und *.xml). In der Action-Datei (*.xaction) werden Aktionen definiert, die ausgeführt werden müssen, damit ein Bericht erzeugt werden kann. In der Extended-Report-Definition-Datei (*.xml) wird das komplette Report-Objekt in einem XML-Format beschrieben.

41 4 Auswahl und Vorstellung der Frameworks S e i t e 40 Für die Runtime werden beide XML-Dateien (*.xaction und *.xml) verwendet, um einen Bericht zu erzeugen. Die Action-Datei wird interpretiert und die Plattform führt die entsprechenden Module aus, die für die Aktionen benötigt werden. Verwendet man nicht die Plattform, sondern nur die Bibliothek, benötigt man die Action-Datei nicht. Damit die Bibliothek auf die Datenbank zugreifen kann, müssen die Verbindungsdaten und die benötigten Treiber-Definitionen manuell in die Extended-Report-Definition- Datei eingetragen werden Architektur Pentaho verwendet eine J2EE-Architektur. Die Pentaho Suite ist prozessorientiert aufgebaut. Es werden nicht Berichte, Datentransformationen oder andere Objekte ausgeführt, sondern Business Intelligence Prozesse. Die Prozesse werden durch Action Sequences beschrieben, die als XML-Dateien abgelegt werden. Eine Action Sequence kann mehrere Aktionen definieren. Um beispielsweise einen einfachen Bericht zu erzeugen, werden in der Action Sequence drei Aktionen definiert: Abfrage von Parametern, Abfrage von Daten aus einer Datenquelle und die Aufbereitung und Ausgabe von einem Bericht, Abbildung 8. Natürlich lassen sich auch aufwendigere Prozesse definieren, dazu werden Schleifen und Bedingungen bereitgestellt. Aufruf Action Sequence Action Sequence J2EE Server HTML Formular Formularparameter Prompt/Filter Action Parameter Web Browser Ergebnis SQL Rule Action Report Action SQL Abfrageergebnis Berichtsdefinition und Daten SQL Component Reporting Component SQL Ergebnis DBMS Bericht Bericht Berichtsdefinition und Daten Bericht Bericht Reporting Engine Abbildung 8, Pentaho Reporting Architektur. Durch die modulare Architektur können die Module einfach ausgetauscht werden. Für die Berichtserzeugung kann nicht nur die Pentaho Reporting Engine genutzt werden, sondern alternativ die Engine von JasperSoft oder die von BIRT. Hierfür stellt

42 4 Auswahl und Vorstellung der Frameworks S e i t e 41 Pentaho schon vorbereitete Module zur Verfügung. Durch die Modularisierung erreicht Pentaho eine sehr hohe Flexibilität. Der Nachteil dieser Flexibilität ist eine gewisse Unübersichtlichkeit. Natürlich lässt sich die Pentaho-Reporting-Engine auch ohne die BI-Suite einsetzen, dadurch entfallen die Action-Sequences. Die Aktionen, die von Action-Sequences ausgeführt werden, müssen dann programmatisch aufgerufen und ausgeführt werden JasperReports Einführung JasperReports ist eine Open Source Java-Bibliothek, die eine API (Application Programming Interface) anbietet, um Berichte zu erstellen. Damit ist es möglich JasperReports in jede Java-Anwendung einzubauen. Trotzdem wird JasperReports vorwiegend für Web-Applikationen verwendet, obwohl JasperReports keine Abhängigkeiten zu der vorhandenen Servlet-API oder den Java EE-Bibliotheken besitzt. Als Teodor Danciu 2001 beauftragt wurde in einem Projekt Reporting- Funktionalitäten zu implementieren, hat er eine Evaluierung von vorhandenen Reporting-Tools durchgeführt, dabei kam heraus, dass diese für das Projekt einfach zu teuer sind, deshalb hat er beschlossen ein eigenes Reporting-Tool zu schreiben. Das Projekt, für welches er das Reporting-Tool schreiben sollte, wurde abgebrochen, deshalb begann er in seiner Freizeit an JasperReports zu arbeiten. Das Projekt wurde im September 2001 bei Sourceforge.net angemeldet, aber noch kein Quellcode hochgeladen. Im November 2001 wurde JasperReports in der Version freigegeben holte die Firma Panscopic, die sich mit Embedded Reporting befasste, Teodor an Bord und änderten den Namen des Unternehmens in JasperSoft. Der offizielle Start als kommerzielles Unternehmen unter dem neuen Namen erfolgte im April JasperSoft sponserte die Entwicklung von JasperReports, dadurch konnten Teodor und andere JasperSoft-Entwickler in Vollzeit daran arbeiten Funktionsweise Die Reportentwicklung mit JasperReports unterteilt sich in zwei Stufen: Design- und Runtime, Abbildung 9.

43 4 Auswahl und Vorstellung der Frameworks S e i t e 42 IReport *.jrxml JasperAssistant XML Report Design Custom Report Designer Jasper Reporting Engine HTML PDF Print XML... Data Report Document *.jrprint Jasper Compiler *.jasper Native Binary Template Designtime Runtime Abbildung 9, JasperReports High-Level-Architektur. Zur Designtime wird mit dem Designer IReport oder einem anderen Designer ein Bericht erzeugt. Dieser wird als XML-Report-Template (*.jrxml) gespeichert. Bevor man den Bericht an die Jasper-Reporting-Engine übergibt, kann man diesen kompilieren. Das Kompilieren wird vom Designer bewerkstelligt. Als Ergebnis wird eine Native-Binary-Template-Datei (*.jasper) erzeugt. Man kann das Kompilieren auch außerhalb des Designers durchführen, indem man es programmatisch oder mit ANT realisiert. 31 Die Jasper-Reporting-Engine kann die XML-Report-Template-Datei auch direkt verarbeiten, diese wird von der Engine selbst kompiliert, aber keine Native- Binary-Template-Datei erzeugt. Um ein Bericht in der Runtime durch die Jasper-Reporting-Engine zu erzeugen, wird die Native-Binary-Template-Datei (*.jasper) verwendet. Die Engine holt die benötigten Daten aus den Datenquellen und bereitet diese auf, als Ergebnis erzeugt diese ein Report-Dokument, der in eine Datei (*.jrprint) gespeichert werden kann. Das Report- Dokument ist ein vollständiger Bericht, der zur Betrachtung, zum Drucken oder zum Exportieren geeignet ist. Das Report-Dokument kann von der Engine in verschiedene Formate wie z.b. in PDF oder HTML exportiert werden Architektur Die Architektur der JasperReports-Bibliothek ist modular aufgebaut, dadurch lässt sich diese in jede Java-Anwendung integrieren. Für einige Funktionalitäten, wie PDF-, 31 Vgl. Heffelfinger (2006), S. 16, 34,

44 4 Auswahl und Vorstellung der Frameworks S e i t e 43 SVG-, Word- und Excel-Exporte, verwendet JasperReports Fremdbibliotheken aus JRXML JasperReportingEngine parse JRXmlLoader Jasper- Design JasperCompile Manager compile JRCompiler Jasper- Report JDBC, JNDI SQL fill JasperFill Manager JRDataSource JNDI XQery, XPath EJB Hibernate POJO JasperPrint XML JasperExport Manager export print JasperPrint Manager XML HTML PDF Printer Screen Abbildung 10, Jasper-Reporting-Engine. 32 anderen Open Source Projekten. Außerdem stellt JasperReports eine API zur Verfügung, um bestimmte Funktionalitäten zu erweitern oder zu verändern. So ist es möglich eine eigene JRDataSource zu implementieren, um auf Datenbanken, die nicht durch JDBC kontaktiert werden können, oder andere Dateien zu zugreifen, Abbildung JasperDesign JasperDesign enthält das Rohmaterial des Berichtes, welches von der JasperReports- Bibliothek verwendet wird, um ein Bericht zu generieren. Die JRXMLLoader-Klasse erzeugt das JasperDesign, indem es die XML-Datei (*.jrxml) interpretiert. Es ist auch möglich JasperDesign programmiertechnisch zu ändern, indem man die JasperReports API verwendet. 32 Vgl. Danciu/Chirita (2007), S. 31.

45 4 Auswahl und Vorstellung der Frameworks S e i t e 44 Alle Instanzen von JasperDesign müssen kompiliert werden, bevor diese für die Datenaufbereitung und Berichtserzeugung genutzt werden können JasperReport JasperReport ist die kompilierte Version von JasperDesign. Diese wird durch den Kompilierprozess von JasperReports erstellt und ist bereit für die Datenaufbereitung und Berichtserstellung. Beim Kompilierprozess wird die Konsistenz geprüft und eine Reorganisation der Berichtselemente durchgeführt, um einen schnelleren Durchsatz in der Anwendung zu erzielen. Es wird zudem eine Klasse oder Script-Datei erstellt, je nachdem welcher Compiler verwendet wird, in der die Berichtsausdrücke (Variablen-, Text- und Bildausdrücke) gespeichert werden. Diese Klasse oder Script-Datei wird später während des Datenaufbereitungsprozesses zur Auswertung der Berichtsausdrücke verwendet JasperPrint Die Instanz von JasperPrint ist das Ergebnis des Datenaufbereitungsprozesses aus der JasperReports-Bibliothek, und stellt das proprietäre Format zur Speicherung von vollfunktionsfähigen und seitenorientierten Dokumenten dar. JasperPrint kann in verschiedene Formate, wie PDF, HTML, RTF, XLS und andere, transformiert, direkt durch den eingebauten Report-Viewer dargestellt oder auf die Festplatte gespeichert werden JasperCompileManager Der CompileManager stellt alle Kompilierungsfunktionalitäten der Bibliothek zur Verfügung. Dieser enthält Methoden, die dem Anwender die Kompilierung der JRXML-Datei, die von der Festplatte oder über einen Stream kommt, erlaubt. Das bedeutet, dass die Erzeugung des JasperDesigns intern abläuft und die Methoden direkt ein JasperReport-Objekt zurück liefern. Es stehen auch Methoden zur Verfügung, die die JRXML-Datei parsen und als Ergebnis einen JasperDesign-Objekt zurück liefern. Außerdem enthält der CompileManager einige Methoden zur Template-Verifizierung und JRXML-Datei-Erzeugung. Dies ist sehr nützlich für die GUI-Anwendung, über die ein Bericht entworfen werden kann JasperFillManager Der FillManager ist für die Datenaufbereitung zuständig. Er enthält mehrere Methoden, über die das Report-Template geladen und verarbeitet werden kann. Diese unterstützen

46 4 Auswahl und Vorstellung der Frameworks S e i t e 45 das Laden des Report-Templates aus einer Datei, einem Objekt oder auch aus einem Eingangs-Datenstrom. Außer dem Report-Template, benötigt der FillManager die Informationen über eine Datenquelle, aus der er die Daten beziehen soll. Es besteht auch die Möglichkeit bestimmte Report-Parameter zu übergeben, die zur Erzeugung des Berichts benötigt werden. Eine Vielzahl von Berichten benötigen die Daten aus einer relationalen Datenbank. Dazu stellt der FillManager einige Methoden bereit, die wiederum die Informationen zu einer Datenbankverbindung benötigen. Wenn diese Informationen übergeben werden, wird vom FillManager automatisch eine JRDataSource für den Zugriff auf die Datenbank über JDBC geladen. Möchte man die vorhandene JRDataSource nicht nutzen, kann man eine eigene JRDataSource erstellen, dazu muss beim Programmieren darauf geachtet werden, dass diese das Interface JRDataSource aus der JasperReports-Bibliothek implementiert JasperExportManager Der ExportManager bietet Methoden zum Transformieren von Report-Dokumenten (JasperPrint) in verschiedene Formate (PDF, HTML, CVS, RTF, XSL usw.). Es besteht auch die Möglichkeit die Daten aus verschiedenen Quellen zu erhalten und die Ergebnisse an verschiedene Ziele zu verschicken (Dateien, Eingangs- und Ausgangs- Datenströme, usw.) JasperPrintManager Der PrintManager bietet vorgefertigte Methoden, um das Report-Dokument oder nur Teile davon anzuzeigen oder zu drucken. Wenn ein Bericht an einen Drucker geschickt wird, besteht die Möglichkeit den Drucker über ein Druck-Dialog auszuwählen BIRT Einführung BIRT (Business Intelligence and Reporting Tools) ist ein auf Eclipse basierendes Open Source Projekt, welches Teile des Berichtswesen- und Business-Intelligence- Funktionalitäten für Rich Clients und Web-Applikationen zur Verfügung stellt. In der ersten Jahreshälfte 2004 wurde BIRT von der Firma Actuate Corporation finanziert und entwickelt. Am 24. August 2004 trat Actuate als strategischer Entwickler der Eclipse Foundation bei und schlug das BIRT-Projekt vor. Als das Projekt am

47 4 Auswahl und Vorstellung der Frameworks S e i t e Oktober 2004 akzeptiert und zu einem Top-Level-Projekt innerhalb der Eclipse- Community wurde, spendete Actuate die geleistete Arbeit Funktionsweise Die Reportentwicklung unter BIRT unterteilt sich in zwei Stufen: Designtime und Runtime, Abbildung 1. Die Aufteilung in die zwei Stufen hat den Vorteil, dass die Runtime auf einem Server oder in einer externen Anwendung platziert werden kann und so von der eigentlichen Reportentwicklung getrennt wird. Eclipse Report Designer Web Based Report Designer Report Design Engine Custom Report Designer... Report Engine Generation Services Charting Engine Presentation Services HTML PDF Print XML... *.rptdesign XML Report Design Data Report Document *.rptdocument Designtime Runtime Abbildung 11, BIRT High-Level Architektur. 33 In der Designtime wird der Report über einen vorhandenen oder eigenen Designer entworfen und an die Datenquellen angebunden. Die Designer verwenden die API von der Report-Design-Engine, um eine Report-Design-Datei (*.rptdesign) zu erzeugen. Diese wird standardmäßig als eine XML-Datei abgespeichert. Die erzeugte Design-Datei aus der Designtime wird in der Runtime verwendet, um den Report zu erstellen. Der Prozess der Erstellung läuft in zwei Phasen ab: Generierung und Präsentation (Rendern). Bei der Generierung werden in dem Generation-Service die Datenquellen abgefragt und die Daten aufbereitet, indem diese berechnet und transformiert werden. Als Ergebnis liefert Generation-Services ein Report-Document (*.rptdocument), in der die aufbereiteten Daten gespeichert werden. In der zweiten Phase rendert der Presentation-Service das Report-Document und erzeugt daraus HTML, PDF oder andere Formate. 33 Vgl. Eclipse-Birt (2008)b

48 4 Auswahl und Vorstellung der Frameworks S e i t e Architektur Die Architektur von BIRT ist sehr eng in die Architektur von Eclipse integriert, so dass BIRT aus Plug-ins besteht und dadurch dem Eclipse-Konzept folgt. Der Aufbau von BIRT lässt sich am besten als ein Gebäude darstellen. In den unteren Ebenen befinden sich die Eclipse-Platform und die Eclipse-Frameworks, die auf die Eclipse-Platform aufbauen. Die BIRT-Core-Components befinden sich in der Ebene drei. Sie verwenden die darunterliegenden Ebenen, in denen sich die Eclipse-Framworks und die Eclipse- Platform befinden. Die BIRT-Engines bauen auf den Core-Components auf und verwenden auch die darunterliegenden Ebenen. Die BIRT-Engines werden von BIRT verwendet, um bestimmte Aufgaben zu erledigen. Diese werden auf der obersten Ebene von den BIRT-Applikationen verwendet. Die BIRT-Applikationen teilen sich in zwei Teile auf: BIRT-Designers und BIRT-Run-time-Applications, Abbildung 12. In den nachfolgenden schematischen Darstellungen der BIRT-Architektur werden folgende Meta-Bezeichnungen verwendet: BIRT Report Designer massive Kästchen: eine Standardkomponente von BIRT. Report item extensions gestrichelte Kästchen: eine spezielle Komponente, die von einem Java-Entwickler verwendet werden kann. Chart engine gepunktete Kästchen: eine Standardkomponente von BIRT, die von anderen BIRT- Komponenten verwendet wird Applikationen BIRT bietet drei Hauptapplikationen an: BIRT Report Designer BIRT RCP Report Designer BIRT Report Viewer

49 4 Auswahl und Vorstellung der Frameworks S e i t e 48 BIRT applications BIRT designers BIRT run-time application BIRT Report Designer Chart Builder BIRT Report Viewer Custom Viewer... BIRT RCP Report Designer BIRT engines Design engine Report engine Chart engine Data engine Script engine Generation engine Presentation engine BIRT core component plug-ins Eclipse frameworks Data Tools Framework Graphical Framework Eclipse Modeling Framework Eclipse platforms Eclipse Tools Platform Eclipse Rich Client Platform Abbildung 12, BIRT Komponenten als Plug-ins für die Eclipse-Platform BIRT Report Designer und BIRT RCP Report Designer Der BIRT Report Designer ist ein grafisches Werkzeug mit dem Berichte entworfen werden. Er besteht aus mehren Eclipse-Plug-ins und wird in die Eclipse-Workbench integriert. Unter der Verwendung der Report-Design-Engine, erzeugt der BIRT Report Designer eine Report-Design-Datei. Report-Design-Dateien sind XML-Dateien, die auf der Syntax von Report Object Model (ROM) basieren. Der BIRT RCP Report Designer ist eine eigenständige RCP-Anwendung, die auf Eclipse-RCP basiert, und besitzt im Gegensatz zum BIRT Report Designer ein vereinfachtes Design-Interface. 34 Vgl. Weathersby/et al. (2006), S. 48.

50 4 Auswahl und Vorstellung der Frameworks S e i t e 49 BIRT Report Designer Tools to create and edit report components and rules, including: Bookmarks Charts Data sources Data filters Data groups Data mapping rules Data sets Expressions Highlighting rules Hyperlinks Library components Master pages Properties Report layout Report parameters Report XML Scripts Styles Report online explorer Data explorer Report item palette Library outline explorer Report online explorer Data previewer BIRT report viewer Data engine Design engine Report Object Model (ROM) Standard BIRT report items Report item extensions Data source ODA framework Custom data source Report library files (.rptlibrary) Report design (.rptdesign) Report template files (.rpttemplate) Web application Report previewer Custom Java application BIRT report viewer BIRT report viewer Report engine Abbildung 13, BIRT Report Designer: Beziehung zwischen Standard- und Spezialkomponenten. 35 Die Hauptunterschiede sind: BIRT RCP Report Designer kann zur gleichen Zeit nur eine einzige Design- Datei geöffnet haben. BIRT RCP Report Designer hat keinen integrierten Debugger. BIRT RCP Report Designer unterstütz die Java-Event-Handler nicht. 35 Vgl. Weathersby/et al. (2006), S. 49.

51 4 Auswahl und Vorstellung der Frameworks S e i t e 50 Die Report-Designer-Applikationen unterstützen eine Wiederverwendung von Report-Designs, indem diese als Templates abgespeichert werden können BIRT Report Viewer BIRT Report Viewer ist ein Java Web-Servlet, der aus dem Report-Design einen Report generiert und präsentiert. Dieser verwendet die Generation-Engine und den Report- Design, um ein Report-Document zu erzeugen. Weiterhin verwendet der Report Viewer die Presentation-Engine, um aus dem Report-Document einen Report zu erzeugen. Report design (.rptdesign) BIRT report viewer Report engine Generation engine Chart engine Design engine Report items Script engine Report executor Data engine Data transform engine Data access engine Report document (.rptdocument) Presentation engine ODA Framework Data source Custom data source Data Engine Data access engine Chart Engine Script engine Report renderer Emitters PDF emitter HTML emitter Custom emitter Report (PDF, HTML, Custom format) Abbildung 14, BIRT Report Viewer: Beziehung zwischen Standard- und Spezialkomponenten Weathersby/et al. (2006), S. 50.

52 4 Auswahl und Vorstellung der Frameworks S e i t e 51 Für die Berichts-Vorschau verwenden die Report Designer den BIRT Report Viewer, um den Bericht darzustellen. Der BIRT Report Viewer kann auf verschiedenen Servern eingesetzt werden, z.b. Apache Tomcat, IBM WebSphere oder BEA WebLogic, um einige davon zu nennen BIRT-Engines BIRT verwendet mehrere Engines, diese bieten eine API an, um bestimmte Funktionalitäten bereit zu stellen. Zum Beispiel bietet die BIRT Data Engine API für die Datenzugriffe an BIRT Chart-Engine Die Chart-Engine enthält APIs zur Generierung von Diagrammen und verbindet diese mit den Daten, die aus dem Data-Source kommen. Die Verwendung der Chart-Engine ist nicht nur auf BIRT begrenzt. Jede Java-Anwendung kann die Chart-Engine verwenden, um die Diagramme zu erzeugen und darzustellen. Der BIRT-Report-Viewer interpretiert die Chart-Design-Informationen aus der Report-Design-Datei und verwendet die Chart-Engine, um die Diagramme zu generieren BIRT Design-Engine Die Report-Design-Engine enthält APIs zur Validierung und Generierung von Report- Design-Dateien. Die Validierung und Generierung der Struktur von Report-Design- Datei wird anhand der ROM-Spezifikation durchgeführt. Diese Engine wird vom BIRT- Report-Designer und von einer individuellen Java-Anwendung verwendet, die eine Report-Design-Datei erstellen möchte. Die Generation-Engine verwendet auch die Report-Design-Engine zum Erzeugen der Report-Document-Datei BIRT Data-Engine Die Data-Engine enthält APIs zum Abrufen und Aufbereiten der Daten. Wenn die Data- Engine von der Generation-Engine verwendet wird, werden die Daten aus dem Data- Source geholt. Wird die Data-Engine von der Präsentation-Engine verwendet, werden die Daten aus dem Report-Document geladen. Die Daten-Engine besteht aus zwei Hauptkomponenten, der Data-Access- Komponente und der Data-Transform-Komponente. Die Data-Access-Komponente interagiert mit dem ODA-Framework, um Daten zu erhalten. Die Data-Transform- Komponente sortiert, gruppiert, aggregiert und filtert die Daten, die von der Data- Access-Komponente geliefert werden.

53 4 Auswahl und Vorstellung der Frameworks S e i t e 52 Das Open Data Access (ODA) Framework verwaltet ODA-Treiber und native Treiber. Es lädt die Treiber, öffnet Verbindungen und verwaltet die Abfragen. Das ODA-Framework verwendet das Data-Tools-Platform-Projekt zum Verwalten von Verbindungen. Durch die Erweiterungs-Punkte, die vom ODA-Framework angeboten werden, können eigene ODA-Treiber entwickelt und eingebunden werden. Die eigenen ODA-Treiber sind wichtig, wenn man eine Datenquelle verwenden möchte, die von BIRT nicht unterstütz wird BIRT Report-Engine Die Report-Engine besteht aus zwei Teilen, der Generation-Engine und der Presentation-Engine. Der BIRT-Report-Viewer und die individuell entwickelten Java- Applikationen verwenden die Report-Engine, um das Report-Design aufzubereiten und einen Bericht in einem bestimmten Format zu generieren BIRT Generation-Engine Die Generation-Engine enthält APIs zum Auslesen und zum Interpretieren von Report- Design. Um Daten aus dem Data-Source, der in dem Report-Design enthalten ist, zu bekommen und aufzubereiten, verwendet die Generation-Engine die Data-Engine. Als Ergebnis liefert die Generation-Engine ein Report-Document, welches das Zwischendokument bei der Erstellung eines Berichts ist BIRT Presentation-Engine Die Presentation-Engine verwendet das Report-Document, welcher von der Generation- Engine erzeugt wurde, und erstellt daraus einen Bericht in dem gewünschten Format. Wie die Generation-Engine, verwendet die Presentation-Engine die Data-Engine. Während des Präsentationsabschnitts werden die Daten von der Data-Engine aus dem Report-Document geladen. Für die formatspezifische Darstellung verwendet die Presentation-Engine die sogenannten Emitter. BIRT besitzt zwei Standard-Emitter: HTML und PDF (in der aktuellen Version von BIRT werden mehrere Emitter mitgeliefert, um einen Bericht im Word- oder Excel-Format darzustellen). Falls keine passenden Emitter für die Darstellung existieren, besteht die Möglichkeit eigene zu entwickeln. Die Chart-Report-Items und eigens entwickelte Report-Items erweitern die Presentation-Engine, damit diese auch dargestellt werden können.

54 S e i t e Durchführung der Evaluierung 5.1. Verteilung der Gewichtungen bei Kategorien Wie im Kapitel 3.1 beschrieben, müssen in der Phase 2 des BRR-Models zwölf Kategorien nach der Wichtigkeit geordnet und durchnummeriert werden. Aus zwölf Kategorien sollten die ersten sieben für die Gewichtung ausgewählt werden. Folgende Kategorien wurden ausgewählt und gewichtet: Grad Kategorie Gewichtung 1 Functionality 25% 2 Usability 20% 3 Documentation 15% 4 Quality 15% 5 Architecture 10% 6 Scalability 10% 7 Community 5% 8 Adoption 0% 9 Security 0% 10 Performance 0% 11 Support 0% 12 Professionalism 0% Tabelle 15, Kategorien mit Gewichtungen Die Kategorien Security, Performance, Support, Adoption und Professionalism fließen in die Bewertung nicht mit ein und werden im weiteren Verlauf der Arbeit nicht mehr betrachtet. Die Support-Kategorie wurde nicht in die Bewertung aufgenommen, da der Support, der von den Firmen angeboten wird, die hinter dem Projekt stehen, nicht kostenlos ist und dieser nur für die BI-Suiten angeboten wird. Da die Performance und Speicherauslastung im Rahmen dieser Arbeit gemessen werden, wurde die Performance-Kategorie nicht ausgewählt. Die Security-Kategorie wurde nicht ausgewählt, da die Metriken in dieser Kategorie nicht zu den ausgewählten Projekten passen. Bei den ausgewählten Frameworks wurde das Projekt von Unternehmen

55 5 Durchführung der Evaluierung S e i t e 54 initialisiert, und wird von diesen auch vorangetrieben und weiterentwickelt, wurde die Kategorie Professionalism nicht ausgewählt. Außerdem wird in dieser Kategorie gemessen, wie einfach man in das Core-Team beitreten kann, da dieses Vorhaben nicht verfolgt wird. Die wichtigsten der ausgewählten sieben Kategorien sind Functionality und Usability. Die Kategorie Functionality bekommt eine Gewichtung von 25% und die Kategorie Usability eine Gewichtung von 20%. Das ausgewählte Framework muss durch die angebotenen Funktionalitäten die Anforderungen, die an das Framework gestellt werden, abdecken. Wenn das nicht der Fall ist, kann das Framework nur begrenzt eingesetzt und genutzt werden. Desweiteren ist die Usability bei den angebotenen Reporting-Designern sehr wichtig. Wenn das Designer-Werkzeug nur begrenzt oder unbenutzbar ist, kann dieses die gestellten Anforderungen nicht erfüllen. Die Kategorien Documentation und Quality bekommen jeweils eine Gewichtung von 15%. Die Dokumentation eines Projekts ist wichtig bei Integration und Verwendung des Frameworks. Wenn die Dokumentation erhebliche Mängel aufweist oder gar nicht zur Verfügung steht, wird es sehr mühsam das Framework zu integrieren und zu verwenden. Die Qualität eines Frameworks ist maßgebend für den Einsatz. Wie oben schon beschrieben, wird die Qualität anhand der Releases, Patches und Anzahl der Fehler gemessen. Wenn ein Framework zu oft gepatcht wird, dann bedeutet das, dass das Framework nicht ausreichend getestet wurde und damit auch bei der Integration erhebliche Probleme bereiten kann. Bei der Anzahl der gemeldeten Fehler sollte man allerdings vorsichtig sein, denn je größer das Projekt ist, desto höher ist die Wahrscheinlichkeit, dass mehr Fehler auftreten können. Hierbei sollte man auf das Projekt-Team achten, wie dieses mit den Fehlern umgeht und wie schnell diese behoben werden. Wichtiger Punkt sind die regelmäßigen Releases; denn daran kann man erkennen, dass das Projekt weiter vorangetrieben wird. Die weiteren Kategorien Architecture und Scalability wurden mit einer Gewichtung von jeweils 10% gewertet. Bei der Integration eines Frameworks in die vorhandene Anwendung, sollte das Framework bestimmte Schnittstellen und eine entsprechende Architektur anbieten. Wenn das Framework keine sichtbare Architektur hat, wird es sehr schwierig dieses in eine Anwendung zu integrieren oder das Framework zu erweitern. Die Skalierbarkeit eines Frameworks ist maßgebend für den Einsatz. Ist ein Framework nicht skalierbar, ist ein Einsatz in einer Serveranwendung nicht

56 5 Durchführung der Evaluierung S e i t e 55 empfehlenswert. In diesem Fall muss erheblicher Aufwand betrieben werden, um das Framework skalierbar zu machen. Die Kategorie Community bekommt eine Gewichtung von 5%. Bei einem Framework ist seine Verbreitung und Akzeptanz durch die Community und die Industrie sehr wichtig. Wenn ein Framework nicht so weit verbreitet ist, besteht die Möglichkeit, dass die Entwicklung eingestellt wird, oder dass die Qualität der Software nicht gut genug ist, um diese in der Industrie einsetzen zu können. Natürlich ist auch die Community, die hinter einem Projekt steht, maßgebend für die Weiterentwicklung und den Support des Projektes. Die erste Anlaufstelle bei einem Problem ist meistens die Mailingliste oder das Forum, die beide durch die Community gepflegt werden Gewichtungen unter der Kategorie Functionality Die untenstehende Tabelle zeigt die ausgewählten Standardfunktionalitäten mit Gewichtungen, die ein Reporting-Framework unterstützen muss und die Zusatzfunktionalitäten, die ein Reporting-Framework haben kann. Die Funktionalitäten aus der Tabelle 16 wurden anhand der Anforderungen und angebotenen Funktionalitäten ausgewählt. Die Funktionalitäten wurden in vier Gruppen unterteilt: Ausgabeformate, Datenquellen, Diagramme und Reporting. Funktionalitäten Gewichtung Standardfunktionalitäten Ausgabeformate PDF 3 HTML 3 Excel 3 Word (DOC) 2 Word (RTF) 2 Datenquellen JDBC 3 Hibernate 2 Diagramme

57 5 Durchführung der Evaluierung S e i t e 56 Funktionalitäten Gewichtung Einbindung dynamischer Inhalte (Bilder, Texte) 3 Einbindung von Charts 3 Reporting Templating (Schablonen) 3 Verschiedene Datenquellen innerhalb eines Reports 3 Drill-Down-Analyse innerhalb eines Reports 2 Internationalisierung (Zeichensatz, Währung..) 3 Unterstützt Sub-Reports (Verschachtelung) 2 Parametrisierte Reports 3 Aggregationen und Gruppierung 2 Zusatzfunktionalitäten Ausgabeformate TXT 1 PPT 1 OpenOffice (ODT) 1 XML 1 CSV 2 SVG (Scalable Vector Graphics) 1 Datenquellen POJO/Java Beans 2 CSV 1 XML 1 Web Services 1 XML/A,MDX 1 Metadatenunterstützung 1

58 5 Durchführung der Evaluierung S e i t e 57 Funktionalitäten Gewichtung Reporting Preview Funktionalität 2 Scheduler für Reportgenerierung 2 Bursting (Verteilung) 2 View Engine für Web-Applikation 2 View Engine für Desktop-Anwendung 2 Report-Entwurf aus Web-Applikation 1 Pixelgenaue Report-Erstellung 2 Cross-Tab Unterstützung 2 Tabelle 16, Übersicht: Gewichtungen von Funktionalitäten. Die Ausgabeformate beinhalten die Datei-Formate in die ein Bericht exportiert werden kann. Dabei wurden die Formate PDF, HTML und Excel als sehr wichtig gewichtet, da dies die gängigsten Formate in der Praxis sind. Vor allem ist das HTML- Format für die Darstellung der Berichte durch eine Web-Anwendung unabdingbar. Als wichtig wurden die Formate DOC, RTF und CSV gewichtet. Für weniger wichtig wurden die Formate TXT, PPT, ODT, XML und SVG gewichtet. Die Datenquellen sind für eine Reporting-Anwendung notwendig, da zum Aufbereiten und Erstellen der Berichte Daten für den Inhalt benötigt werden. Die wichtigste Datenquelle ist dabei JDBC. Durch die angebotenen JDBC-Treiber ist es möglich die Daten aus jeder Datenbank in einem Reporting-Framework zu verwenden. Für wichtig wurden die Datenquellen Hibernate und POJO befunden, da diese meistens in einer Serveranwendung verwendet werden. Durch das Einbinden von dynamischen Inhalten, wie Text und Bilder, besteht die Möglichkeit, die Berichte verständlicher und angepasster an das Corporate Design des Unternehmens zu gestallten, deswegen wurde diese Kategorie als sehr wichtig bewertet. Das Einbinden von Charts in einen Bericht ist sehr wichtig, dadurch kann man die angebotenen Informationen, die in den Tabellen platziert sind, ergänzen und die wichtigsten Ergebnisse grafisch darstellen. Die letzte Gruppe Reporting fasst die Reporting-spezifischen Funktionalitäten zusammen. In dieser Gruppe sind die Funktionalitäten der Server-Anwendungen und

59 5 Durchführung der Evaluierung S e i t e 58 der Report-Designer gemischt. Als sehr wichtig wurden die Funktionalitäten Templating, verschiedene Datenquellen innerhalb eines Reports, Internationalisierung und parametrisierte Reports bewertet. Das Templating ist beim Entwerfen der Berichte sehr wichtig, da man dadurch eine Schablone erstellen kann, die ein Corporate Design des Unternehmens besitzt oder eine bestimmte Struktur des Berichtes beinhaltet. So kann man die Schablone für jeden einzelnen Report verwenden, ohne diesen immer wieder neu zu entwerfen. Die Möglichkeit verschiedene Datenquellen innerhalb eines Reports zu verwenden, ermöglicht das Erstellen von Berichten mit mehreren Tabellen, die unterschiedliche Datenquellen haben und damit auch verschiedene Informationen anbieten. Die Internationalisierung innerhalb der Berichte spielt eine sehr große Rolle. Die automatische Unterstützung dieser Funktionalität ermöglicht das Erstellen von Berichten in unterschiedlichen Sprachen. Wenn diese Funktionalität nicht unterstützt wird, so müssen die Berichte für jede einzelne Sprache angepasst werden, was einen deutlichen Mehraufwand bei dem Entwerfen der Berichte darstellt. Für dynamisches Reporting sind die parametrisierten Berichte sehr wichtig, dabei kann man eine allgemeine SQL-Anweisung entwickeln und durch Parameter bestimmte Ergebnisse erhalten. Dieses Vorgehen wird als Beispiel bei den Berichten verwendet, die für einen bestimmten Zeitabschnitt oder für eine bestimmte Abteilung generiert werden sollen. Als wichtig wurden folgende Funktionalitäten bewertet: Drill-Down-Analyse innerhalb eines Reports, Sub-Reports (Verschachtelung), Aggregationen und Gruppierung, Preview Funktionalität, Scheduler für Reportgenerierung, Bursting zur Verteilung, eigene View Engine Web Applikation, Report View Engine, Reporterstellung aus Webapplikation, pixelgenaue Report-Erstellung und Cross-Tab Unterstützung. Für eine bessere Übersicht werden die komplexen Berichte verdichtet, dadurch ist es nicht ganz klar, wie die Kennzahl, die in dem verdichteten Bericht dargestellt werden, zustande gekommen sind. Die Funktionalität Drill-Down-Analyse hilft dabei die genaue Zusammensetzung der Kennzahlen zu verdeutlichen. Indem man auf eine Zahl klicken kann, wird man vom Reporting-Framework zu einem detaillierteren Bericht weitergeleitet. Dies muss aber nicht zwangsläufig sein. Die detaillierteren Angaben zu einer Kennzahl können auch am Ende eines Reports stehen, so dass die Auswahl der

60 5 Durchführung der Evaluierung S e i t e 59 Kennzahl dazu führt, dass die Anwendung automatisch auf den gleichen Bericht zeigt, nur wird ein anderer Abschnitt ausgewählt. Die Unterstützung der Sub-Reports(Verschachtelung) ist wichtig, da man dadurch in einer Tabelle noch Unter-Tabellen erstellen kann, die die ausgewählten Ergebnisse, weiter aufteilen und verdeutlichen. Die Aggregationen und Gruppierung in den Berichten sind sehr wichtig, damit kann man Gesamtergebnisse erzeugen und anzeigen lassen. Durch Aggregationen in den Berichten kann die Datenbank entlastet werden. Die Preview Funktionalität eines Berichtes ist bei der Gestaltung wichtig, damit kann die Voransicht des fertigen Berichts dargestellt werden. Die beiden Funktionalitäten Scheduler für Reportgenerierung und Bursting sind in einer Serverumgebung und in einem Unternehmen wichtig. Durch den Scheduler besteht die Möglichkeit, die Berichte in regelmäßigen Abständen automatisch zu erzeugen, dadurch kann man die Erzeugung der Berichte auf einen Zeitpunkt legen, an dem die Datenbank ausgelastet werden darf, da einige Berichte teilweise sehr komplexe SQLs enthalten können. Die Bursting Funktionalität bietet die Möglichkeit die Berichte automatisch an die Benutzer in regelmäßigen Abständen über s zu verteilen. Die Funktionalitäten View Engine für Web-Applikation und View Engine für Desktop-Anwendungen sind wichtig, um die Berichte dem Benutzer zu präsentieren. Möchte man die Berichte online präsentieren, so lässt sich das durch eine Web- Applikation umsetzten. Zu diesem Zweck ist es hilfreich, wenn ein Reporting- Framework diese Funktionalität anbietet, da man dadurch keine eigene Anwendung entwickeln muss. Durch die Funktionalität View Engine Applikation besteht die Möglichkeit die Darstellung von Berichten in eine bestehende Desktop-Anwendung zu integrieren. Reporting-Frameworks, die auf Programmiersprache Java basieren, bieten die Möglichkeit, diese Funktionalität in eine bestehende SWING- oder SWT- Anwendung zu integrieren. Die pixelgenaue Report-Erstellung ist bei dem Entwurf und der Erzeugung des Berichtes wichtig. Dadurch lassen sich die Berichte so entwerfen, dass diese in jedem Format (PDF, HTML, EXCEL usw.) gleich aussehen. Der Report-Entwurf aus den Web-Applikationen ist weniger wichtig, da die Anwender, die eine Reporting-Anwendung verwenden, eine genaue Kenntnis von der Tabellenstruktur der Datenbank besitzen müssen, um die SQLs zu entwickeln. Die

61 5 Durchführung der Evaluierung S e i t e 60 Web-Applikationen zum Entwerfen der Berichte bieten umfangreichen Funktionalitäten wie die Desktop-Anwendungen. nicht die gleichen Gewichtungen unter Kategorie Usability Nr. Metrik Gewichtung 2.1 Endbenutzer UI-Erfahrung 75% 2.2 Zeit für Installation der erforderlichen Software, die die Open- Source-Software voraussetzt. 0% 2.3 Zeit für die Installation und Konfiguration von der Software 25% Tabelle 17, Übersicht: Gewichtungen von Metriken unter Kategorie Usability. Bei der Gewichtung in der Kategorie Usability wurde das Augenmerk mehr auf das User Interface gelegt. Das User Interface soll den Benutzer beim Entwurf der Berichte unterstützt, damit es die gestellten Anforderungen erfüllt. Die Metrik 2.1 bekommt dadurch die Gewichtung 75%. Die Metrik 2.2 hat 0% bei der Gewichtung bekommen, da alle Reporting- Anwendungen Java als erforderliche Software voraussetzen. Die Metrik 2.3 wurde mit 25% gewichtet, da die Installation und Konfiguration der Software nur einmal durchgeführt wird Gewichtungen unter Kategorie Documentation Nr. Metrik Gewichtung 3.1 Vorhandensein von verschiedenen Dokumenten. 75% 3.2 Framework für Benutzerbeiträge 25% Tabelle 18, Übersicht: Gewichtungen von Metriken unter Kategorie Documentation. Die Metrik 3.1 in der Kategorie Documentation wurde mit 75% gewichtet, da das Vorhandensein der Dokumentation zu einer Anwendung die höchste Priorität hat. Wenn es keine Dokumentation zu einer Anwendung existiert, so ist es schwierig zu ergründen, wie man diese konfigurieren und verwenden soll. Dadurch steigt die Einarbeitungszeit. Die Metrik 3.2 wurde mit 25% gewichtet, da diese Metrik eher zweitranging ist. Die Tutorials können und dürfen nicht die Dokumentation ersetzen.

62 5 Durchführung der Evaluierung S e i t e Gewichtungen unter Kategorie Quality Nr. Metrik Gewichtung 4.1 Anzahl der Minor Releases in den letzten 12 Monaten 15% 4.2 Anzahl der Point/Patch Releases in den letzten 12 Monaten 10% 4.3 Anzahl der offenen Fehler in den letzten 6 Monaten 15% 4.4 Anzahl der behobenen Fehler in den letzten 6 Monaten 15% 4.5 Anzahl der geöffneten P1/kritischen Fehler. 20% 4.6 Durchschnittliches Alter eines P1 Fehlers in den letzten 6 Monaten 25% Tabelle 19, Übersicht: Gewichtungen von Metriken unter Kategorie Quality. Die ersten Metriken von wurden gleichmäßig gewichtet von 10%-15%. Die wichtigsten Metriken sind 4.5 und 4.6, diese wurden mit 20% und 25% gewichtet. Die Anzahl der kritischen Fehler und die Dauer bis diese behoben werden, zeigt wie gut die Anwendung getestet wird und wie das Projekt mit den kritischen Fehlern umgeht Gewichtungen unter Kategorie Architecture Nr. Metrik Gewichtung 5.1 Gibt es irgendwelche Drittanbieter Plug-ins? 50% 5.2 Öffentliche API/ externe Dienste 30% 5.3 Ein- und Ausschalten von Funktionen durch Konfiguration 20% Tabelle 20, Übersicht: Gewichtungen von Metriken unter Kategorie Architecture. Die Metrik 5.1 wurde mit 50% gewichtet, da diese zeigt wie modular die Anwendung aufgebaut ist, so dass man diese durch Plug-ins um neue Funktionalitäten erweitern kann. Die Metrik 5.2 wurde mit 30% gewichtet, da es bei der Integration der Anwendung wichtig ist, diese später erweitern zu können. Die Metrik 5.3 wurde mit 20% gewichtet, da diese Metrik tertiär ist.

63 5 Durchführung der Evaluierung S e i t e Gewichtungen unter Kategorie Scalability Nr. Metrik Gewichtung 6.1 Referenz-Deployment 50% 6.2 Konzipiert für Skalierbarkeit 50% Tabelle 21, Übersicht: Gewichtungen von Metriken unter Kategorie Scalability. Die beiden Metriken wurden mit 50% gewichtet, da beide wichtig sind. Wenn es kein Referenz-Deployment der Anwendung in der Praxis gibt, so kann man nicht einschätzen, ob diese Anwendung auch in Produktion eingesetzt werden kann. Wird eine Anwendung nicht für die Skalierbarkeit konzipiert, so kann es in der Produktion zu Problemen (Speicherverbrauch, Prozessorauslastung) kommen, wenn mehrere Benutzer den Zugriff auf die Anwendung haben Gewichtungen unter Kategorie Community Nr. Metrik 8.1 Durchschnittliches Volumen einer Hauptmailinglist in den letzten 6 Monaten. 8.2 Anzahl von eindeutigen Quellcode-Beitragenden in den letzten 6 Monaten. Gewichtung 75% 25% Tabelle 22, Übersicht: Gewichtungen von Metriken unter Kategorie Community. Die Metrik 8.1 wurde mit 75% gewichtet, da diese Metrik wichtig ist. Die erste Anlaufstelle für Probleme mit der Software ist das Forum oder eine Mailingliste. Bei einer regen Community wird man vom Projekt-Team oder von der Community beraten, um eine Lösung zum Problem zu finden. Die Metrik 8.2 wurde mit 25% gewichtet, da es eher sekundär ist, wie viele Entwickler an dem Projekt arbeiten, was aber nicht außer Acht gelassen werden darf. Wenn an einem Projekt Unternehmen beteiligt sind, so werden mehr Entwickler für dieses Projekt abgestellt und somit wird auch die Entwicklung des Projektes vorangetrieben.

64 5 Durchführung der Evaluierung S e i t e Bewertung der Frameworks Nach dem BRR-Model werden in der Phase 3 die Daten gesammelt und auf die einzelnen Metriken aus den ausgewählten Kategorien angewendet (vgl. Kapitel 3.1) Bewertung in der Kategorie Functionality Standardfunktionalitäten Ausgabeformate BIRT Pentaho Reporting Jasper- Reports PDF HTML Excel Word (DOC) Word (RTF) Datenquellen JDBC Hibernate Diagramme Einbindung dynamischer Inhalte (Bilder, Texte) Einbindung von Charts Reporting Templating (Schablonen) Verschiedene Datenquellen innerhalb eines Reports Drill-Down-Analyse innerhalb eines Reports Internationalisierung (Zeichensatz, Währung..) Unterstützt Sub-Reports (Verschachtelung) 2 2 2

65 5 Durchführung der Evaluierung S e i t e 64 BIRT Pentaho Reporting Jasper- Reports Parametrisierte Reports Aggregationen und Gruppierung Zusatzfunktionalitäten Ausgabeformate TXT PPT OpenOffice (ODT) XML CSV SVG (Scalable Vector Graphics) Datenquellen POJO/Java Beans CSV XML Web Services XML/A,MDX Metadatenunterstützung Reporting Preview Funktionalität Scheduler für Reportgenerierung Bursting (Verteilung) View Engine für Web-Applikation View Engine für Desktop-Anwendung 2 0 2

66 5 Durchführung der Evaluierung S e i t e 65 BIRT Pentaho Reporting Jasper- Reports Report-Entwurf aus Web-Applikation Pixelgenaue Report-Erstellung Cross-Tab Unterstützung Bewertung in % 142,9% 104,8% 145,2% Bewertung in Punkten Tabelle 23, Bewertungstabelle für die Kategorie Functionality. Betrachtet man die Ergebnisse in der Tabelle 23, sieht man, dass bei der prozentualen Bewertung JasperReports und BIRT deutlich vorne liegen, da die beiden Frameworks die meisten Funktionalitäten unterstützen. Die Drill-Down Analyse und die Internationalisierung wird von Pentaho Reporting nicht unterstütz, da diese Funktionalitäten von Pentaho in die eigene BI-Suite ausgelagert wurden, deswegen bekommt Pentaho hier Abzüge. JasperReports und BIRT decken die Standardfunktionalitäten komplett ab und bekommen Zusatzpunkte bei den Zusatzfunktionalitäten. Im Gegensatz zu Pentaho Reporting unterstützen BIRT und JasperReports nahezu alle Ausgabeformate. Bei der Unterstützung der Datenquellen liegen alle Reporting-Frameworks gleich auf. Die meisten zusätzlichen Reporting-Funktionalitäten werden durch Pentaho Reporting und JasperReports unterstützt. BIRT unterstütz solche Funktionalitäten, wie Scheduler für Reportgenerierung, Bursting zur Verteilung und Reportentwurf aus Web-Applikation in der Open-Source Version nicht. Gegen einen Aufpreis bietet Actuate in Verbindung mit der kommerziellen Version von BIRT einen Reporting- Server an, der diese und noch andere Funktionalitäten unterstützt Bewertung in der Kategorie Usability Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 2.1 Endbenutzer UI-Erfahrung 2,25 2,25 2, Zeit für Installation der erforderlichen Software, die die Open-Source-Software voraussetzt

67 5 Durchführung der Evaluierung S e i t e 66 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 2.3 Zeit für die Installation und Konfiguration von der Software 1,25 1,25 1,25 Summe 3,5 3,5 3,5 Tabelle 24, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Usability. In der Metrik 2.1 bekommen alle Designer-Oberflächen der Frameworks eine ungewichtete Bewertung von 3 Punkten und gewichtet von 2.25, da alle komplex aufgebaut sind und ohne Handbuch oder Tutorials nur zum Teil benutzbar sind. Für die Installation von BIRT werden durch das BIRT-Projekt mehrere Pakete zur Verfügung gestellt: All-in-One, Framework, RCP Designer und die Runtime. Für die Evaluierung wurde das All-In-One-Paket verwendet. Nach dem Download des Pakets, muss man dieses nur entpacken. Um die Anwendung zu starten, muss man in den Unterordner Eclipse wechseln und die Datei eclipse.exe ausführen. Die Dauer der Installation hängt von der Geschwindigkeit des Rechners ab, wie schnell dieser das Paket entpackt. Die Installation auf dem Benchmarksystem dauerte unter einer Minute. BIRT liefert keine Datenbanktreiber, diese muss man gesondert herunterladen und beim Auswählen der Datenbank in der Anwendung auswählen. Pentaho stellt mehrere Downloads zur Verfügung. Es ist möglich die Server- Anwendungen auf verschiedene Weise zu installieren. Möchte man die Anwendungen unter Windows verwenden, bietet Pentaho einen Windows-Installer an. Für andere Betriebssysteme wird unter anderem ein Binary-Installer angeboten. Möchte man keinen Installer verwenden, ist es möglich die Server-Anwendungen als gepacktes Paket herunterzuladen. Der Designer wird als gepacktes Packet angeboten, den man einfach nur entpacken muss. Für die Evaluierung wurde der Windows-Installer für Pentaho- Reporting ausgewählt. Dieser installiert einen Reporting-Server und die grafische Oberfläche zum Entwerfen der Berichte. Installiert man nur den Designer, so erfolgt die Installation unter einer Minute, da man das angebotene Paket nur entpacken muss. Die Installation von Pentaho-Reporting dauerte etwa vier Minuten. Im Gegensatz zu BIRT und JasperReports liefert Pentaho eine Vielzahl von Datenbanktreibern mit: HSQL, MySQL, Sybase, Oracle, DB2, PostgreeSQL u.a. JasperSoft bietet auch mehrere Downloads an und stellt, wie Pentaho, einen Windows-Installer zur Verfügung. Für Linux-Betriebssysteme stellt JasperSoft auch

68 5 Durchführung der Evaluierung S e i t e 67 einen Binary-Installer zur Verfügung. Es besteht auch die Möglichkeit die Anwendungen als gepacktes Paket herunterzuladen. Im Gegensatz zu Pentaho und BIRT wird der Designer als gepacktes Paket und als Windows-Installer angeboten. Für die Evaluierung wurde der Server als Windows-Installer heruntergeladen. Während der Installation wird vom Installer auch der Designer für die Berichte mit installiert. Bei der Installation ist es aufgefallen, dass JasperSoft mit dem Designer die JDBC- Datenbanktreiber für HSQL- und MySQL-Datenbank mit installiert. Positiv war auch, dass der Installer eine Auswahlmöglichkeit anbietet. Beispielsweise kann man auswählen, ob ein Tomcat-Server installiert oder ein vorhandener Server benutzt werden soll. Als nächstes wird angeboten, eine vorhandene Datenbank zu verwenden oder eine neue MySQL-Datenbank zu installieren. Die Installation dauerte etwa fünf Minuten, dabei wurde ein Datenbankserver, Tomcat und IReport installiert und mit Beispieldaten konfiguriert. Die benötige Zeit für die Installation betrug bei allen Frameworks unter fünf Minuten, deswegen bekommen alle Frameworks eine ungewichtete Bewertung von 5 und gewichtet 1, Bewertung in der Kategorie Documentation Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 3.1 Vorhandensein von verschiedenen Dokumenten. 3,75 3 3, Framework für Benutzerbeiträge 1,25 0,75 0,75 Summe 5 3,75 4,5 Tabelle 25, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Documentation. Bei der Metrik 3.1 hat Pentaho Reporting am schlechtesten abgeschnitten, da die Dokumentation, die durch das Projekt angeboten wird, unvollständig, veraltet und teilweise fehlerbehaftet ist. Deswegen bekommt hier Pentaho als einziges Framework eine ungewichtete Bewertung von 4 Punkten und gewichtet 3. Die höchste Punktzahl bei der Metrik 3.2 hat BIRT mit gewichteten 1,25 Punkten erreicht. Bevor die Tutorials auf der Seite veröffentlicht werden, werden diese durch die Moderatoren gelesen und auf Richtigkeit überprüft. Bei den beiden anderen Frameworks steht das Angebot die Tutorials zu veröffentlichen zwar zur Verfügung, die

69 5 Durchführung der Evaluierung S e i t e 68 Tutorials werden aber nicht auf die Richtigkeit überprüft, was an den Kommentaren unterhalb der Tutorials erkennbar ist. In der Kategorie Documentation hat BIRT die höchste Punktzahl 5 Punkten. Das schlechteste Ergebnis hat Pentaho Reporting mit 3,75 Punkten. Die schlechte Bewertung kommt durch die mangelnde Qualität und Unvollständigkeit in der Dokumentation sowie bei den Tutorials Bewertung in der Kategorie Quality Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 4.1 Anzahl der Minor-Releases in den letzten 12 Monaten 4.2 Anzahl der Point/Patch Releases in den letzten 12 Monaten 4.3 Anzahl der offenen Fehler in den letzten 6 Monaten 4.4 Anzahl der behobenen Fehler in den letzten 6 Monaten 4.5 Anzahl der geöffneten P1/kritischen Fehler. 4.6 Durchschnittliches Alter eines P1 Fehlers in den letzten 6 Monaten 0,75 0,75 0,75 0,5 0,3 0,3 0,15 0,6 0,6 0,75 0,75 0,6 0,6 0,4 0,6 1,25 1,25 1,25 Summe 4 4,05 4,1 Tabelle 26, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Quality. Alle drei Frameworks hatten in den letzten zwölf Monaten zwei Minor-Releases, dadurch ergibt sich bei der Metrik 4.1 ein gewichteter Wert von 0,75. Bei der Metrik 4.2 hatte JasperReports fünf Patch-Releases und Pentaho Reporting sechs. Dadurch ergibt sich bei beiden ein ungewichteter Wert von drei und gewichtet jeweils 0,3. BIRT hatte nur drei Patch-Releases, dadurch bekommt BIRT einen ungewichteten Wert von 5 Punkten und gewichtet 0,5. Bei der Metrik 4.3 hat BIRT schlechteste Bewertung, mit einem ungewichteten Wert von 1 und gewichtetem Wert von 0,15. In den letzten sechs Monaten wurden 1630

70 5 Durchführung der Evaluierung S e i t e 69 Fehler gemeldet. Bei dem Modul von Pentaho Reporting wurden nur 58 Fehler gemeldet und bei JasperReports 50 Fehler. BIRT und Pentaho Reporting haben bei der Metrik 4.4 die besten Ergebnisse, da bei beiden Projekten über 75% der gemeldeten Fehler behoben wurden, bei JasperReports waren es nur 66%. Bei der Anzahl der kritischen Fehler hatte Pentaho Reporting die meisten. In den letzten sechs Monaten wurden da 12 kritische Fehler gemeldet, was zu einer ungewichteten Bewertung von 2 Punkten und gewichtet 0,4 Punkte führte. JasperReports und BIRT hatten unter 9 kritische Fehler, was bei beiden zu einer ungewichteten Bewertung von 3 und gewichtet 0,6 führte. Der Umgang mit den kritischen Fehlern ist bei allen drei Projekten sehr positiv. Im Durchschnitt wurden die kritischen Fehler innerhalb einer Woche behoben, was zu einer ungewichteten Bewertung von 5 und einer gewichteten 1,25 führte. Bei der Qualität hat JasperReports das beste Ergebnis mit 4,1 Punkten. Das schlechteste Ergebnis hatte BIRT. Bei BIRT wurde das Ergebnis durch die hohe Anzahl der Fehler beeinflusst, weil das Projekt an sich um einiges größer ist als das von anderen getesteten Frameworks Bewertung in der Kategorie Architecture Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 5.1 Gibt es irgendwelche Drittanbieter Plugins? 2,5 0, Öffentliche API/ externe Dienste 1,5 0,9 0,9 5.3 Ein- und Ausschalten von Funktionen durch Konfiguration Summe 5 2,4 3,9 Tabelle 27, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Architecture. BIRT bekommt bei der Metrik 5.1 die Höchstpunktzahl, da BIRT selbst komplett aus Plug-ins besteht und für die Drittanbieter mehrere Erweiterungs-Punkte anbietet. BIRT basiert auf der Eclipse-Platform und für diese existieren mehr als 1000 Plug-Ins. JasperReports bietet Erweiterungsmöglichkeiten in dem Report Designer durch Plugins. Es werden 6 Plug-ins mitgeliefert, deswegen bekommt JasperReports eine

71 5 Durchführung der Evaluierung S e i t e 70 ungewichtete Bewertung von 4 Punkten und gewichtet von 2 Punkten. Im Gegensatz zu anderen Projekten, die Pentaho betreut und führt, besitzt Pentaho Reporting keine Plug- In Erweiterungsmöglichkeiten. Der neue Ansatz von Pentaho ist es auf die Eclipse Platform zu setzen. Leider gibt es im Design Studio bis jetzt keinen Report-Designer, deswegen wird dieser bei der Metrik 5.1 nicht beachtet. Pentaho Reporting bekommt nur 1 ungewichteten Punkt und 0,5 gewichtete Punkte. BIRT bietet eine API und Extension Points, über die man das Framework nicht nur im Designer sondern auch in der Runtime um eigene Elemente und Zusätze erweitern kann. Dadurch bekommt BIRT bei der Metrik 5.2 eine ungewichtete Bewertung von 5 Punkten und gewichtet 1,5. Die beiden anderen Frameworks bieten die Möglichkeit, diese durch die API zu erweitern. Bei allen drei Frameworks ist es möglich die Funktionalitäten während der Laufzeit ein- bzw. auszuschalten. Jeder der drei Frameworks bekommt bei der Metrik 5.3 ungewichtete Bewertung von 5 Punkten und gewichtet 1. Bei der Architektur bekommt BIRT 5 Punkte, da dieser bei der Erweiterung und Plug-ins die besten Ergebnisse liefert. Pentaho Reporting hat das schlechteste Ergebnis mit 2,4 Punkten, da es keine Erweiterungen durch die Plug-Ins anbietet Bewertung in der Kategorie Scalability Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 6.1 Referenz-Deployment 2,5 2,5 2,5 6.2 Konzipiert für Skalierbarkeit 2,5 2,5 2,5 Summe Tabelle 28, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Scalability. Untersucht man die Seiten der Unternehmen, die die Projekte führen, so kann man erkennen, dass es eine Vielzahl von Referenz-Deployments existiert. Dadurch bekommt jedes der Frameworks die höchste Bewertung. Alle drei Frameworks haben bei der Metrik 6.2 sehr gute Ergebnisse, da alle für die Skalierbarkeit konzipiert wurden.

72 5 Durchführung der Evaluierung S e i t e Bewertung in der Kategorie Community Nr. Metrik BIRT Pentaho Reporting Jasper- Reports 8.1 Durchschnittliches Volumen einer Hauptmailinglist in den letzten 6 Monaten. 8.2 Anzahl von eindeutigen Quellcode- Beitragenden in den letzten 6 Monaten. 3,75 3,75 3,75 1,25 0,75 0,75 Summe 5 4,5 4,5 Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community. Nr. Kategorie Gewichtung BIRT Pentaho Reporting Die Community aller drei Frameworks ist sehr lebhaft, dies kann man an der Anzahl der Beiträge in den Foren und den Mailinglisten erkennen. Alle drei Frameworks bekommen ungewichtet eine Bewertung von 5 Punkten und gewichtet 3,75 bei der Metrik 8.1. Bei der Metrik 8.2 bekommt BIRT das beste Ergebnis von 5 Punkten ungewichtet und 1,25 gewichtet. BIRT wird außer von der Community noch von 4 weiteren Unternehmen wie Actuate, Innoent Solutions, IBM und InetSoft weiterentwickelt und vorangetrieben. Dadurch ergibt sich die Entwickleranzahl von über 50 Leuten. Die beiden anderen Projekte bekommen 0,75 gewichtete Punkte, da bei den beiden nur Entwickler an den Projekten arbeiten. In der Kategorie Community bekommt BIRT die höchste Bewertung von 5 Punkten. Pentaho Reporting und JasperReports bekommen jeweils 4,5 Punkten. Alle drei Projekte haben eine lebhafte Community, BIRT konnte durch die Anzahl der Entwickler die höchste Punktzahl erreichen Ergebnisse der BRR-Bewertung Jasper- Reports 1 Functionality 25% 1,25 1,25 1,25 2 Usability 20% 0,70 0,70 0,70 3 Documentation 15% 0,75 0,56 0,68 4 Quality 15% 0,60 0,61 0,62

73 5 Durchführung der Evaluierung S e i t e 72 Nr. Kategorie Gewichtung BIRT Pentaho Reporting Jasper- Reports 5 Architecture 10% 0,50 0,24 0,39 6 Scalability 10% 0,50 0,50 0,50 7 Community 5% 0,25 0,23 0,23 BRR-Punktezahl 4,55 4,085 4,355 Tabelle 30, Übersicht: Ergebnisse der BRR-Bewertung. Die Ergebnisse beim BRR-Test der drei Frameworks unterscheiden sich nur im Nachkommastellenbereich. BIRT bekommt die beste BRR-Punktzahl durch die höchsten Bewertungen in den Kategorien Documentation und Architecture Zusatzbewertung der Benutzeroberfläche Bei der Bewertung der Benutzeroberfläche in dem BRR-Model ist es aufgefallen, dass die Metrik 2.1 in der Kategorie Usability nicht ausreichend ist, um eine Oberfläche zu bewerten. Es wird nur eine allgemeine Aussage über die Benutzung getroffen. Da aber die Report-Designer sehr komplex sind, müssen zusätzliche Metriken definiert werden. Die untenstehende Tabelle listet die zusätzlichen Metriken auf. Abbildungen der drei getesteten Benutzeroberflächen befinden sich im Anhang C. Metrik: Z1 Platzierung der Elemente/Buttons auf der Benutzeroberfläche. Beschreibung: Mit dieser Metrik wird überprüft: wie gut und übersichtlich die Elemente auf der Benutzeroberfläche positioniert sind. Metrik: Z2 Unterstützung durch die Benutzeroberfläche. Beschreibung: Wie gut wird der Benutzer durch die Benutzeroberfläche unterstützt? Dazu gibt es einige Mechanismen, wie z.b. Schnellhilfe, Tooltipps. Metrik: Z3 Wizard Unterstützung. Beschreibung: Existiert ein Wizard zum Entwerfen von Berichten? Wie schnell und einfach kann ein Bericht durch den Wizard entworfen werden? Metrik: Z4 Entwurf der komplexen Berichte. Beschreibung: Wie einfach oder schwer ist es mit dem vorliegenden Designer einen komplexen Bericht zu entwerfen. Zu den komplexen Berichten

74 5 Durchführung der Evaluierung S e i t e 73 zählen zum Beispiel die Unter-Berichte, Berichte mit mehreren Datenbankverbindungen, Berichte mit mehreren Tabellen. Metrik: Z5 Qualität der Fehlermeldungen. Beschreibung: Sind die Fehlermeldungen für einen Benutzer verständlich, die ausgegeben werden? Metrik: Z6 Entwurf und Konfiguration von Diagrammen. Beschreibung: Besteht eine Unterstützung durch die Benutzeroberfläche, um ein Diagramm zu entwerfen? Sind die Dialoge zum Entwerfen der Diagramme übersichtlich und verständlich? Metrik: Z7 Entwurf und Konfiguration von Aggregationen und Gruppierungen. Beschreibung: Wie einfach kann eine Aggregation oder Gruppierung durch die Benutzeroberfläche angelegt werden? Metrik: Z8 Entwurf und Konfiguration von Tabellen. Beschreibung: Wird der Benutzer durch die Oberfläche unterstütz beim entwerfen der Tabellen? Wie übersichtlich und einfach wird das Entwerfen von der Oberfläche angeboten? Metrik: Z10 Mitgelieferte Hilfe. Beschreibung: Wird eine Hilfe mitgeliefert? Metrik: Z11 Stabilität der Anwendung. Beschreibung: Wie stabil läuft die Anwendung beim entwerfen von Berichten? Metrik: Z12 Preview-Funktionalitäten. Beschreibung: Wie komfortabel ist die Vorschau-Funktionalität und in welchen Formaten lässt sich die Vorschau erstellen? Tabelle 31, Metriken zum Bewerten von der Benutzeroberfläche. Die Bewertung bei allen zusätzlichen Metriken erfolgt nach dem Punktesystem von BRR, d.h. es werden Punkte 1 bis 5 vergeben, dabei ist 1 der schlechteste Wert und 5 der beste. Da alle zusätzlichen Metriken wichtig sind, wird keine Gewichtung durchgeführt, sondern ein arithmetischer Durchschnitt gebildet.

75 5 Durchführung der Evaluierung S e i t e Bewertung der Metrik Z1 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z1 Platzierung der Elemente/Buttons auf der Benutzeroberfläche Tabelle 32, Bewertung der Metrik Z1. Die Oberflächen von Pentaho- und BIRT-Report-Designer sind übersichtlich aufgebaut und alle Elemente, die zum Entwerfen der Berichte benötig werden beschriftet. Dagegen ist die Oberfläche von IReport von JasperReports etwas unübersichtlich aufgebaut, die Elemente zum Entwerfen der Berichte befinden sich in der Symbolleiste als Icons. Um zu erfahren welche Funktionalität hinter dem Icon steht, muss man über das Icon fahren damit der Tooltip dazu angezeigt wird. Pentaho und Jasper bieten in der Symbolleiste eine übersichtliche Konfiguration für die Schriftarten und Schriftgröße an, was bei BIRT fehlt Bewertung der Metrik Z2 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z2 Unterstützung durch die Benutzeroberfläche Tabelle 33, Bewertung der Metrik Z2. Beim Entwerfen der Berichte ist es aufgefallen, dass BIRT nicht nur durch die Tooltipps einen Benutzer unterstützt, sondern zusätzlich durch eine Schnellhilfe, in der beschrieben wird, wofür die einzelnen Dialogfelder stehen, und was man dort eingeben soll. Die beiden anderen Anwendungen Pentaho Report Designer und IReport unterstützen den Benutzer nur durch die Tooltipps Bewertung der Metrik Z3 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z3 Wizard Unterstützung Tabelle 34, Bewertung der Metrik Z3.

76 5 Durchführung der Evaluierung S e i t e 75 Alle drei Anwendungen bieten einen Wizard an, um einen Bericht zu entwerfen. Der schlichteste Wizard war von BIRT, dort konnte man lediglich die Datei benennen und ein Template auswählen, danach wird man auf ein Tutorial in der Schnellhilfe verweisen, die automatisch die lokale Hilfe zu BIRT startet. Pentaho Report Designer und IReport bieten aufwendige Wizards, mit deren Hilfe ein kompletter Bericht entworfen werden kann. Dazu werden die SQL-Anweisungen abgefragt, die Spalten, die man in den Bericht aufnehmen möchte, und das Template Bewertung der Metrik Z4 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z4 Entwurf der komplexen Berichte Tabelle 35, Bewertung der Metrik Z4. Beim Entwerfen von Berichten mit mehreren Tabellen, wobei mehrere SQL-Abfragen verwendet wurden, ist es aufgefallen, dass nur zwei der getesteten Designer mehrere SQL-Abfragen verwalten konnten. Dazu gehören BIRT und Pentaho Reporting. Die Platzierung von mehreren Tabellen war bei Pentaho Reporting und IReport nicht möglich, weil das Berichtslayout dies nicht zulässt, da auf jedem Bericht nur eine Tabelle platziert werden kann. Dieses Problem lässt sich aber durch die Unter-Berichte umgehen. Bei BIRT hingegen lassen sich mehrere Tabellen auf einem Bericht direkt platzieren oder auch durch die Unter-Berichte lösen. Pentaho Reporting und IReport machen für neue Unter-Berichte ein neues Fenster auf, was in einigen Fällen zu einem Synchronisationsproblem führte, z. B. der Unter-Bericht erkannte nicht die übergebenen Parameter, bis man diesen neue geladen hat Bewertung der Metrik Z5 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z5 Qualität der Fehlermeldungen Tabelle 36, Bewertung der Metrik Z5. Alle drei bieten einen gesonderten Bereich auf der Oberfläche, in dem die Fehlermeldungen angezeigt werden. Die Fehlermeldungen, die in diesem Bereich angezeigt wurden, waren verständlich. Wenn man bei BIRT und Pentaho auf die

77 5 Durchführung der Evaluierung S e i t e 76 Fehlermeldung klickt, wird automatisch das Element ausgewählt, welches diese Fehlermeldung verursacht hat. Die Fehlermeldungen, die außerhalb des gesonderten Bereichs angezeigt wurden, waren bei Pentaho und IReport nicht ganz verständlich. Bei IReport wurde bei der Vorschau eine missverständliche Fehlermeldung, die mit dem Diagramm zusammenhing, ausgegeben. Daraufhin wurde man auf die Konsole verwiesen, um die Java-Exception zu untersuchen. Mit der ausgegebenen Fehlermeldung kann ein einfacher Benutzer, der keine oder wenige Java-Skills hat, nichts anfangen. Bei Pentaho gab es Fehlermeldungen beim Export von Unter- Berichten. Diese Fehlermeldung wurde genau wie bei IReport als Java-Exception ausgegeben Bewertung der Metrik Z6 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z6 Entwurf und Konfiguration von Diagrammen Tabelle 37, Bewertung der Metrik Z6. Alle drei Designer bieten einen Wizard zum Entwerfen von Diagrammen an. Das Entwerfen der Diagramme unter Pentaho Report Designer und IReport erwies sich als umständlich, da es keine Vorschau auf das Diagramm gibt und man durch die vielen Einstellungsmöglichkeiten überfordert wird. Bei der Zuweisung von Spalten muss man sehr viel ausprobieren, um das gewünschte Ergebnis zu bekommen, da es nicht ganz klar ist, zu welcher Einstellung welche Spalte angegeben werden soll. BIRT macht es ganz vorbildlich. Es wird eine Vorschau auf das fertige Diagramm angezeigt. In der Vorschau ist direkt zu sehen, welche Werte an welcher Position eingegeben werden müssen Bewertung der Metrik Z7 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z7 Entwurf und Konfiguration von Aggregationen und Gruppierungen Tabelle 38, Bewertung der Metrik Z7.

78 5 Durchführung der Evaluierung S e i t e 77 Bei allen drei Designern funktionierte die Gruppierungsfunktion sehr gut. Die Aggregation bei Pentaho Report Designer und IReport ist kompliziert aufgebaut. Die Konfigurationsmöglichkeiten sind nicht eindeutig beschrieben. Um zu einem gewünschten Ergebnis zu kommen, muss man die einzelnen Konfigurationseinstellungen ausprobieren Bewertung der Metrik Z8 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z8 Entwurf und Konfiguration von Tabellen Tabelle 39, Bewertung der Metrik Z8. Bedingt durch das Layout des Berichtes in Pentaho Report Designer und IReport beschränkt sich der Entwurf der Tabellen auf Platzierung von einzelnen Spalten. Durch dieses Vorgehen ergibt sich ein Problem, wenn man eine Spalte dynamisch gestalten möchte. Die Überschrift wird nicht automatisch auf die Spaltenbreite der Daten vergrößert. Um die einzelnen Spalten zu konfigurieren, wird eine Liste von Einstellungen angeboten. Durch die Vielzahl von den Einstellungen wird die Liste unübersichtlich, da man diese nach bestimmten werten absuchen muss. BIRT arbeitet mit richtigen Tabellen, in die man die Spalten mit der Maus ziehen kann, dadurch werden auch die Beschriftungen automatisch übernommen. Vergrößert sich die Datenbreite, so wird auch die Spaltenbreite bei der Überschrift vergrößert. Die einzelnen Konfigurationen werden über einen Property Editor durchgeführt, der von BIRT angeboten wird. Im Gegensatz zu anderen Designern sind die Einstellungen in verschiedene Bereiche aufgeteilt, was übersichtlicher und verständlicher ist Bewertung der Metrik Z10 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z9 Mitgelieferte Hilfe Tabelle 40, Bewertung der Metrik Z10. Pentaho Report Designer und IReport liefern mit ihren Designern keine Dokumentation mit und verweisen aus der Oberfläche auf die eigene Webseiten, wo diese heruntergeladen werden kann. BIRT liefert eine umfangreiche Dokumentation, die in

79 5 Durchführung der Evaluierung S e i t e 78 die Oberfläche integriert ist. Zu der Dokumentation von BIRT gehören: Tutorials, Tutorials für Entwickler, Buch in online Form, Dokumentation zu der Oberfläche Bewertung der Metrik Z11 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z10 Stabilität der Anwendung Tabelle 41, Bewertung der Metrik Z11. Pentaho Report Designer und Jasper hatten umfangreiche Speicherprobleme beim entwerfen von Unter-Berichten. Dabei sind diese mehrmals abgestürzt. BIRT hingegen lief stabil Bewertung der Metrik Z12 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z11 Preview-Funktionalitäten Tabelle 42, Bewertung der Metrik Z12. BIRT und Pentaho Reporting bieten die besten Vorschaufunktionalitäten an. Ein Bericht lässt sich in verschiedenen Formaten betrachten, dazu wird die entsprechende Anwendung für das ausgewählte Format aufgerufen. JasperReports unterstützt nur die Java-Preview-Funkionalität. Möchte man einen Bericht in PDF oder HTML betrachten, dann muss man in das Verzeichnis wechseln, in dem dieses erzeugt wurde, und manuell öffnen Ergebnisse der Zusatzbewertung der Benutzeroberfläche Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z1 Platzierung der Elemente/Buttons auf der Benutzeroberfläche Z2 Unterstützung durch die Benutzeroberfläche Z3 Wizard Unterstützung Z4 Entwurf der komplexen Berichte

80 5 Durchführung der Evaluierung S e i t e 79 Nr. Metrik BIRT Pentaho Reporting Jasper- Reports Z5 Qualität der Fehlermeldungen Z6 Entwurf und Konfiguration von Diagrammen. Z7 Entwurf und Konfiguration von Aggregationen und Gruppierungen Z8 Entwurf und Konfiguration von Tabellen Z9 Mitgelieferte Hilfe Z10 Stabilität der Anwendung Z11 Preview-Funktionalitäten Ergebnis Benutzeroberfläche 4,64 3,64 3,27 Tabelle 43, Übersicht: Ergebnisse der Zusatzbewertung. Alle drei Designer haben ihre Vor- und Nachteile, aber am komfortabelsten ist der Designer von BIRT. Im Gegensatz zu den anderen getesteten Designern ist BIRT mit Abstand der mächtigste, aber auch vom Datenumfang am größten. Während Pentaho Report Designer und IReport installiert knapp 50 MB haben, hat BIRT, je nach Version, MB Performance und Speicherauslastung Für jedes ausgewählte Framework wurden die Performance und die Speicherauslastung durch die entwickelte Benchmarkanwendung getestet. Um genauere Werte zu erhalten, wurde die Anwendung für jedes einzelne Framework und jeden Bericht neu gestartet. Um eine realistische Umgebung zu simulieren, wurde ein Random-Test bei der Speicherauslastung und Performance durchgeführt. Bei diesem Test werden die Berichte zufällig ausgewählt und generiert Testumgebung Die Benchmark-Tests werden auf zwei separaten Systemen durchgeführt. Das erste System dient dabei der Ausführung von der Testanwendung. Auf dem zweiten System wird die Datenbank Oracle 10 eingesetzt. Als Datenbasis dienen dabei die Daten eines großen Anwenderunternehmens der Software smartidee.

81 5 Durchführung der Evaluierung S e i t e 80 Komponenten Benchmark-System Datenbank-System Prozessor Intel Core 2 Duo 1,83 GHz Pentium 3 GHz Arbeitsspeicher in Gigabyte 3 1 Betriebssystem Windows XP Professional Windows XP Professional Netzwerkbandbreite in Megabit Java Version 1.6u7 JDBC Version Tabelle 44, Übersicht der Test-Systeme Ergebnisse JasperReports Bericht/Format Erstellungszeit Speicherauslastung Dateigröße Bericht1 HTML 642 ms 3233 KB 1411 KB XLS 563 ms 3589 KB 132 KB PDF 756 ms 3237 KB 82 KB Bericht2 HTML 620 ms 3738 KB 1400 KB XLS 563 ms 5367 KB 152 KB PDF 757 ms 4716 KB 83 KB Bericht3 HTML 191 ms 4634 KB 12 KB XLS 200 ms 3960 KB 29 KB PDF 82 ms 5529 KB 114 KB Bericht4 HTML 609 ms 3445 KB 1412 KB XLS 581 ms 3163 KB 155 KB

82 5 Durchführung der Evaluierung S e i t e 81 Bericht/Format Erstellungszeit Speicherauslastung Dateigröße PDF 762 ms 3804 KB 83 KB Bericht5 HTML 845 ms 3207 KB 1975 KB XLS 766 ms 4054 KB 232 KB PDF 1036 ms 3679 KB 116 KB Bericht6 HTML 1286 ms 5540 KB 1118 KB XLS 1439 ms KB 605 KB PDF 1540 ms 6791 KB 70 KB Random-Test HTML 727 ms 6897 KB - XLS 682 ms 9904 KB - PDF 863 ms 7860 KB - Tabelle 45, Performance und Speicherauslastung von JasperReports Ergebnisse Birt Bericht/Format Erstellungszeit Speicherauslastung Dateigröße Bericht1 HTML 458 ms KB 758 KB XLS 556 ms KB 389 KB PDF 731 ms KB 54 KB Bericht2 HTML 466 ms KB 763 KB XLS 570 ms KB 395 KB PDF 753 ms KB 55 KB Bericht3

83 5 Durchführung der Evaluierung S e i t e 82 Bericht/Format Erstellungszeit Speicherauslastung Dateigröße HTML 319 ms KB 9 KB XLS /359 ms 19398/22006 KB 7/95 KB PDF 852 ms KB 106 KB Bericht4 HTML 471 ms KB 759 KB XLS 553 ms KB 390 KB PDF 721 ms KB 55 KB Bericht5 HTML 515 ms KB 941 KB XLS 690 ms KB 633 KB PDF 991 ms KB 98 KB Bericht6 HTML 613 ms KB 552 KB XLS 1007 ms KB 614 KB PDF 1150 ms KB 60 KB Random-Test HTML 479 ms KB - XLS 612 ms KB - PDF 849 ms KB - Tabelle 46, Performance und Speicherauslastung von BIRT. 37 Die Export-Funktionalität für Excel, die BIRT mitliefert, unterstützt kein Export von Bildern und Diagrammen. Diese Funktionalität lässt sich aber durch eine Zusatzerweiterung nachrüsten. Das zweite Ergebnis wurde unter Verwendung der Zusatzerweiterung ermittelt.

84 5 Durchführung der Evaluierung S e i t e Ergebnisse Pentaho Reporting Bericht/Format Erstellungszeit Speicherauslastung Dateigröße Bericht1 HTML 1198 ms KB 320 KB XLS 1166 ms 6825 KB 87 KB PDF 1385 ms KB 65 KB Bericht2 HTML 1299 ms 6349 KB 323 KB XLS 1205 ms 6591 KB 103 KB PDF 1216 ms KB 64 KB Bericht3 HTML 454 ms KB 4 KB XLS 347 ms KB 97 KB PDF 438 ms KB 71 KB Bericht4 HTML 1269 ms 9984 KB 321 KB XLS 1198 ms 6500 KB 98 KB PDF 1396 ms 7837 KB 65 KB Bericht5 HTML 1610 ms 8287 KB 465 KB XLS 1428 ms 7569 KB 113 KB PDF 1588 ms KB 98 KB Bericht6 HTML 2822 ms 8069 KB 302 KB XLS 2623 ms KB 67 KB PDF 2869 ms 6737 KB 99 KB

85 5 Durchführung der Evaluierung S e i t e 84 Bericht/Format Erstellungszeit Speicherauslastung Dateigröße Random-Test HTML 1259 ms KB - XLS 1230 ms KB - PDF 1321 ms KB - Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting Gegenüberstellung der Performance und Speicherauslastung Die untenstehende Tabelle zeigt die Gegenüberstellung von Performanceergebnissen. Die höchste Performance wurde durch eine farbliche Hervorhebung gekennzeichnet. Bericht/Format BIRT Pentaho Reporting Jasper-Reports Bericht1 HTML 458 ms 1198 ms 642 ms XLS 556 ms 1166 ms 563 ms PDF 731 ms 1385 ms 756 ms Bericht2 HTML 466 ms 1299 ms 620 ms XLS 570 ms 1205 ms 563 ms PDF 753 ms 1216 ms 757 ms Bericht3 HTML 319 ms 454 ms 191 ms XLS 308/359 ms 347 ms 200 ms PDF 852 ms 438 ms 82 ms Bericht4 HTML 471 ms 1269 ms 609 ms 38 Von Pentaho Report Designer erzeugten Berichte lassen sich nicht einfach so außerhalb des Pentaho Servers verwenden. Die XML-Report-Dateien müssen manuell durch einen Texteditor angepasst werden, um dort die SQL-Anweisung und die Datenbank einzutragen.

86 5 Durchführung der Evaluierung S e i t e 85 Bericht/Format BIRT Pentaho Reporting Jasper-Reports XLS 553 ms 1198 ms 581 ms PDF 721 ms 1396 ms 762 ms Bericht5 HTML 515 ms 1610 ms 845 ms XLS 690 ms 1428 ms 766 ms PDF 991 ms 1588 ms 1036 ms Bericht6 HTML 613 ms 2822 ms 1286 ms XLS 1007 ms 2623 ms 1439 ms PDF 1150 ms 2869 ms 1540 ms Random-Test HTML 479 ms 1259 ms 727 ms XLS 612 ms 1230 ms 682 ms PDF 849 ms 1321 ms 863 ms Tabelle 48, Gegenüberstellung von Performanceergebnissen. BIRT liefert die besten Performanceergebnisse. Wobei Bericht 3 von JasperReports am schnellsten generiert wurde. Alle drei Reporting-Frameworks haben Performanceeinbußen beim Erstellen von Unter-Berichten, da hierbei zwei SQL- Anweisungen abgesetzt werden, wobei die zweite SQL-Anweisung durch eine Parameterübergabe gesteuert wird. Die schlechtesten Ergebnisse liefert Pentaho Reporting. Dies kann an der Implementierung des Datenbankmoduls liegen. Im Gesamtergebnis des Performancetests hat BIRT die besten Ergebnisse. Die schlechtesten Ergebnisse hat Pentaho Reporting, da Pentaho Reporting bis zu zweimal langsamer ist als die anderen getesteten Frameworks. Die nachfolgende Tabelle zeigt die Gegenüberstellung von Speicherauslastungsergebnissen, die besten Ergebnisse werden wie in der oberen Tabelle durch farbliche Hervorhebung gekennzeichnet.

87 5 Durchführung der Evaluierung S e i t e 86 Bericht/Format BIRT Pentaho Reporting Jasper-Reports Bericht1 HTML KB KB 3233 KB XLS KB 6825 KB 3589 KB PDF KB KB 3237 KB Bericht2 HTML KB 6349 KB 3738 KB XLS KB 6591 KB 5367 KB PDF KB KB 4716 KB Bericht3 HTML KB KB 4634 KB XLS 19398/22006 KB KB 3960 KB PDF KB KB 5529 KB Bericht4 HTML KB 9984 KB 3445 KB XLS KB 6500 KB 3163 KB PDF KB 7837 KB 3804 KB Bericht5 HTML KB 8287 KB 3207 KB XLS KB 7569 KB 4054 KB PDF KB KB 3679 KB Bericht6 HTML KB 8069 KB 5540 KB XLS KB KB KB PDF KB 6737 KB 6791 KB Random-Test

88 5 Durchführung der Evaluierung S e i t e 87 Bericht/Format BIRT Pentaho Reporting Jasper-Reports HTML KB KB 6897 KB XLS KB KB 9904 KB PDF KB KB 7860 KB Tabelle 49, Gegenüberstellung von Speicherauslastungsergebnissen. Die höchste Speicherauslastung hat BIRT. Die optimalste Speicherauslastung hat JasperReports, gefolgt von Penatho Reporting. Die durchschnittliche Performance nach Dateiformaten soll nochmal die Ergebnisse verdeutlichen, Tabelle 50. Format BIRT Pentaho Reporting Jasper-Reports HTML 474 ms 1416 ms 703 ms XLS 621 ms 1314 ms 685 ms PDF 864 ms 1459 ms 828 ms Tabelle 50, durchschnittliche Performance nach Formaten. Die untenstehende Tabelle zeigt die durchschnittliche Speicherauslastung nach Dateiformaten. Format BIRT Pentaho Reporting Jasper-Reports HTML KB 9636 KB 4385 KB XLS KB 8696 KB 5781 KB PDF KB KB 5088 KB Tabelle 51, durchschnittliche Speicherauslastung nach Formaten. Wenn man die Ergebnisse betrachtet, dann wird man auf zwei der getesteten Frameworks BIRT und JasperReports aufmerksam. Beide liegen bei dem Performancetest nah bei einander. Betrachtet man den Speicherauslastungstest, so sieht man, dass BIRT am speicherhungrigsten ist.

89 5 Durchführung der Evaluierung S e i t e Entscheidungsmatrix BIRT Pentaho Reporting Jasper-Reports Designerversion Engineversion Paketgröße 39 ~40 MB ~30 MB ~40 MB BRR-Punktezahl 4,55 4,085 4,355 UI-Bewertung 4,64 3,64 3,27 Performance HTML 474 ms 1416 ms 703 ms XLS 621 ms 1314 ms 685 ms PDF 864 ms 1459 ms 828 ms Speicherauslastung HTML KB 9636 KB 4385 KB XLS KB 8696 KB 5781 KB PDF KB KB 5088 KB Tabelle 52, Entscheidungsmatrix. Liegt der Focus auf Performance und speicherschonender Anwendung, so sollte man sich für JasperReports entscheiden. Wobei Jasper-Reports den schwächsten Designer im Test hatte. Fällt die Entscheidung auf BIRT, dann muss bei der Gestaltung der Berichte auf die Menge der Informationen, die dargestellt werden sollen, geachtet werden. Wird dies nicht beachtet, dann kann es passieren, das BIRT zu viel Speicher verbraucht. BIRT bietet den mächtigsten Designer, der durch gute Bedienung, umfangreiche Funktionalitäten und Übersichtlichkeit aufgefallen ist. 39 Die Angabe beinhaltet die benötigten Bibliotheken, um die Berichte zu generieren.

90 S e i t e Zusammenfassung Das betriebliche Berichtswesen lässt sich mit Hilfe von BI-Konzepten und Techniken in einem Unternehmen umsetzen. Dazu stellt Business Intelligence die Reporting- Werkzeuge zur Verfügung, die eine Vielzahl von Prozessen aus dem Berichtswesen abdecken. Beispielsweise Gestaltung, Erstellung, Speicherung und Verteilung von Berichten. Darüber hinaus unterstützen die Reporting-Werkzeuge einige Analysemöglichkeiten, wie Aggregation, Sortierung, Filterung und Kennzeichnung der Abweichungen durch farbliche Hervorhebungen. Bei der Evaluierung der Open Source Reporting-Frameworks ist aufgefallen, dass das gewählte Business Readiness Rating Model einige Schwächen im Bereich der UI- Kriterien aufweist (vgl. Kapitel 5.2.9). Die ausgewählten Reporting-Frameworks unterscheiden sich im Ergebnis durch die Bewertung mit dem BRR-Model nur im Nachkommastellenbereich. Starke Unterschiede ergaben sich im Bereich der Dokumentation. Hier wies Pentaho erhebliche Mängel auf (vgl. Kapitel 5.2.3). Dagegen bot BIRT die beste Dokumentation. Falls die Dokumentation für bestimmte Fragestellungen nicht ausreicht, so kann für BIRT und JasperReports weitergehende Literatur erworben werden. Die Themenreichweite der Bücher offeriert dabei von Integration des Frameworks bis zur Gestaltung der Berichte. Alle drei Frameworks bieten eine lokale Anwendung zum Gestalten der Berichte. Der Designer von BIRT ist durch gute Bedienung, umfangreiche Funktionalitäten und Übersichtlichkeit aufgefallen. Dagegen wirken JasperReports und Pentaho Reporting unübersichtlich im Bereich der Konfiguration für Elemente und Diagramme. Desweiteren wurden bei JasperReports und Pentaho Reporting Stabilitätsprobleme festgestellt. Für die Gestaltung von einfachen Berichten ist jedoch jeder der hier betrachteten Designer gut geeignet. Durch modulare Architektur lassen sich die evaluierten Reporting-Frameworks in eine bestehende Anwendung als Module integrieren. Wird Pentaho Reporting als Modul integriert, so gehen einige Funktionalitäten verloren, die durch die bestehende BI-Suite angeboten werden. Vor allem die Verwendung des Designers von Pentaho ist dadurch mit einem erheblichen Aufwand verbunden. Da Pentaho Modul selbst keine Business Prozesse unterstützt, müssen die gespeicherten Berichtsentwürfe manuell durch SQL- Abfragen und Datenbankinformationen erweitert werden. Die beste Integration in eine

91 6 Zusammenfassung S e i t e 90 Web-Anwendung bietet BIRT. Dazu wird eine vorgefertigte Servlet-Anwendung angeboten, die die Berichte in verschiedenen Formaten ausgibt und vor dem Erzeugen automatisch nach benötigten Parametern fragt. Die Web-Anwendung lässt sich mit wenig Aufwand an das bestehend Systeme anpassen. JasperReports bietet einige Beispiele für die Integration in eine Web-Anwendung. Diese benötigen aber mehr Anpassungen und Erweiterungen, um die Funktionalitäten auf den gleichen Stand wie BIRT Web-Anwendung zu bringen. Die performanteste Generierung der Berichte bietet BIRT. Dieser Vorteil ist mit einer größeren Speicherauslastung verbunden. Im Vergleich zu anderen Frameworks verbraucht BIRT ~20 MB an Arbeitsspeicher. Die niedrigste Performance wurde bei Pentaho Reporting festgestellt. Er benötigte teilweise die zwei- bis dreifache Zeit bei der Generierung der Berichte im Vergleich zu BIRT. JasperReports war nur geringfügig langsamer als BIRT, verbrauchte aber auch deutlich weniger Speicher. Abschließend lässt sich sagen, dass der Einsatz von BIRT zu empfehlen ist, da die Vorteile überwiegen: Übersichtliche und bedienungsfreundliche Gestaltungsoberfläche für Berichte, Ausgabemöglichkeiten der Berichte, Erweiterbarkeit des Frameworks durch Plug-ins, wenig Aufwand bei der Integration des Frameworks in vorhandene Anwendung oder Web-Applikation und eine vollständige Abdeckung der gestellten Anforderungen durch das Unternehmen. Der Nachteil der hohen Speicherauslastung kann durch eine intelligente Gestaltung der Berichte abgeschwächt werden. Indem die relevanten Informationen in geeigneter Menge ausgewählt werden.

92 S e i t e 91 Literaturverzeichnis BRR (2005): Business Readiness Rating: heruntergeladen am Chamoni (2003): Chamoni, P.: Analytische Informationssysteme für das Controlling - Stand und Entwicklungsperspektiven, heruntergeladen am Chamoni/Gluchowski (2004): Chamoni, P./ Gluchowski, P.: Itegrationstrends bei Business-Ingelligence-Systemen - Empirische Untersuchung auf Basis des Bussines Intelligence Maturity Model, in: Wirtschaftsinformatik, 46. Jg. 2004, H. 2, S Chamoni/Gluchowski (2006): Chamoni, P./ Gluchowski, P.: Analytische Informationssysteme - Einordnung und Überblick, in: Chamoni, P./Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Danciu/Chirita (2007): Danciu, T./ Chirita, L.: The Definitive Guide to JasperReports. Berkeley 2007, Apress. Deprez/Alexandre (2008): Deprez, J.-C./ Alexandre, S.: Comparing Assessment Methodologies for Free/Open Source Software: OpenBRR and QSOS. Berlin 2008, Springer Verlag. Dittmar/Schulze (2006): Dittmar, C./ Schulze, K.: Seine Stärken kennen lernen. In: BI-SPEKTRUM, Jg. 2006, H. 01, S Eclipse-Birt (2008)a: Eclipse-Birt, heruntergeladen am Eclipse-Birt (2008)b: BIRT Project Description and Scope, heruntergeladen am

93 Literaturverzeichnis S e i t e 92 Finger (2006): Finger, R.: BI-Betriebsmodelle auf dem Prüfstand. In: BI-SPEKTRUM, Jg. 2006, H. 02, S Gluchowski (2001): Gluchowski, P.: Business Intelligence. Konzepte, Technologien und Einsatzbereiche, in: HMD - Praxis der Wirtschaftsinformatik, 38. Jg. 2001, H. 222, S Gluchowski (2006): Gluchowski, P.: Techniken und Werkzeuge zum Aufbau betrieblicher Berichtssysteme, in: Chamoni, P./ Gluchowski,P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Gluchowski/Chamoni (2006): Gluchowski, P./ Chamoni, P.: Entwicklungslinien und Architekturkonzepte des On-Line Analytical Processing. In: Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Gluchowski/Gabriel/Dittmar (2008): Gluchowski,P./ Gabriel, R./ Dittmar, C.: Management Support Systeme und Business Intelligence: Computergestützte Informationssysteme für Fach- und Führungskräfte. 2. Aufl., Berlin Heidelberg 2008, Springer Verlag. Gluchowski/Kemper (2006): Gluchowski, P./ Kemper, H.:Quo Vadis Business Intelligence?, in: BI-SPEKTRUM, Jg. 2006, H. 01, S Griffel (1998): Griffel, F.: Componentware., Heidelberg 1998, Dpunkt-Verlag. Grothe (2000): Grothe, M.: Business Intelligence. Aus Informationen Wettbewerbsvorteile gewinnen. o.o. 2000, Addison-Wesley Verlag. Hartmann/Kracker (2004): Hartmann, M./Kracker, O.: Perspektiven eines web-basierten Berichtswesens und Beteiligungsmanagements, in: Hartmann, M. (Hrsg.): Berichtswesen für High-Tech-

94 Literaturverzeichnis S e i t e 93 Unternehmen: Reporting mit Balanced Scorecard, web-basierten Systemen und Beteiligungsmanagement. Berlin 2004, Erich Schmidt Verlag. Heffelfinger (2006): Heffelfinger, D.: JasperReports for JavaDevelopers. Birmingham 2006, Packt Publishing. Heine/Wende (2004): Heine, P./ Wende, K.: Eigenschaften des web-basierten Reporting, in: Hartmann, M. (Hrsg.): Berichtswesen für High-Tech-Unternehmen: Reporting mit Balanced Scorecard, web-basierten Systemen und Beteiligungsmanagement. Berlin 2004, Erich Schmidt Verlag, S Held (2007): Held,M./et al.: Business Intelligence mit Pentaho, Intelligence-mit-Pentaho--/artikel/98599/, heruntergeladen am Hübner (2004): Hübner, J.: Unternehmenskommunikation. In: Hartmann, M. (Hrsg.): Berichtswesen für High-Tech-Unternehmen: Reporting mit Balanced Scorecard, web-basierten Systemen und Beteiligungsmanagement. Berlin 2004, Erich Schmidt Verlag, S JasperSoft (2008): JasperReports, heruntergeladen am Kemper/Lee (2001): Kemper, H./ Lee, P.: Business Intelligence - ein Wegweiser, in: Computerwoche, Jg. 2001, H. 44, S Kemper/Mehanna/Unger (2006): Kemper, H./ Mehanna, W./ Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen: Eine Einführung in die IT-basierte Managementunterstützung. Wiesbaden 2006, Vieweg Verlag. Kleijn (2006): Kleijn, A.: Business Intelligence mit Open Source, Intelligence-mit-Open-Source--/artikel/73725, heruntergeladen am

95 Literaturverzeichnis S e i t e 94 MERIT (2006): MERIT: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU, heruntergeladen am Mertens (2002): Mertens, P.: Business Intelligence - Ein Überblick. In: Information Management & Consulting, 17. Jg. 2002, Sonderausgabe, S Mucksch (2006): Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssysteme, in: Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Open Source Definition (2008): The Open Source Definition, heruntergeladen am Peh (2006): Peh, D./ et al.: BIRT: A Field Guide to Reporting. Amsterdam 2006, Addison-Wesley Longman. Pentaho (2008): Pentaho Reporting, heruntergeladen am Probst (2006): Probst, J.: Berichtswesen. Augsburg 2006, WEKA Media GmbH & Co.KG. Schelp (2006): Schelp, J.: "Real"-Time Warehousing und EAI, in: Chamoni, P./Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-Technologien und - Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Schulze/Dittmar (2006): Schulze, K./ Dittmar, C.: Business Intelligence Reifegradmodelle, in: Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence- Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S

96 Literaturverzeichnis S e i t e 95 Strauch/Winter (2002): Strauch, B./ Winter, R.: Stichwort "Business Intelligence", in: Bellmann, M./ Krcmar, H./ Sommerlatte, T. (Hrsg.): Praxishandbuch Wissensmanagement - Strategien, Methoden, Fallbeispiele. 1. Aufl., Düsseldorf 2002, Symposion Publishing, S Totok (2006): Totok, A.: Entwicklung einer Business-Intelligence-Strategie, in: Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence- Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S Verity (2005): Verity, J.: Intelligence Gets Smarter, heruntergeladen am Waniczek (2002)a: Waniczek, M.: Grundlagen der Reporting-Konzeption, heruntergeladen am Waniczek (2002)b: Waniczek, M.: Reporting-Audit: Die Analyse des Berichtswesens, heruntergeladen am Wayner (2008): Wayner, P.: Product review: Open source reporting goes corporate, heruntergeladen am Weathersby/et al. (2006): Weathersby, J./et al.: Integrating and Extending Birt. Amsterdam 2006, Addison- Wesley Longman. Willenborg (2002): Willenborg, K.: Berichtswesen - Vereinigung von Gegensätzen, heruntergeladen am

97 S e i t e 96 Anhang A. Abbildungen der Berichte B. Benchmarkanwendung Quellcode C. Abbildungen der Designer-Oberflächen

98 S e i t e 97 A. Abbildungen der Berichte Die Abbildungen wurden aus datenschutzrechtlichen Gründen entfernt.

99 S e i t e 98 B. Benchmarkanwendung Quellcode /** * Die Klasse BenchmarkRunner ist für die Steuerung der Hauptanwendung * verantwortlich. */ public class BenchmarkRunner { /** Logger */ private static final Logger logger = Logger.getLogger(BenchmarkRunner.class); /** * Standardkonstruktor für die Klasse BenchmarkRunner */ public BenchmarkRunner() { super(); } /** * Die Main-Methode zum Starten der Anwendung. * args * Argumente */ public static void main(final String[] args) { String format = ""; String report = ""; String engine = ""; try { // Parsen der Programmparameter. for (String string : args) { int index = string.indexof('='); String param = (string.substring(1, string.indexof('='))); String value = string.substring(index + 1, string.length()); if (param.equals("report")) { report = value.tolowercase(); } else if (param.equals("format")) { format = value.tolowercase(); } else if (param.equals("engine")) { engine = value.tolowercase(); } } // wenn die Parameter leer sind, eine Fehlermeldung ausgeben. if (format.trim().length() == 0 report.trim().length() == 0 engine.trim().length() == 0) { usage(); } // ausgeben des Parameterinhalts. logger.info("starting benchmark for engine=" + engine + " report=" + report + " and format=" + format); // Erstellen der Reportingengine anhand des Engineparameters AReportingEngine repengine = ReportEngineFactory.createReportingEngine(engine); // initialisieren der Engine. repengine.initengine(); // berechnen und ausgeben der Ergebnisse. System.out.println(repEngine.computePerformanceResult( format, report)); // Engine Stoppen. repengine.stopengine(); repengine = null; } catch (Exception e) { e.printstacktrace(); }

100 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 99 } } /** * Die Methode gibt die Informationen in der Konsole aus, wie die Anwendung * zu benutzen ist. */ private static void usage() { System.out.println("Bitte geben Sie Parameter ein:"); System.out.println("-report=Bericht1 Bericht2..."); System.out.println("-format=HTML PDF XLS random"); System.out.println("-engine=jasper pentaho birt"); } Listing 1, Quellcode der Klasse BenchmarkRunner. /** * Die Klasse ReportEngineFactory ist eine Factory-Klasse zum Erzeugen von * AReportingEngine-Objekten. * ado */ public class ReportEngineFactory { /** * Erstellt ein neues AReportingEngine-Objekt. * engine * Parameter für die Engineauswahl(jasper, pentaho oder birt) als * String. * the a reporting engine */ public static AReportingEngine createreportingengine(string engine) { } if (engine.equals("jasper")) { return new ReportingEngineJasperReports( "C:/reports/jasper/"); } else if (engine.equals("pentaho")) { return new ReportingEnginePentaho("C:/reports/pentaho/"); } else if (engine.equals("birt")) { return new ReportingEngineBirt("C:/reports/birt/"); } return null; } Listing 2, Quellcode der Klasse ReportEngineFactory. /** * Die Abstrakte Klasse AReportingEngine. * ado */ public abstract class AReportingEngine { /** The output folder. */ private String outputfolder = "c:/tmpreport/"; /** Quellverzeichnis */ private String inputfolder = ""; /** Endung der Quelldatei */ private String suffix = ""; /** Anzahl der Durchläufe */ private final int cycles = 1000;

101 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 100 /** Feld für die Zufallsberichte. */ private File[] randomreports = null; /** Set zum Auffangen der Zuffalszahlen. */ private final Set randomcatcher = new HashSet(6); /** * Liefert die Endung der Quelldatei. * die Endung. */ public final String getsuffix() { return suffix; } /** * Setzt die Endung der Quelldatei. * suffix * die Endung. */ public final void setsuffix(string suffix) { this.suffix = suffix; } /** * Konstruktor für AReportingEngine mit Quellverzeichnis als Parameter. * inputfolder * das Quellverzeichnis */ public AReportingEngine(String inputfolder) { this.inputfolder = inputfolder; } /** * Liefert das Ausgabeverzeichnis. * das Ausgabeverzeichnis. */ public final String getoutputfolder() { return outputfolder; } /** * Liefert das Quellverzeichnis. * das Quellverzeichnis. */ public final String getinputfolder() { return inputfolder; } /** * Setzt das Quellverzeichnis. * inputfolder * Quellverzeichnis als String */ public final void setinputfolder(string inputfolder) { this.inputfolder = inputfolder; } /** * Setzt das Ausgabeverzeichnis. * outputfolder * Ausgabeverzeichnist als String. */ public final void setoutputfolder(string outputfolder) { this.outputfolder = outputfolder; } /** * Berechnet die Performance und Speicherauslastung fuer den übergebenen * Bericht und Ausgabetyp.

102 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 101 * reporttype * Reporttyp, der erzeugt werden soll(html, PDF, XLS oder random. inputreport * Name der Quelldatei, aus der ein Bericht erzeugt werden soll. * die Ergebnisse als String. * Exception * exception */ public final String computeperformanceresult(string reporttype, String inputreport) throws Exception { // Wenn der übergebene Parameter für Quelldatei leer ist, eine // Fehlermeldung ausgeben. if (inputreport == null inputreport.trim().length() == 0) { throw new IllegalArgumentException("InputFile should " + "not be empty!"); } // Wenn der übergebene Parameter für Typ leer ist, eine Fehlermeldung // ausgeben. if (reporttype == null reporttype.trim().length() == 0) { throw new IllegalArgumentException( "reporttype should not be empty!"); } // Initialisierung der StoppUhr. Stopwatch stopwatch = new Stopwatch().reset(); // Vorbereitung für das Ergebnis String result = inputreport + ";" + reporttype + ";"; // Variable für Quelldatei File inputfile = null; // Bei Zuffalsberichten Zuffalsdateien vorbereiten. if (inputreport.equalsignorecase("random")) { // Öffnen des Quellverzeichnisses. File inputfolder = new File(this.inputFolder); // setzen eines Filters zum Laden der Quelldateien this.randomreports = inputfolder.listfiles(new FileFilter() public boolean accept(file pathname) { // die Quelldateien dürfen nur auf den Suffix // enden und nicht mit "sub" anfangen. return pathname.getname().endswith(suffix) &&!pathname.getname().contains("sub"); } }); } else { // Bei Berichten die Quelldatei laden. inputfile = new File(this.inputFolder + inputreport + this.suffix); } // Ergebnisvariable für Zeit. long totaltime = 0; // Ergebnisvariable für Speicher. long totalmemory = 0; for (int i = 0; i < this.cycles; i++) { // Bei Zuffalsberichten Zuffalsquelldatei laden. if (inputreport.equalsignorecase("random") && this.randomreports!= null && this.randomreports.length!= 0) { inputfile = getrandomfile(); } // startet die Zeitmessung. stopwatch.reset().start(); // Auswahl der geeigneten Methode anhand des Berichttyps. if (reporttype.equalsignorecase("pdf")) { this.createpdfreport(inputfile, i); } else if (reporttype.equalsignorecase("xls")) { this.createxlsreport(inputfile, i); } else if (reporttype.equalsignorecase("html")) { this.createhtmlreport(inputfile, i); } // stoppt die Zeitmessung.

103 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 102 stopwatch.stop(); // Speicherung der Ergebnisse in die temporäre Variablen. totalmemory += (MemUtils.usedMemory() / 1024); totaltime += stopwatch.getelapsedtime(); } // Berechnung der Ergebnisse. result += "" + (totaltime / (this.cycles - 200)) + ";" + (totalmemory / (this.cycles - 200)); } return result; /** * Berechnet eine Zuffalsdatei und gibt diese zurück. * the random file */ private File getrandomfile() { // erzeugt ein neues Random-Objekt. Random randomgenerator = new Random(); // leert den Zahlenpuffer, wenn dieser voll ist. if (randomcatcher.size() == this.randomreports.length) { randomcatcher.clear(); } // berechnet die Zuffalszahl zwischen 0 und der Anzahl der Berichte. int randomint = randomgenerator.nextint(this.randomreports.length); } // falls die Zuffalszahl nicht neue ist, wird eine neue generiert. if (!randomcatcher.add(randomint)) { return getrandomfile(); } return this.randomreports[randomint]; /** * Initialisiert die Reporting-Engine. * Exception * exception */ public abstract void initengine() throws Exception; /** * Generiert ein Bericht im HTML-Format. * inputfile * Bericht-Datei, aus der ein Bericht generiert werden soll. count * count * Exception * exception */ protected abstract void createhtmlreport(file inputfile, int count) throws Exception; /** * Generiert ein Bericht im PDF-Format. * inputfile * Bericht-Datei, aus der ein Bericht generiert werden soll. count * count * Exception * exception */ protected abstract void createpdfreport(file inputfile, int count) throws Exception; /** * Generiert ein Bericht im XLS-Format. * inputfile

104 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 103 * Bericht-Datei, aus der ein Bericht generiert werden soll. count * count * Exception * exception */ protected abstract void createxlsreport(file inputfile, int count) throws Exception; } /** * Stoppt die Reporting-Engine. * Exception * exception */ public abstract void stopengine() throws Exception; Listing 3, Quellcode der Klasse AReportingEngine. /** * Die Klasse ReportingEngineBirt enthaelt die Steuerung fuer BIRT, um die * Berichte in Formaten PDF, HTML und XLS. */ public class ReportingEngineBirt extends AReportingEngine { /** Birt engine. */ private IReportEngine engine; /** * Konstruktor. * inputfolder * Quellverzeichnis, aus dem die Berichte geladen werden. */ public ReportingEngineBirt(String inputfolder) { super(inputfolder); this.setsuffix(".rptdesign"); } /* * (non-javadoc) * de.ikom.reporting.areportingengine#createhtmlreport(java.io.file, * int) public void createhtmlreport(file inputfile, int count) throws Exception { // laden der Design-Datei IReportRunnable design = this.engine.openreportdesign(inputfile.getabsolutepath()); // Erzeugt eine Aufgabe zum Erstellen des Berichtes. IRunAndRenderTask task = this.engine.createrunandrendertask(design); // Setzt den Vater-ClassLoader. task.getappcontext().put( EngineConstants.APPCONTEXT_CLASSLOADER_KEY, this.getclass().getclassloader()); // Initialisiert den Renderer für HTML-Ausgabeformat. HTMLRenderOption htmloptions = new HTMLRenderOption(); htmloptions.setoutputfilename(this.getoutputfolder() + inputfile.getname() + count + ".html"); htmloptions.setoutputformat("html"); htmloptions.setimagedirectory(this.getoutputfolder()); htmloptions.setembeddable(false); // übergabe des Renderers an die Aufgabe.

105 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 104 task.setrenderoption(htmloptions); // Ausführen der Aufgabe task.run(); } // schliessen der Aufgabe task.close(); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createpdfreport(java.io.file, * int) public void createpdfreport(file inputfile, int count) throws Exception { // laden der Design-Datei IReportRunnable design = engine.openreportdesign(inputfile.getabsolutepath()); // Erzeugt eine Aufgabe zum Erstellen des Berichtes. IRunAndRenderTask task = engine.createrunandrendertask(design); // Setzt den Vater-ClassLoader. task.getappcontext().put( EngineConstants.APPCONTEXT_CLASSLOADER_KEY, this.getclass().getclassloader()); // Initialisiert den Renderer für PDF-Ausgabeformat. PDFRenderOption options = new PDFRenderOption(); options.setoption(ipdfrenderoption.pagebreak_pagination_only, Boolean.TRUE); options.setoutputfilename(this.getoutputfolder() + inputfile.getname() + count + ".pdf"); options.setoutputformat("pdf"); // übergabe des Renderers an die Aufgabe. task.setrenderoption(options); // Ausführen der Aufgabe task.run(); } // schliessen der Aufgabe task.close(); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createxlsreport(java.io.file, * int) public void createxlsreport(file inputfile, int count) throws Exception { // laden der Design-Datei IReportRunnable design = engine.openreportdesign(inputfile.getabsolutepath()); // Erzeugt eine Aufgabe zum Erstellen des Berichtes. IRunAndRenderTask task = engine.createrunandrendertask(design); // Setzt den Vater-ClassLoader. task.getappcontext().put( EngineConstants.APPCONTEXT_CLASSLOADER_KEY, this.getclass().getclassloader()); // Initialisiert den Renderer für Excel-Ausgabeformat. EXCELRenderOption exceloptions = new EXCELRenderOption(); exceloptions.setoutputfilename(this.getoutputfolder() + inputfile.getname() + count + ".xls"); exceloptions.setoutputformat("xls"); exceloptions.setofficeversion("office2003");

106 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 105 // übergabe des Renderers an die Aufgabe. task.setrenderoption(exceloptions); // Ausführen der Aufgabe task.run(); } // schliessen der Aufgabe task.close(); /* * (non-javadoc) * de.ikom.reporting.areportingengine#initengine() public void initengine() throws Exception { // Konfigurationen für die Engine erzeugen EngineConfig config = new EngineConfig(); config.setlogconfig("log", Level.OFF); // Platform starten Platform.startup(config); // Factory erzeugen IReportEngineFactory factory = (IReportEngineFactory) Platform.createFactoryObject(IReportEngineFactory.EXTENSION_REPORT_ENGINE_FACTORY); } // Engine erzeugen this.engine = factory.createreportengine(config); this.engine.changeloglevel(level.off); /* * (non-javadoc) * de.ikom.reporting.areportingengine#stopengine() public void stopengine() throws Exception { // Engine stoppen. engine.destroy(); } } // Platform stoppen. Platform.shutdown(); Listing 4, Quellcode der Klasse ReportingEngineBirt. /** * Die Klasse ReportingEngineJasperReports enthaelt die Steuerung fuer BIRT, um * die Berichte in Formaten PDF, HTML und XLS. */ public class ReportingEngineJasperReports extends AReportingEngine { /** * Konstruktor. * inputfolder * Quellverzeichnis, aus dem die Berichte geladen werden. */ public ReportingEngineJasperReports(String inputfolder) { super(inputfolder); this.setsuffix(".jasper"); } /** * Logger fuer diese Klasse. */ private static final Logger logger = Logger

107 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 106 /** Datenbankverbindung */ private Connection con;.getlogger(reportingenginejasperreports.class); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createhtmlreport(java.io.file, * int) public void createhtmlreport(file inputfile, int count) throws Exception { // Laden und Parsen der Design-Datei JasperReport jasperreport = (JasperReport) JRLoader.loadObjectFromLocation(inputFile.getAbsolutePath()); // JasperReport mit Daten aus der Datenbank anreichern. JasperPrint jasperprint = JasperFillManager.fillReport( jasperreport, new HashMap(), con); } // JasperPrint als HTML-Datei exportieren. JRHtmlExporter exporterhtml = new JRHtmlExporter(); exporterhtml.setparameter(jrexporterparameter.jasper_print, jasperprint); exporterhtml.setparameter( JRExporterParameter.OUTPUT_FILE_NAME, this.getoutputfolder() + inputfile.getname() + count + ".html"); exporterhtml.setparameter(jrhtmlexporterparameter.size_unit, JRHtmlExporterParameter.SIZE_UNIT_POINT); exporterhtml.exportreport(); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createpdfreport(java.io.file, * int) public void createpdfreport(file inputfile, int count) throws Exception { // Laden und Parsen der Design-Datei JasperReport jasperreport = (JasperReport) JRLoader.loadObjectFromLocation(inputFile.getAbsolutePath()); } // JasperReport mit Daten aus der Datenbank anreichern. JasperPrint jasperprint = JasperFillManager.fillReport( jasperreport, new HashMap(), con); // JasperPrint als PDF-Datei exportieren. JasperExportManager.exportReportToPdfFile(jasperPrint, this.getoutputfolder() + inputfile.getname() + count + ".pdf"); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createxlsreport(java.io.file, * int) public void createxlsreport(file inputfile, int count) throws Exception { // Laden und Parsen der Design-Datei JasperReport jasperreport = (JasperReport) JRLoader.loadObjectFromLocation(inputFile.getAbsolutePath()); // JasperReport mit Daten aus der Datenbank anreichern. JasperPrint jasperprint = JasperFillManager.fillReport( jasperreport, new HashMap(), con); // JasperPrint als XLS-Datei exportieren.

108 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 107 } JRXlsExporter exporterxls = new JRXlsExporter(); exporterxls.setparameter(jrexporterparameter.jasper_print, jasperprint); exporterxls.setparameter( JRExporterParameter.OUTPUT_FILE_NAME, this.getoutputfolder() + inputfile.getname() + count + ".xls"); exporterxls.setparameter( JRXlsExporterParameter.IS_ONE_PAGE_PER_SHEET, Boolean.FALSE); exporterxls.exportreport(); /* * (non-javadoc) * de.ikom.reporting.areportingengine#initengine() public void initengine() throws Exception { this.con = getconnection(); } /** * Liefert die Datenbankverbindung * Datenbankverbindung * ClassNotFoundException * Klasse-Nicht-Gefunden-Exception SQLException * SQL-Exception */ private static Connection getconnection() throws ClassNotFoundException, SQLException { // Debuginformationen ausgeben if (logger.isdebugenabled()) { logger.debug("getconnection() - start"); } // Datenbanktreiber laden Class.forName(Constants.DB_DRIVER); // Verbindung erzeugen Connection conn = DriverManager.getConnection( Constants.DB_CONNECTION_STRING, Constants.DB_USER, Constants.DB_PASSWORD); } // Debuginformationen ausgeben if (logger.isdebugenabled()) { logger.debug("getconnection() - end - return value=" + conn); } return conn; } /* * (non-javadoc) * de.ikom.reporting.areportingengine#stopengine() public void stopengine() throws Exception { // Datenbankverbindung trennen. if (this.con!= null) { this.con.close(); this.con = null; } } Listing 5, Quellcode der Klasse ReportingEngineJasperReports.

109 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 108 /** * Die Klasse ReportingEnginePentaho enthaelt die Steuerung fuer BIRT, um die * Berichte in Formaten PDF, HTML und XLS. * ado */ public class ReportingEnginePentaho extends AReportingEngine { /** * Konstruktor. * inputfolder * Quellverzeichnis, aus dem die Berichte geladen werden. */ public ReportingEnginePentaho(String inputfolder) { super(inputfolder); this.setsuffix(".xml"); } /* * (non-javadoc) * de.ikom.reporting.areportingengine#createhtmlreport(java.io.file, * int) public void createhtmlreport(file inputfile, int count) throws Exception { // ResourcenManager initialisieren. ResourceManager manager = new ResourceManager(); manager.registerdefaults(); // Laden der Quelldatei Resource res = manager.createdirectly(inputfile.touri().tourl(), JFreeReport.class); JFreeReport report = (JFreeReport) res.getresource(); } // Exportieren im HTML-Format HtmlReportUtil.createDirectoryHTML(report, this.getoutputfolder() + inputfile.getname() + count + ".html"); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createpdfreport(java.io.file, * int) public void createpdfreport(file inputfile, int count) throws Exception { // ResourcenManager initialisieren. ResourceManager manager = new ResourceManager(); manager.registerdefaults(); // Laden der Quelldatei Resource res = manager.createdirectly(inputfile.touri().tourl(), JFreeReport.class); JFreeReport report = (JFreeReport) res.getresource(); } // Exportieren im PDF-Format PdfReportUtil.createPDF(report, this.getoutputfolder() + inputfile.getname() + count + ".pdf"); /* * (non-javadoc) * de.ikom.reporting.areportingengine#createxlsreport(java.io.file, * int) public void createxlsreport(file inputfile, int count) throws Exception { // ResourcenManager initialisieren.

110 B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 109 ResourceManager manager = new ResourceManager(); manager.registerdefaults(); // Laden der Quelldatei Resource res = manager.createdirectly(inputfile.touri().tourl(), JFreeReport.class); JFreeReport report = (JFreeReport) res.getresource(); } // Exportieren im XLS-Format ExcelReportUtil.createXLS(report, this.getoutputfolder() + inputfile.getname() + count + ".xls"); /* * (non-javadoc) * de.ikom.reporting.areportingengine#initengine() public void initengine() throws Exception { // Initialiseren von Engine JFreeReportBoot.getInstance().start(); } } /* * (non-javadoc) * de.ikom.reporting.areportingengine#stopengine() public void stopengine() throws Exception { } Listing 6, Quellcode der Klasse ReportingEnginePentaho.

111 S e i t e 110 C. Abbildungen der Designer-Oberflächen Abbildung 15, Designer-Oberfläche Birt. Abbildung 16, Designer-Oberfläche Pentaho Report Designer.

112 C A b b i l d u n g e n d e r Designer-Oberflächen S e i t e 111 Abbildung 17, Designer-Oberläche IReport.