Transformation

Selten sprechen zwei Systeme dasselbe Datenformat. In Gruppe 2 hat der Message Translator das Grundprinzip gezeigt: einen Übersetzer zwischen zwei Formate setzen. Diese Gruppe beschreibt spezielle Formen der Transformation. Die einen verändern die Hülle einer Nachricht, andere ergänzen oder kürzen den Inhalt, eines lagert große Daten aus, und die letzten beiden sorgen dafür, dass viele Systeme sich auf ein gemeinsames Format einigen.

• Anwendung
• Integrationskomponente
• Kanal
• Nachricht
• Datenbank / Speicher

• 41. Envelope Wrapper
• 42. Content Enricher
• 43. Content Filter
• 44. Claim Check
• 45. Normalizer
• 46. Canonical Data Model

41. Envelope Wrapper · Umschlag

Die Idee

Manche Transportwege verlangen ein bestimmtes äußeres Format: zusätzliche Header, eine Signatur, Verschlüsselung oder ein vorgeschriebenes Protokoll. Statt die eigentliche Nachricht dafür umzubauen, wird sie in einen äußeren Umschlag gepackt. Ein Wrapper verpackt sie vor dem Transport, ein Unwrapper packt sie danach wieder aus. Die Anwendungen an beiden Enden sehen nur die ursprüngliche Nachricht.

Beispiel

Ein Händler schickt Bestellungen über das Internet an einen Lieferanten. Der Lieferant verlangt, dass jede Nachricht verschlüsselt und signiert ist und einen Kopf mit Absenderkennung, Zeitstempel und Prüfsumme trägt. Der Wrapper erledigt das. Beim Lieferanten prüft der Unwrapper die Signatur, entschlüsselt und gibt die reine Bestellung weiter.

Worauf achten

Umschläge können verschachtelt sein, wie bei der Post: ein Brief im Umschlag, der in einem Postsack liegt, der in einem Container reist. Das Prinzip kennt jeder aus Netzwerkprotokollen, in denen jede Schicht die Daten der darüberliegenden Schicht einpackt. Wichtig ist, dass Wrapper und Unwrapper genau zueinander passen und der Unwrapper alle Angaben des Umschlags prüft, bevor er den Inhalt freigibt.

In der Praxis

SOAP-Envelopes mit WS-Security, das EDI-Protokoll AS2 mit signierten und verschlüsselten Nachrichten, der Standard CloudEvents als einheitlicher Umschlag um beliebige Ereignisdaten, und auf Netzwerkebene TCP/IP, bei dem jedes Paket schichtweise verpackt wird.

42. Content Enricher · Anreicherer

Die Idee

Oft enthält eine Nachricht nicht alles, was der Empfänger braucht, etwa nur eine Kundennummer statt der vollständigen Adresse. Der Content Enricher ergänzt die fehlenden Daten: Er nimmt die Nachricht, holt die zusätzlichen Informationen aus einer anderen Quelle, etwa einer Datenbank, einem Dienst oder einer Konfiguration, und schickt die angereicherte Nachricht weiter.

Beispiel

Der Shop kennt nur die Kundennummer 815. Der Versanddienstleister braucht aber die vollständige Lieferadresse. Der Content Enricher fragt mit der Nummer beim CRM nach, ergänzt Name und Adresse und gibt die vollständige Nachricht an den Versand weiter. Weder Shop noch Versand müssen das CRM kennen.

Worauf achten

Der Enricher ist von seiner Datenquelle abhängig: Ist das CRM langsam oder nicht erreichbar, staut sich alles. Häufig abgefragte, selten geänderte Daten lassen sich zwischenspeichern. Außerdem sollte man abwägen, ob der Sender die Daten nicht gleich mitschicken kann. Der Enricher lohnt sich vor allem, wenn der Sender die Daten gar nicht hat oder wenn verschiedene Empfänger verschiedene Ergänzungen brauchen.

In der Praxis

