Berichte im Web-Portal, als PDF und per E-Mail (BIRT)

2009/04/14

Nachdem wir lokal Berichte mit BIRT erzeugen können, sollten sie auch über ein Webportal abrufbar sein und wir wollen sie automatisch erzeugen und verschicken.

Zu BIRT gehört eine Web-Applikation, die die Report-Dateien aus dem Designer im Webbrowser darstellen und als PDF, Excel und so weiter exportieren kann. Diese Engine läuft in einem Applikationsserver wie Apache Tomcat oder JBoss. Im BIRT-Projekt wird dies beschrieben unter [1]

Um diese Applikation zu nutzen sind folgende Schritte erforderlich:

  1. Tomcat installieren
  2. BIRT Engine in Tomcat installieren und testen
  3. BIRT Engine mit einem Report aus einer Webseite aufrufen
  4. Reports als aus einem Skript heraus erzeugen
  5. PDF-Dateien per Mail verschicken

Tomcat installieren

Die aktuelle Version BIRT 2.3.2 läuft mit Tomcat 5.5, obwohl es schon die Tomcat 6 gibt. Meine Versuche mit Tomcat 6 waren nicht sehr erfolgreich, also bleibe ich erst mal bei 5.5.

Tomcat wiederum läuft auf JRE 6. Zuerst stellen wir also sicher, dass JRE6 SE betriebsbereit ist. Falls nicht vorhanden, kann man JRE 6 SE von [2] laden.

Das Windows Binary von Tomcat 5.5 liegt auf [3] Am einfachsten ist das Binary mit Installer. Nach der Installation muss der Tomcat manuell gestartet werden; entweder mit der Frage am Ende der Installation oder über das Startmenü.

Tomcat nistet sich im Tray mit einem Symbol ein. Das Systemmenü von Tomcat kann man dort mit der rechten Maustaste erreichen.

tomcat_05

Achtung: Tomcat läuft, einmal gestartet, als Dienst, das heisst auch ohne das Tray-Symbol.

Mit dem Webbrowser kann man unter http://127.0.0.1:8080 nachsehen, ob alles funktioniert.

tomcat_01

BIRT-Viewer in Tomcat installieren

Viele Details dazu stehen auf [4] Hier kommt die Kurzfassung.

Zuerst brauchen wir das BIRT-Binary. Das steht auf [5] Wir brauchen die Datei „Runtime“ unter Deployment. Das Zip-File packen wir erst mal in ein temporäres Verzeichnis aus.

Als nächstes suchen wir das Tomcat-Installationsverzeichnis. Unter Windows dürfte das „c:\Programme\Apache Software Foundation\Tomcat 5.5“ sein. Darin findet sich das Verzeichnis webapps, in dem alle Tomcat-Applikationen installiert werden, jede Applikation in einem eigenen Unterverzeichnis. In dieses Unterverzeichnis webapps kopieren wir aus dem temporären Auspackverzeichnis der BIRT-Runtime das Unterverzeichnis WebViewerExample. Schliesslich benennen wir das kopierte Verzeichnis um in birt-viewer.

Um die Applikation zu aktivieren müssen wir den Tomcat einmal stoppen und wieder starten; am einfachsten mit der rechten Maustaste auf das Tomcat-Tray-Icon. Im Browser rufen wir wieder die Startseite von Tomcat auf – http://127.0.0.1:8080/ – und klicken auf „Tomcat Manager“. In der Liste der Anwendungen muss birt-viewer auftauchen.

tomcat_02

Für einen ersten Funktionstest der Web-Applikation klicken wir auf „birt-viewer“ in der Tomcat-Liste. Das Eclipse-Symbol und die Bemerkung „BIRT viewer has been installed“ sollte angezeigt werden.

tomcat_03

Mit einem Klick auf „View Example“ sollte der Report Viewer angezeigt werden und uns zur korrekten Installation beglückwünschen.

tomcat_04

MySQL-Treiber installieren und eigenen Report testen

Auch in der Web-Applikation muss der MySQL-Treiber installiert werden, bevor wir den Test-Report abrufen können. Der Treiber ist wieder die Jar-Datei aus dem vorherigen Beitrag. Diesmal muss sie in das Verzeichnis „WEB-INF\platform\plugins\org.eclipse.birt.report.data.oda.jdbc_2.3.2.r232_v20090212\drivers\“ im birt-viewer-Verzeichnis kopiert werden.

Dann muss der Test-Report in Reichweite der Engine gebracht werden. Es ist die Datei kpi-report1.rptdesign aus dem Workspace des Report-Designer, die nach birt-viewer\Report kopieren.

Im Browser können wir jetzt den Report im BIRT-Viewer direkt aufrufen: http://localhost:8080/birt-viewer/frameset?__report=Report\kpi-report1.rptdesign. Gezeigt wird der komfortable Webviewer mit Frames und Export-Möglichkeiten. Die Engine bietet auch eine web-only, report-only Ansicht, wenn man sie mit run statt frameset aufruft: http://localhost:8080/birt-viewer/run?__report=Report\kpi-report1.rptdesign

Insgesamt kennt die Engine folgende Parameter:

  • __format: Output format. „html“ oder „pdf“.
  • __isnull: Definiert einen reportParameter als Null
  • __locale: Setzt die Java Sprachvorwahl (locale), wie en, de, en-us oder ch-zh. Default: Java-Default
  • __report: Pfad zur Report-Datei
  • __document: Pfad zum erzeugten Dokument, wenn run und frameset getrennt benutzt werden.
  • reportParameter: Ein Parameter, wie im Report design definiert.

Zulässig sind…

  • … in frameset: __locale, __report, __document, reportParam
  • … in run: __format, __isnull, __locale, __report, reportParam

Beispiel: http://localhost:8080/birt-viewer/run?__format=pdf&__report=Report\kpi-report1.rptdesign&mypara=17

Wichtig bei Parametern und Pfaden: Alles muss URL-kompatibel sein. Bei Leerzeichen oder Umlauten muss gegebenenfalls urlencode() verwendet werden.

Eine vollständige Beschreibung aller Argumente für die Engine steht unter [6].

Der Pfad zur Report-Datei kann absolut oder relativ angegeben werden. Für relative Pfade sucht die Engine mit Hilfe der beiden Settings BIRT_VIEWER_DOCUMENT_FOLDER und BIRT_VIEWER_WORKING_FOLDER in der Datei web.xml im birt-viewer. Wenn die Datei darüber nicht gefunden werden kann, wird das Verzeichnis birt-viewer als Basis genommen.

In der web.xml können auch verschiedene andere Einstellungen gesetzt werden.

Reports aus PHP heraus erzeugen und an den Browser ausliefern

Natürlich können wir die Reports einfach als Link auf die Engine anbieten. Damit liefern wir den Anwendern aber zum einen viele Informationen über unsere Installation und die Reports. Zum anderen ist offen, ob er überhaupt auf den Report-Server und die Portnummer des Tomcat zugreifen kann.

Wir können aber den Aufruf der BIRT-Engine in einem PHP-Skript verbergen und so tun, als ob dieses Skript den Report ausliefert:

<?php
$r = fopen('http://127.0.0.1:8080/birt-viewer/run?__report=Report\kpi-report1.rptdesign&__format=pdf', 'r');
if(!$r) { print "Kann Report nicht öffnen!"; exit; }
header('Content-Type: application/pdf');
fpassthru($r); // gesamte Datei an den Browser liefern
?>

Dieses Skript benutzt die Wrapper-Funktionen, durch man eine URL wie eine Datei öffnen kann. Hier geht natürlich nur die run-Methode der Engine und sämtliche Parameter für den Report müssen bereits beim Aufruf in der URL übergeben werden.

Je nach Laufzeit muss hier unter Umständen ein set_time_limit() eingefügt werden, wenn die Engine länger braucht.

Etwas ähnliches steht unter [7] beschrieben, aber die dortige bewirkt eine Umleitung des Browsers, womit die Original-URL der Engine wieder dem Empfänger bekannt gegeben würde; siehe oben.

Report als PDF erzeugen und abspeichern

Zum Schluss sollen Reports automatisch erzeugt und per Mail verschickt werden. Mit PHP sieht das so aus:

