Immer wieder kommt die Problematik mit UTF-8 auf, gerade mit osteuropäischen Zeichensätzen. Darum möchte ich das hier mal kurz klar stellen. Java verwendet intern den UCS-2 Zeichensatz und der ist 16 Bit breit, kann also alle Zeichen halten. Wenn JReport die Daten aus der Datenbank liest, wandelt der JDBC-Treiber alle String-Datenfelder (VARCHAR) in UCS-2 um. Also bestehen innerhalb von Java keine Probleme. Erst bei der Ausgabe in eine Datei muss sich Java entscheiden, wie die Zeichen in Bytefolgen umgewandelt werden sollen. Auf unterster Ebene gäbe es dafür die System Property file.encoding. Aber die wird eigentlich nicht benötigt, da die meisten Ausgabeformate Meta-Information zum Encoding haben, z. B. PDF, HTML, etc.Nur bei Ausgabe nach TXT oder CSV wird das Thema file.encoding relevant.

Nun aber zum Format UTF-8 für String-Felder: dieses Format ermöglicht es Strings als Bytefolgen eines UTF-8 Strings zu interpretieren. Das wäre nur dann der Fall, wenn die Daten z. B. aus einer Datei (per UDS) gelesen würden und zwar im file.encoding=ASCII und dann falsch in Strings gewandelt worde wären. Dann kann man durch Angabe des Formates UTF-8 (statt XXXXXXX) JReport anweisen, den String in Bytes zu konvertieren und diese mit new String (byteArray, new Encoding(“UTF-8″)) wieder als String zusammen zu bauen. Aber eigentlich wäre das Sache der UDS gewesen.

Meiner Meinung nach macht das Format UTF-8 wenig Sinn und sollte nicht genutzt werden.

Nach langem Warten ist nun JReport 10.1 verfügbar. Leider kam zu einem Missverständnis mit den Versionsnummer, so dass wir die Version 10.0U1 als V10.1 benannten. Wir überarbeiten derzeit die Download-Seite und in Kürze wird dann V10.1 zum Download bereit stehen.

Herausstehende Neuerung in V10.1 ist JDashboard mit dem man sehr einfach und schnell Dashboards erstellen kann. Natürlich müssen die KPIs erst einmal in der Datenbank zur Verfügung stellen. Dann darauf Dashboards zu erstellen ist dann sehr einfach. Programmierer können einzelne Komponenten (Library Component) basieren, die Endbenutzer dann beliebig kombinieren können. Dabei können diese Komponenten in Flash oder mit Javascript umgesetzt werden.

Dashboard

Für Kunden, die noch in 2011 JDashboard nutzen möchten bestehen besonders vorteilhafte Konditionen.

Ein Feature, das in V9 dazu kam, sind die Data Mapping Files (DMF). Diese sollen es ermöglichen, Dateninhalte sprachabhängig darzustellen, also z. B. Länderbezeichnungen aus der Datenbank in der gewählten Sprache darzustellen. Das seit langem existierende NLS-Feature bezieht sich ja nur auf die statischen Inhalte (Labels, Formate). Auf den ersten Blick klingt DMF vernünftig, aber bei näherem Hinsehen wird klar, warum man das mit Vorsicht genießen sollte: Man kann eine oder mehrere DMF erzeugen und darin für ein oder mehrere Mapping-Names (also z. B. Tabellenspalten) ein Datenmapping für die jeweilige Sprache vornehmen. Allerdings immer nur für die gerade vorhandenen Daten. Käme z. B. ein neues Land hinzu würde das erst mal in den DMF-Dateien (je Sprache) fehlen.

Generell muss man sagen, dass sprachabhängige Attribute von Entitäten nun mal in die Datenbank selbst gehören. Eine zweite Art Datenbank in Form von externen Dateien zu pflegen ist nicht hilfreich. Schon aus diesem Grund ist das DMF nicht zielführend*. Dazu kommt, dass das Feature auch etwas unglücklich umgesetzt ist, da die Einträge dort im Endeffekt eine wortweise Übersetzung darstellen – und wie sich in der Praxis zeigt, reicht das halt nicht in einer Welt von Synonymen (frei = “free” oder “available”).