enrich() und pollEnrich() in Camel, ContentEnricher bzw. enrichHeaders() in Spring Integration, in Kafka Streams ein Join eines Ereignisstroms mit einer Tabelle, etwa Bestellungen mit Kundenstammdaten.

43. Content Filter · Inhaltsfilter

Die Idee

Der Content Filter ist das Gegenstück zum Content Enricher: Er entfernt Daten, die der Empfänger nicht braucht. Übrig bleibt eine schlankere Nachricht mit genau den Feldern, auf die es ankommt. Wichtig ist der Unterschied zum Message Filter aus Gruppe 5: Der Message Filter entscheidet über ganze Nachrichten, der Content Filter kürzt den Inhalt einer Nachricht.

Beispiel

Das CRM verschickt vollständige Kundendatensätze mit Geburtsdatum, Bankverbindung, Umsatz und internen Notizen. Der Newsletter-Dienst braucht nur Name und E-Mail-Adresse. Ein Content Filter entfernt alles andere, bevor die Daten den Newsletter-Dienst erreichen, der vielleicht sogar bei einem externen Anbieter läuft.

Worauf achten

Es gibt drei Gründe für einen Content Filter: Datenschutz (Empfänger sollen nur sehen, was sie sehen dürfen, ganz im Sinne der Datensparsamkeit), Effizienz (kleinere Nachrichten, weniger Netzlast) und Vereinfachung (eine verschachtelte Struktur wird flach gemacht, damit der Empfänger es leichter hat). Sicherer ist es, die gewünschten Felder ausdrücklich zu übernehmen, statt die unerwünschten zu entfernen. So rutscht ein neu hinzugekommenes vertrauliches Feld nicht versehentlich durch.

In der Praxis

In Camel mit transform() oder JSONPath bzw. XPath, in Spring Integration mit einem @Transformer, in Kafka Connect mit der Single Message Transform ReplaceField, die Felder ein- oder ausschließen kann. In Java genügt oft ein Record mit genau den gewünschten Feldern.

44. Claim Check · Gepäckschein

Die Idee

Große Datenmengen wie Bilder, Videos oder umfangreiche Dokumente belasten ein Messaging-System, und viele Broker haben eine Größengrenze pro Nachricht. Beim Claim Check werden die Nutzdaten deshalb in einem Speicher abgelegt, und durch den Kanal reist nur ein kleiner Beleg, ein Schlüssel, mit dem der Empfänger die Daten später abholen kann. Wie die Gepäckaufbewahrung am Bahnhof: Den Koffer gibt man ab, mit sich trägt man nur den Zettel.

Beispiel

Ein Fotostudio liefert neue Produktbilder an den Shop, 40 MB pro Artikel. Statt die Bilder durch den Broker zu schicken, legt das Fotostudio sie in einem Objektspeicher ab und verschickt nur eine Nachricht mit Artikelnummer und Beleg A7F3. Der Shop holt die Bilder mit diesem Beleg ab, sobald er sie braucht.

Worauf achten

Der Claim Check entlastet den Broker, schafft aber neue Fragen: Wer räumt den Speicher auf, und wann? Was passiert, wenn der Empfänger die Daten nie abholt oder mehrere Empfänger sie brauchen? Und wer darf mit dem Beleg zugreifen? Daneben eignet sich das Muster auch für sensible Daten: Die Nachricht durchläuft viele Stationen, die Daten selbst bleiben in einem geschützten Speicher und werden nur vom berechtigten Empfänger abgeholt. Sinnvoll ist es, in der Nachricht zusätzlich die Merkmale mitzuschicken, nach denen geroutet wird, damit Zwischenstationen nicht abholen müssen.

In der Praxis

claimCheck() in Camel, Objektspeicher wie Amazon S3 oder Azure Blob Storage mit einer Nachricht, die nur die URL enthält, die Azure Service Bus Claim-Check-Erweiterung. Der Gedanke steckt auch in vorsignierten Download-Links, die per E-Mail statt eines großen Anhangs verschickt werden.

