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.

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.

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

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`

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.

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.

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.

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

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.