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.

Dienstag, 27. September 2016

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

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
  1. ein Name zur Referenzierung der Daten doppelt verwendet wird
  2. keine Beziehung (null) hergestellt werden kann
  3. das Speichern einer Instanz nicht möglich ist
  4. 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.


Freitag, 23. September 2016

SVN und Mac OS X und Umlaute

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:
  1. Im Terminal mit brew edit subversion die Subversion-Formel zum anpassen öffnen
  2. 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:
  3. 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
  4. Speichern und Subversion bauen mit brew install --build-from-source subversion
  5. 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.

Dienstag, 20. September 2016

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

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:
  1. Neues Projekt mit der gewünschten Grails Version erstellen und konfigurieren
  2. Einbinden aller Plugins in der neusten verfügbaren Version, die verwendet werden sollen
  3. Migrieren der Domain-/ Java-/ Groovy-Klassen, sowie TagLibs und i18n- Ressourcen
  4. Einspielen von Testdaten
  5. Migrieren der Services
  6. Migrieren der Controller
  7. Migrieren der Views und alle zugehörigen Ressourcen wie JavaScript und CSS Dateien
  8. 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

Dienstag, 13. September 2016

CKEditor Customizing

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!

Montag, 12. September 2016

Competitive Intelligence: Suchmaschinen im Kontext von Business Intelligence

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.

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.