<?php
$rname = 'kpi-report1';
$wname = $rname . '_' . date('Ymd_Hi') . '.pdf';
$pdf = file_get_contents("http://127.0.0.1:8080/birt-viewer/run?__report=Report\\" . $rname . ".rptdesign&__format=pdf");
file_put_contents($wname, $pdf);
?>

Wieder wird der Wrapper benutzt. Der Report wird als PDF komplett geladen und dann in die Zieldatei gespeichert. Als Komfort-Add-on hängen wir einen Zeitstempel und die Dateiendung an den Namen an.

Dieses Skript kann aus einem Batchfile heraus aufgerufen werden, das wiederum zyklisch durch den Windows Scheduler („Geplante Tasks…“) oder unter Linux per cron gestartet werden kann.

Die andere Methode für den Aufruf der Engine führt über Java. Das ist beschrieben in [8] und [9]. Da dies aber für unsere bisherigen Zwecke keine Vorteile bietet, belasse ich es bei den Links.

Oh, Mailversand! PDFs sollten wir als ordentlichen Anhang verschicken. Das geht mit mail() in PHP nicht so einfach. Ich habe gute Erfahrungen mit der SMTP-Klasse von [10] gemacht, aber auf phpclasses.org finden sich verschiedene andere Lösungen, zum Beispiel [11]. Damit sieht der Versand der PDF-Datei oben so aus:

<?php
$mail = new attach_mailer
( $name = "Mein Name",
$from = "me@mymail.com",
$to = "you@gmail.com",
$cc = "kopie@provider.org",
$bcc = "blind@copy.org",
$subject = "Report", $body = "Was zum Report zu sagen ist"
);
$mail->create_attachment_part($wname);
$mail->process_mail();
?>

Links

[1] http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php
[2] http://java.sun.com/javase/downloads/
[3] http://tomcat.apache.org/
[4] http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php
[5] http://download.eclipse.org/birt/downloads/
[6] http://www.eclipse.org/birt/phoenix/deploy/viewerUsage.php
[7] http://www.eclipse.org/birt/phoenix/deploy/usingPHP.php
[8] http://www.theserverside.com/tt/articles/article.tss?l=IntegratingBIRTwithPHP
[9] http://www.birt-exchange.com/devshare/deploying-birt-reports/743-calling-birt-from-php/
[10] http://www.phpclasses.org/browse/package/1044.html
[11] http://www.phpclasses.org/browse/package/2822.html


Neues Spielzeug (XAMPP installieren)

2009/01/26

In diesem Teil werden die Werkzeuge installiert, die unsere Ubuntu-VM zur Web-Applikations-Spielwiese machen:

Teil 3: XAMPP installieren

Profis würden jetzt die Pakete einzeln installieren; Apache, MySQL, PHP, Perl. Kann man auch, aber es dauert eine Weile und man muss an vielen Stellen Einstellungen ändern, Dateien verschieben und so weiter.

Deshalb holen wir uns das Komplettpaket XAMPP von Apachefriends.org. Das gibt es für Linux, Windows und Mac, und es ist gerade auf Linux sehr einfach zu installieren.

Download und Installation

  • In der VM den Firefox-Browser öffnen, entweder oben in der Mitte des Bildschirms oder über Anwendungen / Internet.
  • apachefriends.org im Browser aufrufen und XAMPP für Linux anwählen. Die Seite am besten mal kurz durchlesen.
  • XAMPP Linux runterladen. Normalerweise speichert Firefox ins Desktop-Verzeichnis, in unserem Fall /home/mes/Desktop.
  • Terminal-Fenster (Shell) öffnen (Anwendungen / Zubehör / Terminal) und ins Download-Verzeichnis wechseln: „cd Desktop“
  • Prüfen, dass das XAMPP-Paket hier liegt: „ls -l“
    Es sollte xampp-linux-1.7.tar.gz oder ähnlich heissen
  • Jetzt folgt der Zauberspruch für die Installation: „sudo tar xvfz xampp-linux-1.7.tar.gz -C /opt“
    Dabei wird das User-Passwort abgefragt; siehe Teil 2.

Das war’s schon. Was ist passiert? Der Inhalt des Pakets wurde in das System-Verzeichnis opt entpackt. Mehr muss man nicht tun, um XAMPP lauffähig zu installieren.

