データフローおよびデータフローグラフの式参照

このリファレンスは、 データ フロー と データ フロー グラフの両方に適用されます。 どちらも、マップ、フィルター、エンリッチメント変換に同じ式言語を使用します。 データ フロー グラフでは、分岐変換とウィンドウ変換 (累積変換) もサポートされています。これは該当する場合に示されます。

位置変数

各ルールの inputs 配列は、 expressionで使用できる変数を決定します。 最初の入力は $1になり、2 番目の入力は $2になります。

入力が 1 つだけ指定され、式が指定されていない場合、その入力の値が出力に直接コピーされます。

オペレーター

式では、次の演算子がサポートされます。優先順位が最も高いものから最も低いものまで一覧表示されます。

+演算子は、少なくとも 1 つのオペランドが文字列の場合に文字列を連結します。 かっこを使用して、既定の優先順位をオーバーライドします。

例:

組み込み関数

単位変換関数

これらの関数は 1 つの数値を受け取り、float を返します。

関数のスケーリングと丸め

数学関数

これらの関数は、組み込みの数学ライブラリから取得されます。

文字列関数

日付と時刻の関数

日付と時間の機能はデータフローグラフでのみ利用可能です。 parse_timestampを除き、タイムスタンプを受け入れる関数はRFC 3339文字列が必要です。 文字列には協調世界時(UTC)からの明示的なオフセット(例えば 2026-06-17T12:00:00Z や 2026-06-17T12:00:00-08:00)が含まれなければなりません。 Returns列には概念的な結果タイプが記載されており、typeofは小文字で"float"、"int"、または"string"と報告されます。

now() 関数が実行されるたびに、データフローワークロードをホストするKubernetesノードのシステムクロックを読み取ります。 同じ式内の呼び出しは異なる値を返すことがあります。 アキュメレーションルールでは、 now() 入力メッセージが到着した時ではなく、ウィンドウが処理された時刻を返します。 クラスタノード間のクロック歪を減らすために、各ノードクロックをネットワークタイムプロトコルサーバーなど信頼できるタイムソースと同期させます。

day_of_week、hour_of_day、year_ofなどのカレンダーやクロック機能は、入力タイムスタンプのオフセットを利用します。 まず値はUTCに変換しません。 以下の例はこの挙動を示しています。

フォーマットとタイムスタンプの解析

format_timestampとparse_timestamp機能はstrftimeパターンを使用します。 以下の表は一般的な指定語を示しています。

サポートされているすべての仕様子については、 Chrono strftimeのドキュメントを参照してください。

format_timestamp 入力タイムスタンプのオフセットを保持します。 たとえば、format_timestamp("2026-06-09T14:00:00+02:00", "%Y-%m-%d %H:%M %:z") は "2026-06-09 14:00 +02:00"を返します。

parse_timestamp 入力は以下の順序で処理されます:

1. 日付と時間、そして数字のオフセット。 関数はオフセットを尊重し、結果をUTCに正規化します。
2. 日付と時間、オフセットなし。 関数はUTCを前提としています。
3. 時間のないデート。 関数はUTCの真夜中を想定しています。

以下の例は、 parse_timestamp が各入力タイプをどのように扱うかを示しています。

Unixのエポック値の変換

Unixのエポック値とRFC 3339タイムスタンプ間の変換には from_epoch と to_epoch を使いましょう。

from_epoch 1970年1月1日以前の日付については負の値を受け入れます。 出力はミリ秒精度を持つため、エポックマイクロ秒をタイムスタンプの破棄に変換すると、1ミリ秒未満の精度が得られます。 to_epoch タイムスタンプのUTCオフセットを考慮し、1970年以前の値を選択単位の次の下整数まで丸めます。

日付と時間の関数は作成可能です。 例えば、 duration_between($1, now(), "days") は最初のルール入力として提供されたRFC 3339タイムスタンプの日数()を計算します。 UTCに変換した後のタイムスタンプを読みたい場合は、 hour_of_day(from_epoch(to_epoch($1, "micros"), "micros"))を使います。

条件付き関数とコレクション関数

集計関数 (ウィンドウ変換のみ)

