?holdResultsOpenOverStatementClose=true

You want to read the english language original of this article? Click the above link!

Pentaho Data Integration (ehemals Kettle) kann für ETL-Prozesse verwendet werden, es lässt sich aber auch in EII-Szenarios (Enterprise-Information-Integration) einsetzen. Nehmen wir zum Beispiel mal an, wir haben einen Report, der aus einem CRM-System heraus aufgerufen werden kann und es dem Kundenservice-Mitarbeiter erlaubt, alle aktuell offenen Anfragen aus der CRM-Datenbank zu sehen. Gleichzeitig soll der Report aber auch eine strategische Übersicht über den jeweiligen Kunden liefern, um die Wirtschaftlichkeit beurteilen zu können. Die Daten dazu kommen aus einem Data-Warehouse. Der Report bezieht seine Daten also aus zwei verschiedenen Quellen, bei denen möglicherweise verschiedene Datenbank- und Betriebssysteme zum Einsatz kommen. Mit Kettle ist es ein Leichtes, die Daten zusammenzufassen und dank der Integration in die Pentaho-BI-Suite kann aus den Daten direkt ein Report erzeugt werden, ohne dass sie zwischendurch erst in irgendwelchen temporären Tabellen abgelegt werden müssten. Es ist leider noch NICHT möglich, die Kettle-Transformation in den Tools zur visuellen Report-Erstellung („Report Designer“ und „Report Design Wizard“) wärend der Report-Erstellung als Datenquelle zu definieren. Das ist ein wichtiger Punkt, der nicht oft genug wiederholt werden kann:

Seit Pentaho 1.6 stellt Pentaho zur Laufzeit EII-Funktionalität zur Verfügung, nicht aber während der Design-Phase.

Man kann also eine ETL-Transformation als Quelle eines Reports nutzen und man kann sich den Beweis dafür im Verzeichnis „samples/etl“ der Pentaho-BI-Suite-Demo ansehen. Was ist also der beste Weg, um Reports mit dieser Funktionalität zu erstellen? Wie viele Andere, die die Pentaho-BI-Suite nutzen, möchte ich den Report Designer nutzen, um meinen Report visuell zu gestalten, die Daten sollen aber aus einer EII-Transformation kommen. Wie das geht, erfahrt ihr hier.

Schritt 1: Erstellen des Datensatzes

Erstelle eine ETL-Transformation, bei der am Ende die gewünschten Daten stehen. Dabei können alle Möglichkeiten genutzt werden, Datenbanken, Lookups, Berechnungen, Excel-Files, was auch immer. Wenn das Ganze später auf einem Pentaho-1.6-Server laufen soll, dann sollte Kettle 2.5.x verwendet werden, denn die neueren Versionen werden nicht voll unterstützt. Als Beispiel habe ich hier mal eine ganz einfach Transformation erstellt, die Verkaufszahlen berechnet indem Anzahl und Preis multipliziert werden.

Schritt 2: Füge einen Tabellen-Output zur Transformation hinzu

Wir werden jetzt eine Tabelle erzeugen, die NUR als Dummy-Datensatz für das Report-Design dient. Dafür kann jede beliebige Datenbank zum Einsatz kommen, die einem gerade zur Verfügung steht. (Vielleicht habt ihr eine lokale MySQL-Installation? Oder ihr habt den Pentaho-Server lokal installiert? Dann kann auch dessen Hypersonic-Datenbank genutzt werden.) Um die nötige Tabelle zu erstellen fügt man der Transformation einfach einen Table-Output-Schritt hinzu und klickt in diesem auf den „SQL“-Button. Kettle spuckt daraufhin das nötige SQL-Statement aus, welches direkt von dort aus ausgeführt werden kann. Gib‘ der Tabelle irgendeinen blöden Namen, zum Beispiel „MYTEMPTABLE“.

Schritt 3: Die temporäre Tabelle mit Daten füllen

Nachdem die Tabelle angelegt ist, muss man nur noch die Transformation laufen lassen, um einen Abzug der aktuellen Daten in die Tabelle zu bekommen. Diese Tabelle kann dann dazu dienen, den Report zu gestalten.

Schritt 4: Den Report gestalten

Öffne den Report Designer. Lege die gerade erstellte temporäre Tabelle als Datenquelle an. Erstelle den Report, so, wie du es gewöhnt bist. In diesem Schritt passiert nichts besonderes, wir erstellen lediglich einen normalen Report auf Basis einer normalen Datenbank-Tabelle.

Schritt 5: Testen des Reports auf dem Pentaho-Server

Lege den Report mit Hilfe der Funktion „Publish“ (oder „Publish to Server“) auf dem Test-Server ab, so dass man ihn dann über das Pentaho-Web-Interface erreichen kann. Ich habe den Report zum Beispiel in samples/etl abgelegt, so dass er dort Seite an Seite mit den ETL-Beispielen steht, die bei der Standard-Installation des Demo-Servers dabei sind.

Überprüfe, dass der Report im Web-Interface erscheint und teste seine Funktion. Ok, unser Report (etlexample.xaction) läuft wie geschmiert. Auch in diesem Schritt haben wir nichts außergewöhnliches getan, das ist ja immer noch der langweilige Report, der seine Daten ganz normal aus der temporären Tabelle „MYTEMPTABLE“ ausliest.

Schritt 6: Die PDI-Transformation auf dem Server ablegen

Es ist zwar nicht zwingend erforderlich aber doch eine sehr gute Idee, in der Transformation den letzten Hop (von „for_pentaho“ zum Table Output) zu deaktivieren. Wenn der Report ausgeführt wird, wollen wir ja schließlich keine INSERT-Statements erzeugen. Wir speichern die Transformation unter dem Namen kettleexample.ktr im Verzeichnis samples/etl, wo auch schon die Datei etlexample.xaction liegt. Man kann die Datei auch an beliebigen anderen Orten ablegen, es macht aber Sinn, alles beisammen zu haben.

Schritt 7: DB durch PDI ersetzen

Um hinterher beide Versionen vergleichen zu können, mache ich erst mal eine Kopie von meiner etlexample.xaction-Datei, die ich etlexample2.xaction nenne. Diese rufe ich im Design Studio auf, um folgende Änderungen durchzuführen:

Als erstes ändere ich den Namen der Action-Sequenz von „ETL Transformation“ nach „ETL Transformation – NO TABLES“.

Als nächstes muss die Datenquelle gelöscht werden. Dafür markiere ich das „rule“-Element und klicke auf das rote X.

Als Drittes füge ich ein „Get Data From Pentaho Data Integration“-Element VOR dem „report“-Element ein.

Viertens: Konfiguriere das PDI-Element wie im Screenshot:

Das haben wir hier getan: Wir haben angegeben, dass unsere Daten aus der PDI-Transformation „kettleexample.ktr“ kommen sollen. Außerdem haben wir noch zwei andere wichtige Informationen eingetragen: Wir haben der Komponente gesagt, dass die Daten aus dem ETL-Schritt „for_pentaho“ kommen sollen. Dort werden die Daten also abgesaugt und stehen dann als Ergebnis zur Verfügung. Deshalb haben wir als zweiten Punkt auch den Namen für das Ergebnis angegeben, unter dem dann der Report auf die Daten zugreifen kann. Wir nennen das Ergebnis hier „final_result“.

Zu guter Letzt markieren wir noch das Report-Element und legen fest, dass die Report-Daten aus diesem „final_result“ kommen sollen. Sonst muss am Report nichts mehr gemacht werden.

Schritt 8: Teste deinen neuen Report

Rufe den neuen Report „ETL Example – NO TABLE“ über das Pentaho-Web-Interface auf. Es sollte jetzt das gleiche Ergebnis zu sehen sein, wie beim vorherigen Report. Der einzige Unterschied ist, dass dieser Report nicht mehr die Datenbanktabelle „MYTEMPTABLE“ benutzt sondern seine Daten direkt aus der PDI-Transformation bezieht.

Gratulation! Du hast dir damit das Handwerkszeug erarbeitet, mit dem du EII-Reports mit dem gleichen Tool visuell gestalten kannst, wie normale Reports. Alle Möglichkeiten von PDI stehen dir damit für deine Reports offen.

