Mit V14.5 wurde die Synchronisation zwischen Komponenten eines Dashboards deutlich vereinfacht. Im Prinzip konnte man ja auch bisher schon dieses Synchronisierung durchführen, allerdings musste man bereits im Designer bei der Komponente (Library Component) festlegen, welche Events gesendet oder empfangen werden sollen. Nun geht es viel einfacher, weil man direkt im JDashboard per Mausklick die Synchronisation aktivieren kann: Mit Send Sync aus dem Kontextmenu kann man einen Filter setzen, den dann automatisch alle anderen Komponenten in diesem Dashboard erhalten. Sobald man jetzt in dieser (führenden) Komponente eine Kategorie klickt (z. B. USA für Country) wird dieser Filter an alle anderen Komponenten gesendet und führt dort zur Filterung (COUNTRY = ‘USA’). Will man das bei einer bestimmten Komponente nicht haben, klickt man auf der Komponente auf Receive (Kontextmenu) und wählt diesen Filter (COUNTRY) einfach ab.

Siehe Online-Doku:

http://www.jinfonet.com/kbase/server14.5/userguide/index.htm#t=HTML%2Fdashboard%2Fdshbrd_sync.htm

Über die Jahre haben wir immer wieder daraufhin gearbeitet, dass die Online-Dokumentation von JReport verbessert wurde und tatsächlich wurde sie wirklich besser. Inzwischen lassen sich die meisten Fragen anhand der Doku klären. Manche, etwas speziellere Themen, wurden nun in der JReport Knowledge Base durch technische Artikel (in Englisch) beschrieben:

Dort lassen sich Detailinformationen über das Customizing finden, z. B. wie man das Produktlogo gegen sein eigenes austauschen kann. Letztlich lässt sich die gesamte Oberfläche an das eigene Look&Feel anpassen. Der Wehmutstropfen ist allerdings, dass man das für jede Version wieder neu vornehmen muss.

Für Entwickler und PowerUser, die sich intensiv mit JReport beschäftigen, kann die Knowledge Base hilfreich sein. Im Zweifel stehen wir von Objective Software GmbH gerne mit Beratung und Schulungen zur Verfügung.

In der letzten Telco mit Jinfonet haben wir über die Marketing-Botschaften gesprochen, die in der obigen Überschrift zusammengefasst sind.

Embed – Einbetten von JReport in Applikationen, da hat sich nicht viel geändert

Customize – V14.5 bietet mehr Möglichkeiten zum Customizing über CSS. Leider ist die Doku hier noch etwas dünn, aber ich habe bereits nachgefordert. Gerade hier bekommen wir immer wieder Kundenanfragen. Ich werde berichten, wenn es Neues gibt.

Scale – Wir haben ja bereits Kunden, welche JReport in Clusterumgebungen einsetzen, über den Einsatz der Standardlösung JReport Cluster (SPOF Dispatcher) kann man diskutieren. Nichtsdestotrotz laufen gerade in den USA sehr große Installationen wie VISA mit JReport Cluster produktiv.

JReport Mobile war bisher die mobile App zur Darstellung von Dashboards auf iOS-Geräten (iPhone, iPad). Eine Android-Version gab es leider nie. Der Hersteller hat sich inzwischen aber dafür entschieden die App einzustellen und stattdessen durchgängig auf CSS und Responsive Design zu setzen. Damit haben Benutzer überall die gleiche Benutzererfahrung (UX).

Die Entscheidung ist nachvollziehbar, hätte man sicher auch von Anfang an so machen können, aber hinterher ist man ja immer klüger.

JReport V14.5 liegt in den letzten Zügen, das Beta-Programm wird gerade abgeschlossen. Die Verbesserungen betreffen ehere kleinere Details, im Vergleich zu V14 ändert sich rein äußerlich nicht viel.

Ein hübsches und nützliches Feature sind Compound Crosstabs, eine Art geschachtelter Crosstabs. Damit lassen sich auch komplexere Daten sehr effizient darstellen, hier ein Beispiel:

Compound Crosstab

Auch ganz nett ist das Quick Search Feature in der Console, mit dem man nach Ressourcen (Reports, Dashboards) suchen kann, z. B. wenn man nicht mehr weis, wo man einen Report abgespeichert hat:

Quick Search

Neu ist das Partial Data Loading, d.h. bei großen Datenmengen wird der Report bereits mit Teildaten angezeigt. Falls Summen angezeigt werden, wird signalisiert, dass diese noch vorläufig sind.

Die Einstellungen im Server Profile wurde nochmals deutlich feiner einstellbar, so kann der Administrator sehr genau einstellen, welche Funktionen in der User Console, dem Page Report Studio, dem Web Report Studio oder JDashboard zur Verfügung stehen. Somit kann er z. B. festlegen dass (alle oder bestimmte) Benutzer Reports nur ansehen, aber nicht verändern können.

