Mit einem Nashorn die Grenzen von ARIS-Reports überwinden und die komplette Java-API nutzen

17.04.2013 |  | Allgemein | 1 Kommentar

Nur Wenige wissen, dass die ARIS-Reporting Engine auf Mozilla Rhino, einer Engine für serverseitiges Javascript basiert. Dies ist deswegen interessant, da sich mit der Rhino Engine nicht nur Javascript-Objekttypen in Skripten verwenden lassen, sondern auch beinahe beliebige Java-Objekte erzeugt werden können.Leider gibt es dabei technische Beschränkungen, die sich zum Glück mit ein paar einfachen Tricks aushebeln lassen. Hierzu ein kleines Beispiel, um vorab mögliche Vorteile der Verwendung von Java-Objekten aufzuzeigen: Nehmen wir an, wir wollen mit einem Report keine doppelten Modelle ausgeben. Für die Erkennung doppelter Modelle verwendet man am besten die GUIDs der Modelle.

Mit reinen Javascript-Boardmitteln würde man dies über ein assoziatives Array abbilden:

und

Natürlich funktioniert dies technisch einwandfrei. Bei größeren Datenmengen kann mit dem assoziativen Array lediglich die Laufzeit des Reports ein wenig leiden. Außerdem kann es Entwicklern bei größeren Skripten schnell passieren, dass die Variable „anArray“ an anderer Stelle im Code tatsächlich wie ein Array angesprochen wird. Die Java-Entwickler werden den im Javascript fehlenden Compiler an dieser Stelle sicherlich verfluchen.

Der Aufruf anArray[0] wird bei einem assoziativen Array jedoch immer den Wert undefined zurückliefern, auch wenn bereits ein Element eingefügt wurde. Gleichermaßen verhält es sich mit dem nativen Befehl anArray.length, der in dem Fall konstant 0 zurückgeben würde.

Besser eignet sich für diese Art der Problemstellung daher etwa das Java-Objekt „java.util.HashSet“. Hiermit würde man den Code ändern zu:

und

So weit, so gut. Erfahreneren Scripting-Experten wird dies natürlich längst bekannt sein. Sofern es sich um eine in der Java-Runtime-Engine mitgelieferte Java-Klasse handelt, kann man dieses Objekt übrigens im Report mit der Anweisung

erzeugen.

Als ich neulich eine eigene Log-Datei mit log4j schreiben wollte, stieß ich jedoch erst einmal an die Grenzen meines ARIS-Lateins. War es noch ohne Probleme möglich, einen log4j-Logger im Report zu erzeugen, stieß ich in der damaligen Version auf das Problem, dass mehrere gleichbenannte Logger zu doppelten Log-Einträgen führen. Daher war mein verwegener Plan, anhand einer Java-Umgebungsvariable zu erkennen, ob mein Logger bereits zuvor erzeugt worden war.

Zu dumm, dass der Zugriff auf das dafür benötigte Java-System-Objekt java.lang.System nicht möglich ist, da die ARIS-Reporting-Engine dessen direkten Aufruf unterbindet. (Gleiches gilt übrigens auch für die Java-Runtime!)

Trotz meines anfänglichen Ärgers habe ich volles Verständnis für diese technische Beschränkung der ARIS-Reporting-Engine! Mit Hilfe dieser Java-Objekte würden sich nämlich allerhand Dummheiten anstellen lassen, wie beispielsweise unzählige neue Java-Threads zu erzeugen oder gar den ARIS-Prozess zu beenden, um nur einige potenzielle Bedrohungen zu nennen. Wer will schon, dass die Skriptentwickler ungehindert den ARIS-Server abschießen?

Doch bei allem Verständnis für diese Einschränkung wollte ich nach wie vor zur Lösung meines harmlosen Problems auf die Umgebungsvariablen zugreifen. Mein Wegbereiter aus dieser Zwickmühle war schließlich die Java-Reflection. Erstaunlicherweise ist es nämlich mittels Reflection auch im ARIS-Script möglich, das Java-System-Objekt anzusteuern und damit u.a. die Umgebungsvariablen abzufragen:

Etwas überrascht, dass die Reflection ungehindert im ARIS funktioniert, bin ich zwar schon gewesen. Aber immerhin kam ich so an meine Umgebungsvariable und konnte ohne Störungen meine Log-Datei schreiben.

Und das Beste ist: Sollte ‘mal wieder eine dringend benötigte Java-Klasse im ARIS-Report blockiert sein, weiß ich, dass man im Zweifelsfall mit Reflection doch daran kommen kann!

Tags:

Dies ist nur ein GravatarPhilipp Thiemann

Experte für Software-Entwicklung und maßgeschneiderte Kundenlösungen mit ausgeprägtem Blick für das Business.

Alle Kommentare

Die Kommentarfunktion ist leider deaktiviert.