Im einzelnen:
„sudo“ – den folgenden Befehl im „super user“-Modus ausführen, deshalb die Passwortabfrage.
„tar“ – ist ein Standard-Unix Pack/Entpackprogramm. Dateien mit der Endung tar sind seine.
„xvfz“ – sind die Parameter für tar: x = entpacken; v = verbose, viel Ausgabe; f = es folgt ein tar-Dateiname; z = es ist ein komprimiertes tar (.gz).
„xampp-linux-1.7.tar.gz“ – der Paketname
„-C /opt“ – eine Option von tar, bedeutet Auspacken in das folgende Verzeichnis (/opt).

Warum „/opt“? Das ist Konvention. Technisch könnten wir XAMPP und jedes andere Programm in jedem Verzeichnis abspeichern und starten. Aber opt ist das traditionelle Systemverzeichnis für optionale Pakete.

Erststart

Im schon geöffneten Terminal tippen wir: „sudo /opt/lampp/lampp start“

„sudo“ kennen wir schon. „/opt/lampp/lampp“ ist das Startprogramm für XAMPP im Verzeichnis /opt/lampp und „start“ heisst genau das: XAMPP starten. Die anderen Optionen für das Startprogramm sind „stop“ und „restart“.

Es sollte „XAMPP fuer Linux gestartet“ ausgegeben werden. Wenn ja, dann laufen jetzt Apache (Webserver), MySQL (Datenbank) und PHP sollte auch verfügbar sein. Das testen wir im Firefox, indem wir localhost oder 127.0.0.1 aufrufen. Der Splash-Screen von XAMPP sollte erscheinen. Wir klicken auf „Deutsch“ – die Hauptseite von XAMPP erscheint – und danach links auf „Status“.

So sollte es dann auf dem Bildschirm aussehen:
xampp_install_01

Wo ist was?

Das wichtigste Verzeichnis auf unserer VM ist jetzt /opt/lampp/htdocs. Das ist das Web-Hauptverzeichnis. Zum Test erstellen wir eine erste PHP-Seite.

  • Im Terminalfenster ins Web-Verzeichnis wechseln: „cd /opt/lampp/htdocs“
  • Mit einem Editor eine neue Datei anlegen: „sudo gedit info.php“
  • In diese Datei die Zeile „<?php phpinfo(); ?>“ eintippen
  • Abspeichern, und
  • im Firefox „localhost/info.php“ aufrufen.

Wenn alles geklappt hat, sollte folgendes zu sehen sein:

xampp_install_02

Gruppenarbeit (Berechtigungen)

Warum schon wieder sudo bei einem simplen Editor? Weil /opt ein Systemverzeichnis ist, in dem wir als Benutzer mes eigentlich nicht schreiben dürfen. Andererseits muss der Webserver die Dateien auch lesen dürfen. Das heisst: Bei allen Dateien, die wir über den Webserver verarbeiten wollen, müssen wir darauf achten, dass die Leserechte ausreichen.

Der Webserver läuft unter dem User nobody. Wir sind normalerweise als mes angemeldet und mit sudo sind wir plötzlich root, also Systemadministrator.

Welche Berechtigungen bei einer Datei gesetzt sind, sieht man mit „ls -l“.

xampp_install_032

Wichtig für uns: Vor jeder Datei, die der Webserver verarbeiten soll, müssen links in der ls-Liste drei „r“ stehen. Drei, weil es die Lese-Berechtigungen („read“) für den Besitzer, die Gruppe des Besitzers und „other“ sind. Sollten keine drei „r“ dort stehen, kann man sie mit „sudo chmod ugo+r dateiname“ setzen. Alles weitere erklärt die man page für chmod, die man im Terminalfenster mit „man chmod“ ansehen kann. Die Kurzfassung gibt es mit „chmod –help“.

Automatischer Start

Leider müssen wir XAMPP bei jedem Start der VM neu starten („sudo /opt/lampp/lampp start“). Das ist hinderlich, deshalb benutzen wir die immer noch geöffnete Shell (das Terminalfenster), um XAMPP automatisch mit Ubuntu zu starten:

  • Wechseln ins Verzeichnis /etc: „cd /etc“
  • Die Datei rc.local in einen Editor laden: „sudo nano rc.local“
  • vor „exit 0“ die Zeile „sudo /opt/lampp/lampp start“ einfügen
  • Beenden mit Strg-X, speichern bestätigen mit J

Jetzt die VM neu starten, um den Autostart zu testen.

Was haben wir getan? Die Datei „/etc/rc.local“ enthält Befehle, die beim Start von Ubuntu ausgeführt werden. Normalerweise ist sie leer, aber aufgerufen wird sie trotzdem. Wir haben einfach die Zeile eingefügt, die wir sonst per Hand eintippen müssten.

Linux-Profis werden hier möglicherweise die Nase rümpfen; wenn sie diese Anleitung überhaupt lesen. Ja, es gibt andere Wege, Programme beziehungsweise „Dienste“ beim Systemstart zu starten. Aber wir bauen eine Spielwiese und beschränken uns auf die einfachste Methode.

Und nu?

Well, die Spielwiese läuft. Am besten jetzt eine Kopie der VM erstellen, denn so rein und frisch kriegen wir sie nie wieder zusammen. Der nächste Teil, Installation von Drupal in der VM, erscheint nicht hier, sondern im Blog Doku-Hotline meiner Frau, für die ich diese kleine Anleitung eigentlich geschrieben habe.


Wir brauchen mal schnell nen Web-Portal…

2008/12/22

In einem früheren Beitrag war die kurz die Rede von einer Konfigurations-Webseite für die Datenverdichtung.
Aber wo installiert man die auf einem proprietären Windows-System, ohne sich tagelang in die Tiefen des IIS und ASP.NET zu verbasteln? Und woher bekommt man ein anständiges Design, Benutzer-Verwaltung, Zugangsrechte, etc.pp.?

IIS war Pflicht, weil schon das Portal des Reporting-Tools drauf lief. Port 80 also belegt, anderer Port für Anwender entweder zu kompliziert oder nicht benutzbar (interne Firmenrouter lassen nicht alle Ports durch).

Meine Lösung als bekennender PHP-Liebhaber: PHP drauf, mit IIS verbinden, MySQL und Drupal. Drupal ist ein freies CMS und bietet aus dem Stand das ganze Drumherum für ein Web-Portal: Benutzerverwaltung, berechtigungsspezifische Menüs, Gestaltung per Themes, usw.

Das eigentlich interessante an Drupal ist aber: Jede erstellte Seite kann per Knopfdruck auf PHP umgeschaltet werden. Als Entwickler kann man sich also ganz auf die Inhalte konzentrieren.

drupal_php_inhalt

PHP installieren und mit IIS zum rennen bringen: 3 Stunden. MySQL: Vernachlässigbar. Drupal mit Auswahl des Themes, Icons anpassen, Basismenüs und erste Benutzer einrichten; also bis die erster Inhaltsseite erstellt werden konnte: noch mal 3 Stunden. Es war schliesslich meine erste produktive Drupal-Installation 🙂

Jedenfalls waren die Eingabe-Forms dann sehr schnell realisiert.

Tipps für PHP-Seiten in Drupal

  • In neueren Drupal-Versionen muss das Eingabeformat PHP erst freigeschaltet werden.
    In der deutschen Version:
  1. Anmelden als Administrator
  2. Unter Verwalten / Einstellungen / Eingabeformate den Eintrag „PHP Code“ konfigurieren, so dass mindestens der Administrator dieses Format nutzen darf.
  • Die PHP-Seiten werden von Drupal per eval() verarbeitet. Deshalb müssen alle Variablen ausserhalb von Funktionen als global gekennzeichnet werden. Am besten wie eine traditionelle Deklaration in C.
    Das betrifft auch Variablen in den eigenen include() und require(), nicht jedoch mit define() erzeugte Konstanten.
  • Die Skripte verschwinden in der Datenbank von Drupal und sind damit schlecht in einer IDE zu bearbeiten. Wenn man gleich zu Beginn ein include() mit passenden Pfaden benutzt, kann man sehr bequem auf die eigentlichen Skripte in einem extra Verzeichnis verlinken.

In Drupal:

<?php
include('meine_include_pfade.php'); // setzt u.a. APPL_DIR
include(APPL_DIR . 'das_eigentliche_skript.php');
?>