exensio it blog

Grails, good to know: Working with the Build Test Data Plugin

2016-10-13T11:20:00.000+02:00

There are several choices for creating test data when working with Grails. Beside the manual creation of domain objects it is possible to use one of the existing plugins. Before Grails 3.0 one of the good choices was the Fixture Plugin for specifying domain test data. This plugin is not ported to newer Grails versions and therefore no longer an option. Another good choice is the Build Test Data Plugin which is in the focus of this post.

After referencing the plugin via the build.gradle file, new domain objects can be created easily by calling the build() method on a domain class. The following listing demonstrates the usage by creating two new entities of the type project. All required attributes of the entities are populated automatically or can be alternatively specified explicitly as shown for the second entity.

The documentation provides more information on the general usage of the plugin. The following sections provide two best practices on using some less known features of the Build Test Data Plugin.

Testing REST APIs

Nowadays many Grails applications provide REST APIs that have also run through the automatic test cycles. Assuming in our case that an existing project from an external system should be imported via REST, it is necessary for a test to construct a post request that contains all necessary attributes and especially an ID. When calling the standard build() method on the project entity and then converting it to JSON, the object will already be saved in the database before sending it via REST to the application. This can be avoided by calling the buildWithoutSave() method instead of the build() method. An example for the usage is shown in the following code snippet:

Creation of custom identities

The ID of the entity is available after creating a new entity via the build() method, when using the standard settings for domain classes. Depending on the requirements it might be necessary to use custom IDs for the database that are assigned manually. This can be specified in the mapping block of a domain class, as shown below:
To avoid the manual assignment of IDs in test cases it is possible to enhance the TestDataConfig file. This file of the BuildTestData Plugin can be used to define static or dynamic values for the attributes of entities when creating test data. In our case we assume that UUIDs are assigned as IDs to the domain classes. We want to make sure that an artificial ascending UUID is assigned to every created entity. This can be done by defining a closure that generates the assignment code of an ID for each domain class which is shown in the following listing.

A simple test for verifying the creation of project entities and its correct UUID assignment can look like shown below.

Migration von Grails 1.3.7 nach 3.1.9 - Testing - Teil 3

2016-10-05T10:26:00.000+02:00

Dies ist der dritte Beitrag über die Migration einer Grails Applikation. Im ersten Teil habe ich mich mit allgemeinen Schwierigkeiten und Lösungen befasst und im Zweiten Teil eine selbstentwickelte Lösung zum Erstellen von Testdaten vorgestellt. In diesem Beitrag werde ich speziell die Tests beleuchten.

Testarten

In der existierenden Applikation gibt es eine übersichtliche Anzahl von Unit-Tests. Der größte Teil der Integrationstests besteht aus Controller- Integrationstests und nur wenigen Service- Integrationstests. Als funktionale Tests wurden historisch bedingt die Frameworks Geb und Webtest eingesetzt.
In früheren Versionen konnte das Testing Framework Spock über ein Plugin eingebunden werden, während es in neueren Versionen direkt in Grails integriert ist. Auch Geb muss nicht mehr als Plugin eingebunden werden sondern wird direkt unterstützt. Webtest ist ein Plugin das zum automatischen Testen von Web-Applikationen implementiert wurde, jedoch nicht mehr weiter entwickelt wird und deshalb nicht mehr verwendet werden kann.

Unit Tests

Da schon in der ursprünglichen Version das Test Framework Spock verwendet wurde, konnten die Unit Tests ohne große Schwierigkeiten migriert werden. Hauptsächlich sind Funktionsaufrufe überflüssig, die durch Annotationen ersetzt wurden.

Integrationstests

Es wird empfohlen Controller möglichst als Unit Tests zu realisieren und Services mit Integrationstests zu testen. Sämtliche Versuche, die bestehenden Controller-Integrationstests zu migrieren, blieben erfolglos. Man kann ein Objekt eines Controllers erstellen, jedoch war es nicht möglich, diesen mit allen Abhängigkeiten zu initialisieren. Schwierigkeiten hierbei waren die Hibernate-Session und HTTP-Sessions, die nicht korrekt funktionierten, so dass bspw. ein Service keine Daten der Datenbank abfragen oder die HTTP- Session bearbeiten konnte.

Wir haben uns dazu entschlossen, den Empfehlungen zu folgen und die Tests zu ändern. Das bedeutet für die Controller neue Unit Tests zu schreiben und für die Services Integrationstests. Ich glaube, dass durch diesen Schritt eine höhere Robustheit gegenüber kommenden neueren Versionen geschaffen wird, da jetzt ausschließlich native Bordmittel von Grails verwendet werden.

Beim Migrieren der Service-Integrationstests macht sich vor allem Grails' Umstellung auf Spring- Boot bemerkbar, das seit der Version 3.0 verwendet wird [1]. Denn ab jetzt wird die setupSpec Funktion von Spock, der ersten Testklasse, vor dem Start der Applikation ausgeführt, was deren Nutzen stark einschränkt. Beispielsweise ist das Anlegen oder Laden von Daten aus der Datenbank, die zum Testen verwendet werden sollen, nicht mehr möglich, denn sämtliche Hibernate- Funktionen sind nicht verfügbar. Weiter wird der where Block, der in Spock verwendet werden kann, vor dem Ausführen der setup- Methode ausgewertet. Somit sollten dort statische Werte verwendet werden, wie String, int oder boolean. Es ist möglich, eine ähnliche Funktionsweise wie die setupSpec Funktion nachzubilden.
Dazu wird eine statische boolean Variable initialized = false angelegt. In der setup-Funktion wird zusätzlich zu dem Code, der vor jeder Testmethode ausgeführt werden soll, eine if- Condition verwendet um Code zu kapseln, der nur ein einziges mal zu Beginn ausgewertet werden soll. Hierzu wird mit !initialized überprüft, ob dieser Teil bereits einmal durchlaufen wurde. Am Ende der if- condition wird die Variable initialized auf true gesetzt und somit wird dieser Codeteil nicht noch einmal ausgeführt. Das nachfolgende Codebeispiel veranschaulicht das Prinzip.

Funktionale Tests

Da in der ursprünglichen Version ebenfalls schon Geb verwendet wurde, können diese Tests ohne größere Anstrengungen migriert werden. Auch hier sind nur vereinzelt kleinere Änderungen durchzuführen. Zum Beispiel müssen alle Testklassen mit der Annotation @Integration markiert werden, oder der contextPath muss bei der Url Definition der pages erweitert werden, da Grails diesen nicht mehr standardmäßig auf den Namen der Applikation setzt [2].

Das dem Grails Webtest Plugin zu Grunde liegende Projekt Canoo Webtest wird nicht mehr entwickelt und somit ist auch das Grails Plugin nicht mehr aktuell und funktionsfähig. [3] [4] Es gibt somit keine Alternative außer der Neu-Implementierung dieser Tests mit Geb. Ich habe eine - wenn auch sehr umständliche - Möglichkeit gefunden, die alten Webtests gegen die migrierte Applikation auszuführen. Der Vorteil hierbei ist, dass die neue Applikationen während der Migration auf die richtige Funktionalität geprüft werden kann. Somit hat man die Gewissheit, dass sie wie gewünscht funktioniert, auch wenn noch keine umfangreichen neu implementierten Tests vorhanden sind.

Dazu lässt sich in der Konfigurationsdatei webtest.properties mit den folgenden drei Zeilen einstellen, welcher Server getestet werden soll. Da dadurch die alte Applikation gestartet wird, muss darauf geachtet werden, dass sie mit einem anderen Port wie die Neue startet, da es sonst zu Fehlern kommt.

Fazit

Die Migration der Tests ist in unserem Fall der größte Teil Umstellung auf Grails 3.1.9. Da es in früheren Versionen noch mehrere Test-Möglichkeiten gab und auch Grails sich stark weiter entwickelt hat, ist es leider nicht immer möglich, alte Tests zu migrieren - ein großer Teil der Tests muss komplett neu geschrieben werden.
Ich hoffe ich kann mit dieser Blog-Artikel-Reihe über die Migration einer großen Grails Applikation einigen Interessierten einige Arbeit ersparen, indem sie auf die aufgezeigten Lösungen zurückgreifen.

Links

[1] Neuerungen seit Grails 3

[2] Funktionale Tests in Grails 3.1.9

[3] Canoo Webtest Sourcecode auf GitHub

[4] Grails Webtest Plugin

Migration von Grails 1.3.7 nach 3.1.9 - Erstellen von Testdaten - Teil 2

2016-09-27T06:30:00.000+02:00

Wie schon im ersten Teil dieser Reihe beschrieben, stand ich während der Migration einer Applikation der Version 1.3.7 auf 3.1.9 vor dem Problem, dass das Plugin Fixtures, welches zum Erstellen und Einspielen von Testdaten verwendet wurde, nicht mehr weiterentwickelt wird. Hier will ich nun darstellen, welche Anforderungen wir an eine neue Lösung hatten, welche Möglichkeiten sich boten und was schließlich dazu führte, eine eigene Lösung zu implementieren. Abschließend werde ich das Prinzip meiner Lösung näher erläutern und Codebeispiele geben.

Anforderungen

Eine besondere Funktionalität des Fixtures-Plugins ist die Möglichkeit, den einzelnen Testdaten-Instanzen einen eindeutigen Namen zu geben und diese in Test Cases zu referenzieren. Da Testdaten vorhanden waren, die natürlich wieder verwendet werden sollten, ist es zusätzlich von Vorteil, wenn die Daten möglichst ähnlich dargestellt werden. Damit ist es möglich mit Hilfe der Suchen und Ersetzen Funktion der IDE wiederkehrende Muster zu finden und diese an das neue Format anzupassen. Eine weitere Anforderung war die Robustheit gegenüber Änderungen. Zum Beispiel sollte es keine großen Anpassung der Fixtures nach sich ziehen, wenn einem Attribut der Constraint bindable:false hinzugefügt wird. Diese Änderung würde bei der Erstellung einer Instanz erzwingen, dass dieses Attribut nicht innerhalb einer Map übergeben wird, sondern einzeln gesetzt werden muss.

Alternativen

Das Grails-Plugin Build-Test-Data wurde für die Erstellung von Testdaten implementiert. Es analysiert automatisch Constraints einer Domainklasse und erstellt valide Instanzen. Möglich wäre es, die schon vorhandenen Daten zu verwenden und daraus Instanzen zu erstellen - jedoch nicht, ohne eine eigene Erweiterung die Daten zu speichern und wieder zu verwenden.

Da ohne eine eigene Implementierung keine Möglichkeit gegeben war, kam die Idee auf, die einzelnen Instanzen manuell per Konstruktor-Aufruf zu erstellen. Hierzu müsste jedoch die Syntax der Test-Daten stark geändert werden. Auch könnte es zu Problemen führen, wenn es Änderungen an den Constraints gibt. Wird, wie oben beschrieben, zu einem Attribut der Constraint bindable:false hinzugefügt, müssten alle Instanzen der Domainklasse angepasst werden.

Da keine der Lösungen zufriedenstellend verwendet werden konnte, habe ich mich dazu entschlossen, eine eigene Lösung zu implementieren, um Test-Daten zu erstellen. Mit der eigenen Implementierung ist es wieder möglich, die Testdaten in Test Cases zu referenzieren.

Implementierung der eigenen Logik

Es soll die Möglichkeit geboten werden, Daten zu definieren, die automatisch gespeichert werden. Für komplexere Beziehungen soll es möglich sein, separate Daten zu beschreiben, die zunächst erstellt und nicht explizit gespeichert werden sollen, da diese von anderen Daten abhängen und dort ein kaskadierendes Speichern notwendig ist. Abschließend kann eine Funktion implementiert sein, in der beliebige Operationen für Modifikationen ausführbar sind.

Data-Klasse

Da alle Klassen einem bestimmten Aufbau folgen müssen, um eine korrekte Funktionsweise zu gewährleisten, habe ich eine abstrakte Oberklasse implementiert, von der geerbt wird. Diese besitzt folgende leere Funktionen, die dazu verwendet werden um zum einen die Daten auszulesen und zum andern ggf. spezielle Beziehungen herzustellen:

getPreData: Diese Methode muss überschrieben werden und eine Map mit Daten zurückgeben.
getData: Diese Methode muss ebenso eine Map der Daten zurück geben.
post: Diese Methode kann überschrieben werden.

