サマリ
フィールド マッパー プロセッサを使用して、あるイベント スキーマから別のイベント レコード スキーマまたは構造にデータを変換 (マッピング) できます。 フィールド マッパー プロセッサには次の 5 つの主要な用途があります。
- 階層構造または多重基本構造を平坦化してから、イベント レコードを追加または更新フィーチャ出力にルーティングします。
- 属性フィールド名または大文字化に必要な変更を処理します。 たとえば、TrackID を track_id にマッピングします。
- イベント レコードを簡略化するために対象のフィールドを新しいフィールドに個別にマッピングします。
- 新しい属性フィールドをイベント レコードのスキーマに追加して、フィールド エンリッチャー (フィーチャ サービス) / フィールド エンリッチャー (ファイル) などの他のプロセッサが新しいフィールドではなく既存のフィールドに書き込めるようにします。
- string から long integer またはその逆など、明示的なデータ タイプ変換を実行します。
- 受信イベント ソース フィールド値をターゲット フィールドにマッピングするときにフィールド演算を実行します (フィールド演算プロセッサに似ています)。
GeoEvent Server に読み込まれるすべてのイベント データに、属性フィールド名、データ タイプ、データ構造全体を定義する関連付けられたジオイベント定義があります。 フィールド マッパー プロセッサは、ジオイベント定義間のマッピングに使用できます。
例
- フィールド マッパー プロセッサは、属性フィールド名または大文字化に必要な変更を処理するために使用できます。 たとえば、ReportedDateTime などの属性フィールド名とともに読み込まれたデータを再分類して、データ値を reported_dt という名前の属性フィールドに転送できます。 これが必要になるのは多くの場合、フィールド名がすべて大文字または小文字のどちらかにするというバックエンド RDMS 要件を受信したスキーマの属性フィールド名が満たしていないときです。
- このプロセッサを使用して、新しいフィールド対象のフィールドを個別にマッピングできるため、ターゲットのイベント構造は、ソースよりも属性フィールドが少なくなります。 たとえば、受信した座標値からジオメトリを構築するよう入力を構成する場合、フィールド マッパー プロセッサを使用してイベント レコードの構造から座標値を削除してから、データを出力にルーティングできます。 都市名、州、その他の一般情報を保持しながら、顧客の名前と住所を削除することでイベント データを匿名にするためにも使用できます。
- このプロセッサを使用して、イベント構造にフィールドをさらに追加できます。 これは、フィールド エンリッチャー (フィーチャ サービス) プロセッサを使用して、プロセッサが新しいフィールドを作成するのではなく既存のフィールドに書き込めるようにするときに便利です。 このプロセッサを他のプロセッサの前に使用すると、イベント データにフィールドを追加でき、下流のプロセッサが新しいフィールドにデータを書き込めるようになります。
- 個別のソース フィールドのテキスト ボックス エントリでは、フィールド演算プロセッサと同じようにフィールド演算を使用できます。 このため、複数のフィールド値を組み込み関数と組み合わせて使用して、複雑な値マッピングを作成できます。 たとえば、「toInteger(replace(' kph',''))*0.6214」という式を使用して、文字列フィールド speed の値 “12.1 kph” をマイル/時 (mph) に変換できます。
- このプロセッサを使用して、string から long (たとえば、“3201” から 3201) および long から string (たとえば、3201 から “3201”) などの明示的なデータ タイプ変換を実行できます。 GeoEvent Server は日付の値 (エポック ミリ秒) を long integer として処理するため、明示的に date から long に変更できますが、フィールド マッパー プロセッサを使用して、date から string または string から date に変更することはできません。 その代わりに、フィールド演算プロセッサの toString( ) 関数を使用して、date から string に変換します。
- このプロセッサを使用して、多重基本イベント構造または階層イベント構造を平坦化できます。 これは通常、イベント レコードを追加または更新フィーチャ出力にルーティングする前に行われます。ジオデータベース内のフィーチャ レコードはデータ値の階層グループまたは多重基本リストをサポートしていません。 たとえば、以下の図は、3 つのデータ値 (pressure、temperature、humidity) が data という名前の親エレメントの下にグループ化されているシナリオを示しています。 このプロセッサを使用して、data の下にグループ化された属性を、id、status、および calibrated の属性とともにピアにマッピングすることでイベント レコードの階層を平坦化できます。
- グループまたは階層構造内で整理された値をマッピングする場合、ドット (.) 表記を使用してネストされたフィールドにアクセスします。 たとえば、グループ data フィールドの下にネストされた pressure フィールドをマッピングするには、data.pressure を pressure という名前のフィールドにマッピングします。
- 配列やリスト、または多重基本構造内で整理された値をマッピングする場合、C# や Java などのプログラミング言語に共通するインデックス表記を使用します。 たとえば、observations という名前の値のリストが指定され、third という名前の新しい属性にそのリストの 3 つ目の値をマッピングするには、third という名前のフィールドに observations[2] をマッピングします。 プログラミング内の配列は、ほぼ必ずゼロベースです。つまり、配列で最初のエレメントのインデックスは 0 です。
- 詳細については、階層および多重基本データの例に関する GeoNet 上のブログ記事「JSON Data Structures - Working with Hierarchy and Multi-cardinality」の「Accessing data values」セクションをご参照ください。
使用上の注意
- フィールド マッパー プロセッサを構成する場合、ソースのジオイベント定義とターゲットのジオイベント定義を選択します。 右に表示されるターゲットのジオイベント定義のフィールドと、ソースのジオイベント定義のフィールドのドロップ ダウン リストを使用して、マッピングする適切なフィールドを選択できます。 各フィールドに適したマッピングを識別できるようにするために、各フィールドのデータ タイプが表示されます。
- リアルタイム処理のある段階でイベント レコードのジオイベント定義が、公開済みフィーチャ サービスのスキーマに一致していない場合があります。 そのようなイベント レコードは、フィールド マッパー プロセッサによって処理し、ターゲット フィーチャのスキーマに一致するように各イベント レコードのスキーマを変換する必要があります。その後、ジオイベント サービスは、フィーチャ サービス内のフィーチャを更新できます。 たとえば、多くの (特に、汎用 JSON を提供する) リアルタイム データ フィードは、データがグループや複数の値のリストとして整理されたデータを含むデータ構造を多くの場合提供します。 そのようなデータ構造は、フィーチャ サービスの、不連続データ タイプ (Date、String、Long など) を必要とするフラットなデータ構造を持つスキーマとは一致しません。 このプロセッサを使用して、階層データ構造や多重基本データ構造のデータをマッピングし、フィーチャ サービスからインポートされたジオイベント定義としてよりシンプルでフラットなデータ構造を作成できます。
- ソースのジオイベント定義に使用可能なドロップダウン リストは、テキスト ボックスに入力することで上書きできます。 フィールド演算プロセッサで使用されるものと同じ式を各ソース フィールドの選択テキスト ボックスで使用できます。 式に含まれるソース フィールドを参照するには、大文字と小文字を区別してソース フィールドの名前を指定します。
- 公開済みフィーチャ サービスのフィーチャを更新するが、既存のフィーチャの 1 つ以上のフィールドを変更したくない場合、それらのフィールドをプロセッサでマッピングしないままにすると、マッピングされていないフィーチャ レコードの属性に NULL 値が書き込まれます。 マッピングされていないフィールドをプロセッサに残す代わりに、更新されないフィールドを削除します。 詳細については、GeoNet のブログ記事「Using a partial GeoEvent Definition to update feature records」をご参照ください。
パラメーター
パラメーター | 説明 |
---|---|
名前 | GeoEvent Manager で参照用として使用されるプロセッサの記述名。 |
プロセッサ | GeoEvent Manager で参照用として使用されるプロセッサの記述名。 |
ソースのジオイベント定義 | 属性値の取得元となるジオイベント定義の名前。 注意:グループまたは階層構造内で整理された値をマッピングする場合、ドット (.) 表記を使用してネストされたフィールドにアクセスします。 リストまたは多重基本構造内で整理された値をマッピングする場合、C# や Java などのプログラミング言語に共通するインデックス表記を使用します。 式を使用してターゲット フィールドの値を計算する場合は、フィールド演算プロセッサの Expression フィールドに用いられるのと同じ表記を使用してください。 |
ターゲットのジオイベント定義 | 属性値がソース データ構造から値を受け取るジオイベント定義の名前。 |
検討事項および制限事項
- フィールド マッパー プロセッサがデータ タイプ変換を実行できない場合は、マッピングされたフィールドに NULL 値が書き込まれます。 たとえば、データ タイプが String の属性フィールドをデータ タイプが Double の属性フィールドにマッピングする場合です。 プロセッサは文字列リテラル値 (12) を数値に変換できないため、Null 値をターゲット フィールドに書き込みます。
- プロセッサは受信するイベント データを選択します。 たとえば、Car ジオイベント定義に関連付けられたイベント レコードを Vehicle ジオイベント定義で示された構造にマッピングするようにプロセッサが構成されるとします。 船の属性データを持つイベント レコードを受信した場合、プロセッサは、データ構造が Vessel のジオイベント定義に一致するイベント コードを別の下流のプロセッサが処理するとして、イベント レコードを変更せずに通過させます。
- ソースのジオイベント定義とターゲットのジオイベント定義の間のフィールド マッピングが間違っている場合、プロセッサはイベント レコードを削除または破棄しません。 イベント レコードはソースのジオイベント定義を使用して引き続き処理され、ターゲットのジオイベント定義は無視されます。 たとえば、TrackID というソース スキーマのフィールドを track_id というターゲット スキーマのフィールドにマップしようとして、ソース フィールドを間違って TrackIDs として入力した場合、プロセッサはどのフィールドもマッピングしません。 その代わり、プロセッサはソースのジオイベント定義を使用して元のイベント レコードを通過させます。 これは、階層の値を参照するためのドット表記またはインデックス表記が間違って指定されている場合にも当てはまります。