Das Beispiel findest kannst du hier als ZIP-Datei (eiiexample.zip) herunter laden. Der Autor des englischen Original-Textes hatte das Ganze mit Version 1.2 des Pentaho-Servers getestet, ich habe 1.6 und auch schon die noch nicht veröffentlichte Version 1.7 ausprobiert, da geht es auch. Feedback, sowohl hier als auch natürlich auf der Website des Original-Artikels, ist sehr willkommen!

Die produktiven Daten eines Unternehmens eignen sich in der Regel nicht direkt zur Erstellung von Reports. Zum einen müssen sie oft aus verschiedensten Quellen zusammengetragen werden (XLS, CSV, TXT, XML, …), zum anderen ist die Struktur von Produktiv-Datenbanken auf andere Belange hin optimiert und bietet beim Reporting daher keine gute Performance. Deshalb erstellt man vor dem eigentlichen Report erst mal ein Datawarehouse. Das ist ein Datentopf, in dem Daten in einer Struktur abgelegt werden, die die einfache und schnelle Report-Erstellung erlaubt. Um diese Aufgabe zu bewältigen benötigt man ein ETL-Werkzeug (Extrahieren, Transformieren, Laden). Die Pentaho-Werkzeugkiste enthält dafür das Programm „Pentaho Data Integration“ (PDI), früher bekannt unter dem Namen „Kettle“. Mit PDI kann man grafisch definieren, welche Daten von wo gelesen werden sollen, wie sie aufbereitet und wohin sie dann geschrieben werden. Man tut dies, indem man diverse Komponenten auf die Arbeitsfläche zieht und diese dann miteinander verbindet. Das Ergebnis nennt sich „Transformation“. In der Regel beginnt eine Transformation mit einem oder mehreren Eingabe-Komponenten (z. B. Lesen von Daten aus Datenbanken, Dateien und Online-Quellen) und endet mit einer Ausgabe-Komponente (z. B. Schreiben von Daten in eine Datenbank). Dazwischen können noch beliebige Schritte zur Aufbereitung der Daten stehen (z. B. Berechnungen, Filter, Nachschlagen weiterer Details).

Das Report-Design 

Wenn das Datawarehouse steht, kann man den Pentaho Report Designer anwerfen. Hier erstellt man den Report, entweder zu Fuß oder mit Hilfe des Report-Design-Wizards. Aus dem Report Designer heraus kann man sich die Reports für den Eigenbedarf direkt erzeugen, man kann den Report aber auch von dort aus auf den BI-Server publizieren.

Die Arbeit im Report-Designer beginnt mit dem Konfigurieren der Datenquelle. Das kann zum Beispiel ein SQL-Statement sein, die daraus resultierenden Daten stehen dann für den Report zur Verfügung. Pro Report kann nur eine Datenquelle (also zum Beispiel nur ein SQL-Statement) genutzt werden. Es ist allerdings möglich, Unterreports mit anderen Datenquellen einzubinden.

Ist die Datenquelle definiert, geht es an das Layout.

Die Login-Seite

Dies ist der erste Kontakt des Users mit unserem Server. Oben ist ein grüner Balken, oben rechts ein Pentaho-Logo, links gibt es aktuelle Pentaho-News, die von einem externen Server gezogen werden (sie erscheinen also auch nur, wenn mein Test-Rechner eine Internet-Verbindung hat) und rechts ist die Login-Maske, bei der oben über ein Dropdown-Feld gültige Logins inklusive Passwort gewählt werden können.

Welche Dateien definieren diese Seite? 

Die HTML-Bestandteile und ein Bisschen Logik kommen aus der Datei C:\pentaho\pentaho-demo\jboss\server\default\deploy\pentaho.war\jsp\Login.jsp. In der Datei kann man das Layout der Login-Seite völlig auf den Kopf stellen, einfache HTML-Kenntnisse reichen dafür aus. Ein paar Hinweise zum Inhalt:

• Äußerer Rahmen
  Noch bevor die ersten HTML-Tags in der JSP-Datei auftauchen, wird in den Zeilen 79 bis 94 auf ein HTML-Template verwiesen. Dieses Template definiert den äußeren Rahmen um den eigentlichen Inhalt und findet sich unter C:\pentaho\pentaho-demo\pentaho-solutions\system\custom\template-login.html.
