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.

Freitag, 8. Januar 2016

Quo vadis Pharmavertrieb?

„Quo vadis Pharmavertrieb?“ ist der Titel eines Artikels von exensio in der Ausgabe 12/2015 des „pharmaberaters“. Der Beitrag beschreibt die Herausforderungen im Pharmamarketing und –vertrieb und zeigt Lösungsszenarien durch den Einsatz eines gezielten IT-Informationsmanagements auf. Wer mehr erfahren will, kann den vollständigen Artikel hier lesen.

Mittwoch, 6. Januar 2016

REST API testen mit Node.js, Mocha und Chakram - auch für Java Entwickler

In diesem Blog-Post möchte ich aufzeigen, wie man Node.js [1], Mocha [2] und Chakram [3] für das Testen von REST APIs benutzt und warum Selbiges auch für Java-Entwickler, die eigentlich gar nichts mit Node.js am Hut haben, interessant sein kann.

So benutzen wir JUnit für Unit-Tests und das Gespann Geb / Spock für Integrations- bzw. Funktionale Tests. Diese werden entweder während der Programmierung innerhalb von IntelliJ gestartet oder über den täglichen Build mittels Jenkins (Continuous Integration) ausgeführt.

Sollen die Tests jedoch direkt in der Infrastruktur des Kunden laufen, so scheitert dieser Ansatz. Die funktionalen Tests des Web-Frontends kann man noch per Testspezifikation und manuellen Tests abdecken, aber wie sieht es bei einer REST API aus? Wollte man hier händisch vorgehen, könnte man dies mit vorbereiteten Testdaten bewerkstelligen, die zusammen mit cURL Aufrufen benutzt werden. Geht das nicht auch automatisiert?

Folgende Eigenschaften sollte ein automatisiertes Framework erfüllen:
  • Das Framework sollte nicht aus dem Java-Stack kommen. Hierdurch kann man sicherstellen, dass sich nicht potentielle Java-Fehler in die REST-Schnittstelle »einschleichen«.
  • Es sollte auf unterschiedlichen Betriebssystemen unkompliziert installierbar sein. So fand ich für Python Lösungen, diese waren jedoch unter Windows nicht einfach aufzusetzen.
  • Eine Validierung von komplexen Datentypen wie UUIDs oder Datumswerte nach ISO 8601 [4] sollte möglich sein.
  • Die Formulierung der Testfälle sollte simpel und deklarativ sein. 
  • System-Tests sollen möglich sein, sprich die REST-API sollte nicht nur innerhalb des Tomcats getestet werden, sondern auch über den als Load-Balancer vorgeschalteten Apache-Web-Server.
Schließlich bin ich bei Chakram im Kontext von Node.js und Mocha fündig geworden. Eigentlich wollte ich nicht mit Node.js und Javascript arbeiten, aber nach einer kurzen Einarbeitungszeit fand ich das Ganze nicht mehr so schlecht und das Validator-Package [5] von Node.js nahm mir schlussendlich sehr viel Arbeit bei der Validierung ab.

Die Modularisierung und Wiederverwendung von Javascript-Code innerhalb von Node.js kostete mich dann doch etwas Zeit, deshalb folgt im Souce-Code unten meine Utility-Methode validateHTTPMethods().


Mittels require wird die utility.js dann in den Test-Cases benutzt. Des Weiteren sieht man in folgendem Source-Code sehr schön wie einfach und deklarativ Test-Cases geschrieben werden können:

Fazit

Meines Erachtens eignet sich das Gespann Node.js, Mocha und Chakram sehr gut für das Aufsetzen von deklarativen und kompakten Testcases. Vor allem das Validator-Plugin ermöglicht die einfache Validierung von unzähligen Datentypen.

Links

[1] https://nodejs.org/en/
[2] https://mochajs.org/
[3] http://dareid.github.io/chakram/
[4] https://en.wikipedia.org/wiki/ISO_8601
[5] https://www.npmjs.com/package/validator

Dienstag, 15. Dezember 2015

Synology DiskStation per SNMP überwachen

In diesem Posting zeige ich, wie man ein DiskStation NAS von Synology mit einem Monitoring System überwachen kann.

Übersicht

Im Büro kommen einige DiskStation NAS von Synology als FileStore und zu Backup Zwecken zum Einsatz. Der Betrieb dieser Geräte geschieht weitgehend im Hintergrund, so dass Probleme mit den Geräten vermutlich erst bei deren Ausfall ans Licht treten würden. Die genannten Geräte sind 24 Stunden pro Tag in Betrieb. Die Aufgabe bestand deshalb darin, die DiskStations Geräte ins Monitoring einzubeziehen, so dass sich ankündigende Schwierigkeiten rechtzeitig erkannt werden können. Insbesondere soll frühzeitig informiert werden, wenn Plattenplatz knapp wird.

Lösung

Als einfachste Lösung erschien mir die Verwendung des Plugins check_snmp_synology [1] von Nicolas Ordonez, welches auf Nagios Exchange zur Verfügung steht. Das Plugin wurde in den vergangengen Monaten einigermaßen häufig aktualisiert und relativ gut bewertet.

Das Plugin ist speziell für DiskStation NAS des Herstellers Synology geschrieben worden und basiert auf SNMP-Abfragen an die Geräte. Zuerst muss deshalb die SNMP-Funktion im NAS, welche im Auslieferungszustand ausgeschaltet ist, aktiviert werden.

Bei genauerer Betrachtung des Plugins stellte sich heraus, dass es einige kleinere Nachteile aufwies. So prüft es beispielsweise standardmäßig, ob ein Update für die NAS Firmware zur Verfügung steht. Die Erfahrung mit Firmware Updates hat allerdings gezeigt, dass der Nutzen nicht in Relation zum Aufwand steht, so dass wir uns gegen Firmware Updates auf den Geräten entschieden haben. Diese Tatsache führte beim ursprünglichen Plugin allerdings immer zu einem kritischen Gerätezustand („CRITICAL“). Aus diesem Grund habe ich das Plugin dahingehend angepasst, dass die standardmäßige Firmware Update Prüfung in eine optionale Funktion ausgelagert wurde. Die zweite Anpassung betrifft die Ausgabe der Ergebnisse des Plugins. Hier lege ich Wert auf Performance-Angaben (PerfData) und habe deshalb den Parameter „-f“ implementiert. Damit gibt das Plugin Performance Werte zurück, die von Nagios entsprechend verarbeitet werden können. Mit diesen Änderungen stand einer Verwendung des Plugins nichts im Wege. Den Quellcode des angepassten Plugins habe ich auf GitHub zur Verfügung gestellt [2].

Wie oben erwähnt basiert das Plugin auf SNMP-Anfragen an die DiskStation Geräte. SNMP setzt auf die Verwendung einer gemeinsamen Management Information Base (MIB). Synology stellt für seine DiskStations eine eigene MIB zur Verfügung, wie im MIB Guide [3] beschrieben. Die MIB ist entsprechend in den DiskStations bereits hinterlegt. Im Monitoring System muss sie aber natürlich installiert werden. In einem früheren Posting [4] habe ich beschrieben, wie man MIBs unter Linux installiert und testet.

Sofern die MIB korrekt installiert wurde und SNMP auf dem NAS aktiviert ist, erfordert das Plugin keine weiteren Maßnahmen und kann direkt ausgeführt werden. Mein Kommando dafür sieht wie folgt aus:
define command {
  command_name                   check_snmp_synology
  command_line                   $USER2$/check_snmp_synology -2 public -v -h $HOSTADDRESS$ -f -W $ARG1$ -C $ARG2$ -w $ARG3$ -c $ARG4$
}

Und der Service für eines der Geräte sieht so aus:
define service {
  service_description            check_snmp_synology_demo
  host_name                      demo_host
  use                            check_mk_active
  check_command                  check_snmp_synology!public!45!48!85!90
}

Durch die Verwendung des PerfData Parameters übermittelt das Plugin Rückgabewerte, die sich im Monitoring System in einer ansehnlichen Grafik präsentieren lassen:

Fazit

Mit dem vorgestellten Plugin lassen sich Synologys DiskStations mit geringem Aufwand in ein bestehendes Monitoring System einbinden. Auf diese Weise lässt sich einfach und schnell sicherstellen, dass drohende Ausfälle rechtzeitig erkannt werden. Dank Open-Source war es sogar möglich, das Plugin an die eigenen Bedürfnisse anzupassen. Der ursprüngliche Autor hat auf meine Anfragen leider nicht reagiert, so dass ich meine Änderungen leider nicht diskutieren konnte.

Links

[1] https://exchange.nagios.org/directory/Plugins/Network-and-Systems-Management/Others/Synology-status/details
[2] https://github.com/exensio/synology-nagios-plugin
[3] http://global.download.synology.com/download/Document/MIBGuide/Synology_DiskStation_MIB_Guide.pdf
[4] http://blog.exensio.de/2015/07/lancom-router-per-snmp-uberwachen.html

Mittwoch, 9. Dezember 2015

Excel2Web: Self Contained Web Apps mit Vaadin und Jetty

Für interne Workflows werden nach wie vor häufig Tabellenkalkulations-Programme wie Excel verwendet, selbst dann wenn Excel-Sheets der Aufgabe nicht mehr gewachsen sind. Ein wichtiger Grund dafür dürfte sein, dass maßgeschneiderte Anwendungen für interne Abläufe häufig zu teuer erscheinen. Dabei können entsprechende Business-Applikationen mit den richtigen Werkzeugen schnell erstellt werden und dann Monat für Monat Aufwand sparen. Eine Amortisation ist somit schon nach kurzer Zeit möglich.

Für einen Kunden haben wir zur Verbesserung betriebsinterner Abläufe eine Web-Applikation mit Vaadin entwickelt, die vollständig self contained als "fat jar" ausgeliefert und gestartet werden kann.

Das vorliegende Business-Intelligence-System extrahiert eine Vielzahl von Attributen aus verschiedenen Quellen im Web. Dabei kommt es immer wieder zu Problemen da die zugehörigen Webcrawler an Änderungen der entsprechenden Websites angepasst werden müssen. Um eine grobe Übersicht über die Qualität der jeweils aktuellen Daten zu erhalten, werden diese quantitativ mit den Vormonats-Daten verglichen. Dabei kommen bei dem Kunden bisher Kapow-Robots zum Einsatz, welche im Wesentlichen SQL-Abfragen ausführen und eine Excel-Datei erzeugen. Diese enthält zu verschiedenen Attributen die Anzahl der gefundenen Objekte auf einer Website im aktuellen Monat und den zugehörigen Vergleichswert aus dem Vormonat. Den Vergleich führt anschließend aktuell ein Mitarbeiter manuell durch.

Um das umständliche manuelle Verfahren zu vereinfachen und zu beschleunigen, haben wir für den Kunden eine Web-Applikation entwickelt, mit welcher die Abfragen online ausgeführt werden können.

Altes Excel-Sheet (Daten anonymisiert)

Vaadin-Webapp (Daten anonymisiert)
Als Grundlage dient uns das Vaadin-Framework, mit dem sich sehr schnell ansprechende und moderne Rich Internet Applications entwickeln lassen. Damit beim Kunden keine aufwendige Installation nötig wird, haben wir uns entschieden, die Applikation als ausführbare JAR-Datei mit allen nötigen Abhängigkeiten (sog. "fat jar") zu deployen. Dabei enthält die Anwendung auch die Jetty Servlet Engine, um vollständig selbstständig lauffähig zu sein.

Ein solches JAR lässt sich u. a. mit Gradle und dem Shadow Plugin erstellen:

apply plugin: "com.github.johnrengelman.shadow"

jar {
    manifest {
        attributes('Main-Class': 'com.exensio.MyVaadinApplication',
                'Built-By': System.getProperty('user.name'),
                'Build-Jdk': System.getProperty('java.version'),
                'Implementation-Title': project.name,
                'Implementation-Version': project.version,
                'Implementation-Vendor-Id': project.group)
    }
}

Um den eigentlichen Anwendungsserver kümmert sich dann der folgende Code in der main-Methode der Klasse MyVaadinApplication:

final Server server = new Server(HTTP_PORT);

final ServletContextHandler handler = new ServletContextHandler(ServletContextHandler.SESSIONS);
server.setHandler(handler);

final ServletHolder servletHolder = handler.addServlet(VaadinServlet.class, "/*");
servletHolder.setInitParameter("UI", MyVaadinUI.class.getName());

if (isProductionMode()) {
 servletHolder.setInitParameter("productionMode", "true");
}

server.start();
server.join();

Wichtig dabei ist, für den ServletContextHandler bei dessen Instanziierung die Unterstützung für Sessions (ServletContextHandler.SESSIONS) zu aktivieren, da Vaadin ohne diese nicht lauffähig ist.

Selbstverständlich berät exensio Sie gern auch bei der Ablösung Ihrer Excel-Workflows durch einfach zu bedienende (Web-)Applikationen.

Montag, 30. November 2015

File Upload bei funktionalen Tests in Grails

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

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

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

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


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

Donnerstag, 19. November 2015

Informationen aus SharePoint 2013 für besseres Wissensmanagement zusammenführen

Im diesjährigen Intranet Design Annual [1] der Norman Nielson Group nutzt die Hälfte der mit einem "best-designed" Intranet ausgezeichneten Organisationen Microsoft SharePoint 2013. Auch in Gesprächen mit unseren Kunden wird bewusst, dass SharePoint in vielen Unternehmen präsent ist.

In diesem Blog Post wird aufgezeigt, wie sich eine Stärke von SharePoint schnell - und gleichzeitig schleichend -  zur Krux für das gesamte Wissens- und Informationsmanagement eines Unternehmens entwickeln kann. Der Blog Post zeigt eine Lösungsmöglichkeit auf, bei der die bestehende SharePoint-Infrastruktur nicht verändert werden muss und dem Unternehmen ein immenser Mehrwert durch das übersichtliche Bereitstellen von dokumentiertem Wissen geboten wird.

SharePoint und das dezentrale Informationsmanagement

Die Philosophie von SharePoint setzt stark auf dezentrales Management von Informationen. Dies lässt sich einfach am Beispiel eines Intranets aufzeigen: Sobald mehrere Bereiche oder Abteilungen auf der SharePoint-Infrastruktur definiert sind (Site Collections), gibt es keine Möglichkeit, eine übergreifende, einheitliche Navigation über diese Bereiche abzubilden. Das klingt verwunderlich - passt aber in das von Microsoft propagierte Konzept des dezentralen Managements. Jeder Bereich ist selbst für seine Informationen verantwortlich, Nutzer müssen manuell zu den Informationstöpfen navigieren, die für Sie interessant sind. Eine personalisierte Unterstützung ist nicht vorhanden (und nicht vorgesehen).

Eine einheitliche und personalisierte Navigation ist einem Digital Workplace jedoch kein "nice 2 have"-Feature - sie ist eine essentielle Unterstützung für alle Mitarbeiter, die regelmäßig aus verschiedenen Bereichen Informationen benötigen. Sie hilft zudem ein konsistentes Design zu etablieren, Bereichsgrenzen zu eliminieren und dem Mitarbeiter einen Single Point of Access zu gewähren. Das spart dem Mitarbeiter Zeit und dem Unternehmen Kosten.

Gleichwohl ist einfaches Erstellen von separaten Bereichen ein Segen für all diejenigen, die schnell Informationen für ein Team bereitstellen wollen. Es entfallen "lästige" Absprachen oder langwierige Prozesse über die Frage, wie gewisse Bereiche in der gemeinsamen Navigation vertreten sind - der eigene Bereich ist schnell und unkompliziert erstellt und per Link verteilt.
Hat ein Unternehmen an dieser Stelle keine Governance-Prozesse etabliert, entstehen unkontrolliert täglich neue TeamSites (so der Fachbegriff), die zu verschiedensten Zwecken eingesetzt werden: Vorstellungen von Abteilungen, Zusammenarbeit in Teams, Dokumenten-Sharing zwischen Bereichen, Projekträume für zeitlich begrenzt laufende Projekte,...
Eine Übersicht über die vorhandenen Informationen geht schnell verloren und wichtiges Wissen bleibt anderen verborgen.

Konsolidieren und Aggregieren von Informationen 

Um der Informationsflut gerecht zu werden, bietet es sich für Unternehmen an, Informationen aus den verschiedenen Töpfen zu aggregieren um sie dann einheitlich und gesammelt darstellen zu können. Dies kann in Form von Dashboards oder Themenseiten erfolgen. 
Durch den zentral gesteuerten Ansatz der Aggregation kann sichergestellt werden, dass sich alle Themenseiten in einem einheitlichen Layout darstellen und dem Mitarbeiter so auf einen Blick Zugang zu Informationen gewähren, die bis dato unbekannt oder verborgen waren.
Kofax Kapow [2] ist eine Plattform für die Informationsintegration, insbesondere von Websites und Webportalen. Mit der Software lassen sich sogenannte Robots erstellen, verwalten und steuern. Entsprechend programmierte Robots können Inhalte aus den SharePoint TeamSites extrahieren, abspeichern und bieten somit die Basis für die einheitliche Darstellung in Form von Dashboards/Themenseiten.