Beide get Methoden müssen eine Map zurückgeben, in der die Daten enthalten sind. Als Schlüssel wird jeweils der Name verwendet, unter dem die Testdaten Instanz referenziert werden kann, und als Wert eine Map, die die Attribute und deren Werte enthält. Zusätzlich muss der Schlüssel domainName enthalten sein, der die Domainklasse definiert. Da der Aufbau der neuen Daten ähnlich dem der Fixtures ist lassen sich diese schnell passend migrieren. Wie nachfolgend zu sehen müssen vor allem die Klassen sowie Methoden-Deklarationen erweitert werden.

Sollen Beziehungen zwischen Instanzen hergestellt werden, realisiert man diese mit Closures. Dabei wird, wie oben zu sehen eine Referenz auf die gewünschte Instanz zurückgeben. Da die Closure erst beim Erstellen der Daten ausgewertet wird, muss die Reihenfolge beachtet werden, in der man Daten erstellt. Bei Beziehungen, die mit belongsTo markiert sind, greift ein kaskadierendes Speichern, das die abhängige Instanz mitspeichert. Hierfür wurde die Methode getPre geschaffen, die es ermöglicht, Daten zu erstellen, die nicht explizit gespeichert werden, aber nach dem Erstellen der Hauptdaten auf Persistenz überprüft werden. In der Methode post kann man beliebige Operationen ausführen. In der migrierten Applikation sind in wenigen Domainklassen Hilfsfunktionen implementiert um Beziehungen zwischen Instanzen herzustellen. Dabei wird nicht nur die Referenz gespeichert sondern auch Attributwerte an verschiedensten Stellen in der Datenbank geändert. Es bietet sich an dies, wie in dem nachfolgenden Codeausschnitt zu sehen, in der post Methode zu verwenden.

DataLoader-Klasse

DataLoader ist eine abstrakte Klasse, die die Map data enthält, in der alle erstellten Instanzen gespeichert werden. Mit der Funktion loadDataClass ist es möglich, alle Daten, die in der übergebenen Klasse definiert sind, zu erstellen und speichern. Tritt ein Fehler in einer der Daten Instanzen auf, wird eine Exception geworfen. Zuerst wird ein Objekt der übergebenen Klasse erstellt und die preData sowie data ausgelesen. Sind preData vorhanden, werden diese vor den Hauptdaten erstellt, anschließend gespeichert und die preData auf Persistenz geprüft. Zum Schluss wird die Funktion post ausgeführt. Im folgenden Sequenzdiagramm ist der Ablauf bildlich darstellt:

Eine Exception wird erzeugt, wenn

ein Name zur Referenzierung der Daten doppelt verwendet wird
keine Beziehung (null) hergestellt werden kann
das Speichern einer Instanz nicht möglich ist
ein preData-Aufruf nicht gespeichert wurde

Der folgende Code- Block enthält einen ersten Entwurf der Logik, wie das Erstellen der Daten realisiert werden kann.

Fazit

Diesd Implementierung funktioniert in dem migrierten Projekt sehr gut, wenngleich noch einige Verbesserungen möglich sind. Zum einen könnte die Performance verbessert werden und zum anderen könnten die Implementierung dahingehend verbessert werden, dass eine Fehlverwendung vermieden wird.

Migration von Grails 1.3.7 nach 3.1.9 - Probleme und deren Behebung - Teil 1

2016-09-20T06:00:00.000+02:00

In den letzten Monaten hat es zu meinen Hauptaufgaben gezählt, eine große Business-Applikation von Grails 1.3.7 auf die Version 3 zu migrieren. In diesem Blog Post will ich auf allgemeine Schwierigkeiten und Lösungen eingehen, die in unserem Fall aufgetreten sind.
In den folgenden Posts werde ich zum einen auf die selbst entwickelte Lösung zum Erstellen von Testdaten eingehen und zum anderen die Probleme bei der Migration der einzelnen Testarten erläutern.

Für die Migration wurde in folgender Reihenfolge vorgegangen:

Neues Projekt mit der gewünschten Grails Version erstellen und konfigurieren
Einbinden aller Plugins in der neusten verfügbaren Version, die verwendet werden sollen
Migrieren der Domain-/ Java-/ Groovy-Klassen, sowie TagLibs und i18n- Ressourcen
Einspielen von Testdaten
Migrieren der Services
Migrieren der Controller
Migrieren der Views und alle zugehörigen Ressourcen wie JavaScript und CSS Dateien
Migrieren der Testdateien

Nach jedem Schritt wurden automatisierte Tests, die die schon migrierten Teile der Applikation testen, ebenfalls migriert, um möglichst früh Fehler zu erkennen. Wie oben beschrieben werde ich im dritten Teil dieser Serie genauer darauf eingehen.

Hibernate naming_strategy

Nachdem die Domainklassen sowie sämtliche Hilfsklassen migriert waren, ist durch das Starten mit einer bestehenden Datenbank, aufgefallen, dass das automatisch erstellte Datenbankschema nach dem Starten der Applikation sich von dem Ursprünglichen hinsichtlich der Tabellennamen unterscheidet. Das Anpassen der hibernate.naming_strategy hat für mich das Problem gelöst. In der Hibernate-Dokumentation für das Interface NamingStrategy können implementierte Strategien gefunden werden, die Hibernate von Haus aus mit bringt. Das Definieren eigener Strategien ist jedoch ebenso möglich. [1]

Actions von Controllern

Treten bei Controllern Fehler auf, dass Annotationen nicht erlaubt seien, liegt das daran, dass Actions seit Grails 2 als Methoden implementiert werden sollen. Bei Applikationen der Version 1.x war es üblich diese als Closures zu programmieren. [2]

Transaktionen in Services

Transaktionen ist der wesentliche Punkt, der sich für Services verändert hat. Bis zur Version 2.3 von Grails wurden die Spring Transaktionen verwendet, die durch das statische Attribut transactional aktiviert oder deaktiviert wurden. Empfohlen wird, diese komplett durch die seither neuen, Grails Transaktionen zu ersetzen, die über Annotationen verwendet werden. Alle Services ohne jegliche Annotationen benutzen standardmäßig Transaktionen.

Vorsicht ist geboten, wenn der Modus einzelner Methoden vom default Wert read-write beispielsweise zu readOnly geändert werden soll, denn dann muss die Service Klasse ebenfalls als @Transactional gekennzeichnet werden. Sind nur einzelne Methoden und nicht die Klasse gekennzeichnet, werden nur für diese Methoden Transaktionen verwendet, alle anderen jedoch nicht. [3]

Resource- Plugin durch Asset- Pipeline ersetzen

Seit der Version 2.0 von Grails wurde das bisher verwendete resource Plugin durch asset-pipeline ersetzt. Dadurch muss das Einbinden der JavaScript und CSS Dateien angepasst werden. In der Datei UIResources.groovy wurden bisher sogenannte Module definiert. Mit dem Tag <r:require modules=“common”/> wurden diese Dateien in dem entsprechenden View eingebettet. Um ein ähnliches Verhalten nachzubilden, habe ich für jedes Modul eine neue JavaScript und eine CSS Datei erstellt, die die zugehörigen Dateien definiert. In den folgenden Ausschnitten ist dies beispielhaft dargestellt.

Die verwendeten Pfade der Ressourcen sind relativ, ausgehend von der Dateistruktur grails-app/assets/javascript/ oder grails-app/assets/stylesheets/. Wichtig ist hierbei auf die Reihenfolge zu achten, denn ansonsten könnte es vorkommen, dass JavaScript eine Funktion verwenden will, die noch nicht definiert wurde, was zu Fehlern führt. Um die neu erstellten "Module" zu nutzen, werden nun zwei Aufrufe benötigt: <asset:javascript src=“commonModule.js”/> und <asset:stylesheet src=“commonModule.css”/>.

Deploying

Abschließend gehe ich noch auf ein Problem ein, das schwer zu entdecken ist. Ein, mit Hilfe des Gradle Task bootRepackage erstelltes Standalone War-File, hat zufällig, entweder unter Windows oder, was öfter auftrat, unter Linux, anstelle der erwarteten Login Seite eine Liste aller Controller angezeigt. Verursacht wurde dieses Problem dadurch, dass in unserer Applikation das URL- Mapping, speziell der Root- Endpunkt (“/“), angepasst wurde. Dadurch kann es auftreten, dass ein Plugin, das auch eine UrlMapping.groovy Datei besitzt, die eigene Änderung überschreibt. Hier war noch der Standardwert enthalten, der auf eine fehlerhafte View verwiesen hat. Mit einem Workaround lässt sich dies umgehen. Dazu wird ein Interceptor implementiert, der aktiv werden soll, wenn eine Anfrage an “/“ gesendet wird und dann manuell auf den gewollten Controller und dessen action umleitet. Hier ist ein Beispiel, das eine mögliche Implementierung des Interceptors darstellt.

Fazit

Es wurden einige Probleme und deren Möglichkeiten zur Behebung bei einer Grails-Migration vorgestellt. Eine Migration von älteren Versionen ist also nicht unmöglich, aber auch nicht an allen Stellen einfach. Oft sind es nur Kleinigkeiten, die sich geändert haben und meist durch eine Anpassung der Konfigurationen behoben werden können. Problematisch ist eher das Finden der Ursache zu den auftretenden Fehlern.

Links

[1] Hibernate Naming Strategy ändern - Grails 3.1.9 Guide
[2] Änderungen seit Grails 2.0
[3] Transaktionen in Grails 3.1.9

Lizenzanalyse mit dem Open Source Tool ScanCode toolkit

2016-07-01T11:02:00.000+02:00

In diesem Blogpost möchte ich auf das Tool ScanCode toolkit eingehen und zeigen wie man damit überprüfen kann welche Lizenzen die abhängigen Jar-Dateien eines Java-Projektes verwenden. Diese Information kann relevant sein, wenn man prüfen will ob daraus bspw. rechtliche Probleme resultieren können. Im Bitkom-Leitfaden zu Open-Source-Software 2.0 wird diese Thematik aufgegriffen und behandelt.
Für dieses Beispiel wurde eine Grails- Applikation zur Hand genommen, welche etwas mehr als 150 externe Jar- Dateien einbindet, von denen die Lizenzen ermittelt werden sollen.

Damit ScanCode toolkit Dateien überprüfen kann, müssen sie in entpackter Form vorliegen. Die Funktion zum Entpacken wird von Haus aus mitgeliefert, jedoch muss das Entpacken manuell gestartet werden. Wechselt man mit einem Terminal in das Verzeichnis des Tools kann mit folgendem Befehl das rekursive Entpacken aller Dateien in dem Zielverzeichnis gestartet werden:

Der Pfad zum Zielverzeichnis ist relativ. Alle entpackten Dateien werden in demselben Verzeichnis mit dem Postfix „-extract“ gespeichert. Liegen alle Dateien entpackt vor, kann man den Scan starten.
Dies geschieht mit dem folgenden Befehl:

Auch hier werden relative Pfade erwartet. Verwendet man die Option „-- format“kann die Art der Ausgabe bestimmt werden, dazu später mehr.

Die Funktionsweise von ScanCode toolkit ist einfach, es durchsucht alle Dateien, in dem Zielverzeichnis, gegen einen bestehenden und erweiterbaren Datensatz von Lizenzen. Nach dem gleichen Prinzip ist es auch möglich Copyright- Statements zu finden, dies wurde jedoch nicht getestet und wird hier nicht weiter erläutert.
Der Nachteil hierbei ist, dass dadurch Jar- Dateien mehrfach aufgelistet werden. Dies hat mehrere Gründe, zum einen kann es sein, dass diese unter einem dualen Lizenzsystem angeboten werden. Das bedeutet es werden mehrere Lizenzen aufgelistet, unter welcher die Software verwendet wird bleibt dem Benutzer überlassen. Zum anderen ist es möglich, dass ein Plugin seinerseits weiteren Code einbindet und dessen Lizenz, beispielsweise in einem Kommentar deutlich macht. In extremen Fällen verwendet auch dieser ein duales Lizenzsystem.

Man hat die Wahl zwischen 3 verschiedenen Visualisierungsmöglichkeiten. Die Ausgabe als JSON- Datei, einer statisch HTML- Seite, welche eine Tabelle der Daten enthält oder eine HTML- Applikation die das Filtern, Sortieren und Navigieren über die Verzeichnisstruktur erlaubt.