Daher sollten sprachabhängige Bezeichnungen und Dateninhalten IMMER in der Datenbank selbst hinterlegt sein. Ggfs. zugemischt in der VIEW, welche für das Reporting gentuzt wird, falls man auf Legacy-Daten zugreifen muss.

Ein bisschen kniffelig wird es bei Parametern. Oftmals werden die ausgewählten Werte in SQL-Abfragen verwendet, müssen aslo stabil bleiben. Will man aber dennoch sprachabhängige Auswahl ermöglichen, so muss sollte man eine Parametertabelle in der Datenbank anlegen und die Parameterdefinition darauf aufbauen (NAME, LANG, VALUE, DISPLAY_VALUE). Leider muss man die Anzeige des DISPLAY_VALUE im Header des Report dann aber wieder per Subreport oder Join realisieren.

Fazit: man muss schon sehr viel Vorarbeit leisten, um wirklich mehrsprachige Reports hinzubekommen, aber wer hat behauptet, Reporting wäre einfach? Noch ein Tipp aus der Praxis: nicht immer leitet sich die Sprache des Reports aus dem Kunden ab. In mehrsprachigen Ländern wie der Schweiz und in internationalen Konzernen tut man gut daran, die gewünschte Sprache frei konfigurierbar zu halten.

* Nachtrag: das gleiche gilt eigentlich für die NLS-Dateien selbst. Kluge Köpfe generieren diese aus der zentralne Datenbank

Eine sehr häufig gestellte Anforderung an das Reporting mit JReport ist die Verarbeitung von Excel-Dateien, sei es als Ausgabe oder als Input. Gerade die Verarbeitung als Input kann mit ODBC sehr einfach umgesetzt werden: man legt eine Benutzer-DSN für die Excel- oder CSV-Datei an und legt im Catalog Browser eine neue Datasource dafür an. Pro DSN legt man eine Datasource im Catalog an, dann geht die Verarbeitung am einfachsten.

Das Konfigurieren der DSN unter Systemsteuerung -> Verwaltung -> ODBC ist etwas tricky, da CSV-Dateien meist per ‘;’ getrennt sind. Man kann im Konfigurationsdialog der DSN pro Datei das Forma festlegen (hier benutzerdefiniert, Codierung ANSI). Wenn die erste Zeile die Spaltennamen enthält muss die entsprechende Checkbox aktiviert werden. Man kann nun die Spalten vorschlagen lassen und die Typdefinitionen entpsrechend ändern. Nach Drücken von OK wird im Verzeichnis der CSV-dAteien eine scham.ini mit diesen Einstellungen hinterlegt.

Sollte es beim Auslesen der Daten Probleme geben, könnte es daran liegen, wie JReport das SQL erstellt. Eigentlich korrekt, gemäß Spezifikation, aber der MS-Treiber sieht das anders. Abhilfe: Imported SQL verwenden und das SQL selbst schreiben:

SELECT * FROM `meinedatei.csv`

Mit JReport V10 wurde die HSQL-Datenbank durch Derby abgelöst, die bisher als Demodatenbank und beim JReport Server auch als Systemdatenbank genutzt wurde. Derby ist um vieles moderner und leistungsfähiger als HSQL-DB, die gerade im JReport Server als Systemdatenbank schnell an ihre Grenzen stieß. Derby ist wie HSQL eine In-Memory-Datenbank, die auch ins Dateisystem persistieren kann. Die Java-Unterstützung für Derby ist bereits in Java6 integriert, daher lag dieser Schritt nahe. Für den Einsatz in Unternehmensumgebungen stellt sich allerdings nach wie vor die Frage, ob man nicht besser die Systemdatenban auf ein etabliertes RDMS wie Oracle oder DB2 umstellt, was ja durchaus möglich ist – man muss es nur ganz zu Anfang machen.