45. Normalizer · Vereinheitlicher

Die Idee

Kommen gleichartige Nachrichten aus verschiedenen Quellen in verschiedenen Formaten, bringt der Normalizer sie in ein einheitliches Format. Er ist ein zusammengesetztes Muster: Ein Router erkennt das Eingangsformat, und für jedes Format gibt es einen eigenen Message Translator. Hinter dem Normalizer gibt es nur noch ein Format.

Beispiel

Drei Lieferanten schicken ihre Preislisten: der eine als CSV, der zweite als XML, der dritte als JSON, jeder mit eigenen Feldnamen. Der Einkauf soll nicht drei Formate verstehen müssen. Der Normalizer erkennt das Format, etwa am Absender, an der Dateiendung oder an einem Format Indicator (Gruppe 4), und schickt jede Liste durch den passenden Übersetzer. Der Einkauf erhält alle Preislisten im selben Format.

Worauf achten

Die Formaterkennung ist der heikle Teil. Am zuverlässigsten ist ein ausdrückliches Kennzeichen in der Nachricht. Am unzuverlässigsten ist es, das Format aus dem Inhalt zu erraten. Jeder neue Lieferant mit eigenem Format bedeutet einen neuen Übersetzer. Das bleibt aber an einer Stelle, statt sich auf jeden Empfänger zu verteilen. Welches Format das Zielformat ist, regelt im Idealfall das Canonical Data Model (Muster 46).

In der Praxis

Daten-Importstrecken im Handel und in der Logistik, die Lieferungen vieler Partner zusammenführen, ETL-Prozesse in Data Warehouses, Log-Sammler wie Logstash oder Fluentd, die Logs aus verschiedenen Quellen in ein gemeinsames Format bringen.

46. Canonical Data Model · Kanonisches Datenmodell

Die Idee

Spricht jede Anwendung ihr eigenes Datenformat, braucht man zwischen jedem Paar einen eigenen Übersetzer. Das Canonical Data Model legt stattdessen ein gemeinsames, anwendungsunabhängiges Datenmodell fest. Jede Anwendung übersetzt nur noch in dieses Standardmodell hinein und aus ihm heraus. Wie Englisch als gemeinsame Verkehrssprache: Statt dass jeder jede Sprache lernt, lernt jeder nur eine zusätzliche.

Beispiel

Shop, Lager, CRM und ERP haben jeweils ihre eigene Vorstellung von einem „Kunden“, mit anderen Feldnamen, Formaten und Codes. Das Unternehmen definiert einen Standard-Kunden mit festgelegten Feldern. Jede Anwendung bekommt einen Übersetzer in das Standardmodell und einen zurück. Kommt eine fünfte Anwendung hinzu, braucht sie nur zwei neue Übersetzer statt acht.

Worauf achten

Die Rechnung ist eindeutig: Bei n Anwendungen braucht man ohne Standardmodell bis zu n·(n−1) Übersetzer, mit Standardmodell nur 2·n. Bei zehn Anwendungen sind das 90 gegen 20. Der Aufwand verschiebt sich aber in die Abstimmung: Ein Modell zu finden, auf das sich alle Abteilungen einigen, ist schwierig, und ein Modell, das alles für alle abbilden will, wird groß und unhandlich. Das Domain-Driven Design rät deshalb oft zu mehreren kleineren Modellen für abgegrenzte Bereiche statt einem einzigen für das ganze Unternehmen. Außerdem muss das Standardmodell versioniert werden, damit Änderungen nicht alle Anwendungen auf einmal treffen.

In der Praxis

Branchenstandards wie EDIFACT im Handel, HL7 und FHIR im Gesundheitswesen oder ISO 20022 im Zahlungsverkehr, unternehmensweite Schemata in einer Schema Registry für Kafka, und das gemeinsame Datenformat eines Message Bus (Gruppe 3).

Die Transformationsmuster im Überblick