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

Keine Kommentare

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:

  • Properties oder Inhalt lassen sich durch die Mule Expression Language (MEL) berechnen.
  • XML lässt sich mit Xslt transformieren.
  • 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).
  • Java-Components oder Java-Transformer bieten sich an, wenn es mal komplexer wird oder man existierenden Transformationscode wiederverwenden möchte.
  • Maus-Schubser nutzen den grafisch konfigurierbaren DataMapper um zwischen XML, Json, CSV und Pojos zu transformieren.

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.

Beispiel

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:

Einfaches Beispiel im DataWeave-Editor vom AnypointStudio

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:

Beispieldaten, Transformationsvorschrift und zugehörige Ausgabedaten.

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.

Anypoint kennt die Message

Kennt Mule das Format der Ausgabedaten (Stichwort DataSense, siehe Blogpost 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.

Roger Butenuth

Dr. Roger Butenuth hat in Karlsruhe Informatik studiert und anschließend in Paderborn promoviert (Kommunikation in Parallelrechnern). Er hat langjährige Erfahrung in der Projekt- und Produktentwicklung.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.