SharePoint bietet in der teuersten Lizenzvariante die Möglichkeit auch mit Bordmitteln Informationen verschiedener Site Collections zu aggregieren. Hierbei sind die zusätzlich entstehenden Lizenzkosten, die Konfiguration der Farm-übergreifenden Suche und die dadurch entstehenden Auswirkungen auf die existierende Suche zu beachten. Der Suchindex enthält zudem nicht alle Daten (z.B. Linklisten in WebParts), die mit Kapow abgefragt werden können.

Kosten von SharePoint-Projekten

Häufig werden SharePoint-Projekte als günstige Alternative gegenüber alternativen Portalprojekten dargestellt. Die Gründe hierfür sind vielfältig, meist aber damit zu erklären, dass SharePoint bereits im Unternehmen existiert (häufig im Zusammenhang mit anderen Microsoft-Produkten bzw. Lizenzen), von der IT installiert wurde und andere Abteilungen "schleichend" nach und nach Informationen darin speichern. Schnell kommt es zum eingangs beschriebenen Phänomen: viele TeamSites entstehen ohne Planung, es fehlt ein einheitliches Konzept, Informationen bleiben anderen verborgen, Schulungen für Editoren und Nutzer sind nicht vorhanden bzw. werden nicht koordiniert. Massive Kosten für eine Konsolidierung entstehen demnach in der Regel erst nach Abschluss des SharePoint-Projekts.

In anderen Portal-Projekten finden anfangs Konzeptarbeiten statt, so dass verschiedene Systeme personalisiert für den Mitarbeiter integriert werden können. Dies verursacht selbstverständlich höhere Kosten zu Beginn - sichert aber eine langfristige Strategie, welche die Folgekosten gering hält.
Es ist demnach stark zu bezweifeln, dass SharePoint-Projekte wirklich günstiger sind, wenn man alle Parameter und die Gesamtlaufzeit des Portals betrachtet.

Bei einer Kostenanalyse dürfen zudem der Nutzen eines Systems und die indirekt entstehende Kosten nicht außer Acht gelassen werden: Ein IT-Projekt kann auch dann für die IT-Abteilung günstig sein, weil Anforderungen des Fachbereichs gestrichen werden. So wird SharePoint schnell "out of the box", sprich nur mit Konfigurationen und ohne zusätzliche Features, eingeführt und die IT-Kosten werden durch das Weglassen von Konzepten, Entwicklungen und Support gesenkt.
Für alle anderen Abteilungen, die mit dem eingeführten System arbeiten müssen, steigen jedoch die eigenen Kosten, da angefragte Anforderungen nicht umgesetzt sind und Zusatzaufwände durch umständlichere Prozesse oder mangelhafte Usability generiert werden.
Eine ganzheitliche Kostenbetrachtung ist demnach unumgänglich.

Fazit

Die dezentrale Funktionsweise von Microsoft SharePoint erlaubt zwar das schnelle Bereitstellen von Informationen, sorgt aber gleichzeitig für eine unübersichtliche Informationslandschaft, in der sich Mitarbeiter schnell verloren fühlen können und Informationen vielen verborgen bleibt.
Für Unternehmen sind insbesondere Governance-Konzepte wichtig, die sicherstellen, dass das Anlegen neuer TeamSites einem bestimmten Prozess folgt.

Einen Mehrwert schafft eine gesammelte Datensicht auf mehrere TeamSites, die mithilfe der Aggregation von Daten über Kofax Kapow bereitgestellt werden kann. Kapow kann unterschiedliche Quellsysteme integrieren, ohne dass diese ihrerseits verändert oder angepasst werden müssen und bietet daher eine optimale Lösung für die Verbesserung des eigenen Informationsmanagement.

Links

[1] Intranet Design Annual der Norman Nielson Group: http://www.nngroup.com/reports/intranet-design-annual/
[2] Kofax Kapow: http://www.kofax.com/data-integration-extraction