Einblick in Mule ESB 3.5.0-M4 Early Access – DataSense und DataMapper

Vor einigen Tagen hat Mule ein neues Early Access Release seiner Mule ESB Plattform – Die Version 3.5.0-M4 – freigegeben.

Neben zahlreichen neuen Features wie z.B. projektübergreifenden Artefakten („Shared Resources“) oder einer Aktivität zum vereinfachten Konsumieren von Web Services halte ich eine Neuigkeit für besonders interessant: Die Verbesserungen an DataSense in Kombination mit „DataSense enabled“ Konnektoren wie z.B. dem neuen Database Connector.
Meiner Meinung nach wird an dieser Kombination sehr gut ersichtlich, wie sich die Entwicklung mit Mule ESB in Zukunft verändern wird. Aus diesem Grund stelle ich DataSense in Kombination mit dem neuen Datenbank Connector an einem kurzen Beispiel in diesem Artikel vor.

Durch die Einführung des neuen Datenbank Connectors gilt der bisherige als deprecated, kann jedoch zwecks Abwärtskompatibilität weitergenutzt werden. Gleiches gilt für alle bisherigen datenbankspezifischen Data Sources. Die Konfiguration von Datenbanken wird vereinfacht, in Zukunft wird pro Datenbank nur noch ein globales Element zu konfigurieren sein. Für die wichtigsten Datenbanken wird es eine spezifische Konfiguration geben, für alle anderen eine generischen JDBC Konfiguration. Einen Vorgeschmack gibt es im aktuellen Release nur für MySQL, weswegen ich dies für mein Beispiel verwende.

Um eine MySQL Datenbank zu konfigurieren waren bisher zwei globale Elemente nötig: Ein „Database Connector“ sowie eine „MySQL Data Source“. In Zukunft ist nur noch ein Element vom Typ „MySQL Configuration“ erforderlich. Die folgende Grafik zeigt den Unterschied in der Konfiguration:

Die Datenbank lässt sich weiterhin via URL konfigurieren, zusätzlich besteht nun eine einfache Möglichkeit, datenbankspezifische Parameter in genau passende Felder einzugeben, was die Konfiguration meiner Meinung nach durchaus erleichtert und übersichtlicher gestaltet, insbesondere bei umgebungsabhängigen Werten.
Über den Haken bei „Enable DataSense“ aktivieren wir DataSense. Was dies bedeutet, wird im Folgenden klar.

Einen Datenbankzugriff werde ich an einem einfachen SELECT Beispiel demonstrieren. Hierzu verwende ich einen HTTP Request Response Receiver als Trigger für den Prozess. Diesem füge ich eine „Database“ Aktivität hinzu und konfiguriere diese mit einem SELECT Statement wie auf der folgenden Grafik sichtbar ist:

Schon beim Speichern der Aktivität erscheint ein Popup mit der Meldung „Getting DataSense metadata“. Das bedeutet, dass Mule zur Design Time das SELECT Statement auf der Datenbank absetzt und Metadaten über die zurückgelieferte Datenstruktur speichert. Fügen wir dem Flow nun einen Data Mapper hinzu, ist dieser dank DataSense bereits mit den aus der Datenbank gelieferten Daten vorbefüllt:

Ich mappe die beiden Felder einfach auf eine CSV Struktur um und beende den Flow damit. Der fertige Flow sieht wie folgt aus:

Führt man nun Änderungen am SELECT Statement durch (z.B. durch Hinzufügen weiterer Abfragefelder), genügt auf dem Data Mapper ein Klick auf den Button „Reload Metadata“, und schon sind die neuen Felder auch im Mapper sichtbar und können verwendet werden.

DataSense bietet noch eine weitere Neuerung, die die Entwicklung erleichtert: Ein Metadaten Viewer zeigt an jedem Schritt im Flow die vorliegenden Daten an. Hierdurch ist für den Entwickler viel leichter erkennbar, auf welche Daten derzeit zugegriffen werden kann. Über einen kleinen Button kann dieser Editor jederzeit eingeblendet werden:

Diese Kombination aus neuen, „DataSense enabled“ Connectoren, DataSense und dem Data Mapper zeigt, wohin die Reise gehen wird. Der Data Mapper wird an Bedeutung gewinnen und bei Transformationen immer öfter die erste Wahl sein. Durch DataSense wird die Usability zur Design Time im Vergleich zu bisher sehr verbessert.
Außerdem ist zu vermuten, dass sich die Entwicklung in Mule durch DataSense in Zukunft auf eine abstraktere Ebene verlagern wird. Ich persönlich halte dies für sehr sinnvoll, da Mule hierdurch mächtiger wird und die Notwendigkeit zur Verwendung von Basistechnologien wie eigenen Java Klassen, XSLT Transformatoren oder Groovy Scripten reduziert wird. Das Spektrum an erforderlichen Kompetenzen zur Entwicklung wird reduziert, was wiederum langfristig die Entwicklung kostengünstiger, einfacher, sicherer und weniger Fehleranfällig gestaltet.