Man kann mit Tools wie DbVisualizer leicht auf die DB zugreifen:
jdbc:derby://localhost:1527/realmtable.defaultRealm;create=false;create=false
User sa und Passwort sa und schon ist man drin! Sicherheit ist etwas anderes, insbesondere, da der Port 1527 auch gelich nach außen aufgemacht wird. Hier muss ein Systemadministrator gleich nacharbeiten und in derby/server.properties den Eintrag ändern:

derby.drda.host=0.0.0.0

auf

derby.drda.host=127.0.0.1

anderfalls reisst man ein Sicherheitsloch auf.

Mit JReport V10.0 wurde ein neues Feature eingeführt, welches von Kunden oft nachgefragt wurde: Cached Report Data (CRD). Es handelt sich dabei um ein Verfahren, bei dem Reports nicht direkt auf die Datenbank zu greifen, sondern auf zuvor extrahierte Daten. Man kann es als Snapshot verstehen. Wie funktioniert es nun also? Legt man im JReport Server für eine Query ein CRD an, so greifen alle Reports auf den aktuellste CRD (den Snapshot) zu, anstatt auf die Datenbank direkt. Ganz hübsch, aber man muss aufpassen, dass man damit keine unbeabsichtigten Unsinn anstellt. Denn ist ein CRD einaml angelegt, greifen die Reports stur darauf zu. Neue Daten in der Datenbank kommen dann einfach nicht im Report heraus (weil der Snapshot ja noch die alten Daten enthält). Auszug aus dem User Guide: “After a scheduled CRD is created, all reports based on the same query as the CRD will automatically use the CRD for retrieving data.”

Anwendungsfälle gibt es immer dann, wenn man auf einen Snapshot zugreifen will (z. B. bei Bankanwendungen Stand nach der TEV) oder wenn viele Benutzer immer die selben, stabilen Daten auswerten wollen. Wie bei jedem Snapshot muss man sich Gedanken machen, wann dieser erneuert werden sollen (Refresh). Dies passiert in JReport Server mit ähnlichen Mitteln wie beim Scheduling von Reports. Allerdings kann das Anlegen und Verwalten der CRDs nur in der Admin-Konsole (8889) erfolgen.

Der Hype um SOA ist mittlerweilen abgeklungen, aber WebServices sind Standard in vielen Unternehmensumgebungen. Daher wird es zunehmend wichtiger, dass man Reports auch direkt auf Basis von WebServices erstellen kann. Mit der neuen Version 10.0 bietet JReport hierzu ein neues Feature: http://www.jinfonet.com/kbase/designer10/userguide/HTML/connection/cnctn_wbsvc.htm

