NGSINameMappingsInterceptor¶
コンテンツ：
機能性¶
これは、Cygnus 専用に設計されたカスタム・インターセプタです。その目的は、同時に1つ以上の置き換えることによって、NGSIRestHandler によりハンドルされた NGSI 通知から来る、元の NGSIEvent オブジェクトから変更することです：
- 通知と共に送信された FIWARE service の Http ヘッダ
- 通知とともに送信された FIWARE service path の Http ヘッダ
- 通知内のすべてのエンティティID
- 通知内のすべてのエンティティタイプ
- 通知内の任意の属性名
- 通知内の任意の属性タイプ
知られているように、NGSIEvent は ContextElement タイプのオブジェクトとして通知された Json ペイロードのヘッダと既に解析されたバージョンのセットを含みます。これが言っていることは、実際の置換はありませんが、適切なマップされた名前を持つ別の2つの ContextElement が作成され、NGSIEvent に追加され、次のようになります :
- Flume
Eventオブジェクトの元のヘッダは、FIWARE service と FIWARE service path のマップされたバージョンで拡張されています - すでに解析された
ContextElementオブジェクトには元のコンテキスト要素が含まれています - すでに解析された
ContextElementオブジェクトには、マップされたコンテキスト要素が含まれます
名前マッピングの構文¶
この形式に従った Json を含む名前マッピングのファイルが存在します：
{
"serviceMappings": [
{
"originalService": "<original_service>",
"newService": "<new_service>",
"servicePathMappings": [
{
"originalServicePath": "<original_service_path>",
"newServicePath": "<new_service_path>",
"entityMappings": [
{
"originalEntityId": "<original_entity_id>",
"originalEntityType": "<original_entity_type>",
"newEntityId": "<new_entity_id>",
"newEntityType": "<new_entity_type>",
"attributeMappings": [
{
"originalAttributeName": "<original_attribute_name>",
"originalAttributeType": "<original_attribute_type>",
"newAttributeName": "<new_attribute_name>",
"newAttributeType": "<new_attribute_type>"
},
...
]
},
...
]
},
...
]
},
...
]
}上記の Json は非常に単純です：<original_service> は、<new_service>としてマッピングされ、 <original_service_path> は <new_service_path> などとしてマッピングされます。名前のマッピングは、マップが見つかるまで反復されます。マップが見つからない場合、元の通知のマップされたバージョンは元の通知と等しくなります。
ただし、特定の特殊な動作に注意する必要があります :
- 元の名前のいずれかが存在しない場合、マッピングはそのタイプのすべての名前に影響します
- 新しい名前のいずれかが存在しない場合、元の名前がマッピングで使用されます
- 元の名前は Java ベースの正規表現をサポートしています
インターセプト前後のヘッダ¶
インターセプションの前に、これらのヘッダは、'Event' タイプのすべての内部 Flume イベントに NGSIRestHandler によって次のように追加されます :
fiware-service: 通知されたデータに関連するエンティティが属する FIWARE servicefiware-servicepath: 通知されたデータに関連するエンティティが属する FIWARE service path。通知が異なるサービスパスの複数のエンティティに関連する場合、これらはカンマで区切られたこのヘッダ内に含まれますfiware-correlator: Cygnus が属する統合全体に e2e フローを識別するために予約された UUIDtransaction-id: Flume ソースから Flume シンクへの内部フローを識別するための UUID
インターセプションの後で、NGSINameMappingsInterceptor によって次のように NGSIEvent に追加されたヘッダです :
mapped-fiware-service: 元の FIWARE service のマップされたバージョンmapped-fiwre-service-path: 元の FIWARE service path のマップされたバージョン
他のインターセプタは、ネイティブのタイムスタンプ・インターセプタによって追加された timestamp ヘッダのような、さらなるヘッダを追加することができます。
例¶
これらの名前マッピングを仮定しましょう：
{
"serviceMappings": [
{
"originalService": "hotel1",
"servicePathMappings": [
{
"originalServicePath": "/suites",
"entityMappings": [
{
"originalEntityId": "suite.(\\d*)",
"originalEntityType": "room",
"newEntityId": "all_suites",
"newEntityType": "room",
"attributeMappings": []
}
]
},
{
"originalServicePath": "/other",
"entityMappings": [
{
"originalEntityId": "room.(\\d*)",
"originalEntityType": "room",
"newEntityId": "all_other",
"newEntityType": "room",
"attributeMappings": []
}
]
}
]
}
]
}次に、受け取った通知に関する以下の非インターセプト・イベントを想定しましょう。以下のコードは実際のデータフォーマットではなくオブジェクト表現です :
notification={
headers={
fiware-service=hotel1,
fiware-servicepath=/other,/suites,
correlation-id=1234567890-0000-1234567890
},
body={
{
entityId=suite.12,
entityType=room,
attributes=[
...
]
},
{
entityId=other.9,
entityType=room,
attributes=[
...
]
}
}
}見て分かるように、FIWARE service (hotel) 内の同じタイプ(room)の2つのエンティティ(suite.12 および other.9)が異なるサービスパス(/suites および /other)が通知されます。NGSIRestHandler は2つの NGSIEvents を作成します：
ngsi-event-1={
headers={
fiware-service=hotel,
fiware-servicepath=/suites,
transaction-id=1234567890-0000-1234567890,
correlation-id=1234567890-0000-1234567890,
timestamp=1234567890,
mapped-fiware-service=hotel
mapped-fiware-service-path=/suites
},
original-context-element={
entityId=suite.12,
entityType=room,
attributes=[
...
]
},
mapped-context-element=null
}
ngsi-event-2={
headers={
fiware-service=hotel,
fiware-servicepath=/other,
transaction-id=1234567890-0000-1234567890,
correlation-id=1234567890-0000-1234567890,
timestamp=1234567890,
mapped-fiware-service=hotel
mapped-fiware-service-path=/other
},
original-context-element={
entityId=other.9,
entityType=room,
attributes=[
...
]
},
mapped-context-element=null
}いったんインターセプトされると、上記のイベントは次のようになります。以下のコードは実際のデータフォーマットではなくオブジェクト表現です :
intercepted-ngsi-event-1={
headers={
fiware-service=hotel,
fiware-servicepath=/suites,
transaction-id=1234567890-0000-1234567890,
correlation-id=1234567890-0000-1234567890,
timestamp=1234567890,
mapped-fiware-service=hotel
mapped-fiware-service-path=/suites
},
original-context-element={
entityId=suite.12,
entityType=room,
attributes=[
...
]
},
mapped-context-element={
entityId=all_suites,
entityType=room,
attributes=[
...
]
}
}
intercepted-ngsi-event-2={
headers={
fiware-service=hotel,
fiware-servicepath=/other,
transaction-id=1234567890-0000-1234567890,
correlation-id=1234567890-0000-1234567890,
timestamp=1234567890,
mapped-fiware-service=hotel
mapped-fiware-service-path=/other
},
original-context-element={
entityId=other.9,
entityType=room,
attributes=[
...
]
},
mapped-context-element={
entityId=all_other,
entityType=room,
attributes=[
...
]
}
}管理ガイド¶
構成¶
NGSINameMappingsInterceptor は、次のパラメータによって構成されます :
| パラメータ | 必須 | デフォルト値 | コメント |
|---|---|---|---|
| name_mappings_conf_file | yes | N/A | 名前マッピングファイルへの絶対パスを設定することは非常に重要です。名前マッピングファイルは通常、[FLUME_HOME_DIR]/conf/ にあり、Cygnus ディストリビューション内にテンプレートが存在します |
構成例は、次のとおりです :
cygnus-ngsi.sources.http-source.interceptors = nmi <other-interceptors>
cygnus-ngsi.sources.http-source.interceptors.nmi.type = com.telefonica.iot.cygnus.interceptors.NGSINameMappingsInterceptor$Builder
cygnus-ngsi.sources.http-source.interceptors.nmi.name_mappings_conf_file = [FLUME_HOME_DIR]/conf/name_mappings.confそれにもかかわらず、この構成は、NGSIRestHandler が入れたオリジナルの Flume イベントをインターセプトするだけで、元の通知とマップされた通知の両方を含み、シンクの使用についてすでに解析された NGSI イベントを構成済みのチャネルに入れることができます。したがって、シンクが元の通知の代わりに元の通知のマップされたバージョンを使用するためには、シンク構成で enable_name_mappings パラメータを true に設定する必要があります。たとえば、HDFSの場合：
cygnus-ngsi.sinks.hdfs-sink.enable_name_mappings = true詳細については、"Flume拡張機能カタログ" の特定のシンクのドキュメントを確認してください。
管理インタフェース関連の操作¶
近日公開