• Login-Fehler
  Die Zeilen 107 bis 154 definieren eine Nachrichten-Box für den Fall eines Anmeldefehlers. Der Nachrichten-Text wird durch die Funktion in den Zeilen 246 bis 263 aufbereitet.
• Pentaho-News
  In den Zeilen 158 bis 165 werden die Pentaho-News aus dem Internet geladen. Diesen Bereich sollte man im Life-Betrieb unbedingt entfernen, da sich der Seitenaufbau verzögert, wenn der Webserver, der die News liefert, nicht antwortet.
• Veraltetes Tabellen-Layout
  In den Zeilen 174 bis 180 ist ein abschreckendes Beispiel für Seitenlayout mit Hilfe von Tabellen zu sehen. Der Login-Kasten mit seinen gerundeten Ecken wird also über eine Tabelle definiert. Web-Designer wissen, was zu tun ist.
• Messages.getString()
  An einien Stellen des JSP-Files wird Text ausgegeben, der vorher mit der Methode getString() aus dem Messages-Objekt ausgelesen wird. Dabei handelt es sich im internationalisierte Texte. Die Texte, die dabei ausgegeben werden, finden sich im Ordner C:\pentaho\pentaho-demo\jboss\server\default\deploy\pentaho.war\WEB-INF\classes\org\pentaho\locale in den Dateien messages.properties (für die englischen Texte) und messages_*.properties (für Texte für andere Sprachen).
• User-Dropdown
  Die Zeilen 204 bis 210 definieren das Dropdown-Feld zur Selektion eines gültigen Benutzers. Das macht nur für den reinen, lokalen Demo-Betrieb Sinn. Diese Zeilen sollten in allen anderen Fällen ersatzlos gestrichen werden.

Zur erwähnten Template-Datei für den äußeren Rahmen gibt es auch ein paar Hinweise:

• XHTML
  Zu Beginn der Datei wird definiert, dass XHTML verwendet wird.
• CSS-Stylesheet
  Es wird ein Stylesheet eingebunden, welches sich im Dateisystem unter C:\pentaho\pentaho-demo\jboss\server\default\deploy\pentaho-style.war\styles-new.css findet.
• Favicon
  Das kleine Icon, welches vom Browser meist oben links neben dem Seitentitel angezeigt wird, findet sich unter C:\pentaho\pentaho-demo\jboss\server\default\deploy\pentaho-style.war\favicon.ico.
• Java-Script
  Zu guter Letzt wird noch ein Standard-JavaScript eingebunden. Es findet sich unter C:\pentaho\pentaho-demo\jboss\server\default\deploy\pentaho-style.war\pentaho.js.

Jetzt fehlt nur noch der Footer. Dieser findet sich in der Datei C:\pentaho\pentaho-demo\pentaho-solutions\system\custom\template-footer.html.

SUN baut mit dem Zukauf einer Datenbank-Firma außerdem das eigene Software-Portfolio sinnvoll aus. Mit eigenem Betriebssystem (Solaris), eigener Programmiersprache (Java) und nun einer eigenen Datenbank (MySQL) kann man eine komplette Umgebung für Web-Anwendungen aus einer Hand anbieten.

Mehr Infos (auf Englisch) gibt es hier: Jonathan’s Blog

Auf dem frisch installierten Demo-Server sind vier Benutzer mit allseits bekannten Passwörtern angelegt. Das muss natürlich geändert werden, bevor der Server von außen erreichbar ist. Die Login-Informationen kommen aus der Datei C:/pentaho/pentaho-demo/jboss/server/default/deploy/pentaho.war/WEB-INF/applicationContext-acegi-security-memory.xml. Dort findet sich folgender Abschnitt:

<bean id=“userMap“ class=“java.lang.String“></bean>
<constructor-arg type=“java.lang.String“></constructor-arg>
<!– case matters –>
<value></value>
<!–DATA[<–>
joe=password,ceo,Admin,User,Authenticated
suzy=password,cto,is,User,Authenticated
pat=password,dev,User,Authenticated
tiffany=password,dev,devmgr,User,Authenticated
]]>

