Pentaho, BO und der Unterschied

Als ich vor ein paar Monaten meine erzwungene Projektpause von meinem langjährigen Kundenprojekt antrat, erhielt ich die Gelegenheit, mich in einem internen Projekt für die Collogia mit bisher für mich unbekannten BI-Tools zu beschäftigen. Eine spannende Herausforderung auch für einen alten Hasen …

Es galt, eine vergleichsweise einfache Anforderung mit wenigen Reports, wenigen Tabellen und wenigen Daten umzusetzen. Meine Wahl fiel auf die Community Edition von Pentaho – aus mehreren Gründen: Die Software ist kostenlos, hat eine gewisse Verbreitung am Markt und ich bekam die Gelegenheit, mich in ein neues Tool einzuarbeiten. Aus meiner Projektarbeit kenne ich Business Objects – einen der Platzhirsche im Markt der BI-Suiten – sehr gut, aber hier sollte es etwas Neues sein. Außerdem hätte man mit dem mächtigen BO in diesem Fall bezüglich der Anforderungen doch ein wenig auf Spatzen geschossen. 

Nun denn – gesagt, getan – installiert und losgelegt! Doch halt – so schnell ging es doch nicht. Ich bewege mich im täglichen Projektleben und auch bei privaten Computerarbeiten hauptsächlich in der Windows-Welt und bin es daher gewohnt, mit einem Klick auf die Installationsdatei schon so gut wie alles getan zu haben („Weiter, weiter, fertig“ – habe ich doch irgendwo schon mal gelesen …). Die richtigen Dateien für die Pentaho-Installation zu finden, war noch vergleichsweise einfach; und den Client für die Report-Erstellung hat man auch schnell einsatzbereit. Aber dann ging der ganze Spaß erst los …

Plattform für die Installation des Pentaho-Servers sollte ein Linux-System sein – ok, damit hatte ich schon mal zu tun. Für das Repository – die Datenbank, in der Pentaho seine Report-Definitionen und Metadaten speichert – wurde Oracle gewählt. Einerseits gut, denn auch die Nutzdaten liegen in einer Oracle-Datenbank und wir haben zu diesem Produkt sehr viel Sachverstand im Haus. Leider gilt das nicht für mich, da ich bisher nur mit den Produkten der Konkurrenz zu tun hatte. Zum Glück gibt es hilfreiche Kollegen, die wissen, wie man Datenbanken aufsetzt, konfiguriert und einbindet – danke dafür! 

Nun aber zum Kern der Herausforderung: der Konfiguration der Server-Komponente von Pentaho! Hätte ich noch Haare, wären sie darüber wohl grau geworden. Der BA (Business Analytics) Server von Pentaho kommt vorkonfiguriert für MySQL – für Oracle müssen daher einige Änderungen in den Konfigurationsdateien vorgenommen werden. Einen Waschzettel dafür gibt es auf den Hilfe-Seiten im Internet, aber natürlich klappt so etwas nicht auf Anhieb einwandfrei. Bis ich die für die weiteren Schritte notwendigen Log-Dateien und Fehlermeldungen gefunden hatte, vergingen Stunden – fast  Tage. Dass meine Kenntnisse in den Bereichen Oracle, Java und Linux bislang eher nicht so umfangreich waren, hat die Einrichtungszeit nicht unbedingt verkürzt ... 

Um es kurz zu machen: Mit beherzter Unterstützung der Oracle Spezialisten lief am Ende alles wie gewünscht und die eigentliche Arbeit – das Erstellen von Reports zur Auswertung von Kundendaten – konnte endlich beginnen. Wirklich? Eine Kleinigkeit fehlt noch: um die Reports leicht zugänglich zu machen, sollte die Nutzerverwaltung von Pentaho über LDAP an die Collogia-Domäne eingebunden werden – und, ja, richtig: bisher hatte ich ziemlich wenig damit zu tun. Aber auch das war irgendwann geschafft und die Anmeldemaske nimmt meine LDAP Kennung.

Stand in der Überschrift nicht irgendwo BO? Richtig, ich wollte noch ein paar Worte zur Report-Erstellung in den beiden Tools verlieren. Mit einem Wort: ein Unterschied wie Tag und Nacht. Hier merkt man eben doch, dass in die Entwicklung von Business Objects mittlerweile ein paar Mannjahrzehnte mehr geflossen sind als in das vergleichsweise junge und mit weniger Manpower produzierte Pentaho. Ich habe selten eine so holprige Software bedient wie den Pentaho Report Designer! Vielleicht habe ich den vollen Funktionsumfang und typische Workflows noch nicht vollständig erfasst, aber das Tool macht es einem auch nicht einfach - intuitiv geht meiner Meinung nach anders.  Spontan auftretende nichtssagende Fehlermeldungen und Komponenten, die man zwar in den Bericht einbauen, nicht aber wieder entfernen kann, machen einem das Leben schwer. Bestimmte Funktionen, die in BO selbstverständlich sind, sucht man in Pentaho vergeblich. Wann man Objekte im Berichtslayout frei positionieren kann und wann sie zwangsweise automatisch angeordnet werden, habe ich bis heute nicht vollständig durchdrungen. Die Liste der ärgerlichen Kleinigkeiten könnte noch um einiges verlängert werden … aber auch wenn Papier geduldig ist, wollen wir hier keinen Roman schreiben.

Kommen wir zum Fazit meiner kleinen (noch andauernden) Reise in die Pentaho-Welt: Zumindest für mich waren bei der Installation und Konfiguration des Systems größere Aufwände zu treiben als ich es von anderen Umgebungen gewohnt bin. Der Report Designer, mit dem ich die Berichte definiert habe, ist vom Funktionsumfang her ok, könnte aber noch einiges an Feinschliff vertragen. Das Wichtigste aber: das System funktioniert, die Anforderungen können im Wesentlichen abgedeckt werden (was teilweise noch zu beweisen ist) und die Anwender können recht komfortabel mit den Berichten arbeiten. Holpriger Weg, Ziel erreicht.

Jetzt muss ich nur noch schaffen, den Nutzern der Reports zu erklären, was sie ausgewertet haben wollen – aber das ist eine andere Geschichte …

Autor: Stefan ErnstWebsite: /index.php/prof/profile-se