Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Manchmal enthält die eingehende Nachricht nicht alles, was Sie benötigen. Ein Temperaturmesswert kann mit einer Geräte-ID übermittelt werden, aber der Anzeigename, der Standort und der Kalibrierungs-Offset befinden sich in einer separaten Nachschlagetabelle. Durch Anreicherung können Sie diese externen Daten in Ihre Transformationsregeln ziehen.
Eine Übersicht über Datenflussdiagramme finden Sie in der Übersicht über Datenflussdiagramme.
Transformationen verwenden eine Ausdruckssprache, um Werte, Testbedingungen und Referenzfelder zu berechnen. Ausdrücke beziehen sich auf Eingaben nach Position, nicht nach Namen: Die erste Eingabe in der inputs Liste ist $1, die zweite ist $2, und so weiter. Integrierte Funktionen wie cToF konvertieren und bearbeiten diese Werte.
Für die vollständige Liste der Operatoren, Funktionen, Datentypen und Metadatenfelder siehe die Expressions-Referenz.
Enrichment ist optional und eine separate Funktion, getrennt von den Datensätzen, die für ein Asset definiert werden können. In Datenflussgraphen bedeutet ein Datensatz immer einen Kontextualisierungsdatensatz, der aus dem Zustandsspeicher gelesen wird. Wenn Ihre Nachrichten bereits die benötigten Felder enthalten, müssen Sie Datensätze überhaupt nicht konfigurieren.
Enrichment funktioniert mit Map-, Filter- und Branch-Transformationen sowie mit Trigger-Regeln in Fenstertransformationen ab Version 1.1.
Voraussetzungen
- Eine Instanz von Azure IoT Einsatz, die in einem Kubernetes-Cluster bereitgestellt wird. Weitere Informationen finden Sie unter Deploy Azure IoT Einsatz.
- Die Bereitstellung erstellt automatisch einen Standard-Registry-Endpunkt namens
default, der aufmcr.microsoft.comverweist.
Die Azure CLI Beispiele in diesem Artikel verwenden Umgebungsvariablen, sodass Sie jeden Wert einmal festlegen und dann die Befehle as-iskopieren und einfügen können. Wenn Sie die Azure IoT Einsatz Codespaces-Umgebung aus dem Quickstart verwenden, sind diese Variablen bereits für Sie festgelegt und Sie können diesen Schritt überspringen. Ansonsten setze die folgenden Umgebungsvariablen in deiner Shell, bevor du die Befehle ausführst.
Die folgenden Skripte legen die am häufigsten verwendeten Umweltvariablen fest:
| Umgebungsvariable | Beschreibung |
|---|---|
SUBSCRIPTION_ID |
Die ID des Abonnements, das Ihre Azure IoT Einsatz-Instanz enthält. |
RESOURCE_GROUP |
Der Name der Ressourcengruppe, die Ihre Azure IoT Einsatz-Instanz enthält. |
AIO_INSTANCE_NAME |
Der Name Ihrer Azure IoT Einsatz Instanz. Um deine Instanzen aufzulisten, führe az iot ops list -o table. |
CLUSTER_NAME |
Der Name des Azure Arc-fähigen Kubernetes-Clusters, der deine Instanz hostet. |
LOCATION |
Die Azure-Region zur Nutzung für neue Ressourcen, zum Beispiel eastus. |
SUBSCRIPTION_ID=<subscription-id>
RESOURCE_GROUP=<resource-group-name>
AIO_INSTANCE_NAME=<instance-name>
CLUSTER_NAME=<cluster-name>
LOCATION=<region>
Du musst nur die Variablen festlegen, die dieser Artikel verwendet. Dieser Artikel könnte zusätzliche Umgebungsvariablen für die von Ihnen gewählten Ressourcennamen verwenden. Der Artikel erklärt, wie man sie dort platziert, wo sie eingeführt werden.
Einrichten des Statusspeichers
Die Laufzeit liest Datensätze aus dem verteilten Zustandsspeicher von Azure IoT Einsatz. Jeder Datasetschlüssel wird einem oder mehreren Datensätzen im NDJSON-Format (ein JSON-Objekt pro Zeile) zugeordnet. Die Laufzeit speichert Datensätze und erhält Änderungsbenachrichtigungen, sodass während der Verarbeitung Zustandstore-Aktualisierungen wirksam werden.
Informationen zum Konfigurieren des verteilten Zustandsspeichers finden Sie in der Übersicht über den Zustandsspeicher.
Den Schlüssel des Statusspeichers füllen
Der staatliche Laden ist nicht vorbevölkert. Schreibe Datensatzdatensätze über MQTT mit dem SET Befehl des State Store darauf. Für den später in diesem Artikel konfigurierten device-metadata as device Datensatz veröffentlichen Sie die folgende Anfrage, zwei NDJSON-Datensätze (einer pro Zeile) unter dem device-metadata Schlüssel zu seeden. Fügen Sie jedes Feld ein, das von Regeln referenziert wird, die diesen Datensatz verwenden, einschließlich location. Das Beispiel "Deploy a Data Flow with Enrichment" wird später in diesem Artikel verwendet location . Andernfalls löst sich das Feld für jede Nachricht auf null :
mosquitto_pub -h <BROKER_HOST> -p <BROKER_PORT> -V mqttv5 -q 1 \
-t 'statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke' \
-D publish response-topic 'clients/dataflow-docs-client/services/statestore/_any_/command/invoke/response' \
-D publish correlation-data '1' \
-D publish user-property __ts "$(date +%s%3N):0:dataflow-docs-client" \
-m $'*3\r\n$3\r\nSET\r\n$15\r\ndevice-metadata\r\n$153\r\n{"deviceId":"dev-001","displayName":"Line 1 Sensor","location":"Building A"}\n{"deviceId":"dev-002","displayName":"Line 2 Sensor","location":"Building B"}\r\n'
Die Werte $15 und $153 sind die Byte-Längen des nachfolgenden Schlüssels (device-metadata) und Werts. Ein erfolgreiches SET antwortet mit +OK im Antwortthema. Für das vollständige Anforderungsformat, erforderliche MQTT v5-Eigenschaften und Antwortcodes siehe die Zustandsspeicher-Protokollreferenz.
Konfigurieren eines Datasets
Definiere Datensätze im datasets Array auf der obersten Ebene deiner Regelkonfiguration für map, filter, und branch Transformationen.
Für Fenstertransformationen (Version 1.1 oder neuer) konfigurieren Sie Datensätze innerhalb der Konfiguration triggers . Details finden Sie unter Aggregierte Daten mit Fenstertransformationen in Datenflussdiagrammen.
Fügen Sie in der Transformationskonfiguration ein Dataset hinzu. Konfigurieren:
| Setting | Beschreibung |
|---|---|
| Statusspeicherschlüssel | Der Schlüssel, auf dem Datensätze gespeichert werden. Verwenden Sie as, um einen Alias zuzuweisen (zum Beispiel device-metadata as device). |
| Eingaben abgleichen | Zu vergleichende Felder: eine aus der Quellnachricht ($source.<field>) und eine aus dem Dataset ($context.<field>). |
| Übereinstimmungsausdruck | Ein boolescher Ausdruck (z. B $1 == $2. ). |
Jeder Dataseteintrag weist folgende Eigenschaften auf:
| Eigentum | Erforderlich | Beschreibung |
|---|---|---|
key |
Ja | Der Zustandsspeicherschlüssel, in dem die Datasetdatensätze gespeichert werden. Unterstützt einen optionalen Alias mit dem as Schlüsselwort. Um diesen Schlüssel auszufüllen, veröffentlichen Sie eine SET Anfrage über MQTT (siehe Füllen des Zustandsspeicherschlüssels). |
dynamicValues |
No | Liste der Nachrichtenfeldpfade, die in $N Platzhalter in keyersetzt werden, sodass die Laufzeit den Zustandsspeicherschlüssel für jede Nachricht ableiten kann. Siehe Dynamische Tasten. |
inputs |
Ja | Liste der Feldverweise, die im Übereinstimmungsausdruck verwendet werden. Jeder Eintrag verwendet ein $source.- oder $context.-Präfix. |
expression |
Ja | Ein boolescher Ausdruck, der bestimmt, welcher Datasetdatensatz der eingehenden Nachricht entspricht. |
Schlüssel und Alias
Der key Wert ist der Zustandsspeicherschlüssel, den die Laufzeit liest. Geben Sie mit dem Schlüsselwort as einen kürzeren Alias zu. Beispielsweise können Sie mit datasets.parag10.rule42 as position auf Felder als $context(position).WorkingHours verweisen.
Ein Schlüssel kann auch eine Vorlage sein, die die Laufzeit für jede Nachricht separat auflöst. Weitere Informationen finden Sie unter Dynamische Tasten.
Dynamische Tasten
Ein statisches key Signal funktioniert gut, wenn du jede Nachricht aus demselben Zustandsspeicher-Datensatz anreicherst. Aber manchmal braucht jede Nachricht einen anderen Datensatz. Zum Beispiel hängt bei Kalibrierungsdaten pro Gerät der zu suchende Datensatz von einem Feld in der eingehenden Nachricht ab.
Anstatt für jeden möglichen Lookup-Wert einen separaten Datensatz (und einen separaten Graphen) bereitzustellen, machen Sie key zu einer Vorlage mit Platzhaltern wie $1, $2 usw. Füge eine dynamicValues Eigenschaft hinzu, die das Nachrichtenfeld auflistet, das für jeden Platzhalter eingesetzt werden soll. Die Laufzeit löst die Vorlage für jede Nachricht auf, bevor sie den Zustandsspeicher abfragt.
Tip
Verknüpfen Sie ein dynamisches Element key mithilfe von as mit einem Alias. Der Alias, nicht der Resolved-Schlüssel, ist der feste Name, den du in den Regeln als $context(<alias>).<field>referenzierst. Behalten Sie das Alias als stabile Kennung, auch wenn sich der zugrunde liegende Schlüssel pro Nachricht ändert.
Voraussetzung: Fülle einen dynamischen Zustandsspeicherschlüssel aus
Da der aufgelöste Schlüssel datengetrieben ist, musst du den State-Store mit einem Datensatz für jeden aufgelösten Wert füllen, den du nachschlagen möchtest. Im Beispiel im folgenden Abschnitt sucht die Laufzeit für eine Nachricht mit sensorId: "TEMP-42", also wird calibration:TEMP-42eine SET Anfrage für genau diesen Schlüssel veröffentlicht. Der Datensatz muss jedes Feld enthalten, das vom Datensatz übereinstimmt inputs (hier sensorId, verglichen mit der eingehenden Nachricht $source.sensorId), zusätzlich zu allen Feldern, mit denen die Regeln bereichern, wie z. offsetB. . Andernfalls gelingt das Match nie und die Anreicherungsfelder bleiben nicht verfügbar:
mosquitto_pub -h <BROKER_HOST> -p <BROKER_PORT> -V mqttv5 -q 1 \
-t 'statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke' \
-D publish response-topic 'clients/dataflow-docs-client/services/statestore/_any_/command/invoke/response' \
-D publish correlation-data '1' \
-D publish user-property __ts "$(date +%s%3N):0:dataflow-docs-client" \
-m $'*3\r\n$3\r\nSET\r\n$19\r\ncalibration:TEMP-42\r\n$33\r\n{"sensorId":"TEMP-42","offset":5}\r\n'
Die Werte $19 und $33 sind die Byte-Längen des nachfolgenden Schlüssels (calibration:TEMP-42) und Werts. Ein erfolgreiches SET antwortet mit +OK im Antwortthema. Für das vollständige Anforderungsformat, erforderliche MQTT v5-Eigenschaften und Antwortcodes siehe die Zustandsspeicher-Protokollreferenz.
Konfigurieren Sie einen Datensatz mit dynamischen Werten
In der Transformationskonfiguration fügen Sie einen Datensatz hinzu und konfigurieren:
| Setting | Beschreibung |
|---|---|
| Statusspeicherschlüssel | Eine Vorlage wie calibration:$1 as calibration, wobei ein Nachrichtenfeld zur Verarbeitungszeit ersetzt $1 wird. Um den aufgelösten Schlüssel zu füllen, veröffentlichen Sie eine SET Anfrage über MQTT (siehe Einen dynamischen Zustandsspeicherschlüssel ausfüllen). |
| Dynamische Werte | Das Nachrichtenfeld, das für jeden Platzhalter ersetzt werden soll, in der Reihenfolge (zum Beispiel sensorId). |
| Übereinstimmende Eingaben / Übereinstimmungsausdruck | Konfigurieren Sie es auf die gleiche Weise wie bei einem statischen Schlüssel-Datensatz. |
Für eine Nachricht mit sensorId: "TEMP-42" löst die Runtime vor der Abfrage des Zustandsspeichers die Vorlage zu calibration:TEMP-42 auf. Das offset-Feld des zugeordneten Datensatzes ist als $context(calibration).offset verfügbar.
Standardwerte für fehlende Felder
Jeder Eintrag in dynamicValues kann einen ?? Standardeintrag enthalten, der verwendet wird, wenn das Nachrichtenfeld fehlt oder null. Ohne einen Standardwert schlägt die Verarbeitung dieser Nachricht fehl, wenn ein Feld fehlt oder null ist.
{
"key": "calibration:$1 as calibration",
"dynamicValues": ["sensorId ?? \"unknown\""]
}
Literalen $ mit Escapezeichen versehen
Wenn die Schlüssel des Zustandsspeichers in Ihrem System bereits ein literales $-Zeichen enthalten, versehen Sie es in der Vorlage wie folgt mit dem Escapezeichen: $$. Nur $N (a $ gefolgt von Ziffern) wird als Platzhalter behandelt.
$$ ergibt immer ein einziges Literal $.
{
"key": "rate:$$USD:$1",
"dynamicValues": ["region ?? \"us\""]
}
Für eine Nachricht mit region: "eu" wird dies zu rate:$USD:eu.
Zusammengesetzte Schlüssel
Eine Vorlage kann auf mehr als ein Nachrichtenfeld verweisen. Jedes $N wird in der Reihenfolge dem entsprechenden Eintrag in dynamicValues zugeordnet:
{
"key": "line:$1:station:$2 as lineStatus",
"dynamicValues": ["lineId ?? \"unknown\"", "stationId ?? \"0\""]
}
Für eine Nachricht mit lineId: "L-3" und stationId: "7", löst sich dies auf line:L-3:station:7.
Note
Es können nur Zeichenketten-, Zahlen- und boolesche Nachrichtenfelder in einen Schlüssel eingefügt werden. Objekt- und Arrayfelder werden nicht als dynamische Schlüsselwerte unterstützt. Die Verwendung eines führt zu einem Fehler, wenn die Nachricht verarbeitet wird.
Von Bedeutung
Die folgenden Fehler werden überprüft, wenn der Graph angewendet wird, nicht wenn Nachrichten verarbeitet werden:
- Ein Platzhalter, dessen Index
$Ngrößer ist als die Anzahl der Einträge indynamicValues. - Eine
dynamicValues-Liste, die aufkeykonfiguriert ist, die keinen$N-Platzhalter ohne Escapezeichen enthält. - Ein fehlerhafter Platzhalter, wie
$0oder ein$, auf das keine Ziffer folgt.
Beheben Sie diese Fehler, bevor Sie das Diagramm anwenden. Sie treten später nicht mehr als Fehler bei der Nachrichtenverarbeitung auf.
Da der aufgelöste Schlüssel datenbasiert ist, kann er für jede Nachricht unterschiedlich sein. Wenn Sie die Diagnoseprotokollierung oder Ablaufverfolgung für die Anreicherungssuche aktivieren, sollten Sie den -aufgelösten-Schlüssel (zum Beispiel calibration:TEMP-42) sehen, nicht die konfigurierte Vorlage.
Datensatzeingaben
Jeder Eintrag im inputs Array verwendet ein Präfix, um anzugeben, wo der Wert stammt:
-
$source.<field>: liest aus der eingehenden Nachricht. -
$context.<field>: liest aus dem zu bewertenden Datensatz.
Eingaben können in beliebiger Reihenfolge erscheinen, und Sie können $source und $context Verweise frei mischen. Wildcardeingaben werden in Datasetdefinitionen nicht unterstützt.
Match-Ausdruck
Der expression wird zu einem booleschen Wert ausgewertet. Die Laufzeit lädt das Dataset aus dem Zustandsspeicher als NDJSON (ein JSON-Objekt pro Zeile), durchläuft die Einträge und gibt den ersten Eintrag zurück, bei dem der Ausdruck true ausgewertet wird.
Wenn kein Datensatz übereinstimmt, sind die Anreicherungsfelder nicht verfügbar. Regeln, die davon abhängen, werden weiterhin ausgeführt, aber sie schreiben in ihr Ausgabefeld einen null-Wert, anstatt die Nachricht fehlschlagen zu lassen. Die Regel wird nicht aus der Ausgabe entfernt, nur ihr aufgelöster Wert ist null.
Verwenden von erweiterten Daten in Regeln
Referenzen Sie abgestimmte Datensatzfelder in einem inputs Regelarray mit $context(<alias>).<fieldPath>.
Kartenbeispiel
Fügen Sie Zuordnungsregeln hinzu, die auf erweiterte Felder verweisen:
| Eingabe | Output |
|---|---|
$context(position).WorkingHours |
WorkingHours |
rawValue und $context(product).multiplier |
adjustedValue (Ausdruck: $1 * $2) |
Filterbeispiel
Fügen Sie eine Filterregel mit den Eingaben rawValue, $context(limits).multiplier und $context(limits).baseLimit sowie dem Ausdruck $1 * $2 > $3 hinzu.
Branchbeispiel
Konfigurieren Sie eine Verzweigungsregel mit den Eingaben quantity, $context(mult).factor und $context(mult).threshold sowie dem Ausdruck $1 * $2 > $3.
Wildcards mit Datensätzen
Verwenden Sie in Kartenregeln $context(<alias>).*, um alle Felder auf oberster Ebene aus dem übereinstimmenden Datensatz zu kopieren:
Fügen Sie eine Kartenregel mit Eingabe $context(device).* und Ausgabe *hinzu.
Wildcards können auch ein verschachteltes Objekt innerhalb des Datensatz-Datensatzes anvisieren. Kopiert z. B. $context(device).configuration.* nur die Felder unter configuration.
Nur die Kartenregeln unterstützen Wildcard-Anreicherungseingaben. Filter- und Verzweigungsregeln unterstützen keine Wildcardeingaben.
Bereitstellen eines Datenflussdiagramms mit Anreicherung
Erstellen Sie in der Betriebsumgebung ein Datenflussdiagramm mit Anreicherung:
- Fügen Sie eine Quelle hinzu, die aus Ihrem MQTT-Topic gelesen wird.
- Fügen Sie eine Kartentransformation hinzu. Fügen Sie in der Datasetkonfiguration ein Dataset mit dem Zustandsspeicherschlüssel und der Übereinstimmungsbedingung hinzu.
- In den Kartenregeln werden angereicherte Felder mithilfe von
$context(<alias>).<field>Syntax referenziert. - Fügen Sie ein Ziel hinzu, das an Ihr Ausgabe-Topic sendet.
Einschränkungen der Anreicherung
- Die Unterstützung für Fenster erfolgt nur per Trigger. Bei Fenstertransformationen ist Datensatzanreicherung für Trigger-Regeln (
triggers.datasets) inazureiotoperations/graph-dataflow-window:1.1.0oder später verfügbar, nicht für Akkumulationsregeln. - Der Gewinner ist derjenige, der das erste Spiel gewinnt. Die Laufzeit verwendet den ersten Datensatz, bei dem der Ausdruck zu
trueausgewertet wird. - Fehlende Übereinstimmungen lassen die Nachricht nicht fehlschlagen. Wenn kein Datensatz-Datensatz übereinstimmt, laufen die Regeln, die auf Felder referenzieren
$context(<alias>), lösen sich aber aufnull. Das Ausgabefeld ist mit einem Wertnullvorhanden, nicht weggelassen. Die Transformation schlägt nicht fehl. - Zustandsspeicherfehler werden weitergegeben. Wenn der Statusspeicher nicht erreichbar ist, schlägt die Transformation für diese Nachricht fehl.
- Keine Wildcardeingaben in Datasetdefinitionen. Jede Eingabe muss ein bestimmter
$source.<field>oder$context.<field>Bezug sein.