Hier werden also sowohl die Passwörter als auch die Gruppenzugehörigkeiten zugewiesen. Alle Passwörter lauten im Urzustand „password“. Ich nenne den ersten User „admin“ anstatt „Joe“ und gebe ihm ein Passwort meiner Wahl. Bei den anderen Benutzern setze ich kryptische Passwörter. Natürlich kann man die anderen Accounts auch einfach löschen, ich behalte sie aber noch bei, um später benutzerabhängige Berechtigungen testen zu können.

Zweitens: JBOSS-JMX-Konsole sperren

In einer Standard-Installation des JBOSS-Servers ist die sogenannte JMX-Konsole frei zugänglich. Dies ist auch in der mit dem Pentaho-Demo-Server ausgelieferten Version der Fall. Da es über diese Konsole für einen Angreifer möglich ist, Systembefehle mit den Berechtigungen des JBOSS-Servers auszuführen, muss dieses Sicherheitsloch gestopft werden.

In der Datei C:\pentaho\pentaho-demo\jboss\server\default\deploy\jmx-console.war\WEB-INF\web.xml muss der folgende Abschnitt gefunden und die hier rot markierten Zeilen gelöscht werden:

<!– A security constraint that restricts access to the HTML JMX console
to users with the role JBossAdmin. Edit the roles to what you want and
uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
secured access to the HTML JMX console.
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>
–>

Im gleichen Verzeichnis muss in der Datei jboss-web.xml ebenfalls ein Kommentar entfernt werden:

<!– Uncomment the security-domain to enable security. You will
need to edit the htmladaptor login configuration to setup the
login modules used to authentication users.
<security-domain>java:/jaas/jmx-console</security-domain>
–>

Damit ist dann schon mal ein Passwort-Schutz aktiviert, jetzt muss nur noch das Standard-Login (User: admin, Passwort: admin) abgeändert werden. Das passiert in der Datei C:\pentaho\pentaho-demo\jboss\server\default\conf\props\jmx-console-users.properties. Hier kann man zum Beispiel die Zeile admin=admin durch keinerechte=haha ersetzen. Nun kann sich ein User „keinerechte“ mit dem Passwort „haha“ anmelden, er bekommt aber danach nur die Meldung zu sehen, dass er nicht über die nötigen Rechte verfügt, die Konsole zu sehen. Das liegt daran, dass der User „keinerechte“ nicht der Rolle „JBossAdmin“ zugeordnet ist. Sicher ist sicher.

Drittens: Auf externer Adresse erreichbar machen

Bisher reagiert das Ganze nur auf Anfragen an localhost. Angenommen, man hat die Installation auf einem Server ohne grafischen Desktop durchgeführt, dann möchte man sicherlich von einem anderen Rechner aus auf das Webinterface zugreifen. Dazu muss mindestens das Folgende passieren:

JBOSS dazu bringen, auf die externe IP-Adresse zu hören

Wenn es auf einem Server läuft und extern erreichbar sein soll, gehe ich mal von einem Linux-Server aus. Dort findet sich in der Datei /pentaho/pentaho-demo/start-pentaho.sh diese Zeile:

sh run.sh

An diese Zeile wird die IP angehängt:

sh run.sh -b 192.168.100.100

Damit JBOSS auch wieder beendet werden kann, muss auch in der Datei /pentaho/pentaho-demo/stop-pentaho.sh diese Zeile geändert werden:

./shutdown.sh -S

Daraus würde dann in unserem Beispiel:

./shutdown.sh -s 192.168.100.100 -S

Ändern der Pentaho-Basis-URL

Damit in den generierten HTML-Dateien die Verknüpfungen zu CSS-Dateien und sonstigen Inhalten stimmen, muss der BI-Server die Basis-URL kennen. Diese wird in der Datei /pentaho/pentaho-demo/jboss/server/default/deploy/pentaho.war/WEB-INF/web.xml definiert. Der betreffende Abschnitt sieht so aus:

<context-param>
<param-name>base-url</param-name>
<param-value>http://localhost:8080/pentaho/</param-value>
</context-param>

Das Wörtchen localhost muss hier also durch die externe IP-Adresse oder den Domain-Namen ersetzt werden.

Viertens: Das Ganze per SSL erreichbar machen

Die SSL-Konfiguration hat mit dem JBOSS-Server nicht viel zu tun, denn in der Praxis übernimmt diesen Part normalerweise ein vorgeschalteter Webserver, der als Proxy fungiert. Ich beschreibe den Aufbau anhand eines Apache2-Servers.

Für den ersten schnellen Blick auf die Metadaten des Beispiels gehe ich auf „File => Import from XMI File“ und wähle dort die eben erwähnte Datei aus. Ich werde nach einem Namen gefragt. „Samples“ scheint mir passend. Ich empfehle, einfach mal 15 Minuten lang wild rum zu klicken (dabei auch die rechte Maustaste benutzen) und alles auf sich wirken zu lassen. Danach ist sicher Vieles schon klar.

Tabellen einlesen

Ich versuche es jetzt mal von Grund auf nach zu vollziehen. Dazu gehe ich auf „File => New… => Domain File…“ Jetzt ist alles wieder leer. Als erstes benötigt man eine Datenbank-Verbindung. Dazu macht man einen Rechts-Klick auf „Connections“ und wählt „New Connection…“ Hier kann ich mich jetzt mit beliebigen Datenbanken verbinden. Ich verbinde mich einfach mal mit den mitgelieferten Beispiel-Daten. Ich gebe also als „Connection Name“ „SampleData“ ein, wähle als „Connection Type“ „Hypersonic“ aus, wähle als „Method of Access“ „JNDI“ und schreibe „SampleData“ in das Feld „Database Name“. Ein Klick auf „Test“ sagt mir, dass alles ok ist. Warum ist alles ok? Das sind doch kaum genug Informationen, um sich mit einer Datenbank zu verbinden? Richtig. Wenn man „JNDI“ wählt erwartet die Software die eigentliche Spezifikation der Verbindungsdaten in der Konfigurationsdatei C:\pentaho\pentaho-metadata-*\simple-jndi\jdbc.properties. Ich habe also eigentlich eine JDBC-Verbindung aufgebaut, die in den Metadaten aber über einen Namen referenziert wird. Das hat Vorteile, wenn man die Metadaten später mal auf mehrere Rechner verteilen will, zum Beispiel auf ein Produktiv- und ein Test-System.

Wenn man dann auf „Ok“ klickt öffnet sich ein Popup-Fenster, welches die vorhandenen Datenbank-Tabellen anzeigt. Hier kann man alle Tabellen auswählen, die man in das Business-Modell integrieren möchte. Wenn man seine Auswahl getroffen hat, liest der Metadata-Editor die dazugehörigen Spaltennamen ein.

Internationalisierung

Die Metadaten können mehrsprachig angelegt werden. Ich als Deutscher möchte die Endnutzer meist in Deutsch und Englisch auf ihre Daten zugreifen lassen. Standardmäßig ist nur die Lokale für Englisch (US) angelegt. Um Deutsch hinzu zu fügen, klicke ich oben auf das Icon mit der kleinen Weltkugel. Als neue Lokale lege ich „de_DE“ mit dem Namen „Deutsch“ an.

Spaltennamen und Beschreibungen

Zu jeder Spalte kann ein Name und eine Beschreibung in allen angelegten Lokalen hinterlegt werden. Dazu klicke ich mit der rechten Maustaste auf die Tabelle und wähle „Edit…“ aus dem Kontextmenü. Im folgenden Popup-Fenster kann ich auf die Spaltenbezeichner links klicken und dann rechts die gewünschten Werte eingeben.

• Eclipse BIRT
  Reporting-Komponente
• JasperSoft Business Intelligence Suite
  Vollständiges BI-Paket
• JBOSS
  Java Enterprise Middleware (Web-Server)
• OpenOffice
  Office-Paket
• Palo-Server
  OLAP-Server plus Excel-Komponenten
• Pentaho BI Suite
  Vollständiges BI-Paket
• RapidMiner
  Data-Mining-Tool, welches bis Mitte 2007 unter dem Namen YALE bekannt war.
• Talend
  ETL-Komponente