Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus!

Im ersten Teil  habe ich eine allgemeine Einführung in das Thema ESB gegeben. Nach der vielen Theorie wird es nun Zeit für die Praxis. An einem kleinen Beispiel werde ich zeigen, dass ESB – zumindest von der technischen Seite her – überhaupt nicht so schwer ist. Als Plattform für die Beispiele dient Mule ESB von Mulesoft . Man bekommt ihn sowohl in einer Community Edition (kostenlos, Open Source) als auch in der Enterprise Edition (kostenpflichtig). Zur Entwicklung dient Mule Studio, ein mit Plugins aufgerüstetes Eclipse. Im Mule Studio ist bereits die Runtime-Umgebung enthalten, so dass man sich für Experimente den Download des Standalone-Busses sparen kann.

Also frisch ans Werk: Nach Angabe der Email-Adresse und dem Download liegt ein größeres zip oder tar.gz-Archiv auf der Platte. Wie man dies in ein lauffähiges Mule Studio umwandelt erkläre ich hier nicht im Detail, damit würde ich nur Langeweile verbreiten. Nach dem Start vom Mule Studio kann man entweder direkt den Wizard für ein neues Mule-Projekt aktivieren oder in eine der gewohnten Eclipse-Perspektiven wechseln und mittels „File -> new Other“ / „Mule -> Mule Project“ ein neues Projekt anlegen. Der Wizard ist weitgehend selbsterklärend, die schwierigste Frage dürfte die nach dem Projekt-Namen sein, für den ersten Versuch schlage ich „hellobus“ vor. Den Rest des Wizards  kann man per „Next“ durchklicken.

Mule Projektstruktur, passend für einen Maven-Build.

Etwas verwirrend ist bei genauer Betrachtung der Schritt „Java Settings“. Dort wird vorgetäuscht, dass die Quellen unter „src“ und die Klassen unter „bin“ liegen. Stimmt jedoch nicht, nach dem Klick auf „Finish“ wird ein lupenreines Maven-Projekt angelegt, wie man in der Abbildung sieht.

Im Editor-Bereich von Eclipse ist die Datei „hellobus.mflow“ geöffnet. Am unteren Rand kann man zwischen „Message Flow“ (der grafischen Darstellung des Flows), Global Elements (erkläre ich später) und Configuration XML (der XML-Darstellung des Flows) umschalten.

Am rechten Rand des Editors findet man die Toolbox mit den Elementen, aus denen wir Flows zusammensetzen können. Das erste Beispiel soll ganz einfach sein: Wir benutzen Mule als schlichte Kopiermaschine: Alle Dateien, die im Verzeichnis „in“ gefunden werden, sollen in das Verzeichnis „out“ kopiert und anschließend in „in“ gelöscht werden. Das Beispiel als Ganzes betrachtet ist natürlich Unfug, nimmt man aber nur ein Ende des Flows, erkennt man ein in der Praxis übliches Kommunikationsmuster: Eine Anwendung erwartet in einem Verzeichnis eine Eingabedatei beziehungsweise schreibt eine Ausgabedatei in ein Verzeichnis. Möchte man dies Anwendung mit einem anderen System zusammenbringen, das ein anderes Dateiformat erwartet oder statt einer Datei eine Queue  zur Kommunikation nutzt, so wird der Sinn des ESBs schon eher klar.

Erster Flow

Im Editor-Fenster steht schon, was wir machen müssen: „To begin, drop an endpoint or a composite source here from the palette…“ Also rechts „Endpoints“ aufklappen und einen mit „File“ beschrifteten Kasten ins Editorfenster ziehen. Mule Studio legt neben dem Endpoint automatisch einen Flow an, hier „hellobusFlow1“.

Stop: Das war jetzt etwas viel Magie, was ist hier passiert? Der erste Teil dürfte noch halbwegs klar sein, wir wollen eine Datei aus einem Verzeichnis lesen, das ist unsere Eingangsschnittstelle. In Mule startet die Verarbeitung immer mit einem „ingoing endpoint“.  Ausgaben erfolgen über einen „outgoing endpoint“. Aber was ist ein Flow? Der Flow ist die waagerechte Linie oder der flache Kasten, der in der hübschen und einfachen grafischen Darstellung für einen ESB steht. Genau genommen sogar nur ein Teil des Kastens, da ein ESB aus mehreren Flows bestehen kann, dazu aber später mehr. Der Flow hat übrigens automatisch den Namen „hellobusFlow1“ bekommen, durch einen Klick wird der Name editierbar und lässt sich damit ändern. Bisher haben nur die erste Hälfte des Flows, die Eingabe.

Am Endpoint sieht man übrigens unten links ein hässliches Kreuz auf rotem Grund. Da stimmt wohl etwas nicht. Also schnell einen Doppelklick auf den Endpoint ausführen:

Dialog mit Einstellungen zum File-Endpoint.

