Mulesoft Meetup v8 – Loops, Container und Pizza

Bereits zum achten Mal fand sich am 28. November unsere Mulesoft Meetup Community zu einem gemeinsamen Abend in Solingen zusammen. Neben alteingesessenen Mule-Meetup-Enthusiasten konnten wir uns auch dieses Mal wieder über neue Gesichter in unserer Runde freuen. Und da nicht jeder die Zeit hatte bei uns zu sein, fassen wir den Abend hier noch einmal für euch zusammen.

⁠Die Themen

Wie immer startete der  Abend mit Vorträgen zu verschiedenen Themen. Im Rampenlicht standen dabei dieses Mal die codecentric-Kollegen Roger Butenuth, der etwas über Mule-Loop-Prozessoren und sein selbstentwickeltes Loop-Modul erzählte, und Benjamin Lüdicke, der uns in die Welt der Testcontainer im Zusammenhang mit Mule entführte.

⁠Loops – da kann einem schwindelig werden

Im ersten Vortrag des Abends zeigte Roger sein selbst entwickeltes Loop-Modul (GitHub) für Mule4, das fehlende Features der Mulesoft-eigenen Loop-Prozessoren ergänzt.

Dem for-Loop fehlt dabei die Möglichkeit, sich Ergebnisse aus verschiedenen Iterationen effektiv merken zu können. Möchte man zum Beispiel in jedem Schleifendurchlauf das Ergebnis am Ende behalten, bleibt in erster Linie die Möglichkeit, vor dem for-Loop eine leere Liste zu erstellen und diese dann am Ende jedes Durchlaufs mit dem aktuellen Wert zu erweitern. „Erweitern“ ist dabei relativ, da diese Liste immutable ist und somit bei jedem „Erweitern“ eine neue Liste erzeugt wird. Da es sich dabei um eine exponentielle Komplexität handelt, wird dies spätestens bei größeren Datenmengen ineffizient.

Dieses Problem kann man zwar mit dem parallel-for-Loop umgehen, der einem die Möglichkeit bietet, den Payload nach jeder Iteration zu sammeln. (Dabei können wir bei Bedarf durch das Setzen der Concurrency auf „1“ einen sequentiellen Loop vortäuschen.) Dieser speichert jedoch das komplette Event-Objekt, was ebenfalls je nach Menge der Datensätze und Größe der existierenden Payloads, Variablen und Attribute zu einem größeren Speicherverbrauch führen kann als eigentlich notwendig wäre.

Und genau an dieser Stelle kommt Rogers eigenes Loop-Modul ins Spiel, das die Möglichkeit bietet, auf effiziente Art und Weise den Payload aus Iterationen zu speichern. Zusätzlich enthält sein Modul einen While-Loop, der ebenfalls bei den Bordmitteln von Mule nicht vorhanden ist und nur über Umwege abgebildet werden kann.

Testcontainer – der Realität ein Stück näher

Im Anschluss gab uns Benjamin einen Einblick in die Welt der Testcontainer und zeigte, wie man diese in Mule nutzen kann. Entstanden ist das Thema dabei, als er bei einem Kunden ein Statement gegen eine Memory-basierte H2-Datenbank testen wollte, die Query (die gegen eine echte Datenbank problemlos funktioniert hat) von der H2-Datenbank jedoch nicht korrekt aufgelöst werden konnte.

An dieser Stelle kommen Testcontainer ins Spiel, die einem – einmal gestartet – die Möglichkeit bieten, gegen realistische Systeme zu testen. In seinem Fall wurde dabei mithilfe eines von ihm entwickelten Skripts vor einem MUnit-Test automatisch ein Postgres-Testcontainer gestartet, mit vordefinierten Daten gefüllt und anschließend die gewünschten Tests gegen diese Datenbank ausgeführt.

Die Testcontainer-Community bietet dabei eine Vielzahl von Containern, sodass prinzipiell alle handelsüblichen Systeme abgebildet werden können.

Auch das Projekt von Benjamin kann auf GitHub gefunden werden und relativ einfach an die eigenen Bedürfnisse angepasst werden.

Das Networking

Der Abend endete traditionsgemäß mit Pizza und Getränken, und alle Teilnehmer hatten in einer entspannten Atmosphäre die Gelegenheit, sich über verschiedene Themen auszutauschen. Wir hoffen, dass der Abend allen Teilnehmern gefallen hat.

Und wie immer: Nach dem Meetup ist vor dem Meetup. Auch im kommenden Jahr würden wir uns freuen, alle Teilnehmer erneut begrüßen zu dürfen – und vielleicht hat ja der oder die Eine oder Andere beim Lesen auch Lust bekommen, beim nächsten Mal selbst dabei zu sein.