Herzlich willkommen auf dem Blog der exensio GmbH

exensio ist ein unabhängiges Software-Unternehmen von erfahrenen IT Beratern und Architekten. Zu unseren Kunden zählen namhafte deutsche Großunternehmen.

exensio verbessert das Kommunikations- und Informationsmanagement von Unternehmen. Auf Basis sinnvoller und zweckmäßiger Technologien erarbeiten wir flexible und übergreifende Lösungen für webbasierte Informationssysteme. Abhängig von den Kundenanforderungen realisieren wir Web Applikationen sowie Lösungen auf Basis von Web Content Management- und Portalsystemen. Integrativ, wirtschaftlich und anwenderfreundlich!

Hier gelangen Sie zur exensio GmbH.

Montag, 25. Juli 2016

Integration mit SEEBURGER Business Integration Suite

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.

Montag, 18. Juli 2016

Interaktive Browser-Automatisierung mit Geb und der Groovy-Shell

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.

Freitag, 1. Juli 2016

Lizenzanalyse mit dem Open Source Tool ScanCode toolkit

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.

Freitag, 24. Juni 2016

Warum sich Responsive Design für Intranet Applikationen lohnt

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.

Mittwoch, 22. Juni 2016

HTML als HTML in Grails anzeigen

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!

Donnerstag, 16. Juni 2016

Requirements Engineering nach IREB

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.