Im Report Wizard (Anlegen neuer Report) kann man jetzt die Datenfelder auch per Drag&Drop ziehen (statt mit den Pfeilen hinzuzufügen oder zu entfernen).

Das Online-Hilfesystem wurde optisch etwas aufgefrischt, ansonsten bleibt es unverändert.

Leider ist die Android-Version von JReport Mobile noch immer nicht in Sicht, schade eigentlich.

Und mehr als 70 Verbesserungen finden sich in den Resolved Issues. Alles in allem geht die Entwicklung also stetig auf dem bisherigen Pfad weiter. Ich persönlich erwarte die Verfügbarkeit von V14.5 bis circa September 2017.

Dass amerikanische Firmen immer wieder Probleme mit anderen Sprachen und Ländern haben, dürfte bekannt sein. Auch JReport zickt gerne mal in dieser Beziehung. Seit V13.5 wurde das Verhalten mal wieder geändert, sehr zum Leidtragen deutscher Benutzer. Daher hier ein kurzer Exkurs und ein Tipp, wie man es korrekt einstellt.

In Java ist Internationalisierung tief verankert über sog. ResourceBundles. Das Laden erfolgt über ResourceBundle.getBundle(). Dabei kann das Application Locale angegeben werden, welches ja nicht zwingend das Default Locale der Java VM sein muss (französicher Benutzer auf deutschem Rechner). Nun sucht Java nach Ressourcen in bestimmter Reihenfolge, z.B.:

1. fr_CH
2. fr
3. en_US
4. en
5. ohne Angabe

Dies für den Fall, Anwender hat in Applikation fr_CH gesetzt und Java VM läuft mit en_US. Im einfachsten Fall muss man die Resource-Dateien (meist .properties) nur ohne Angabe locale ausliefern, dann fallen einfach alle darauf zurück, im Zweifelsfalle also Englisch.

Bei Oracle ist das gut erklärt: https://docs.oracle.com/javase/tutorial/i18n/resbundle/concept.html

In JReport kann man das Application Locale in bin/config.xml setzen (vorher Designer beenden):

<Language name=”de_DE”></Language>

Aber man muss dann gleichzeitig die Datei lib/resource_en_US.jar nach lib/resource_de_DE.jar kopieren. Jetzt wird beim Starten diese neue JAR eingelesen und JReport nutzt jetzt de_DE. Damit ist auch die Sprachwahl für die Ausführung genauso wie die Formattierung der Zahlen korrekt:

Voreinstellung für Deutsch

Diese Implementierung ist leider nicht ganz Java-Standard, aber so kann man JReport dazu bringen das Locale de_DE zu nutzen.

Leider sind damit noch nicht alle Texte umd Meldungen übersetzt. Das wäre eine echte Fleißaufgabe.

Jeder kennt den farbigen Schritzug von Google, klar. Kann man solche farbigen Texte auch in JReport erzeugen? Ja, kann man:

JDashboard unterstützt mehrere Themes un man kann mit dem Einstellungssymbol (Zahnrad) in der Sidebar das Theme ändern:

Themes Menu in einstellungen

Es existieren die Themes Default, Blue, Green, Module und Steel.

Technisch liegen diese im Serververzeichnis unter

.\public_html\webos\style\

Hier mal der Inhalt des Themes “Steel” (naja, Themes liegen im Unterverzeichnis style):

Dateien des Theme Steel

Für uns wichtig ist dashboard.css und die könnten wir spaßhalber (nicht in Produktion) mal pimpen, also rote Hintergrundfarbe für das Dashboard eintragen:

.dashboard, .dashboard_0,
.dashboard_8, .dashboard_16 {
 background-color:#FF0000;
 overflow: auto;
}

Wenn wir jetzt dieses Theme in JDashboard auswählen – passiert erst mal nix, weil der Browser-Cache noch reinspielt. Cache löschen oder Crtl-F5 und die Änderung sollte sichtbar werden.

Ich habe mal ein style-Verzeichnis (wieder steel) kopiert (nach bongo) und darin gespielt. Prompt habe ich jetzt ein neues Theme bongo zur Verfügung.

Ist jetzt nicht der Pfad zur Erleuchtung, aber evtl. mal ganz hilfreich.