In Abbildung 1 ist eine beispielhafte Darstellung eines Scanergebnisses als HTML- App dargestellt. Navigiert man im linken Bereich durch die Verzeichnisstruktur werden die visualisierten Daten im rechten Bereich entsprechend angepasst. Sind in dieser Gesamtansicht nun unerwünschte Lizenzen aufgelistet wird die Stärke dieser HTML- Applikation deutlich.

Abbildung 1

Wechselt man in den Reiter „License & Copyright Details“wird eine Liste angezeigt die Dateien enthält in denen Lizenzen gefunden wurden. Sortiert man diese, wie in Abbildung 2, nach der Spalte Info kann man gezielt die Namen, der Jar- Files, in der Spalte Path ablesen, in denen Stichworte gefunden wurden, die in Verbindung mit den unerwünschten Lizenzen stehen. Das Verwenden der Suchfunktion, oben rechts, kann hierbei eine Hilfe sein.

Abbildung 2

Es ist sinnvoll die Plugins, bei denen ein unerwünschte Lizenz gefunden wurde, einzelnen auf deren Lizenz zu überprüfen. Denn, wie oben beschrieben, ist es möglich und meiner Erfahrung nach meistens der Fall, dass es unter einer Multilizenz steht oder Code einbindet der unter einer Mehrfachlizenzierung steht, was der Grund ist warum diese unerwünschte Lizenz angezeigt und in Verbindung mit der Jar- Datei aufgelistet wird.

Fazit

Das Tool ersetzt nicht das Evaluieren der Lizenzen. Die Entscheidung unter welche Lizenz eine Jar-Datei fallen darf, oder besser unter welche sie nicht fallen darf, damit es verwendet wird, muss noch immer manuell getroffen werden. Aber um einen schnellen Überblick zu bekommen welche Lizenzen verwendet werden und ob evtl. unerwünschte vorhanden sind ist es hervorragend geeignet.
In diesem Fall sind, von den anfänglich gut 150 Jar- Dateien, sieben in Verbindung mit unerwünschten Lizenzen aufgetaucht. Nach einer weiteren Untersuchung, bspw. auf der Hersteller Homepage, konnten auch deren Lizenzen schnell überprüft und für gut befunden werden.

HTML als HTML in Grails anzeigen

2016-06-22T15:25:00.001+02:00

HTML als HTML in Grails anzeigen ist natürlich keine Rocket-Science. Aber da ich aktuell eine Weile suchen musste, möchte ich hier kurz mein Wissen teilen :-)

In Solr Highlighting bekommt man die markierten Texte automatisch mit <em> bzw. </em> markiert. Und eben diese wollte ich in eine GSP in Grails anzeigen.

Eigentlich sollte folgendes funktionieren:

${doc.content} wird automatisch encoded, wenn in Config.groovy grails.views.default.codec="html" gesetzt ist, müsste man auf "none" setzen. Man kann dies auch auf nur einer Seite mittels <%@page defaultCodec="none" %> setzen.
Oder man benutzt die JSP Notation, <%=doc.content%> benutzen.

Hat beides nicht funktioniert. In Grails 2.5.4 hat schließlich nur folgendes funktioniert: ${raw(doc.content)}.

Happy Coding!

Rückblick auf die GR8Conf in Kopenhagen

2016-06-06T07:17:00.000+02:00

Dieses Jahr durfte ich drei Tage auf der gr8conf zu Gast sein und mein Wissen hinsichtlich des Groovy- und Grails-Ökosystems erweitern. Um die Open-Source Aktivitäten rund um diese Technologien zu fördern waren wir von der Firma exensio auch einer der Sponsoren dieser Konferenz.

Tag 1

Über den gesamten ersten Tag wurden jeweils 2 parallele Workshops angeboten.
Ich hatte zunächst den Workshop zu gradle besucht, der viele Best Practices zum Build-System geboten hat.
Mein zweiter Workshop befasste sich mit Grails und AngularJS. Mit dem AngularJS-Profile wird eine Integration des Javascript-Frameworks innerhalb von Grails ermöglicht. Durch die direkte Integration können allerdings die beiden Komponenten nicht mehr einfach voneinander physikalisch getrennt werden, sprich der Javascript-Code wird auf einem anderen Server wie die Grails-Code installiert.
Am Abend fand der traditionelle Hackergarten statt, dessen Ziel es ist innerhalb eines Abends etwas zur Open-Source-Community beizutragen. Ich arbeitete mit anderen Teilnehmern an der Aktualisierung des Elasticsearch-Plugins für Grails.

Tag 2

Mit der Keynote von Ken Kousen startete der zweite Tag. Er ging insbesondere auf den aktuellen Status von Groovy ein. Die Ankündigung von gradle vor wenigen Wochen, dass zukünftig neben Groovy die Programmiersprache Kotlin unterstützt wird, sorgte für einiges an Diskussionen in der Groovy-Community. Aus seiner Sicht sollte sich Groovy davon aber nicht beunruhigen lassen, da Groovy weiterhin von gradle unterstützt wird und außerdem in vielen anderen Systemen, wie bspw. Jenkins, verwendet wird.

Den interessantesten Vortrag an diesem Tag hielt aus meiner Sicht Michael Ploed zum Thema Reactive Applikations mit Grails 3. Er zeigte auf, wie einfach die Modularisierung von Grails-Applikationen mit Hilfe des in Grails 3 integrierten Reactor-Frameworks erfolgen kann.
In der Präsentation »Monitoring and Metrics with Grails 3« stellte Jeff Scott Brown das neue dropwizard-metric Plugin vor. Hiermit können zukünftig elegant Laufzeiten und die Anzahl von Methodenaufrufen gemessen werden.
Das Thema »Dockerize you Grails App« war meine Abschluss-Session an diesem Tag. Hier wurde auf Docker Basics eingegangen und aufgezeigt, wie einfach Grails-Applikationen darauf aufsetzen können.

Tag 3

Am dritten Tag standen für mich zwei Sessions zum Thema Plugins auf dem Programm. Neben einem generellen Überblick im Vortrag »Mastering Grails 3 plugins« ging der zweite Vortrag auf die Migrationsmöglichkeiten von Plugins von der Version 2 auf 3 ein.
Am spannendsten waren die Präsentationen von Graeme Rocher zur weiteren Entwicklung von Grails. Hier ist insbesondere das mit Grails 3.2 kommende Thema RxGORM, das nicht blockierende Datenbankzugriffe bietet sehr interessant.

Fazit

Neben vielen wissenswerten Informationen zu den verschiedenen Groovy- und Grails-Technologien ist Kopenhagen nicht nur wegen der gr8conf eine Reise wert. Die Stadt ist wunderschön und bietet im Vergleich zu den meisten Städten in Deutschland vielfältige und interessante Gebäudearchitekturen.

Latest jQuery with Grails 2 and the resources plugin

2016-04-15T16:40:00.000+02:00

We just updated the front end of an older Grails 2.1.5 application to Bootstrap.

The application uses the resources plugin and due to some other dependencies the jQuery plugin is loaded. The jQuery plugin ships with jQuery 1.11.1 and was not updated since 2014. The latest jQuery version as of now is 2.2.3. So how can we update the javascript library without fiddling with dependency excludes or other hacks?

The resources plugin lets you override single resource files that are loaded in a plugin. The only thing you need is the id of the resource. In this case we have the following definition in the Grails jQuery plugin: The id for the javascript file is 'js'. The new jQuery version was put in web-app/lib/jquery-2.2.3. With the following override in the ApplicationResources.goorvy configuration the latest jQuery version is used everywhere: This is a simple and fast way to override any javascript or css file that is provided by a Grails plugin. The documentation of the resources plugin has some more informations about overrides.

ShipIt Day 2016: iBeacon Tracking Server

2016-02-16T09:08:00.000+01:00

Für unser Ship-It Day Projekt "Mit iBeacons Arbeitszeit erfassen" haben wir eine App für Smartphones und eine Server-Applikation entwickelt. Nachdem wir im ersten Artikel das Projekt und die mobile App vorgestellt haben, geht es in diesem Artikel um die Server-Applikation.

In der Server-Applikation werden alle Daten gespeichert, aggregiert und verwaltet. Die App wurde mit Grails 3.1.1 und Bootstrap 4 (Alpha) umgesetzt.

Die Funktionalitäten

Auf der Startseite wird angezeigt, welche Mitarbeiter gerade im Büro sind und wann sie angekommen sind. Im unteren Teil werden die Mitarbeiter angezeigt, die nicht im Büro sind, und wann sie das Büro verlassen haben.

Für jeden Mitarbeiter gibt es eine Detail-Ansicht, wo die Arbeitszeit für die letzten Tage, Wochen usw. angezeigt werden. Es wird auch eine Liste mit den einzelnen Events angezeigt, wie sie von den Smartphones geschickt wurden.

Außerdem können neue Mitarbeiter angelegt, die wichtigsten Mitarbeiter-Daten bearbeitet und Geräte einem Mitarbeiter zugeordnet werden. Sendet ein neues Gerät Daten an die Applikation, taucht es automatisch in der Übersicht auf und kann einem Mitarbeiter zugeordnet werden.

REST-API

Die Daten werden über eine REST-Schnittstelle von der App entgegen genommen. Über diese Schnittstelle kann die App ebenfalls die aggregierten Daten für einen Mitarbeiter abrufen. Außerdem ist eine Schnittstelle für unser zweites ShipIt-Day Projekt, das Dashboard, vorhanden. So könnte auch das Dashboard die anwesenden Mitarbeiter anzeigen.

Durch Grails 3 kamen diese Schnittstellen praktisch umsonst bei der Entwicklung mit. Grails erkennt automatisch, ob der Client HTML oder JSON empfangen will, und sendet selbständig die richtige Antwort. Eine Funktion, die alle anwesenden und abwesenden Mitarbeiter in zwei Listen zurück gibt sieht z.B. so aus:

    def index() {
        List<User> usersInOffice = User.findAllByStatus(UserStatus.IN_OFFICE)
        List<User> usersOutOfOffice = User.findAllByStatus(UserStatus.OUT_OF_OFFICE)

        def result = [usersInOffice: usersInOffice, usersOutOfOffice: usersOutOfOffice]

        respond result
    }

Auch die Integration von Bootstrap gelingt auf Anhieb und macht eine solche Anwendung ohne großen Aufwand gleich um einiges hübscher.

Weiter-Entwicklung

Für einen produktiven Einsatz fehlen noch einige Komponenten, wie z.B. eine Authentifizierung und die sichere Übertragung der Daten. Diese müssten noch nachgerüstet werden.

Als Erweiterungen könnten wir uns noch eine Verwaltung für die iBeacons vorstellen. Die Applikation könnte mit mehr Informationen über die iBeacons auch feststellen, in welchem Raum sich welcher Mitarbeiter aufhält. So könnte dann auf dem Dashboard immer angezeigt werden, wenn die heiß begehrte "Telefonzelle" besetzt ist.

Fazit

Der ShipIt Day hat viel Spaß gemacht und für das eine oder andere Gelächter gesorgt. Die Projekte sind für zwei Tage Entwicklung ganz gut gelungen und wir freuen uns schon auf den nächsten ShipIt Day.

File Upload bei funktionalen Tests in Grails

2015-11-30T14:28:00.002+01:00

In diesem kurzen Blog-Post möchte ich zeigen, wie man bei Grails bei funktionalen Tests einen File Upload überprüfen kann. Laut Geb Dokumentation [1] funktioniert das folgendermaßen:


        when: "lorem ipsum "
            ...
            assert uploadedIconFile1.exists()
            form.productIcon = uploadedIconFile1.absolutePath
            report 'lorem ipsum'
            saveButton()

Für die Tests bietet es sich an, bereits mit dem Asset-Pipeline-Plug-in verwaltete Bilder zu benutzen. Die Dokumentation hierzu ist jedoch recht dürftig.

Dieser Zugriff kann so erfolgen:


class ProductSpec extends GebServiceSpec {
    ...  
    @Shared
    File uploadedIconFile1 = new File(AssetHelper.fileForFullName('layer1.png').getInputStream().properties['inIfOpen'].path as String)
    ...

[1] http://www.gebish.org/manual/current/#file-upload
[2] https://grails.org/plugin/asset-pipeline

Wie frage ich Elasticsearch mit der Elastic Groovy API in Grails ab?

2015-06-07T17:20:00.000+02:00

Es gibt verschiedene Möglichkeiten, Elasticsearch in Grails zu integrieren. Am Besten finde ich die Groovy API von Elasticsearch. Das Ganze wird über folgende Zeilen in der BuildConfig.groovy konfiguriert.

com.spatial4j und com.vividsolutions werden für die Geo Location und Search Funktionalität von Elasticsearch benötigt.

dependencies {
       ...
        compile group: 'org.elasticsearch', name: 'elasticsearch-groovy', version: '1.5.0', classifier: 'grails'
        compile group: 'com.spatial4j', name: 'spatial4j' , version : '0.4.1'
        compile group: 'com.vividsolutions', name: 'jts' , version : '1.13', excludes: 'xerces'
    }

Und folgendes Beispiel zeigt eine Grails Service Methode, die Elasticsearch abfrägt. Hierbei sieht man m.E. sehr schön, wie elegant man die Queries in Groovy definieren und später die Response verarbeiten kann.

package competition

import grails.transaction.Transactional
import org.elasticsearch.action.search.SearchRequestBuilder
import org.elasticsearch.action.search.SearchResponse
import org.elasticsearch.client.Client
import org.elasticsearch.client.transport.TransportClient
import org.elasticsearch.common.settings.ImmutableSettings
import org.elasticsearch.common.settings.Settings
import org.elasticsearch.common.transport.InetSocketTransportAddress
import org.elasticsearch.index.query.QueryBuilders
import org.elasticsearch.search.aggregations.AggregationBuilders

@Transactional
class ElasticGroovyClientInGrailsService {
    static transactional = false

    def query() {

        Client client = getESClient()
        SearchRequestBuilder requestBuilder = client.prepareSearch("weinsuche")

        requestBuilder
                .setQuery(QueryBuilders.matchAllQuery())
                .addFields("shopname", "shopurl", "kategorie", "herkunftsland", "anbauregion", "weingut", "preiseinheit")
                .setSize(15)
                .addAggregation(AggregationBuilders.terms("Händler").field("shopurl"))
                .addAggregation(AggregationBuilders.terms("Kategorie").field("kategorie_raw"))
                .addAggregation(AggregationBuilders.terms("Land").field("herkunftsland_raw"))
                .addAggregation(AggregationBuilders.terms("Anbauregion").field("anbauregion_raw"))
                .addAggregation(AggregationBuilders.terms("Weingut").field("weingut_raw"))
                .addAggregation(AggregationBuilders.range("Preis").field("preiseinheit")
                .addUnboundedTo(10.0f)
                .addRange(10.0f, 15.0f)
                .addRange(15.0f, 20.0f)
                .addRange(20.0f, 30.0f)
                .addRange(30.0f, 50.0f)
                .addRange(50.0f, 100.0f)
                .addUnboundedFrom(100.0f)
        )

        SearchResponse response = requestBuilder.execute().actionGet()
        printResponse(response)

        client.close()

        return response
    }

    private printResponse(SearchResponse response) {
        response.getHits().getHits().each { searchHit ->
            println searchHit.fields.shopname?.value
            println searchHit.fields.shopurl?.value
            println searchHit.fields.kategorie?.value
            println searchHit.fields.herkunftsland?.value
            println searchHit.fields.anbauregion?.value
            println searchHit.fields.weingut?.value
            println searchHit.fields.preiseinheit?.value
        }
    }