これらの関数は、ウィンドウ変換内の累積ルールでのみ使用できます。 それぞれが 1 つの位置変数を受け取ります。

集計関数の使用の詳細については、 時間の経過に伴うデータの集計に関するページを参照してください。

条件付きロジック

if関数を使用して、式内のロジックを分岐します。

() (空の値) を比較して、不足しているフィールドを検出します。

メタデータ フィールド

ルールの$metadata.フィールドまたはinputs フィールドのoutput プレフィックスを使用して、メッセージ メタデータの読み取りと書き込みを行います。 メタデータ参照は、式自体ではなく、フィールド パスに格納されます。

メタデータのプロパティ

• トピック: MQTT と Kafka の両方に使用できます。 メッセージが公開された文字列が含まれます。 例: $metadata.topic。
• ユーザー プロパティ: MQTT では、これは MQTT メッセージが伝送できる自由形式のキー/値のペアを指します。 たとえば、MQTT メッセージが、キー "priority" と値 "high" のユーザー プロパティを使用して発行された場合、 $metadata.user_property.priority 参照は値 "high" を保持します。 ユーザー プロパティ キーは任意の文字列で、エスケープが必要な場合があります: $metadata.user_property."weird key" はキー "weird key" (スペースを含む) を使います。
• システム プロパティ: この用語は、ユーザー プロパティでないすべてのプロパティに使用されます。 現在、1 つのシステム プロパティのみがサポートされています: MQTT メッセージのコンテンツ タイプ プロパティを読み取る $metadata.system_property.content_type (設定されている場合)。
• ヘッダー: これは、MQTT ユーザー プロパティと同等の Kafka です。 Kafka はキーに任意のバイナリ値を使用できますが、データ フローでは UTF-8 文字列キーのみをサポートしています。 例: $metadata.header.priority。 この機能はユーザー プロパティに似ています。

メタデータからの読み取り

式のソース トピックとユーザー プロパティを参照するには、それらを入力として一覧表示します。

式: $1 + "/" + $2

次の例では、MQTT の topic プロパティが出力の origin_topic フィールドにマップされています。

ユーザー プロパティ priority が MQTT メッセージに存在する場合、それを出力フィールドにマッピングする方法を次の例で示します。

メタデータへの書き込み

出力メッセージにユーザー プロパティを設定するには、出力フィールドとして $metadata.user_property.<key> を使用します。

メタデータ フィールドを空の値 (()) に設定すると、削除されます。 ユーザー プロパティの場合、重複するキーが許可されます。

メタデータ プロパティを出力ヘッダーやユーザー プロパティにマッピングすることもできます。 次の例では、MQTT の topic が出力のユーザー プロパティの origin_topic フィールドにマップされています。

受信ペイロードに priority フィールドが含まれている場合、次の例でそれを MQTT ユーザー プロパティにマッピングする方法を示します。

Kafka の同じ例:

メタデータ フィールドは、マップ、フィルター、分岐のルールでサポートされています。 ウィンドウ (累積) ルールでは使用できません。

最後の既知の値

入力の ? $last サフィックスを使用して、そのフィールドの最新の値を覚えておくようランタイムに指示します。 現在のメッセージにフィールドがない場合は、代わりに最後の既知の値が使用されます。

? $last ディレクティブでは大文字と小文字が区別されず、柔軟な空白がサポートされます。

最後の既知の値は、マップ、フィルター、分岐のルールでサポートされています。 ウィンドウ (累積) ルールでは使用できません。

既定の値

入力に ?? <default> サフィックスを使用して、フィールドが見つからない場合にフォールバック値を指定します。 サポートされている既定の型: 整数、float、ブール値、文字列、null。

最後の既知の値と既定値を結合する

? $lastと?? <default>を組み合わせることができます。 ランタイムは、最初に現在のメッセージ、最後の既知の値、次に既定値を確認します。 ?? <default>を使用せずに? $lastを使用する場合、ランタイムは現在のメッセージをチェックしてから、既定値を直接チェックします。

既定値は、マップ、フィルター、分岐のルールでサポートされています。 ウィンドウ (累積) ルールでは使用できません。

データ型

JSON オブジェクトと配列は、フィールドが式なしでコピーされるときに as-is 保持されますが、式の評価の入力として使用することはできません。

変換の種類による機能のサポート

同じ式言語は変換を超えて機能しますが、各 式の結果は それぞれ異なる意味を持ちます:

¹ データ フロー グラフでのみ使用できます。 データ フロー builtInTransformation 入力ではサポートされていません。

ドット表記とエスケープ

ドット表記は、入れ子になったフィールドを参照するために広く使用されています。 標準のドット表記パスは、 Person.Address.Street.Numberのようになります。

データ フローでは、ドット表記で記述されたパスに、エスケープを必要とせずに文字列や特殊文字 ( Person.Date of Birthなど) が含まれる場合があります。

それ以外の場合は、エスケープが必要です (例: nsu=http://opcfoundation.org/UA/Plc/Applications;s=RandomSignedInt32)。 このパスには、他の特殊文字の中でも、フィールド名内にドットが含まれています。 エスケープなしでは、このフィールド名はドット表記の中で区切りとして機能することになります。

データ フローはパスを解析しますが、次の 2 つの文字のみを特殊として扱います。

• ドット (.) はフィールド区切りとして機能します。
• 二重引用符は、セグメントの始まりや終わりに置くと、ドットがフィールド区切りとして扱われない脱出セクションを始めます。

その他の文字は、フィールド名の一部として扱われます。 この柔軟性は、フィールド名を任意の文字列にできる JSON などの形式で役立ちます。

パス定義は、構成形式の規則にも従う必要があります。 パスに特別な意味を持つ文字が含まれている場合は、適切な引用符が必要です。 たとえば、コロン ( :Person:.:name: など) で始まるフィールド名や、数値の後にテキスト ( 100 celsius.hot など) で始まるフィールド名は、構成で引用符で囲んで文字列として正しく解釈する必要があります。

エスケープ

ドットで示されたパスでエスケープする主な機能は、区切り記号ではなくフィールド名の一部であるドットの使用に対応することです。 たとえば、パス Payload."Tag.10".Value は、 Payload、 Tag.10、 Valueの 3 つのセグメントで構成されます。 Tag.10の二重引用符を使用すると、ドットが区切り記号として機能しなくなります。

ドット表記でのエスケープ ルール

• 各セグメントの個別エスケープ: 複数のセグメントにドットが含まれている場合は、それらのセグメントを二重引用符で囲む必要があります。 他のセグメントも引用符で囲むことができますが、パスの解釈には影響しません。 例: Payload."Tag.10".Measurements."Vibration.$12".Value

• セグメントは脱出が必要な時だけ引用してください。 区間に点(または区切り文字と誤読される他の文字)が含まれている場合にのみ、二重引用符を付けてください。 普通のフィールドネームを引用しないでください。

  例えば、TagName 内のRecordsというフィールドの場合:

  これを実行してください	これは違う
  Records.TagName	Records."TagName"

  追加の引用符は役に立たず、Operations Experience Data Flow Editorのような一部のツールではフィールド名の一部になってしまいます。 マッピングは "TagName" (引用符付き)というフィールドを探しますが、そのフィールドは存在せず、何も一致しません。 エクスポートされたデータフローの定義で、名前がエスケープクオート付きで表示されているのがわかります。例えば \"TagName\"です。 直すには、名前を TagNameにするために引用符を外してください。

• 二重引用符の適切な使用: 二重引用符は、エスケープされるセグメントの前後に付ける必要があります。 セグメントの中央にある引用符は、フィールド名の一部と見なされます。 たとえば、パス Payload.He said: "Hello", and waved では、 Payload と He said: "Hello", and waved の 2 つのフィールドが定義されます。 このような状況でドットが表示されると、引き続き区切り記号として機能します。 たとえば、パス Payload.He said: "No. It is done" は、セグメント Payload、 He said: "No、 It is done" (スペースから始まる) に分割されます。

分割アルゴリズム

• セグメントの最初の文字が引用符の場合、パーサーは次の引用符を探します。 これらの引用符によって囲まれた文字列は、1 つのセグメントと見なされます。
• セグメントが引用符で始まらない場合、パーサーは次のドットまたはパスの末尾を見つけることでセグメントを特定します。

ワイルドカード

入力パスと出力パスでワイルドカード (*) を使用して、一度に複数のフィールドを照合します。 これは、出力が入力とよく似ている場合や、複数のフィールドに同じ変換を適用する必要がある場合に役立ちます。

すべてのフィールドをコピーする

すべてのフィールドを変更せずに渡すには:

*は、入力内の各フィールド パスと一致し、出力内の同じパスに配置します。 一致するパスの部分*キャプチャされたセグメントと呼ばれます。 出力では、キャプチャされたセグメントによって *が置き換えられます。

入れ子になったフィールドをフラット化する

入れ子になったオブジェクトからルート レベルにフィールドを移動するには、プレフィックスを入力に配置し、出力に * します。

次の入力を与える

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

出力では、次の両方のオブジェクトがフラット化されます。

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

フィールドを再構築する

新しい親の下にフィールドを移動するには、入力に * を配置し、出力にプレフィックスを追加します。

これにより、 Telemetry オブジェクト内のすべての最上位フィールドがラップされます。

ワイルドカードの配置規則

• 入力パスまたは出力パスごとに許可されるは *です。
• *は完全なセグメントと一致する必要があります (Sensor*のような部分的なセグメントではありません)。
• *は、パスの先頭 (*.Value)、中央 (Sensors.*.Reading)、または終了 (Sensors.*) に表示できます。

複数入力ワイルドカード

ルールにワイルドカードを含む複数の入力がある場合、 * はすべての入力で 同じセグメント をキャプチャする必要があります。 ランタイムは、最初の入力から * を解決し、その後、他の入力で一致するパスを探します。

たとえば、各センサーの最大読み取り値と最小読み取り値を平均するには、次のようにします。

次の入力を与える

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

*は最初Temperatureキャプチャするため、ルールはTemperature.MaxとTemperature.Minの両方を検索します。 次に、 Pressure をキャプチャし、 Pressure.Max と Pressure.Minを探します。 出力は次のようになります。

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

キャプチャされたセグメントに対して何らかの入力を解決できない場合 (たとえば、フィールドが異なる入れ子になっている場合に *.Mid.Avg )、そのセグメントはスキップされます。 すべての入力のパスに、データの実際の構造が反映されていることを確認します。

特定のフィールドのワイルドカードをオーバーライドする

ワイルドカード規則を特定の規則と組み合わせることができます。 特定のルールは 、カバレッジが低い 場合に優先されます ( *で一致するセグメントが少なくなります)。 これは 特殊化と呼ばれます。

最初のルールはすべてのフィールドに適用されます。 2 つ目のルールは、Pressure (カバレッジ 0 とカバレッジ 1) よりも具体的なPressure.Maxであるため、*.Maxに対してのみオーバーライドされます。

フィールド全体を除外するには、空の出力を使用します。

空の出力は、結果からフィールドを削除します。 これにより、それ以外の場合にそれを含めるワイルドカードルールがオーバーライドされます。

同じ入力に対する複数のルール

2 つのルールが同じかそれより高いカバレッジを持つ場合は、両方が適用されます。 これにより、同じ入力から複数の派生値を計算できます。

どちらのルールもキャプチャされたセグメントごとに実行され、センサーごとに 2 つの出力フィールドが生成されます。

コンテキスト化データセットのワイルドカード

ワイルドカードを $context 参照と共に使用して、データセットからすべてのフィールドをコピーできます。

これにより、 assetMeta データセットのすべてのフィールドが出力の Asset セクションにコピーされます。

コンテキスト化データセット

コンテキスト化データセットを使用すると、マッピングによって外部データベースからの追加データを統合できます。 データセットのフィールドを参照するには、 $context(datasetName) プレフィックスを使用します。 たとえば、$context(position).BaseSalaryBaseSalaryという名前のデータセットからposition フィールドを読み取ります。

コンテキスト化データセットの構成の詳細については、 データ フローを使用したデータのエンリッチと、データ フローグラフ内の外部データのエンリッチを参照してください。

関連するコンテンツ

もし特定の変換で使われる構文を探してここに来たなら、これらの記事は文脈中の表現を示しています:

データフローについては、「 Map data by using data flows 」および「 データフロー内のフィルタリング」を参照してください。