Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Senior Integration Architect

Developer Week

Softwarearchitektur

APIs oder Event Broker – wie sollen meine Services kommunizieren?

Wer arbeitet auf einem Mac oder Windows-Rechner und installiert seine Software anschließend auf einem Unix/Server?Wer braucht ab und zu eine Kommandozeile mit Ad-Hoc-Programmierung?Wer möchte nicht auf jedem System eine neue Shell-Sprache lernen?Wer eine der obigen Fragen mit „ja“ beantwortet, für den könnte dieser Blog-Beitrag einige nützlichen Tipps enthalten, auch wenn die hier dargestellten Fakten nicht neu sind: Die JavaScript-Shell existiert bereits seit Java 6. (Das diesen Monat gerade seine Unterstützung durch Oracle verliert…) <h1>Erste Schritte</h1>Mit Java 6 hat Sun das Kommanto jrunscript eingeführt (nur im JDK, im JRE ist es nicht enthalten). Nach dem Start begrüßt es den Nutzer mit „<code>js></code>“ und einem freundlich blinkenden Cursor. Der geneigte Linux-Nutzer tippt nun sicher <code>ls</code>, der Windows-Nutzer <code>dir</code>. Hier sind jedoch beide gleich schlecht dran, es funktioniert nicht wie erwartet. Wir arbeiten hier schließlich mit JavaScript, dort evaluiert der Name einer Funktion zu einem Funktions-Objekt. Will man die Funktion ausführen, so muss man sie aufrufen. Richtig sind daher die beiden folgenden Varianten: <code>ls()</code> oder <code>dir()</code>. Beide funktionieren auf allen Betriebssystemen und geben den Inhalt des aktuellen Verzeichnisses im Unix-Stil von „<code>ls –l</code>“ aus.Das Kommando jrunscript besteht nur aus ein wenig Code um das Java Scripting API <a href="http://www.jcp.org/en/jsr/detail?id=223">[JSR223]</a> . Jede eingegebene Zeile wird als JavaScript-Ausdruck betrachtet und ausgewertet. Ist das Ergebnis des Ausdrucks nicht <code>null</code>, so wird es per <code>toString()</code> in eine lesbare Form verwandelt und auf der Konsole ausgegeben. Eine Shell wird daraus erst durch einen Satz von in JavaScript implementierten Funktionen. Es handelt sich dabei um leicht abgewandelte Varianten von häufig genutzten Unix-Kommandos wie „<code>ls</code>„, „<code>cd</code>„, „<code>pwd</code>“ etc.. Die komplette Liste ist von Oracle dokumentiert, siehe  <a href="http://docs.oracle.com/javase/6/docs/technotes/tools/share/jsdocs/GLOBALS.html">[JRUNSCRIPT]</a> . Neben den üblichen Verdächtigen existieren noch einige für eine Shell eher unübliche Kommandos, mit deren Hilfe man XML einlesen kann (in ein DOM) oder eine Xslt-Transformation anstoßen kann.Bis jetzt haben wir die interaktive Betriebsart von jrunscript gesehen, natürlich sind aber auch Batches möglich: Die Option <code>-f</code>, gefolgt von einem Dateinamen, führt das in der Datei enthaltene JavaScript-Programm aus und terminiert anschließend.Dies kann man für automatisch zu festen Zeiten gestartete Jobs nutzen. Unter Unix/Linux startet man solche Jobs typischerweise mittels „cron“, unter Windows heißt das Gegenstück „Geplante Tasks“ (in der Systemsteuerung suchen).Der Vorteil gegenüber .bat-Dateien oder bash-Shellskripten ist die Unabhängigkeit vom Betriebssystem, da JavaScript überall läuft, wo auch Java läuft. Schaut man sich in seinem (Web-)Projekt um, wird man schnell jemand finden, der die notwendigen JavaScript-Kenntnisse besitzt. Oft reicht dafür schon ein Blick in den Spiegel. Heutzutage ist es oft schon schwieriger, jemand zu finden, der fließend bash spricht.<h1>Ad Hoc Programmierung</h1>In einer Programmiersprache sollte man Programme schreiben – und auch ausführen! jrunscript eignet sich insbesondere für kurze Wegwerfprogramme, die man nur ein- oder zweimal laufen lässt. Nehmen wir mal an, im Build-Script fehlt ein ordentliches Clean-Target, man möchte aber trotzdem rekursiv alle .class-Dateien löschen. Geht ganz einfach: <code>find('.', '.*\.class', rm)</code>. Der erste Parameter der find-Funktion ist das Start-Vereichnis (Punkt steht für aktuelles Verzeichnis). Der zweite ist ein regulärer Ausdruck für den Dateinamen (ohne Pfad). Interessant wird’s beim dritten Parameter: Hier übergibt man eine Funktion, die beim Aufruf einen Parameter erhält, den absoluten Dateinamen der gefundenen Datei. Im Beispiel ist es die eingebaute Löschfunktion.Zur Erinnerung: Callbacks in JavaScript sind Funktions-Objekte. Sie erhält man, indem man entweder nur den Funktionsnamen – ohne Klammern – angibt oder als anonyme Funktion. Nun zur Veranschaulichung ein weiteres Beispiel mit einer anonymen Funktion (Lambda-Ausdruck). Der Schnipsel findet alle Java-Dateien, deren absoluter Dateiname länger als 60 Zeichen ist. Damit kann man Dateien finden, die auf Betriebssystemen mit anderen Limits für Pfadlängen Ärger machen:<code>find('.', '.*\.java', function(x) { if (x.toString().length() > 60) echo(x) })</code>Leider hat die Shellkeine eingebaute Hilfe, man muss also entweder zum Browser greifen und die Dokumentation bei Oracle lesen oder man nutzt ein anderes Feature: <code>echo(rm)</code> gibt den JavaScript-Code der eingebauten Funktion <code>rm</code> aus. Den kompletten Sourcecode aller eingebauten Funktionen findet man im JDK im Archiv <code>tools.jar</code>, darin die Datei <code>com/sun/tools/script/shell/init.js</code>.Jede eingetippte Zeile wird direkt ausgeführt, es wird nicht geprüft, ob der Ausdruck vollständig ist. Enthält sie nur einen unvollständigen Ausdruck oder endet mit einem unvollständigen Ausdruck, so antwortet jrunscript mit einem Syntax-Fehler. Es gibt aber einen Trick, seine Ausdrücke über mehr als eine Zeile hinweg einzugeben, mit Hilfe der beiden Funktionen <code>read()</code> und <code>eval()</code>: <code> return eval(read('>', true))</code>. Der erste Parameter von <code>read</code> ist der Prompt, der zweite gibt an, dass wir mehr als eine Zeile lesen wollen. Sobald <code>read()</code> eine leere Zeile liest, terminiert es.<h1>Selbstegebaute Kommandos</h1>Wie schon erwähnt, kann man mittels <code>-f dateiname.js</code> eine Datei mit JavaScript-Code ausführen. Die Option kann auch mehrfach genutzt werden, um mehrere Dateien in einem Rutsch auszuführen. Da <code>-f -</code> den Code von der Standardeingabe liest, lassen sich Batch und interaktive Arbeit auch kombinieren: Erst ein Skript ausführen, anschließend in den interaktiven Modus wechseln.So hat man die Möglichkeit, den Namespace des Interpreters mit eigenen Funktionen und Objekten zu füllen. Für das oben erwähnte Multi-Line-Problem lässt sich einfach eine Funktion definieren:<code>function ml() { return eval(read('>', true)) }</code>Damit kann man interaktiv die Funktion <code>ml()</code> nutzen, wann immer man Kommandos auf mehr als einer Zeile eingeben möchte.<h1>Zusammenfassung</h1>jrunscript lässt sich schlecht mit „normalen“ Shells vergleichen. Die Syntax von JavaScript ist geschwätziger, man muss mehr Zeichen eingeben, zum Beispiel die Klammern für Funktionsaufrufe. Kommandos lassen sich dagegen in anderen Shells nur durch den Namen aufrufen. In JavaScript benötigt man kein Dollar- oder Prozent-Zeichen vor Variablennamen, dafür müssen Strings in Anführungszeichen eingeschlossen sein. Das hat auch Vorteile: Wie oft hat man bei Unix Ärger, weil in einem Dateinamen ein Leerzeichen enthalten ist?Interessant ist auch der Vergleich mit einer JavaScript-Konsole im Browser. Hier ist die Sprache identisch, aber der Kontext komplett anders: Im Browser hat man Objekte wie <code>window</code>, in jrunscript dagegen durch die Java-Bridge vollen Zugriff auf alle Klassen des JDK (siehe auch <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html">[JSGUIDE]</a> für Details). Da keine Sandbox greift, darf man aus den Skripten heraus auch auf das Dateisystem zugreifen. Mit zusätzlichen jar-Dateien im Klassenpfad lassen sich die Möglichkeiten sogar noch erweitern.Die Shell ist sicher kein Ersatz für Build-Tools wie ant, maven oder gradle, dafür ist sie jedoch immer schnell zur Hand, wenn man etwas Logik ausführen muss und es sich nicht lohnt, den Java-Compiler anzuwerfen. In diesem Sinne mag es beim Entwickeln eine kleine Nische füllen.<h1>Werbung</h1>Bei jrunscript handelt es sich nur um einen kleinen Wrapper um das Java-Scripting-API. Wer dazu und zu anderen Themen wie Rhino oder der JavaScript-Schnittstelle in ant mehr wissen möchte, dem kann ich das eBook <a href="http://entwickler-press.de/ep/psecom,id,2,buchid,295.html">JavaScript auf dem Server</a> empfehlen.Ach ja: Wenn man von jrunscript genug hat: <code>quit()</code>

Schon gewusst? JDK enthält serienmäßig JavaScript Shell

In den letzten Jahren ist die Geschwindigkeit einzelner CPU-Kerne kaum noch gestiegen. Stattdessen steigt die Anzahl der Kerne, Laptops haben heutzutage oft acht Kerne (ok, vier echte, der Rest ist nur Hyperthreading). Selbst in Smartphones sind vier Kerne inzwischen Standard. Will man solche Rechner auslasten, muss man  parallele Programme einsetzen.In diesem Artikel werde ich ein kleines Brettspiel als Anwendung für Parallelprogrammierung und andere Optimierungen verwenden, eine dreieckige Variante von <a href="http://de.wikipedia.org/wiki/Solit%C3%A4r_(Brettspiel)">Solitaire</a> . Die Frage ist: Wie viele verschiedene Lösungsvarianten existieren für ein Spielbrett? Der Fokus des Artikels wird auf verschiedenen Optimierungstechniken liegen, nicht nur dem Fork/Join-Framework. Es wird sich zeigen, dass neben der Parallelisierung in diesem Fall andere Techniken überlegen sind.<h1>Aufgabenbeschreibung</h1>Im Artikel geht es um Solitaire auf einem dreieckigen Brett der Kantenlänge <code>n</code>. Ein Brett der Kantenlänge fünf (n = 5) sieht vor dem ersten Zug folgendermaßen aus:

```
 x
 x x
 x o x
 x x x x
 x x x x x
```

In der Startstellung ist das mittlere Feld in der dritten Reihe leer. Ein gültiger Zug besteht aus einem Sprung in einer der sechs möglichen Richtungen über einen Stein, welcher dadurch entfernt wird. Das Zielfeld muss vor dem Zug natürlich frei sein. Nach dem ersten Zug könnte das Brett also folgendermaßen aussehen:

```
 x
 x x
 x x x
 x o x x
 x o x x x
```

Wenn sich nur noch ein Stein aus dem Brett befindet, ist das Spiel gelöst. Für verschiedene Startpositionen (bei gleicher Kantenlänge) existiert eine unterschiedliche Anzahl von Lösungen, eine schöne Untersuchung findet man auf Dan O’Briens Puzzle Solution Page. Dort wurde die Anzahl der verschiedenen Lösungen auch mit einem Java-Programm untersucht, jedoch immer für n = 5.Hat man erst mal eine Klasse geschrieben, die das Spielbrett repräsentieren kann und in der Lage ist, aus einer Stellung die Folgendstellungen zu ermitteln, besteht die restliche Logik nur noch aus einer kleinen, rekursiven Methode:<div>

```java5
 long countSolutions(Board start) {
 if (start.isSolution()) {
 return 1;
 } else {
 long count = 0;
 for (Board board : start.nextPositions()) {
 count += countSolutions(board);
 }
 return count;
 }
 }
```

</div>(Den kompletten Source-Code als Eclipse-Projekt gibt es übrigens als <a href="http://blog.codecentric.de/files/2012/10/Puzzle.zip">ZIP</a> .) Für ein Brett mit Kantenlänge fünf benötigt die Methode ca. eine Zehntel Sekunde zum Ermitteln der 1550 verschiedenen Lösungen. Klingt nicht danach, als wenn hier großer Optimierungsbedarf besteht. Wie sieht es also für größere Kantenlängen aus? Bei Kantenlänge sechs dauert es schon länger. Viel länger. Zwar nicht solange wie die Berechnung von 42, aber immerhin noch ca. 30 Stunden. Es existieren 29.235.690.234 verschiedene Lösungen für diese Brettgröße. Deswegen ist der Rückgabewert auch ein <code>long</code> und kein <code>int</code>.Woher kommt dieser große Unterschied, obwohl das Brett doch kaum größer ist? Die Anzahl der möglichen Positionen für ein Brett der Kantenlänge <code>n</code> ist <code>2^(n * (n+1)/2)</code>. Es handelt sich also um eine Exponentialfunktion mit einer quadratischen Funktion im Exponenten…<h1>Fork/Join</h1>Wenn man das Fork/Join-Framework kennt (wenn nicht: <a href="http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html">Fork/Join tutorial</a> lesen) erkennt man, dass es wie die Faust aufs Auge auf das Problem passt. Mit wenigen Zeilen lässt sich die Berechnung initialisieren:<div>

```java5
 ForkJoinPool pool = new ForkJoinPool(numThreads);
 RecursiveSolver root = new RecursiveSolver(startBoard, sequential);
 solutions = pool.invoke(root);
```

</div>Dazu braucht man noch eine kleine Klasse für die Tasks:<div>

```java5
class RecursiveSolver extends RecursiveTask {
 private Board start;
 private int sequential;
 
 public RecursiveSolver(Board start, int sequential) {
 this.start = start;
 this.sequential = sequential;
 }
 
 @Override
 protected Long compute() {
 int card = start.cardinality();
 if (card == 1) {
 return Long.valueOf(1);
 } else if (card < sequential) {
 return Long.valueOf(countSolutions(start));
 } else {
 List nextPositions = start.nextPositions();
 List tasks = new ArrayList<>(nextPositions.size());
 for (Board b : nextPositions) {
 tasks.add(new RecursiveSolver(b, sequential));
 }
 invokeAll(tasks);
 long count = 0;
 for (RecursiveSolver rs : tasks) {
 count += rs.join();
 }
 return count;
 }
 return Long.valueOf(0);
 }
}
```

</div>Wo im sequentiellen Fall die Rekursion steht, werden hier neue Instanzen von <code>RecursiveTask</code> angelegt. Als weitere Optimierung wechselt der Algorithmus innerhalb eines Threads zur sequentiellen Variante, wenn nur noch eine einstellbare Anzahl von Steinen auf dem Brett vorhanden ist. Somit wird unnötiger Verwaltungsaufwand im Fork/Join-Framework vermieden. Bei meinen Testläufen hat sich acht als gute Grenze für den Wechsel zur sequentiellen Variante herausgestellt.Auf meinem Laptop (acht Kerne mit Hyperthreading, vier „echte“ Kerne) gestartet, war dieser für die nächsten 7 Stunden und 28 Minuten erst mal gut beschäftigt. Verglichen mit den 30 Stunden für die sequentielle Variante ungefähr ein Faktor von vier, das passt gut zu den vier „echten“ Kernen, perfekter Speedup. Eigentlich könnte man jetzt das Thema ad acta legen.Ich wollte jedoch nicht nur Bretter mit Kantenlänge fünf und sechs lösen, sondern auch größere Bretter. Wie sieht es beispielsweise für n = 7 aus? Auf meinem Laptop habe ich das nicht ausprobiert. Weder sequentiell noch parallel. Vermutlich wäre das Programm weder in meiner noch in der Lebensdauer des Laptops fertig geworden. Wenn man sich also für größere Bretter interessiert, müssen noch weitere Optimierungen dazukommen.<h1>Caches</h1>Wie in den meisten Brettspielen ergeben sich bei Solitaire nach Änderung der Reihenfolge von Zügen oft identische Stellungen. Speichert man also für eine Stellung ab, wie viele Lösungen es aus dieser Stellung gibt, so muss man es nicht wiederholt berechnen. Dies kann man beispielsweise mittels einer <code>HashMap</code> implementieren. Diese Technik ist in der Spieleprogrammierung auch unter dem Namen <a href="http://en.wikipedia.org/wiki/Transposition_table">Transposition Table</a> bekannt. Damit sie funktioniert, muss die Klasse <code>Board</code> die Methoden <code>hashCode()</code> und <code>equals()</code> implementieren.Für n = 5 bringt diese Optimierung noch nicht sehr viel, statt 0,1 Sekunden dauert es jetzt nur noch 0,07 Sekunden, das heißt nur noch 70% der Zeit. Für n = 6 ist der Effekt schon beeindruckender, statt 30 Stunden der sequentiellen Implementierung nur noch 0,4 Sekunden, ein Faktor von 270.000. Auch gegenüber der parallelen Variante mit vier Kernen ist die optimierte Variante immer noch um den Faktor 67.500 schneller.Das ist ja schon mal recht vielversprechend, also habe ich es direkt mal mit n = 7 ausprobiert. Auf einer „gewöhnlichen“ JVM mit 32-Bit Heap gibt das aber nur einen <code>OutOfMemoryError</code>, die <code>HashMap</code> passt nicht mehr in den Speicher. Da hilft auch kein einfaches <code>-Xmx</code> mehr, es muss zusätzlich per <code>-d64</code> in den 64-Bit-Modus umgeschaltet werden.Stop!Die <code>HashMap</code> ist zwar eine meiner Lieblingsklassen, da sie so schön einfach und schnell ist, manchmal existieren jedoch bessere Varianten, hier das gute alte Array. Eine Stellung des Spiels lässt sich nämlich – zumindest bis n = 7 – auch in einem <code>int</code> speichern, schließlich sind es nur 7*(7+1)/2=28 Felder. Damit hat man den Index. Gespeichert werden in dem Array <code>long</code>s, die jeweils die Anzahl der Lösungen für die Stellung repräsentieren. Für noch nicht untersuchte Stellungen wird -1 abgelegt. Mit n = 7 passt es immer noch nicht in einen 32-Bit-Heap, ist aber sowohl bezogen auf den Speicher als auch auf die Rechenzeit effizienter, zum Beispiel entfällt das Hashing. Für n = 6 benötigt der Algorithmus jetzt nur noch 0,2 Sekunden statt der 0,4 Sekunden mit der <code>HashMap</code>.Mit einer 64-Bit-JVM könnte man jetzt also n = 7 lösen. Aber vorher gehen wir noch einmal einen Schritt zurück und nehmen an, wir könnten uns die notwendige Speichermenge nicht leisten. Wenn man etwas Debug-Ausgaben einbaut, fällt etwas auf: Für n = 5 und n = 6 findet der Algorithmus ziemlich schnell die ersten Lösungen. Bei n = 7 ist dies anders. Ich hatte das vor etlichen Jahren beobachtet, als ich dieses Problem noch mit C auf einer SUN-Workstation beackert hatte. Auch nach etlichen Minuten war noch keine Lösung gefunden. Daraufhin keimte in mir der Verdacht, dass Solitaire für diese Kantenlänge möglicherweise unlösbar ist. Also schnell das Programm modifiziert und für jede Stellung nur noch ein Bit spendiert: 0 = Stellung noch nicht ausgewertet, 1 = Stellung ausgewertet, unlösbar.Letzte Woche war ich etwas fauler (mein Laptop hat ja auch mehr Speicher als die alte Workstation) und habe statt eines Bits ein <code>byte</code> spendiert, damit passt das Array immer noch in einen 32-Bit-Heap. Noch eleganter wäre natürlich die Klasse <code>BitSet</code> aus dem JDK gewesen. Nach 34 Sekunden kam die Bestätigung dessen, was ich durch das alte C-Programm schon wusste: Für n = 7 existiert keine Lösung. Mit <code>long</code> auf der 64-Bit-JVM dauert es etwas länger, 37 Sekunden. Dies dürfte an schlechterer Cache-Lokalität durch den höheren Speicherverbrauch und an den größeren 64-Bit Referenzen liegen.<h1>Jetzt wieder parallel</h1>Bisher haben wir zwei total unterschiedliche Optimierungsansätze betrachtet: Parallelität und Caching. Die Frage ist, lassen sie sich für noch bessere Ergebnisse kombinieren? Es ist möglich, die Lösung ist dann aber nicht mehr so einfach und elegant. Die bisherige parallele Variante kam komplett ohne <code>synchronized</code> aus, da die Threads nur auf lokalen Daten arbeiten. Damit ist Schluss, sobald man eine globale Datenstruktur wie ein Array oder eine <code>HashMap</code> einsetzt. Dazu muss man sich noch überlegen, in welcher Granularität man sperrt. Die Struktur komplett zu sperren hat zwei Nachteile:<ol><li>Ein Großteil der Parallelität wird zerstört, wenn alle Threads auf eine Ressource zugreifen</li><li>Es löst nicht das Problem der doppelten Arbeit: Nachdem ein Thread festgestellt hat, dass eine Stellung noch nicht ausgewertet hat und mit der Arbeit beginnt, könnte ein zweiter Thread die gleiche Stellung auswerten.</li></ol>Also sollte man feingranularer arbeiten: Ein Lock pro Stellung. Da <code>synchronized</code> immer ein Objekt benötigt, muss mann statt des eingebauten Datentyps im Array jetzt ein Objekt einführen:<div>

```java5
class Value {
 public Value() {
 v = -1;
 }
 public long v;
}
```

</div>Der Rest ändert sich nicht besonders:<div>

```java5
long countSolutions(Board start) {
 Integer startAsInt = Integer.valueOf(start.asInteger());
 Value value = cache[startAsInt];
 synchronized (value) {
 if (value.v != -1) {
 return value.v;
 } else if (start.isSolution()) {
 value.v = 1;
 return 1;
 } else {
 long count = 0;
 List nextPositions = start.nextPositions();
 for (Board board : nextPositions) {
 count += countSolutions(board);
 }
 value.v = count;
 return count;
 }
 } // synchronized
}
```

</div>Die Lösung verhindert, dass mehrere Threads eine Stellung bearbeiten. Da Threads hier länger blockiert werden können, sollte man mit mehr Threads als Kernen arbeiten.Messungen zeigen, dass sich – zumindest für diese Problem – die Kombination aus Caching und Parallelisierung nicht lohnt. Für n = 6 benötigt das Programm eine Sekunde, fünf mal länger als die schnellste sequentielle Variante. Der Aufwand durch die Synchronisierung ist im Vergleich zur Berechnung zu hoch. Dies mag für andere Problemstellungen, in denen die Einzelprobleme komplexer sind, anders sein.<h1>Lessons Learned</h1>Was kann man aus diesen Spielereien lernen? Speziell, wenn man langweilige/interessante Geschäftsanwendungen mit (No)SQL-Databases entwickelt? Nun, ich habe für dieses Experiment erstmalig mit dem Fork/Join-Framework in der Praxis gearbeitet. Meine Schlussfolgerung: Gut dokumentiert, ziemlich einfach zu benutzen. Auch die intern eingebauten Tricks des Frameworks (wie die Arbeit zwischen den Threads verschoben wird) scheinen gut zu funktionieren. Es wäre deutlich aufwändiger gewesen, selbst Threads zu erzeugen und zu verwalten.Als zweiten Punkt kann man mitnehmen, dass gute Algorithmen wichtig sind. Wichtiger als kleine Optimierungen durch Bitfrickeleien. Mit letzteren holt man nur konstante Faktoren heraus, ein besserer Algorithmus kann jedoch Größenordnungen ausmachen. Gerade bei großen Problemen macht es einen riesigen Unterschied, ob der Aufwand <code>n log(n)</code> oder <code>n^2</code> beträgt (Hinweis: Sortieralgorithmen).Der dritte Punkt ist ganz einfach: Am schnellsten ist die Arbeit erledigt, die man überhaupt nicht ausführt. Wenn sie sich jedoch nicht komplett umgehen lässt, so sollte man sie zumindest nicht mehrfach ausführen, stattdessen sollte man einmalig berechnete Ergebnisse zwischenspeichern (caching). Hier war das die Berechnung von Teilbäumen, in Geschäftsanwendungen sind typischerweise die Datenbankoperationen der Zeitfresser. Mit einem guten JPA-Provider im Classpath muss man hier nicht einmal selbst einen Cache implementieren. Stattdessen kann man die Zeit nutzen, den Cache vernünftig zu konfigurieren.Wo man selbst Hand anlegen muss, existieren einige hilfreiche Klassen, die (Implementierungs)Arbeit einsparen helfen. <code>HashMap</code> und Array, so wie sie hier verwendet wurden, sind keine echten Caches, ihnen fehlt die Fähigkeit, Dinge zu vergessen. Aber im JDK existieren weitere hilfreiche Klassen zum Thema: Nicht wirklich geeignet ist die <code>WeakHashMap</code>, deren Einträge verwirft der Garbage Collector, allerdings ohne jede Kontrolle durch den Programmierer. Besser ist da oft einen echter LRU-Cache, der ganz einfach mit Hilfe der Klasse <code>LinkedHashMap</code> realisiert werden kann, man muss dazu nur die Methode <code>removeEldestEntry()</code> überladen (Details finden sich im zugehörigen Javadoc).Will man noch mehr Kontrolle über seinen Cache haben, sollte man sich den <a href="http://code.google.com/p/guava-libraries/wiki/CachesExplained">Google Guava Cache</a> ansehen. Bei ihm können Einträge auch zeitgesteuert oder basierend auf den Kosten eines Eintrags entfernt werden, wobei man das Maß für die Kosten selbst bestimmen kann.Ein Punkt wurde hier überhaupt nicht betrachtet: Die Analyse des Codes mittels eines Profilers. In diesem einfachen Beispiel war auch so klar, wo die Zeit verbraucht wurde.<h1>Anhang</h1>Es überrascht, dass für n = 7 keine einzige Lösung existiert. Man kann sogar beweisen, dass für alle n mit <code>n modulo 3 = 1</code> keine Lösung existiert. Es folgt eine kurze Skizze des Beweises.Zuerst werden die Felder des Spielfeldes in zwei Varianten mit Werten markiert:

```
 1 1
 1 0 0 1
 0[1]1 1[1]0
 1 1 0 1 1 0 1 1
 1 0 1 1 0 0 1 1 0 1
0 1 1 0 1 1 1 1 0 1 1 0
```

Das Feld in eckigen Klammern ist die Stelle, bei der am Spielanfang kein Stein steht. Für jede Stellung lässt sich nun eine Funktion berechnen: Summe der Feldwerte, auf denen ein Stein steht modulo zwei.Für n = 6 ist die Zahl der Einsen auf dem Brett gerade. Da das initial leere Feld jedoch auch mit einer Eins belegt ist, ist der Funktionswert sowohl für die linke als auch für die rechte Variante der Markierung eins.In einer Zeile oder in den beiden Diagonalen betrachtet wiederholt sich das Muster <code>1 1 0</code>. Ein Zug auf dem Muster verändert nie das Ergebnis der Funktion: Gerade bleibt gerade, ungerade bleibt ungerade.Dies gilt natürlich nicht nur für einen Zug, sondern auch über ein ganzes Spiel hinweg. Da für beide oben gezeigten Feldmarkierungen die Startposition als Funktionswert eins hat, muss am Ende des Spiels der übrig bleibende Stein für beide Feldmarkierungen auf einem mit eins markierten Feld stehen.Für n = 5 und n = 6 kann man dies mit einer leichten Modifikation des Programms alle Felder ermitteln, auf denen bei den gefunden Lösungen der letzte Stein steht:

```
 o
 o o
 o o o
 o o o o
o o x o o
```

Bei n = 5 kommt also nur ein Feld heraus, bei n = 6 mehr:

```
 x
 o o
 o x o
 x o o x
 o o x o o
o x o o x o
```

Wenn <code>n modulo 3 = 1</code> gilt, dann ist auch die Feldanzahl modulo drei gerechnet eins. Erweitert man die beiden oben gezeigten Muster für größere n so sieht man, dass für die n mit <code>n modulo 3 = 1</code> in der Ecke unten rechts und links immer eine Eins Steht. Das Brett enthält also eine <code>n/3</code> von <code>1 1 0</code> Gruppen und eine zusätzliche Eins. Zusammen mit dem leeren Feld am Start auf einer Eins führt dies zum Funktionsergebnis null. Der letzte Stein muss daher auf einer Null stehen, für das linke und rechte Muster. Da es aber keine Felder gibt, die in beiden Mustern eine Null enthalten, kann es für diese n keine Lösung geben.Wäre es nicht gemein, das Spiel mit Kantenlänge sieben auf den Markt zu bringen?

Fork/Join und andere Optimierungen von Algorithmen

Transaktionen in Mule

Da Mule weitgehend aus Java besteht, überraschen die vielfältigen Kombinationsmöglichkeiten mit Java nicht. Einige bekannte – und weniger bekannte – Varianten stelle ich in den folgenden Abschnitten vor. Eine Kleinigkeit aber vorweg: Einige werden sich nach der Einleitung die Frage stellen, welche Sprache sonst noch im Mule-Kern vorkommt: Es ist Scala, das in einigen der Enterprise-Komponenten (DataWeave, Batch) vorkommt. Wenn Mule läuft, befindet sich die Scala-Laufzeitbibiliothek also immer auch auf dem Classpath. Wer möchte, kann daher auch Scala statt Java verwenden. Ich beschäftige mich heute aber “nur” mit Java.<h2>Expression Language</h2>Mule erlaubt an beinahe allen Stellen in seinen Flows statt fester Werte sogenannte MEL-Expressions. MEL steht für “Mule Expression Language”. Eine MEL-Expression wird mit <code>#[]</code> eingerahmt. MEL sieht aus wie viele andere Skriptsprachen, sie ist stark an C- bzw. Java-Syntax angelehnt. Die genaue Beschreibung befindet sich bei Mule: <a href="https://docs.mulesoft.com/mule-user-guide/v/3.8/mule-expression-language-reference">MEL-Reference</a> . Wenn eine MEL-Expression in einem Flow ausgewertet wird, so liegen einige Objekte bereits im Scope, z.B. <code>message</code> für die Nachricht oder <code>payload</code> für die Nutzlast der Nachricht. Mule-Kenner wissen bereits: Die Payload ist immer ein Java-Objekt (genauer: eine Instanz eines Objektes). Bei POJOs kann mit Punkt-Notation auf die Attribute zugegriffen werden, im Hintergrund ruft der MEL-Interpreter die zugehörigen Getter auf. So könnte man aus einem String mit<div>

```xml
<set-payload value="#[payload.bytes]" doc:name="getBytes()" />
```

</div>den Inhalt als Byte-Array auslesen. (Das Beispiel ist konstruiert und gefährlich: Es gibt zwar eine Methode <code>getBytes()</code> in String, die ist jedoch kein echter “Getter”. Außerdem verlassen wir uns hier auf das Default-Encoding, was grundsätzlich keine gute Idee ist.) Anschließend hätten wir in der Mule-Message ein Byte-Array statt eines Strings. Mit<div>

```xml
<logger level="INFO" message="Paylod type is: #[payload.getClass()]" doc:name="getClass()" />
```

</div>ließe sich das auch direkt prüfen. Nebenbei habe ich gezeigt, wie Methoden aufgerufen werden. Man kann natürlich auch Methoden mit Parametern aufrufen, um zum Beispiel alle x zum u zu machen:<div>

```xml
<set-payload value="#[payload.replace('x', 'u')]" doc:name="'x' to 'u'"/>
```

</div>Oder – wenn man die Welt verdrehen möchte – geht das mit Apache Commons 3 und einer statischen Methode aus <code>StringUtils</code>:<div>

```xml
<set-payload value="#[org.apache.commons.lang3.StringUtils.reverse(payload)]" doc:name="reverse" />
```

</div>Ich habe mich hier auf Klassen beschränkt, die bereits im Classpath vorhanden sind. Natürlich darf man auch eigene Klassen benutzen, die man im Verzeichnis src/main/java implementiert.<h2>Java-Component</h2>Die nächste Variante sind die sogenannten Java Components. Sie existieren in zwei Geschmacksrichtungen: entweder als einfache POJOs oder als Implementierung des Mule-Interfaces <code>org.mule.api.lifecycle.Callable</code>. Fangen wir mit einem POJO an:<div>

```java
public class SimplePojo {
 public String xToU(String text) {
 return text.replace('x', 'u');
 }
}
```

</div>Den Code können wir per XML-Schnipsel aufrufen:<div>

```xml
<component class="de.codecentric.components.SimplePojo" />
```

</div>Wenn in der Klasse nur eine Public-Methode mit einem Parameter existiert, so ruft Mule diese auf. Existieren mehrere Methoden, wird es komplizierter: Dann kommen sogenannte Entry-Point-Resolver ins Spiel. Wer es genauer wissen möchte: Unter <a href="https://docs.mulesoft.com/mule-user-guide/v/3.8/configuring-components">Configuring-Components</a> in der Mule-Doku stehen die Details. POJOs bieten die üblichen Vorteile: Sie sind extrem lose an Mule gekoppelt (genau genommen überhaupt nicht) und sie lassen sich in JUnit-Tests ohne Abhängigkeiten zu irgendwelchem Mule-Code testen. Da die Mule-XML-Konfiguration nur eine Variante einer Spring-Konfiguration darstellt, können Components übrigens auch als Spring-Beans instanziiert werden, mit den bekannten Möglichkeiten von Spring: Factories, Scopes, etc. Standardmäßig sind die Components Singletons (und müssen daher auch thread-safe implementiert sein). Die zweite Variante der Components implementieren das Mule-Interface <code>Callable</code>. Über diesen Weg kommt man auch an einige Innereien von Mule heran:<div>

```java
public class SimpleCallable implements Callable {
 @Override
 public Object onCall(MuleEventContext eventCtx) throws Exception {
 return ((String)eventCtx.getMessage().getPayload()).replace('u', 'x');
 }
}
```

</div>Wie man sich denken kann, wird aus dem Flow <code>onCall()</code> aufgerufen. Darin hat man Zugriff auf den <code>MuleEventContext</code>, die <code>MuleMessage</code> und den <code>MuleContext</code>. Über die MuleMessage lassen sich nicht nur die Payload auslesen und bearbeiten, sondern auch die Properties in den verschiedenen Mule-Scopes. Der Nachteil besteht darin, dass Tests schwieriger sind, da man sich erst einen <code>MuleEventContext</code> bauen muss. Braucht man nur den MuleContext und möchte bei den “einfachen” Methoden bleiben, kann man auch – in einem POJO – <code>MuleContextAware</code> implementieren. Nachdem eine Instanz der Component erstellt wurde, ruft Mule die Methode <code>setMuleContext(MuleContext ctx)</code> auf, so dass man sich den Context in einer Member-Variablen merken kann.<h2>Java-Transformer</h2>Einen Java-Transformer ruft man aus der XML-Konfiguration ähnlich wie eine Component auf:<div>

```xml
<custom-transformer class="de.codecentric.SimpleTransformer" doc:name="Java"/>
```

</div>Hier haben wir wieder eine Kopplung an Mule, die Klasse muss das Interface <code>org.mule.api.transformer.MessageTransformer</code> implementieren. Die Implementierung muss man nicht komplett selbst erledigen. Es gibt zwei vorgefertigte abstrakte Klassen, bei denen jeweils nur eine Methode zu implementieren ist. Beginnen wir mit <code>AbstractTransformer</code>:<div>

```java
public class SimpleTransformer extends AbstractTransformer {
 @Override
 protected Object doTransform(Object src, String enc) throws TransformerException {
 return src;
 }
}
```

</div>Hier bekommen wir die Payload und das gewünschte Encoding geliefert. Als Ergebnis müssen wir die neue Payload zurückgeben. (Im Beispiel gebe ich einfach das Original zurück.) Wieder haben wir eine Kopplung an Mule (wir leiten ab), können aber noch einfach testen, da der Transformer für den Test einfach instanziiert werden kann. Vom Encoding abgesehen ist der Unterschied zu der ersten Component-Variante (POJO) gering. Ich benutze diese Variante in der Praxis daher so gut wie nie, da sie gegenüber dem POJO keine Vorteile bietet. Etwas anders sieht es beim <code>AbstractMessageTransformer</code> aus:<div>

```java
public class SimpleMessageTransformer extends AbstractMessageTransformer {
 @Override
 public Object transformMessage(MuleMessage message, String output) throws TransformerException {
 return message;
 }
}
```

</div>Analog zum <code>AbstractTransformer</code> ist ebenfalls nur eine Methode zu implementieren, die Signatur bietet jedoch mehr Flexibilität: Statt der Payload übergibt Mule die <code>MuleMessage</code> als Parameter. Somit besteht auch Zugriff auf die Properties in den verschiedenen Scopes. Der Rückgabewert kann eine (transformierte) Payload oder eine Message (neu oder verändertes Original) sein. Diese Variante ist immer die Wahl, wenn man mit der Payload und/oder anderen Bestandteilen der <code>MuleMessage</code> (Properties, Attachments) arbeitet.<h2>Filter</h2>Alle bisher genannten Varianten besitzen einen Nachteil: Sie spielen nicht gut mit DataSense im AnypointStudio zusammen. In vielen Fällen kann AnypointStudio herleiten, was für ein Typ in einer Nachricht steht und dies über den Flow hinweg verfolgen. Bei Java-Klassen hat das AnypointStudio jedoch keine Chance: Es kann nicht wissen, was für ein Datentyp aus einer Komponente herauskommt. Möchte man in der Java-Komponente die Payload überhaupt nicht beeinflussen, z.B. weil man nur einen Seiteneffekt auslösen möchte oder nur eine Property/Attachment der Nachricht ändern möchte, so ist es schade, dass die Typinformation verloren geht. Ein (zugegebenermaßen dreckiger) Trick besteht darin, einen <code>Filter</code> zu benutzen. So sieht das XML aus:<div>

```xml
<custom-filter class="de.codecentric.components.SimpleCustomFilter" doc:name="SimpleCustomFilter"/>
```

</div>Und so der zugehörige Java-Code:<div>

```java
public class SimpleCustomFilter implements Filter {
 @Override
 public boolean accept(MuleMessage message) {
 // irgendwas mit der Message machen...
 return true;
 }
}
```

</div>Beim Filter geht das AnypointStudio davon aus, dass die Payload unverändert bleibt. Was daran unschön ist: Im Flow steht ein Filter, der nicht filtert, sondern etwas anderes macht. Man stiftet also Verwirrung. Ich würde diesen Hack – wenn überhaupt – nur sehr sparsam einsetzen, z.B. in Utility-Subflows. Man kann den Filter natürlich auch bestimmungsgemäß nutzen: Gibt <code>accept()</code> false zurück, so bricht der Flow an der Stelle des Filters ab. In asynchronen Flows ist dann einfach die Bearbeitung beendet, in synchronen Flows geht die zu diesem Zeitpunkt in der Nachricht enthaltene Payload an den Aufrufer zurück. In den meisten Fällen ist das nicht sinnvoll, der Einsatz von Filtern ergibt eher in asynchronen Flows Sinn.<h2>Custom-Processor</h2>Wer noch tiefer in die Innereien von Mule einsteigen möchte, muss <code>org.mule.api.processor.MessageProcessor</code> implementieren und kann ihn folgendermaßen in XML konfigurieren/aufrufen:<div>

```xml
<custom-processor class="de.codecentric.FlowCaller" doc:name="FlowCaller">	 	 
 <spring:property name="calledFlow" value="some-flow-name" />	 	<pre lang="xml"> 
</custom-processor>
```

</div>Ich habe hier ein Spring-Feature genutzt: Properties mit Getter/Setter lassen sich mittels spring:property mit Werten versorgen. Im Interface <code>MessageProcessor</code> befindet sich die Methode mit folgender Signatur:<div>

```java
public MuleEvent process(MuleEvent event) throws MuleException
```

</div>Wir haben hier keine <code>MuleMessage</code> oder keinen <code>MuleEventContext</code> in der Hand, sondern ein <code>MuleEvent</code>. Brauchen wir das? In den meisten Fällen nicht, aber ohne Beispiel würde ich davon sicher nicht schreiben. Es ist notwendig, wenn es aus der Java-Welt zurück in die Mule-Welt gehen soll:<h2>Mule-Flow aus Java heraus aufrufen</h2>Wollen wir einen Flow aus Java aufrufen, benötigen wir das <code>MuleEvent</code> (bekommen wir im <code>MessageProcessor</code>) und den <code>MuleContext</code> (bekommen wir durch Implementierung von <code>MuleContextAware</code>, siehe oben). Vom <code>MuleContext</code> führt der Weg über die <code>MuleRegistry</code> zum Flow. Der lässt sich dann einfach über <code>process()</code> ausführen:<div>

```java
public MuleEvent process(MuleEvent event) throws MuleException {
 Flow flow = (Flow) context.getRegistry().lookupFlowConstruct(calledFlow);
 MuleEvent result = flow.process(event);
 return result;
}
```

</div>Wozu soll das gut sein? Zugegeben, die Einsatzfälle sind selten, kommen aber vor: So bietet Mule zwar ein for-each, um über eine Collection zu iterieren, aber eine while-Schleife fehlt. Das geht in Java recht einfach, den Schleifenrumpf kann man dann wieder als Mule-Flow realisieren und die vielfältigen Möglichkeiten von Mule zur Kommunikation mit dem Rest der Welt nutzen. Ebenso könnte man selbst ein dynamisches Dispatching auf verschiedene Flows durchführen, so wie Mule es im API-Kit-Router macht.<h2>Fazit</h2>Mule bietet mit seiner grafischen Darstellung der Flows (dahinter steckt eine Spring-XML-Konfigurationsdatei) zwar eine recht komfortable Umgebung für viele Integrationsaufgaben an, oft lohnt jedoch der Rückgriff auf das gute, alte Java. Mit DataWeave in der Enterprise-Edition kann man zwar oft auf Java verzichten, aber auch dort existieren Grenzen oder es wird mit der Kombination XML/DataWeave einfach unübersichtlich. Für die verschiedenen Anforderungen (Kopplung) existieren jedoch mehrere maßgeschneiderte Wege. Aus den Beispielen sollte ersichtlich geworden sein, dass man dort ohne Boilerplate-Code schnell zum Ziel kommt. Schließlich braucht man neben den fachlichen Diskussionen in Integrationsprojekten nicht auch noch technischen Stress.

Von Mule nach Java und zurück

Nach einem langen zweiten Teil und einer noch längeren Pause kommt heute ein kurzer Text über Mocks und Spies in MUnit Tests. Mocks machen das, was man aus JUnit kennt; was Spies machen, werden wir gleich sehen.Um es nicht zu kompliziert zu machen, benutze ich nur einen sehr einfachen Flow für die Demo:<img width="422" height="152" src="https://media.graphassets.com/uI2Kfn0TjCMg0QaLIC2n" alt="Einfacher Flow, der einen Webservice aufruft." />Der Flow stammt aus einem Projekt, das mit RAML (restful api modelling language) und mit dem API-Kit von Mule erstellt wurde. Das ist im Rahmen des Tests aber egal. Worauf es ankommt: Links geht ein JSON-Dokument hinein, Beispiel:

```
{
 "groesse": 1.8,
 "gewicht": 80
}
```

Rechts wieder ein JSON raus, Beispiel:

```
{
 "beschreibung": "Normalgewicht",
 "bmi": 24.7
}
```

In der Mitte steht der Web-Service-Consumer von Mule, der in Ein- und Ausgabe mit XML arbeitet. Die beiden Transformer müssen also zwischen JSON bzw. XML vermitteln und dabei noch Attribute umbenennen.Der erste Transformer (build request) macht aus dem JSON ein XML, das zu der WSDL des SOAP-Service passt:

```
%dw 1.0
%output application/xml
%namespace bmi http://codecentric.de/services/bmi
---
{
 bmi#calculateBmi: {
 input: {
 length: payload.groesse,
 mass: payload.gewicht
 }
 }
}
```

Der zweite Transformer (build response) arbeitet in der Gegenrichtung und produziert aus dem XML wieder JSON:

```
%dw 1.0
%output application/json
%namespace bmi http://codecentric.de/services/bmi
---
{
 beschreibung: payload.bmi#calculateBmiResponse.return.description,
 bmi: payload.bmi#calculateBmiResponse.return.bmi as :number
}
```

Wie gehen wir beim Test vor? Prinzipiell existieren hier zwei Geschmacksrichtungen: eher Unit-Test, bei dem der Test für sich ausführbar ist, oder eher Integrationstest, in dem Randsysteme – hier der SOAP-Service – mitgetestet werden. Welche der beiden Varianten sinnvoller ist, soll hier nicht diskutiert werden (das ist einen eigenen Blog-Post wert).So, jetzt geht es endlich los: Im Anypoint Studio erzeugen wir durch einen Rechtsklick auf den Flow mit MUnit -> Create new suite die leere Hülle für den Testfall:<img loading="lazy" width="421" height="250" src="https://media.graphassets.com/8zphYg6GQFaAjgLiujIH" alt="Testhülle" />Wie viele Dinge in Mule sieht der Testfall einem Flow recht ähnlich. Was anders ist:<ul><li>Es fehlt der Listener (oder endpoint), der den Flow startet. MUnit-Tests werden durch Maven oder aus Anypoint direkt gestartet.</li><li>Schaut man ins XML – oder auf den Reiter „Global Elements“ – sieht man eine „MUnit Configuration“ und Spring Imports. Mit Letzeren gibt man an, welche XML-Dateien mit Flows für den Test geladen werden. Das kann von den XML-Dateien in der deploy.properties abweichen.</li></ul>Den Aufruf des zu testenden Flows hat der Wizard vom Studio freundlicherweise schon direkt generiert. Wir müssen nur noch die richtigen Eingabedaten zur Verfügung stellen, den SOAP-Service mocken und die Ausgabe prüfen. So sieht es aus, wenn’s fertig ist:<img loading="lazy" width="739" height="306" src="https://media.graphassets.com/W2nmIB4BTeusJtVKt1Wn" alt="Flow mit Mock und Asserts" />Jetzt aber schrittweise:Links starten wir mit einem „Set Message“, quasi der Ersatz für den http-Listener, der den Flow sonst mit Daten versorgt.

```
 <munit:set payload="#[getResource('input.json').asStream()]" 
 mimeType="application/json" 
 doc:name="Set Message"/>
```

Er lädt die JSON-Datei mit den Eingabedaten aus src/test/resources/input.json und stellt sie in einem Stream zur Verfügung. Außerdem setzt er den korrekten Mime-Type. Für unseren einfachen Flow reicht das aus. Falls der Flow noch weitere Daten aus dem http-Request benötigt: Hier lassen sich Properties aus allen vier Scopes setzen.<h2>Mock</h2>Der zweite Schritt ist schon der Aufruf des Flows. Ohne weitere Eingriffe würde der Flow den originalen SOAP-Service aufrufen. Da wir das verhindern wollen, ziehen wir einen Mock in den Bereich „Setup“ (im Bild oben). Der Mock sieht im XML folgendermaßen aus:

```
<mock:when messageProcessor=".*:.*" doc:name="Mock soap call">
 <mock:with-attributes>
 <mock:with-attribute name="doc:name" whereValue="#['call bmi-soap']"/>
 </mock:with-attributes>
 <mock:then-return payload="#[getResource('output.xml').asStream()]" mimeType="application/xml"/>
</mock:when>
```

Der schwierigste Teil beim Mock ist es, den richtigen Message-Prozessor zu treffen. Die Eingrenzung erfolgt nach zwei Strategien:<ol><li>Direkt im <code>mock:when</code> Tag mit dem Attribut <code>messageProcessor</code>. Hier zielt man per regulärem Ausdruck auf Namespace und Name des XML-Tags. Das ist leider nicht sehr zielgenau: Es kann ja durchaus mehrere SOAP-Aufrufe im Flow geben. Der Wizard im Anypoint Studio trägt an der Stelle daher nur „<code>.*:.*</code>“ ein, was auf alles zutrifft.</li><li>Durch die Eingrenzung auf Attribute des Message Processors. Der Wizard wählt dafür standardmäßig <code>doc:name</code> aus, prinzipiell kann man hier aber beliebige Attribute verwenden. Da der Vergleichswert eine MEL-Expression enthalten darf, ist hier auch Dynamik möglich.</li></ol>Insgesamt kann man die beiden Strategien als sehr kritisch ansehen: Durch Refactoring in den Flows wird ein Match schnell zerstört. Oder man hat zu viele Treffer. Solange man in den Flows aber keine zusätzlichen technischen IDs für die einzelnen Elemente einführt, existiert einfach keine bessere Lösung.Aufpassen muss man auch, wenn man komplette Flows mocken möchte: Dafür muss man tatsächlich den Flow selbst mocken, nicht die aufrufende Flow-Ref. Außerdem generiert das Studio an der Stelle aktuell noch falsche Werte im Wizard: Flows haben kein <code>doc:name</code>, sondern nur ein <code>name</code>. Bei Sub-Flows ist noch zu beachten, dass man mit <code>matchContains(...)</code> arbeitet (siehe <a href="https://docs.mulesoft.com/munit/v/1.2.1/mock-message-processor#defining-mocks">MUnit-Dokumentation</a> ).Was machen wir im Mock? Er soll den SOAP-Aufruf ersetzen, also laden wir hier eine Payload mit dem SOAP-Ergebnis aus einer Datei und stellen sie als Stream zur Verfügung. Zusätzlich ließen sich hier auch – wie am Anfang des Tests – Properties definieren.Anschließend folgt die Prüfung des Ergebnisses. Ausnahmsweise habe ich hier mal nicht zu meinem Lieblingswerkzeug DataWeave gegriffen, sondern zu den guten alten Mule-Hausmitteln: Das JSON wird zu einer Map gewandelt, aus der man anschließend mittels MEL die Werte holt und vergleicht:

```
 <json:json-to-object-transformer returnClass="java.util.Map" doc:name="JSON to Object"/>
 <munit:assert-on-equals message="BMI wrong" expectedValue="25" actualValue="#[java.lang.Math.round(payload.bmi) + '']" doc:name="Assert BMI"/>
 <munit:assert-on-equals message="Beschreibung wrong" expectedValue="Normalgewicht" actualValue="#[payload.beschreibung]" doc:name="Assert Beschreibung"/>

```

Hier gilt noch die alte Entwicklerweisheit: Fließkommawerte nie auf Gleichheit testen (passt nie), sondern immer runden.<h2>Spy</h2>Auf das Vorspiegeln falscher Tatsachen (Mock) folgt jetzt die Spionage (Spy): Wir schauen dem Flow über die Schulter bzw. direkt ins Herz: Ein Spy wird wie ein Mock auf einen Message-Prozessor losgelassen. Statt jedoch den originalen Aufruf zu ersetzen, lassen sich darin Werte überprüfen. Ein Spy hat keine Lizenz zum Töten, noch schlimmer: Er darf die Payload nicht verändern! Das erzeugt gewisse Probleme: Eigentlich wollte ich die Werte vor dem SOAP-Aufruf überprüfen. Die liegen aber als Stream vor. Lese ich ihn ein, ist er weg (bzw. leer). Eigentlich egal, schließlich haben wir den SOAP-Call ja gegen einen Mock ausgetauscht. Aber Mule lässt uns hier die Payload nicht verändern. Was bleibt? Wir speichern den Stream – der ja nur eine Referenz auf ein Java-Objekt ist – in einer Flow-Variablen. Wir können den Inhalt dann später prüfen. Grafisch sieht das folgendermaßen aus:<img loading="lazy" width="926" height="372" src="https://media.graphassets.com/tNMUAjmdQyyYNVZSVMvR" alt="Kompletter Test-Flow" />Oder der Spy im XML:

```
<mock:spy messageProcessor=".*:.*" doc:name="Spy">
 <mock:with-attributes>
 <mock:with-attribute name="doc:name" whereValue="#['call bmi-soap']"/>
 </mock:with-attributes>
 <mock:assertions-before-call>
 <set-variable variableName="beforeSoap" value="#[payload]" doc:name="Set beforeSoap"/>
 </mock:assertions-before-call>
</mock:spy>
```

Der Spy wird – wie der Mock – über einen regulären Ausdruck und Attribute auf den Message-Prozessor angesetzt. Anschließend folgen die Spionageoperationen, die vor oder nach dem Message-Prozessor ausgeführt werden. Hier ist nur „vorher“ sinnvoll, sonst würden wir nur unseren Mock testen. Statt der Prüfung landet der Stream in der Flow-Variablen beforeSoap.Die Prüfung folgt anschließend im Flow. Mittels DataWeave holen wir uns den interessanten Teil aus der SOAP-Antwort:

```
 <dw:transform-message metadata:id="1b10de07-fcc6-49ff-ae10-7042e019d03a" doc:name="Extract input">
 <dw:input-variable variableName="beforeSoap" doc:sample="input.xml" mimeType="application/xml"/>
 <dw:set-payload resource="classpath:extract-input.dwl"/>
 </dw:transform-message>
```

Das zugehörige DWL-Script:

```
%dw 1.0
%output application/java
%namespace bmi http://codecentric.de/services/bmi
---
flowVars.beforeSoap.bmi#calculateBmi.input

```

Und die Prüfung:

```
<munit:assert-on-equals message="length wrong" expectedValue="1.8" actualValue="#[payload.length]" doc:name="Assert length"/>
<munit:assert-on-equals message="mass wrong" expectedValue="80" actualValue="#[payload.mass]" doc:name="Assert mass"/>
```

<h2>Zusammenfassung</h2>Wer bis hier durchgehalten hat und auch schon JUnit kennt, wird die Gemeinsamkeiten erkannt haben: Man schafft Vorbedingungen, führt den Code unter Test aus und nutzt Mocking (nicht Teil von JUnit), um im Rahmen des Tests nicht interessanten Code bzw. hier komplette Systeme zu ersetzen. Während die Mocks die Ausgabewerte der angeschlossenen Systeme liefern, kann man mithilfe der Spys die Eingabewerte validieren. Der Aufwand für den Test liegt schnell im gleichen Bereich wie der eigentliche Flow. Aber wer schon einmal Java-Code nach TDD entwickelt hat, den dürfte auch dies nicht überraschen.<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Mule Anwendungen mit MUnit Testen (Teil 1): Start im Anypoint Studio: <a href="https://blog.codecentric.de/2016/04/mule-munit-anypoint-studio/">https://blog.codecentric.de/2016/03/mule-munit-anypoint-studio/</a> </li><li>Mule-Anwendungen mit MUnit testen (Teil 2): Testdaten und Asserts <a href="https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/">https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/</a> </li><li>Mule-Anwendungen mit MUnit testen (Teil 3): Tabellenbasierte Tests <a href="https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/">https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric-Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Mule-Anwendungen mit MUnit testen (Teil 4): Mocks und Spies

Am Ende des <a href="https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/">zweiten Teils</a>  hatte ich schon den Begriff „tabellenbasierte Tests“ erwähnt. Was heißt das? Es geht darum, mehrere gleichartige Tests auszuführen, die sich nur durch Eingabe- und erwartete Ausgabedaten unterscheiden. Das Schöne an dieser Art der Tests ist, dass die Tabellen mit den Testdaten auch für weniger IT-affine Personen lesbar sind. Der Fachbereich kann somit nachvollziehen, was im Test passiert oder sogar Testdaten liefern. In unserem Beispiel – dem Body-Mass-Index-Rechner – könnte eine Tabelle mit Testdaten folgendermaßen aussehen:Größe Gewicht BMI Beschreibung 1.88 79 22.35 Normalgewicht 1.88 90 25.46 Präadipositas 1.88 150 42.44 Präadipositas Grad III 1.88 50 14.15 starkes UntergewichtDie Eingabedaten befinden sich in den ersten beiden Spalten (Größe in Metern, Gewicht in Kilogramm), die erwarteten Ergebnisse in den Spalten drei und vier (BMI, zwei Nachkommastellen, Beschreibung).Die Spalten sind durch Tabulatoren getrennt (im Layout nicht erkennbar). Die Aufgabe besteht nun darin, für jede Zeile den BMI-Rechner aufzurufen und das Ergebnis zu überprüfen.Welche Aufgaben müssen wir für den Test abarbeiten? Die CSV-Datei muss gelesen und „zerlegt“ werden (Parsing). Anschließend folgt dann in einer Schleife die gleiche Arbeit, die wir im letzten Teil auch hatten: Daten für einen Aufruf zusammenstellen, Service aufrufen, Ergebnisse überprüfen. Fangen wir an…<h2>Einlesen und parsen</h2>Gemäß Maven-Konventionen gehört die Tabelle mit den Testdaten nach src/test/resources, ich habe noch ein Unterverzeichnis (alias Package) data_tables spendiert. Wer erinnert sich noch daran, wie im ersten Teil die XML-Daten für den SOAP-Aufruf in die Message kamen? Set Message aus der MUnit-Palette ist die korrekte Antwort. Darin steht dann der folgende MEL-Ausdruck:

```
#[getResource('data_tables/bmi.csv').asStream()]
```

Als Ergebnis steht ein InputStream mit der CSV-Datei in der Nachricht. Nicht vergessen: Das Encoding sollte noch passend eingestellt werden (z.B. UTF-8, oder Cp1252 bei Daten vom Fachbereich), außerdem darf der Mime-Type (application/csv) nicht fehlen.Das CSV-Parsen erledigt DataWeave mit einem sehr simplen Script:

```
%dw 1.0
%output application/java
---
payload
```

Dass in dem Stream CSV steht, weiß DataWeave bereits durch den Mime-Type, aber woher weiß DataWeave, wie das CSV aussieht? Das ist über die Reader Configuration möglich, die man per rechtem Mausklick auf die Payload erreicht:<img width="569" height="328" src="https://media.graphassets.com/6ajqHNItQFSF0A6LyOmC" alt="reader-configuration" />Quote benötigt man dann, wenn innerhalb einer Zelle das Trennzeichen oder ein Zeilenumbruch steht, Ignore Empty Line ist selbsterklärend. Der Haken bei Header bewirkt, dass die erste Zeile als Überschrift erkannt wird. Escape wird innerhalb einer Zelle dem Quote-Zeichen vorangestellt, falls es in der Zelle vorkommt. Schwierig wird es beim Separator: Wie gibt man ein Tab-Zeichen ein? Ich habe es in der Oberfläche nicht hinbekommen und habe (mal wieder) die XML-Ansicht eingeschaltet:

```
<dw:input-payload mimeType="application/csv" doc:sample="list_csv.csv">
 <dw:reader-property name="separator" value="&#009;" />
</dw:input-payload>
```

Wer den ASCII-Code im Kopf hat: Für den Tabulator steht die 9. Die anderen Attribute fehlen im XML, weil sie auf den Default-Werten stehen.Über den Rechtsklick auf die Payload lassen sich auch noch die Meta-Daten der CSV-Datei definieren, entweder manuell oder über eine Beispieldatei: <img loading="lazy" width="549" height="517" src="https://media.graphassets.com/I2mXaZmjQdKvzcdt89ET" alt="csv-metadata" />Macht man sich die Mühe mit den Meta-Daten, kann man in einem folgenden DataWeave Attribute per Drag and Drop einfach von links nach rechts ziehen und spart sich das manuelle Tippen. Aber auch beim Tippen wird die Welt einfach: Control-Space-Completion funktioniert ebenso auf Basis der Meta-Daten. Hier kommen wir aber auch ganz gut ohne diese Information aus.Was steht nun nach dem DataWeave mit dem simplen Script payload in der Message? Eine ArrayList von Maps, letztere mit Spaltennamen als Key und den Zellinhalten als Value. Damit haben wir eine Struktur, über die sich mit For Each iterieren lässt.<h2>Vorbereiten und aufrufen</h2>Innerhalb der Schleife enthält die Message jetzt die eben genannte Map, aus der wir die Testdaten für den SOAP-Aufruf vorbereiten müssen. Der Übersichtlichkeit halber habe ich das in einen Sub-Flow ausgelagert: <img loading="lazy" width="223" height="139" src="https://media.graphassets.com/REeTXb62QoOZ2P3KJqEl" alt="prepare-row" />Im ersten Schritt wird per Set Variable die Payload in die Variable row gesichert. Das ist notwendig, da der nächste Schritt die Payload ersetzt und wir den Inhalt noch für die später folgende Verifikation benötigen.Die SOAP-Aufrufe innerhalb der Schleife sind gleichartig: Das XML ist bis auf die Werte für Körpergröße und Gewicht immer gleich. Um es zu erzeugen, bietet Mule Parse Template, eine minimalistische Template-Engine (ohne Bedingungen und Schleifen), die in einem Text MEL-Ausdrücke durch deren Auswertungsergebnis ersetzen kann. Das Template ähnelt damit dem konstanten XML aus dem vorigen Teil der Serie:

```
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
 xmlns:bmi="http://codecentric.de/services/bmi">
 <soapenv:Header/>
 <soapenv:Body>
 <bmi:calculateBmi>
 <input>
 <length>#[payload.Grösse]</length>
 <mass>#[payload.Gewicht]</mass>
 </input>
 </bmi:calculateBmi>
 </soapenv:Body>
</soapenv:Envelope>
```

Statt payload hätte ich übrigens auch row schreiben können, da wir die Payload in eine Flow-Variable kopiert haben und die Flow-Variablen direkt im Scope für MEL-Ausdrücke stehen.Der Aufruf des Service geschieht – wie bei MUnit üblich – über eine Flow Reference. Auch hier hat sich gegenüber dem letzten Teil der Serie nichts geändert.<h2>Verifizieren</h2>Der SOAP-Aufruf gibt ein XML zurück. Dessen Überprüfung läuft schrittweise ab. Da die ersten drei Schritte für diesen Testfall gleich sind wie für den Testfall aus dem letzten Teil der Serie, habe ich sie in einen Sub Flow ausgelagert. Schließlich gilt auch in Tests: Don’t repeat yourself. <img loading="lazy" src="https://media.graphassets.com/A7WkKJMuQwOCoqdBJhMi" alt width="385" height="140" />Zur Erinnerung: Der erste DataWeave streift den SOAP-Envelope ab, der Filter prüft die Struktur des XMl-Response gegen seine XSD, der zweite DataWeave extrahiert die beiden relevanten Teile aus dem Ergebnis (bmi, description) in gleichnamige Flow-Variablen.Die folgenden Asserts stehen wieder in einem Sub Flow: <img loading="lazy" width="221" height="127" src="https://media.graphassets.com/4zQhp38ZQLq9oegbQSlD" alt="assert-row" />Die Ausdrücke greifen auf die Flow-Variable row zurück, in der unsere Tabellenzeile als Map steht. Daraus ergibt sich das erwartete Ergebnis (expectedValue), das mit dem Ergebnis des Aufrufs (actualValue) verglichen wird:

```
 <munit:assert-on-equals message="bmi" 
 expectedValue="#[row.BMI]" 
 actualValue="#[bmi]" 
 doc:name="Assert bmi" />
 <munit:assert-on-equals message="description" 
 expectedValue="#[row.Beschreibung]" 
 actualValue="#[description]" 
 doc:name="Assert description" />
```

Zusammengesetzt ergeben die Einzelteile das folgende Gesamtbild: <img loading="lazy" width="689" height="254" src="https://media.graphassets.com/YqzCDTHTPKYLWoYpOqIj" alt="table-based-test" />Es beginnt mit dem Lesen/Parsen der CSV-Datei. Dann folgt die Schleife, in der nur noch Sub Flows aufgerufen werden. Ich habe das alte Motto Caesars beherzigt: Teile und herrsche. Analog zur Programmierung (z. B. in Java) sollten die Einzelteile (z. B. Methoden) klein und übersichtlich sein.<h2>Zusammenfassung und Ausblick</h2>Vergleichen wir den hier gezeigten tabellenbasierten Testfall mit dem einfachen Testfall aus dem letzten Teil der MUnit-Serie: Was hat sich geändert? Gar nicht so viel: Einige Teile sind in Sub Flows gewandert, was man zwecks Übersichtlichkeit auch schon vorher hätte machen können. Einige dieser Sub Flows  sind jetzt auch über Flow-Variablen konfigurierbar, was im ersten Teil nicht notwendig war. Ansonsten sind die Änderungen – und damit der Mehraufwand – eher gering: Zwei Schritte zum Lesen und Parsen der CSV-Datei sowie die Schleife (For Each) sind dazugekommen. Statt die XML-Testdaten direkt zu lesen, kommt das Mule-Element Parse Template zum Einsatz.Was haben wir gewonnen? Wir haben mehrere Testfälle mit gleichartiger Struktur ohne großen Aufwand und vor allem ohne Copy-and-Paste-Orgien umgesetzt. Zusätzlich haben wir den Testcode von den Testdaten getrennt. Als Nebeneffekt liegen die Testdaten in einem Format vor, das man als Austauschformat mit dem Fachbereich nutzen kann.Im nächsten Teil der Serie werde ich mich dann um das Mocking von Konnektoren kümmern. Dafür brauche ich dann aber ein neues Beispiel, beim BMI-Rechner war schließlich nichts zu mocken.<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Mule Anwendungen mit MUnit Testen (Teil 1): Start im Anypoint Studio: https://blog.codecentric.de/2016/03/mule-munit-anypoint-studio/</li><li>Mule-Anwendungen mit MUnit testen (Teil 2): Testdaten und Asserts <a href="https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/">https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric-Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Mule-Anwendungen mit MUnit testen (Teil 3): Tabellenbasierte Tests

Was ist ein ESB und wofür kann man ihn nutzen?

Im <a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">ersten Teil</a>  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 <a href="http://www.mulesoft.com/mule-esb-open-source-esb">Mule ESB</a> von <a href="http://www.mulesoft.com/">Mulesoft</a> . 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.<div><a href="https://media.graphassets.com/2yc9HXViSZWesXoCrbMk"><img title="mule-projektstruktur" alt="Mule Projektstruktur" src="https://media.graphassets.com/2yc9HXViSZWesXoCrbMk" width="256" height="219" /></a> Mule Projektstruktur, passend für einen Maven-Build.</div>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.<div><a href="https://media.graphassets.com/4Zg6h843Ql2RsbMKKPg2"><img loading="lazy" title="mule-hellobusFlow1" alt src="https://media.graphassets.com/4Zg6h843Ql2RsbMKKPg2" width="152" height="149" /></a> Erster Flow</div>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:<div><a href="https://media.graphassets.com/CXu9ui8Ts2FiASYwby7o"><img loading="lazy" title="mule-file-endpoint" alt src="https://media.graphassets.com/CXu9ui8Ts2FiASYwby7o" width="643" height="552" /></a> Dialog mit Einstellungen zum File-Endpoint.</div>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:<a href="https://media.graphassets.com/CjJJQRDeS9OLpcNavvjI"><img loading="lazy" title="mule-file-endpoint-detail" alt src="https://media.graphassets.com/CjJJQRDeS9OLpcNavvjI" width="591" height="115" /></a> 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:<div><a href="https://media.graphassets.com/6w2hwE7PRoyEm4R3I0sB"><img loading="lazy" title="mule-file-endpoint-out" alt src="https://media.graphassets.com/6w2hwE7PRoyEm4R3I0sB" width="646" height="449" /></a> Edit-Dialog für den ausgehenden File-Endpoint.</div>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:<div><a href="https://media.graphassets.com/I24XkRTeSVuqhfTtMTz0"><img loading="lazy" title="mule-flow-mit-logger" alt src="https://media.graphassets.com/I24XkRTeSVuqhfTtMTz0" width="359" height="149" /></a> Flow mit Logger.</div>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:<div><a href="https://media.graphassets.com/ltShDviwQhuCZ6PR5mKA"><img loading="lazy" title="mule-logger" alt src="https://media.graphassets.com/ltShDviwQhuCZ6PR5mKA" width="646" height="451" /></a> Edit-Dialog zum Logger.</div>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.<h2>Weitere Teile dieser Artikelserie</h2><ol><li><a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">Was ist ein ESB und wofür kann man ihn nutzen?</a> </li><li><a href="http://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-komponenten/">Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-transform/">Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren</a> </li><li><a href="http://blog.codecentric.de/2013/06/tutorial-enterprise-service-bus-mit-mule-esb-integration-von-cics-programmen/">Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-esb-transport-connector-endpoint-grundlagen/">Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-enterprise-service-bus-mule-esb-performance-threads/">Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mule-esb-jmx-kontrolle-steuerung/">Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX</a> </li><li><a href="http://blog.codecentric.de/2013/09/veroffentlichen-der-versionsnummer-von-mule-applikationen/">Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mit-mule-esb-exceptions-email/">Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email</a> </li></ol>

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

Im letzten Teil habe gezeigt, wie man im Mule Studio ein kleines Projekt anlegt. Die umgesetzte Funktionalität war jedoch einfach: Im Eingabeverzeichnis liegende Dateien wurden in das Ausgabeverzeichnis kopiert.  Zusätzlich wurde für jede Datei eine Meldung über den Logger ausgegeben.Ich habe mich gefragt, womit ich in diesem Teil weitermachen soll: In einer Verkaufsveranstaltung würde ich vermutlich bunte Bilder zeigen, auf denen die vielen Konnektoren (File, JMS, Http, etc.) und internen Blöcke (Filter, Router, Transformatoren) von Mule zu sehen sind. Die Serie soll aber keine Verkaufsveranstaltung sein, daher spare ich mir das für spätere Artikel auf. Heute steht die MuleMessage und wie man ihren Inhalt transformiert im Mittelpunkt.<h2>MuleMessage</h2>Fangen wir also mit der MuleMessage an. Sucht man im Mule Studio – zur Erinnerung: ein Eclipse mit zusätzlichen Plugins – über „Open Type…“ nach <code>MuleMessage</code>, so öffnet sich ein Interface. Also steckt ein Java-Objekt dahinter. Und was ist seine Aufgabe? Im Wesentlichen ist die MuleMessage ein Container, der durch den ESB wandert. Schauen wir uns dazu den Flow aus dem letzten Teil nochmals an:<div><img title="mule-flow-mit-logger" alt src="https://media.graphassets.com/wlypgKAYSwmloUb6qgDw" width="359" height="149" />Der einfache Flow aus dem letzten Teil.</div>Links und rechts sieht man die beiden Endpoints, über die Mule mit der Außenwelt kommuniziert. In der Mitte symbolisieren die Pfeile zwischen den Komponenten den Datenfluss innerhalb von Mule, genau dort werden Instanzen von MuleMessage weitergereicht. Eine Komponente kann eine Message unverändert durchreichen und einen Seiteneffekt auslösen (Logger). Sie kann aber auch die Message verändern (transformieren). Einige Komponenten lassen sogar Messages verschwinden (Filter) oder erzeugen aus einer einzelnen Nachricht mehrere (Collection Splitter).Wenn der „Inbound Endpoint“ auf der linken Seite eine neue Datei findet, erzeugt er eine MuleMessage und schickt sie zum Logger. Wenn der „Outbound Endpoint“ die MuleMessage erhält, schreibt er wieder eine Datei. Mit Ausnahme einiger kleiner Details wird der gesamte Zustand des Busses in den Messages gehalten. Eine MuleMessage lässt sich in vier Bereiche aufteilen:<ol><li>Die Properties teilen sich in mehrere Maps (String -> Object) auf, die wichtigsten davon sind die Inbound Properties und die Outbound Properties. Im Beispiel-Flow steht in der Inbound Property „originalFilename“ der Name der Eingabedatei. Setzt man keine Outbound Property „filename“, so wird dort automatisch der Eingabedateiname übernommen.</li><li>Die Anwendungsdaten stehen in der Payload, deren Typ ist Object. Bei der Nutzlast kann es sich also um ein beliebiges Java-Objekt handeln. Hier unterscheidet sich Mule von anderen ESB-Implementierungen, die sich oft auf XML-Nachrichten beschränken.</li><li>In einigen Fällen, zum Beispiel bei der Verarbeitung von Emails, enthält die MuleMessage zusätzlich noch Attachments.</li><li>Die ExceptionPayload ist nur gefüllt, wenn bei der Verarbeitung Fehler aufgetreten sind. Sie enthält Informationen zur Exception und die Nachricht, durch die der Fehler ausgelöst wurde.</li></ol>Wie mag in unserem Beispiel die Payload aussehen? Es ist eine Implementierung von <code>InputStream</code>. Die Datei wird also nicht sofort gelesen, sondern nur als Dateihandle über den Bus weitergereicht. Im Beispiel würde sie auch der Logger nicht anfassen, erst der Outbound Endpoint kopiert die Datei. Die Mule-Implementierung des <code>InputStream</code>sorgt dafür, dass die Eingabedatei beim Aufruf von close() gelöscht oder verschoben wird. Baut man eigene Transformer, darf man daher auf keinen Fall das Schließen der Datei vergessen. Der Trick spart Speicher: Die Anwendungsdaten belasten den Speicher erst in dem Moment, in dem er auch wirklich benötigt wird. Im Idealfall liegt die Datei sogar nie komplett im Speicher. Das funktioniert, wenn nur Teile benötigt werden oder sie komplett per Streaming (wie im Beispiel) verarbeitet werden kann.<h2>Java-Komponenten</h2>Wie kann man jetzt in die Verarbeitung der MuleMessage eingreifen? Über die vielen „Kästen“ (Komponenten), die man rechts in der Toolbox findet. Zieht man einen der Kästen auf einen Pfeil, so wird er an genau dieser Stelle in den Flow eingebaut. Im letzten Artikel wurde auf diese Art der Logger eingebaut, der den Kopiervorgang auf der Konsole bestätigt.Für die Komponenten mit einer eigenen Java-Klasse existieren zwei „Kästen“:<ol><li>„Java“ in der Gruppe „Components“</li><li>„Java“ in der Gruppe „Transformers“</li></ol>Ungeschickterweise haben sie den gleichen Namen, obwohl dahinter verschiedene Implementierungen konfiguriert werden müssen. Wählt man die falsche, antwortet Mule mit einer unverständlichen Exception, also in den nächsten Absätzen aufgepasst!Die erste Variante ist am einfachsten, bietet aber weniger Möglichkeiten als die anderen. Die Konfiguration ist schlicht, die notwendigen Angaben beschränken sich auf den Namen der Komponente und den voll qualifizierten Klassennamen. Letzerer lässt sich nicht nur als String eingeben, sondern man kann dafür auch den Klassenauswahldialog von Eclipse nutzen. Als Name der Komponente empfehle ich den Klassennamen ohne Packagenamen, dann erkennt man im Diagramm auf einen Blick, was sich hinter dem Symbol verbirgt. In der Klasse muss man nur eine Methode (public) mit einem Argument implementieren. In dem Argument wird die Payload übergeben, der Typ muss also passen. Ist man nicht sicher ist, was Mule liefert, kann man erst mal „Object“ nehmen und mit dem Debugger nachschauen, was ankommt. Der Ergebnistyp muss so gewählt werden, dass die nächste Komponente im Fluss damit klar kommt.Für die beiden folgenden Varianten zieht man den anderen Kasten, nämlich „Java“ aus der Gruppe „Transformers“ in den Flow. Auch hier ist eine Klasse anzugeben, sie muss aber zwingend das Interface <code>Transformer</code> implementieren.Die zweite Variante implementiert das Interface nicht direkt, sondern leitet von <code>AbstractTransformer</code> ab. Die Basisklasse erspart eine Menge Code, implementieren muss man nur noch eine Methode:

```java5
Object doTransform(Object src, String enc) throws TransformerException
```

Als erstes Argument wird wieder die Payload übergeben, Rückgabewert ist ebenso die Payload. Das zweite Argument kann genutzt werden, um auf das Encoding zuzugreifen (bei Verarbeitung von Textdateien). Es ist aber nicht das im Konfigurationsdialog angegebene Encoding, das erhält man per <code>getEncoding()</code>.Die dritte Variante nutzt eine andere Basisklasse – <code>AbstractMessageTransformer</code> – in dem eine andere Methode zu implementieren ist:

```java5
public Object transformMessage(MuleMessage message, String enc) throws TransformerException
```

Statt der Payload hat man jetzt die Message in der Hand, über die man natürlich wieder auf die Payload zugreifen kann. Die Methode sollte die veränderte oder eine neue Message zurückgeben. Sinnvoll ist diese Variante immer dann, wenn man nicht nur auf die Payload, sondern auch auf andere Teile der MuleMessage (Properties, Attachments) zugreifen möchte. Für den Rest dieses Artikels werde ich nur die zweite Variante benutzen.<h2>Unsere erste Komponente</h2>Was ist ein sinnvolles und dazu noch überschaubares Beispiel? Da Mule für die meisten in der Praxis geforderten Umwandlungen (CSV, XML, JSON, Objektgraphen etc. in ein anderes aus der Liste) schon fertige Transformatoren mitbringt, war die Suche nach dem Beispiel schwieriger als die Implementierung. Der Transformer arbeitet ähnlich wie das Modul mod_mime_magic aus dem Apache Webserver. Er schaut sich die ersten Bytes der Payload an und bestimmt dann den Dateityp. Implementiert habe ich das nur für einige Bildformate (bmp, gif, jpg, tif). Die für das Format übliche Dateiendung wird anschließend in die Outbound-Property „fileType“ der <code>MuleMessage</code> geschrieben, ein Ablageort, auf den auch mit der Mule-Expression-Language leicht zugegriffen werden kann. Der spätere Beispiel-Flow wird dies ausnutzen, um Dateien entsprechend ihres Typs in verschiedene Verzeichnisse zu sortieren.Der Kern des Transformers ist die Methode <code>transformMessage()</code>:

```java5
@Override
public Object transformMessage(MuleMessage message, String outputEncoding) 
throws TransformerException {
 byte[] data = (byte[]) message.getPayload();
 for (int i = 0; i < formats.length; i++) {
 FileFormat format = formats[i];
 if (format.matches(data)) {
 message.setProperty("fileType", format.getSuffix(), PropertyScope.OUTBOUND);
 if (logger.isInfoEnabled()) {
 logger.info("fileType is " + format.getName()
 + " (suffix: " + format.getSuffix() + ")");
 }
 break;
 }
 }
 return message;
}
```

Was geschieht darin? Nicht viel, die Payload – der Dateiinhalt als Byte-Array – wird der Reihe nach an Instanzen von <code>FileFormat</code> übergeben. Sobald man einen Treffer landet, wird die Property gesetzt und gegebenenfalls noch eine Log-Message abgesetzt. Das war’s auch schon. Der zugehörige Flow sieht folgendermaßen aus:<div><img loading="lazy" alt="mule-file-sorter-flow" src="https://media.graphassets.com/pAXqPMdRj6H7RBY2Mpuk" width="731" height="368" />Mule-Flow zum Verteilen von Dateien auf Basis des Dateiinhalts.</div>Links startet der Flow mit dem File-Endpoint, der einen InputStream als Payload erzeugt. Über den Transformer „File to Byte Array“ wird daraus ein Byte-Array, das wir an unseren <code>FileRecognizer</code> weitergeben können. Falls dieser die Datei erkennt, setzt er eine Property, die man im Choice-Router auswerten kann. Welche Bedingungen an den einzelnen Ausgängen stehen sieht man leider nicht in der Flow-Ansicht, aber ein Doppelklick hilft:<div><img loading="lazy" alt="mule-choice-router-configuration" src="https://media.graphassets.com/U2hswd7QqW2YOQhnO9WA" width="625" height="625" />Konfiguration des Mule-Choice-Routers.</div>Die ersten beiden Routen prüfen auf die Dateiformate gif und jpg. Andere erkannte Dateiformate – aber auch alle unerkannten mit <code>fileType == null</code> – landen auf der dritten, der Default-Route. Die Bedingungen sind in der Mule-Expression-Language (MEL) geschrieben. Die MEL ist einen eigenen Blog-Artikel wert, daher hier nur die wichtigsten Informationen: Ein MEL-Ausdruck wird grundsätzlich in #[] eingeschlossen. Innerhalb von Ausdrücken kann auf Properties von POJOs in der üblichen Property-Syntax zugegriffen werden, aus <code>.outboundProperties</code> wird intern ein Aufruf von <code>getOutboundProperties()</code>. Strings sind in einfache Anführungszeichen einzuschließen, da der gesamte Ausdruck im XML in doppelten Anführungszeichen steht. Auf die Elemente von Maps mit Strings als Schlüssel lässt sich in Array-Syntax zugreifen. Ansonsten existieren die typischen Operatoren (+, -, etc.) analog zu Java.Die Bedingungen am Choice-Router ergeben zusammen eine if-else-Kaskade, mit einem unbedingten else-Zweig am Ende (der Default-Route). Die Default-Route sollte man auf keinen Fall weglassen, da ansonsten Nachrichten im Nirwana verschwinden können. Selbst wenn man alle Fälle abzudecken glaubt, sollte man eine Default-Route einbauen. In ihr kann immer noch eine Log-Meldung ausgeben und die Payload mittels eines File-Endpoints in einem Fehler-Verzeichnis speichern.Die Routen enden in File Endpoints, jeweils mit einem eigenen Verzeichnis. Auf Basis des Dateiinhalts erkannte gif- oder jpg-Bilder landen also in gleinamigen Verzeichnissen, alle anderen Dateien im Verzeichnis other. Da wir nur eine zusätzliche Property gesetzt haben, bleiben die Dateinamen erhalten (wie im Beispiel aus dem letzten Artikel).<h2>Zusammenfassung</h2>Was haben wir nun erreicht? Einen ESB dafür genutzt, einige Dateien in Verzeichnisse zu sortieren? Ein geübter Unix-Nutzer löst das Problem sicher mit weniger als zehn Zeilen bash-Script. Es ist halt das übliche Problem mit Beispielen: Sind sie übersichtlich, so sind sie meistens inhaltlich flach. Die zwei wesentlichen Teile aus diesem Beispiel kann man sich aber auch in der realen Welt vorstellen: Eine Java-Komponente, die den Inhalt einer Message analysiert und Properties setzt sowie einen Choice-Router, der auf Basis der Property die Message auf unterschiedlichen Wegen weiterleitet. In der IT-Landschaft nach einer Firmen-Fusion könnte sich hinter den Wegen jeweils ein IT-System aus einer der ursprünglichen Firmen verbergen. Vorne könnten jedoch Aufträge, Rechnungen oder andere Daten bereits über einen gemeinsamen Kanal eintreffen (der in der Realität meistens Fällen auch kein File Endpoint sein dürfte).Wie geht es weiter? Im nächsten Teil soll dann tatsächlich eine Message transformiert werden, statt nur auf Basis des Inhalts Properties zu setzen. Der Schwerpunkt wird dabei nicht auf der Transformation liegen – dafür habe ich wieder nur ein weniger sinnvolles Beispiel – sondern auf der Konfiguration der Java-Komponente.<h2>Weitere Teile dieser Artikelserie</h2><ol><li><a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">Was ist ein ESB und wofür kann man ihn nutzen?</a> </li><li><a href="http://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-komponenten/">Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-transform/">Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren</a> </li><li><a href="http://blog.codecentric.de/2013/06/tutorial-enterprise-service-bus-mit-mule-esb-integration-von-cics-programmen/">Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-esb-transport-connector-endpoint-grundlagen/">Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-enterprise-service-bus-mule-esb-performance-threads/">Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mule-esb-jmx-kontrolle-steuerung/">Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX</a> </li><li><a href="http://blog.codecentric.de/2013/09/veroffentlichen-der-versionsnummer-von-mule-applikationen/">Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mit-mule-esb-exceptions-email/">Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email</a> </li></ol>

Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten

Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren

Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…

Ist der ESB erst mal produktiv, möchte man vielleicht wissen, was darin so alles vorgeht. Wie bei jedem Server richtet sich der Blick zuerst auf das Log-File. In einen Mule-Server kann man jedoch auch durch andere „Fenster“ hineinschauen: Die <a href="http://www.mulesoft.org/documentation/display/current/Mule+Management+Console">Mule Management Console</a> (nur in der Enterprise-Version) oder <a href="http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html">JMX</a>  (auch in der Community-Version). Neben der Überwachung lassen sich per JMX auch Parameter zur Laufzeit ändern. JMX bleibt auch dann weiterhin nützlich wenn man mit der Management Console arbeitet, da sie ebenso einen Zugriff auf die JMX-Beans anbietet. JMX (Java Management Extension ist bereits seit Version 1.5 in der JVM enthalten. JMX verwaltet sogenannte MBeans, die lesbare und/oder schreibbare Attribute sowie Operationen enthalten können. Das folgende Programm zeigt alle in der JVM existierende MBeans mit ihren Attributen und Operationen an:

```Java
public class BeanLister {
 public static void main(String[] args) throws Exception {
 MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
 for (ObjectInstance oi : mbs.queryMBeans(null, null)) {
 System.out.println(oi.getObjectName().toString());
 MBeanInfo info = mbs.getMBeanInfo(oi.getObjectName());
 MBeanAttributeInfo[] attributes = info.getAttributes();
 System.out.println(" attributes:");
 for (int i = 0; i < attributes.length; i++) {
 System.out.println(" " + attributes[i].getName());
 }
 MBeanOperationInfo[] operations = info.getOperations();
 System.out.println(" operations:");
 for (int i = 0; i < operations.length; i++) {
 System.out.println(" " + operations[i].getName());
 }
 }
 }
}
```

Ist ja ganz nett, wenn man innerhalb eines Java-Programms per JMX in das Java-Programm schauen kann, das ginge jedoch auch einfacher. Wie sieht es aus, wenn wir von draußen in eine JVM schauen wollen? Dafür muss der MBeanServer über eine Remoting-Technologie zugänglich gemacht werden. Dafür gibt es verschiedene Möglichkeiten: Ein Tomcat bietet zum Beispiel eine Web-Schnittstelle an, die sich per Browser bedienen lässt. Ähnliche Schnittstellen bieten auch die gängigen JEE-Server. Serienmäßig – auch ohne EE –  im JDK enthalten ist die Möglichkeit, den MBeanServer per RMI verfügbar zu machen. Das lässt sich sowohl aus dem Programm heraus als auch über die Kommandozeile beim Aufruf der JVM erledigen. Was hilft einem die RMI-Schnittstelle? Muss man sich dafür jetzt extra einen Client schreiben? Nein: Dem JDK liegt mit dem Programm jconsole ein passender Swing-Client bei, hier ein Screenshot:<div><a href="https://media.graphassets.com/TUXp4IoTVepEtW3dHpEt"><img alt="Screenshot der JMX-Console." src="https://media.graphassets.com/TUXp4IoTVepEtW3dHpEt" width="702" height="349" /></a> Screenshot der JMX-Console. Links der Baum mit den MBeans, rechts die Attribute einer MBean.</div>Mit jconsole lassen sich sowohl allgemeine Daten über die JVM anzeigen (über die ersten fünf Tabs) als auch alle MBeans der JVM einzeln ansprechen (im letzten Tab MBeans).<h1>JMX in Mule zugänglich machen</h1>In der Enterprise-Version von Mule ist der Zugriff auf die JMX-Daten über die Management Console möglich, dort muss man sich um nichts kümmern, die nette Web-Oberfläche ist auch recht intuitiv zu bedienen. In der Community-Edition ist ein wenig Arbeit notwendig, dort lässt sich der JMX-Zugriff per RMI einschalten, wenn man folgden Schnipsel in sein XML einbaut:

```XML
<management:jmx-server>
 <management:connector-server
 url="service:jmx:rmi:///jndi/rmi://localhost:1099/server"
 rebind="false" />
 <management:credentials>
 <spring:entry key="admin" value="geheim" />
 </management:credentials>
</management:jmx-server>
```

An der URL erkennt man, dass der Zugriff per RMI läuft. Startet man jconsole, muss man dort genau die gleiche URL eingeben:<div><a href="https://media.graphassets.com/TX5V7n4PS7Sib5BeqptQ"><img loading="lazy" alt="Login-Maske von jconsole." src="https://media.graphassets.com/TX5V7n4PS7Sib5BeqptQ" width="417" height="356" /></a> Login-Maske von jconsole.</div>Wer möchte, kann natürlich einen anderen Port nehmen. Die Verbindung ist in dieser Konfiguration nicht verschlüsselt, eine entsprechende Warnung beim Login in jconsole muss man daher wegklicken. Der Port sollte aber sowieso nicht „von außen“ erreichbar sein, sondern nur im internen (Firmen-)Netzwerk. JMX unterstützt auch eine SSL-Verschlüsselung, auf deren Konfiguration gehe ich hier jedoch nicht weiter ein.Schaut man sich per jconsole einen Mule-Server an, so sieht man auf der oberen Ebene den Eintrag „Mule.xxx“, wobei „xxx“ der Name der im Server laufenden Mule-Applikation ist. Im folgenden Bild sind einige Knoten aufgeklappt:<div><a href="https://media.graphassets.com/5PdZei2IRCyCwkQ9lSQ9"><img loading="lazy" alt="Blick per jconsole in einen laufenden Mule-Server." src="https://media.graphassets.com/5PdZei2IRCyCwkQ9lSQ9" width="777" height="464" /></a> Blick per jconsole in einen laufenden Mule-Server.</div>Die wichtigsten MBeans von Mule:<ul><li>Application: Statistik über die gesamte Mule-Applikation.</li><li>Connector: Alle Konnektoren der Applikation, mit der Möglichkeit, sie anzuhalten und wieder zu starten.</li><li>Endpoint: Statische Daten zum Endpoint, mit der Möglichkeit, den Endpoint zu deaktivieren (disconnect) bzw. wieder zu aktivieren (connect).</li><li>Flow: Statistik, aufgeschlüsselt nach Flows der Applikation.</li></ul>Für eine schnelle Analyse sind die Statistiken schon mal interessant: Die Statistik zeigt, welche Flows wie stark belastet sind und wie die Verarbeitungszeiten aussehen. Die Management Console bietet darüber hinaus noch weitere Möglichkeiten, zum Beispiel eine grafische Aufbereitung oder die Definition von Alerts, so dass man bei Überschreitung von Grenzwerten automatisch benachrichtigt wird (z.B. per SNMP-Trap).Wer sich das Bild genauer ansieht, entdeckt unten auch die MBean „de.codecentric.jmxdemo“. Sie stammt nicht von Mule, hier wird etwas aus der eigenen Applikation zugänglich gemacht.<h1>Eigene JMX-Beans in Mule</h1>Bevor ich zu der eigenen MBean in Mule komme, brauche ich erst mal eine Beispielanwendung. Sie nutzt wieder meinen „Lieblingsbeispielendpoint“, den File-Endpoint. Er ist halt für eine Demo so schön einfach…Der Flow nimmt Dateien in einem Verzeichnis entgegen und legt sie – je nach Einstellung zur Laufzeit – links oder rechts ab. Falls man sich weder für links noch für rechts entscheiden kann, gibt es noch einen default-Weg. Grafisch erhält man:<div><a href="https://media.graphassets.com/Tff0vso6SUebRiYHV0cc"><img loading="lazy" alt="Flow zum Verteilen von Dateien." src="https://media.graphassets.com/Tff0vso6SUebRiYHV0cc" width="688" height="368" /></a> Flow zum Verteilen von Dateien.</div>Von links nach rechts ein File-Endpoint, ein Java-Transformer (der eine Property setzt), ein Logger und der Choice-Router mit den drei möglichen Ausgängen, an denen jeweils ein File-Endpoint für die unterschiedlichen Zielverzeichnisse folgt. In „echten“ Projekten wären das vermutlich eher SOAP, REST oder sonstige Aufrufe an verschiedene Backendsysteme.Schauen wir uns einige der Teile – vor allem die nicht im Bild sichtbaren – im XML-Format an. Beginnen wir mit der MBean. Die muss man nicht nur implementieren, sie muss auch irgendwie zum Leben erweckt werden. Das heißt, es muss zur Laufzeit eine Instanz erzeugt werden. Am elegantesten geschieht das in Mule durch eine Spring-Bean. Da wir nur eine Instanz benötigen, darf es ein Singleton sein:

```XML
<spring:beans>
 <spring:bean id="Control"
 name="Control"
 class="de.codecentric.jmxdemo.Control"
 scope="singleton">
 <spring:property name="direction" value="right" />
 </spring:bean>
</spring:beans>
```

Der Getter- und Setter im Java-Code sind langweilig, der interessante Teil ist der Konstruktor, in dem sich die MBean selbst beim JMX-Server anmeldet:

```Java
public class Control implements ControlMBean {
 private String direction;

 public Control() throws MalformedObjectNameException, InstanceAlreadyExistsException,
 MBeanRegistrationException, NotCompliantMBeanException {
 MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
 ObjectName name = new ObjectName("de.codecentric.jmxdemo:type=Control");
 try {
 mbs.getObjectInstance(name);
 mbs.unregisterMBean(name);
 } catch (InstanceNotFoundException e) {
 ; // ignore
 }
 mbs.registerMBean(this, name);
 }

 // Getter und Setter fehlen hier.
}
```

Den try-catch-Block benötigt man wegen des Hot-Deployments in Mule: Der MBeanServer lebt solange wie die JVM. Wird die Applikation zum zweiten mal deployed, so kennt der MBeanServer die MBean bereits, sie muss also erst mit unregisterMBean(…) entfernt werden.Dieser Teil der Konfiguration macht die MBean bereits in Mule bekannt, so dass wir sie im Flow innerhalb eines Java-Transformers nutzen können:

```XML
<flow name="jmxdemoFlow1" doc:name="jmxdemoFlow1">
 <file:inbound-endpoint path="C:\MuleDemo\input" responseTimeout="10000"
 doc:name="File"
 moveToDirectory="C:\MuleDemo\processed" />
 <custom-transformer class="de.codecentric.jmxdemo.DirectionSetter"
 doc:name="DirectionSetter">
 <spring:property name="controller" ref="Control" />
 </custom-transformer>
 <logger level="ERROR" doc:name="Logger"
 message="#['Richtung: ' + message.outboundProperties['direction']]">
 </logger>
 <choice doc:name="Choice">
 <when expression="#[message.outboundProperties['direction']=='left']">
 <file:outbound-endpoint path="C:\MuleDemo\left" responseTimeout="10000"
 doc:name="left" />
 </when>
 <when expression="#[message.outboundProperties['direction']=='right']">
 <file:outbound-endpoint path="C:\MuleDemo\right" responseTimeout="10000"
 doc:name="right" />
 </when>
 <otherwise>
 <file:outbound-endpoint path="C:\MuleDemo\output" responseTimeout="10000"
 doc:name="output" />
 </otherwise>
 </choice>
</flow>
```

Der Transformer liest aus der MBean die Property „direction“ und setzt sie als Outbound-Property an die Mule-Message. Der Logger und der Choice-Router können anschließend per Mule Expression Language auf die Property in der Message zugreifen und den Wert ausgeben bzw. ihre Routing-Entscheidung davon abhängig machen. Der Vollständigkeit halber hier noch der Java-Code des Transformers:

```Java
public class DirectionSetter extends AbstractMessageTransformer {
 private ControlMBean controller;

 @Override
 public Object transformMessage(MuleMessage message, String outputEncoding)
 throws TransformerException {
 message.setOutboundProperty("direction", controller.getDirection());
 return message;
 }

 public ControlMBean getController() {
 return controller;
 }

 public void setController(ControlMBean controller) {
 this.controller = controller;
 }
}
```

Was passiert nun, wenn wir die Applikation laufen lassen? Da die „direction“ in der MBean mit „rechts“ vorbelegt ist, werden alle Dateien aus dem Eingangsverzeichnis nach „rechts“ kopiert. Setzt man das Attribut per JMX auf „links“, geht es ab sofort nach „links“. Andere Werte sorgen dafür, dass die Dateien – über den otherwise-Weg des Choice-Routers – im Verzeichnis „output“ landen.<h1>Zusammenfassung</h1>Mule bietet – wie viele Web- oder EE-Server – auch JMX-Unterstützung. Investiert man nicht in die Enterprise-Version mit ihrer Management Console, so muss man auf einen anderen JMX-Client wie jconsole zurückgreifen. Der macht sich zwar nicht so hübsch in einer Vertriebs-Demo, da er doch recht technisch daherkommt, die notwendigen Funktionen sind trotzdem mit wenigen Klicks erreichbar.JMX bietet nicht nur die Möglichkeit, einen Mule-Server zur Laufzeit ohne ein Blick in das Log zu überwachen, sondern auch die Möglichkeit zur Steuerung. Die Überwachung wäre zwar auch über entsprechende Log-Ausgaben möglich, dadurch würde aber das Log entsprechend länger und man müsste sich die Events dort erst zusammensuchen und Daten berechnen/aggregieren.<h1>Weitere Teile dieser Artikelserie</h1><ol><li><a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">Was ist ein ESB und wofür kann man ihn nutzen?</a> </li><li><a href="http://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-komponenten/">Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-transform/">Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren</a> </li><li><a href="http://blog.codecentric.de/2013/06/tutorial-enterprise-service-bus-mit-mule-esb-integration-von-cics-programmen/">Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-esb-transport-connector-endpoint-grundlagen/">Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-enterprise-service-bus-mule-esb-performance-threads/">Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mule-esb-jmx-kontrolle-steuerung/">Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX</a> </li><li><a href="http://blog.codecentric.de/2013/09/veroffentlichen-der-versionsnummer-von-mule-applikationen/">Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mit-mule-esb-exceptions-email/">Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email</a> </li></ol>

Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX

Es wäre schön, wenn immer alles funktioniert. Aber wie wir alle wissen: Jeder mögliche Fehler wird irgendwann auftreten. Früher musste man dafür seinen Code mit vielen if-Abfragen verunstalten, heute nutzt man Exceptions, die man dann in catch-Blöcken abfangen kann. Das Konzept gibt es nicht nur in Programmiersprachen, sondern auch in Mule (und anderen ESBs). Um ein paar Fehlerquellen zu haben, gibt es in dem Beispiel auch noch einige Endpoints und Transformer, die bisher in der Serie noch keinen Platz gefunden haben. Was soll unser Beispiel machen? Es geht um einen automatischen Email-Eingang, eine low-tech-Variante einer Queue, die einfach über Firmengrenzen hinweg aufgesetzt werden kann. Es werden Mails verarbeitet, die im Anhang eine XML-Datei enthalten. Die Datei wird im Mule-Flow an einen Rest-Service übergeben. Falls der XML-Anhang fehlt oder ein anderer Fehler auftritt (z.B. könnte die XML-Struktur falsch sein), soll eine Fehlermail an eine definierte Adresse verschickt werden. Der Flow sieht im grafischen Editor folgendermaßen aus:<div><a href="https://media.graphassets.com/QSrsCvGwRrySFaukQUga"><img alt="Flow mit Exception-Handling" src="https://media.graphassets.com/QSrsCvGwRrySFaukQUga" width="891" height="262" /></a> Flow mit Exception-Handling</div>Er beginnt mit einem POP3-Endpoint, den man ähnlich wie ein Email-Programm konfiguriert: Host, Port, User, Passwort, was halt einen POP3-Account so ausmacht. Wer möchte, kann natürlich auch IMAP statt POP3 verwenden. Der Mail-Inhalt steht anschließend in der Payload der Message, aber der interessiert und nicht: Wir wollen ja schließlich an die Attachments ran, insbesondere das eine XML-Attachment. Das geht am einfachsten mit einem Transformer in Java:

```Java
public class AttachmentTransformer extends AbstractMessageTransformer {
    @Override
    public Object transformMessage(MuleMessage message, String outputEncoding) 
 throws TransformerException {
        for (String name : message.getInboundAttachmentNames()) {
            if (name.endsWith(".xml")) {
                DataHandler attm = message.getInboundAttachment(name);
                try {
                    return attm.getInputStream();
                } catch (IOException e) {
                    throw new TransformerException(MessageFactory.
 createStaticMessage("I/O problem"), e);
                }
            }
        }
        throw new TransformerException(MessageFactory.
 createStaticMessage("No XML attachment found"));
    }
}
```

Wie schon in vorigen Beispielen wird von AbstractMessageTransformer abgeleitet und die Methode transformMessage() überladen. In der Methode wird das erste Attachment genommen, das einen Namen mit „.xml“ am Ende besitzt, es wird dann in Form eines InputStreams als neue Payload weitergegeben. (Mule Streaming macht’s möglich.) Falls kein passendes Attachment gefunden wird, löst die Methode eine Exception aus. Dem Leser als Übung überlassen bleibt die Aufgabe, auch bei mehr als einem XML-Attachment eine Exception auszulösen. Attachments kommen übrigens nur bei wenigen Transports vor, neben Mail auch in JMS.Im Flow haben wir anschließend den XML-Stream in der Message-Payload stehen, der mit einem xml-to-object-transformer in ein Java-Objekt umgewandelt wird. Mule setzt dafür XStream ein. Über einen Alias muss man XStream noch mitteilen, dass die Root-Entity <person> auf die Java-Klasse de.codecentric.basics.Person abgebildet werden soll. (Wer möchte, kann über den Transformer jaxb-xml-to-object-transformer auch Jaxb statt Xstream verwenden.)Jetzt könnte man natürlich wieder mit Java weitermachen, schließlich haben wir als Payload kein XML oder einen String, sondern ein echtes Person-Objekt. Müssen wir hier aber nicht, als Vorbereitung für den Http-Endpoint, der unseren REST-Call macht, benötigen wir noch die ID der Person. Die holen wir uns per Mule Expression Language (MEL) aus der Nachricht und setzen sie in eine Message-Property. Da der REST-Service altmodisches nutzt, wird das Objekt im nächsten Schritt wieder in XML umgebaut. Es folgt der Http-Endpoint, der das XML-Dokument per Put-Request beim REST-Service abliefert. Der Pfad enthält dabei – im üblichen REST-Stil – die ID der anzulegenden Person.Für den Gut-Fall wären wir damit fertig. Für den Fehlerfall ergänzen wir noch die Exception-Strategie: Sie enthält hier nur einen Endpoint, der die Mail per smtp verschickt. Auch hier sollten die Parameter niemanden überraschen, der schon einmal ein Mail-Programm konfiguriert hat.Im XML steht die Exception-Strategie einfach am Ende des Flows, in der grafischen Darstellung ist sie durch eine Linie vom Rest des Flows getrennt und kann für eine bessere Übersichtlichkeit auch eingeklappt werden (Pfeil links an der Trennlinie).Hier das vollständige XML:

```XML
<flow name="XML-Mail" doc:name="XML-Mail">
 <pop3s:inbound-endpoint host="pop3.web.de"
 port="995" user="vertrieb.klammer-ag" password="sach-ich-nicht"
 responseTimeout="10000" doc:name="Mail-Poller" />
 <custom-transformer class="de.codecentric.basics.AttachmentTransformer"
 doc:name="AttachmentTransformer" />
 <mulexml:xml-to-object-transformer doc:name="XML to Person"
 returnClass="de.codecentric.basics.Person">
 <mulexml:alias name="person" class="de.codecentric.basics.Person"/>
 </mulexml:xml-to-object-transformer>
 <set-property propertyName="id" 
 value="#[message.payload.getId()]" doc:name="Set ID Property"/>
 <mulexml:object-to-xml-transformer doc:name="Person to XML">
 <mulexml:alias name="person" class="de.codecentric.basics.Person"/>
 </mulexml:object-to-xml-transformer>
 <http:outbound-endpoint exchange-pattern="request-response"
 host="localhost" port="8181" 
 path="rest/#[message.outboundProperties['id']]"
 method="PUT" contentType="application/xml" 
 doc:name="Put Person" />
 <catch-exception-strategy doc:name="Catch Exception">
 <smtp:outbound-endpoint host="mail.gmx.net" user="12345678" 
 password="very-secret" to="failed@codecentric.de"
 from="muli@gmx.de" subject="Failed Mail"
 responseTimeout="10000" doc:name="Error Mail" />
 </catch-exception-strategy>
</flow>
```

<h1>Varianten</h1>Die dargestellte Version ist natürlich nicht die einzig mögliche Variante, man kann es auch anders lösen. Es ist zum Beispiel nicht sehr schön, erst das XML in ein Objekt zu wandeln, nur um nachher wieder XML daraus zu erzeugen. Das wäre natürlich nicht aufgefallen, wenn ich den REST-Service mit dem modernerem Json statt XML bestückt hätte.Das Problem bestand darin, dass ich die ID irgendwie aus dem XML in eine Message-Property transportieren musste. Dafür fallen mir spontan noch zwei andere Möglichkeiten ein:<ol><li>Im set-property hätte man in der Mule-Expression-Language per xpath direkt ins XML greifen können.</li><li>Man hätte es auch direkt in Java lösen können, dann hätte man aber auf Java heraus die Umwandlung von XML in ein Objekt vornehmen müssen. Wozu hat man dann noch einen ESB?</li></ol>Die erste ist vermutlich für dieses synthetische Beispiel die einfachste/beste Variante. Wenn man für weitere Tests/Transformationen sowieso in die Java-Welt muss oder wenn ein anderes Zielformat (z.B. anders strukturiertes XML oder Json) gefordert ist, dann darf es auch bei der ursprünglichen Variante bleiben.Hätte man auf den Java-Transformer auch verzichten können, so dass wir bei reiner „klicki-bunti-Programmierung“ geblieben wären? Ein Attachment lässt sich auch per Mule Expression Language extrahieren, mann muss dann aber wissen, welches. Eine Logik wie „nimm das erste, dessen Name auf .xml endet“ belässt man dann doch besser in einer Programmiersprache wie Java.Der Flow ist übrigens „one-way“, etwas anderes unterstützt der POP3-Endpoint auch nicht. Das Ergebnis des Http-Endpoints für den REST-Aufruf wird also ignoriert. Die ganze Sache wird also nur dann sicher, wenn der ursprüngliche Absender irgendwann Feedback bekommt und bei einem Timeout seine Mail nochmals abschickt. Der REST-Server muss natürlich auch erkennen, dass er unter Umständen schon ein Objekt mit der ID angelegt hat und darf den zweiten Aufruf nur noch quittieren, ohne ein zweites Objekt anzulegen.<h1>REST-Server</h1>Zum Testen war auch noch ein REST-Server notwendig. Den hätte ich natürlich mit irgendeinem REST-Framework aufbauen können, aber wenn man einen Mule auf dem Rechner hat, dann sieht die Welt wie ein ESB aus. Also den REST-Server auch schnell in Mule zusammengeklickt:<div><a href="https://media.graphassets.com/nzsTBrxURQO3UJLApKTk"><img loading="lazy" alt="Einfacher Rest-Flow" src="https://media.graphassets.com/nzsTBrxURQO3UJLApKTk" width="230" height="241" /></a> Einfacher Rest-Flow</div>Ein http-Endpoint, dahinter eine REST-Component, fertig ist die REST-Konfiguration. Als XML:

```XML
<flow name="REST-Server" doc:name="REST-Server">
 <http:inbound-endpoint exchange-pattern="request-response"
 connector-ref="HTTP"
 host="localhost" port="8181" doc:name="Rest@8181">
 </http:inbound-endpoint>
 <jersey:resources doc:name="REST">
 <component class="de.codecentric.basics.RestService" />
 </jersey:resources>
</flow>
```

Aha, doch nicht fertig, da wird eine Java-Klasse referenziert, die noch implementiert werden will:@Path(„/rest/{id}“)

```"Java
public class RestService {
 @PUT
 @Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
 @Produces(MediaType.TEXT_PLAIN)
 public String consume(@PathParam(value = "id") String id, Person person) {
 System.out.println("id: " + id);
 System.out.println("message: " + person);
 return "OK";
 }
}
```

Wie man schon am XML sieht, setzt Mule intern auf Jersey. Warum auch das Rad neu erfinden, wenn es schon ein passendes REST-Framework gibt. In der Klasse selbst sieht man dann auch die üblichen Annotationen von Jersey. In der Bean Person muss dann gemäß JAXB annotiert werden. Da in der @Consumes-Annotation zwei Media-Types angegeben sind, hätte der Service übrigens auch funktioniert, wenn der Client Json geschickt hätte. Eine „echte“ Implementierung, die eine Person in der Datenbank anlegt, fehlt hier aus Platzgründen. Aber das wäre doch mal was für einen Artikel mit dem JDBC- oder JPA-Transport.<h1>Zusammenfassung</h1>Die heutige Folge war mal etwas kürzer, obwohl mehrere Dinge vorkamen: XML-Endpoints (In- und Outbound), Exception-Handling und ein REST-Server. Werde ich jetzt schreibfaul? Vermutlich etwas, da ich bei den Lesern schon etwas Mule-Kenntnisse voraussetze. Auf der anderen Seite: Wenn man etwas mit Mule arbeitet, geht der Einsatz des nächsten Transports oder Transformers meistens sehr einfach. Und Fehler müssen nicht immer (nur) im Log-File landen, per Catch Exception Strategy lässt sich auch im Flow einfach darauf reagieren.<h1>Weitere Teile dieser Artikelserie</h1><ol><li><a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">Was ist ein ESB und wofür kann man ihn nutzen?</a> </li><li><a href="http://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-komponenten/">Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-transform/">Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren</a> </li><li><a href="http://blog.codecentric.de/2013/06/tutorial-enterprise-service-bus-mit-mule-esb-integration-von-cics-programmen/">Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-esb-transport-connector-endpoint-grundlagen/">Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-enterprise-service-bus-mule-esb-performance-threads/">Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mule-esb-jmx-kontrolle-steuerung/">Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX</a> </li><li><a href="http://blog.codecentric.de/2013/09/veroffentlichen-der-versionsnummer-von-mule-applikationen/">Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mit-mule-esb-exceptions-email/">Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email</a> </li></ol>

Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email

MuleSoft hat mit Version 3.7 den DataMapper in Rente geschickt und durch DataWeave ersetzt. Was verbirgt sich dahinter? Mein erster Eindruck: semantisch eine Mischung aus SQL und Xslt, syntaktisch JavaScript. Ist das gelungen? Das soll jeder selbst beurteilen. Mule bietet auch schon vor Version 3.7 verschiedene Bausteine zur Transformation von Nachrichten an, teilweise für Metadaten (Properties), teilweise für den Inhalt (Payload). Hier einige Beispiele:<ul><li>Properties oder Inhalt lassen sich durch die Mule Expression Language (MEL) berechnen.</li><li>XML lässt sich mit Xslt transformieren.</li><li>JavaScript und Groovy stehen für Fans von Scriptsprachen zur Verfügung (serienmäßig, weitere JSR-223-konforme Scriptsprachen müssen nur in den Classpath aufgenommen werden).</li><li>Java-Components oder Java-Transformer bieten sich an, wenn es mal komplexer wird oder man existierenden Transformationscode wiederverwenden möchte.</li><li>Maus-Schubser nutzen den grafisch konfigurierbaren DataMapper um zwischen XML, Json, CSV und Pojos zu transformieren.</li></ul>Gerade den letzten Baustein, mit seiner bunten Drag-&-Drop-Konfiguration der Star jeder Präsentation, wirft MuleSoft nun raus und ersetzt ihn durch DataWeave. Warum? Darüber lässt sich spekulieren. Einer der Gründe mag sein, dass der DataMapper auf Clover ETL aufsetzt und MuleSoft keine Lizenzgebühren an eine andere Firma zahlen möchte. Für Anwender ist das egal.Was mich als Anwender am DataMapper stört, ist die Tatsache, wie man ihn konfiguriert: rein grafisch. Nichts gegen grafische Konfiguration (ich male meine Flows gerne in AnypointStudio), das Ergebnis sollte jedoch eine Textdatei sein, die man notfalls auch ohne Tool lesen und bearbeiten kann. Der DataMapper arbeitet jedoch mit einem XML-Format, das man getrost auch als Binärformat hätte schreiben können: komplett unleserlich.Warum ist mir ein menschenlesbares Textformat wichtig? In ihm kann man problemlos Änderungen nachvollziehen, wenn man sich Diffs in der Versionsverwaltung (svn, git, …) anschaut. Es skaliert meistens auch besser, wenn’s mal komplizierter wird. Dagegen verliert man in dem Liniengewusel des DataMapper schnell die Übersicht.<h2>Beispiel</h2>Genug philosophiert, starten wir mit einem DataWeave-Beispiel. Im Mule-Flow wird DataWeave folgendermaßen referenziert:

```
<dw:transform-message doc:name="Transform Message">
 <dw:set-payload resource="simpleObject2Json.dwl"/>
</dw:transform-message>

```

Und in der DWL-Datei (die man auch inline in den Flow schreiben könnte) steht:

```
%dw 1.0
%input payload application/java
%output application/json
---
{
 "name": payload.name,
 "gender": payload.gender
}

```

Was passiert darin? Aus einem POJO werden zwei Attribute (name, gender) in ein Json-Objekt transformiert. Die dazu notwendige Meta-Information steht direkt unter der Versionsnummer von DataWeave.Unterhalb von der Zeile „—“ folgt die Transformationslogik. Ihre Syntax lehnt sich an Json an (auch wenn ein anderes Format wie XML ausgegeben wird). Sie definiert die Struktur der Ausgabe. Man muss sich dabei natürlich an die Restriktionen des Ausgabeformats halten, zum Beispiel erlaubt Json keine doppelten Keys und in XML muss es genau einen Wurzelknoten geben.Ob die DWL inline im XML oder extern in einer eigenen Datei (unter src/main/resources) steht, ist Geschmacksache. Ich persönlich finde es getrennt übersichtlicher. Innerhalb des AnypointStudios ist der Unterschied jedoch nur ein gesetzter Haken und die Auswahl eines Dateinamens.Trotz des Textformats gibt es im AnypointStudio natürlich Unterstützung, so sieht der Design-Dialog aus:<a href="https://media.graphassets.com/Cl3AClTpRSmaeDDvCBLC"><img width="754" height="332" src="https://media.graphassets.com/Cl3AClTpRSmaeDDvCBLC" alt="Einfaches Beispiel im DataWeave-Editor vom AnypointStudio" /></a> Links stehen die Metadaten der ankommenden Mule-Message, rechts die der transformierten Message. In der Mitte wird die DWL-Datei editiert. Interessant wird es, wenn man unten auf „payload“ und „Preview“ umschaltet. Links stehen eingehende Beispieldaten (die man jederzeit editieren darf), rechts zeigt Anypoint das Ergebnis der Transformation direkt an. Bei XML-, Json- und CSV-Daten sieht man die Daten in der jeweiligen Syntax, bei Java-Klassen (wie im Beispiel links für die Eingabedaten zu sehen) wird der Inhalt als Json dargestellt:<a href="https://media.graphassets.com/BU0beFAqRaeYnpmaLGQP"><img loading="lazy" width="947" height="332" src="https://media.graphassets.com/BU0beFAqRaeYnpmaLGQP" alt="Beispieldaten, Transformationsvorschrift und zugehörige Ausgabedaten." /></a> Was man selbst erleben muss: Die Preview rechts wird aktualisiert, sobald man die Transformation in der Mitte editiert. Und zwar direkt, ohne Speichern oder Wartezeiten. Im Falle von Syntaxfehlern in der DWL werden diese unten rechts ebenso sofort dargestellt. Auch wenn es in einer Präsentation nicht so bunt daherkommt wie Drag-&-Drop von Attributen: Für die Praxis finde ich diese Lösung sehr brauchbar.<h2>Anypoint kennt die Message</h2>Kennt Mule das Format der Ausgabedaten (Stichwort DataSense, siehe <a href="https://blog.codecentric.de/2014/04/einblick-mule-esb-3-5-0-m4-early-access-datasense-und-datamapper/">Blogpost</a> von meinem Kollegen Tobias Schaber), so lässt sich ein Gerüst der Transformation auf Knopfdruck erzeugen. Das Gleiche gilt für die Eingabedaten: In dem im Bild zu sehenden Beispiel habe ich nur „Peter“ und „male“ statt der beiden „???“ eingetragen.Standardmäßig liest DataWeave die Payload als Eingabe und schreibt die Ausgabe auch wieder in die Payload. Die Eingabedaten müssen nicht komplett als String oder Byte-Array vorliegen, es darf auch ein Stream sein. Die Ausgabe erfolgt – außer bei Java-Objekten – ebenfalls als Stream. Falls das nächste Flow-Element kein Streaming unterstützt (was bei Mule selten ist), so muss man den Stream zuerst „materialisieren“. Am einfachsten geschieht dies mit dem <object-to-string-transformer/>.Eine Falle lauert in der Eingabe: Hier wählt DataWeave mittels Mime-Type den korrekten Parser aus (Json, Xml, CSV). Auch wenn es so aussieht, die Zeile

```
%input payload appplication/xml
```

in der Transformationsdatei reicht dafür nicht aus. Aber es existieren drei andere Wege:1. Der Endpoint ermittelt den Mime-Type automatisch aus den eingehenden Daten (z.B. bei http) 2. Er wird im Endpoint am Anfang des Flows manuell konfiguriert (z.B. in einem VM-Endpoint: mimeType=“application/json“) 3. Er wird im DataWeave-Transformer manuell konfiguriert (z.B.: mimeType=“application/json“)Dummerweise fällt dieser Fehler nicht in der Preview auf, stattdessen meldet sich der Parser mit einer nicht offensichtlichen Fehlermeldung.<h2>Mehr als ein Ziel</h2>Die beiden Bilder oben zeigen noch zwei andere Features von DataWeave, allerdings nicht auf den ersten Blick: Über dem Editor lässt sich einstellen, wo das Ergebnis der Transformation gespeichert werden soll:<a href="https://media.graphassets.com/ZcnjMvkTVaUShoVirX8P"><img loading="lazy" width="446" height="291" src="https://media.graphassets.com/ZcnjMvkTVaUShoVirX8P" alt="Es sind auch mehrere Ziele für die Transformation möglich." /></a> Neben „Payload“ existieren dort die diversen Variablen-Scopes als Ziele, per Drop-Down auszuwählen. Unten rechts im Bild sieht man ein kleines Plus-Zeichen im Kreis: Ein Klick darauf öffnet einen weiteren Tab-Reiter, dessen Ausgabe an ein weiteres Ziel geleitet werden kann. Ein DataWeave-Transformer kann somit nicht nur eine neue Payload setzen, sondern zusätzlich eine oder mehrere Variablen bestücken.Das geht auch anders, mit dem Message-Enricher-Pattern. Das hat jedoch gegenüber der Integration in DataWeave einige Nachteile:<ol><li>Es bläht den Flow auf, für jedes Ziel benötigt man einen Message-Enricher mit embedded DataWeave-Transformer.</li><li>Streaming funktioniert nicht: Vor dem ersten Message-Enricher muss der Stream komplett in den Speicher gelesen werden, damit die Daten in den weiteren Enrichern noch zur Verfügung stehen. Der Speicherverbrauch wird dadurch erhöht.</li><li>Es erfordert, dass die ankommende Payload mehrfach durch den Parser von DataWeave läuft.</li></ol><h2>Pojos und Schleifen</h2>Im nächsten Bild habe ich das Beispiel von oben um zwei weitere Features ergänzt:<ul><li>Pojos als Ziel</li><li>Schleifen</li></ul>Erzeugt man aus XML oder Json Java-Objekte, muss man DataWeave mitteilen, welche Klassen verwendet werden sollen. Dies geschieht mit „as :object“ hinter der schließenden Klammer eines Blocks in der DWL. Das darauf folgende class-Attribut hat als Wert den voll qualifizierten Klassennamen (mit Package).Ansonsten werden an die Klasse keine besonderen Anforderungen gestellt. Sie muss einen public-Konstruktor ohne Argumente enthalten und auch ansonsten ein Pojo sein, das heißt es sind Public Getter und Setter für die Member-Variablen notwendig. Public Member-Variablen funktionieren nicht.<a href="https://media.graphassets.com/hr8tMf6eQkGjC6mAwBBK"><img loading="lazy" width="955" height="392" src="https://media.graphassets.com/hr8tMf6eQkGjC6mAwBBK" alt="Transformation in Pojos, mit einer Liste als Attribut." /></a> Nur ein Pojo zu transformieren ist eher banal, daher enthält die Klasse „Parent“ noch eine java.util.List von „Child(ren)“. Den Typ der Listenelemente könnte man hier sogar weglassen, Mule würde ihn in diesem einfachen Beispiel auch alleine erkennen. Die Angabe des Typen kann aber beim Einsatz von Vererbungshierarchien oder Interfaces notwendig sein.Wie geschieht das Mapping der Liste? Es wird keine Schleife ausprogrammiert, stattdessen erstellt man ein Mapping des Json-Arrays „children“ auf die Member-Variable „children“ im Pojo. Dahinter folgt dann, wie ein einzelnes Element transformiert werden soll. Der einzige Unterschied zum Mapping des Wurzelelements besteht darin, dass man nicht mehr mit „payload“ auf die Wurzel zugreift, sondern mit „$“ auf das aktuelle Element.Das funktioniert natürlich nicht nur über eine 1:n-Beziehung, sondern auch mit tiefer verschachtelten Strukturen.<h2>Zusammenfassung und Ausblick</h2>Was haben wir bisher von DataWeave gesehen? Wir können Formate (XML etc.) ineinander umwandeln, das Ergebnis in der Payload oder Variablen speichern sowie die Attributnamen beim Mapping ändern.Das CSV-Format haben wir bisher ignoriert. Auf der einen Seite ist es einfacher als die anderen Formate, da es flach ist. Auf der anderen Seite sind Feinheiten wie Trenner und Spaltennamen einzustellen. No Big Deal.Ein Test unter realen Bedingungen steht noch aus: Schließlich stimmen in der Realität die Strukturen von Quelle und Ziel nicht notwendigerweise überein: Statt der Liste in der Eingabe existiert in der Ausgabe beispielsweise nur noch eine Summe. Oder eine Liste muss in zwei Listen umgewandelt werden. Oder in der Eingabe unterscheiden sich Daten nur in einem Attribut, während in der Ausgabe verschiedene Klassen stehen. Auch XML-Namespaces, dynamische Attribute oder die Zusammenarbeit mit anderen Mule-Komponenten fehlt noch. Es bleiben also noch spannende Themen für weitere Posts…<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 2: Bedingungen und reguläre Ausdrücke <a href="https://blog.codecentric.de/2015/11/transformieren-von-nachrichten-mit-mule-dataweave-bedingungen/">https://blog.codecentric.de/2015/11/transformieren-von-nachrichten-mit-mule-dataweave-bedingungen/</a> </li><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 3: Schleifen und Gruppierungen <a href="https://blog.codecentric.de/2016/01/mule-dataweave-teil-3-schleifen-und-gruppierungen/">https://blog.codecentric.de/2016/01/mule-dataweave-teil-3-schleifen-und-gruppierungen/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li><li>Enterprise Integration Patterns <a href="http://www.enterpriseintegrationpatterns.com/">http://www.enterpriseintegrationpatterns.com/</a> </li><li>Tobias Schaber, Einblick in Mule ESB 3.5.0-M4 Early Access – DataSense und DataMapper<a href="https://blog.codecentric.de/2014/04/einblick-mule-esb-3-5-0-m4-early-access-datasense-und-datamapper/">https://blog.codecentric.de/2014/04/einblick-mule-esb-3-5-0-m4-early-access-datasense-und-datamapper/</a> </li></ul>

Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung

Nach der <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">Einführung</a> sollten die Grundlagen von DataWeave schon halbwegs bekannt sein. Heute geht es darum, wie man dynamisch steuern kann, was in den Zieldaten steht – quasi um das „if“ von DataWeave. Die Steuerungsdaten für die Bedingungen können dabei aus dem Inhalt der Nachricht oder Metadaten stammen. Als Beispiel nutze ich für diesen Teil eine einfache JSON-Struktur mit einer Liste von Personen:

```
{
 "persons": [
 {
 "gender": "male",
 "name": "Peter"
 },
 { 
 "gender": "female",
 "name": "Paula"
 }
 ]
}

```

Neben dem Namen hat jede Person noch ein gender-Attribut. Im ersten Schritt wandeln wir die Struktur 1:1 in XML um:

```
%dw 1.0
%output application/xml encoding="utf-8"
--- 
personen: {
 (payload.persons map {
 person: {
 geschlecht: $.gender,
 vorname: $.name
 }
 }
 )
}

```

Als XML erhalten wir dann:

```
<?xml version='1.0' encoding='UTF-8'?>
<personen>
 <person>
 <geschlecht>male</geschlecht>
 <vorname>Peter</vorname>
 </person>
</personen>

```

Bisher ganz einfach. Was eigentlich schon im ersten Teil dieser Serie stehen sollte, ist das Attribut für das Encoding (encoding=“utf-8″). Ohne nutzt Mule das Standard-Encoding des Betriebssystems (z. B. „windows-1252“), was erstens nicht unbedingt gewünscht ist und zweitens zu unterschiedlichen Encodings in den Stages vom Entwicklerrechner bis in die Produktion führen kann.Im nächsten Schritt filtern wir das Ergebnis, so dass in der Ausgabe nur die Männer übrig bleiben. Dazu wird das DataWeave-Skript um einen Filter ergänzt:

```
%dw 1.0
%output application/xml encoding="utf-8"
--- 
personen: {
 (payload.persons filter ($.gender == "male") map {
 person: {
 geschlecht: $.gender,
 vorname: $.name
 }
 }
 )
}

```

Jetzt wird Paula unterschlagen und nur noch Peter bleibt im Ergebnis stehen:

```
<?xml version='1.0' encoding='UTF-8'?>
<personen>
 <person>
 <geschlecht>male</geschlecht>
 <vorname>Peter</vorname>
 </person>
</personen>

```

Ein Filter reicht nicht mehr aus, wenn alle Elemente im Ergebnis auftauchen sollen, aber – abhängig von einer Bedingung – in unterschiedlicher Form. Nehmen wir also an, dass statt des XML-Tags <person> die Spezifikation jetzt <mann> und <frau> fordert. Wären sie in zwei getrennten Listen, ginge das noch mit dem Filter, gemischt in einer gemeinsamen Liste jedoch nicht mehr. Mit Bedingungen lässt sich auch dies lösen:

```
%dw 1.0
%output application/xml encoding="utf-8"
--- 
personen: {
 (payload.persons map {
 (mann: {
 vorname: $.name
 }) when ($.gender == "male"),
 (frau: {
 vorname: $.name
 }) when ($.gender == "female")
 }
 )
}
```

Möchte man – wie hier gezeigt – komplette Attribut-Wert-Paare ausschließen, muss man um das ganze Paar noch runde Klammern setzen. Tauscht man dagegen nur Werte aus, kann man darauf verzichten. In dem letzten Fall lässt sich mit dem Schlüsselwort „otherwise“ auch das Äquivalent eines else-Zweiges implementieren.Für Freunde der Verneinung steht statt „when“ auch noch „unless“ zur Verfügung. Logische Verknüpfungen erfolgen nicht mit den Java-/JavaScript-typischen Zeichen && bzw. ||, sondern über die Schlüsselwörter „and“ bzw. „or“. Für Verneinungen gibt es noch „not“.Wer mit Texten arbeitet, erwartet sicher auch reguläre Ausdrücke. Diese kommen in DataWeave in drei Varianten vor. Die einfachste ist in Bedingungen. So passt die Bedingung

```
($.gender matches /.*male/)
```

sowohl auf „male“ als auch auf „female“ (und alle anderen Strings, die auf „male“ enden).Das Schlüsselwort „replace“ erlaubt das Suchen und Ersetzen mit regulären Ausdrücken. Der Ausdruck

```CodeRay highlight
replace /(\d+)/ with "ID"
```

tauscht alle Zahlen durch die Zeichenkette „ID“ aus.Wendet man den Operator „match“ mit einem regulären Ausdruck auf einen String an, steht im Ergebnis ein Array. Unter dem Index 0 findet sich der gesamte Match wieder, ab Index 1 die Teilausdrücke des gesamten Ausdrucks. Dazu ein Beispiel:

```
%dw 1.0
%output application/xml encoding="utf-8"
--- 
personen: {
 (payload.persons map {
 person: {
 vorname: $.name,
 vorwahl: ($.phone match /(\d+)\/(\d+)/)[1],
 nummer: ($.phone match /(\d+)\/(\d+)/)[2]
 }
 }
 )
}
```

Was passiert hier? Aus dem Attribut „phone“ (bitte in der Beispieleingabe am Anfang des Artikels dazudenken) fischt sich der reguläre Ausdruck die Teile vor und hinter einem Schrägstrich getrennt heraus. Mit dem angehängten [0] und [1] landen sie dann in den Tags <vorwahl> und <nummer> im XML.So, das soll für heute reichen. Im nächsten Teil werde ich mich dann mit Gruppierungsfunktionen beschäftigen.<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 3: Schleifen und Gruppierungen <a href="https://blog.codecentric.de/2016/01/mule-dataweave-teil-3-schleifen-und-gruppierungen/">https://blog.codecentric.de/2016/01/mule-dataweave-teil-3-schleifen-und-gruppierungen/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Transformieren von Nachrichten mit Mule DataWeave – Teil 2: Bedingungen und reguläre Ausdrücke

In den ersten beiden Teilen dieser Serie habe ich bereits Collections – und damit implizit – Schleifen verwendet. In diesem Beitrag werde ich das Thema vertiefen und dabei genauer auf das Mapping mit Lambdas eingehen. Zum Abschluss werde ich Gruppierungsfunktionen erläutern.Bevor ich tiefer in das Thema einsteige, noch eine Ergänzung zum ersten Teil. Dort hatte ich <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">geschrieben</a> , dass es bei DataWeave (im Gegensatz zum alten DataMapper) kein grafisches Mapping mit Drag and Drop gibt. Stimmt nicht (mehr): Mitte Dezember kam mit einem Update des AnypointStudio das grafische Mapping für DataWeave. Der Editor hat dazu eine weitere Spalte erhalten, in der die Zuordnung grafisch durch Linien dargestellt wird:<a href="https://media.graphassets.com/OJ3msuW1S72D5C0hGo6r"><img width="912" height="485" src="https://media.graphassets.com/OJ3msuW1S72D5C0hGo6r" alt="DataWeave-Editor mit grafischem Mapping" /></a> Was mir an der Lösung gefällt: Die textuelle DSL hat sich nicht geändert, sie bleibt weiterhin kurz und prägnant. Die grafische Darstellung mit Drag and Drop ist nur eine Ergänzung. Wem es nicht gefällt, der kann weiter mit der Tastatur arbeiten und sich die Mappings durch die Linien anzeigen lassen. Wem das immer noch zu viel ist: Die Spalte mit den Linien lässt sich auch ausblenden. Umschalten kann man die Darstellung mit den Icons oben rechts (neben dem Button „Preview“).Dem Editor fehlt aktuell (Stand: Dezember 2015) noch die nötige Reife: Er kommt beim Umschalten zwischen Drag and Drop und textuellem Editieren schnell durcheinander. Es empfiehlt sich, ihn nach Drag-and-Drop-Operationen zu schließen, bevor man textuell Änderungen vornimmt.<h2>Flaches Remapping</h2>Nun zum angekündigten Thema. Starten wir mit einem einfachen Beispiel: Eine Datenbanktabelle soll als CSV-Datei exportiert werden. Der Datenbank-Connector von Mule produziert eine Liste von Zeilen. In jeder Zeile befindet sich eine Map von Spaltenname auf Spalteninhalt. Bei gängigen Datenbanken (MySQL, Oracle etc.) ist AnypointStudio in der Lage, die Metadaten aus der Datenbank zu lesen. Name und Typ der Spalten zeigt der Editor direkt an.Wie exportiert man nun eine Tabelle als CSV-Datei? Die Lösung ist trivial, wenn die Tabelle 1:1 exportiert werden soll und DataWeave nur die Formatumwandlung nach CSV durchführen muss:%dw 1.0 %output application/csv — payloadHier wird ausgenutzt, dass die Payload eine Liste enthält, die auch für CSV benötigt wird. Die Maps in der Liste legen dabei auch direkt die Spaltennamen für die CSV-Datei fest.Über das Schlüsselwort „map“ und einen Lambda-Ausdruck lassen sich die Spalten auswählen und bei Bedarf umbenennen: %dw 1.0 %output application/csv header=true, separator=‚;‘ — payload map ({     „gewicht“: $.gewicht_in_kg,     „groesse“: $.groesse_in_m * 100,     „bmi“: $.bmi   } ) Das Beispiel arbeitet mit der Kurzform, in der kein Name für die Schleifenvariable vergeben wird. Auf sie kann stattdessen mit $ zugegriffen werden. Da es sich um eine Map handelt, greift man auf einzelnen Elemente per Punktnation zu.In der nicht anonymen Variante sieht man klarer, was hinter den Kulissen passiert: %dw 1.0 %output application/csv — payload map ((a) -> {     „gewicht“: a.gewicht_in_kg,     „groesse“: a.groesse_in_m   } ) Hinter „map“ steht der Lambda-Ausdruck mit einem Parameter in runden Klammern: (a), gefolgt von einem Pfeil und dem gemappten Ausdruck.<h2>Strukturelle Änderungen</h2>Mit Lambdas lassen sich nicht nur Attribute umbenennen, sondern auch die Struktur eines Datensatzes ändern. Für das nächste Beispiel besteht die Eingabedatei aus einem JSON-Array von Objekten mit den Attributen gewicht und groesse, Beispiel:[ { „groesse“: 1.88, „gewicht“: 90 }, { „groesse“: 2.00, „gewicht“: 88 } ]Wie gehen wir vor, wenn wir stattdessen ein Objekt mit Arrays für Größe und Gewicht haben wollen? Wir schreiben einfach ein JSON-Objekt mit den beiden Attributen hin und iterieren darin jeweils über die Eingabedaten. Die Projektion (SQL lässt grüßen) erledigen wir jeweils mit einem Lambda:%dw 1.0 %output application/json — {     „massen„: payload map ((p) -> p.gewicht),     „laengen„: payload map ((p) -> p.groesse) } Bei diesem Beispiel fehlen auf der rechten Seite die geschweiften Klammern: Es soll schließlich kein Objekt erzeugt werden, in den Arrays massen und laengen stehen nur die Zahlen.Lasst uns mit den Zahlen etwas rechnen! Wie wäre es mit einer Summenbildung? Geht, einfach reduce verwenden: %dw 1.0 %output application/json — {     „massen„: payload map ((p) -> p.gewicht) reduce ((val, acc = 0) -> acc + val),     „laengen„: payload map ((p) -> p.groesse) reduce ((val, acc = 0) -> acc + val) } Der reduce-Operator arbeitet mit zwei Argumenten: Das erste enthält das aktuelle Array-Element, das zweite das Zwischenergebnis (Akkumulator). Es lässt sich explizit initialisieren (im Beispiel mit 0) oder enthält standardmäßig das erste Arrayelement.<h2>Group By</h2>Nachdem wir im letzten Beispiel ein Array von Objekten in zwei Arrays zerlegt haben, versuchen wir uns jetzt an der umgekehrten Richtung: Die Daten sollen nach dem Gewicht gruppiert werden. Aber nicht für jedes Gewicht eine Gruppe, sondern alle > 100 in die Kategorie „schwer“, der Rest in die Kategorie „leicht“.Für Gruppierung existiert – wie in SQL – der groupBy-Operator. Aber wie erhalten wir das Mapping in die beiden Kategorien „leicht“ und „schwer“? Bei wenigen Kategorien (die dazu vorab bekannt sind) kann man Filter benutzen (siehe <a href="https://blog.codecentric.de/2015/11/transformieren-von-nachrichten-mit-mule-dataweave-bedingungen/">Teil 2 der Serie</a> ). Im anderen Fall muss eine Funktion her, mit der sich die Kategorie bestimmen lässt. Ich habe hier mittels lookup einen Flow aufgerufen, der die Funktion umsetzt:%dw 1.0 %output application/json — {     „data“: payload groupBy lookup(„kategorie„, $.gewicht) }Der erste Parameter enthält den Namen des Flows, der zweite die Payload. Der Flow selbst ist im Beispiel recht simpel, abhängig vom Gewicht gibt er eine der beiden Kategorien zurück:<flow name=„kategorie“>   <choice>     <when expression=„#[payload > 100]“>       <set-payload value=„schwer“ />     </when>     <otherwise>       <set-payload value=„leicht“ />     </otherwise>   </choice> </flow>Der Flow könnte auch noch komplexere Transformationen enthalten, Services aufrufen oder Datenbanklookups durchführen. Eben alles, was Mule sonst noch bietet.<h2>Zusammenfassung</h2>Nachdem ich mit DataWeave einige Zeit herumexperimentiert habe, bin ich immer noch begeistert. Viele Dinge sind damit deutlich einfacher, als wenn man zuerst mit JAXB/Jackson alles nach Java umwandelt, dort das Mapping umwandelt und dann wieder nach XML/Json zurückkonvertiert. Messungen habe ich noch nicht durchgeführt, aber es ist vermutlich auch schneller. Vom Speicherbedarf ganz zu schweigen: Da DataWeave, wo immer es möglich ist, mit Streaming arbeitet, kann man in vielen Fällen auch Datenstrukturen bearbeiten, die größer als der verfügbare Hauptspeicher sind.Mal sehen, eventuell gibt es noch einen weiteren Teil mit Praxisberichten aus dem Projekteinsatz. Stay tuned.<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 2: Bedingungen und reguläre Ausdrücke <a href="https://blog.codecentric.de/2015/11/transformieren-von-nachrichten-mit-mule-dataweave-bedingungen/">https://blog.codecentric.de/2015/11/transformieren-von-nachrichten-mit-mule-dataweave-bedingungen/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric-Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Transformieren von Nachrichten mit Mule DataWeave – Teil 3: Schleifen und Gruppierungen

Traditionell testet man Mule-Anwendungen mit JUnit, also Java-Code. Seit einiger Zeit bietet Mule zusätzlich MUnit an, das auch Tests als Flows realisiert. Außerdem hat das Anypoint Studio einige Wizards spendiert bekommen, mit denen sich Testfälle einfach erstellen lassen.Mein Kollege Conrad Pöpke hat vor einiger Zeit schon über MUnit <a href="https://blog.codecentric.de/2015/01/testen-von-mule-esb-applikationen-teil-23-modultests-und-funktionales-testen/">geschrieben</a> , aber inzwischen hat sich die Welt weitergedreht und MUnit hat im Mule-Universum einen wesentlich höheren Stellenwert. Es befindet sich außerdem nicht mehr im Beta-Stadium. In diesem Blogpost zeige ich, wie man im Anypoint Studio ein einfaches Projekt aufsetzt und mit MUnit testet. Die weiteren Teile existieren bisher nur vage in meinem Kopf, ich werde mich in ihnen auf jeden Fall um die zentralen Probleme bei Tests kümmern:<ol><li>Wie bekomme ich die Eingangsdaten in meinen Testfall?</li><li>Wie mocke ich Teile, die ich nicht mittesten kann (oder will)?</li><li>Wie verifiziere ich die Ergebnisse?</li></ol><h2>Vorbereitung</h2>Los geht’s, Anypoint Studio starten (ich nutze aktuell 5.4.2), anschließend prüfen, ob wir aktuell sind und alle notwendigen Plugins installiert wurden: Über Help -> Check for Updates prüfen wir die Aktualität und spielen ggf. Updates ein. Je nach Studio hat man jetzt schon die volle MUnit-Unterstützung, aber auch das prüfen wir besser: Also Help -> Install New Software. Unter den Sites sollte http://studio.mulesoft.org/r4/munit schon vorhanden sein, falls nicht: bitte ergänzen. Wählt man die Site aus, darf man das MUnit-Plugin und einige Zusatzplugins installieren. Ich habe einfach mal alle ausgewählt, auch wenn wir in diesem Teil nur mit der Basis arbeiten:<img width="559" height="171" src="https://media.graphassets.com/EUJ2ngNySgGSQXMr8gYY" alt="MUnit-Plugins" />Eclipse-typisch folgt nach der Installation vermutlich ein Neustart…Mit File -> New Mule Project erstellen wir über den Wizard ein neues Projekt. Ich arbeite aktuell mit der Runtime 3.7.3 EE (im Studio darf man auch dann mit der Enterprise-Version spielen, wenn man kein zahlender Kunde ist). Damit wir später auch in einer CI-Umgebung (z.B. Jenkins) bauen können, sollte man auf jeden Fall ein Kreuz bei „Use Maven“ setzen. Das Projekt nenne ich einfach mal „munit-testprojekt“. Jetzt können wir noch eine Tasse Kaffee trinken, während Maven das halbe Internet herunterlädt, dann kann’s losgehen.Die Mule-Anwendung enthält nur einen einfachen Flow mit einem HTTP-Endpoint:<img loading="lazy" width="186" height="207" src="https://media.graphassets.com/fg0jqKnuS5eLFBSWRqab" alt="Hello-World-Flow" />Den HTTP-Listener habe ich auf den Port 9090 konfiguriert, der Pfad bleibt leer. Set Payload gibt eine freundliche Nachricht zurück:<img loading="lazy" width="323" height="234" src="https://media.graphassets.com/uuw6YEN2SRCFi6EqBfYL" alt="Set-Payload" />Der Korrektheit wegen ist der MIME Type auf text/plain gesetzt.Bevor wir mit der Testautomatisierung beginnen, können wir das Projekt manuell testen. Also über Run -> Run Configurations unter Mule Applications eine neue Konfiguration erstellen. In meinem Studio befinden sich im Workspace meist mehrere Mule-Projekte, für den Test wähle ich nur das munit-testprojekt aus. (Man könnte auch mit einem Rechtsklick auf das Projekt und Run as… starten, aber dort wird bei Maven-Projekten nur der Start mit Maven angeboten. Mit Maven starten die Projekte jedoch langsamer, ich gehe daher den oben beschriebenen Weg.)Nach wenigen Sekunden sollte in der Console View stehen:

```
****************************************************************************
* - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - -        *
****************************************************************************
* munit-testprojekt * default * DEPLOYED                                   *
****************************************************************************

```

Also schnell im Browser <a href="http://localhost:9090" target="_blank">http://localhost:9090</a> eintippen und über eine freundliche Begrüßung freuen:

```
Hello, world!
```

Stimmt der MIME Type? Das kann man in der Developer-Konsole seines Lieblingsbrowsers prüfen:

```
Content-Type:text/plain
```

Wer immer nur manuell testet, der kann sich jetzt zurücklehnen, mit dem Lesen aufhören und das Browser-Fenster schließen.Noch jemand da? Gut, dann wollen wir jetzt unsere Mule-Anwendung mit einem MUnit-Test erweitern.<h2>Maven</h2>Der erste Schritt zu MUnit-Tests geht über Maven: ein Rechtsklick auf das Projekt, Menüpunkt MUnit -> Configure MUnit Maven Support erweitert die Datei pom.xml des Projekts. Kann man auch manuell machen, geht aber so einfacher. Was hat sich in der Datei alles geändert? Schauen wir mal:<ol><li>In den Properties stehen die MUnit-Version (1.1.0) und die Version der Support-Bibliotheken (3.7.1).</li><li>Die Konfiguration des Mule-Maven-Plugins wird erweitert</li><li>Es kommt ein weiteres Plugin für die Ausführung der MUnit-Tests hinzu: com.mulesoft.munit.tools / munit-maven-plugin.</li><li>Die Test-Ressourcen werden um src/test/munit erweitert. (Jetzt darf jeder raten, in welches Verzeichnis die MUnit-Tests gehören.)</li><li>In den Dependencies stehen noch einige JARs mit Scope-Test für die Ausführung der Tests.</li></ol>Was haben wir damit erreicht? Wir können die MUnit-Tests – die wir erst noch schreiben müssen – nicht nur im Anypoint Studio ausführen, sondern sie werden auch im Build automatisch ausgeführt.<h2>Erster Test</h2>Jetzt kommt endlich der erste Test, den wir ganz faul mit einem Wizard erstellen. Dafür genügt ein Rechtsklick auf unseren zu testenden Flow: MUnit -> Create new suite. Anypoint-Studio legt daraufhin die Datei munit-testprojekt-test-suite.xml im Verzeichnis src/test/munit an. Der zugehörige Test-Flow öffnet sich auch direkt im Editor:<img loading="lazy" width="310" height="221" src="https://media.graphassets.com/S9lUXUXjQdRpQrzZrKKp" alt="Leerer-MUnit-Flow" />Im XML sieht es ähnlich aus (die Namespaces habe ich durch … ersetzt):

```
<?xml version="1.0" encoding="UTF-8"?>
<mule ...>
 <munit:config name="munit" doc:name="Munit configuration" />
 <spring:beans>
 <spring:import resource="classpath:munit-testprojekt.xml" />
 </spring:beans>
 <munit:test name="test-munit-testprojektFlowTest" description="Test">
 <flow-ref name="munit-testprojektFlow" 
 doc:name="Flow-ref to munit-testprojektFlow" />
 </munit:test>
</mule>
```

Wer schon einmal einen Mule Flow in der XML-Ansicht gesehen hat, dem wird das bekannt vorkommen: Tests sind auch nur Mule Flows.Mit einem Rechtsklick auf den Test im Flow-Editor lässt sich der Test direkt ausführen. Wenn bis hier alles glatt gelaufen ist, sollte in der MUnit-View ein grüner Balken erscheinen.Würde ich mich strikt an meine Aussage in der Einleitung halten, könnte ich jetzt aufhören. Schließlich läuft der Test. Ganz so einfach mache ich es mir dann doch nicht: Die Payload und den MIME Type möchte ich dann doch prüfen, also werden zweimal Assert Equals aus der Mule-Palette (Abteilung MUnit) in den Flow gezogen:<img loading="lazy" width="376" height="224" src="https://media.graphassets.com/qlytCE2Q4SLpDdloNyZC" alt="Test-Flow" />Intern sieht ein Assert Equals in MUnit ähnlich wie ein assertEquals() im JUnit-Test aus:<img loading="lazy" width="360" height="162" src="https://media.graphassets.com/juLyH61zTiK7rJ7KPGYL" alt="Check-Payload" />Oder im XML:

```
<munit:assert-on-equals expectedValue="Hello, world!" 
 actualValue="#[message.payload]"
 doc:name="Check Payload"/>
```

Der MIME Type ist schon etwas komplizierter zu prüfen. Dazu muss man wissen, dass er sich im DataType der Mule-Message versteckt:<img loading="lazy" width="352" height="161" src="https://media.graphassets.com/oKc7sEqiQCKJBRlUhE6M" alt="Check-MimeType" />Damit ist das kleine Projekt inklusive Testfall vollständig. Wer mag, kann auf der Kommandozeile mittels

```
mvn clean test
```

verifizieren, dass es auch dort funktioniert. Je nach Betriebssystem kann hier noch ein kleines Problem auftauchen: Das Maven-Plugin nutzt die Bibliothek <a href="https://github.com/fusesource/jansi" target="_blank">jansi</a> , um Text auf der Konsole farbig darstellen zu können. Unter Windows versucht es daher, die Datei jansi-64.dll unter C:\Windows abzulegen. Damit das funktioniert, muss man die Maven-Tests einmalig als Administrator ausführen oder die Datei manuell dort ablegen.<h2>Und nun?</h2>Wie in der Einleitung versprochen (oder angedroht?), mache ich für heute Schluss. Was kommt als nächstes? Ich habe da noch ein Projekt mit einem SOAP-Service, den plane ich schon für den zweiten Teil der Serie ein. Aber ich will nicht zu weit in die Zukunft schauen…<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Mule-Anwendungen mit MUnit testen (Teil 2): Testdaten und Asserts <a href="https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/">https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/</a> </li><li>Mule-Anwendungen mit MUnit testen (Teil 3): Tabellenbasierte Tests <a href="https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/">https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/</a> </li><li>Testen von Mule ESB Applikationen (Teil 2/3): Integrationstests und (Endpoint) Mocking mit MUnit: <a href="https://blog.codecentric.de/2015/01/testen-von-mule-esb-applikationen-teil-23-modultests-und-funktionales-testen/">https://blog.codecentric.de/2015/01/testen-von-mule-esb-applikationen-teil-23-modultests-und-funktionales-testen/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric-Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Mule-Anwendungen mit MUnit testen (Teil 1): Start im Anypoint Studio

Im <a href="https://blog.codecentric.de/2016/04/mule-munit-anypoint-studio/">ersten Teil</a> dieser Artikelserie hatte ich versprochen, einen SOAP-Service mit MUnit zu testen, also muss ich das wohl heute einlösen. SOAP ist dabei der Vorwand, die Versorgung mit Testdaten und die Überprüfung der Ergebnisse (assert) vorzuführen.Was brauchen wir zum Testen eines SOAP-Services? Ein Mule-Projekt mit einer SOAP-Schnittstelle. Mule kann SOAP in zwei grundsätzlichen Varianten anbieten:<ul><li>Als Proxy/Adapter für ein existierendes Backend, in dem die Fachlogik lebt.</li><li>Mule selbst bietet den Service an.</li></ul>Die erste Variante passt besser in das ESB-Umfeld, schließlich soll der ESB keine Fachlichkeit selbst implementieren. Würde ich das heute nutzen, müsste ich jedoch den „echten“ Service mocken, was ich mir aber für den nächsten Teil der Serie vorgenommen habe.Also bleibt – zumindest für diesen Blogpost – nur die zweite Variante: Mule selbst hostet den Service. Dank CXF innerhalb von Mule funktioniert das ohne Klimmzüge, hier der zugehörige Flow:<img width="290" height="206" src="https://media.graphassets.com/jIsjihRfTW68ZjDhjMWL" alt="CXF-in-Mule" />Links beginnen wir mit einem synchronen http-Endpoint, der alle Nachrichten direkt in eine CXF-Komponente leitet. Die CXF-Server-Komponente trennt die XML-Welt auf der linken Seite von der Java-Welt auf der rechten Seite: Rechts stecken in der Nachricht die Aufrufargumente für die Java-Methode, die von der Java-Komponente implementiert wird. Das Java-Objekt mit dem Ergebnis wandelt die CXF-Komponente wieder in eine SOAP-XML-Nachricht um, die der http-Endpoint auf der linken Seite an den Aufrufer zurückgibt.Wie man an dem Beispiel sieht, benötigt man in Mule neben den annotierten Klassen (Interface, Implementierung, Aufruf- und Ergebnisobjekte) nur noch einen kleinen Flow mit drei Elementen – fertig ist der CXF-Service. Hängt man an die Service-URL noch ein „?wsdl“, so liefert Mule auch die passende WSDL-Datei des Service aus. (Wer lieber WSDL-Dateien statt annotierter Klassen schreibt, kann natürlich auch aus der WSDL die annotierten Klassen generieren lassen.)<h2>Vorbereitung</h2>Nun aber zum Test: Bevor ich automatisiere, teste ich den Service mit SoapUI manuell. Den Testrahmen erzeugt SoapUI automatisch, es braucht dabei nur die WSDL (die Mule praktischerweise liefert). SoapUI generiert auf Basis der WSDL das Gerüst der Requests. In diese trägt man nur noch die Testdaten ein, hier ein Beispiel:

```
<soapenv:Envelope 
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:bmi="http://codecentric.de/services/bmi">
 <soapenv:Header/>
 <soapenv:Body>
 <bmi:calculateBmi>
 <input>
 <length>1.88</length>
 <mass>77</mass>
 </input>
 </bmi:calculateBmi>
 </soapenv:Body>
</soapenv:Envelope>
```

Das zugehörige Projekt stammt noch aus der Weihnachtszeit, da bot sich als Beispiel ein Service an, der auf Basis von Größe und Gewicht den so genannten „Body Mass Index“ (kurz: BMI) berechnet. Ruft man den Service in SoapUI auf (und hat in Mule keinen Fehler gemacht), zeigt SoapUI das Ergebnis an:

```
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
 <ns2:calculateBmiResponse xmlns:ns2="http://codecentric.de/services/bmi">
 <return>
 <bmi>21.79</bmi>
 <description>Normalgewicht</description>
 </return>
 </ns2:calculateBmiResponse>
 </soap:Body>
</soap:Envelope>
```

(Ich könnte den Service mal erweitern, so dass er einem noch direkt ausrechnet, wie viele Kilo man bei gegebener Größe noch zunehmen darf, bis man in den Bereich „Übergewicht“ wechselt…)Warum schreibe ich hier so viel über SoapUI, wo es doch eigentlich um MUnit gehen soll? Einfacher komme ich nicht an die Ein- und Ausgabedaten für den MUnit Test. Den erstellen wir mit einem Wizard, den wir per Klick mit der rechten Maustaste auf den Header des zu testenden Flows erreichen:<img loading="lazy" width="428" height="254" src="https://media.graphassets.com/Joko5Z3lRSKH9kSyhAFU" alt="New-MUnit-Test" />Über das Untermenü „Create new suite“ stoßen wir den Wizard an (okay, das hatten wir schon im ersten Teil…). Gegenüber dem ersten Teil können wir den Testfall allerdings nicht direkt erfolgreich ausführen, es fehlen noch die Eingabedaten für den SOAP-Service.<h2>Eingabe</h2>Die Eingabedaten (aus SoapUI kopiert) speichern wir als XML-Datei in dem Ordner src/test/resources. Ich ergänze noch ein Package, hier passend zur Implementierung de.codecentric.bmi. Wie kommen die Daten in den Test-Flow? Für kurze Strings bietet sich set-payload aus der Standard-Mule-Palette an, eine längere XML-Datei passt aber nicht sinnvoll in das Eingabefeld (und sieht dann wegen des Quotings aller Sonderzeichen in der XML-Ansicht des Flows gruselig aus). Daher habe ich die XML-Daten einer Datei gespeichert. Deren Inhalt müssen wir jetzt in die Payload bekommen.Mule bietet dazu in der Palette im Bereich MUnit das Element „Set Message“ (munit:set im XML) an. Auf den ersten Blick sieht man dort auch nur ein kleines Einabefeld (wie bei „Set Payload“). Allerdings gibt es hier in der MEL noch einige zusätzliche Funktionen, eine davon zum Laden von Ressourcen aus dem Classpath:#[getResource(‚de/codecentric/bmi/sample-input.xml‘).asString()] Die Methode getResource() erzeugt eine Instanz der Klasse MunitResource mit folgenden Methoden:<ul><li>asStream()</li><li>asString() (Encoding ist leider nicht einstellbar, es ist immer das Standardenconding des Betriebssystems)</li><li>asByteArray()</li></ul>Für die XML-Payload besteht die richte Wahl aus asString().Die GUI des AnypointStudio sperrt sich – in der aktuellen Version – dagegen, das Element „Set Message“ links neben der Flow-Reference abzulegen. Ein Workaround ist einfach: zuerst rechts neben die Flow-Reference legen, anschließend die Flow-Reference nach rechts ziehen, schon stimmt die Reihenfolge wieder.Somit hätten wir die Daten für den SOAP-Aufruf geladen, der Testfall sollte damit also funktionieren. Probieren wir es also aus: Ja, bei mir ist der Balken grün.Dummerweise bleibt der Balken auch dann grün, wenn das Ergebnis falsch ist. Sogar eine Exception in der Implementierung lässt den Balken nicht rot werden, da SOAP im Fehlerfall nur ein XML mit der Exception als Inhalt liefert. Es fehlt noch die Verifikation des Ergebnisses.<h2>Verifikation</h2>Die Verifikation der Ergebnisse funktioniert ähnlich wie in JUnit-Tests, mit „Assert Payload“ statt assertEquals(). Dazu kopieren wir uns vorher die Ausgabe aus SoapUI in eine Datei sample-output.xml und laden die Datei über getResource() (siehe oben).Laufen lassen, roter Balken…Ein genauer Blick in den Errors-Tab der MUnit-View oder ein Logger zeigt, dass wir kein XML zurückbekommen, sondern folgendes Objekt:

```
org.mule.module.cxf.CxfInboundMessageProcessor$2@5cc1bf20
```

Wer schon länger mit Mule arbeitet, sieht hier wieder Streaming am Werk und kennt den Standardtrick: Ein Object-to-String-Transformer zwischen Flow-Reference und dem Assert materialisiert den Stream in einen String.Laufen lassen, immer noch ein roter Balken…Schaut man sich wieder den Error-Tab an, erkennt man das Problem: Das XML aus SoapUI ist hübsch formatiert, aus CXF kommt jedoch ein kompaktes XML-Dokument in einer einzigen Zeile. Wir bekommen den Test grün, wenn wir die Ergebnisdatei ebenso in eine einzige Zeile schreiben.Laufen lassen, grüner Balken…Die Lösung funktioniert zwar, taugt aber ansonsten eher als schlechtes Beispiel:<ul><li>Der Testfall schlägt fehl, sobald sich die Formatierung des XML ändert, auch wenn die Daten korrekt sind.</li><li>Das XML in einer langen Zeile ist komplett unleserlich. Wartbarkeit sieht anders aus.</li></ul>Konzentrieren wir uns daher auf die wichtigen Dinge: Die Struktur und der Inhalt des XML müssen stimmen.Die Struktur einer XML-Datei finden wir (hoffentlich) in einer XSD. Falls sie nicht als separate Datei vorliegt und in die WSDL inkludiert wurde, ist es jetzt Zeit, sie zu extrahieren und in eine eigene Datei zu legen. Mule validiert XML mit Hilfe des schema-validation-filter gegen eine XSD. Letztere lässt sich aus dem Classpath laden, kann also unter src/main/resources oder src/test/resources liegen, je nachdem, ob wir sie nur für den Test oder auch im Produktionscode benötigen.Das XSD-Schema beschreibt nur das Ergebnisobjekt, in der Nachricht steckt jedoch eine komplette SOAP-Response, inklusive Envelope- und Body-Tag. Mit Hilfe von DataWeave entfernt man die beiden:

```
%dw 1.0
%output application/xml
%namespace soap http://schemas.xmlsoap.org/soap/envelope/
---
payload.soap#Envelope.soap#Body

```

Jetzt haben wir ein XML in der Payload stehen, das zur XSD passt.Eine Falle lauert noch beim Filter: Schlägt die Validierung fehl, bricht Mule den Flow an dem Filter kommentarlos ab. Die Asserts – die wir gleich noch einbauen – führt Mule nicht mehr aus, und MUnit bekommt nicht mehr die Möglichkeit, einen Fehler anzuzeigen. Möchte man beim Fehlschlagen des Filters eine Exception werfen, schachtelt man den Validation-Filter in einen Message-Filter, bei dem throwOnUnaccepted auf „true“ gesetzt wird. So sieht der zugehörige Flow-Schnipsel im XML aus:

```
<message-filter throwOnUnaccepted="true" doc:name="Check structure">
 <mulexml:schema-validation-filter
 name="check-response" 
 schemaLocations="de/codecentric/bmi/bmi-response.xsd" 
 returnResult="true" 
 doc:name="Schema Validation"/>
</message-filter>

```

Jetzt steht hinter dem Filter ein XML mit garantiert korrekter Struktur in der Payload. Daraus können wir mittels DataWeave zwei Flow-Variablen extrahieren: bmi und description. Da der Filter den Mime-Type nicht auf application-xml setzt, müssen wir in DataWeave den Mime-Type explizit angeben (funktioniert leider nur im XML und nicht über den GUI-Editor):

```
<dw:input-payload mimeType="application/xml" />

```

Das folgende DataWeave-Script extrahiert aus dem XML den bmi:

```
%dw 1.0
%output application/java
%namespace bmi http://codecentric.de/services/bmi
---
payload.bmi#calculateBmiResponse.return.bmi

```

Das Script für die description sieht ähnlich aus (das überlasse ich dem Leser als Übung).Jetzt steht alles bereit für die zwei finalen Asserts:

```
<munit:assert-on-equals message="bmi" 
 expectedValue="22.35" actualValue="#[bmi]" doc:name="Assert bmi" />
<munit:assert-on-equals message="description" 
 expectedValue="Normalgewicht" actualValue="#[description]"

```

Und zu guter Letzt auch noch eine grafische Darstellung des vollständigen Test-Flows:<img loading="lazy" width="847" height="220" src="https://media.graphassets.com/HK93fq1nTnGBisQ4ybkJ" alt="Test-Flow" /><h2>Fazit</h2>Hat es sich gelohnt? Von mir kann ja nur ein „Ja“ kommen, sonst hätte ich mir den Blog-Beitrag ja sparen können. Also muss ich wohl eine Begründung liefern: Auf der Haben-Seite steht eine übersichtliche Darstellung in der GUI, die den Ablauf des Tests klar visualisiert:<ul><li>Daten laden</li><li>Aufruf des Testflows</li><li>Body extrahieren (SOAP-Envelope mit DataWeave abstreifen)</li><li>Schema-Validierung</li><li>Extrahieren der Werte (ebenfalls DataWeave)</li><li>Ein Assert für jeden der beiden Werte</li></ul>Schlägt irgendetwas fehl, sieht man in der Fehlermeldung auch direkt die Ursache: Struktur, bmi, description.Und wie sieht es im XML aus? Zwölf Zeilen für Namespaces etc. plus 32 Zeilen für den eigentlichen Testfall. Zugegeben, in der Länge könnte Java das mit dem passenden SOAP-Framework eventuell unterbieten. Dann darf man aber auf keinen Fall die (generierten) Zeilen für das Interface und die Transportobjekte mitzählen.Das ist natürlich erstmal ein einfaches Beispiel. In weiteren Folgen werde ich noch auf das Thema Mock eingehen. Vorher schiebe ich eventuell aber noch etwas zum Thema tabellenbasiertes Testen ein, mal sehen…<h2>Links</h2><ul><li>Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung <a href="https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/">https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/</a> </li><li>Mule Anwendungen mit MUnit Testen (Teil 1): Start im Anypoint Studio: <a href="https://blog.codecentric.de/2016/04/mule-munit-anypoint-studio/">https://blog.codecentric.de/2016/04/mule-munit-anypoint-studio/</a> </li><li>Mule-Anwendungen mit MUnit testen (Teil 3): Tabellenbasierte Tests <a href="https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/">https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/</a> </li><li>Alle Blog-Artikel zu Mule im codecentric-Blog: <a href="https://blog.codecentric.de/?s=mule">https://blog.codecentric.de/?s=mule</a> </li><li>Was ist ein ESB und wofür kann man ihn nutzen? <a href="https://blog.codecentric.de/2012/11/was-und-wofur-esb/">https://blog.codecentric.de/2012/11/was-und-wofur-esb/</a> </li><li>Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! <a href="https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/</a> </li></ul>

Mule-Anwendungen mit MUnit testen (Teil 2): Testdaten und Asserts

Mule legt den Datentyp für die Payload einer Nachricht nicht fest. Genauer als <code>Object</code> will es das Maultier nicht wissen. Häufig sind es PoJos, XML oder JSON. Da die letzten beiden nur strukturierter Text sind, müssen sie irgendwie abgelegt werden. Das geschieht entweder am Stück (<code>String</code>) oder über Streaming (<code>InputStream</code>). Die meisten Mule-Komponenten schlucken beide Varianten klaglos. Auch die in der Enterprise-Version vorhandene Transformationssprache DataWeave arbeitet serienmäßig mit beiden Varianten.Für erfahrene Mule-Entwickler dürfte das alles nicht neu sein. Was jedoch weniger bekannt ist: Streaming funktioniert auch mit PoJos: Richtig konfiguriert kann DataWeave nicht nur eine <code>List</code> von Objekten erzeugen, sondern auch einen <code>Iterator</code>.Vorher aber noch etwas einge Details zum Streaming von Texten. Für alte Hasen ist das quasi eine Wiederholung, für viele sind aber sicher noch einige Neuigkeiten dabei.<h2>DataWeave Streaming mit XML, JSON und anderen Textformaten</h2>Zieht man eine DataWeave-Transformation in den Flow und konfiguriert ein Textformat als Ausgabe (CSV, XML, JSON), so sieht man anschließend in der Payload einen <code>java.io.InputStream</code> (bzw. eine davon abgeleitete Klasse). Es sieht also so aus, als würde DataWeave seine Eingabe liegenlassen und erst mit der Arbeit anfangen, sobald der nächste Message Processor den Stream liest. Das stimmt jedoch nicht: Schaut man genauer hin, sieht man einen <code>ByteArraySeekableStream</code>. DataWeave verarbeitet seine Eingabe komplett und liefert anschließend eine Stream-Sicht auf das Ergebnis.Aber halt: Heißt es nicht, dass durch Streaming Payloads größer als der Hauptspeicher möglich sind? Was passiert bei einer großen Eingabe – gibt es dann irgendwann eine <code>OutOfMemoryException</code>, weil das Byte-Array zu groß wird? Nein, Mule verwendet nur dann ein Byte-Array, wenn es nicht zu viele Daten sind. Ab der Größe von 1,5 MByte (genau: 1572864 Bytes) schaltet Mule auf einen <code>RandomAccessFileSeekableStream</code> um, also auf einen Stream, der über den Umweg eines Delegate auf eine Datei zeigt.Mule kombiniert hier also die schnelle Lösung „Hauptspeicher“ mit der langsameren, aber sicheren Lösung „Dateisystem“. Wem die Grenze von 1,5 MByte nicht gefällt: Sie lässt sich ändern – über die System Property <code>com.mulesoft.dw.buffersize</code>. Damit gilt sie allerdings für den gesamten Server, nicht für einen einzelnen DataWeave. Alles gut? Nicht ganz: Die abstrakte Klasse <code>InputStream</code> enthält eine <code>close()</code>-Methode. Im Fall der Hauptspeicherlösung spielt sie keine große Rolle, hinter dem Byte-Array steckt nur ein Stück Speicher, um den sich auch ohne Aufruf von <code>close()</code> irgendwann der Garbage Collector kümmert.Im Fall des <code>RandomAccessFileSeekableStream</code> ist es jedoch doppelt gefährlich: Wird hier kein <code>close()</code> aufgerufen, bleibt nicht nur das Datei-Handle auf Betriebssystem-Ebene geöffnet, sondern es bleibt auch die Datei auf der Platte liegen. Der Delegate-Mechanismus sorgt nämlich dafür, dass beim Aufruf von <code>close()</code> die Datei nicht nur geschlossen, sondern auch aus dem Dateisystem gelöscht wird.<h2>Geschlossen?</h2>Es stellt sich die Frage, wie es dazu kommen kann – schließlich ruft doch der nächste Message-Prozessor automatisch <code>close()</code> auf. Schneller als man denkt: Eventuell wird der Stream einige Schritte weitergereicht, bevor er verarbeitet wird. Tritt dann eine Exception auf, haben wir ein Problem. Oder es wird nach dem DataWeave noch eine Entscheidung per Choice-Router getroffen, und in einem der Zweige ist die Payload nicht interessant.Es gibt mehrere Varianten, wie man sich hier ins Knie schießen kann. Dummerweise handelt es sich um ein Problem, das meistens erst in der Produktion auffällt: Wer testet schon mit großen Dateien? Und dann noch mit so vielen, dass die Platte vollläuft? Wer schaut nach Tests schon im Temp-Verzeichnis nach? Was hilft also? Nur Wissen um das Problem und Vorsicht: Im Zweifelsfall im Exception-Handler noch den Stream schließen. Generell ist es guter Stil, offene Streams nicht über viele Schritte weiterzureichen.<h2>On Demand Streaming</h2>Die bisher beschriebene Streaming-Variante funktioniert zwar mit beliebiger Nachrichtengröße bei begrenztem Hauptspeicher, dafür benötigt sie jedoch externen Speicher. Der ist zwar meistens größer, aber auch endlich und kann daher zum Engpass werden. Weiterhin ist sie nicht wirklich parallel: DataWeave verarbeitet die Eingangsdaten komplett, bevor der nächste Message Processor starten kann.Wer echte Parallelität möchte, muss im XML <code>mode="deferred"</code> einstellen. DataWeave gibt in diesem Fall eine Instanz zurück, die das Interface <code>OutputHandler</code> implementiert. Es enthält nur eine Methode: <code>void write(MuleEvent event, OutputStream out) throws IOException</code>.Was passiert hier? Wenn der DataWeave-Knoten durchlaufen wird, nicht viel: DataWeave liest sein Skript ein, macht ansonsten aber nichts. Erst beim Aufruf von <code>write(...)</code> aus dem <code>OutputHandler</code> läuft der Transformationscode los und schreibt sein Ergebnis in den Ausgabestrom, der ihm sozusagen nachträglich und von hinten zur Verfügung gestellt wird.Aber Vorsicht: Nicht alle Komponenten setzen den <code>OutputHandler</code> so ein, wie man es sich wünscht. Wenn man Pech hat, wird die Payload doch noch im Speicher materialisiert. Im Zweifelsfall sollte man sich nicht darauf verlassen, sondern testen. Wichtig ist es dabei, nicht nur mit kleinen Nachrichten zu testen, sondern auch mit großen, die den Hauptspeicher sprengen. Besser im Test als nach dem Livegang…Weitere Details zu dem Thema findet man in der MuleSoft-Dokumentation unter <a href="https://docs.mulesoft.com/mule-user-guide/v/3.9/dataweave-memory-management" target="_blank">DataWeave memory management</a> .<h2>DataWeave mit Java</h2>Der Schnipsel <code>%output application/java</code> im Header eines DataWeave-Skripts reicht aus, um Java-Objekte zu erzeugen. Ohne Angabe konkreter Java-Klassen (PoJos) erzeugt DataWeave eine generische Struktur aus Listen und Maps. So eine Struktur ist bei kleinen Datenmengen sehr effizient. Bei größeren hat sie jedoch das Potential, den Hauptspeicher zu sprengen. Abhilfe besteht darin, auch Java-Objekte zu streamen. Wie das funktioniert, werde ich in den folgenden Abschnitten zeigen.<h2>Beispiel: Geodaten synchronisieren</h2>Zuerst benötigen wir aber ein (mehr oder weniger konstruiertes) Beispiel: In JSON vorliegende Geodaten (eine Menge von Punkten) sollen an einen REST-Service gesendet werden. Quelle kann eine Datei oder der HTTP-Listener von einem Post-Request sein. Wichtig ist nur, dass die Quelle einen Stream in der Payload liefert.Als Quellformat nutze ich <a href="http://geojson.org/" target="_blank">GeoJSON</a> , das man sich auch leicht auf einer Karte darstellen lassen kann (siehe <a href="http://geojson.io/" target="_blank">geojson.io</a> ). Eine Beispieldatei mit zwei Punkten auf der Weltkugel sieht folgendermaßen aus:<div>

```javascript
{
 "type": "FeatureCollection",
 "features": [
 {
 "type": "Feature",
 "properties": {
 "marker-color": "#7e7e7e",
 "marker-size": "medium",
 "marker-symbol": "",
 "name": "CC Headquarter"
 },
 "geometry": {
 "type": "Point",
 "coordinates": [
 7.00702428817749,
 51.16197720229481
 ]
 }
 },
 {
 "type": "Feature",
 "properties": {
 "marker-color": "#7e7e7e",
 "marker-size": "medium",
 "marker-symbol": "",
 "name": "MuleSoft Germany"
 },
 "geometry": {
 "type": "Point",
 "coordinates": [
 6.9658,
 50.9274
 ]
 }
 }
 ]
}
```

</div>Längen- und Breitengrad stehen in einem Array (ein optionales drittes Arrayelement steht für die Höhe), weitere Daten können die Darstellung auf der Karte steuern (Art des Markers, Farbe etc.).Das Zielformat ist etwas einfacher gestrickt:<div>

```javascript
{
 "points": [
 {
 "latitude": 51.16197720229481,
 "longitude": 7.00702428817749, 
 "name": "CC Headquarter"
 },
 {
 "latitude": 50.9274,
 "longitude": 6.9658, 
 "name": "MuleSoft Germany"
 } 
 ]
}
```

</div>Neben Längen- und Breitengrad wird hier zu jedem Punkt nur der Name gespeichert. Das Skript zur Umwandlung der beiden Formate ist recht einfach:

```

%dw 1.0
%output application/json
---
{ 
 points: payload.features map ((feature , indexOfFeature) -> {
 name: feature.properties.name,
 latitude: feature.geometry.coordinates[1],
 longitude: feature.geometry.coordinates[0]
 })
}
```

Eigentlich eine typische Situation: Für ein fachliches Problem – Liste von Punkten auf unserer Weltkugel – existieren technisch leicht inkompatible Formate. Wenn wir die Daten aus einer Datei lesen (Streaming möglich) und über HTTP-Post beim Zielservice abliefern können (Streaming möglich), dann haben wir unser Problem auch schon gelöst.<h2>Na und? Wo ist das Problem?</h2>Wo liegt also das Problem? Wie gesagt, wir konstruieren ein Beispiel: Nehmen wir an, dass die Post-Requests nicht beliebig groß werden dürfen. Oder wir ein Stück Java-Code eine Berechnung auf den Koordinaten ausführen lassen wollen. In beiden Fällen können wir nicht ein großes JSON (mit Streaming) erzeugen. Schalten wir das Ausgabeformat auf Java (durch <code>%output application/java</code> im Header), entsteht ein anderes Problem: DataWeave erzeugt eine Liste (genauer: <code>java.util.ArrayList</code>) von Objekten, die vollständig im Hauptspeicher landet.<h2>DataWeave mit Iterator</h2>Dabei existiert eine Streaming-Lösung in Java: der gute alte <code>Iterator</code>. Kann Mule das auch? Einfache Antwort: Ja, das geht. Auch wenn es in der Dokumentation anscheinend vergessen wurde. Einfach im DataWeave ein <code>as :iterator</code> anhängen, Beispiel:

```

%dw 1.0
%output application/java
---
(payload.features map ((feature , indexOfFeature) -> {
 name: feature.properties.name,
 latitude: feature.geometry.coordinates[1],
 longitude: feature.geometry.coordinates[0]
})) as :iterator

```

Meist – wie hier – ist es dabei noch notwendig, den Ausdruck vor <code>as :iterator</code> in runde Klammern einzurahmen.Mit diesem Code erhalten wir nicht mehr eine Liste, sondern einen <code>java.util.Iterator</code>, der sich als Eingabe in einen „For Each“ oder „Batch“ von Mule eignet.Wenn wir die so erhaltenen Datensätze einzeln an einen Webservice übergeben, haben wir den Teufel „Speicherverschwendung“ jedoch mit dem Beelzebub „viele kleine Aufrufe“ ausgetrieben: Es ist einfach nicht effizient, jeden Datensatz einzeln per HTTP-Post an einen Service zu übergeben.<h2>Gruppierung</h2>Zwischen „alle Punkte auf einmal“ und „jeden Punkt einzeln“ existiert noch die goldene Mitte: „Gruppe von Punkten“. Auch das funktioniert einfach: In „For Each“ das Attribut <code>batchSize</code> setzen. Innerhalb der Schleife verarbeitet der Flow dann nicht mehr einzelne Datensätze, sondern jeweils eine Liste der Größe <code>batchSize</code> (oder kleiner, wenn das Ende der Quelle erreicht ist).Ein Flow könnte damit folgende Elemente enthalten:<ol><li>Eine Datenquelle (HTTP-listener, File-listener, etc.)</li><li>Ein DataWeave mit einem <code>Iterator</code> als Ergebnis</li><li>Ein „For Each“ mit <code>batchSize</code> größer 1</li><li>In der Schleife:</li><ul><li>Ein DataWeave, der aus der Liste von Punkten ein JSON-Dokument erzeugt</li><li>Ein Post an den externen REST-Service</li></ul></ol>Oder als Bild:<a href="https://blog.codecentric.de/2018/09/mule-streaming-dataweave/for-each-mit-batch/"><img width="521" height="190" src="https://media.graphassets.com/kPbCIdgkRISppUhHdMdv" alt="For-Each mit Batch" /></a> <h2>Zusammenfassung und Ausblick</h2>Streaming ist ein mächtiges Werkzeug. Nur damit ist es möglich, Datenmengen jenseits der Hauptspeichergröße verarbeiten zu können. Mule arbeitet an vielen Stellen automatisch mit Streams, so dass man sich als Entwickler nicht darum kümmern muss. Leider nicht an allen Stellen und auch nicht ohne Tücken: Ein vergessenes <code>close()</code> hat unter Umständen fatale Folgen in der Produktion.In diesem Blogpost haben wir drei Arten von Streaming mit DataWeave kennengelernt:<ol><li>DataWeave Default mit Textformat (z. B. JSON) als Ausgabe. Hier haben wir zwar einen Stream, aber trotzdem eine rein sequentielle Verarbeitung: erst DataWeave komplett, dann der nächste Message Processor. Mule kümmert sich nur darum, dass größere Datenmengen auf der Platte gepuffert werden.</li><li>DataWeave im Modus „deferred“: Hier läuft die Transformation erst in dem Moment los, in dem eine Senke zur Verfügung steht. Damit ist auch Parallelität zwischen mehreren Message Processors möglich.</li><li>DataWeave mit einem <code>Iterator</code> als Ausgabe. Auch hier brauchen wir nicht die Platte, und es ist echte Parallelität möglich. Außerdem kann man mit einem for-each hinter dem DataWeave bequem gruppieren.</li></ol>Mit Mule 4 hat sich das Streaming übrigens grundsätzlich geändert: Dort kann man zum Beispiel einen Stream auch mehrfach lesen. Aber das ist einen eigenen Blogpost wert.

Mule: Streaming mit DataWeave

Ein ESB sitzt meistens nicht in einer langweiligen Ecke der Unternehmens-IT, sondern mitten drin. Da wo es wichtig ist. Da wo auch mal etwas mehr Last zu bewältigen ist. Da wo ein Ausfall oder Performance-Problem richtig weh tut. In diesem Artikel geht es um Tuning-Möglichkeiten und damit um die Thread-Architektur von Mule. Deren Kenntnis führt direkt zu den Stellschrauben, an denen man zur Optimierung der Performance drehen kann. Liest man im Internet einen Artikel rund um das Thema ESB und Performance, taucht beinahe immer auch die Abkürzung SEDA auf. Was ist SEDA? Die deutsche Wikipedia löst immerhin die Abkürzung auf: Staged Event Driven Architecture. Das war’s dann aber auch, für mehr Details kann man es ja mal mit der englischen Variante probieren: Neben der Übersichtsseite (mit Verweis auf berühmte Personen und einen Serienkiller) findet sich dort wenigstens auch ein Artikel, der SEDA im Zusammenhang mit Informatik erklärt. Er ist zwar arg kurz geraten, aber man soll seine Erkenntnisse ja auch besser aus der Primärliteratur ziehen, die ist zumindest referenziert. Unter den Referenzen findet sich auch ein kritischer Blog-Artikel zu SEDA.  Aber der Reihe nach, in Mule ist nämlich nicht alles SEDA, was auf den ersten Blick so aussieht.<h1>Ein einfacher Flow mit http</h1>Fangen wir mit einem einfachem Flow an, dem Debug-Flow aus dem letzten Artikel mit einer kleinen Veränderung: Die Java-Component wartet eine – über URL-Parameter – einstellbare Zeit. Das sieht dann folgendermaßen aus:<a href="https://media.graphassets.com/GqPxLvpoSJSFWNh6pi58"><img alt="SlowFlow" src="https://media.graphassets.com/GqPxLvpoSJSFWNh6pi58" width="462" height="241" /></a> Vorne ein http-Inbound-Endpoint, ein Transformer, der aus dem http-Request die Parameter extrahiert, anschließend die Java-Component. In XML sieht es folgendermaßen aus:

```xml
<flow name="SlowFlow" doc:name="SlowFlow">
 <http:inbound-endpoint exchange-pattern="request-response" 
 host="localhost" 
 port="8080" path="slow"
 doc:name="slow"
 mimeType="text/plain"
 connector-ref="HTTP" />
 <http:body-to-parameter-map-transformer doc:name="Body to Parameter Map" />
 <component class="de.codecentric.perftest.SlowComponent" doc:name="SlowComponent" />
</flow>
```

Die Java-Klasse ist auch nicht sonderlich kompliziert:

```Java
package de.codecentric.perftest;

import java.util.Map;

public class SlowComponent {
 public String processMessage(Map<String, String> parameters)
 throws InterruptedException {
 int sleepTime;
 try {
 sleepTime = Integer.parseInt(parameters.get("sleep"));
 } catch (Exception e) {
 sleepTime = 0;
 }
 Thread.sleep(sleepTime * 1000); // Millisekunden -> Sekunden
 return "Hello, waited " + sleepTime + " seconds";
 }
}
```

Was macht dieser Flow? Er beantwortet Requests der Art <code>http://localhost:8080/slow?sleep=5</code> mit einer Zeile Text. Dies geschieht jedoch nicht sofort, sondern erst nach der einstellbaren Wartezeit (in Sekunden), per URL-Parameter „sleep“. Im Beispiel würde also nach fünf Sekunden im Browser der Text „Hello, waited 5 seconds“ erscheinen.Die Warterei simuliert Aufrufe an andere Services oder I/O-Operationen. Beide zeichnen sich dadurch aus, dass die CPU (zumindest die auf dem eigenen Server) nichts zu tun hat und – wie im Beispiel – auf ein externes Ereignis wartet.Was passiert, wenn man einen Request abschickt? Er wird nach der eingestellten Zeit – zuzüglich ca. 10 µs – 2 ms für die Verarbeitung – eine Zeile an den Browser zurückliefern. So weit, so langweilig. Was passiert, wenn man 10 oder 100 Requests direkt hintereinander abschickt? Werden alle Requests sequentiell abgearbeitet? Oder alle parallel? Kommt auf die Einstellungen im Flow an…Der http-Inbound-Endpoint von Mule funktioniert wie gängige Servlet-Container: Er erzeugt an dem http-Server, der für einen Port zuständig ist, einen Thread-Pool. Requests werden an Threads aus dem Pool gebunden und ausgeführt. Während der Wartezeit ist der Thread blockiert, er wird erst wieder freigegeben, wenn der Reply zurück an den Browser geschickt wird.Der Pool enthält standardmäßig 25 Threads, die jedoch nicht alle sofort gestartet werden, sondern „on demand“. Die Anzahl stellt man nicht am Endpoint ein, sondern am Connector. Ist auch logisch, schließlich können sich mehrere Endpoints einen Port (und damit http-Server) teilen. Die Konfiguration des Connectors sieht folgendermaßen aus:

```"XML
<http:connector name="HTTP" doc:name="HTTP\HTTPS" receiveBacklog="100" >
 <receiver-threading-profile maxThreadsActive="10" />
</http:connector>
```

Im Beispiel wurde die Anzahl der Threads auf zehn begrenzt, das „receiveBacklog“ jedoch auf 100 gesetzt. Es legt fest, wie viele Verbindungsanfragen ein Socket in seine Warteschlange einreiht, bevor er neue Anfragen mit der Fehlermeldung „Connection refused“ abweist. Für die Thread-Einstellungen muss man übrigens in die XML-Ansicht wechseln, in der GUI sind sie nicht sichtbar. Welche weiteren Parameter im Threading-Provile existieren, zeigt der XML-Editor an, wenn man Strg+Leertaste betätigt. (Die XSD-Datei von Mule ist sehr gut mit Hilfetexten versehen.)<h2>Kleiner Benchmark</h2>Für Tests habe ich einen Web-Client mit 40 Threads gestartet, von denen jeder 10 Requests abschickt, die Wartezeit der Java-Component war auf eine Sekunde eingestellt. Die Ergebnisse sind (beinahe) wie erwartet: Bei einem Thread im Mule Server dauert es 163 Sekunden, bei 10 Threads 27 Sekunden, bei 50 Threads 11 Sekunden. Warum nicht genau wie erwartet? Mule hat noch einige Reserve-Threads in der Hinterhand, die bei „zu wenigen“ http-Threads einspringen und das Ergebnis schneller als erwartet ausfallen lassen. 50 Threads in Mule sind dann „genug“ (ihnen stehen ja nur 40 Client-Threads gegenüber): Hier hätten wir im Idealfall 10 Sekunden erwarten können, die Abweichung von ca. einer Sekunde dürfte dem Overhead der vielen Threads geschuldet sein.<h2>Alles SEDA oder nicht?</h2>Liest man das Paper „SEDA: An Architecture for Well-Conditioned, Scalable Internet Services“ von Matt Welsh, David Culler und Eric Brewer und hat die Aussage im Hinterkopf, dass Mule (und andere ESBs) SEDA umsetzen, so kann man sich am Kopf kratzen: SEDA funktioniert anders. Bei echtem SEDA hätte für das Beispiel ein Thread für maximale Performance gereicht, schließlich hat die CPU beinahe nichts zu tun, neben dem Request-Parsing wird ja nur eine Sekunde gewartet.Aber was bedeutet SEDA nun? Wer’s genau wissen will: Oben genanntes Paper lesen. Kurze Zusammenfassung: Statt viele Threads zu nutzen, die jeweils einem Request zugeordnet werden, gibt es bei SEDA nur wenige (im Extremfall einen) Threads, die jedoch nicht blockieren: In unserem Beispiel wird der Request-Thread für die eine Sekunde blockiert und steht auch nicht für andere Aufgaben (z.B. nächsten Request annehmen) zur Verfügung. In SEDA sieht die Struktur komplett anders aus, dort gibt es mehrere Stages und in einem Stage wird nie blockiert.In unserem Beispiel würde ein erster Stage den Request (man könnte ihn auch Event nennen) entgegennehmen und bis zur „Wartestelle“ treiben. In der Praxis wäre dies der Aufruf eines weiteren Systems, bei uns nur ein Sleep. Ein zweiter Stage würde jetzt auf das Event „Antwort vom anderen System“ (bzw. Wartezeit beendet) reagieren. Damit keine Events verloren gehen, werden sie bei Bedarf in einer Warteschlange vor den Stages gepuffert.SEDA benötigt weniger Threads als der Ansatz in typischen Webservern, der Nachteil ist eine aufwändigere Programmierung: Jeder potentiell blockierende Zugriff auf eine Ressource (Datei, entferntes System, etc.) führt dazu, dass der Stage aufgeteilt werden muss. Im Extremfall reicht ein einzelner Thread, in der Praxis wird einen gemeinsamen Thread-Pool oder einen Pool pro Stage verwenden.Die Idee von SEDA ist schon ein paar Jahre alt, inzwischen haben sich die Rahmenbedingungen geändert. Betriebssystem (und das JDK) sind in Bezug auf Threads deutlich effizienter geworden, so dass man sich mehr Threads „leisten“ kann, ohne ineffizient zu werden. Sehr schön dargelegt ist dies in dem Blog-Artikel Is it Raining Comets and Threads… Again? von Jose Maria Arranz aus dem Jahr 2008.Die Tatsache, dass Mule bei synchronen Flows kein SEDA einsetzt, kann man daher durchaus verschmerzen. Ich habe hier bewusst auf „synchrone Flows“ verallgemeinert, was oben exemplarisch für http beschrieben wurde, gilt auch für andere Inbound Endpoints mit Reqest-Reply-Pattern.<h1>Asynchrone Flows</h1>Wenn ich schon so oft SEDA erwähne, dann muss es irgendwann auch mal kommen, jetzt ist es so weit. Das Beispiel dafür hatten wir schon mal in einem anderen Zusammenhang, der einfache File-Copy-Flow aus Teil 2 der Artikelserie:<a href="https://media.graphassets.com/3VHduENMTsuRwyjhL4eu"><img loading="lazy" alt="FileCopyFlow" src="https://media.graphassets.com/3VHduENMTsuRwyjhL4eu" width="353" height="144" /></a> Was macht der Flow? Er überwacht ein Verzeichnis, greift sich alle Dateien daraus, loggt jede Datei, kopiert sie in ein Zielverzeichnis. Diesen Flow setzt Mule gemäß SEDA um, es kommen drei Stages mit jeweils einem eigenen Thread-Pool zum Einsatz. Zwischen den Stages befinden sich Queues, über die Messages (SEDA: Events) weitergeleitet werden:<ol><li>Ein Stage für den Inbound-File-Endpoint</li><li>Ein Stage für den Kern des Flows (hier nur der Logger, wären es mehrere Komponenten, würden alle im gleichen Pool ausgeführt)</li><li>Ein Stage für den Outbound-File-Endpoint</li></ol>Mule-Default sind hier wieder 25 Threads pro Pool, die Anzahl lässt sich natürlich wieder konfigurieren. Für die beiden File-Endpoints benötigt man – wie schon bei http – einen Connector. Darin werden jedoch jetzt zwei Pools über sogenannte Threading-Profiles konfiguriert: Ein Receiver-Profile für Inbound-Endpoints, ein Dispatcher für Outbound-Endpoints. So sieht’s im XML aus:

```XML
<file:connector name="FILE">
 <receiver-threading-profile maxThreadsActive="1" />
 <dispatcher-threading-profile maxThreadsActive="1" />
</file:connector>
```

Den Thread-Pool für den Flow konfiguriert man ebenso nicht direkt am Flow, sondern über eine Processing-Strategy:

```XML
<asynchronous-processing-strategy name="async" maxThreads="10">
```

Die Strategie muss anschließend im Flow refernziert werden, der Connector in den beiden Endpoints:

```XML
<flow name="FileFlow" doc:name="FileFlow" processingStrategy="async">
 <file:inbound-endpoint path="files/in" doc:name="File In" connector-ref="FILE"/>
 <logger level="INFO" doc:name="Logger" />
 <file:outbound-endpoint path="files/out" doc:name="File Out" connector-ref="FILE"/>
</flow>
```

Welche Größen für die einzelnen Pools sinnvoll sind, lässt sich nicht pauschal beantworten, dafür muss man wissen, wie lange die einzelnen Stages (oder Components) benötigen und wieviel Last man anderen beteiligten System zumuten möchte. Einige Hinweise und Formeln dazu findet man in der Mule-Dokumentation unter dem Titel „<a href="http://www.mulesoft.org/documentation/display/current/Tuning+Performance">Tuning Performance</a> „. In unserem Beispiel müsste ein Pool nicht groß sein: Der Receiver-Pool des File-Connectors. Warum? Weil der File-Connector nicht viel Arbeit hat: Er überwacht zwar das Verzeichnis und öffnet die Dateien, aber er liest sie nicht. Stattdessen wird der InputStream als Payload in der Message weitergereicht. Gelesen wird die Datei erst im Flow selbst (zweiter Stage). Anders sieht es beim Outbound-Endpoint aus: Hier muss wirklich in die Datei geschrieben werden, was bei großen Dateien schon mal länger dauern kann.<h1>Gemischte Flows</h1>Die Welt der Flows lässt sich nicht scharf in synchron und asynchron aufteilen, es gibt auch Mischformen, die sich manchmal implizit ergeben, oder die man mit Hilfe eines Async-Scopes erzwingen kann. Hier ein einfaches Beispiel eins synchronen http-Flows, mit einem asynchron laufenden File-Outbound-Endpoint: <a href="https://media.graphassets.com/NXNM8heDRAi0jb7OZCt4"><img loading="lazy" alt="HybridFlow" src="https://media.graphassets.com/NXNM8heDRAi0jb7OZCt4" width="354" height="243" /></a> Was passiert in dem Flow? Im Thread des Inbound-Endpoints wird Echo-Component ausgeführt, anschließend schickt der Endpoint das Ergebnis an den Aufrufer zurück. Hinter der Echo-Component wird die Message jedoch in eine Queue für einen zweiten Thread-Pool eingestellt, der zum File-Outbound-Endpoint gehört. Das Verschicken der Antwort per http und das Schreiben der Datei werden in getrennten Threads ausgeführt, so dass sie sich nicht gegenseitig beeinflussen.<h1>Zusammenfassung</h1>Ein oder mehrere Flows sind in Mule schnell zusammengeklickt, die Details der Verarbeitung mit den diversen Thread-Pools bleibt dabei erst einmal verborgen. Auch bei der Programmierung von Java-Components muss man sich um Threads und Synchronisierung nicht kümmern (man sollte nur keine static-Variablen nutzen).Geht es darum, die Performance eines Systems unter hoher Last zu analysieren oder zu tunen, sollte man sich den Aufbau genauer anschauen und die Stellschrauben kennen. Der Artikel hat dazu hoffentlich einen Grundstock gelegt. Im Zweifelsfall sollte man die Pools übrigens nicht zu klein wählen: Mule erzeugt nicht sofort beim Start die volle Zahl von Threads, dies geschieht erst dann, wenn sie wirklich benötigt werden.<h1>Weitere Teile dieser Artikelserie</h1><ol><li><a href="http://blog.codecentric.de/2012/11/was-und-wofur-esb/">Was ist ein ESB und wofür kann man ihn nutzen?</a> </li><li><a href="http://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/">Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-komponenten/">Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten</a> </li><li><a href="http://blog.codecentric.de/2013/01/tutorial-mule-esb-mulemessage-java-transform/">Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren</a> </li><li><a href="http://blog.codecentric.de/2013/06/tutorial-enterprise-service-bus-mit-mule-esb-integration-von-cics-programmen/">Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-esb-transport-connector-endpoint-grundlagen/">Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…</a> </li><li><a href="http://blog.codecentric.de/2013/07/tutorial-enterprise-service-bus-mule-esb-performance-threads/">Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mule-esb-jmx-kontrolle-steuerung/">Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX</a> </li><li><a href="http://blog.codecentric.de/2013/09/veroffentlichen-der-versionsnummer-von-mule-applikationen/">Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld</a> </li><li><a href="http://blog.codecentric.de/2013/09/tutorial-enterprise-service-bus-mit-mule-esb-exceptions-email/">Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email</a> </li></ol>

Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads

In the last few years there has been nearly no improvement in single thread performance of CPUs. On the other hand, the number of cores increases: Laptops with eight cores are common (okay, including hyperthreading, only four real cores). Even modern smartphones often have four cores. To utilize these modern beasts, you need parallel programming.In this article, I use a simple board game as an example for a parallel algorithm and other optimization techniques, a variant of <a href="http://en.wikipedia.org/wiki/Peg_solitaire">peg solitaire</a> . The problem to solve is: How many different solutions exist for a board with n pegs on a side? The focus is on different optimization techniques, not only the Fork/Join framework. You may be surprised to find other techniques are much more efficient for these problems.<h2>Definition of the Problem</h2>Lets start with a more precise definition of the problem. We play on a triangular board. A board with edge length 5 (n = 5) before any move has been done looks like this:

```
 x
 x x
 x o x
 x x x x
 x x x x x
```

The middle peg of the third row is empty. A legal move is a jump over one peg in one of the six different directions. The leapfrogged peg is removed from the board. So the board could look like this after one move:

```
 x
 x x
 x x x
 x o x x
 x o x x x
```

A solution is found when there is only one peg left, wherever it is located on the board. You get different results for different starting positions, see <a href="http://pegboardgame.blogspot.de/">Dan O’Briens Puzzle Solution Page</a>  for some more information on the topic.Given a Java class which can represent a position and which is capable to compute a list of all resulting positions after one move, the solver is a simple recursive function (<a href="http://blog.codecentric.de/files/2012/10/Puzzle.zip">source code as zip</a> ):<div>

```java5
 long countSolutions(Board start) {
 if (start.isSolution()) {
 return 1;
 } else {
 long count = 0;
 for (Board board : start.nextPositions()) {
 count += countSolutions(board);
 }
 return count;
 }
 }
```

</div>When you feed it with the start board with edge length five, it takes about a tenth of a second and you can see there are 1,550 solutions for n = 5. A tenth of a second is a short time, so why optimize? Let’s see bigger values, e.g. n = 6. Takes a little bit longer. Much longer. Not as long as to compute 42, but about 30  hours  resulting in 29,235,690,234 (now it should be obvious why <code>countSolutions()</code> returns a <code>long</code> and not an <code>int</code>).Why is there such a huge difference for a slightly larger board? Because the number of positions for a board of size n is 2^(n * (n+1)/2). The exponent is the number of holes/pegs on the board, which increases quadratically.<h1>Fork/Join</h1>When you know the Java Fork/Join framework (otherwise read the <a href="http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html">fork/join tutorial</a> ), you should see the perfect match: In each recursion level, you can fork a thread for the list of next positions. Here is the code, first the initialization of the pool and the code for starting the computation:<div>

```java5
 ForkJoinPool pool = new ForkJoinPool(numThreads);
 RecursiveSolver root = new RecursiveSolver(startBoard, sequential);
 solutions = pool.invoke(root);
```

</div>Then the implementing class:<div>

```java5
class RecursiveSolver extends RecursiveTask<Long> {
 private Board start;
 private int sequential;
 
 public RecursiveSolver(Board start, int sequential) {
 this.start = start;
 this.sequential = sequential;
 }
 
 @Override
 protected Long compute() {
 int card = start.cardinality();
 if (card == 1) {
 return Long.valueOf(1);
 } else if (card < sequential) {
 return Long.valueOf(countSolutions(start));
 } else {
 List<Board> nextPositions = start.nextPositions();
 List<Board> tasks = new ArrayList<>(nextPositions.size());
 for (Board b : nextPositions) {
 tasks.add(new RecursiveSolver(b, sequential));
 }
 invokeAll(tasks);
 long count = 0;
 for (RecursiveSolver rs : tasks) {
 count += rs.join();
 }
 return count;
 }
 return Long.valueOf(0);
 }
}
```

</div>The recursion of the sequential algorithm has been replaced by the creation of new instances of <code>RecursiveTask</code>. I introduced another optimization (as proposed in the fork/join tutorial): The parallel algorithm switches back to a sequential one when there are less than <code>sequential</code> pegs left. This avoids the overhead of task creation for small problems. After some experiments I used eight as threshold in my test runs.Starting this, my laptop (eight cores with hyperthreading, four real ones) was unusable for the next 7 hours and 28 minutes. Compared to the 30 hours of the sequential solver, a factor of four, which matches the number of “real” cores. So why bother? Four cores, four times faster than sequential, perfect speedup.But what about n = 7? How many solutions are there for a board with edge length seven? I didn’t run this on my laptop, neither sequential nor parallel. I assume it would exceed the lifetime of the poor machine. So let’s look for some other optimizations.<h1>Caching</h1>As in most board games, there is often more than one sequence of moves which result in the same position. An obvious optimization is to store the number of solutions for already computed positions in a <code>HashMap</code>. This is a well known technique called <a href="http://en.wikipedia.org/wiki/Transposition_table">transposition table</a> . As a precondition, the class <code>Board</code> has to implement <code>hashCode()</code> and <code>equals()</code>. For n = 5 this doesn’t make a big difference, we get the answer in 0.07 seconds, 70% of the time needed by the simple sequential solver. For n = 6 we get a more impressing effect, only 0.4 seconds elapse before we can see the result. That’s about 270,000 times faster compared to the sequential solver and even 67,500 times faster compared to the parallel solver running with four cores.This sounds very promising, so let’s try the next board size, n = 7. Starting this without any JVM options results in an <code>OutOfMemoryError</code>, the <code>HashMap</code> does not fit into the standard heap. Increasing the heap size with the well known <code>-Xmx</code> does not help on a 32 bit JVM: The memory needed does not fit into the 32 bit address space. The next step is to use the brute force approach: 64 bit JVM and the <code>-d64</code> option to activate the 64 bit mode.Stop!I like the <code>HashMap</code>, it’s is one of my favorite data structures and amazingly fast. But in this case there is a simpler, more efficient data structure, the good old array. A position in the game can be represented by some bits, for n = 7 you need 7*(7+1)/2=28 bits, which fits into an integer which can be used as the index of the array. The value in the array is the number of solutions for this position, -1 for positions which have not been evaluated so far. This still doesn’t fit into the 32 bit address space for n = 7, but is more efficient (in time and space) than the <code>HashMap</code> solution. For n = 6, we need only 0.2 seconds compared to the 0.4 seconds.When we have a 64 bit JVM, we can attack n = 7. But for one moment let’s assume we can’t afford the amount of memory and still want to solve the problem. When you add some debugging output to your code, you will find some strange behavior for n = 7: For n = 5 or n = 6 there are a lot of different solutions, usually the algorithms finds the first solutions quite fast. Not for n = 7. When I tried this first (some years ago, with C instead of Java on an old SUN workstation), the code found no solutions running several minutes. I had a strong suspicion: The triangle peg solitaire has no solution for n = 7. So I modified the code and used only one bit for each position: 0 = position not evaluated so far, 1 = position evaluated, no solution found.Last week, when I tried this again I was too lazy to use bits, instead I changed the array from <code>long</code> to <code>byte</code>, which was small enough to fit into the 32 bit address space. I could have used a Java <code>BitSet</code>, which saves even more space, but was too lazy. It confirmed what I already knew: There is no solution for n = 7, it took 34 seconds to compute this. Using the 64 bit JVM and <code>long</code> is a little bit slower: 37 seconds. I attribute the three seconds to worse cache locality.<h1>Parallelism Again</h1>We have seen two orthogonal ways to improve performance: Parallelism and caching. Is it possible to combine the approaches? Will this be even faster? Yes, we can combine them, but it becomes uglier. The sheer elegance of the fork join is based on its simplicity: We create new tasks, invoke them in a parallel fashion, wait for the result: You need no synchronized blocks or synchronized methods, every thread works on its own data. A global data structure like a <code>HashMap</code> or array destroys this simplicity, they both need some way of synchronization. But what is the granularity? Locking the complete array for each access? This causes two problems:<ol><li>Much of the parallelism will be destroyed because all threads compete for one resource.</li><li>It does not solve the problem of duplicate work: After one thread sees an unevaluated position and starts to evaluate it, another thread may evaluate the same position in parallel, wasting resources.</li></ol>So let’s try a more fine grained approach: Locking an entry for one position. Because we need an object as lock holder, we have to change the array of <code>long</code>s to an array of some sort of objects:<div>

```java5
class Value {
 public Value() {
 v = -1;
 }
 public long v;
}
```

</div>The rest of the code looks similar, but with a synchronized block:<div>

```java5
long countSolutions(Board start) {
 Integer startAsInt = Integer.valueOf(start.asInteger());
 Value value = cache[startAsInt];
 synchronized (value) {
 if (value.v != -1) {
 return value.v;
 } else if (start.isSolution()) {
 value.v = 1;
 return 1;
 } else {
 long count = 0;
 List nextPositions = start.nextPositions();
 for (Board board : nextPositions) {
 count += countSolutions(board);
 }
 value.v = count;
 return count;
 }
 } // synchronized
}
```

</div>With this approach, we have a separate lock for each position. A thread holds the lock until the evaluation of the position is complete. This avoids duplicate work by several threads, but limits parallelism. For this reason, you should start this algorithm with more threads than CPUs on your system.Unfortunately the overhead caused by the value object compared to the primitive data type and the synchronization is not compensated by the parallelism: For n = 6 we need 1 second, five times slower compared to the fastest sequential solution with the array of <code>long</code>s.<h1>Lessons Learned</h1>What can we learn from this experiment? Is there anything valuable learned here you can make use of when coding enterprise applications with boring/interesting (No)SQL-Databases as back end? For me it was the first time I used the Fork/Join framework, so I learned this :-). I was surprised, it’s quite easy. The load balancing and work stealing mechanisms seem to work good, the speedup compared to the sequential algorithm was as expected. This is definitively much easier comparing to create threads manually.The second lesson is about better algorithms. As we have seen, this can make a world of difference, not just a factor of four gained by parallelism. This is far more important than eliminating some function calls or saving a few cycles by replacing <code>double</code> with <code>float</code> or some other tricky programming. This is especially true for large problems, where – for example – the time complexity <code>n log(n)</code> of a good algorithm is much smaller than a time complexity <code>n^2</code> of a bad algorithm (hint: Sorting).The third lesson is simple: Don’t do the work at all. At least, don’t repeat it, use caching instead of repeated expensive operations. In this example, the expensive operation was the evaluation of identical branches in the tree. In enterprise applications, accessing the database usually takes most of the time. Given a good JPA provider or application server, you don’t have to implement the caching yourself, just plug in the cache recommended/supported by your provider/server and use the saved time to find a good set of configuration parameters.In other cases, you have to do some work yourself. But don’t implement everything, there are helping classes available. The <code>HashMap</code> or array used in this post are no real caches, they miss the feature of forgetting entries, so they will blow up your memory at some point. But the JDK has other classes which attack this problem: A <code>WeakHashMap</code> forgets entries automatically when the garbage collector is running, but you have no control when entries are removed or which entries are removed. So it is not recommended to implement a cache. To regain some sort of control, extend <code>LinkedHashMap</code> and override <code>removeEldestEntry()</code> (see javadoc for details). This gives you an LRU cache with just a few lines of code.When you want even more control, I recommend the <a href="http://code.google.com/p/guava-libraries/wiki/CachesExplained">Google Guava Cache</a> . It allows eviction on time base or on weight base with a user defined comparison function for the weight.Another important lesson not learned here is the proper use of a profiler. It can give you valuable information where your application spends all the time. For this simple example, it was clear without a profiler.<h1>Epilogue</h1>It may come as a surprise that there is no solution for n = 7. In fact, you can prove there is no solution for every <code>n</code> where <code>n modulo 3 = 1</code>. I will give a short sketch of the parity based proof.First let’s place numbers on the board according to the following two patterns:

```
 1 1
 1 0 0 1
 0[1]1 1[1]0
 1 1 0 1 1 0 1 1
 1 0 1 1 0 0 1 1 0 1
0 1 1 0 1 1 1 1 0 1 1 0
```

The field in brackets is the field with no peg at the start of a game. The parity is computed by adding all numbers of the fields with a peg and to apply modulo 2. For <code>n = 6</code> there is an even number of ones on the board. Because the empty field has a one, too, the parity of the start position is odd. If you look at the pattern in a row or on one of the diagonals, you see a repeated sequence of <code>1 1 0</code>. For every move in such a pattern, the parity stays the same.Obviously, when the parity of the start position is odd (which is true for the left and right pattern), it must be odd for every position in the game, including the end position. An odd parity with one peg is possible only if this peg is on a field marked with a one.If you record all end positions with one peg for <code>n = 5</code>, you se it’s always on the same place, which is marked with a one in both patterns:

```
 o
 o o
 o o o
 o o o o
o o x o o
```

For n = 6 there are several fields where the last peg may end. Note all these fields are marked with a one on both boards shown above:

```
 x
 o o
 o x o
 x o o x
 o o x o o
o x o o x o
```

When <code>n modulo 3 = 1</code>, the number of fields modulo three is one, too. If you extend the patterns shown above, you see there is always a one on the lower left and lower right corner. As a consequence, you have a number of <code>1 1 0</code> groups and one additional one. Together with the empty field in the start position located on a one, this results in an even parity for the start position. Even parity with one peg left implies the last peg has to end on a field marked with zero. But whenever a field is marked zero in the left pattern, it is marked with a one in the right pattern  (and vice versa). So there is no possible end position left for the last peg…Wouldn’t it be evil to sell this game with size <code>n = 7</code>? <img src="http://vg06.met.vgwort.de/na/6f1d341ba12044adb61d7581a194accd" alt width="1" height="1" />

Fork/Join and other Techniques to Improve Performance

Weitere Infos

Details

Sprich mich gern an

Komm zu unserer Konferenz, ich freue mich auf den Austausch mit dir! Hast du vorher schon Fragen?

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Ich habe die \nDatenschutzbestimmungen\n und die Einwilligung in die Datenverarbeitung gelesen und stimme diesen zu.*

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Kontakt

Absenden

APIs oder Event Broker – wie sollen meine Services kommunizieren?

Developer Week

Weitere Infos

Details

Sprich mich gern an

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten