Uttrycksreferenser för dataflöden och dataflödesgrafer

Den här referensen gäller både dataflöden och dataflödesdiagram. Båda använder samma uttrycksspråk för map-, filter- och berikningstransformeringar. Dataflödesdiagram stöder även förgrenings- och fönstertransformeringar (ackumulerade), som noteras i förekommande fall.

Positionsvariabler

Varje regels inputs matris avgör vilka variabler som är tillgängliga i expression. Den första inmatningen blir $1, den andra blir $2, och så vidare.

Om endast en indata anges och inget uttryck anges kopieras värdet vid indata direkt till utdata.

Operatörer

Uttryck stöder följande operatorer, listade från högsta till lägsta prioritet:

Operatorn + sammanfogar strängar när minst en operand är en sträng. Använd parenteser för att åsidosätta standardprioretens.

Exempel:

Inbyggda funktioner

Enhetskonverteringsfunktioner

Dessa funktioner accepterar ett enda numeriskt värde och returnerar ett flyttal.

Skalnings- och avrundningsfunktioner

Matematiska funktioner

Dessa funktioner kommer från det inbyggda matematiska biblioteket.

Strängfunktioner

Datum- och tidsfunktioner

Datum- och tidsfunktioner finns endast tillgängliga i dataflödesgrafer. Förutom parse_timestamp, kräver funktioner som accepterar en tidsstämpel en RFC 3339-sträng . Strängen måste innehålla en explicit offset från Coordinated Universal Time (UTC), såsom 2026-06-17T12:00:00Z eller 2026-06-17T12:00:00-08:00. Kolumnen Returns listar den konceptuella resultattypen, som typeof med liten text anges som "float", "int", eller "string".

now() läser systemklockan för Kubernetes-noden som är värd för dataflödesarbetsbelastningen varje gång funktionen körs. Anrop i samma uttryck kan returnera olika värden. I en ackumuleringsregel returnerar now() tiden då fönstret bearbetas, inte när ett inmatningsmeddelande anländer. För att minska klockskevhet mellan klusternoder, synkronisera varje nodklocka med en pålitlig tidskälla, såsom en Network Time Protocol-server.

Kalender- och klockfunktioner, såsom day_of_week, hour_of_day, och year_of, använder offset i indatatidsstämpeln. De konverterar inte först värdet till UTC. Följande exempel visar detta beteende.

Format och tidsstämplar för parsning

Och format_timestamp funktionerna parse_timestamp använder strftime mönster. Följande tabell listar vanliga specifierare.

För alla stödda specifierare, se Chrono strftime-dokumentationen.

format_timestamp bevarar inmatningstidsstämpelns offset. Till exempel, format_timestamp("2026-06-09T14:00:00+02:00", "%Y-%m-%d %H:%M %:z") returnerar "2026-06-09 14:00 +02:00".

parse_timestamp hanterar indata i följande ordning:

1. Ett datum och tid med numerisk förskjutning. Funktionen hedrar offsetet och normaliserar resultatet till UTC.
2. Ett datum och tid utan förskjutning. Funktionen antar UTC.
3. En dejt utan tid. Funktionen antar midnatt UTC.

Följande exempel visar hur parse_timestamp varje typ av indata hanteras.

Konvertera Unix-epokvärden

Använd from_epoch och to_epoch för att konvertera mellan Unix-epokvärden och RFC 3339-tidsstämplar.

from_epoch accepterar negativa värden för datum före 1 januari 1970. Dess utdata har millisekundprecision, så att omvandla epokmikrosekunder till en tidsstämpel gör att precisionen under en millisekund blir borta. to_epoch tar hänsyn till tidsstämpelns UTC-offset och rundar av värden före 1970 ner till nästa lägre heltal för den valda enheten.

Datum- och tidfunktioner kan skrivas. Till exempel beräknar duration_between($1, now(), "days") den åldern i dagar för en RFC 3339-tidsstämpel som anges som första regelinmatning. För att läsa en tidsstämpels timme efter att den konverterats till UTC, använd hour_of_day(from_epoch(to_epoch($1, "micros"), "micros")).

Villkors- och samlingsfunktioner

Sammansättningsfunktioner (endast fönstertransformering)

Dessa funktioner är endast tillgängliga i ackumuleringsregler i fönstertransformeringar. Var och en tar en enda positionsvariabel.

Mer information om hur du använder aggregeringsfunktioner finns i Sammanställa data över tid.

Villkorsstyrd logik

if Använd funktionen för att förgrena logik i ett uttryck:

Använd () (det tomma värdet) i jämförelser för att identifiera saknade fält.

Metadatafält

Läsa från och skriva till meddelandemetadata med hjälp $metadata. av prefixet i fälten inputs eller output i en regel. Metadatareferenser finns i fältsökvägen, inte i själva uttrycket.

Metadataegenskaper

• Ämne: Fungerar för både MQTT och Kafka. Den innehåller textsträngen där meddelandet publicerades. Exempel: $metadata.topic.
• Användaregenskap: I MQTT refererar detta till de nyckel-/värdepar med fritt format som ett MQTT-meddelande kan innehålla. Om till exempel MQTT-meddelandet publicerades med en användaregenskap med nyckeln "prioritet" och värdet "hög" innehåller referensen $metadata.user_property.priority värdet "hög". Användaregenskapsnycklar kan vara godtyckliga strängar och kan kräva att de tas bort: $metadata.user_property."weird key" använder nyckeln "konstig nyckel" (med ett blanksteg).
• Systemegenskap: Den här termen används för varje egenskap som inte är en användaregenskap. För närvarande stöds endast en enda systemegenskap: $metadata.system_property.content_type, som läser innehållstypegenskapen för MQTT-meddelandet (om den anges).
• Rubrik: Det här är Kafka-motsvarigheten till MQTT-användaregenskapen. Kafka kan använda valfritt binärt värde för en nyckel, men dataflöden stöder endast UTF-8-strängnycklar. Exempel: $metadata.header.priority. Den här funktionen liknar användaregenskaper.

Läsa från metadata

Om du vill referera till källavsnittet och en användaregenskap i ett uttryck anger du dem som indata:

Uttryck: $1 + "/" + $2

I följande exempel mappas MQTT-egenskapen topic till fältet origin_topic i utdata:

Om användaregenskapen priority finns i MQTT-meddelandet visar följande exempel hur du mappar den till ett utdatafält:

Skriva till metadata

Om du vill ange en användaregenskap i utdatameddelandet använder du $metadata.user_property.<key> som utdatafält.

Om du anger ett metadatafält till ett tomt värde (()) tar du bort det. För användaregenskaper tillåts dubbletter av nycklar.

Du kan också mappa metadataegenskaper till ett utdatahuvud eller en användaregenskap. I följande exempel mappas MQTT topic till origin_topic fältet i utdatans användaregenskap:

Om den inkommande nyttolasten innehåller ett priority fält visar följande exempel hur du mappar den till en MQTT-användaregenskap:

Samma exempel för Kafka:

Metadatafält stöds i kart-, filter- och grenregler. De är inte tillgängliga i regler för fönster (ackumulerade).

Senast kända värde

Använd suffixet ? $last på indata för att be körningen att komma ihåg det senaste värdet för fältet. Om fältet saknas i det aktuella meddelandet används det senast kända värdet i stället.

Direktivet ? $last är skiftlägeskänsligt och stöder flexibla blanksteg.

Senast kända värde stöds i kart-, filter- och grenregler. Det är inte tillgängligt i regler för fönster (ackumulerade).

Standardvärden

Använd suffixet ?? <default> på indata för att ange ett återställningsvärde när fältet saknas. Standardtyper som stöds: heltal, flyttal, booleskt värde, sträng och null.

Kombinera senast kända värde och standard

Du kan kombinera ? $last och ?? <default>. Körningen kontrollerar det aktuella meddelandet först, sedan det senast kända värdet och sedan standardvärdet. Om du använder ?? <default> utan ? $lastkontrollerar körningen det aktuella meddelandet och sedan standardvärdet direkt.

Standardvärden stöds i map-, filter- och grenregler. De är inte tillgängliga i regler för fönster (ackumulerade).

Datatyper

JSON-objekt och matriser bevaras as-is när fält kopieras utan uttryck, men de kan inte användas som indata för uttrycksutvärdering.

Funktionsstöd efter transformeringstyp

Samma uttrycksspråk fungerar över transformationer, men resultatet av ett uttryck betyder något olika i varje transform:

¹ Endast tillgängligt i dataflödesdiagram. Stöds inte i dataflödesindata builtInTransformation .

Punkt notation och escapeing

Punkt notation används ofta för att referera till kapslade fält. En standardsökväg för punkt notation ser ut som Person.Address.Street.Number.

I ett dataflöde kan en sökväg som Person.Date of Birthbeskrivs av punkt notation innehålla strängar och vissa specialtecken utan att behöva fly, till exempel .

I andra fall är det nödvändigt att fly, till exempel: nsu=http://opcfoundation.org/UA/Plc/Applications;s=RandomSignedInt32. Den här sökvägen innehåller bland annat punkter i fältnamnet. Utan escape skulle fältnamnet fungera som avgränsare i själva punktnotationen.

Även om ett dataflöde parsar en sökväg behandlar det bara två tecken som specialtecken:

• Punkter (.) fungerar som fältavgränsare.
• Dubbla citationstecken, när de placeras i början eller slutet av ett segment, startar en utlämnad sektion där prickar inte behandlas som fältseparatorer.

Andra tecken behandlas som en del av fältnamnet. Den här flexibiliteten är användbar i format som JSON, där fältnamn kan vara godtyckliga strängar.

Sökvägsdefinitionen måste också följa reglerna i konfigurationsformatet. När ett tecken med särskild betydelse ingår i sökvägen krävs korrekt citattecken. Till exempel måste fältnamn som börjar med ett kolon (t.ex :Person:.:name:. ) eller som börjar med ett tal följt av text (som 100 celsius.hot) citera i konfigurationen tolkas korrekt som strängar.

Escape

Den primära funktionen för att fly i en punkt noterad sökväg är att hantera användningen av punkter som ingår i fältnamn i stället för avgränsare. Sökvägen Payload."Tag.10".Value består till exempel av tre segment: Payload, Tag.10och Value. De dubbla citattecknen runt Tag.10 hindrar punkten från att fungera som avgränsare.

Undantag från regler i punkt notation

• Undvik varje segment separat: Om flera segment innehåller punkter måste dessa segment omges av dubbla citattecken. Andra segment kan också citeras, men det påverkar inte vägtolkningen. Till exempel: Payload."Tag.10".Measurements."Vibration.$12".Value

• Citera ett segment endast när det behöver tas bort. Lägg till dubbla citattecken runt ett segment endast när det innehåller en prick (eller ett annat tecken som annars skulle misstolkas som en separator). Citera inte ett vanligt fältnamn.

  Till exempel, för ett fält med namnet inuti TagNameRecords:

  Gör detta	Inte detta
  Records.TagName	Records."TagName"

  De extra citattecknen hjälper inte, och i vissa verktyg, som operations experience data flow-editorn, blir de en del av fältnamnet. Mappningen letar sedan efter ett fält med namnet "TagName" (citat inkluderat), vilket inte finns, så inget stämmer. Du kan se detta i definitionen av exporterade dataflödes, där namnet förekommer med undanflygande citattecken, som \"TagName\". För att åtgärda det, ta bort citattecknen så att namnet bara TagNameblir .

• Korrekt användning av dubbla citattecken: Dubbla citattecken måste öppna och stänga ett undantaget segment. Citattecken i mitten av segmentet betraktas som en del av fältnamnet. Sökvägen Payload.He said: "Hello", and waved definierar till exempel två fält: Payload och He said: "Hello", and waved. När en punkt visas under dessa omständigheter fortsätter den att fungera som avgränsare. Sökvägen Payload.He said: "No. It is done" är till exempel uppdelad i segmenten Payload, He said: "Nooch It is done" (börjar med ett blanksteg).

Segmenteringsalgoritm

• Om det första tecknet i ett segment är ett citattecken söker parsern efter nästa citattecken. Strängen som omges av dessa citattecken betraktas som ett enda segment.
• Om segmentet inte börjar med ett citattecken identifierar parsern segment genom att söka efter nästa punkt eller slutet av sökvägen.

Jokertecken

Använd ett jokertecken (*) i sökvägar för in- och utdata för att matcha flera fält samtidigt. Detta är användbart när utdata liknar indata, eller när du behöver använda samma transformering i många fält utan att visa var och en.

