evaluierung von reporting-frameworks am beispiel der...
TRANSCRIPT
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
11032929
Erster Prüfer: Prof. Dr. Heide Faeskorn-Woyke
Zweiter Prüfer: Dipl.-Kfm. Kai Lehmann
Gummersbach, im Oktober 2008
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.
S e i t e 2
Inhaltsverzeichnis
Abbildungsverzeichnis .................................................................................................... 5
Tabellenverzeichnis ......................................................................................................... 6
Listingverzeichnis ............................................................................................................ 8
Abkürzungs- und Symbolverzeichnis ............................................................................ 9
Glossar ............................................................................................................................ 10
1. Einleitung ................................................................................................................... 11
1.1. Problembeschreibung ........................................................................................... 11
1.2. Zielsetzung ........................................................................................................... 11
1.3. Inhalt der Diplomarbeit ........................................................................................ 12
2. Business Intelligence und Reporting ....................................................................... 14
2.1. Business Intelligence – theoretische Grundlagen ................................................ 14
2.1.1. Begriffsdefinition .................................................................................................................... 14
2.1.2. Architektur .............................................................................................................................. 17
2.2. Einordnung des Berichtswesens ........................................................................... 18
2.3. Berichtsgestaltung ................................................................................................ 19
2.4. Open Source ......................................................................................................... 21
3. Vorbereitung der Evaluierung ................................................................................. 22
3.1. Evaluierungs-Model ............................................................................................. 22
3.2. Kriterienkatalog.................................................................................................... 23
3.2.1. Kriterien für Vorbewertung .................................................................................................... 23
3.2.2. Kriterien für Hauptbewertung ................................................................................................. 24
3.3. Testberichte .......................................................................................................... 35
3.3.1. Einleitung................................................................................................................................ 35
3.3.2. Übersicht ................................................................................................................................. 35
3.4. Benchmarkanwendung ......................................................................................... 36
3.4.1. Beschreibung .......................................................................................................................... 36
3.4.2. Architektur .............................................................................................................................. 36
4. Auswahl und Vorstellung der Frameworks ............................................................ 38
4.1. Softwareauswahl .................................................................................................. 38
I n h a l t s v e r z e i c h n i s S e i t e 3
4.2. Pentaho Reporting ................................................................................................ 38
4.2.1. Einführung .............................................................................................................................. 38
4.2.2. Funktionsweise ....................................................................................................................... 39
4.2.3. Architektur .............................................................................................................................. 40
4.3. JasperReports ....................................................................................................... 41
4.3.1. Einführung .............................................................................................................................. 41
4.3.2. Funktionsweise ....................................................................................................................... 41
4.3.3. Architektur .............................................................................................................................. 42
4.4. BIRT ..................................................................................................................... 45
4.4.1. Einführung .............................................................................................................................. 45
4.4.2. Funktionsweise ....................................................................................................................... 46
4.4.3. Architektur .............................................................................................................................. 47
5. Durchführung der Evaluierung ............................................................................... 53
5.1. Verteilung der Gewichtungen bei Kategorien...................................................... 53
5.1.1. Gewichtungen unter der Kategorie Functionality ................................................................... 55
5.1.2. Gewichtungen unter Kategorie Usability ................................................................................ 60
5.1.3. Gewichtungen unter Kategorie Documentation ...................................................................... 60
5.1.4. Gewichtungen unter Kategorie Quality .................................................................................. 61
5.1.5. Gewichtungen unter Kategorie Architecture .......................................................................... 61
5.1.6. Gewichtungen unter Kategorie Scalability ............................................................................. 62
5.1.7. Gewichtungen unter Kategorie Community ........................................................................... 62
5.2. Bewertung der Frameworks ................................................................................. 63
5.2.1. Bewertung in der Kategorie Functionality .............................................................................. 63
5.2.2. Bewertung in der Kategorie Usability .................................................................................... 65
5.2.3. Bewertung in der Kategorie Documentation .......................................................................... 67
5.2.4. Bewertung in der Kategorie Quality ....................................................................................... 68
5.2.5. Bewertung in der Kategorie Architecture ............................................................................... 69
5.2.6. Bewertung in der Kategorie Scalability .................................................................................. 70
5.2.7. Bewertung in der Kategorie Community ................................................................................ 71
5.2.8. Ergebnisse der BRR-Bewertung ............................................................................................. 71
5.2.9. Zusatzbewertung der Benutzeroberfläche ............................................................................... 72
5.2.10. Ergebnisse der Zusatzbewertung der Benutzeroberfläche .................................................... 78
5.3. Performance und Speicherauslastung .................................................................. 79
5.3.1. Testumgebung ........................................................................................................................ 79
5.3.2. Ergebnisse JasperReports ....................................................................................................... 80
5.3.3. Ergebnisse Birt ....................................................................................................................... 81
I n h a l t s v e r z e i c h n i s S e i t e 4
5.3.4. Ergebnisse Pentaho Reporting ................................................................................................ 83
5.3.5. Gegenüberstellung der Performance und Speicherauslastung ................................................ 84
5.4. Entscheidungsmatrix ............................................................................................ 88
6. Zusammenfassung ..................................................................................................... 89
Literaturverzeichnis ...................................................................................................... 91
Anhang ........................................................................................................................... 96
S e i t e 5
Abbildungsverzeichnis
Abbildung 1, unterschiedliche Facetten und Abgrenzungen von Business Intelligence. ...................16
Abbildung 2, BI-Schichtenmodell. ......................................................................................................17
Abbildung 3, Prozesse des betrieblichen Berichtswesens. ..................................................................19
Abbildung 4, Merkmale zur Kennzeichnung und Gestaltung von Berichten. ...................................20
Abbildung 5, 4 Phasen des BRR-Models. ...........................................................................................22
Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung. .......................................36
Abbildung 7, Pentaho-Reporting High-Level-Architektur. ...............................................................39
Abbildung 8, Pentaho Reporting Architektur. ...................................................................................40
Abbildung 9, JasperReports High-Level-Architektur. ......................................................................42
Abbildung 10, Jasper-Reporting-Engine. ...........................................................................................43
Abbildung 11, BIRT High-Level Architektur. ...................................................................................46
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. ....50
Abbildung 21, Designer-Oberfläche Birt. ......................................................................................... 115
Abbildung 22, Designer-Oberfläche Pentaho Report Designer. ...................................................... 115
Abbildung 23, Designer-Oberläche IReport. .................................................................................... 116
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. ..............................................................................26
Tabelle 3, Metriken aus der Kategorie Quality. .................................................................................28
Tabelle 4, Metriken aus der Kategorie Security.................................................................................29
Tabelle 5, Metriken aus der Kategorie Performance. ........................................................................29
Tabelle 6, Metriken aus der Kategorie Scalability. ............................................................................30
Tabelle 7, Metriken aus der Kategorie Architecture. ........................................................................31
Tabelle 8, Metriken aus der Kategorie Support. ................................................................................31
Tabelle 9, Metriken aus der Kategorie Documentation. ....................................................................32
Tabelle 10, Metriken aus der Kategorie Adoption. ............................................................................33
Tabelle 11, Metriken aus der Kategorie Community. ........................................................................34
Tabelle 12, Metriken aus der Kategorie Professionalism. ..................................................................34
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. .............................................................57
Tabelle 17, Übersicht: Gewichtungen von Metriken unter Kategorie Usability. ..............................60
Tabelle 18, Übersicht: Gewichtungen von Metriken unter Kategorie Documentation. ....................60
Tabelle 19, Übersicht: Gewichtungen von Metriken unter Kategorie Quality. .................................61
Tabelle 20, Übersicht: Gewichtungen von Metriken unter Kategorie Architecture. ........................61
Tabelle 21, Übersicht: Gewichtungen von Metriken unter Kategorie Scalability. ............................62
Tabelle 22, Übersicht: Gewichtungen von Metriken unter Kategorie Community. ..........................62
Tabelle 23, Bewertungstabelle für die Kategorie Functionality. ........................................................65
Tabelle 24, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Usability. ................66
Tabelle 25, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Documentation. .....67
Tabelle 26, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Quality. ..................68
Tabelle 27, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Architecture. .........69
Tabelle 28, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Scalability. .............70
Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community. ...........71
Tabelle 30, Übersicht: Ergebnisse der BRR-Bewertung. ...................................................................72
Tabelle 31, Metriken zum Bewerten von der Benutzeroberfläche. ....................................................73
Tabelle 32, Bewertung der Metrik Z1. ...............................................................................................74
Tabelle 33, Bewertung der Metrik Z2. ...............................................................................................74
Tabelle 34, Bewertung der Metrik Z3. ...............................................................................................74
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 Z4. ...............................................................................................75
Tabelle 36, Bewertung der Metrik Z5. ...............................................................................................75
Tabelle 37, Bewertung der Metrik Z6. ...............................................................................................76
Tabelle 38, Bewertung der Metrik Z7. ...............................................................................................76
Tabelle 39, Bewertung der Metrik Z8. ...............................................................................................77
Tabelle 40, Bewertung der Metrik Z10. .............................................................................................77
Tabelle 41, Bewertung der Metrik Z11. .............................................................................................78
Tabelle 42, Bewertung der Metrik Z12. .............................................................................................78
Tabelle 43, Übersicht: Ergebnisse der Zusatzbewertung. ..................................................................79
Tabelle 44, Übersicht der Test-Systeme. ............................................................................................80
Tabelle 45, Performance und Speicherauslastung von JasperReports. .............................................81
Tabelle 46, Performance und Speicherauslastung von BIRT. ...........................................................82
Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting. ......................................84
Tabelle 48, Gegenüberstellung von Performanceergebnissen. ...........................................................85
Tabelle 49, Gegenüberstellung von Speicherauslastungsergebnissen. ...............................................87
Tabelle 50, durchschnittliche Performance nach Formaten. .............................................................87
Tabelle 51, durchschnittliche Speicherauslastung nach Formaten. ...................................................87
Tabelle 52, Entscheidungsmatrix. ......................................................................................................88
S e i t e 8
Listingverzeichnis
Listing 1, Quellcode der Klasse BenchmarkRunner. .........................................................................99
Listing 2, Quellcode der Klasse ReportEngineFactory. .....................................................................99
Listing 3, Quellcode der Klasse AReportingEngine. ........................................................................ 103
Listing 4, Quellcode der Klasse ReportingEngineBirt. .................................................................... 105
Listing 5, Quellcode der Klasse ReportingEngineJasperReports. ................................................... 107
Listing 6, Quellcode der Klasse ReportingEnginePentaho. ............................................................. 114
S e i t e 9
Abkürzungs- und Symbolverzeichnis
BI Business Intelligence
CSV Comma Separated Values
DOC Dateiendung der Dateien des Textverarbeitungsprogramms Microsoft
Word
ETL Extract, Transform, Load
HTML Hypertext Markup Language
J2EE Java 2 Enterprise Edition
JDBC Java Database Connectivity
MDX Multi-dimensional Expressions
ODA Open Data Access
ODT Open Document Text
OLAP On-Line Analytical Processing
PDF Portable Document Format
POJO Plain Old Java Object
PPT Dateiendung der Dateien des Präsentationsprogramms Microsoft
PowerPoint
RCP Rich Client Platform
ROM Report Object Model
RTF Rich Text Format
SVG Scalable Vector Graphics
TXT Abkürzung für Text
XMI XML Metadata Interchange
XML Extensible Markup Language
XMLA XML for Analysis
S e i t e 10
Glossar
Drill-Down: 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.
Engine: In der Informationstechnologie wird mit Engine (von engl. Antrieb) ein
eigenständiger Teil eines Computerprogramms bezeichnet, der komplexe
Berechnungen oder Simulationen durchführt.
Framework: 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
Platform: 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.
Rich-Client: 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).
S e i t e 11
1. 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.
1.1. Problembeschreibung
Die Grundlage der Arbeit wurde durch folgende Feststellung umrissen:
1. Die angebotenen Reports2 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.
1.2. Zielsetzung
Zur Verbesserung des vorhandenen Reporting-Systems in der angebotenen
Softwarelösung soll eine Evaluierung von Reporting-Frameworks3 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 Source4 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.
1 E i n l e i t u n g S e i t e 12
7. 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.
1.3. 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.
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.
S e i t e 14
2. Business Intelligence und Reporting
2.1. Business Intelligence – theoretische Grundlagen
2.1.1. 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 Kosten-
und 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. 89.
6 Vgl. Kemper/Lee (2001); Gluchowski/Kemper (2006); Gluchowski/Gabriel/Dittmar (2008), S. 89;
Strauch/Winter (2002)
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.
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 Auswertungs-
und 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. 7.
9 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 91; Gluchowski (2001), S. 6.
10 Übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 92 in Anlehnung an Gluchowski (2001), S. 7.
2 Business Intelligence und Reporting S e i t e 17
relevanter Informationen sowie um die Bausteine zur Präsentation und Analyse dieser
Inhalte.“11
2.1.2. 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
Untersuchung und Auswertung
(Analysesysteme)
-Operative Vorsysteme
-Externe Daten
Speicherung (Data Warehouse)
Aufbereitung (ETL-Systeme)
Präsentations-
schicht
Daten-
bereitstellungs-
schicht
Analyse-
schicht
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. 93.
12 Abgeändert übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 109, vgl. u.a.
Kemper/Mehanna/Unger (2006), S. 10.
2 Business Intelligence und Reporting S e i t e 18
Warehouse13
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.15
2.2. 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.17
13
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. 208.
17 Kemper/Mehanna/Unger (2006), S. 110; Gluchowski (2006), S. 209; Heine/Wende (2004), S. 331 ff.
2 Business Intelligence und Reporting S e i t e 19
Berichtsgestaltung und -erstellung
Berichtsverwaltung
Berichtsverteilung
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.
2.3. 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.19
18
Modifiziert übernommen aus Kemper/Mehanna/Unger (2006), S. 110.
19 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 207; Gluchowski (2006), S. 210.
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. 210.
21 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 208; Gluchowski (2006), S. 211.
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.23
2.4. 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 Kommission24
.
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.26
22
Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 209; Gluchowski (2006), S. 211.
23 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 209; Gluchowski (2006), S. 212.
24 MERIT (2006)
25 Open Source Definition (2008)
26 Open Source Definition (2008)
S e i t e 22
3. 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
verwendet28
. 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).
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.
3.2. Kriterienkatalog
3.2.1. 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.
3 Vorbereitung der Evaluierung S e i t e 24
3.2.2. Kriterien für Hauptbewertung29
3.2.2.1. 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).
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.
3.2.2.2. 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
3 Vorbereitung der Evaluierung S e i t e 26
4 - 10 - 30 Minuten
3 - 30 min - 1 Stunde
2 - 1 - 4 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
4 - 10 - 30 Minuten
3 - 30 min - 1 Stunde
2 - 1 - 4 Stunden
1 - > 4 Stunden
Tabelle 2, Metriken aus der Kategorie Usability.
3.2.2.3. 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: 5 - 3 – 4 Releases
3 - 1 – 2 oder 5 – 6 Releases
3 Vorbereitung der Evaluierung S e i t e 27
1 - 0 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
4 - 50 - 100 Fehler
3 - 100 – 500 Fehler
2 - 500 – 1000 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
4 - 1 - 5 Fehler
3 - 5 – 10 Fehler
2 - 10 – 20 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
3 Vorbereitung der Evaluierung S e i t e 28
4 - 1 - 2 Wochen
3 - 2 - 3 Wochen
2 - 3 - 4 Wochen
1 - > 4 Wochen
Tabelle 3, Metriken aus der Kategorie Quality.
3.2.2.4. 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
4 - 1 – 2 Sicherheitslücken
3 - 3 – 4 Sicherheitslücken
2 - 5 – 6 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
2 - 3 – 5 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
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.
3.2.2.5. 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.
3.2.2.6. 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
3 Vorbereitung der Evaluierung S e i t e 30
1 - 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.
3.2.2.7. 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
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.
3.2.2.8. 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 - [300 – 720) Nachrichten pro Monat
3 - [150 – 300) 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.
3.2.2.9. Documentation-Kategorie
Die Qualität der Dokumentation, die die Firma oder die Community zu dieser Software
anbieten, wird in dieser Kategorie bewertet.
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.
3.2.2.10. 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
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.
3.2.2.11. 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 - [300 – 720) Nachrichten pro Monat
3 - [150 – 300) 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
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.
3.2.2.12. 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.
3 Vorbereitung der Evaluierung S e i t e 35
3.3. Testberichte
3.3.1. 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.
3.3.2. Ü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
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.
3.4. Benchmarkanwendung
3.4.1. 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.
3.4.2. Architektur
ReportBenchmark Klassendiagramm
+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()
AReportingEngine
+createReportingEngine(ein engine : String) : AReportingEngine
ReportingEngineFactory
+main(ein args : String[])
BenchmarkRunner«uses»
«create»
«uses»
+start() : Stopwatch
+stop() : Stopwatch
+reset() : Stopwatch
+getElapsedTime() : long
Stopwatch«uses»
+usedMemory() : long
MemUtils«uses»
Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung.
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.
3.4.2.1. 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.
3.4.2.2. ReportingEngineFactory
Die ReportingEngineFactory-Klasse erzeugt anhand des übergebenen Parameters die
entsprechende ReportingEngine-Klasse.
3.4.2.3. 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.
S e i t e 38
4. Auswahl und Vorstellung der Frameworks
4.1. Softwareauswahl
Nach der Internet- und Literaturrecherche30
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 2.3.1 erfüllen.
Projekt Aktuelle
Version
Erstes
Release
Designer Reporting-
Engine
Pentaho-BI 1.6 2006 Pentaho
ReportDesigner
JFreeReport
BIRT 2.2.2 2004 BIRT Designer BIRT
JasperIntelligence 3.0 2006 IReport JasperReports
SpagoBI 2.0 2006 SpagoBIStudio JasperReports,
BIRT
openi 1.3 2005 - JasperReports
OpenReports 3.0 2003 - 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.
4.2. Pentaho Reporting
4.2.1. 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)
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 0.8.8 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.
4.2.2. Funktionsweise
Die Reportentwicklung unter Pentaho-Reporting unterteilt sich in zwei Stufen:
Designtime und Runtime, Abbildung 7.
RuntimeDesigntime
Action
Sequence
Data
Pentaho Report
Design Wizard
JFreeReport
Pentaho Reporting Engine
HTML
XML
...
*.xaction
*.xml
Pentaho Report
Designer
Extended
Report
Definition
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.
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.
4.2.3. 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.
J2EE Server
Action Sequence
Parameter
SQL Rule
Action
Report
Action
Prompt/Filter
Action
Ergebnis
Bericht
We
b B
row
se
r
DBMSSQL
Component
Reporting
Component
Reporting
Engine
SQL
Berichtsdefinition
und Daten
Abfrageergebnis
Bericht
SQL
Ergebnis
BerichtBerichtsdefinition
und Daten
Aufruf
Action Sequence
HTML Formular
Formularparameter
Bericht
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
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.
4.3. JasperReports
4.3.1. 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 0.1.5
freigegeben.
2004 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 2005.
JasperSoft sponserte die Entwicklung von JasperReports, dadurch konnten Teodor und
andere JasperSoft-Entwickler in Vollzeit daran arbeiten.
4.3.2. Funktionsweise
Die Reportentwicklung mit JasperReports unterteilt sich in zwei Stufen: Design- und
Runtime, Abbildung 9.
4 Auswahl und Vorstellung der Frameworks S e i t e 42
RuntimeDesigntime
XML
Report
Design
Data
JasperAssistantCustom Report
Designer
Jasper Compiler
Report
Document
Jasper Reporting Engine
HTML
XML
...*.jrxml
*.jrprint
*.jasper
IReport
Native Binary Template
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.
4.3.3. 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, 36-37.
4 Auswahl und Vorstellung der Frameworks S e i t e 43
SVG-, Word- und Excel-Exporte, verwendet JasperReports Fremdbibliotheken aus
JasperReportingEngine
JRXmlLoader
JRXML
Jasper-
Report
JasperPrint
Jasper-
Design
JasperPrint
Manager
JasperExport
Manager
JasperFill
Manager
JRCompiler
JasperCompile
Manager
ScreenPrinterPDFHTMLXML
printexport
fill
compile
parse
SQL
XML
EJB
Hibernate
POJO
JNDI
XQery, XPath
JRDataSource
JDBC, JNDI
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 10.
4.3.3.1. 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.
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.
4.3.3.2. 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.
4.3.3.3. 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.
4.3.3.4. 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.
4.3.3.5. 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
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.
4.3.3.6. 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.).
4.3.3.7. 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.
4.4. BIRT
4.4.1. 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
4 Auswahl und Vorstellung der Frameworks S e i t e 46
6. Oktober 2004 akzeptiert und zu einem Top-Level-Projekt innerhalb der Eclipse-
Community wurde, spendete Actuate die geleistete Arbeit.
4.4.2. 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.
RuntimeDesigntime
XML
Report
DesignData
Eclipse
Report
Designer
Web Based
Report
Designer
Custom
Report
Designer...
Report Design Engine
Report
Document
Charting Engine
Report Engine
Generation
Services
Presentation
Services
HTML
XML
...
*.rptdesign*.rptdocument
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
4 Auswahl und Vorstellung der Frameworks S e i t e 47
4.4.3. 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.
4.4.3.1. Applikationen
BIRT bietet drei Hauptapplikationen an:
BIRT Report Designer
BIRT RCP Report Designer
BIRT Report Viewer
4 Auswahl und Vorstellung der Frameworks S e i t e 48
BIRT applications
BIRT designers
BIRT Report Designer
Chart Builder
BIRT RCP Report Designer
BIRT run-time application
BIRT Report Viewer
Custom Viewer ...
BIRT engines
Design engine Data engineReport engine
Presentation
engineScript engine
Chart engine
Generation
engine
BIRT core component plug-ins
Eclipse frameworks
Eclipse platforms
Data Tools
Framework
Eclipse Modeling
Framework
Graphical
Framework
Eclipse Tools Platform Eclipse Rich Client Platform
Abbildung 12, BIRT Komponenten als Plug-ins für die Eclipse-Platform34
4.4.3.2. 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.
4 Auswahl und Vorstellung der Frameworks S e i t e 49
BIRT Report Designer
Bookmarks
Charts
Data sources
Data filters
Data groups
Data mapping rules
Tools to create and edit report components and rules, including:
Data sets
Expressions
Highlighting rules
Hyperlinks
Library components
Master pages
Properties
Report layout
Report parameters
Report XML
Scripts
Styles
Report online explorer
Library outline explorer
Data explorer
Report item palette
Report online explorer
BIRT report viewer
Data previewer
Data engine
ODA framework
Data sourceCustom data
source
Design engine
Report Object Model (ROM)
Standard BIRT report items
Report item extensions
Report library files
(.rptlibrary)
Report design
(.rptdesign)
Report template files
(.rpttemplate)
Web application
BIRT report viewer
Report previewer Custom Java application
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.
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.
4.4.3.3. 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.
BIRT report viewer
Report engine
Generation engine
Presentation engine
Report design
(.rptdesign)
Chart engine
Design engine
Report items
Script engine Data engine
Data access engine
Data transform engine
Report executor
Report document
(.rptdocument)
Data sourceCustom data
source
ODA Framework
Data Engine
Data access engine
Script engine Emitters
Report renderer
PDF emitter
HTML emitter
Custom emitterChart Engine
Report
(PDF, HTML, Custom format)
Abbildung 14, BIRT Report Viewer: Beziehung zwischen Standard- und Spezialkomponenten.36
36
Weathersby/et al. (2006), S. 50.
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.
4.4.3.4. 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.
4.4.3.4.1 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.
4.4.3.4.2 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.
4.4.3.4.3 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.
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.
4.4.3.4.4 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.
4.4.3.4.4.1 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.
4.4.3.4.4.2 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.
S e i t e 53
5. 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
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
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.
5.1.1. 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
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
5 Durchführung der Evaluierung S e i t e 57
Funktionalitäten Gewichtung
Reporting
Preview Funktionalität 2
Scheduler für Reportgenerierung 2
E-Mail 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
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, E-Mail
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
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 E-Mail 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 E-Mail Bursting Funktionalität bietet die Möglichkeit die
Berichte automatisch an die Benutzer in regelmäßigen Abständen über E-Mails 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
5 Durchführung der Evaluierung S e i t e 60
Web-Applikationen zum Entwerfen der Berichte bieten nicht die gleichen
umfangreichen Funktionalitäten wie die Desktop-Anwendungen.
5.1.2. 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.
5.1.3. 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.
5 Durchführung der Evaluierung S e i t e 61
5.1.4. 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 4.1-4.4 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.
5.1.5. 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.
5 Durchführung der Evaluierung S e i t e 62
5.1.6. 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.
5.1.7. Gewichtungen unter Kategorie Community
Nr. Metrik Gewichtung
8.1 Durchschnittliches Volumen einer Hauptmailinglist in den
letzten 6 Monaten. 75%
8.2 Anzahl von eindeutigen Quellcode-Beitragenden in den letzten
6 Monaten. 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.
5 Durchführung der Evaluierung S e i t e 63
5.2. 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).
5.2.1. Bewertung in der Kategorie Functionality
BIRT Pentaho
Reporting
Jasper-
Reports
Standardfunktionalitäten
Ausgabeformate
PDF 3 3 3
HTML 3 3 3
Excel 3 3 3
Word (DOC) 2 -2 -2
Word (RTF) 2 2 2
Datenquellen
JDBC 3 3 3
Hibernate 2 2 2
Diagramme
Einbindung dynamischer Inhalte (Bilder, Texte) 3 3 3
Einbindung von Charts 3 3 3
Reporting
Templating (Schablonen) 3 3 3
Verschiedene Datenquellen innerhalb eines
Reports 3 3 3
Drill-Down-Analyse innerhalb eines Reports 2 -2 2
Internationalisierung (Zeichensatz, Währung..) 3 -3 3
Unterstützt Sub-Reports (Verschachtelung) 2 2 2
5 Durchführung der Evaluierung S e i t e 64
BIRT Pentaho
Reporting
Jasper-
Reports
Parametrisierte Reports 3 3 3
Aggregationen und Gruppierung 2 2 2
Zusatzfunktionalitäten
Ausgabeformate
TXT 0 1 1
PPT 1 0 0
OpenOffice (ODT) 0 0 1
XML 1 0 1
CSV 2 0 2
SVG (Scalable Vector Graphics) 1 0 1
Datenquellen
POJO/Java Beans 2 0 2
CSV 1 0 1
XML 1 1 1
Web Services 1 1 0
XML/A,MDX 0 1 1
Metadatenunterstützung 0 1 0
Reporting
Preview Funktionalität 2 2 2
Scheduler für Reportgenerierung 0 2 2
E-Mail Bursting (Verteilung) 0 2 0
View Engine für Web-Applikation 2 2 2
View Engine für Desktop-Anwendung 2 0 2
5 Durchführung der Evaluierung S e i t e 65
BIRT Pentaho
Reporting
Jasper-
Reports
Report-Entwurf aus Web-Applikation 0 1 0
Pixelgenaue Report-Erstellung 0 2 2
Cross-Tab Unterstützung 2 0 2
Bewertung in % 142,9% 104,8% 145,2%
Bewertung in Punkten 5 5 5
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, E-Mail 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.
5.2.2. Bewertung in der Kategorie Usability
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
2.1 Endbenutzer UI-Erfahrung 2,25 2,25 2,25
2.2 Zeit für Installation der erforderlichen
Software, die die Open-Source-Software
voraussetzt.
0 0 0
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
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,25.
5.2.3. Bewertung in der Kategorie Documentation
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
3.1 Vorhandensein von verschiedenen
Dokumenten. 3,75 3 3,75
3.2 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
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.
5.2.4. Bewertung in der Kategorie Quality
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
4.1 Anzahl der Minor-Releases in den letzten
12 Monaten 0,75 0,75 0,75
4.2 Anzahl der Point/Patch Releases in den
letzten 12 Monaten 0,5 0,3 0,3
4.3 Anzahl der offenen Fehler in den letzten 6
Monaten 0,15 0,6 0,6
4.4 Anzahl der behobenen Fehler in den letzten
6 Monaten 0,75 0,75 0,6
4.5 Anzahl der geöffneten P1/kritischen
Fehler. 0,6 0,4 0,6
4.6 Durchschnittliches Alter eines P1 Fehlers
in den letzten 6 Monaten 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
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.
5.2.5. Bewertung in der Kategorie Architecture
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
5.1 Gibt es irgendwelche Drittanbieter Plug-
ins? 2,5 0,5 2
5.2 Öffentliche API/ externe Dienste 1,5 0,9 0,9
5.3 Ein- und Ausschalten von Funktionen
durch Konfiguration 1 1 1
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 Plug-
ins. Es werden 6 Plug-ins mitgeliefert, deswegen bekommt JasperReports eine
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.
5.2.6. 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 5 5 5
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.
5 Durchführung der Evaluierung S e i t e 71
5.2.7. Bewertung in der Kategorie Community
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
8.1 Durchschnittliches Volumen einer
Hauptmailinglist in den letzten 6 Monaten. 3,75 3,75 3,75
8.2 Anzahl von eindeutigen Quellcode-
Beitragenden in den letzten 6 Monaten. 1,25 0,75 0,75
Summe 5 4,5 4,5
Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community.
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 10-
19 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.
5.2.8. Ergebnisse der BRR-Bewertung
Nr. Kategorie Gewichtung BIRT Pentaho
Reporting
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
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.
5.2.9. 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
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.
5 Durchführung der Evaluierung S e i t e 74
5.2.9.1. Bewertung der Metrik Z1
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z1 Platzierung der Elemente/Buttons auf der
Benutzeroberfläche. 4 5 4
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.
5.2.9.2. Bewertung der Metrik Z2
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z2 Unterstützung durch die
Benutzeroberfläche. 5 3 3
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.
5.2.9.3. Bewertung der Metrik Z3
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z3 Wizard Unterstützung. 3 5 5
Tabelle 34, Bewertung der Metrik Z3.
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.
5.2.9.4. Bewertung der Metrik Z4
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z4 Entwurf der komplexen Berichte. 5 3 3
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.
5.2.9.5. Bewertung der Metrik Z5
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z5 Qualität der Fehlermeldungen. 5 4 3
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
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.
5.2.9.6. Bewertung der Metrik Z6
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z6 Entwurf und Konfiguration von
Diagrammen. 5 4 4
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.
5.2.9.7. Bewertung der Metrik Z7
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z7 Entwurf und Konfiguration von
Aggregationen und Gruppierungen. 5 4 4
Tabelle 38, Bewertung der Metrik Z7.
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.
5.2.9.8. Bewertung der Metrik Z8
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z8 Entwurf und Konfiguration von Tabellen. 4 3 3
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.
5.2.9.9. Bewertung der Metrik Z10
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z9 Mitgelieferte Hilfe. 5 1 1
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
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.
5.2.9.10. Bewertung der Metrik Z11
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z10 Stabilität der Anwendung. 5 3 3
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.
5.2.9.11. Bewertung der Metrik Z12
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z11 Preview-Funktionalitäten. 5 5 3
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.
5.2.10. Ergebnisse der Zusatzbewertung der Benutzeroberfläche
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z1 Platzierung der Elemente/Buttons auf der
Benutzeroberfläche. 4 5 4
Z2 Unterstützung durch die
Benutzeroberfläche. 5 3 3
Z3 Wizard Unterstützung. 3 5 5
Z4 Entwurf der komplexen Berichte. 5 3 3
5 Durchführung der Evaluierung S e i t e 79
Nr. Metrik BIRT Pentaho
Reporting
Jasper-
Reports
Z5 Qualität der Fehlermeldungen. 5 4 3
Z6 Entwurf und Konfiguration von
Diagrammen. 5 4 4
Z7 Entwurf und Konfiguration von
Aggregationen und Gruppierungen. 5 4 4
Z8 Entwurf und Konfiguration von Tabellen. 4 3 3
Z9 Mitgelieferte Hilfe. 5 1 1
Z10 Stabilität der Anwendung. 5 3 3
Z11 Preview-Funktionalitäten. 5 5 3
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,
90-130 MB.
5.3. 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.
5.3.1. 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“.
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 1000 100
Java Version 1.6u7
JDBC Version 10.1.0.5.0
Tabelle 44, Übersicht der Test-Systeme.
5.3.2. 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
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 10427 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.
5.3.3. Ergebnisse Birt
Bericht/Format Erstellungszeit Speicherauslastung Dateigröße
Bericht1
HTML 458 ms 24275 KB 758 KB
XLS 556 ms 31461 KB 389 KB
PDF 731 ms 17682 KB 54 KB
Bericht2
HTML 466 ms 25953 KB 763 KB
XLS 570 ms 32269 KB 395 KB
PDF 753 ms 17313 KB 55 KB
Bericht3
5 Durchführung der Evaluierung S e i t e 82
Bericht/Format Erstellungszeit Speicherauslastung Dateigröße
HTML 319 ms 19050 KB 9 KB
XLS37
308/359 ms 19398/22006 KB 7/95 KB
PDF 852 ms 23986 KB 106 KB
Bericht4
HTML 471 ms 16217 KB 759 KB
XLS 553 ms 26113 KB 390 KB
PDF 721 ms 18736 KB 55 KB
Bericht5
HTML 515 ms 24564 KB 941 KB
XLS 690 ms 33230 KB 633 KB
PDF 991 ms 17932 KB 98 KB
Bericht6
HTML 613 ms 22180 KB 552 KB
XLS 1007 ms 32824 KB 614 KB
PDF 1150 ms 18282 KB 60 KB
Random-Test
HTML 479 ms 26148 KB -
XLS 612 ms 36711 KB -
PDF 849 ms 24816 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.
5 Durchführung der Evaluierung S e i t e 83
5.3.4. Ergebnisse Pentaho Reporting
Bericht/Format Erstellungszeit Speicherauslastung Dateigröße
Bericht1
HTML 1198 ms 11947 KB 320 KB
XLS 1166 ms 6825 KB 87 KB
PDF 1385 ms 10348 KB 65 KB
Bericht2
HTML 1299 ms 6349 KB 323 KB
XLS 1205 ms 6591 KB 103 KB
PDF 1216 ms 10394 KB 64 KB
Bericht3
HTML 454 ms 10108 KB 4 KB
XLS 347 ms 10393 KB 97 KB
PDF 438 ms 13563 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 10417 KB 98 KB
Bericht6
HTML 2822 ms 8069 KB 302 KB
XLS 2623 ms 12499 KB 67 KB
PDF 2869 ms 6737 KB 99 KB
5 Durchführung der Evaluierung S e i t e 84
Bericht/Format Erstellungszeit Speicherauslastung Dateigröße
Random-Test
HTML 1259 ms 12711 KB -
XLS 1230 ms 10496 KB -
PDF 1321 ms 15145 KB -
Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting.38
5.3.5. 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.
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.
5 Durchführung der Evaluierung S e i t e 86
Bericht/Format BIRT Pentaho Reporting Jasper-Reports
Bericht1
HTML 24275 KB 11947 KB 3233 KB
XLS 31461 KB 6825 KB 3589 KB
PDF 17682 KB 10348 KB 3237 KB
Bericht2
HTML 25953 KB 6349 KB 3738 KB
XLS 32269 KB 6591 KB 5367 KB
PDF 17313 KB 10394 KB 4716 KB
Bericht3
HTML 19050 KB 10108 KB 4634 KB
XLS 19398/22006 KB 10393 KB 3960 KB
PDF 23986 KB 13563 KB 5529 KB
Bericht4
HTML 16217 KB 9984 KB 3445 KB
XLS 26113 KB 6500 KB 3163 KB
PDF 18736 KB 7837 KB 3804 KB
Bericht5
HTML 24564 KB 8287 KB 3207 KB
XLS 33230 KB 7569 KB 4054 KB
PDF 17932 KB 10417 KB 3679 KB
Bericht6
HTML 22180 KB 8069 KB 5540 KB
XLS 32824 KB 12499 KB 10427 KB
PDF 18282 KB 6737 KB 6791 KB
Random-Test
5 Durchführung der Evaluierung S e i t e 87
Bericht/Format BIRT Pentaho Reporting Jasper-Reports
HTML 26148 KB 12711 KB 6897 KB
XLS 36711 KB 10496 KB 9904 KB
PDF 24816 KB 15145 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 22627 KB 9636 KB 4385 KB
XLS 30659 KB 8696 KB 5781 KB
PDF 19821 KB 10634 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.
5 Durchführung der Evaluierung S e i t e 88
5.4. Entscheidungsmatrix
BIRT Pentaho Reporting Jasper-Reports
Designerversion 2.3.0 1.7 3.0
Engineversion 2.3.0 0.8.9.4 3.0
Paketgröße39
~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 22627 KB 9636 KB 4385 KB
XLS 30659 KB 8696 KB 5781 KB
PDF 19821 KB 10634 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.
S e i t e 89
6. 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
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.
S e i t e 91
Literaturverzeichnis
BRR (2005):
Business Readiness Rating: http://www.openbrr.org/, heruntergeladen am 17.06.2008
Chamoni (2003):
Chamoni, P.: Analytische Informationssysteme für das Controlling - Stand und
Entwicklungsperspektiven, http://www.cundus.de/downloads/ZfCM-AIS.pdf,
heruntergeladen am 19.05.2008.
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. 119-128.
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. 3-22.
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. 27-31.
Eclipse-Birt (2008)a:
Eclipse-Birt, http://www.eclipse.org/birt/phoenix/, heruntergeladen am 19.05.2008.
Eclipse-Birt (2008)b:
BIRT Project Description and Scope,
http://www.eclipse.org/birt/phoenix/project/description.php, heruntergeladen am
19.05.2008.
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. 21-25.
Gluchowski (2001):
Gluchowski, P.: Business Intelligence. Konzepte, Technologien und Einsatzbereiche, in:
HMD - Praxis der Wirtschaftsinformatik, 38. Jg. 2001, H. 222, S. 5 – 15.
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. 207-226.
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. 143-176.
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. 12-19.
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-
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. 331-369.
Held (2007):
Held,M./et al.: Business Intelligence mit Pentaho, http://www.heise.de/open/Business-
Intelligence-mit-Pentaho--/artikel/98599/, heruntergeladen am 17.06.2008.
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. 61-79.
JasperSoft (2008):
JasperReports,
http://www.jasperforge.org/jaspersoft/opensource/business_intelligence/jasperreports/,
heruntergeladen am 19.05.2008.
Kemper/Lee (2001):
Kemper, H./ Lee, P.: Business Intelligence - ein Wegweiser, in: Computerwoche, Jg.
2001, H. 44, S. 54-55.
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, http://www.heise.de/open/Business-
Intelligence-mit-Open-Source--/artikel/73725, heruntergeladen am 17.06.2008.
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, http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf,
heruntergeladen am 15.09.2008.
Mertens (2002):
Mertens, P.: Business Intelligence - Ein Überblick. In: Information Management &
Consulting, 17. Jg. 2002, Sonderausgabe, S. 65-73.
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. 129-142.
Open Source Definition (2008):
The Open Source Definition, http://www.opensource.org/docs/osd, heruntergeladen am
15.09.2008.
Peh (2006):
Peh, D./ et al.: BIRT: A Field Guide to Reporting. Amsterdam 2006, Addison-Wesley
Longman.
Pentaho (2008):
Pentaho Reporting, http://www.pentaho.com/products/reporting/, heruntergeladen am
19.05.2008.
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. 425-438.
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. 71-87.
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. 439 - 448
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. 51-70.
Verity (2005):
Verity, J.: Intelligence Gets Smarter, http://cfo.com/article.cfm/4390968/,
heruntergeladen am 17.06.2008.
Waniczek (2002)a:
Waniczek, M.: Grundlagen der Reporting-Konzeption, http://www.controlling-
portal.org/index.php?load=http://www.controlling-
portal.org/3/Einfuehrung/23/23.shtml, heruntergeladen am 17.06.2008.
Waniczek (2002)b:
Waniczek, M.: Reporting-Audit: Die Analyse des Berichtswesens,
http://www.controlling-portal.org/index.php?load=http://www.controlling-
portal.org/3/Einfuehrung/19/19.shtml, heruntergeladen am 17.06.2008.
Wayner (2008):
Wayner, P.: Product review: Open source reporting goes corporate,
http://www.infoworld.com/article/08/02/18/08TC-open-source-reporting_1.html,
heruntergeladen am 17.06.2008.
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,
http://www.sapdesignguild.org/editions/edition2/willenborg/index.html,
heruntergeladen am 19.05.2008.
S e i t e 96
Anhang
A. Abbildungen der Berichte ....................................................................................... 97
B. Benchmarkanwendung Quellcode .......................................................................... 98
C. Abbildungen der Designer-Oberflächen .............................................................. 115
S e i t e 97
A. Abbildungen der Berichte
Die Abbildungen wurden aus datenschutzrechtlichen Gründen entfernt.
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.
*
* @param 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();
}
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.
*
* @author ado
*/
public class ReportEngineFactory {
/**
* Erstellt ein neues AReportingEngine-Objekt.
*
* @param engine
* Parameter für die Engineauswahl(jasper, pentaho oder birt) als
* String.
*
* @return 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.
*
* @author 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;
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.
*
* @return die Endung.
*/
public final String getSuffix() {
return suffix;
}
/**
* Setzt die Endung der Quelldatei.
*
* @param suffix
* die Endung.
*/
public final void setSuffix(String suffix) {
this.suffix = suffix;
}
/**
* Konstruktor für AReportingEngine mit Quellverzeichnis als Parameter.
*
* @param inputFolder
* das Quellverzeichnis
*/
public AReportingEngine(String inputFolder) {
this.inputFolder = inputFolder;
}
/**
* Liefert das Ausgabeverzeichnis.
*
* @return das Ausgabeverzeichnis.
*/
public final String getOutputFolder() {
return outputFolder;
}
/**
* Liefert das Quellverzeichnis.
*
* @return das Quellverzeichnis.
*/
public final String getInputFolder() {
return inputFolder;
}
/**
* Setzt das Quellverzeichnis.
*
* @param inputFolder
* Quellverzeichnis als String
*/
public final void setInputFolder(String inputFolder) {
this.inputFolder = inputFolder;
}
/**
* Setzt das Ausgabeverzeichnis.
*
* @param outputFolder
* Ausgabeverzeichnist als String.
*/
public final void setOutputFolder(String outputFolder) {
this.outputFolder = outputFolder;
}
/**
* Berechnet die Performance und Speicherauslastung fuer den übergebenen
* Bericht und Ausgabetyp.
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
*
* @param reportType
* Reporttyp, der erzeugt werden soll(HTML, PDF, XLS oder random.
* @param inputReport
* Name der Quelldatei, aus der ein Bericht erzeugt werden soll.
*
* @return die Ergebnisse als String.
*
* @throws 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() {
@Override
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.
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.
*
* @return 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.
*
* @throws Exception
* exception
*/
public abstract void initEngine() throws Exception;
/**
* Generiert ein Bericht im HTML-Format.
*
* @param inputFile
* Bericht-Datei, aus der ein Bericht generiert werden soll.
* @param count
* count
*
* @throws Exception
* exception
*/
protected abstract void createHTMLReport(File inputFile, int count)
throws Exception;
/**
* Generiert ein Bericht im PDF-Format.
*
* @param inputFile
* Bericht-Datei, aus der ein Bericht generiert werden soll.
* @param count
* count
*
* @throws Exception
* exception
*/
protected abstract void createPDFReport(File inputFile, int count)
throws Exception;
/**
* Generiert ein Bericht im XLS-Format.
*
* @param inputFile
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.
* @param count
* count
*
* @throws Exception
* exception
*/
protected abstract void createXLSReport(File inputFile, int count)
throws Exception;
/**
* Stoppt die Reporting-Engine.
*
* @throws 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.
*
* @param inputFolder
* Quellverzeichnis, aus dem die Berichte geladen werden.
*/
public ReportingEngineBirt(String inputFolder) {
super(inputFolder);
this.setSuffix(".rptdesign");
}
/*
* (non-Javadoc)
*
* @see de.ikom.reporting.AReportingEngine#createHTMLReport(java.io.File,
* int)
*/
@Override
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.
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)
*
* @see de.ikom.reporting.AReportingEngine#createPDFReport(java.io.File,
* int)
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#createXLSReport(java.io.File,
* int)
*/
@Override
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");
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)
*
* @see de.ikom.reporting.AReportingEngine#initEngine()
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#stopEngine()
*/
@Override
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.
*
* @param 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
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
.getLogger(ReportingEngineJasperReports.class);
/** Datenbankverbindung */
private Connection con;
/*
* (non-Javadoc)
*
* @see de.ikom.reporting.AReportingEngine#createHTMLReport(java.io.File,
* int)
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#createPDFReport(java.io.File,
* int)
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#createXLSReport(java.io.File,
* int)
*/
@Override
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.
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)
*
* @see de.ikom.reporting.AReportingEngine#initEngine()
*/
@Override
public void initEngine() throws Exception {
this.con = getConnection();
}
/**
* Liefert die Datenbankverbindung
*
* @return Datenbankverbindung
*
* @throws ClassNotFoundException
* Klasse-Nicht-Gefunden-Exception
* @throws 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)
*
* @see de.ikom.reporting.AReportingEngine#stopEngine()
*/
@Override
public void stopEngine() throws Exception {
// Datenbankverbindung trennen.
if (this.con != null) {
this.con.close();
this.con = null;
}
}
}
Listing 5, Quellcode der Klasse ReportingEngineJasperReports.
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.
*
* @author ado
*/
public class ReportingEnginePentaho extends AReportingEngine {
/**
* Konstruktor.
*
* @param inputFolder
* Quellverzeichnis, aus dem die Berichte geladen werden.
*/
public ReportingEnginePentaho(String inputFolder) {
super(inputFolder);
this.setSuffix(".xml");
}
/*
* (non-Javadoc)
*
* @see de.ikom.reporting.AReportingEngine#createHTMLReport(java.io.File,
* int)
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#createPDFReport(java.io.File,
* int)
*/
@Override
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)
*
* @see de.ikom.reporting.AReportingEngine#createXLSReport(java.io.File,
* int)
*/
@Override
public void createXLSReport(File inputFile, int count)
throws Exception {
// ResourcenManager initialisieren.
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)
*
* @see de.ikom.reporting.AReportingEngine#initEngine()
*/
@Override
public void initEngine() throws Exception {
// Initialiseren von Engine
JFreeReportBoot.getInstance().start();
}
/*
* (non-Javadoc)
*
* @see de.ikom.reporting.AReportingEngine#stopEngine()
*/
@Override
public void stopEngine() throws Exception {
}
}
Listing 6, Quellcode der Klasse ReportingEnginePentaho.
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.
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.
Ich versichere, die von mir vorgelegte Arbeit selbständig verfasst zu haben. Alle
Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichten
Arbeiten anderer entnommen sind, habe ich als entnommen kenntlich gemacht.
Sämtliche Quellen und Hilfsmittel, die ich für die Arbeit benutzt habe, sind angegeben.
Die Arbeit hat mit gleichem Inhalt bzw. in wesentlichen Teilen noch keiner anderen
Prüfungsbehörde vorgelegen.
20.10.2008, Gummersbach,______________________
(Datum, Ort, Unterschrift)