Natürlich konnte man das zuvor via UDS auch bereits, jetzt soll der Zugriff auf WebServices jetzt allerdings deutlich vereinfacht werden. In der Praxis zeigte sich allerdings schnell, dass die Umsetzung noch hinkt: der Woden-Parser stolpert darüber, dass die wenigsten WSDL-Files schon WSDL 2.0 (vormals 1.2) entsprechen. Mit WSDL 1.1 kann das Woden nicht umgehen (siehe http://old.nabble.com/Getting-INVALID_WSDL-with-WSDL-generated-from-.NET-web-service-td15170380.html). Wer mag, kann es ja mal selber ausprobieren. Hier ein nette Seite mit nützlichen WebServices: http://www.service-repository.com/

Also muss man schon einen WSDL 2.0 WebService haben. In der Praxis sind die meisten WebServices aber noch dem Standard WSDL 1.1 entsprechend. Schade. Man könnte einen Backport auf WSDL4J wagen oder den WebService auf 2.0 migrieren. Schöne neue Zeit.

Bei Reporting und BI denkt man zuerst immer an eine SQL-Datenbank. Aber oft ist es so, dass die Daten bereits wunderbar in Java-Objekt-Strukturen vorliegen und das Lesen dieser Daten aus der Datenbank oft recht komplex ist. Außerdem ist gar nicht gesagt, das die Daten des Reports so auch in der Datenbank stehen (z. B. Report soll noch vor Commit erfolgen, weil Probeausdruck).

Für einen großen Schweizer Konzern habe ich vor Jahren schon man ein sehr tragfähiges Konzept entwickelt, da wurden die Beans als Base64-String serialisiert und so an den entfernen JReport Server übertragen. Das hat sich absolut bewährt. Man kann das aber noch ein wenig einfacher haben mit einem mitgelieferten Sample von Jinfonet. Mit JReport wird in help/Designer/samples ein UDSForJavaBean.zip ausgeliefert. Packt man das aus, hat man eine UDS (User Defined Datasource), die JavaBeans in ein ResultSet umwandeln kann. Das kann eine gute Vorlage sein, um ein Reporting auf Basis interner Java-Beans zu realisieren. In derDoku ist das ganze auch recht gut beschrieben:

http://www.jinfonet.com/kbase/designer9.1/userguide/HTML/connection/cnctn_uds_rpt_exmpl3_dm1.htm

Ein Beispiel gibt es auch:

http://www.jinfonet.com/kbase/designer9.1/userguide/HTML/connection/cnctn_uds_rpt_exmpl3.htm

Bei dieser Gelegenheit: einfach öfter mal die Suchfunktion der JReport Online-Hilfe nutzen. Deshalb auch dieser Link hier nochmal:

http://www.jinfonet.com/kbase.htm

Jinfonet Software, a leader in Java reporting , announced reporting solutions for Salesforce.com’s cloud database, Database.com. This new development provides the ability to create reports and dashboards to directly access Database.com, the first enterprise database built for the cloud.

As a result of this support, JReport can now access Database.com using SQL, just like accessing any other data source. Providing business intelligence solutions for Database.com greatly simplifies the development of cloud-based enterprise applications.

“Salesforce.com designed Database.com to address the growing need to support mobile, social and cloud-based applications in the enterprise,” said George Hu, Executive Vice President of Platform and Marketing, Salesforce.com.

“JReport’s enabling cloud data reporting through Database.com will drastically improve the functionality of actionable information for Database.com’s customers,” said Greg Harris, Senior Product Manager at Jinfonet Software. “This allows users to run reports and create new reports from cloud data in exactly the same way as if the data is in a locally managed DBMS.”

JReport’s access to Database.com employs the DataDirect JDBC driver. “Only 100% Java based tools such as JReport can effectively utilize these Java-based drivers. Providing access to cloud data using JReport will speed the proliferation of cloud-based applications across the enterprise,” Harris explained.

With JReport’s enablement for cloud data reporting, customers can now instantly add high performance reporting, data visualization, dashboards and ad hoc analysis to their Database.com applications, including Salesforce.com’s Force.com and other applications.

Hier nochmal ein Tipp zu den Mapping Names: beim ersten Import von Tables und Views in den Catalog werden die Mapping-Names etwas “komisch” ertsellt, nämlich ohne Prfix, wenn unique, ansonsten mit Prefix. Das ist natürlich nicht stabil, weil sich das im Laufe der Zeit ändern kann. Der Tipp, alle Tables und Views zweimal zu importieren und die zuerst importierten zuvor mit “_Dummy” zu kennzeichnen kann hier Abhilfe schaffen, aber Achtung: bei den als Zweites importierten Tabellen und Views ist der Table-Type im Catalog Browser unbedingt zu setzen (ist nämlich leer)! Andernfalls besteht das Problem, dass man Formulas, die auf Basis dieser (zweitimportierten) Tabellen und Views basieren nicht in Reports hinzugefügt werden können. Fiel gerade mal wieder in einem Seminar auf.