Kopiera alla fält

Så här skickar du varje fält genom oförändrat:

Matchar * varje fältsökväg i indata och placerar den på samma sökväg i utdata. Den del av sökvägen som * matchar kallas det insamlade segmentet. I utdata ersätter *det insamlade segmentet .

Platta ut kapslade fält

Om du vill flytta fält från ett kapslat objekt till rotnivån lägger du prefixet i indata och * i utdata:

Med dessa indata:

{
  "Sensors": { "Temperature": 72.5, "Pressure": 14.7 },
  "Metadata": { "LineId": "Line-3", "Shift": "A" }
}

Utdata plattar ut båda objekten:

{
  "Temperature": 72.5,
  "Pressure": 14.7,
  "LineId": "Line-3",
  "Shift": "A"
}

Omstrukturera fält

Om du vill flytta fält under en ny överordnad lägger du * till indata och lägger till ett prefix i utdata:

Detta omsluter alla fält på den översta nivån i ett Telemetry objekt.

Placeringsregler för jokertecken

• Endast en* tillåts per in- eller utdatasökväg.
• * Måste matcha ett fullständigt segment (inte ett partiellt segment som Sensor*).
• * Kan visas i början (*.Value), mitten (Sensors.*.Reading) eller slutet (Sensors.*) av en sökväg.

Jokertecken med flera indata

När en regel har flera indata med jokertecken måste * samma segment avbildas i alla indata. Körningen * löser från den första indatan och letar sedan efter matchande sökvägar i de andra indata.

Om du till exempel vill medelvärdet av max- och min-avläsningarna för varje sensor:

Med dessa indata:

{
  "Temperature": { "Max": 85.3, "Min": 62.1 },
  "Pressure": { "Max": 15.2, "Min": 14.1 }
}

Avbildningarna *Temperature först, så regeln letar efter både Temperature.Max och Temperature.Min. Sedan fångar den in Pressure och letar Pressure.Max efter och Pressure.Min. Resultatet är:

{
  "Averaged": { "Temperature": 73.7, "Pressure": 14.65 }
}

Om några indata inte kan matchas för ett insamlat segment (till exempel *.Mid.Avg när fältet är kapslat på ett annat sätt) hoppas det segmentet över. Kontrollera att sökvägarna i alla indata återspeglar datans faktiska struktur.

Åsidosätt ett jokertecken för specifika fält

Du kan kombinera en jokerteckenregel med specifika regler. Specifika regler har företräde när de har en lägre täckning (färre segment matchas av *). Detta kallas specialisering.

Den första regeln gäller för alla fält. Den andra regeln åsidosätter den endast för Pressure , eftersom Pressure.Max den är mer specifik än *.Max (täckning 0 jämfört med täckning 1).

Om du vill exkludera ett fält helt använder du tomma utdata:

Ett tomt utdata släpper fältet från resultatet. Detta åsidosätter alla jokerteckenregler som annars skulle inkludera den.

Flera regler för samma indata

Om två regler har samma eller högre täckning gäller båda. På så sätt kan du beräkna flera härledda värden från samma indata:

Båda reglerna körs för varje insamlat segment, vilket ger två utdatafält per sensor.

Jokertecken i kontextualiseringsdatauppsättningar

Du kan använda jokertecken med $context referenser för att kopiera alla fält från en datauppsättning:

Detta kopierar varje fält från datamängden assetMetaAsset till avsnittet i utdata.

Kontextualiseringsdatauppsättningar

Med kontextualiseringsdatauppsättningar kan mappningar integrera extra data från externa databaser. Använd prefixet $context(datasetName) för att referera till fält från en datauppsättning. Läser $context(position).BaseSalary till exempel fältet BaseSalary från en datauppsättning med namnet position.

Mer information om hur du konfigurerar kontextualiseringsdatamängder finns i Berika data med hjälp av dataflöden och Berika med externa data i dataflödesdiagram.

Relaterat innehåll

Om du kom hit för att leta efter syntaxen som används i en specifik transform, visar dessa artiklar uttryck i kontext:

För dataflöden, se Karta data genom att använda dataflöden och Filterdata i ett dataflöde.