Mit Einführung von JDashboard kamen die Library Components (LC) hinzu. Dies sind die Kacheln, aus denen man sein Dashboard baut. Üblicherweise nutzt man pro Kachel immer ein Report-Objekt, also eine Tabelle oder ein Chart. Ähnlich wie in den herkömmlichen Reports (Page Reports und Web Reports), kann man auch in LC’s per Hyperlink auf andere Reports oder Dashboards verlinken. Jetzt wird es aber etwas kniffelig, weil hier die Implementierung im Vergleich zu Reports geändert wurde. Wir müssen zwei Fälle unterscheiden:

• Aufruf eines anderen Dashboards oder Reports
• Filterung des Zielreports per Parameter oder Condition

Zum einen hat die Hyperlink Property in LC-Objekten eine andere Syntax als die vergleichbare Link-Property in Reports. Zum anderen ist der Aufruf eines Dashboards etwas anders als bei Reports (wo es über runReport.jsp funktioniert). Mehr Info findet sich hier:

http://www.jinfonet.com/kbase/server13.1/userguide/HTML/dashboard/dshbrd_url.htm

Mir geht es hier aber um den Fall aus einer LC mit Chart-Objekt heraus einen Detail-Report aufzurufen. Dazu kann man sich “Sales Bar.lc” in den Beispielreports ansehen. Dort ist ein Chart-Object (Bar) enthalten und das hat die folgende Hyperlink-Property (am Chart Object, Kommentare sind von mir nur zur Beschreibung hier):

{"target":0, // öffnen in neuem Fenster/Tab
 "field":"ChartObject", // Name des Objektes im aktuellen LC
 "srcComp":"ChartObject", // Name des Report-Objekts im aktuellen LC
 "type":0, // keine Ahnung
 "desCatalog":"\/SampleReports.cat", // Zielkatalog
 "desRptset":"\/Pie_Link.wls", // Zielreport
 "desRptsheet":"Report", // Zielreporttab (Tab unten in Design View)
 "condDefs":[], // Conditions, falls keine Parameter
 "paramExp":["AND", // Parameterübergabe
 ["EQUALS", // == für die folgenden Operanden
 {"scope":2,"type":"parameter","iname":"p_Country","dname":"p_Country","mname":"p_Country","sql":-1},
 {"scope":2,"type":"group","iname":"WorldWideSalesBV.Customers","dname":"Country","mname":"Country"}
 ]
 ],
"prefix":".\/..\/jinfonet\/runReport.jsp", // Aufruf über runReport.jsp
"axis":0 // keine Ahnung
}

Leider gibt die aktelle Doku dazu wenig her, ich musste das also forschen. Wirklich spannend sind eigentlich nur folgende beiden Einträge:

• “mname”:”p_Country”
• “mname”:”Country”

Die Mapping Names des Parameters p_Country und Country in der WorldWideSalesBV. Der Pfad “WorldWideSalesBV.Customers” hat scheinbar keine Auswirkung, da MApping Names ja eindeutig sein müssen. dname steht wohl für Display Name und ist eher nicht relevant. das sql:-1 heißt wohl, dass es nicht in die SQL-Query eingeht, da die Filterung ja über den Parameter erfolgt (der aber sicher in die Query eingeht).

Sehr häufig hat man Messdaten, Aktienkurse oder andere Daten, die als Zeitreihe in der Datenbank abgelegt werden sollen. Natürlich möchte man solche Daten dann auch mit JReport auswerten und darstellen. Wenn man die einschlägigen Dokus von MongoDB liest, wird häufig folgendes Pattern empfohlen:

{ name: 'Blabla', timestamp: new Date('2014-01-14T16:14:03Z),

  data : {0 : 1.05, 1 : 1.07, 2 : 1.09, ...}
}

Das funktioniert allerdings so nicht mit JReport, da JReport die collection in eine “Table” umdeuted und die Attribute des Sub-Dokumentes “data” als innere Tabelle (ähnlich JOIN in SQL) und dann hätte man Spalte wie data.0, data.1, … . Das passende Pattern sieht so aus:

{ name: "Blabla, timestamp: new Date('2014-01-14T16:14:03Z),
  data : [{time:0, val:1.05}, {time:1, val:1.07}, {time:2, val:1.09}, ...}]
}

D.h. data ist ein Array von Dokumenten, alle mit time und val. Das kann JReport gut in eine relationale Form transformieren. Sieht man sich die Query an, dann stellt man fest, dass JReport künstliche Foreign Keys und Primary Keys einführt, um eine Art JOIN zu ermöglichen:

Query

Noch ein Hinweis: in V13.1 macht JReport immer die $unwind-Operation, um die data-Felder zu “joinen”. Bei gr0ßen Datenmengen ist das Gift, weil der Server erst alles auspackt, bevor $match angewendet wird. Ich habe bereits angeregt, das $unwind nach dem $match zu machen, wenn kein Filter auf eines der inneren Felder (data) erfolgt.