フィールド マッパー プロセッサ

フィールド マッパー プロセッサは、あるイベント スキーマから別のイベント レコード スキーマまたは構造にデータを変換 (マッピング) するときに使用します。 フィールド マッパー プロセッサには次の主要な用途があります。

• 階層構造または多重基本構造を平坦化してから、イベント レコードを追加または更新フィーチャ出力にルーティングします。
• 属性フィールド名または大文字化に必要な変更を処理します。たとえば、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 integer に変更できますが、フィールド マッパー プロセッサを使用して、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 です。
• 詳細については、階層および多重基本データの例に関する Esri Community上のブログ記事「JSON Data Structures - Working with Hierarchy and Multi-cardinality」の「Accessing data values」セクションをご参照ください。

使用上の注意

フィールド マッパー プロセッサを使用する際には、以下の点に注意してください。

• フィールド マッパー プロセッサを構成する場合、ソースのジオイベント定義とターゲットのジオイベント定義を選択します。 右に表示されるターゲットのジオイベント定義のフィールドと、ソースのジオイベント定義のフィールドのドロップ ダウン リストを使用して、マッピングする適切なフィールドを選択できます。 各フィールドに適したマッピングを識別できるようにするために、各フィールドのデータ タイプが表示されます。
• リアルタイム処理のある段階でイベント レコードのジオイベント定義が、公開済みフィーチャ サービスのスキーマに一致していない場合があります。 そのようなイベント レコードは、フィールド マッパー プロセッサによって処理し、ターゲット フィーチャのスキーマに一致するように各イベント レコードのスキーマを変換する必要があります。その後、ジオイベント サービスは、フィーチャ サービス内のフィーチャを更新できます。 たとえば、多くの (特に、汎用 JSON を提供する) リアルタイム データ フィードは、データがグループや複数の値のリストとして整理されたデータを含むデータ構造を多くの場合提供します。 そのようなデータ構造は、フィーチャ サービスの、不連続データ タイプ (Date、String、Long など) を必要とするフラットなデータ構造を持つスキーマとは一致しません。 このプロセッサを使用して、階層データ構造や多重基本データ構造のデータをマッピングし、フィーチャ サービスからインポートされたジオイベント定義としてよりシンプルでフラットなデータ構造を作成できます。
• ソースのジオイベント定義に使用可能なドロップダウン リストは、テキスト ボックスに入力することで上書きできます。 フィールド演算プロセッサで使用されるものと同じ式を各ソース フィールドの選択テキスト ボックスで使用できます。 式に含まれるソース フィールドを参照するには、大文字と小文字を区別してソース フィールドの名前を指定します。
• 公開済みフィーチャ サービスのフィーチャを更新するが、既存のフィーチャの 1 つ以上のフィールドを変更したくない場合、それらのフィールドをプロセッサでマッピングしないままにすると、マッピングされていないフィーチャ レコードの属性に NULL 値が書き込まれます。 マッピングされていないフィールドをプロセッサに残す代わりに、更新されないフィールドを削除します。 詳細については、Esri Community上のブログ記事「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 として入力した場合、プロセッサはどのフィールドもマッピングしません。 その代わり、プロセッサはソースのジオイベント定義を使用して元のイベント レコードを通過させます。 これは、階層の値を参照するためのドット表記またはインデックス表記が間違って指定されている場合にも当てはまります。

フィールド名の分離

一般に算術演算関数または演算子として認識される文字を属性フィールドの名前に使用してはなりません。 このプロセッサで使用されている式パーサーは、フィールド名を式の残りの部分から分離するように特別に設計されている構文でフィールド名自体が囲まれていない限り、式 subtract accuracy from gps と gps-accuracy (属性フィールド名にダッシュが含まれている) を区別することができません。

外部ソースからのデータに含まれている属性フィールド名で使用可能なメタ文字が、通常は算術演算関数として認識される文字 (加算 (+)、減算 (-)、乗算 (*)、除算 (/) など) と競合している場合、属性名を ${} で囲むことによって、式パーサーに対して、フィールド名を式の残りの部分から分離して解釈するように指示する必要があります。

以下の例では、センサー レコードが汎用 JSON として表されており、リテラルのダッシュがフィールド名に含まれているという事実に対処するため、属性下部構造内の gps-accuracy キーへの参照をコーディングする必要があります。

@deviceID キーと @address キーでアンパサンド (@) は使用できますが、推奨されません。 詳細については、「フィールド名の制限」をご参照ください。 データのスキーマを更新または変更できない場合、イベント処理ワークフローのできるだけ早い段階でフィールド マッパー プロセッサを使用して、フィールド名から英数字以外の文字を削除する必要があります。 行 1 と行 2 に示す式は、属性名を ${} で囲んでフィールド名を分離することなく、この処理を行っています。

行 3 に示す式では、属性下部構造内の @notes キーに対処するために必要なドット表記 (.) が使用されています。 この場合も、フィールド名にアンパサンド (@) を含めることはできますが、推奨されません。 メタ文字によって式パーサーの解釈が曖昧になることはないため、属性名を ${} で囲む必要はありません。

キー gps-accuracy にダッシュ (-) が含まれていることで曖昧さが生じています。 このため、行 4 に示す式では、${} 構文を使用してフィールド名を明確に分離しています。 属性下部構造内の gps-accuracy キーに対処するために必要なドット表記は ${} 構文に組み込まれています。

フィールド名のガイドラインを促すために、フィールド マッパー プロセッサはジオイベント サービスの早い段階で使用する必要があるため、図に示すソリューションでは、受信した座標からジオメトリを作成しないように入力が構成されています。 代わりに、行 5 に示す式で、関数を使用して、ジオメトリをリアルタイムで生成し、Geometry という名前のフィールドにマッピングしています。 関数のパラメーターでドット表記を使用して、座標下部構造内の Longitude キーと Latitude キーに対処していることに注意してください。