Überblick
Transformationen passen die Struktur ausgehender Datenpakete an die Anforderungen von Drittsystemen an — etwa für Abrechnung, Energiemanagement oder nachgelagerte APIs. Sie werden im Integrationsflow als Schritt zwischen Filter und ausgehendem Konnektor eingesetzt; zu Datenfluss und Auslösern siehe dort.
Eingehende Datenpakete werden nicht im Integrationsflow transformiert, sondern über das Transformations-Template im eingehenden Konnektor. Details dazu sind im Kapitel Konnektoren im Abschnitt Eingehende Konnektoren beschrieben.
Datenmodell und Beispiel-Payloads
Die Eingabe für eine Transformation ist typischerweise ein JSON-Objekt mit den Feldern meta und value. Welche Felder in meta gesetzt sind, hängt vom Auslöser des Integrationsflows und vom Datenpunkt ab.
Vollständige Beispiel-Payloads und Felderklärungen finden sich im Kapitel Integrationsflows:
| Kontext | Abschnitt |
|---|---|
Daten nach Konnektor und Gerätetreiber, vor Zuweisung an Virtuelles Gerät oder Digitalen Zwilling (dtwin_id u. a. fehlen) |
Erläuterung des BEFORE STATE-HANDLING-Objektes |
| Standardpaket nach Datenpunkt-Update (Virtuelles Gerät oder Digitaler Zwilling) | Erläuterung des „After state handling“-Objektes |
| Alarmprotokolleintrag erstellt oder aufgelöst | Alarmlog was created/resolved Objekt |
Diese Beispiele können als Beispiel-Eingabe im Transformations-Editor übernommen oder angepasst werden (siehe Transformation im UI testen).
Zugriff & Navigation
Unter Integrationen > Transformationen lassen sich Transformationen anlegen und bearbeiten. Beim Anlegen oder Bearbeiten stehen zwei Reiter zur Verfügung:
- Metadaten — Name, Konto, Beschreibung
- Transformation — Ausgabeformat, Transformationstyp, Editor, Testbereich und Schnellreferenz

Konfiguration
- Name: Eindeutiger Name der Transformation.
- Konto: Konto, für das die Transformation gilt (bei neuen Einträgen nach dem Anlegen nicht mehr änderbar).
- Beschreibung: Optionale Zusatzinformationen.
- Ausgabeformat: Gewünschtes Format der transformierten Ausgabe, passend zum ausgehenden Konnektor bzw. Zielsystem — z. B.
application/json,text/plainodergeneric(siehe auch den Hinweis zu JSON undgenericim Integrationsflow-Kapitel). - Typ der Transformation:
- JSONata — Ausdruck gegen das gesamte Eingabeobjekt (Root), Zugriff z. B. mit
$.meta…und$.value. - JavaScript — Funktionsrumpf: Der Editor enthält nur den Code innerhalb der Funktion; die Plattform umschließt ihn zu einer Funktion
module.exports = (x) => { … }. Das Argumentxist das Eingabeobjekt (meta/value). Es muss ein Rückgabewert geliefert werden, der der neuen Nutzlast entspricht (siehe nächster Abschnitt).
- JSONata — Ausdruck gegen das gesamte Eingabeobjekt (Root), Zugriff z. B. mit
Verhalten im Integrationsflow: Das Ergebnis der Transformation ersetzt den bisherigen Inhalt von value im Payload; meta wird vom System weitergeführt, soweit zutreffend. Entsprechend sollte die Transformation genau die Struktur liefern, die das Zielsystem in value erwartet.
JSONata- und JavaScript-Transformation
Die folgenden Beispiele beziehen sich auf typische AFTER STATE HANDLING-Pakete (mit dtwin_id in meta). Für BEFORE STATE-HANDLING oder ALARMLOG-Auslöser die Felder an die jeweiligen Objekte aus den verlinkten Abschnitten anpassen.
JSONata
Ausdruck liefert das neue Wertobjekt. Beispiel: Messwert und ausgewählte Metadaten für ein schlankes JSON-Zielformat:
{
"timestamp": $.meta.timestamp,
"deviceId": $.meta.dtwin_id,
"deviceTitle": $.meta.dtwin_title,
"reading": $.value
}
JavaScript
Es wird nur der Funktionsrumpf eingetragen (der Code innerhalb von (x) => { … }). Die Oberfläche setzt module.exports = (x) => { und die schließende Klammer; eine eigene module.exports-Deklaration ist nicht nötig. Beispiel:
return {
ts: x.meta.timestamp,
twin: x.meta.dtwin_id,
tags: x.meta.twin_tags,
v: x.value
};
Bedingung und abweichendes Format:
if (x.meta.state_type === "number" && x.value > 100) {
return { alert: true, value: x.value, unit: x.meta.unit };
}
return { alert: false, value: x.value };
Transformation im UI testen und Schnellreferenz
Auf dem Reiter Transformation sind drei Bereiche nummeriert:
- Ausgabeformat definieren — Ausgabeformat wählen (Voraussetzung für den Test).
- Transformation schreiben — JSONata- oder JavaScript-Code bearbeiten.
- Transformation testen — Im Feld Beispiel Eingabe gültiges JSON einfügen (z. B. aus den Integrationsflows-Beispielen). Mit dem „Transformer testen“-Button wird die Transformation serverseitig ausgeführt; das Ergebnis erscheint unter Ausgabe nach Transformation.
Ohne gültige Beispieldaten, ohne gewähltes Konto oder ohne Ausgabeformat ist der Test deaktiviert; beim Überfahren des Buttons zeigt ein Hinweis das jeweils fehlende Feld an.
Schnellreferenz: Unterhalb des Editors befindet sich ein aufklappbarer Bereich „Schnellreferenz (Metawerte und Beispiel)“. Dort sind die typischerweise verfügbaren Meta-Attribute aufgelistet (einschließlich Hinweis, dass einige Felder nur nach Zuweisung an Virtuelles Gerät oder Digitalen Zwilling vorkommen, vergleichbar AFTER STATE HANDLING). Außerdem enthält die Schnellreferenz ein kompaktes JSONata-Beispiel: Original-Payload, Transformationsausdruck und erwartete Ausgabe — analog zur Darstellung in der Oberfläche.
Platzhalter in URLs oder Topics von Webhook- und MQTT-Konnektoren (z. B. {{dtwin_id}}) beziehen sich auf dieselbe Metadatenmenge; die Schnellreferenz im Transformations-Editor dient dabei als Übersicht. Details stehen bei den jeweiligen Konnektoren und im Integrationsflow-Kapitel.
Verwandte Seiten
- Integrationsflows — Auslöser, Datenobjekte, Konnektor-Schritt
- Konnektoren — eingehende und ausgehende Konnektoren
- Filter — JSONata/JavaScript-Filter in der Kette