Mächtigeres ARIS-Reporting dank externer Java-Bibliotheken

23.04.2013 |  | Allgemein | Kommentare geschlossen

Mein Kollege Philipp Thiemann hat sich in seinen Blogbeiträgen (Link1 und Link2) damit beschäftigt, wie man im ARIS-Skript beliebige Java-Objekte verwendet, auch dann, wenn ihre Verwendung in der Scripting-Engine nicht vorgesehen ist. Meinen Einstieg in die Reporting-Serie unserer Blogs möchte ich damit bestreiten, die Einbindung von externen Java-Bibliotheken zu diskutieren.

Ich möchte gerne vier beispielhafte Anwendungsfälle aus der Praxis vorstellen, um die Motivation für die Einbindung externer Bibliotheken in ARIS-Skripten zu erklären:

1. Der Kunde möchte Informationen aus einem Corporate Directory zu Prozessverantwortlichen ermitteln
2. Der Kunde möchte Reportergebnisse automatisch auf einen Server übertragen
3. Der Kunde möchte im Report Emails empfangen und versenden.
4. Der Kunde möchte sich mit externen Systemen (z.B. Ticketsystem) via Webservice verbinden.

Den vier Anwendungsfällen ist gemeinsam, dass man zu ihrer Umsetzung darauf angewiesen ist, Java-Klassen, die in einer JAR-Datei vorhanden sind, im ARIS-Skript aufzurufen. Durch Recherche im Internet findet man schnell heraus, dass es für die beschriebene Aufgabe gute Java-Bibliotheken gibt, die man einer Eigenentwicklung vorziehen sollte. Für das vierte Anwendungsbeispiel kommt zusätzlich hinzu, dass Entwicklungsumgebungen einem zu einer Webservice-Definition die umfangreiche Erstellung von Code weitgehend abnehmen. Die anschließende Portierung des Java-Codes in das ARIS-Skript erweist sich jedoch als mühselig. In jedem Fall hat man am Ende eine oder mehrere Java-Bibliotheken, die man gerne im ARIS-Skript ansprechen möchte.

Bevor wir dies tun stellen wir uns jedoch die Frage, welche Java-Klassen eigentlich in der Skripting-Umgebung des ARIS ohne eigenes Zutun zur Verfügung stehen. Aus Philipps Beiträgen (Link und Link) haben wir gelernt, dass dies der Klassen der Java-JRE sind, wobei Philipp einige Objekte aus ihrem Versteck geholt hat. Man könnte vermuten, dass man nur die JRE-Klassen zur Verfügung hat, aber dies ist nicht der Fall. Durch Ausprobieren findet man schnell heraus, dass man etwa auch auf Klassen der Bibliothek POI zugreifen kann, mit der Excel-Dateien umfangreicher als mit reinen ARIS-Methoden eingelesen und geschrieben werden können. Tatsächlich sind im ARIS-Skript über die Klassen der JRE hinaus, diejenigen Klassen verfügbar, die in den JAR-Dateien des Verzeichnisses \server\lib des Reportservers im „unveränderten Installationszustand“ definiert sind. Der unveränderte Installationszustand wird deshalb betont, weil der naive Versuch, die benötigte JAR-Datei einfach in dieses Verzeichnis zu kopieren, leider scheitert. Die Klassen des hinzugefügten JAR-Files lassen sich so einfach nicht verwenden. Mit über zweihundert Bibliotheken stehen dem ARIS-Reportentwickler aber auch deutlich mehr Klassen als lediglich diejenigen der JRE zur Verfügung. Der erste Schritt lautet daher, zunächst zu prüfen, ob die gewünschte Klasse in einem der JAR-Files in \server\lib definiert ist.

Wir nehmen jetzt an, dies sei nicht der Fall. Nach kurzer Recherche stellen wir fest, dass wir zusätzliche Klassen mit Hilfe eines Java-ClassLoaders laden können. Wer mehr über die Tücken von Java-Classloadern erfahren möchte, kann Details hier nachlesen.

Wir überlegen zunächst noch einmal, ob wir tatsächlich die Klassen „selbst“ laden müssen, oder aber dies nicht doch dem ARIS-Server überlassen können. Wer den obigen verlinkten Artikel sorgfältig liest, wird feststellen, dass es ausreichen würde, die JAR-Dateien nach \server\jre\lib\ext zu kopieren. Aus zwei einfachen Gründen sollte man aber die Finger davon lassen: Zum einen können Klassen hierdurch doppelt definiert sein und erhebliche Laufzeitprobleme bereiten. Zum anderen hätte man mit diesem Vorgehen den ARIS-Server selbst einem Customizing unterzogen und würde wohlmöglich sämtlichen Wartungsanspruch verlieren. Daher ist der einzig akzeptable Weg, die Klassen selbst zu laden. Dazu kommt nach einem kurzen Blick in die Java-Dokumentation der URL-Classloader in Frage (siehe auch).

Aus Gründen der Übersichtlichkeit und Kapselung entscheiden wir uns dafür, eine eigene Javascript-Funktion zu schreiben, die wir in eine eigene Datei ClassLoaderSupport.js auslagern:

Im übrigen Reportquellcode wird dann eine Klasse beispielsweise wie folgt erzeugt:

Soll oder muss ein spezieller Konstruktor verwendet werden, kann man dies wie in Philipps Artikel beschrieben über Reflection lösen:

Ob man dies im eigentlichen Quellcode machen möchte, oder aber dem ClassLoaderSupport eine Funktion mitgibt, die dies eleganter löst, hängt von der Häufigkeit und Art der verwendeten Konstruktoren ab.

Diese Javascript-Funktion ClassLoaderSupport werden wir in jedem Fall künftig dazu verwenden, Klassen aus externen oder eigenen Bibliotheken in ARIS-Reportskripten zu laden und somit den Funktionsumfang in ARIS-Skripten zu erweitern.

Tags:

Dies ist nur ein GravatarSascha Zinflou

Interdisziplinär denkender und handelnder Mathematiker mit mehr als zehnjähriger Erfahrung im Bereich „Softwareentwicklung und -anwendung”.