    private getESClient() {
        Client retVal
        // clustername is defined in the elastic file elasticsearch.yml
        Settings settings = ImmutableSettings.settingsBuilder().put("cluster.name", "---ClusterName---").build()
        TransportClient transportClient = new TransportClient(settings)
        retVal = transportClient.addTransportAddress(new InetSocketTransportAddress("localhost", 9300))
        return retVal
    }
}

Eindrücke von der GGX in London

2014-12-15T23:46:00.000+01:00

Vom 11. bis 12.12. konnte ich an der Groovy & Grails Exchange in London teilnehmen. Im Vergleich zum Jahr 2012 hatte das Programm weniger Besucher angezogen und bei den Keynotes blieben einige Stühle leer. Dies hatte aber nichts mit der Qualität des Programm zu tun. Es waren fast alle Core-Entwickler von Groovy und Grails mit Vorträgen präsent.

Den Reigen eröffnete Guillaume Laforge, der die aktuelle Groovy Version vorstellte und auf die Roadmap für die Zukunft einging. Neben Anpassungen für Java8 sind in der Version 2.3 vor allen Dingen die Themen Traits sowie die schnelle Implementierung des JSON-Parsers erwähnenswert.

Anschließend gab es über den Tag verteilt zwei parallele Session mit verschiedenen Themengebieten. Besonders interessant fand ich den Vortrag von Geb-Lead Marcin Erdmann über das Betreuen von Open-Source-Projekten. Er zeigte auf, dass ein erfolgreiches Open-Source-Projekt viel mehr erfordert wie das reine Programmieren. Die Details können im aufgezeichneten Video entnommen werden.

Bei der Panel-Diskussion am Ende des ersten Tages stellten sich die Kern-Entwickler den Fragen des Plenums. Es wurde unter anderem darüber diskutiert, warum die Frameworks Geb und Spock noch nicht in der Version 1.0 vorliegen. Beide Frameworks sind seit Jahren stabil und können nach mehrheitlicher Meinung schon längst im Status eines Major-Releases sein. Dieser psychologische Schritt würde einen zusätzlichen Schub für Groovy und die Frameworks selbst bedeuten, da damit auch der Einsatz in Unternehmen einfacher zu vertreten sein wird. Wir dürfen gespannt sein, ob sich in den nächsten zwei Monaten hierzu etwas tut.

Der zweite Tag wurde von Graeme Rocher mit seiner Keynote zu Grails 3.0 eröffnet. Vermutlich schon im Januar 2015 wird der erste Meilenstein verfügbar sein. Das neue Grails-Release wird eng mit Springboot verzahnt sein und damit auch die dort verfügbaren Features einfach einbinden können. Eine weitere große Umstellung wird das Build-System sein, das zukünftig auf Gradle basieren wird. Damit dürfte eine Integration mit Entwicklungsumgebungen deutlich einfacher sein.

Ein weiteres Highlight am zweiten Tag war das testgetriebene Vorgehen beim Entwicklen einer Springboot-Applikation mit dem Einsatz des Test-Frameworks Cucumber. Hierbei wurde innerhalb von 45 Minuten eine kleine auf Springboot basierende Anwendung entwickelt.

Ich konnte während der zwei Tage in London wieder einige noch nicht bekannte Dinge aus dem Groovy-Öko-System aufschnappen, die sich in dem ein oder anderen Projekt sinnvoll einsetzen lassen werden.

Wie macht man eine Microsoft-Access-Datenbank mit Grails webfähig?

2014-05-19T18:58:00.001+02:00

In einer aktuellen Kundensituation wurden wir angefragt, ob es machbar sei, eine Microsoft-Access-Datenbank mit Hilfe von Grails in eine Web-Applikation zu migrieren. Wir setzen seit Jahren das Grails-Framework erfolgreich ein und einigten uns mit dem Kunden darauf, dies im Rahmen eines Proof-Of-Concepts zu beweisen.

Migration von Microsft-Access nach Microsoft SQL-Server

Die Northwind-Access-Datenbank benutzten wir für unseren Test. Leider ist diese aktuell als .mdb-Datei äußerst schwer zu finden. Als SQL-Skript kann man sie bspw. von hier [1] heruntergeladen. Wir wurden schließlich doch noch fündig [2]. Der MDB-Viewer [3] eignet sich, um die Tabellen anzuschauen. Es ist indes besser, die MS-Access Runtime inkl. Viewer zu installieren [4]. Für den Import der MS-Acess-Db gibt es verschiedene Tools. Hierbei ist darauf zu achten, dass die Relationen (Kardinalitäten) zwischen den Tabellen mit importiert werden. Hierfür bietet sich der Microsoft SQL Server Migration Assistant for Access an. Diesen haben wir nicht mehr auf der Microsoft-Homepage gefunden, jedoch hier [5]. Der Import-Prozess ist selbsterklärend. Das Bild unten zeigt das Datenbank-Schema im SQL Server.

Reverse-Engineering der Grails-Applikation

Die Grails Applikation wurde mit dem Grails Database Reverse Engineering Plugin von Burt Beckwith [6] migriert. Der benötigte JDBC-Treiber (sqljdbc4.jar), der in das Grails- Lib-Verzeichnis kopiert werden muss, findest sich hier [7]. Das gesamte Grails-Projekt findet sich zu Lernzwecken auf unserem Github-Repository [8]. Dort ist es möglich nachzuschauen, welche Werte in der BuildConfig.groovy, Config.groovy und DataSource.groovy gesetzt wurden.

Das Bild unten zeigt das Grails-Domain-Modell. Es sieht analog zu obigem ER-Modell aus.

Folgendes sollte bei der Migration beachtet werden:

Leerzeichen aus Tabellennamen entfernen
Alle Attribute in Kleinbuchstaben wandeln
Umwandlung von Serializable in String
M:N Relationen müssen potentiell manuell aufgelöst werden
Die Tabellenspalten werden durch das Grails-Scaffolding zufällig ausgewählt und können später angepasst werden
Etwaige Business-Logic, die in MS-Access implementiert wurde kann nicht automatisch migriert werden

Fazit

Das Bild unten zeigt die MS-Access-Northwind-Datenbank im Original und darunter die migrierte Grails Applikation.

Mit dem Plugin ist es ausgesprochen einfach, eine Microsoft-Access-Datenbank in eine Grails-Applikation zu wandeln. Obige Screenshots zeigen meines Erachtens sehr ausdrucksstark das gelungene Ergebnis.

Links

[1] http://northwinddatabase.codeplex.com/
[2] https://courseconference.wikispaces.com/file/detail/Northwind.mdb
[3] http://download.cnet.com/MDB-Viewer-Plus/3000-10254_4-75285626.html
[4] http://www.microsoft.com/de-de/download/details.aspx?id=10910
[5] http://microsoft-sql-server-migration-assistant.software.informer.com/
[6] http://grails-plugins.github.io/grails-db-reverse-engineer/
[7] http://www.microsoft.com/de-de/download/details.aspx?id=11774
[8] https://github.com/exensio/northwind

Erster Java Saxony Day in Dresden

2014-04-07T23:15:00.002+02:00

Nach der BED-Con ging es am darauffolgenden Tag gleich weiter zum Java Saxony Day in Dresden. Die Veranstaltung fand zum ersten Mal statt und wurde von der örtlichen Java User Gruppe organisiert. Mit 4 parallelen Tracks und einigen Ausstellern im Forum wurde viel geboten.

Mein Vortrag "Grails - schneller zum Ziel - für Enterprise Applikationen" war mit ca. 40-50 Personen erfreulich gut besucht. Auch wenn der Hype um Grails etwas zurückgegangen ist , zeigten mir die anschließenden Fragen, dass dieses Thema weiterhin von Interesse für die Java-Welt ist.

Von den wenigen Sessions, die ich selbst hören durfte, gefielen mir besonders "Java 8 Streams - How to Kick Ass with Lambdas" sowie "RESTful Services mit Dropwizard".

Die Veranstaltung wurde perfekt organisiert und die Resonanz von den Teilnehmern, mit denen ich sprechen konnte, fiel durchweg positiv aus.
Insofern wäre es schön, wenn der Java Saxony Day auch im nächsten Jahr stattfindet.

Umsetzung von Enterprise Applikationen mit Grails (Teil 3)

2014-02-06T20:12:00.001+01:00

Nachdem die ersten beiden Teile Grails bzw. Enterprise Applikationen separat betrachtet haben, geht der letzte Teil auf beide Seiten im Zusammenhang ein. Aus diesem Grund werden nachfolgend einige Bereiche, die im Enterprise-Umfeld relevant sind im Zusammenhang mit Grails näher beleuchtet.

Produktivbetrieb

Für die Entwicklung wird, wie bereits im 1. Beitrag erwähnt, Tomcat benutzt. In größeren Unternehmen ist in der Regel der Laufzeit-Container jedoch vorgegeben und es kommen vor allem kommerzielle Server wie bspw. Websphere oder Weblogic zum Einsatz. Da für den Wirkbetrieb ein WAR-Archiv erzeugt wird, kann Grails auf sämtlichen Servlet-Engines und Applikations-Servern betrieben werden. Clustering zur Erhöhung der Ausfallsicherheit ist dank der Verteilung als WAR-Archiv mit Grails problemlos möglich. Abhängig von den Anforderungen mag Load-Balancing mit und ohne Session-Replication eingesetzt werden [1].
Im Produktivbetrieb sind Monitoring-Aktivitäten unumgänglich. Zusätzlich zu den Standardmonitoring-Möglichkeiten von WAR-Archiven können von der Applikation über MBeans Informationen exportiert werden und diese mittels JMX abgefragt werden.

Konfigurationsmöglichkeiten

Existieren mehrere Umgebungen, wie Test-, Integrations-, Produktionsumgebung, so ist das Auslagern von Konfigurationsparametern sinnvoll. Außerdem sind damit Anpassungen ohne ein neues Deployment möglich.
Hierfür unterstützt Grails JNDI. Hiermit können bspw. die Werte für den Datenbankzugriff oder auch des Mail-Servers aus dem Laufzeit-Container gelesen und ebenso dort angepasst werden. Für das Mail-Plugin ist diese Konfiguration, wie im untenstehenden Codeausschnitt dargestellt, denkbar einfach.


grails {
     mail {
          jndiName = 'TW_DEMO_MAIL_SESSION'
          disabled = false
     }
     mail.default.from = 'noReply@twitter-demo.de'
}

Eine weitere Alternative sind Konfigurationsdateien, die über den Klassenpfad oder ein relatives Verzeichnis eingelesen werden.

Security

In Unternehmen erfolgt die Benutzer- und Rollen-Verwaltung in vielen Fällen über LDAP-Server. Zum Zwecke der zentralen und einmaligen Pflege ist es sinnvoll, dass Software-Applikationen diese Services nutzen. Das Spring-Security-Plugin deckt für Grails-Anwendungen den kompletten Bereich der Authentifizierung und der Autorisierung ab.
Neben Datenbanken können genauso LDAP-Server angebunden werden. Wird ein Microsoft IIS der Grails-Applikation vorgeschaltet, ist eine Anbindung der passwortfreien integrierten Windows-Authentifizierung (ehemals NTLM) problemlos umsetzbar. Mit den diversen verfügbaren Aufsätzen für das Spring Security Plugin sind auch Authentifizierungsmechanismen für Twitter, Facebook und weitere andere Provider möglich. Durch die Erweiterbarkeit können gleichfalls eigene Authentifizierungs- und Autorisierungs-Mechanismen umgesetzt werden.

Integration mit Java und Drittsystemen

Mit der JVM als Basisplattform kann in Grails sämtlicher Java-Code ausgeführt und auch entsprechende JAR-Archive integriert werden. Sehr interessant ist die Integration von EJBs, um mit bestehenden Java-Systemen zu kommunizieren. Im nachfolgenden ist ein Szenario für den Zugriff auf ein Dokumenten-Management-System über EJB’s dargestellt.

Hierbei wird in Grails via Spring-Beans der JNDI-Zugriff in weniger als 5 Zeilen konfiguriert. Das JAR-Archiv mit den Java-Interfaces ist in beiden Applikationen vorhanden. Über die Spring-Bean können anschließend die in den Schnittstellen definierten Service-Methoden genutzt werden.
Häufig findet man in der Industrie Messaging-Systeme zur Interkommunikation und asynchronen Abarbeitung vor. Eine unkomplizierte Integrationsmöglichkeit für Drittsysteme bieten ebenfalls JSON und XML. Mit Hilfe von Groovy ist die Verarbeitung dieser Formate absolut einfach.

Robustheit des Systems

Die aus Java bekannten Exception-Mechanismen werden auch bei Grails eingesetzt und es können zentrale Fehlerseiten abhängig vom Fehler-Typ angezeigt werden. In den Services ist ein besonders feingranulares Transaktionshandling denkbar, um bedingt vom Anwendungsfall entsprechende Rollbacks zu initiieren. Es ist zu beachten, dass nur Unchecked Exceptions einen Rollback auslösen. Sind 2 Phase-Commits notwendig - falls z.B. mit Messaging und der DB innerhalb einer Transaktion gearbeitet wird, gibt es - wie in Grails üblich - wiederum ein Plugin, das eingebunden werden kann [2].

Tool- und Fullstack-Unterstützung

Unumgänglich ist im Enterprise-Umfeld eine ausreichende Tool-Unterstützung. Im Bereich der Entwicklungsumgebung ist die kommerzielle Version von IntelliJ ungemein fortschrittlich und unterstützt immer die aktuellsten Grails-Versionen. Mit den weit verbreiteten Open-Source Produkten Jenkins und Hudson stehen für Continuous Integration sehr ausgereifte Werkzeuge zur Verfügung. Für die in professionellen Projekten unumgänglichen automatisierten Tests bieten Spock und Geb die ideale Basis für Grails. Über die Continuous Integration Server wird auch mit den entsprechenden Grails-Plugins die Testabdeckung [3] oder die Codequalität [4] analysiert.

Große Code-Basis

Wie verhält sich Grails bei einer großen bzw. immer weiter wachsenden Code-Basis? Die bis heute von uns umgesetzten Projekte zeigten keine negativen Performance-Einbußen. Bei steigender Code-Basis verlängert sich natürlich die Zeit für Neu-Kompilierungen. Im Zusammenspiel mit Datenbanken und Datenmengen konnten bei den bisher in Produktion befindlichen Applikationen Erfahrungen mit bis zu 20 GB gesammelt werden und auch hier gab es keinerlei Anzeichen von Problemen.
Aus Architektur-Sicht ist es bei umfangreicheren Vorhaben sinnvoll, nicht alles in einem einzigen Grails-Projekt umzusetzen, sondern vielmehr nach fachlichen Gesichtspunkten die Anwendung zu schneiden und Teile über den Plugin-Mechanismus auszulagern.

Fazit

Da die Anforderungs-Szenarien an Enterprise-Anwendungen breitgefächert und umfangreich sind, kann dieser Beitrag nur einige wesentliche Bereiche beleuchten. Es ist jedoch deutlich geworden, dass Grails auf Grund der engen Beziehung zu Java Ansprüche von Enterprise-Applikationen in vielen Fällen erfüllen kann.
Durch die zahlreichen Plugins können weitere Funktionalitäten abgedeckt werden oder bei Bedarf selbst mit einem eigenen Plugin implementiert werden.

Links

[1] Grails in Produktion – mit Apache, Tomcat und MySQL
[2] Atomikos
[3] Test Code Coverage Plugin
[4] Codenarc

Umsetzung von Enterprise Applikationen mit Grails (Teil 2)

2014-01-29T08:45:00.001+01:00

Einführung

Nachdem der 1. Teil dieser Serie einen kurzen Überblick zu Grails gab, wird in diesem Teil auf Anforderungen von Enterprise Applikationen eingegangen.

Definition von Enterprise Applikationen

Eine eindeutige Definition von Enterprise Applikationen ist in der Literatur nicht zu finden. Auch in Wikipedia [1] findet sich nur eine relativ breitgefächerte Beschreibung. In der Regel wird unter Enterprise Applikationen Software verstanden, die bzgl. der Datenmengen, der Verarbeitungslogik, der Integration von Drittsystemen oder der Oberfläche komplex ist.

Neben den erwähnten Charakteristiken weisen Enterprise Applikationen oftmals auch die nachfolgend aufgeführten Merkmale bzw. ein Teil dieser Merkmale auf:

Integration von Legacy-Systemen
Integration mit anderen Geschäftsbereichen / Organisationen
Zugriff auf relationale Datenbanken
Distributed Computing
Unterstützung von verteilten Transaktionen
Datenaustausch zwischen heterogenen Systemen
Einsatz von Message-Oriented Middleware
Verwendung von Directory und Naming Services
Inter-Kommunikation (Mail, Dokumente, ...)
Unterstützung von komplexen Security-Anforderungen
Zentrale Administration und Wartung

Nicht funktionale Anforderungen an Enterprise Applikationen

Für die Umsetzung von Enterprise Anforderungen müssen Applikationen in der Lage sein, eine Vielzahl von nicht funktionalen Anforderungen zu erfüllen. Nachfolgend findet sich eine Auswahl relevanter Kriterien:

Betrieb und Monitoring
Verfügbarkeit
Ausfallsicherheit
Wartbarkeit und Erweiterbarkeit über mehrere Jahre
Unterstützung komplexer Authentifizierungs- und Autorisierungs-Mechanismen
Kein Daten-Verlust bzw. Korruption bei Fehlern
Testbarkeit

Ausblick

Nach dem in diesem Teil kurz auf Enterprise Applikationen im Allgemeinen eingegangen wurde, beschäftigt sich der nächste und letzte Teil dieser Serie wie solche Anforderungen mit Grails umgesetzt werden können.

Links

[1] Definition Enterprise Software in Wikipedia

Unidirectional many-to-many relationships in Grails, and how it could affect the batch performance decisively.

2013-12-18T16:17:00.000+01:00

Mapping business domains using GORM (Grails Object Relational Mapping) is in most cases straightforward and uncomplicated to implement.
The documented way to map many-to-many relationships in Grails is to define a hasMany on both sides of the relationship AND having a belongsTo on the owned side: [1]

class Fee {
    static hasMany = [foos:Foo]
    ...
}

class Foo {
    static hasMany = [fees:Fee]
    static belongsTo = Fee
    ...
}

The example given above demonstrates a bidirectional many-to-many association between Fee and Foo. Both sides of the relationship are holding references to the other side. This might be the most common use case.

What if you don't really need references from both sides, but only from one side (unidirectional)? Someone could ask - "Does it make sense to have unidirectional many-to-many? The references are per default lazy loaded and therefore seems to be harmless." - Not in a particular situation.

In a project that is in production since years we have batch jobs for persisting a large number of domain entities into the database. Thanks to the approaches introduced by Ted Naleid [2] the performance of the batches was fine. We are using the service method cleanUpGorm() at regular intervals to release memory usage by the hibernate session:

def cleanUpGorm() {
    def session = sessionFactory.currentSession
    session.flush()
    session.clear()
    propertyInstanceMap.get().clear()
}

Consider the following situation:

There is a many-to-many relationship between Fee and Foo
A Foo instance, let's say "foo-1" is referenced by 200,000 Fee instances
Batch has inserted some more Fee instances which are also referenced to "foo-1"

In this case, the call to session.clear() was taking minutes after the batch process has inserted 30 Fee instances. With such a performance the batch won't be finished within the time window. We used to have a much better performance and the problem must be fixed for the total changes on that branch to be released.

One of the solutions here is to have a unidirectional many-to-many relationship from Fee to Foo. The result in the giving situation was a performance boost up to 10x faster. The following example shows how to achieve it with GORM:

class Fee {
    static hasMany = [foos:Foo]
    ...
}

class Foo {
    static hasMany = [Fee]
    ...
}

Fee is the owning side and is responsable for persisting relationships. Foo is the owned side and do not have any references to Fee.

Conclusion

Unidirectional many-to-many relationships is supported by hibernate [3] and Grails.
The GORM keyword belongsTo is mandatory for bidirectional, but not for unidirectional many-to-many relationships.
To achieve a unidirectional many-to-many you should define a "hasMany" without references and without belongsTo on the owned side.

Links

[1] http://grails.org/doc/2.3.x/guide/GORM.html#manyToMany
[2] http://naleid.com/blog/2009/10/01/batch-import-performance-with-grails-and-mysql/
[3] http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/associations.html#assoc-unidirectional-join-m2m

Enterprise-2.0-Portale mit Grails − geht das?

2013-12-18T12:26:00.003+01:00

Unsere Kollegen Manuel Breitfeld und Tobias Kraft haben zu diesem Thema einen Artikel in der aktuellen Ausgabe 01/ 2014 der Zeitschrift JavaAktuell veröffentlicht.

In dieser Veröffentlichung beschreiben sie äußerst ausführlich die Grundlagen, die die Basis unseres Claretportal-Frameworks bilden.

Folgende Aspekte werden beleuchtet:

Was ist ein Portal?
Grails als Basis-Technologie
Schnelles Entwickeln mit Grails
Integration mit Groovy und Grails
Grails für Portale
Umsetzung von Portal-Modulen

Tagging
Enterprise-Suche
Content/Document Management System
Web 2.0 Funktionalitäten

Personalisierung und Berechtigungen

Der Sonderdruck kann von der exensio Homepage heruntergeladen werden.

Umsetzung von Enterprise Applikationen mit Grails (Teil 1)

2013-12-09T11:26:00.001+01:00

Das Framework Grails ist bereits seit einigen Jahren auf dem Markt und es stellt sich die Frage nach den Einsatzbereichen. Insbesondere ist interessant, inwiefern es sich für Applikationen im Unternehmensbereich eignet, oder ob es nur für die "kleine schnelle Lösung" seine Daseinsberechtigung hat.

In dieser dreiteiligen Blog-Serie werden die folgenden Themen beleuchtet:

Grails im Überblick (Teil 1)
Anforderungen an Enterprise Applikationen (Teil 2)
Enterprise Applikationen mit Grails (Teil 3)

In unserem Blog haben wir schon vielfach zu technischen Themen über Grails berichtet. In diesem 1. Teil wird nochmal auf einige grundlegende Features eingegangen.

Grails im Überblick

Bereits im Jahr 2005 startete das Projekt Grails, inspiriert im Wesentlichen durch die Konzepte von Ruby on Rails. Zu dieser Zeit war die Entwicklung von JEE-Applikationen schwergewichtig und es floss viel Arbeit in die Programmierung von Glue Code. Mit Hilfe von Spring und Neuerungen im JEE-Standard hat sich dies natürlich in den letzten Jahren massiv geändert. Als Fullstack-Webframework deckt Grails das gesamte Spektrum des Entwickelns, Testens und der Produktivsetzung einer Webapplikation ab. Es hat insbesondere das Ziel, die Komplexität bei der Erstellung von Webapplikationen zu reduzieren, basiert jedoch trotzdem auf etablierten Java-Technologien.

Zwischenzeitlich werden in regelmäßigen Abständen jährlich Minor- und Major-Releases freigegeben. Das nächste größere Release, die Version 3.0, legt seinen Schwerpunkt auf die Modularisierung und die Verschmelzung mit Gradle als Build-System. Es soll neben Servlet-Containern auch eine bessere Integration für Frameworks wie bspw. Netty geben.
Grails ist ein Open-Source-Projekt und steht unter der Apache Lizenz 2.0, so dass keine Lizenzkosten bei der Verwendung anfallen. Die Weiterentwicklung und Pflege wird wesentlich von der Firma Pivotal, eine ausgelagerte Tochterfirma von VMWare, vorangetrieben.

Groovy

Die Basis von Grails bildet die Sprache Groovy. Hierbei handelt es sich um eine nicht typisierte Programmiersprache, die eine JVM benötigt und es oftmals ermöglicht, Anweisungen - im Vergleich zu Java - kürzer auszudrücken. Das folgende Code-Beispiel zeigt, wie einfach Listen definiert und wie sie mit Hilfe der Groovy-Closure findAll für Collections verarbeitet werden können. Closures sind das Pendant zu den in Java8 erscheinenden Lambda-Expressions.

Ab Version 2 von Groovy kann bei Bedarf im Code mit der Annotation @TypeChecked die Typsicherheit gewährleistet werden. Dies ist beispielsweise für öffentlich verwendete Schnittstellen interessant.
In der Vergangenheit gab es bei Groovy öfters Kritik bzgl. der Performance. Hier wurden in den zurückliegenden Releases wesentliche Optimierungen eingearbeitet und durch explizites Setzen der ebenfalls ab Version 2 verfügbaren Annotation @CompileStatic können zusätzliche Performance-Gewinne erzielt werden.

Schlüsselkonzepte

Wesentliche Schlüsselkonzepte von Grails sind DRY (Don’t repeat yourself) und CoC (Convention over Configuration). Diese Prinzipien erlauben dem Entwickler eine stärkere Konzentration auf die Business-Logik und auch der Code wird übersichtlicher. Nachfolgend werden einige Beispiele aufgeführt:

Logging kann auf Anhieb verwendet werden ohne vorherige Instanziierung
Zugriff auf Services von Controllern erfolgt durch Definition einer Klassen-Variablen, die den gleichen Namen wie der Service hat
Domain-Klassen, das Pendant zu den Entity Beans, liegen im Verzeichnis grails-app/domain. Sie werden automatisch mit der DB gemappt und es kann direkt damit gearbeitet werden, ohne dass ein EntityManager oder Ähnliches benötigt wird

Die Flexibilität geht mit CoC aber nicht verloren. Es bedeutet viel mehr, dass der Standard vordefiniert ist, man bei Bedarf jedoch auch davon abweichen kann.

Einfacher Start mit Grails

Besonders der Einstieg in Grails gestaltet sich einfach. Für den Start mit Grails wird von der Homepage die aktuelle Version heruntergeladen und entpackt. Da Grails auf der JVM aufsetzt, muss nichts als das JDK vorhanden, sowie über die Umgebungsvariable eingebunden sein. Es ist möglich, mit einem gewöhnlichen Texteditor loszulegen. Das Basisprojekt wie auch einzelne Code-Fragmente können mit der Anweisung grails und daran angehängten Optionen erstellt werden. Der Befehl grails create-domain-class com.exensio.Project erzeugt die entsprechende Domain-Klasse Project für die Interaktion mit der Persistenzschicht. Die Applikation wird mit dem Befehl grails run-app auf dem eingebetteten Tomcat-Server gestartet. Alternativ kann ebenfalls mit den später vorgestellten Plugins Jetty als Laufzeitumgebung ausgewählt werden. Während der gesamten Entwicklungszeit und auch beim Ausführen von Tests wird gegen den eingebauten Tomcat-Server entwickelt.

Ein weiteres Feature, das den Einstieg erleichtert, ist das sogenannte Scaffolding. Über Scaffolding können aus Domain-Klassen Controller und Views für die CRUD-Funktionalitäten erzeugt werden. Dieser Ansatz eignet sich hervorragend für das Rapid Prototyping, um bspw. dem Kunden zeitnah erste Ergebnisse zeigen und besprechen zu können. Es wird zwischen dynamischen und statischen Scaffolding unterschieden. Ersteres generiert den Code der Views und Controller immer zur Laufzeit aus Templates. Die statische Methode erstellt beide Komponenten einmalig und speichert sie in den entsprechenden Dateien. Damit kann der Source-Code im Nachhinein an die eigenen Bedürfnisse angepasst werden. Ändern sich Attribute in der Domain-Klasse, so müssen diese manuell in den erzeugten Dateien nachgezogen werden.

Bewährte Technologien

Grails setzt auf bewährte Technologien in seinem Technologiestack, wie die nachfolgende Grafik verdeutlicht. Neben der JVM ist Spring eine wesentliche Basistechnologie, die in allen Bereichen eingesetzt wird. Außer JEE-Standards und Hibernate für die Persistenz kommen mit JUnit und Ivy auch im Test- und Build-Zyklus weit verbreitete Technologien zum Einsatz.

Kurz eingegangen werden soll hier auf GORM, das die Persistenzschicht kapselt und entsprechende Funktionalitäten für einen schnellen Zugriff auf diese bereitstellt. Hibernate ist der standardmäßig konfigurierte OR-Mapper. Es ist aber auch möglich GORM mit NOSQL-Datenbanken wie MongoDB zu verwenden.

Insbesondere das Erstellen von Datenbankabfragen ist mit GORM sehr komfortabel möglich. Über die Domain-Klasse können direkt Finder-Methoden mit bis zu drei Abfrage-Kriterien erstellt werden, wie das nachfolgende Beispiel zeigt. Ein Zweites zeigt die sogenannten Where-Queries, die Abfragen erlauben mit in Groovy-Code formulierten Bedingungen.


// Finde Methode mit zwei AND verknüpften Attributen
Book.findAllByTitleAndAuthor('Grails in Action', authorInstance)
// Where-Query
def query = Book.where{ 
  year(published) == 2013 && title =~ 'grails'
}
def results = query.list(sort: 'title')

Plugins

Ein zusätzlicher wichtiger Baustein sind Plugins, über die weitere Funktionalitäten hinzugefügt werden können. Derzeit stehen fast 800 Plugins für Grails bereit. Plugins bieten hauptsächlich Erweiterungen für folgende Bereiche:

Frontend (z.B. JQuery, AngularJS)
Integration von Drittsystemen (z.B. Suchmaschinen, BPMN-Maschinen)
Fachliche Funktionalitäten (z.B. Tagging, Voting)
Persistenzschicht (z.B. neo4j, MongoDB)
Nichtfunktionale Erweiterungen (z.B. Auditing zum Messen von Antwortzeiten)

Neben der Wiederverwendbarkeit sind als wesentliche Vorteile von Plugins eine einfache Installation und Möglichkeiten zur Modularisierung anzusehen.

Ausblick

Nach einem Blick aus der Vogelperspektive auf das Grails-Framework, fokusieren sich die beiden folgenden Beiträge dieser Serie auf Enterprise Applikationen.

Vorträge von exensio im Jahr 2013 zum Thema Grails

2013-11-22T12:04:00.000+01:00

In diesem Blogpost möchte ich kurz auf Vorträge von uns zum Thema Grails hinweisen. Besonderer Dank gilt hier unserem Kollegen Tobias Kraft, der die meisten Vorträge gehalten hat.

Kann ich mit Grails Enterprise Applikationen umsetzen? from Tobias Kraft

Enterprise 2.0 Portale mit Grails. Geht das? from Tobias Kraft

Grails im Überblick und in der Praxis from Tobias Kraft

Word-Dateien aus Templates mit FreeMarker in Grails erstellen

2013-10-10T22:02:00.000+02:00

In einem aktuellen Kundenprojekt sollen dynamisch erzeugte Word-Dokumente zum Download angeboten werden. Dabei sollen die Word-Dokumente genau wie die Vorlage des Kunden aussehen und an den entsprechenden Stellen mit Werten aus der Applikation gefüllt sein.
In diesem konkreten Fall erzeugt die Applikation aus einer Fülle an Daten ein Übersichtsdokument in Word - ganz nach dem Template des Kunden.
Dieser Blog-Post soll zeigen, wie einfach die Erstellung eines Word-Dokuments - auch unter Verwendung einer Vorlage - mittlerweile ist.

Word und Office Open XML

Das "neue" Word-Format "docx" ist im Prinzip eine zip-Datei, die verschiedene Ordner und Dateien enthält [1]. Jede docx-Datei kann entpackt, manuell verändert und wieder gepackt werden. Dabei findet sich der Inhalt des Dokuments maßgeblich in der XML-Datei "word/document.xml" wieder.

FreeMarker Templates

FreeMarker Templates [2] sind Textdateien, in denen - im einfachsten Fall - Variablen durch Werte ersetzt werden. Um also ein bestimmtes Word-Dokument in ein FreeMarker Template umzuwandeln, genügen folgende Schritte:

Word-Datei als docx speichern und mit einem Zip-Porgramm entpacken
Die Datei "word/document.xml" in einem Texteditor öffnen und FreeMarker-Variablen in Form von ${titel}, ${datum} etc. an den gewünschten Stellen einfügen
Die in Schritt 1 entstandene Ordnerstruktur wieder zu einem docx-Dokument zippen.

Implementierung in Groovy / Grails

Die Schritte, um jedes beliebige Template als Word-Datei anbieten zu können, sind sehr einfach. Der Ablauf ist wie folgt:

docx-Template vom ClassPath in ein temporäres Verzeichnis kopieren und entzippen

// Specify path to template in classpath
def applicationContext = grailsApplication.mainContext
def basePath = applicationContext.getResource("/").getFile().toString()
def source = new File("${basePath}/../src/groovy/com/exensio/templates/Project_Summary.docx")

// Specify destination file name and path (uses temp directory)
def destinationFile = File.createTempFile("Project_Summary", ".zip")
def destinationFolderName = FilenameUtils.getBaseName(destinationFile.name)
def destinationFolder = new File(destinationFile.getParent() + "/" + destinationFolderName)
destinationFolder.mkdir()

// Copy the Word template to a temp file and unzip it to the temp folder
FileUtils.copyFile(source, destinationFile)
def ant = new AntBuilder();
ant.unzip(src: destinationFile, dest:destinationFolder,  overwrite:"true")

XML-Datei mit FreeMarker verarbeiten

// Specify FreeMarker to load from temp directory
def freeMarkerConfig = new Configuration()
freeMarkerConfig.setDefaultEncoding("utf-8")
def fileTemplateLoader = new FileTemplateLoader(new File(System.getProperty("java.io.tmpdir")))
freeMarkerConfig.setTemplateLoader(fileTemplateLoader);

// Load the template (destinationFolderName has to be relative to the temp directory!)
def template = freeMarkerConfig.getTemplate(destinationFolderName + "/word/document.xml")

// Process template and write it to itself
def writer = new FileWriter(new File(destinationFolder.getAbsolutePath() + "/word/document.xml")
template.process(model, writer);

Word-Dokument als docx zippen und zum Download anbieten

// Zip the docx folder to the final docx file
ant.zip(destfile: destinationFile, basedir:destinationFolder)

// Send file as stream to response output stream
response.setContentType("application/vnd.openxmlformats-officedocument.wordprocessingml.document")
response.setHeader("Content-Disposition", "attachment; filename=\"Project_Summary.docx\"");
def inputStream = new FileInputStream(destinationFile)
IOUtils.copy(inputStream, response.outputStream)

Streams schließen und temporäre Dateien/Ordner aufräumen

finally {
 IOUtils.closeQuietly(response.outputStream)
 IOUtils.closeQuietly(inputStream)
 FileUtils.deleteQuietly(destinationFile)
 FileUtils.deleteQuietly(destinationFolder)
}

Fazit

Das Erstellen echter Word-Dokumente ist aufgrund des XML-basierten Standards Office Open XML relativ einfach geworden. Mit der Kombination von Grails und FreeMarker lassen sich auch komplizierte Formatvorlagen zügig umsetzen.

Allerdings: Je komplizierter das Vorlagedokument ist, desto aufwändiger ist auch die Erstellung des FreeMarker-Templates. Besonders übersichtlich ist die "document.xml"-Datei nämlich nicht.

Links

[1] http://de.wikipedia.org/wiki/Office_Open_XML
[2] http://freemarker.org/

Java Forum Stuttgart - wir waren als Aussteller und Vortragende mit dabei

2013-07-07T15:47:00.000+02:00

Am 04. Juli fand wieder das Java Forum in Stuttgart statt. Das JFS ist eine eintägige Konferenz rund um das Thema Java. exensio war dieses Mal als Aussteller mit dabei. Des Weiteren haben unsere Kollegen Manuel Breitfeld und Tobias Kraft einen Vortrag mit dem Titel »Enterprise 2.0 Portale mit Grails. Geht das?« gehalten. Der Vortag kann von hier als PDF heruntergeladen werden.

Besuch der gr8conf in Kopenhagen

2013-05-30T12:51:00.000+02:00

Bereits zum fünften Mal wurde die gr8conf in Kopenhagen abgehalten. Die Konferenz beschäftigt sich mit Themen rund um die Technologien Groovy und Grails.

University Day

In Kopenhagen wurde man am ersten Tag mit Dauerregen begrüßt, also der ideale Start um beim sogenannten "University Day" nicht anderweitig abgelenkt zur werden. Für mich standen drei Workshops auf dem Plan.

Async Grails Workshop

Nach einem zögerlichen Start aufgrund von Netzwerkproblemen stellte Collin Harrington verschiedene Möglichkeiten zur Realisierung von asynchronen Anwendungsfällen vor. Es wurden exemplarisch einige mit dem Springframework zur Verfügung gestellten Event-Mechanismen umgesetzt, wie beispielsweise ApplicationEvents oder SecurityEvents. Als weitere Möglichkeiten wurde die Nutzung des Events Push Plugin für Grails sowie Servlet 3.0 vorgestellt.

GPars Workshop

Nach dem Mittagessen beschäftigte sich der nächste Workshop mit der parallelen Programmierung unter GPars ab. Es wurden viele Code-Beispiele vorgeführt, die anschaulich zeigten wie GPars die Entwicklung von parallelen Tasks durch Abstraktion vereinfacht.

Unleashing the power of AST transformations workshop

Auch beim letzten Workshop des Tages gab es viele Code-Beispiele und praktische Tipps für den Umgang mit AST-Transformationen. Der Workshop zeigte insbesondere auf, dass AST-Transformationen nicht nur für Frameworks geeignet sind, sondern auch in Kundenprojekten einen Mehrwert bringen können.

Hackergarten

Nach Pizza am Buffet ging es am Abend mit dem Hackergarten weiter. Ziel von Hackergarten ist es gemeinsam in kleineren Gruppen einen Beitrag zu einem Open-Source-Projekt innerhalb eines Abends zu leisten. Ich schloss mich der Gruppe für das Ratpack-Framework an, bei der es um die Erweiterung der Framework-Tests ging.

Erster Konferenztag

Die Konferenz startete nach der Begrüßung mit der Keynote "The rise and fall of empires: Lessons for language designers and programmers" von Dr. Venkat Subramaniam. Er hinterlegte in einem sehr unterhaltsamen Vortrag seine Thesen mit Beispielen aus der Weltgeschichte, so dass man nebenbei noch Gast einer Vorlesung in Geschichte sein durfte.

Using Static Analysis with Grails

Der erste Vortrag des Tages stellte statische Code-Analyse mit Hilfe von Jenkins vor. Jenkins ist auch der von exensio verwendete Continuous Integration Server. Der Vortrag zeigte, dass exensio bzgl. der Continuous Integration auf dem aktuellsten Stand ist.

Raspberry Pi à la GroovyFX

exensio hat wie in diesem Blog bereits berichtet ebenfalls schon Projekte mit Raspberry PI umgesetzt, allerdings mit einem anderen Technlogie-Stack. Neben Besonderheiten des Raspberry PI ging Stephen Chin auf Umsetzung der animierten GroovyFX-Applikation ein. Die Applikation wurde während der Konferenz über den HDMI-Ausgang des Raspberry PI an einen Monitor angeschlossen und zeigte den Besuchern am Info-Stand Details zu den Sessions und Sprechern der gr8conf.

Road to Grails 3.0

Graeme Rocher ging in seinem Vortrag neben Neuerungen in den aktuellen Releases auch auf das nächste Hauptrelease 3.0 ein. Neben Gradle für Build- und Dependency-Management ist vor allem die Modularisierung von Grails ein wichtiges Hauptthema.

Functional Programming in Groovy

Funktionale Programmierung mit Life-Coding vom Feinsten zeigte Keynote-Speaker Dr. Subramaniam in seinem Vortrag. Es wurden zwar keine unbekannten Sachen gezeigt, aber es wurde einem wieder vieles ins Gedächtnis gerufen auf das man beim Programmieren achten sollte.

Building Grails apps with Gradle

Luke Delay stellte für die Grails Version 2.3 vor, wie der Build-Prozess sowie das Depedency-Management über Gradle erfolgen kann. Wie bereits erwähnt wird ab Grails 3.0 der Build-Mechanismus komplett auf Gradle umgestellt. Allerdings wird diese Lösung dann komplett neu sein und nicht auf der Version von Grails 2.3 aufsetzen. Deshalb scheint sich die Umstellung des Builds in 2.3 auf Gradle nur für größere bzw. Multi-Projekte einen entsprechenden Mehrwert zu bieten.

Grails Under The Hood

Im letzten Vortrag des Tages ging Graeme Rocher detailliert auf die Struktur des Grails-Core-Projektes ein. Er stellte einige ausgewählte Details des Source-Codes vor.

Zweiter Konferenztag

Auch am zweiten Konferenztag gab es wieder jeweils zwei parallele Sessions zur Auswahl. Ich habe die nachfolgenden Sessions besucht.

Is Groovy as Fast as Java?

Der Vortragstitel bietet natürlich sofort einiges an Gesprächsstoff. Russel Winder hat die Performance anhand eines Code-Beispiels verglichen. Iterativ hat er anschließend die Performance des Groovy-Programms verbessert. Am Ende war das Groovy-Programm sogar etwas schneller wie der Java-Code, wobei dies natürlich keine allgemein gültige Aussage ist.

Speed up your development: GroovyServ and Grails Improx Plugin

Bei diesem Vortrag wurden zwei Lösungen vorgestellt, die die Produktivität während der Entwicklung steigern sollen. Durch eine interne serverseitige Lösung wird mit GroovyServ die Startzeit von Groovy minimiert. Gleiches gilt für das Grails Improx Plugin bei der die Startzeit von Tests minimiert wird. Insbesondere Integration Tests haben bei Grails eine relativ lange Startzeit, da der Embedded Server hochgefahren wird. Hier verspricht das Improx Plugin beim mehrmaligen Durchführen von Tests Verbesserung.

Spring 4 and Groovy 2

Jürgen Höller, der Projekt-Manager des Springframeworks, gab Einblicke in die Neuerungen von Spring 4. Interessant ist vor allen Dingen die geplante Unterstützung von Groovy in diesem Release. Damit wäre es beispielsweise möglich Spring-Konfigurationen über Groovy zu erstellen.

Trench code

In diesem Vortrag wurden einige Best Practices aus einem größeren Grails-Projekt vorgestellt. Hierzu zählten unter anderem die Verwendung von Abstrakten Domain-Klasse oder Hibernate-Filter für SQL-Abfragen. Besonders interessant war der Einsatz von Scaffolding im Produktiv-Betrieb. In dem Projekt wurden die meisten Controller-Klassen zur Laufzeit über Scaffolding erzeugt.

Ratpack

Das schon erwähnte Ratpack-Framework ist ein leichtgewichtiges Framework, um Applikationen zu bauen. Basis zur Kommunikation ist Netty, so dass hier eine asynchrone Abarbeitung der Reqeusts erfolgt. Ratpack läuft als Standalone-Applikation und nicht in einem Servlet- bzw. JEE-Container.

Grails Transactions

Bei meinem letzten Vortrag als Zuhörer ging Burt Beckwith auf das Transaktions-Handling von Grails in der Tiefe ein. Bisher weniger bekannt ist wohl die Tatsache, dass es bereits seit längerem Unterstützung für "Two Phase Commits" in Form des Atomikos-Plugins gibt.

Fazit

Auch dieses Jahr hat sich die Reise nach Kopenhagen gelohnt. Es gibt viele Informationen über die aktuellen Entwicklungen und Trends aus den Bereichen Groovy und Grails von den Kern-Entwicklern der jeweiligen Projekte.

Aufbau einer Intranetsuche leicht gemacht, dank Open Source

2013-05-08T10:51:00.000+02:00

Jeder kennt vermutlich das folgende Szenario aus eigener Erfahrung: Vor längerer Zeit hat man an einem Projekt gearbeitet und sucht nun verzweifelt nach einem Dokument, in dem bspw. eine Schnittstelle fachlich spezifiziert wurde. Doch wo wurde das Dokument bloß von den Kollegen abgelegt?

Dieser Blogeintrag beschreibt die einfache Realisierung einer Suchanwendung im Intranet für Dokumente unterschiedlichster Dateiformate, die in einem SVN-Repository sowie auf zentralen Laufwerken abgelegt sind. Dies bedeutet also, dass die Suchanwendung Input aus verschiedenen Quellsystemen erhält.
Als Suchserver wird elasticsearch verwendet. Das Frontend für die Suche wurde mit Grails umgesetzt.

Indexieren der Dokumente

Zunächst ist es wichtig, die Dokumente zu indexieren und eine regelmäßige Aktualisierung des Indexes zu gewährleisten, um Änderungen an den Dokumenten in der Suche abbilden zu können.
Zur Indexierung der Laufwerke wird ManifoldCF in der Version 1.1.1 eingesetzt. ManifoldCF ist ein Open Source Projekt, dessen Ziel es ist, verschiedene Quellsysteme zur gemeinsamen Indices oder Repositories zu verbinden. ManifoldCF bietet einige Vorteile:

Im Idealfall ist kein eigener Code nötig, um geänderte Dokumente aufzufinden und diese zu indexieren
Unterstützung für eine Vielzahl von Quellsystemen, wie bspw. SharePoint oder zentrale Laufwerke
Nicht auf elasticsearch als Suchserver beschränkt; es ist eine Vielzahl sogenannter OutputConnectoren vorhanden, z.B. auch für Solr
Graphische Oberfläche wie in der nachfolgenden Grafik exemplarisch dargestellt zur leichteren Konfiguration der zu indexierenden Ordner, Planung der Ausführungszeitpunkte etc.)


ManifoldCF Oberfläche

Der in ManifoldCF bereits vorhandene Elasticsearch-Output-Connector wurde angepasst, da die vorhandene Implementierung für den Anwendungsfall nicht ausreichend geeignet war. Diese Anpassungen sind im Wesentlichen

Statt des attachment-Plugin von Elasticsearch übernimmt der Connector selbst die Analyse der Dokumente (unter Verwendung von Tika). Dadurch ist eine wesentlich feinere Kontrolle der im Index gespeicherten Informationen möglich.
Die Verbindung zum Elasticsearchserver wurde von einem HTTP-Client auf einen TransportClient geändert. Beim HTTP-Client treten einige Probleme mit Sonderzeichen, Zeilenumbrüchen etc. beim Senden der extrahierten Informationen an Elasticsearch auf.

Input aus den Quellsystemen

ManifoldCF ist derzeit nicht in der Lage SVN-Repositories direkt zu indexieren. Jedoch ist es möglich, Ordner im lokalen Dateisystem zu indexieren. Damit ist es möglich, das Repository auszuchecken und danach mit svn up regelmäßige Updates durchzuführen, um die ausgecheckten Dateien zu aktualisieren. Diese Dateien werden schließlich mit ManifoldCF indexiert.
Aus Performancegründen wurde diese Lösung jedoch verworfen. Wenn man svn up ausführt, so erhält man eine Liste mit allen hinzufügten, geänderten oder gelöschten Dateien sowie jeweils die Angabe, welcher Fall vorliegt.
Über eine separates kleines Javaprogramm die Ausgabe des svn-Updates eingelesen und nur die darin verzeichneten Dateien wird die entsprechende Aktion durchgeführt. Obwohl dieses Programm die Aktionen in mehreren Threads parallel ausführt, ist es nur etwa 150 Zeilen lang. Zur Analyse der Dokumente wird ein Teil des angepassten ManifoldCF-Codes, der oben beschrieben wurde, wiederverwendet.
Dieses Vorgehen erspart gegenüber ManifoldCF die Iteration über alle ausgecheckten Dateien, um neue, geänderte und gelöschte Dateien zu identifizieren. Da im Anwendungsfall die Anzahl der geänderten Dateien gegenüber der Gesamtzahl Dateien sehr klein ist, beschleunigt sich der Indexierungsprozess enorm. Der gesamte Vorgang wird über einen cronjob gesteuert. Wenn keine Änderungen vorliegen, ist die Dauer des Vorgangs im Wesentlichen identisch mit der Zeit, die svn up benötigt. Müssen dagegen alle oder fast alle Dokumente neu indexiert werden, so dauert der Vorgang etwa so lange wie mit oben beschriebenen ManifoldCF-basierten Ansatz.

Neben dem SVN-Repository wird als zweites Quellsystem das öffentliche Firmenlaufwerk indexiert. Hier existiert für ManifoldCF ein Standard-Konnektor, der lediglich über die ManifoldCF-Oberfläche konfiguriert werden muss.

Performance

ManifoldCF ist in der Lage, den Fileshare (ca. 70 000 Dateien) in etwa 15 Minuten nach Änderungen zu durchsuchen und diese zu indexieren. Wurden sehr viele Dokumente geändert oder hinzugefügt, so verlängert sich die Laufzeit.

Elasticsearch

Es wird Elasticsearch 0.20.5 verwendet. Zum Betrieb der Suche werden keine Plugins benötigt. Das elasticsearch-head-plugin ist jedoch hilfreich, um den Zustand des Indexes zu überprüfen.

Such-Oberfläche

Die Grailsanwendung verwendet eine geringfügig angepasste Variante von FacetView als Oberfläche. Um die für den Suchbegriff relevanten Textausschnitte anzeigen zu können, werden die Suchanfragen von Facetview nicht direkt an Elasticsearch gesendet, sondern zuvor von der Grailsanwendung weiter verarbeitet.
Die Anwendung besitzt keine Domainklassen und benötigt auch keine Datenbank. Da keine Domainklassen indexiert werden und der Elasticsearchserver eigenständig läuft, wurde auf die Verwendung des grails elasticsearch plugins verzichtet. Stattdessen werden erneut TransportClients verwendet. Um die Anzahl der erzeugten Clients zu reduzieren und sicherzustellen, dass sie korrekt geschlossen werden, werden die Clients in einem Pool verwaltet. Daneben wurde die Möglichkeit, die Dokumente direkt herunterzuladen, geschaffen. Die Anwendung läuft auf einem Tomcat-Server.


Oberfläche der Suchanwendung

Fazit

ManifoldCF eignet sich sehr gut zum Indexieren von Dokumenten aus unterschiedlichen Quellen, jedoch gibt es spezielle Anwendungsfälle, in denen es ineffizient ist, das gesamte Quellsystem zu durchlaufen, um geänderte Dokumente zu finden. In diesen Fällen kann die Performance von ManifoldCF nicht mit einer Anwendung mithalten, die die Eigenheiten dieses Quellsystems, in dem hier beschriebenen Fall SVN, ausnutzt. Es wäre auch möglich, diese Optimierungen in ManifoldCF zu integrieren, indem man einen eigenen, sogenannten RepositoryConnector für SVN schreibt, der Dokumente aus dem Quellsystem bereitstellt. Dazu besteht jedoch in diesem Anwendungsfall keine Notwendigkeit.
ManifoldCF ist, abgesehen von einigen Kleinigkeiten, leicht zu konfigurieren und die Geschwindigkeit beim Aktualisieren des Indexes ist sehr zufriedenstellend.
Über die Qualitäten von Grails, FacetView und Elasticsearch wurde im exensio-Blog bereits berichtet.

Technische Umsetzung von Business Intelligence Applikationen mit Open Source

2013-03-07T22:32:00.000+01:00

Nach dem mein Kollege Peter Soth im ersten Teil dieser Blogserie die fachlichen Hintergründe sowie die generelle Motivation zur Verwendung von Open Source im Business Intelligence Umfeld beleuchtet hat, geht dieser Teil tiefer auf die technische Umsetzung ein.

Technische Basis

Wie bereits erwähnt wurde das Grails-Framework für die Implementierung der Business Intelligence Applikation verwendet. Da Grails eigentlich als Framework für Webapplikationen bekannt ist, werden hier zunächst Gründe aufgeführt, die zu dieser Auswahl geführt haben.

Keine zusätzlichen Lizenzkosten für die Software
Mitverwendung der bestehenden Server-Infrastruktur
Die Umsetzung als Webapplikation ermöglicht eine einfache Integration in existierende Web-Applikationen (wie bspw. Portale) mit dem kundenspezifischen Look&Feel
Verschiedene Ausgabeformate können einfach durch Plugins unterstützt bzw. selbst implementiert werden
Die Programmiersprache Groovy ist die Basis von Grails. Groovy eignet sich auch hervorragend, zur Durchführung von Operationen auf Datenstrukturen, was beim Transformieren der zu importierenden Dateien benötigt wird. Des Weiteren können mit Groovy relativ einfach DSL’s realisiert werden.

Ein weiteres wichtiges Kriterium ist die Möglichkeit zur Unterstützung von Batch-Funktionalitäten für die Umsetzung des ETL-Prozesses. Hierfür wird das Batch-Launcher Plugin [1] eingesetzt. Das Plugin ermöglicht die Ausführung von Grails außerhalb eines Servlet-Containers, in dem die Anwendung als normale Java-Applikation über eine Main-Methode gestartet wird. Der Vorteil ist hierbei, dass der ETL-Prozess unabhängig von der Web-Applikation läuft und damit dort zu keinen Ressourcen-Engpässen führt.

Da es mehrere Batches in der Applikation gibt, die auch entsprechend überwacht werden müssen, wurde zusätzlich ein leichtgewichtiges Batchframework aufgesetzt. Kern dieses Frameworks ist eine Datenbanktabelle in der die Aktivitäten und der aktuelle Status protokolliert werden. Dadurch kann insbesondere verhindert werden, dass der gleiche Batch mehrfach angestoßen wird und es können Abhängigkeiten zwischen den einzelnen Batches geprüft werden.

Der ETL-Prozess im Detail

Wie in BI-Applikationen üblich werden auch in diesem Projekt die Daten über den ETL-Prozess [2] importiert und aufbereitet, so dass sie für Analysen in der Applikation vom Endanwender genutzt werden können.

Grundlage sind ca. 50 Dateien im CSV-Format, die monatlich von den verschiedenen Quellsystemen geliefert werden. Die CSV-Dateien enthalten Daten über mehrere Monate und sind auch vom Aufbau unterschiedlich. Diese Dateien liefern die Inhalte auf dem untersten Level, die in das Starschema importiert werden.

Aus fachlicher Sicht wurden drei Hauptbereiche für Analysen identifiziert, die jeweils über eine eigene Faktentabelle mit den zugehörigen Dimensionstabellen abgebildet werden. In den Dimensionstabellen finden sich unter anderem die zeitlichen Aspekte oder auch Wirkstoffe, da es sich um eine Applikation aus dem Pharmabereich handelt. Die drei Faktentabellen werden jeweils durch einen eigenen Batch mit Inhalten der verschiedenen CSV-Dateien gefüllt. Die Batches sind entsprechend parametrierbar, da die Anzahl der enthaltenen Monate sowie die Monate selbst variieren.

Da die Daten zwischen den verschiedenen Quellsystemen abgeglichen und auch gefiltert werden müssen, werden entsprechende Transformationen und Regeln benötigt. Ein hierfür nützliches Hilfsmittel sind Closures [4] in Groovy, um diese Verarbeitungsschritte relativ einfach umzusetzen. Nachfolgend ist eine sehr einfache Bedingung zur Filterung von CSV-Zeilen exemplarisch dargestellt.

def ignoreConditionGeneric = { name ->
  return name && name != 'Summe'
}

Um für die 50 zu importierenden Dateien nicht unnötig viel ähnlichen oder gar doppelten Code zu erzeugen wurde eine Art DSL [5] entworfen, die für jede Datei die entsprechenden Eigenschaften definiert. Über die DSL wird z.B. definiert welche Spalten sich wiederholen und sich nur durch den Monat unterscheiden oder ob es sich bei den einzelnen Spalten um Beträge oder Namen handelt. Ändert sich die Struktur einer Datei kann somit schnell durch Anpassung der Konfiguration darauf reagiert werden.

Nachdem die Daten auf der untersten Ebene vorhanden sind, läuft für jede Faktentabelle ein weiterer Batch zur Aggregation der Daten. Hier werden beispielsweise auf der zeitlichen Dimension Daten quartalsweise oder jährlich summiert.

Die grafische Oberfläche

Eine fachliche Anforderung ist die Unterstützung von verschiedenen Ausgabeformaten. Die folgende Abbildung zeigt die verschiedenen Darstellungsformate exemplarisch für einen Report.

Die drei verschiedenen Darstellungsformate

Neben der HTML-Oberfläche stehen Exporte nach CSV sowie PDF zur Verfügung. Diese drei Ausgabeformate werden für sämtliche Reports innerhalb der Applikation auf jeder Ebene angeboten. Dies bedeutet ein Anwender selektiert über entsprechende Auswahlboxen Kriterien und lässt sich für diese einen entsprechenden Report generieren.

Für den PDF-Report wird eine Open Source Version der itext-Bibliothek eingesetzt. CSV-Dateien werden mit Hilfe des Export-Plugins von Grails umgesetzt.

Zusätzlich zu den tabellarischen Reportdarstellungen gibt es grafische Aufbereitungen in Form von Diagrammen. Auch hier wird auf die Bibliothek itext zurückgegriffen.

Grafische Aufbereitung von Kennzahlen

Fazit

Mit dem hier vorgestellten Ansatz lassen sich kostengünstig Standardreports erstellen, die vor allen Dingen homogen in bestehende Unternehmens-Applikationen und Infrastrukturen integriert werden können. Applikationen dieser Art sind für Endanwender im Vergleich zu den speziellen BI-Werkzeugen sehr einfach zu bedienen und bieten trotzdem verschiedene Sichten mit entsprechenden Drill-Down Möglichkeiten auf den Daten.

Links

[1] Batch Launcher Plugin
[2] ETL-Process
[3] Star Schema
[4] Groovy Closures
[5] Domain Specific Language