Im Bild habe ich den Namen schon durch „Input“ ersetzt. Das Verzeichnis (Path), in dem Mule nach den Eingabedateien sucht, ist noch einzustellen. Der Einfachheit halber nehmen wir auch „input“. Wenn das Verzeichnis nicht existiert, meckert Mule, also sollte man es anschließend mit „New -> Folder“ (von Eclipse) anlegen. Statt des relativen Pfades im Projekt wird man in der Praxis eher ein absolutes Verzeichnis angeben oder – noch besser – mit Variablen arbeiten, doch das kommt auch erst später dran…

Was kann man sonst noch so in dem Dialog einstellen? Wir betrachten erst mal nur den aktuellen Reiter. Direkt unter dem Pfad sind noch zwei Felder. Etwas versteckt gibt es dazu auch eine Hilfe: In das Feld klicken, anschließend mit dem Mauszeiger auf das „i“ zeigen dann sieht man:

Füllt man das Feld „Move to Directory“, so werden Dateien nach der erfolgreichen Verarbeitung in das angegebenen Verzeichnis verschoben. (Dazu sollte das Verzeichnis auf dem gleichen Laufwerk bzw. im gleichen Dateisystem liegen, damit der Move-Befehl des Betriebssystems funktioniert.) Über „Move to Pattern“ kann die Datei nach Verarbeitung umbenannt werden. Lässt man beide Felder leer, werden Eingabedateien nach erfolgreicher Verarbeitung gelöscht.

Das Umbenennen ergibt natürlich nur Sinn, wenn Mule nicht im nächsten Schritt die umbenannte Datei wieder verarbeitet. Nicht nur dazu kann man weiter unten einen regulären Ausdruck vorgeben. Mule nimmt sich dann nur noch die Dateien vor, deren Name auf den Ausdruck passt.

Über die weiteren Feldern kontrolliert man, in welchen Zeitintervallen Mule nach neuen Dateien schaut  und wie alt die Dateien mindestens sein müssen. Darüber lässt sich verhindern, dass Mule unvollständige Dateien liest. Sicherer ist es natürlich, wenn man die Dateien zuerst mit einem temporären Namen schreibt  – auf den der reguläre Ausdruck dann nicht passen darf – und sie umbenennt, wenn sie komplett geschrieben sind.

Wir hätten damit den ersten Teil fertig, die Eingabe. Die Aufgabe ist damit noch nicht erledigt, die Datei soll ja auch noch in ein anderes Verzeichnis kopiert werden. Mule unterscheidet beim File-Endpoint in der Palette am rechten Rand nicht zwischen Ein- und Ausgabe, die Rolle ergibt sich durch die Position im Flow. Also ziehen wir einen weiteren File-Endpoint in den Flow, Mule verbindet die beiden automatisch  mit einem Pfeil. Der Dialog für zu schreibende Dateien sieht etwas einfacher aus:

Edit-Dialog für den ausgehenden File-Endpoint.

Einstellungen für Polling-Intervall beziehungsweise zum Verschieben/Löschen von Dateien entfallen hier natürlich. Dafür sieht man eine Fehlermeldung von Mule, da ich das Verzeichnis „output“ noch nicht angelebt habe. Damit sind wir dann schon fertig, unser erster Flow ist bereit zum Test. Wie startet man? Ganz einfach, im Studio über „Run as -> Mule Application“. In der Console sollten einige Log-Meldungen zu sehen sein.

Mule schaut ab jetzt jede Sekunde (1000 ms) in das Verzeichnis „input“. Findet er dort eine Datei, die seit mindestens einer halben Sekunde (500 ms) unverändert ist, kopiert er sie nach „output“ und löscht sie anschließend in „input“.

Eigentlich wäre dieser Blog-Artikel fertig, wenn ich im Titel nicht leichtfertig die Worte „Hello World/Bus“ benutzt hätte. Das korrigieren wir jetzt schnell, wir fügen einfach unsere „Verarbeitungskomponente“ in den Flow ein. Dazu ziehen wir einen „Logger“ (aus der Gruppe „Components“) in den Editor und lassen ihn zwischen den beiden File-Endpoints fallen. Damit ergibt sich folgender Flow:

Flow mit Logger.

Das Layout lässt sich übrigens in der aktuellen Version vom Mule Studio nicht ändern, die einzelnen Komponenten werden automatisch angeordnet. Man muss seine Komponenten nur an der richtigen Stelle zwischen vorhandenen Komponenten fallen lassen. Jetzt noch schnell den Logger konfigurieren:

Edit-Dialog zum Logger.

Im Feld „Message“ können wir unsere nette Begrüßung einbauen, den Level lassen wir auf „INFO“ stehen. Somit ist auch das Ziel aus dem Titel erreicht: Für jede kopierte Datei erscheint „Hello Bus!“ im Console-Fenster vom Mule Studio. Im nächsten Teil geht es dann etwas tiefer in die Innereien: Wir schauen uns an, wie Mule intern tickt und wie man die Datei auf dem Weg durch Mule transformieren kann.

Weitere Teile dieser Artikelserie

1. Was ist ein ESB und wofür kann man ihn nutzen?
2. Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus
3. Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten
4. Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren
5. Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen
6. Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…
7. Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads
8. Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX
9. Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld
10. Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email