exensio it blog

Preisbindung für rezeptpflichtige Medikamente – Warum sich Pharma-politische Entscheidungen auf unsere IT Lösungen auswirken?

noreply@blogger.com (Irving Tschepke) — Thu, 03 Nov 2016 09:00:00 +0000

Vor kurzem hat der Europäische Gerichtshof die Preisbindung für verschreibungspflichtige Medikamente in Deutschland gekippt (siehe u.a. http://www.tagesschau.de/wirtschaft/eugh-arzneimittel-103.html). Was steckt dahinter? In Deutschland ist die Preisbildung für verschreibungspflichtige Arzneimittel gesetzlich geregelt (Arzneimittelpreisverordnung). Dahinter steckt der Grundgedanke, dass Patienten das gleiche Medikament in jeder Apotheke zum gleichen Preis erhalten. Kranke sollen in ihrer Notlage nicht noch Preise vergleichen müssen. Zudem soll mit dem System die Grund- und Notfallversorgung mit Medikamenten sichergestellt werden.

D.h. deutschen Apotheken ist es für rezeptpflichtige Arzneimittel nicht erlaubt, Rabatte zu gewähren. Dies gilt auch für Versandapotheken.

Mit dem Urteil des EuGH ist diese Preisbindung für ausländische Versandapotheken nun aufgehoben worden. Der Aufschrei der deutschen (Versand-)Apotheken blieb natürlich nicht aus, wenn ab sofort über den ausländischen Apotheken-Versandhandel die gleichen Medikamente zu günstigerem Preis erworben werden können und in Deutschland aber die Preisbindung gilt.

2 Lösungsszenarien liegen auf der Hand: Entweder wird nun auch für deutsche (Versand-) Apotheken die Preisbindung aufgehoben oder der Versandhandel für rezeptpflichtige Medikamente wird verboten. Zu letzterer Variante gibt es bereits einen Vorstoß durch den Gesundheitsminister (siehe u.a. https://www.welt.de/newsticker/dpa_nt/infoline_nt/schlaglichter_nt/article159106082/Groehe-will-Versandhandel-mit-Arzneien-auf-Rezept-verbieten.html).

Wieso beschäftigen wir von exensio uns mit diesem Thema? exensio erstellt IT Lösungen in unterschiedlichen Bereichen von Pharmaunternehmen. Da wir die geschäftlichen Abläufe und Hintergründe verstehen müssen, ist es für uns wichtig, immer ein Ohr an den aktuellen fachlichen Entwicklungen zu haben.

So hat exensio für einen unserer Pharma Kunden ein PIM (Product Information Management) System implementiert, mit dem unter anderem sämtliche Preise für alle Präparate verwaltet werden. Dazu gehören der Hersteller Abgabepreis (HAP), der Apotheken Einkaufspreis (AEP) sowie der Apotheken Verkaufspreis (AVP).

Der Hersteller kann diese Preise regelmäßig (alle 14 Tage) ändern und meldet diese der IFA (Informationsstelle für Arzneimittelspezialitäten). Mit Hilfe unserer PIM Lösung können diese Preisanpassungen auf elektronischem Wege automatisiert übermittelt (und Rückmeldungen verarbeitet) werden.

Je nach Lösung des oben beschriebenen Konflikts würde dies eine Änderung für unser Modul "Preisänderungsmeldung" implizieren. Warten wir ab, wer sich durchsetzt.

Integration mit Scrapy und Tweepy

noreply@blogger.com (Roland Rickborn) — Wed, 19 Oct 2016 07:57:00 +0000

In diesem Posting gehe ich auf die Integration von Webinhalten mittels Scrapy und Tweepy ein. Ich zeige, wie man einen Scrapy-Spider bei Srapinghub betreibt und wie man Tweets auf Twitter postet.

Problemstellung

Eine Webseite (in diesem Fall im Internet) stellt Content zur Verfügung, der potentiell für eine breite Masse von Interesse ist. Die Usability der Webseite stellt eine hohe Hürde für viele User dar. Das beginnt beispielsweise am fehlenden Responsive Design, geht weiter über mangelnde Teilbarkeit und endet bei nicht vorhandener, moderner Funktionalität. Die Ursachen für die Mängel sind vielschichtig und reichen von nicht vorhandenem Budget bis zur falschen Wahl des verwendeten Frameworks bzw. veralteter Technologie. Ähnlich verhält es sich mit der Ablösung des Systems, die eigentlich folgerichtig wäre. Die üblichen Gründe für den Weiterbetrieb sind z.B. fehlendes Bewußtsein der Mängel, eingeschränktes KnowHow bzgl. neuer Technologien oder nicht vorhandenes Budget.

Das bestehende System wird trotz der Mängel vom Betreiber intensiv genutzt. Ziel des Projekts ist die einfache Integration der im Quellsystem zur Verfügung gestellten Inhalte in moderne Technologien, hier gezeigt anhand von Twitter. Die Vorteile der vorgestellten Lösung sind geringe Integrationskosten, cloudbasierte Lösung, die kaum Verwaltungsaufwand erfordert, bestehende Arbeitsprozesse seitens des Betreibers bleiben unverändert. Durch die Veröffentlichung auf Twitter wird der zur Verfügung gestellte Inhalt auf einfachste Weise einem breiten Publikum zugänglich gemacht. Zugleich lassen sich sämtliche Vorteile der Plattform nutzen (Teilbarkeit, Usability, Responsive Design).

Projektübersicht und Ablauf

Das Quellsystem verfügt über keinerlei Schnittstelle oder API, so dass entschieden wurde, die zur Verfügung gestellten Inhalte mit Screen Scraping Technologie auszulesen. Die Wahl fiel auf das Framework Scrapy [1], da es einfach in der Handhabung ist und es sich günstig in der Cloudlösung Scrapinghub [2] betreiben lässt.
Aus den oben genannten Gründen wurde für die Wiederveröffentlichung der erfassten Inhalte der Mikrobloggingdienst Twitter [3] gewählt. Durch die zuvor genannte Festlegung der Web Scraping Technologie (Scrapy benutzt Python) musste ein auf Python basiertes Tool gefunden werden. Hier bot sich die Verwendung von Tweepy [4] an, einer einfach zu benutzenden Python Bibliothek für die Twitter API.
Abgerundet wird die Lösung durch den Einsatz von TinyURL [5], einem Kurz-URL-Dienst, der sich sehr einfach in Python integrieren lässt. Dieser Schritt ist notwendig, um die 140-Zeichen Grenze von Twitter einzuhalten und dennoch sinnvolle Inhalte zu posten.

Der Scrapy-Spider wird nach seiner Erstellung in den Srapinghub geladen. Dort wird ein scheduled Job angelegt, der z.B. stündlich ausgeführt wird. Die durch den Spider erfassten Inhalte werden im Spider selbst anhand von Selektoren verarbeitet und in Items aufgeteilt. Alle Items werden anschließend an eine Pipeline übergeben. In der Pipeline sind weitere Bearbeitungsschritte möglich, wie z.B. Aufarbeitung von Inhalten oder Veröffentlichung als Tweet.

Im Spider wird der Request auf die angegebene URL ausgeführt und die erfassten Daten schrittweise verarbeitet. Im ersten Schritt werden die erfassten IDs mit den bereits bearbeiteten IDs verglichen. Items mit IDs, die bereits bekannt sind, werden ausgefiltert. Auf diese Weise wird Persistenz erreicht und es wird verhindert, dass bereits bearbeitete Inhalte erneut veröffentlicht werden.
Anschließend werden alle nicht gefilterten Items an die Pipeline durchgereicht, siehe Code Listing 1:
Die Pipeline umfasst zwei Schritte.

Kurz-URL anlegen
Für die Erzeugung der Kurz-URL bot sich TinyURL auch deswegen an, weil weder ein Account erforderlich ist, noch eine eigene Bibliothek installiert werden muss. Dies kann einfach mit den Modulen requests und json erledigt werden, siehe Code Listing 2:
Tweet posten
Bevor der erfasste Inhalt getweetet werden kann, soll ein Hashtag hinzugefügt werden. Und natürlich muss die verkürzte URL zum eigentlichen Inhalt eingefügt werden. Schließlich muss noch kontrolliert werden, dass der gesamte Tweet nicht länger als 140 Zeichen lang ist. Sollte der Text die Grenze überschreiten, muss gekürzt werden, siehe Code Listing 3:

Hands on...

Zur Vorbereitung der Arbeitsumgebung gehört die Installation von Scrapy, Tweepy und weiteren Tools. Unter Linux also:

sudo pip install Scrapy
sudo pip install tweepy
sudo pip install shub

shub [6] installiert den Scrapinghub Command Line Client. Der Client stellt ein praktisches Tool für die Entwicklung und das Deployment des Projekts auf Scrapinghub dar.Zuerst muss ein Projektverzeichnis angelegt werden. Mit dem Kommando:

scrapy startproject myProject

erstellt Scrapy das komplette Projektverzeichnis inkl. aller zusätzlicher Dateien. Die Datei settings.py enthält alle Einstellungen auf Projektebene. Die Datei pipelines.py enthält die oben definierten Pipelines. Und in der Datei items.py werden die Attribute unseres Items festgelegt.

Im nächsten Schritt wird mit dem folgenden Kommando ein Scrapy-Spider angelegt und seine Start-URL definiert:

scrapy genspider mySpider start.url

Scrapy erstellt in diesem Fall die Datei mySpider.py, mit einem Grundgerüst eines Scrapy-Spiders. Die Datei lässt sich anschließend in einem Editor bearbeiten. Für das Grundgerüst unterstützt Scrapy Templates und Profile. Mehr dazu ist in der Hilfe jedes Befehls zu finden (scrapy genspider -h).

Ist der Spider ausreichend an die eigenen Bedürfnisse angepasst, lässt er sich mit diesem Kommando starten:

scrapy crawl mySpider

Bei diesem Aufruf findet die Ausgabe mit dem DEBUG Loglevel auf stdout statt. Damit lässt sich also prima überprüfen, was der Spider im Detail macht. Dort sieht man insbesondere auch die verwendeten Umgebungsvariablen, die angewendeten Einstellungen (bestehend aus globalen Scrapy-Einstellungen, Projekteinstellungen und Spider-Einstellungen), die Attribute unserer Items und die verwendeten Pipelines.

Bevor das Projekt nach Scrapinghub geladen werden kann, müssen evtl. vorhandene Abhängigkeiten zu Fremd-Modulen berücksichtigt werden. Scrapinghub erlaubt die Möglichkeit, externe Bibliotheken zu definieren [7]. Ich habe mit dem folgenden Kommando die Abhängigkeiten in meinem Projekt ermittelt:

pip freeze > requirements.txt

Anschließend verweise ich in der Datei scrapinghub.yml auf meine soeben erstellte Datei requirements.txt, siehe Code Listing 4: Jetzt sind alle Bedingungen erfüllt und das Projekt kann nach Scrapinghub geladen werden. Für das Deployment dient der Befehl:

shub deploy

Beim ersten Aufruf dieses Befehl wird ein Wizard gestartet, mit dessen Hilfe die benötigen Einstellungen für den Upload beu Scrapinghub vorgenommen werden. Nach erfolgtem Deployment sieht eine typische Ausgabe so aus:

Packing version 1.0
Deploying to Scrapy Cloud project "myProjectId"
{"status": "ok", "version": "1.0", "spiders": 1, "project": myProjectId}
Run your spiders at: https://app.scrapinghub.com/p/myProjectId/

Da das Deployment erfolgreich war, folgt jetzt der große Moment, in dem der Spider das erste Mal gestartet wird. Der Spider kann entweder über die Weboberfläche von Scrapinghub gestartet werden, oder wieder über den Command Line Client. Das Kommando dafür ist:

shub schedule mySpider

Der Aufruf wird typischerweise quittiert durch die folgende Ausgabe, die Hinweise auf das Logging enthält:

Spider mySpider scheduled, job ID: myProjectId/1/1
Watch the log on the command line:
    shub log -f 1/1
or print items as they are being scraped:
    shub items -f 1/1
or watch it running in Scrapinghub's web interface:
    https://app.scrapinghub.com/p/myProjectId/job/1/1

Tipp: Persistenz zwischen Läufen eines Spiders

Häufig wird in der Scrapinghub Dokumentation und in Foren zum Thema Persistenz auf das Addon DeltaFetch [8] verwiesen. Dieses Addon ist dazu geeignet, das Erfassen von URLs zu vermeiden, die bereits früher analysiert wurden. Ist der eigene Spider also so angelegt, dass die zu erfassenden URLs aus der Start-URL gescrapt werden, dann ist DeltaFethc in der Lage zu unterscheiden, ob die eingelesenen URLs in einem vorigen Lauf schon ausgelesen wurden. In diesem Fall werden diese URLs nicht erneut bearbeitet.
Im aktuellen Projekt werden allerdings keine URLs erfasst, sondern IDs die sich in Div-Tags befinden und die keine eigene URL besitzen. Deshalb war es für die Persistenz erforderlich, eine eigene Lösung zu entwickeln. Als Basis dient das Addon DotScrapy [9], das die Funktion data_path() zur Verfügung stellt. Umgesetzt wurden die Funktionen setLastRunId() und getLastRunId(), siehe Code Listing 1.

Fazit

Mit der vorgestellten Lösung lassen sich Webinhalte von schwer zugänglichen Webseiten auf einfache, günstige und schnelle Weise einem großen Publikum zur Verfügung stellen. Die Lösung ist vollständig cloudbasiert, erfordert also keinerlei eigene Administration. Durch die Screen Scraping Technik müssen weder bestehende Prozesse, noch bestehende Systeme angepasst werden.

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

noreply@blogger.com (Tobias Kraft) — Thu, 13 Oct 2016 09:20:00 +0000

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

noreply@blogger.com (Sebastian Jäger) — Wed, 05 Oct 2016 08:26:00 +0000

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

noreply@blogger.com (Sebastian Jäger) — Tue, 27 Sep 2016 04:30:00 +0000

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.

SVN und Mac OS X und Umlaute

noreply@blogger.com (Florian Mutter) — Fri, 23 Sep 2016 07:30:00 +0000

Hat man unter Mac OS X schon einmal ein Subversion Repository ausgecheckt, das Dateien mit Umlauten im Namen enthält kennt man wahrscheinlich das Problem: Es werden scheinbar ohne Grund Dateien als geändert und als unversioniert angezeigt. Es gibt auch erst einmal keine offensichtliche Lösung für das Problem.

Das Problem

Mac OS X speichert Umlaute in Dateinamen als sogenannte precomposed characters (auf Deutsch etwa: "zusammengesetzte Buchstaben"). Das bedeutet, dass ein "ü" nicht als einzelner Buchstabe gespeichert wird, sondern als Zusammensetzung aus einem "u" und dem Zeichen für zwei Punkte über dem Buchstabe ("¨"). Das ist an sich völlig in Ordnung und so vorgesehen. Allerdings gibt es Programme (wie Subversion), die beim Vergleich von Dateinamen diesen Umstand nicht berücksichtigen. Für Subversion sind das Zeichen "ü" und das zusammengesetzte Zeichen "ü" aus zwei Zeichen unterschiedliche Buchstaben.

Fügt man mit Windows eine Datei mit Umlauten in ein Subversion Repository hinzu und checked dieses auf OS X aus, sieht das Ergebnis von svn status so aus: Man kann die Dateien weder commiten noch reverten. Der Zustand lässt sich nicht ändern. Das Problem ist im Subversion Bugtracker seit 2005 gemeldet. Es existiert auch eine Seite im Subversion-Wiki zu diesem Thema. Nur leider ist bisher noch keine Lösung im offizielle Subversion-Code gelandet (Zum Zeitpunkt der Erstellung diese Artikels ist 1.9.4 die aktuelle Version von Subversion).

Die Lösung

An der Fehlermeldung im Subversion-Bugtracker ist ein Patch angehängt, der das Problem behebt. Mit dem Paketmanager Homebrew kann dieser relativ einfach in Subversion eingebaut werden. Ein Nebeneffekt ist, dass man ab dann eine relativ aktuelle Version von Subversion verwendet.

Um den Patch einspielen zu können muss man natürlich erst einmal Homebrew installieren. Wie das geht steht auf der oben verlinkten Seite. Mit den folgenden Schritten kann man Subversion patchen:

Im Terminal mit brew edit subversion die Subversion-Formel zum anpassen öffnen
Unterhalb von patch :DATA muss die URL und der Hash des Patches eingetragen werden. Standardmäßig wird unter OS X der Editor VIM verwendet. Mit der Taste i kann man in den Eingabemodus wechseln. Die Datei sieht an dieser Stelle dann so aus:
Die Datei speichern und schließen. In VIM drückt man zuerst ESC um den Eingabemodus zu verlassen und gibt dann :x ein und bestätigt mit Enter
Speichern und Subversion bauen mit brew install --build-from-source subversion
Terminal schließen und neu öffnen und mit svn --version überprüfen ob Version 1.9.4 oder neuer läuft

Update von Subversion

Mit Homebrew kann man im Terminal mit dem Befehl brew update und dann brew upgrade alle installierten Programme aktualisieren.

Bei brew update öffnet sich bedingt durch die obige Anpassung manchmal der Standardeditor mit einer Merge-Nachtricht. Es muss dann einfach gespeichert und der Editor beendet werden, damit Homebrew das Update beendet. Es handelt sich hier um einen normalen Git-Merge.

Wird eine neue Version von Subversion installiert (z.B. durch brew upgrade), wird automatisch die vorkompilierte Version verwendet. Diese muss dann durch eine selbstkompilierte Version ersetzt werden: brew reinstall --build-from-source subversion. So wird automatisch wieder der Patch eingespielt.

Nun kann man ohne Probleme mit Subversion-Repsitories arbeiten, die Datei mit Umlauten enthalten.

IntelliJ

IntelliJ kann glücklicherweise so eingestellt werden, dass die neue gepatche Version von Subversion verwendet wird. Dazu muss man in den Einstellungen auf die Homebrew-Version von Subversion wechseln (/usr/local/bin/svn):

Jetzt sollte auch IntelliJ mit Umlauten in Repositories umgehen können.

Subversion GUI Tools

Bei fast allen Subversion GUI Tools (z.B. Versions, Cornerstone oder SmartSVN) ist es leider so, dass diese eingebaute Subversion-Clients verwenden. Diese sind in der Regel leider nicht gepatcht (siehe z.B. den FAQ von Cornerstone) und so zeigen diese Programme auch immer Dateien als geändert an, obwohl sich dort nichts geändert hat.

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

noreply@blogger.com (Sebastian Jäger) — Tue, 20 Sep 2016 04:00:00 +0000

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

CKEditor Customizing

noreply@blogger.com (Andreas Scheidmeir) — Tue, 13 Sep 2016 12:12:00 +0000

CKEditor ist ein im Web weit verbreiteter WYSIWYG-Editor ("what you see is what you get"), welcher sich sehr flexibel an die Bedürfnisse eines Projekts anpassen lässt. In diesem Blogpost möchte ich kurz einige Anpassungen beleuchten, welche vielleicht auch Ihnen bei Ihren Projekten weiterhelfen können.

Lange Texte im Editor

In einem unserer Projekte ist die Anforderung, dass über den CKEditor relativ lange Texte eingegeben werden müssen. Dies ist an sich kein Problem, allerdings erhält man damit unter umständen zwei Scrollbars - eine im Editor und eine für die gesamte Seite. Gerade im Zeitalter von Touchscreens eine unschöne Sache.

Abhilfe schafft hier das Plugin Autogrow, welches den Editor mit dem Inhalt wachsen lässt. Nach dem herunterladen und hinzufügen muss es nur noch in der config-Datei aktiviert werden. Standardmäßig reagiert das Plugin erst, sobald der Editor im Fokus ist. Will man jedoch, dass dies direkt bei Seitenaufbau passiert, zum Beispiel weil der Editor mit Inhalt gefüllt wird, kann dies ebenfalls in der Config angepasst werden.

Nun wächst der Editor wie gewollt mit dem Inhalt mit, jedoch verliert sich die Toolbar am oberen Rand. Soll etwas editiert werden muss erst wieder ganz nach oben gescrollt werden. Unschön!

Hierfür haben wir zwei Lösungsansätze gefunden: entweder die Toolbar mitscrollen lassen oder eine Toolbar bei Bedarf einblenden, sobald der Nutzer einen Bereich markiert.

Für die erste Variante existiert das Plugin Fixed, welches jedoch ohne Anpassungen in unserem Fall nicht korrekt funktioniert (beim Scrollen verschob sich die Position der Toolbar). Nichts, was sich nicht richten ließe, aber in unseren Projekten wollen wir externe Plugins möglichst nicht verändern, um spätere Updates problemlos durchführen zu können.

Umgesetzt haben wir die zweite Option mittels des Plugins Floating-Tools. Es hat eine Abhängigkeit zu Editor Toolbar, diesen Plugin ist aber standardmäßig in alles Presets des Builders enthalten, sodass keine weiteren Schritte nötig sind. Die Toolbar von Floating-Tools kann unabhängig von der Haupttoolbar konfiguriert werden, übernimmt aber deren Aussehen.

Soll das Plugin nicht in alles Instanzen des CKEditors aktiv sein, so kann man es auch lokal aktivieren. Hier müssen alle zusätzlichen Plugins angegeben sein, da dieser Parameter extraPlugins aus der config-Datei überschreibt.

Nun lässt sich vernünftig mit langen Texten arbeiten.

Paste from Word

Eine weitere Anforderung ist die Möglichkeit Texte aus Word in den Editor zu kopieren. Um ungewünschte Formatierung zu vermeiden gibt es hierfür das Paste From Word Plugin, welches an sich gute Arbeit leistet. Was das Plugin allerdings nicht bewerkstelligt, ist leere Paragraphen und alleinstehende Leerzeichen zu unterdrücken. Außerdem werden Einrückungen über inline-Style mit margin-left bewerkstelligt. Dies tut CKEditor selbst auch, aber aus Word eingefügte Einrückung verwendet cm und der Editor erwartet px, sodass solche Einzüge über die graphische Oberfläche nicht mehr editiert werden können.

Um dem entgegenzuwirken haben wir in der Config für paste-Events Regeln definiert, welche eben jene Zeichenketten erkennen und ersetzen. In unserem Fall löschen wir neben leeren Paragraphen und Leerzeichen alle inline-Styles - genauer genommen finden wir diese Fälle und ersetzen sie mit einer leeren Zeichenkette.

Hier können natürlich auch weitere Regeln eingefügt oder der reguläre Ausdruck entsprechen Ihrer Anforderung angepasst werden.

Viel Spaß beim Customizing!

Competitive Intelligence: Suchmaschinen im Kontext von Business Intelligence

noreply@blogger.com (Peter Soth) — Mon, 12 Sep 2016 16:40:00 +0000

Im aktuellen BI Spektrum ist von uns ein Artikel bzgl. des Einsatzes von Suchtechnologien im Kontext von Competitive Intelligence erschienen.

Suchmaschinen werden hauptsächlich mit der Suche in unstrukturierten Datenansammlungen wie Texten assoziiert. Die Eignung für die Analyse strukturierter Informationen ist derzeit dagegen nicht umfassend bekannt. Bei der Verwendung strukturloser Daten stoßen BI-Lösungen leicht an ihre Grenzen, besonders wenn ein eindeutiger Kenner wie beispielsweise ein EAN-Code (Barcode) für eine Preisvergleichsanalyse fehlt ...

Der Artikel kann hier als Sonderdruck auf unserer Homepage gelesen werden.

Integration mit SEEBURGER Business Integration Suite

noreply@blogger.com (Irving Tschepke) — Mon, 25 Jul 2016 08:12:00 +0000

exensio hat schon sehr viele individuelle Portal Lösungen für seine Kunden implementiert. Wesentliches Element bei diesen Projekten sind stets Integrationen mit verschiedensten Backend Systemen. Erst der versteckte Durchgriff auf andere Applikationen macht den Mehrwert echter Portal-Lösungen für die Benutzer aus.

Durch diese Projekte kommen wir mit allerlei anderen Systemen in Kontakt und haben verschiedenste technische Anbindungen implementiert. In einem vor kurzem abgeschlossenen Projekt konnten wir den Vorteil eines Enterprise Integration Busses genießen: bei unserem Kunden wird die SEEBURGER Business Integration Suite (BIS) eingesetzt.

Damit waren wir von der individuellen Anbindung an die Systeme entbunden und konnten eine für uns technisch einfache Umsetzung der Schnittstelle wählen. Die Konvertierung in die für das Schnittstellensystem gewünschten Formate wurde durch den BIS Server umgesetzt.

Wir wählten für die Kommunikation XML over http, d.h. haben entsprechend als XML verpackte Anfragen per GET und PUT Requests an den BIS Server geschickt und Antworten in Form von XML erhalten. Damit lassen sich auch sehr einfach die Schnittstellen per cURL testen.

In dieser identischen Art konnten wir zum einen das CRM System anbinden (hier konkret Update7) sowie SAP. Die Zugriffe waren sowohl lesend als auch schreibend.

Folgende Vorteile haben wir bei der Umsetzung gesehen:

Vom technischen Format unabhängige Implementierung der beiden an der Schnittstelle beteiligten Systeme (Abstraktion durch den BIS Server)
Gute Testbarkeit, insbesondere auch während des Betriebs (Testen der Schnittstelle durch cURL Aufrufe)
Zusätzliche Monitoring Ebene realisiert durch den BIS Server
Verfügbarkeit der Schnittstelle, auch wenn das eigentliche Zielsystem temporär technisch nicht erreichbar ist – beispielsweise bei der Weitergabe von Statusinformationen

In Summe konnten durch die Verwendung des Enterprise Integration Busses die Implementierungsaufwände für die Schnittstellen gegenüber einer konventionellen Anbindung deutlich reduziert werden.

Neben SEEBURGER gibt es natürlich noch jede Menge weiterer Anbieter, die solche Enterprise Service Bus Lösungen anbieten (IBM, Oracle, etc.). SEEBURGER ist bekannt für die Integration mit SAP und stellt hierfür entsprechende Adapter zur Verfügung. Darüber hinaus gibt es eine ganze Reihe nicht-kommerzieller Anbieter, wie beispielsweise verschiedene Lösungen der Apache Software Foundation (Service Mix, Synapse, Tuscany) oder von JBoss.

Im Übrigen halten wir Bus Lösungen oder Integrations-Frameworks wie Apache Camel nicht nur für Enterprise Portale sondern generell für zukünftige Lösungen im IoT und Industrie 4.0 Kontext für sehr relevant. Aber das Thema ist wohl einen separaten Blogbeitrag wert.

Interaktive Browser-Automatisierung mit Geb und der Groovy-Shell

noreply@blogger.com (Benjamin Kretschmann) — Mon, 18 Jul 2016 05:34:00 +0000

Dieser Blog-Post beschreibt die Entstehung eines einfachen Werkzeugs zur interaktiven Benutzung von Geb und zeigt die Verwendung des Werkzeugs anhand eines Beispiels.

Problemstellung und Motivation

Geb ist eine Lösung zur Browser-Automatisierung auf Basis der Selenium Webdriver und der Programmiersprache Groovy. Die Programm-Bibliothek bietet einfache und elegante Möglichkeiten für das automatisierte Testen von Webanwendungen, lässt sich aber auch für das Scraping von Webseiten einsetzen. Zusammen mit dem Testframework Spock setzen wir Geb für funktionale Tests ein.

Um einzelne Elemente einer Seite zu selektieren, bietet Geb eine jQuery-ähnliche Syntax. Die auf diese Weise selektierten Elemente einer Seite lassen sich in Geb zu einer logischen Einheit zusammenfassen.
Bevor ich einen neuen funktionalen Test schreibe, wähle ich zunächst die daran beteiligten Elemente einer Seite (Buttons, Eingabefelder etc.) aus und erstelle entsprechende Selektoren - also Ausdrücke, die ein bestimmtes Element oder eine Gruppe von Elementen adressieren und für weitere Aktionen zugänglich machen. Auf Grundlage dieser Selektoren erstelle ich die oben beschriebene Einheit, auch PageObject genannt und verwende diese dann im funktionalen Test.

Als ich erste Erfahrungen mit Geb sammelte, um funktionale Tests zu schreiben, verhielt sich mein Programmcode nicht immer so, wie ich es erwartet hätte. Ich passte die entsprechenden Stellen an und startete den funktionalen Test erneut. Dieses Vorgehen ist aber sehr zeitintensiv, da die zu testende Applikation neu gestartet und Testdaten neu geladen werden müssen. Daher suchte ich nach einer einfachen Lösung, um die Selektoren vor ihrer Verwendung ausprobieren zu können. Als ich keine fertige Lösung für dieses Problem fand, erstellte ich ein kleines Werkzeug auf Basis der Groovy-Shell und dem Build-Tool Gradle. Die Groovy-Shell implementiert einen REPL (read-eval-print-loop), wie man ihn von vielen Scriptsprachen (wie beispielsweise Python oder Javascript) kennt. In Kombination mit Geb lassen sich so Webseiten interaktiv untersuchen.

Im folgenden Szenario möchten wir die Überschriften der zuletzt veröffentlichten Blog-Posts von der exensio-Homepage extrahieren.

Wir laden uns den Quellcode des Projektes von GitHub herunter oder checken das Projekt mittels git aus. Um das Tool starten zu können, wird das Java Development Kit in der Version 8 und der Firefox Browser benötigt. Außerdem sollte die Umgebungsvariable „JAVA_HOME“ korrekt gesetzt sein.
Nach dem wir auf der Kommandozeile in das Projektverzeichnis gewechselt sind, wird folgender Befehl eingegeben, um die Groovy-Shell und Geb zu initialisieren:

Zunächst wird Gradle und die benötigten Abhängigkeiten (die Geb-Bibliothek, der Selenium-Webdriver etc.) heruntergeladen. Dann sollte sich automatisch eine neue Firefox-Instanz öffnen. Mittels des Browser-Objekts können wir nun diese Instanz ansteuern. Das folgende Beispiel sucht vom exensio-Blog die letzten Posts heraus und zeigt diese mit Hilfe des inspect-Befehls der Groovy-Shell in einem Dialog an.

Um die Groovy-Shell zu beenden, müssen folgende Befehle eingegeben werden:

Fazit

„Probieren geht über Studieren“ – ersetzt sicherlich nicht das Lesen der Dokumentation, doch gerade, wenn man eine neue Technologie kennenlernt, ist es von großem Vorteil, über eine Möglichkeit zu verfügen, einfach und unkompliziert etwas ausprobieren zu können. Die Groovy-Shell ist hierfür ein gutes Werkzeug. In diesem Beispiel haben wir sie mit Geb kombiniert, doch lässt sich dieses Prinzip auch auf andere Java bzw. Groovy-Bibliotheken übertragen. Auf der Projektseite des Gradle-Groovy-Shell-Plugins finden sich weitere Beispiele, u.a. zur Kombination mit Spring-Boot.

Lizenzanalyse mit dem Open Source Tool ScanCode toolkit

noreply@blogger.com (Sebastian Jäger) — Fri, 01 Jul 2016 09:02:00 +0000

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.

Warum sich Responsive Design für Intranet Applikationen lohnt

noreply@blogger.com (Irving Tschepke) — Fri, 24 Jun 2016 08:04:00 +0000

Responsive Design ist eines der Buzzwords in Bezug auf die Gestaltung von Internet Webseiten. Was steckt dahinter? Die Webseite wird so implementiert, dass sich das Layout flexibel dem Ausgabegerät und dessen Auflösung anpasst. Damit kann man mit einer Implementierung alles von PC bis Smartphone abdecken.

Natürlich gibt es Vor- und Nachteile dieses Ansatzes. Insbesondere wenn es um mobile Geräte geht, stellt sich die Frage, ob nicht doch besser eine native App – also eine Implementierung für ein spezielles Endgerät – Sinn macht. Eine native App ist generell dann vorteilhaft, wenn Hardware-nahe Funktionen genutzt werden müssen. Diese lassen sich bei einer Geräte-unabhängigen Implementierung nicht oder erheblich schwieriger umsetzen. Auf der anderen Seite muss dann für verschiedene Endgeräte jeweils eine neue Version der App, meist von Grund auf, umgesetzt werden. Und die eigentliche Web Applikation benötigt man ja auch noch.

exensio entwickelt viele Web Lösungen, die im Intranet der Unternehmen eingesetzt werden. Auch hier stellt sich immer häufiger die Frage, mit welchen Endgeräten auf die Applikation zugegriffen werden soll. Ein klassischer Fall sind unsere Portal-Lösungen, die beispielsweise von Marketing und Vertrieb genutzt werden. Während etliche Marketing Kollegen vor allem im Innendienst aktiv sind und Desktop PCs oder Laptops verwenden, arbeiten die Vertriebsmitarbeiter mit mobilen Varianten, d.h. hier kommen verstärkt Tablets zum Einsatz.

Bei einem unserer Kunden gab es das Szenario, dass für unsere Portal Lösung eine native App implementiert wurde. Auf Portal Seite haben wir entsprechende REST/JSON Schnittstellen entwickelt, ein anderer Dienstleister die App.

Schon die erste Version der App hatte trotz vorhandener Portal Schnittstellen bei weitem nicht den Funktionsumfang des Portals. Zudem gab es nicht zu vernachlässigende Aufwände, um die Mitarbeiter für die App zu schulen, da diese im Vergleich zum Portal einen anderen Aufbau hatte und komplett anders zu bedienen war.

Weiterhin stellte sich bei allen neu entwickelten Erweiterungen für das Portal die Frage, ob dies in der Schnittstelle für die App abzubilden ist und wann das neue Feature dann auch auf der App verfügbar ist. Die Konstellation mit 2 Dienstleistern tat ihr Übriges dazu. So wurde die funktionale Lücke zwischen Portal und App immer größer und die Akzeptanz der App schwand.

Letztlich konnten wir unseren Kunden davon überzeugen, das Portal auf ein Responsive Design umzustellen. Die Vorteile waren klar:

Keine Trennung in der Entwicklung einer Desktop Version und einer App.
Ein durchgängiges Design Konzept für Desktop Version und Zugriff über die Tablets.
Eine Umsetzung mit HTML5, die auf allen Endgeräten lauffähig ist.

Für Entscheider ist insbesondere der Blick auf die Kosten relevant:

Reduzierung der Entwicklungskosten: keine extra Entwicklungen für Portal, Schnittstelle und App
Reduzierung von Schulungs- und Trainingsaufwand: intuitives Design auf allen Geräten ähnlich
Reduzierung der Wartungskosten: kein Installations- und Updateaufwand von Endgeräten
Keine Migrationskosten: HTML5 ist auf allen Plattformen (iOS, Android, Windows, …) lauffähig

Die beispielhaften Vergleichsrechnungen bei den Investitionskosten konnten auch überzeugen. Faktor 2 beim Vergleich, das Portal auf Responsive Design umzustellen gegenüber der Angleichung zwischen Portal und App. Beim Vergleich der Kosten für die Entwicklung einer neuen Funktion kamen wir sogar auf einen Faktor 3 zwischen der Responsive Lösung und der Variante mit Portal und nativer App.

Als positiven Nebeneffekt konnten wir die generelle Überarbeitung des Designs des Portals in einen frischeren und modernen Look nutzen und damit auch alle Anwender zusätzlich erfreuen.

Fazit: Auch bei internen Web Applikationen, die im Intranet von Unternehmen zum Einsatz kommen, kann sich die Umsetzung eines Responsive Designs lohnen.

HTML als HTML in Grails anzeigen

noreply@blogger.com (Peter Soth) — Wed, 22 Jun 2016 13:25:00 +0000

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!

Requirements Engineering nach IREB

noreply@blogger.com (Irving Tschepke) — Thu, 16 Jun 2016 07:42:00 +0000

Nach dem Wunsch von 2 Kollegen, sich mit dem Thema „Anforderungen“ näher beschäftigen zu wollen, haben wir kurzerhand eine interne Fortbildung für alle Mitarbeiter veranstaltet. Neben dem Gedanken, dass alle Mitarbeiter Grundkenntnisse im Requirements Engineering besitzen sollten, hatten wir auch ein weiteres Ziel: ein gemeinsames Verständnis für die Anforderungsanalyse zu entwickeln und das Zusammenspiel zwischen den Kollegen, die mehr beim Kunden vor Ort sind und täglich sich mit Anforderungen beschäftigen und jenen, die ihren Schwerpunkt auf der Entwicklung haben, zu fördern.

Über die Technische Akademie Esslingen TAE (https://www.tae.de/) haben wir Kontakt zu Frau Dr. Andrea Herrmann (http://herrmannehrlich.twoday.net/) aufgenommen, die für uns ein 2-tägiges Programm mit dem Titel „Requirements Engineering nach IREB“ zusammengestellt hat.

IREB ist das „International Requirements Engineering Board“, eine non-profit Organisation, die sich zum Ziel gesetzt hat, Aus- und Weiterbildung im Requirements Engineering zu fördern und einen entsprechenden Standard entwickelt hat.

In intensiven Sessions haben wir uns in 2 Tagen mit einer Fallstudie auseinandergesetzt und dabei alle wesentlichen Themen des Requirements Engineering vermittelt bekommen und in Übungen angewendet. Beginnend mit der Definition des Systems und dessen Kontext haben wir die verschiedenen Erhebungsmethoden kennen gelernt und darauf aufbauend die Anforderungen an das System in Form von Use Cases beschrieben.

Intensive Diskussionen gab es beim Thema Qualitätsanforderungen, da hier insbesondere die praktischen Erfahrungen die Bedeutung dieser Art von Anforderungen relativiert: Aspekte wie beispielsweise Wartbarkeit und Sicherheit will jeder Kunden haben, aber es soll am besten nichts kosten… Auf der anderen Seite ist es nicht einfach, Anforderungen dieser Art messbar und damit nachprüfbar zu machen.

Frau Dr. Herrmann hat auch auf unseren Wunsch hin Aspekte des GMP (Good Manufacturing Practice) beleuchtet, da wir durch unsere Tätigkeiten für die Pharma Industrie uns mit diesem Thema beschäftigen müssen.

In verschiedenen Übungen haben wir die diversen Diagrammtypen der UML angewendet (wie Use Case-, Aktivitäts- und Zustands- und Klassendiagramm) und dafür das freie UML Werkzeug StarUML (http://staruml.io/) eingesetzt. Über unsere (auch bereits vor der Schulung vorhandenen) Erfahrungen mit dem Tool berichten wir in einem späteren Blog-Beitrag. Die aktuelle Verwendung verschiedener Diagrammtypen in unseren bisherigen Projekten haben wir auch beleuchtet. Nicht alles, was die UML bietet, kann man auch dem Endkunden zur Abstimmung der Anforderungen vorlegen. So setzen wir bereits heute sehr gezielt nur eine Auswahl von Diagrammtypen ein. Zudem stellt sich auch immer die Frage des Kosten-Nutzen-Verhältnisses.

Schließlich haben wir uns noch mit dem Management der Anforderungen im Projektverlauf beschäftigt (Requirements Management) und uns mit dem (für uns üblichen) iterativen Vorgehen und Change Request Verfahren auseinander gesetzt.

Das Ziel, eine gemeinsame Basis beim Thema Requirements Engineering für alle Mitarbeiter der exensio zu schaffen, ist erreicht. Nun gilt es, die ein oder andere Anregung aus den beiden Tagen näher zu betrachten und in den Projektalltag zu integrieren.

Einen herzlichen Dank nochmals an Frau Dr. Herrmann, die uns in der Kürze der Zeit sehr fundiert das Requirements Engineering nach IREB vermittelt hat und auf unsere Spezialthemen eingegangen ist.

Artikel von exensio im aktuellen JavaSPKETRUM // Schweizer Taschenmesser für Daten - Serverlose Suchmaschinen

noreply@blogger.com (Peter Soth) — Tue, 07 Jun 2016 07:41:00 +0000

In der aktuellen Ausgabe des JavaSPEKTRUM ist von mir ein Artikel mit dem Titel »Schweizer Taschenmesser für Daten - Serverlose Suchmaschinen« erschienen. In diesem zeige ich auf, dass sich Suchtechnologie noch für mehr, als nur Volltextsuche eignet. Als weitere Einsatzgebiete kommen hier:

Query-Turbo für SQL-Datenbanken
Verarbeitung von GEO-Daten
Business Intelligence
Internet of Things (IoT)

in Frage.

Der Artikel kann von hier geladen werden.

Rückblick auf die GR8Conf in Kopenhagen

noreply@blogger.com (Tobias Kraft) — Mon, 06 Jun 2016 05:17:00 +0000

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.

Query Turbo für SQL : Elasticsearch, Apache Lucene bzw. Apache Solr vs. SQL Queries

noreply@blogger.com (Peter Soth) — Tue, 17 May 2016 05:59:00 +0000

In diesem Blogpost möchte ich aufzeigen, dass sich Suchmaschinen (in diesem Blogpost gehe ich auf Elasticsearch ein, das wie Apache Solr auf Apache Lucene basiert) auch ausgesprochen effektiv als Turbo für SQL-Queries verwenden lassen. SQL-Queries neigen ab einer gewissen Komplexität (hierarchisch, viele Aggregationen bzw. Joins) dazu, langsam zu werden. So entstehen beispielsweise in Portalen komplexe SQL Statements bei der Abfrage von Personalisierungsregeln (wer darf was sehen). Als prominentes Beispiel kann man hier das Liferay Portal erwähnen. Seit der Liferay-Version 6.2 [1] wird beim Asset Publisher ein Lucene Index anstelle von Datenbankabfragen eingesetzt.

Mein Vergleich verwendet hingegen die 1,5 Millionen Zeilen, die ich in meinem Blogpost mit dem Thema »Olap Cube vs. Elasticsearch« [2] benutzte. Ich habe hierzu in MySQL eine flache Tabelle (keine Joins) angelegt, auf die entsprechenden Spalten einen Index gesetzt und im Anschluss daran befüllt. Anschließend ermittle ich mit Hilfe einer SQL-Abfrage dieselbe Pivot-Tabelle, die ich in meinem vorigen Blogpost mit Elasticsearch erzeugte. Das Retrieval und das Aufbereiten der Daten für die Pivot-Tabelle erfolgt mit folgendem Python-Skript.

Die Tabelle unten zeigt das Resultat, die Sortierung habe ich noch der Elasticsearch-Query meines letzten Blog-Posts hinzugefügt. Damit ist das von MySQL und Elasticsearch zurückgelieferte Ergebnis gleich und muss nicht innerhalb von Python sortiert werden.


+-----------+------------------------------------+-------------+-------------+-------------+
| Land      | Kunde                              | Umsatz 1994 | Umsatz 1995 | Umsatz 1996 |
+-----------+------------------------------------+-------------+-------------+-------------+
| Argentina |                                    |             |             |             |
|           | Cactus Comidas para llevar         |       0.00  |   32339.16  |  104296.86  |
|           | Océano Atlántico Ltda.             |       0.00  |   71270.10  |  504599.82  |
|           | Rancho grande                      |       0.00  |  115290.42  |  296329.62  |
| Brazil    |                                    |             |             |             |
|           | Comércio Mineiro                   |  149676.60  |  146333.76  |   56055.82  |
|           | Familia Arquibaldo                 |    5821.80  |  431282.70  |       0.00  |
|           | Gourmet Lanchonetes                |       0.00  |  521745.96  |   83500.20  |
|           | Hanari Carnes                      |  232872.00  |  181903.08  |  944863.26  |
|           | Que Delícia                        |   17747.10  |  491754.30  |  105637.50  |
|           | Queen Cozinha                      |       0.00  | 2704507.80  | 1017204.30  |
|           | Ricardo Adocicados                 |   79852.56  |  485725.92  |  621214.02  |
|           | Tradição Hipermercados             |    2535.30  |  236947.26  |  276141.12  |
|           | Wellington Importadora             |   26235.66  |  108304.26  |  231125.46  |
| Mexico    |                                    |             |             |             |
|           | Ana Trujillo Emparedados y helados |    3023.58  |  104961.42  |   74969.76  |
|           | Antonio Moreno Taquería            |   41316.00  |  353233.02  |  109731.54  |
|           | Centro comercial Moctezuma         |    6103.50  |       0.00  |       0.00  |
|           | Pericles Comidas clásicas          |  101787.60  |  286977.18  |  132695.20  |
|           | Tortuga Restaurante                |  306696.18  |  448316.16  |  137876.06  |
| Venezuela |                                    |             |             |             |
|           | GROSELLA-Restaurante               |  124492.62  |       0.00  |    2835.78  |
|           | HILARIÓN-Abastos                   |  153826.98  | 1487469.90  |  720745.36  |
|           | LILA-Supermercado                  |  248947.68  |  576151.62  |  553818.20  |
|           | LINO-Delicateses                   |       0.00  |  834376.62  |  431038.56  |
+-----------+------------------------------------+-------------+-------------+-------------+
Time taken: 10.31 seconds

Die gemessene Zeit liegt immer bei ca. 10 Sekunden (MySQL cached nicht) auf meinem Notebook. Vergleiche ich die Zeitdauer mit Elasticsearch, so ergibt sich folgendes Bild. Initial (Caches nicht aktiv) benötigt die Abfrage mit Nested Objects 1,2 Sekunden ohne nur noch 1 Sekunde. Elasticsearch cached bei den nächsten Aufrufen und wir erhalten schließlich Zeiten von ca. 200ms. Hierbei sei zusätzlich erwähnt, dass ich sowohl MySQL als auch Elasticsearch nicht getuned habe.

Fazit

Sollte man bei der Entwicklung auf komplexe SQL-Queries stoßen, die nicht performant laufen, so kann es eine Überlegung wert sein, eine Suchmaschine wie Elasticsearch zu involvieren. Elasticsearch unterstützt Relationen, mit Nested Objects bzw. Parent-Child. Mein kleiner Test hat gezeigt, dass Nested Objects initial ca. 20 % langsamer sind. Parent-Child-Abfragen sind laut Dokumentation [3] 5-10 mal behäbiger als eine Nested Query. Im Vergleich zu MySQL ist in meinem Testaufbau zu sehen, dass Elasticsearch ca. 10-mal performanter ist.

Links

[1] https://web.liferay.com/en/documentation/liferay-portal/6.2/release-notes
[2] http://blog.exensio.de/2016/04/olap-cube-vs-elasticsearch.html
[3] https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html

Geschäftsprozesse mit BPMN Tools wie Bizagi, Yaoqiang oder Camunda Modeler modellieren

noreply@blogger.com (Irving Tschepke) — Wed, 04 May 2016 15:54:00 +0000

Nachdem ich zuletzt Prozesse noch vorwiegend mittels der EPK Methode (ereignisgesteuerte Prozessketten) modelliert habe, bin ich aktuell zur Business Process Modell and Notation – kurz BPMN – gewechselt.

Warum? BPMN wird zunehmend in Unternehmen eingesetzt (und an den Hochschulen gelehrt) und es ist ein Hersteller-neutraler Standard. BPMN wurde auch für die Umsetzung von Prozessen durch IT Lösungen entwickelt – unter Nutzung einer BPM Engine.

Zudem ist die Notation einfach zu verstehen und eignet sich daher gut zur Diskussion von Prozessen mit den Fachbereichen – was letztlich mein Hauptgrund für den Einsatz ist.

Beim Entwurf der Prozesse stellt sich sehr schnell die Frage nach einer geeigneten Tool Unterstützung. Auch wenn das „Malen“ erst mal im Vordergrund steht, wollte ich Visio und ähnliche Tools nicht nutzen. Mein erster Versuch mit draw.io war beispielsweise wenig zufriedenstellend.

Mit dem Ausblick auf eine zukünftige umfangreichere Nutzung habe ich Ausschau nach einem kostengünstigen BPMN Modellierungstool gehalten.

Hier kurz meine zusammenfassenden Erkenntnisse:

Einen guten Einstieg in die Thematik liefert der Blog „Kurze Prozesse“ von Thomas Allweyer, der sich als Experte intensiv dem Thema Geschäftsprozessmanagement und BPM widmet (und bspw. auch ein Buch über BPMN 2.0 geschrieben hat). In seinem Beitrag „Kostenfreie Modellierungstools im Test“ findet sich ein guter Startpunkt für die Suche nach dem geeigneten Tool.

Eine ältere Version des Modellierungstools von Bizagi hatte ich noch auf meinem Rechner – dieses hatte ich mir mal vor einiger Zeit kurz angeschaut. Der Einstieg war leicht und die Bedienung sehr angenehm. Den vorgeschlagenen Upgrade auf die neueste Version habe durchgeführt. Danach konnte ich das Tool nur noch nach Registrierung verwenden.

Durch einen Beitrag von Thomas Allweyer habe ich mir noch kurz Yaoqiang angeschaut. Das Tool basiert auf Java und erfüllt alle Ansprüche zum Erstellen der Prozesse. Vom Handling und der Oberflächengestaltung erinnert es mich stark an Visio.

Ein weiteres Werkzeug habe ich ausprobiert: den Camunda BPMN Modeler. Dieser kann unabhängig von der BPM Plattform von Camunda genutzt werden. Technisch basiert das Tool auf der Web-Modellierungsumgebung bpmn.io. Auf diese war ich bei meiner Web Recherche auch gestoßen und war von der einfachen Bedienung begeistert. Mit dem BPMN Modeler habe ich nun den gleichen Bedienungs-Komfort aber ohne eine notwendige Online Verbindung.

Nach meiner kurzen Evaluierung bin ich beim Camunda Modeler „hängen geblieben“. Kostenfrei, keine Registrierung und sehr einfach und intuitiv zu bedienen. Auch nach einiger Zeit der Nutzung bin ich noch begeistert – die Modellierung geht eminent schnell mit dem Tool. Entsprechende Export Funktionen sind vorhanden, um die Modelle in die von Kunden gewünschten Dokumentationen einzufügen.

Eine IT-gestützte Umsetzung war nicht in meinem Fokus. Dennoch könnten diese Modelle später in der Open Source BPM Plattform von Camunda implementiert werden.

Wer sich mit BPMN noch nicht so intensiv auseinander gesetzt hat, findet bei Camunda im Übrigen jede Menge Informationen. Sehr hilfreich sind beispielsweise die Best Practices.

Ergonomische Arbeitsplätze bei exensio

noreply@blogger.com (Peter Soth) — Fri, 29 Apr 2016 10:00:00 +0000

Wieder einmal eine nichttechnische Information von uns :-).

Schmerzen, Müdigkeit oder Erschöpfung treten nicht selten nach einem langen Arbeitstag auf. Der Grund hierfür: Einseitige körperliche Belastungen sind ungesund und führen eines Tages zu Problemen. Die Ergonomie am Arbeitsplatz darf keinesfalls zu kurz kommen, da Krankheiten des Bewegungsapparates für die meisten Krankenstandstage verantwortlich sind. Die passende Arbeitsplatzgestaltung sowie eine korrekte Sitzhaltung ist daher äußerst wichtig.

Wir haben nun all unsere Schreibtische durch elektrisch höhenverstellbare ersetzt. Mal schauen, wann sich die ersten Symptome eines Muskelkaters vom langen Stehen einstellen :-)

OLAP Cube vs. Elasticsearch

noreply@blogger.com (Peter Soth) — Sat, 23 Apr 2016 14:18:00 +0000

In diesem Blog-Post möchte ich die Möglichkeiten aufzeigen, die Elasticsearch im Bereich Business Analytics bietet. Als Basis benutzte ich wiederum Testdaten aus der Publikation »Excel 2010 im Controlling« [1], das im Verlag Rheinwerk (früher Galileo Computing) erschienen ist. Diesmal ist es eine CSV-Datei mit 1,5 Millionen Zeilen. Da diese für Excel zu umfangreich ist (~1 Million Zeilen Limit in Excel 2007), wird im Buch PowerPivot und OLAP Cubes (auch als Datenwürfel bezeichnet) in Kombination mit dem Microsoft SQL Server benutzt.

OLAP ist die Abkürzung für »Online Analytical Processing« und dient der Abfrage von mehrdimensionalen Informationen, analog zu einer Pivot-Tabelle. In unserem Beispiel ist die erste Dimension das Land, die zweite das Produkt und die dritte das Jahr (zeitliche). Die Dimensionen können in einem OLAP-Cube je nach Anforderung flexibel gewählt werden, jedoch sind spätere Änderungen äußerst aufwändig. Des Weiteren gibt es noch die Faktentabellen, die mathematische Auswertungen, wie berechnete Umsätze enthalten. Solch ein Datenbankschema wird auch als Star-Schema bezeichnet. Vorteil des Star-Schemas besteht darin, dass nur eine geringe Anzahl von Joins benötigt werden (bessere Performance bei großen Datenmengen einer RDB). Die Abfrage von OLAP-Cubes erfolgt mit einer speziellen Sprache, genannt MDX (Multidimensional Expressions).

In Elasticsearch wird dies alles nicht benötigt. Die Daten müssen demzufolge nicht voraggregiert in ein Star-Schema geladen werden, sie werden einfach flach (denormalisiert) in einem JSON-Dokument gespeichert. Will man Relationen in Elasticsearch verwenden, so gibt es die Möglichkeit »Nested Objects« bzw. »Parent/Child Relationships« zu benutzen. In meinem Beispiel habe ich zu Testzwecken »Nested Objects« für die Kunden und die Produkte eingefügt. Man sollte jedoch darauf verzichten, sofern es machbar ist, da dies komplexere Abfragen gegen Elasticsearch bewirkt.

Folgendes Python-Skript erzeugt das Elasticsearch-Schema:
Mit folgendem Python-Skript erzeuge ich das JSON-File für den Bulk-Import in Elasticsearch. Es werden auch gleich noch die 1:n und m:n Relationen aufgelöst und als »Nested Objects« gespeichert. Die Datei ist zum Schluss ca. 1 GByte groß, mit dem Linux Befehl split (split -l 700000 olap_test.json ./bulk) habe ich dieses dann in kleinere Happen aufgeteilt und mit mehreren Imports (curl -XPOST localhost:9200/_bulk --data-binary @bulkaa) in Elasticsearch importiert.Folgendes Python-Skript zeigt die Abfrage gegen Elasticsearch, die benötigt wird, um die Pivot-Tabelle aufzubauen. Das Skript enthält auch die Query für die Nested Objects. Hierbei sieht man sehr schön, dass diese um einiges komplexer ist. Ich habe auch die Zeiten ausgegeben, die Elasticsearch benötigt. Diese sind beim initialen Aufruf fast gleich. Bei mehrmaligem Aufruf greift der Cache, dann ist die Nested Query um ca. 30% langsamer. Ich habe meinen Elasticsearch-Server in keiner Weise optimiert. Am Ende des Python-Skripts findet sich noch die ausgegebene Tabelle. Das Ergebnis sieht folgendermaßen aus:

+-----------+------------------------------------+-------------+-------------+-------------+
| Land      | Kunde                              | Umsatz 1994 | Umsatz 1995 | Umsatz 1996 |
+-----------+------------------------------------+-------------+-------------+-------------+
| Brazil    |                                    |             |             |             |
|           | Hanari Carnes                      |  232872.00  |  181903.08  |  944863.26  |
|           | Queen Cozinha                      |       0.00  | 2704507.80  | 1017204.30  |
|           | Ricardo Adocicados                 |   79852.56  |  485725.92  |  621214.02  |
|           | Que Delícia                        |   17747.10  |  491754.30  |  105637.50  |
|           | Wellington Importadora             |   26235.66  |  108304.26  |  231125.46  |
|           | Gourmet Lanchonetes                |       0.00  |  521745.96  |   83500.20  |
|           | Familia Arquibaldo                 |    5821.80  |  431282.70  |       0.00  |
|           | Tradição Hipermercados             |    2535.30  |  236947.26  |  276141.12  |
|           | Comércio Mineiro                   |  149676.60  |  146333.76  |   56055.82  |
| Venezuela |                                    |             |             |             |
|           | HILARIÓN-Abastos                   |  153826.98  | 1487469.90  |  720745.36  |
|           | LILA-Supermercado                  |  248947.68  |  576151.62  |  553818.20  |
|           | LINO-Delicateses                   |       0.00  |  834376.62  |  431038.56  |
|           | GROSELLA-Restaurante               |  124492.62  |       0.00  |    2835.78  |
| Mexico    |                                    |             |             |             |
|           | Tortuga Restaurante                |  306696.18  |  448316.16  |  137876.06  |
|           | Antonio Moreno Taquería            |   41316.00  |  353233.02  |  109731.54  |
|           | Pericles Comidas clásicas          |  101787.60  |  286977.18  |  132695.20  |
|           | Ana Trujillo Emparedados y helados |    3023.58  |  104961.42  |   74969.76  |
|           | Centro comercial Moctezuma         |    6103.50  |       0.00  |       0.00  |
| Argentina |                                    |             |             |             |
|           | Cactus Comidas para llevar         |       0.00  |   32339.16  |  104296.86  |
|           | Océano Atlántico Ltda.             |       0.00  |   71270.10  |  504599.82  |
|           | Rancho grande                      |       0.00  |  115290.42  |  296329.62  |
+-----------+------------------------------------+-------------+-------------+-------------+

Fazit

Anhand dieses Beispiels kann man m.E. überaus schön sehen, dass sich mit Elasticsearch auch im Bereich Business Analytics einiges bewerkstelligen lässt. Man muss kein Star-Schema aufsetzen und dieses über nächtliche Aggregationen laden. Ebenso ist das Erlernen von MDX oder eine Einarbeitung in andere BI-Tools nicht notwendig. Besonders interessant wird solch eine Lösung, wenn man noch die Volltextsuche in dieses Szenario integriert. So könnte man beispielsweise nach dem Kundennamen suchen. Bei einem riesigen Kundenkreis ist dies bestimmt schneller als das Filtern in einer Tree-View in einem klassischen BI-Tool. Einige BI-Tools verfügen auch über eine Suche, aber eine Suchmaschine kann hier beispielsweise mit einer Fuzzy-Search (Kundennamen werden dann auch noch mit Schreibfehlern gefunden) noch mehr punkten.

Links

[1] https://www.rheinwerk-verlag.de/excel-2010-im-controlling_2289/

Latest jQuery with Grails 2 and the resources plugin

noreply@blogger.com (Florian Mutter) — Fri, 15 Apr 2016 14:40:00 +0000

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.

RSS Feeds mit Logstash und Elasticsearch durchsuchen

noreply@blogger.com (Peter Soth) — Tue, 12 Apr 2016 16:18:00 +0000

In diesem Blogpost möchte ich aufzeigen, wie man RSS Feeds mit Logstash und Elasticsearch durchsuchen kann. Folgendes Logstash-Skript holt sich alle 2 Stunden Informationen aus der Logistikbranche.
Und folgendes Python-Skript ermöglicht das Dursuchen des RSS-Feeds. Die Elasticsearch-Query liefert keine Dubletten (da ja alle 2 Stunden der RSS-Feed indiziert wird) zurück. Dies wird mit Hilfe einer top_hits Aggregation erreicht.
Und so sieht das Ganze in Aktion aus:

Natürlich kann die Abfrage auch in einer Web-Applikation bereitgestellt werden. Python wurde hier nur zur Veranschaulichung benutzt.

CeBIT 2016

noreply@blogger.com (Tobias Kraft) — Mon, 21 Mar 2016 06:55:00 +0000

Auf der diesjährigen CeBIT durfte ich einen Vortrag mit dem Thema "Die Suche macht den Unterschied" halten.

Die Präsentation fand im Rahmen der vom Heise-Verlag organisierten developer world statt. Da ich gleich um 10 Uhr die erste Präsentation hatte, dachte ich, dass sich nicht allzu viele Zuhörer einfinden würden. Zum Glück erwies sich dies als Trugschluss und nach den ersten Vortrags-Minuten gingen die Sitzplätze im Auditorium zu Neige und die neu eingetroffenen Hörer mussten sich mit Stehplätzen begnügen.

Was gibt es sonst noch zur CeBIT zu sagen?

Die CeBIT ist nach wie vor ein enormer Besuchermagnet, bei der man alle Altersklassen antrifft, die sich für moderne IT-Technologien interessieren. Erschreckend fand ich dagegen beim Durchschlendern der Hallen, wie beinahe auf jedem Stand die Banner mit den selben Buzzwörtern (IoT, Digitalisierung, ..) versehen waren und zwanghaft die Aufmerksamkeit erringen wollten.

Javaland 2016

noreply@blogger.com (Tobias Kraft) — Thu, 10 Mar 2016 08:25:00 +0000

Dieses Jahr besuchte ich das erste Mal die Javaland-Konferenz im Phantasialand in Brühl. Die Lokation ist für eine Konferenz natürlich etwas Außergewöhnliches, und spätestens als am ersten Abend die Fahrgeschäfte aufmachten, leuchteten die Augen der Teilnehmer wie bei kleinen Kindern.

Mit meinem Kollegen Ralf Müller durfte ich einen Vortrag zum Thema Testen mit Spock und Geb unter Einbeziehung des Fachbereiches halten. Die Problematik der nachvollziehbaren Tests für den Fachbereich scheint viele Entwickler anzusprechen, da sie offensichtlich ähnliche Probleme haben, wie nachträgliche Diskussionen zeigten.

Die von mir besuchten Sessions auf der Konferenz waren durchweg qualitativ hochwertig. Neben Hype-Themen wie Microservices oder Container, die meiner Wahrnehmung nach aktuell auf jeder Konferenz zu finden sind, gab auch zahlreiche klassische Vorträge zu Java, die einen Besuch wert waren.

Hier ein Auszug meiner gehörten Vorträge:

JUnit Lambda - the Next Generation (Jens Schauder)
Netter Überblick über die Neuerungen in der nächsten JUnit Version. Ich ziehe Spock aber aufgrund der Lesbarkeit nach wie vor jederzeit als Testframework vor.
Fun in groovyLand (Dierk König)
Allergrößten Respekt, dass Dierk die ersten 15 Minuten der Session ohne Beamer auskommen musste, und dies bravourös mit seinem gewohnt angenehmen Vortragsstil meisterte. Anschließend zeigte er einige Szenarien auf wie mit groovy kompakt und doch übersichtlich Code produziert werden kann.
Hacking Java (Sean Floyd)
Der Titel-Name war Programm und es wurden Tricks gezeigt, die ich eigentlich nur in Notfällen anwenden möchte.
Mit Vert.x vom Monolithen zum reaktiven Microservice (Jochen Mader)
Nachdem Jochen zunächst sehr schön auf die Probleme von verteilten Applikationen und damit auch Mikroservices einging, zeigte er auf wie vert.x OutOfTheBox den Übergang von einer monolithischen in eine verteilte Applikation unterstützt.
IoT with Apache ActiveMQ, Camel & Spark (Burr Sutter)
Mit Hilfe von iBeacons, die wir ebenfalls bei unserem letzten ShipIt-Day nutzen, wurden einige IoT-Szenarien aufgezeigt und ich konnte mir Ideen für die Weiterentwicklung unserer eigenen Applikation holen.