名前マッピング¶

名前マッピングは、Cygnus の高度なグローバル機能です。すべての NGSI シンクで利用できるため、グローバルです。

名前マッピングは、通知された FIWARE service、FIWARE service path、エンティティID、エンティティ・タイプ、属性名、および属性タイプを、マッピングが与えられた場合に変更することを可能にします。このようなマッピングは、元の命名を別の命名によってどのように置き換えなければならないかを詳述する構成ファイル内の単なる Json にすぎません。

{
   "serviceMappings": [
      {
         "originalService": "myservice1",
         "newService": "new_myservice1",
         "servicePathMappings": [
            {
               "originalServicePath": "/myservicepath1",
               "newServicePath": "/new_myservicepath1",
               "entityMappings": [
                  {
                     "originalEntityId": "myentityid1",
                     "originalEntityType": "myentitytype1",
                     "newEntityId": "new_myentityid1",
                     "newEntityType": "new_myentitytype1",
                     "attributeMappings": [
                        {
                           "originalAttributeName": "myattributename1",
                           "originalAttributeType": "myattributetype1",
                           "newAttributeName": "new_myattributename1",
                           "newAttributeType": "new_myattributetype1"
                        },
                        ...
                     ]
                  },
                  ...
               ]
            },
            ...
         ]
      },
      ...
   ]
}

Cygnus に通知が送られると NGSINameMappingsInterceptor と呼ばれる特別な Flume インターセプタは、NGSIRestHandler により生成されたプレーン Event をインターセプトし、Event の本体を解析し、元の通知のマップバージョンを作成するために設定されたマッピングを繰り返します。終了したら、通知の元のバージョンとマップされたバージョンの両方のバージョンが、処理できるJavaオブジェクトである NGSIEvent のチャネル購入手段に入れられます :

NGSIRestHandler によって送信された元のヘッダ。すなわち、fiware-service、fiware-servicepath、fiware-correlatorとtransaction-id
マッピングされたFIWARE serviceとFIWARE service pathに関する新しいヘッダ。すなわち、mapped-fiware-service と mapped-fiware-service-path
すでに NotifyContextRequest オブジェクトとして解析されている元の通知
NotifyContextRequest オブジェクトとして、元の通知のマップされたバージョン

ボディについての生のバイトは送信されません。

シンクがこれら NGSIEvent の1つを取るときはいつでも、そのようなシンクがマッピング(enable_name_mappings パラメータ)を可能にするかどうかを決定することだけです。マッピングが有効になっている場合は、既に解析済み NotifyContextRequest (マップされたバージョン)が使用されます。そうでない場合は、元のバージョンが使用されます。

独自の名前マッピングの作成¶

NGSIRestHandler で、マッピングの定義が、Flumeインターセプタとして、すべてのシンクに対してグローバルであることに注意してください。それにもかかわらず、enable_name_mappings パラメータに応じて、アプリケーションはシンクに対してローカルです。したがって、シンクのいずれもマッピングを利用しない場合は、単純に NGSIRestHandler でNGSINameMappingsInterceptorin を設定しないでください。これにより、不必要なインターセプトやマッピングの反復を避けることができ、Cygnus はより高速に動作します。

$ cat /path/to/conf/agent.conf
cygnus-ngsi.sources.http-source.type = org.apache.flume.source.http.HTTPSource
cygnus-ngsi.sources.http-source.channels = hdfs-channel
cygnus-ngsi.sources.http-source ...
cygnus-ngsi.sources.http-source.handler = com.telefonica.iot.cygnus.handlers.NGSIRestHandler
cygnus-ngsi.sources.http-source.handler ...
cygnus-ngsi.sources.http-source.interceptors = ts nmi
cygnus-ngsi.sources.http-source.interceptors.ts.type = timestamp
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 = /path/to/conf/name_mappings.conf

さらに、元の名前が存在しない場合は、マッピングがそのタイプのすべての名前に影響することに注意してください。たとえば originalServiceがマッピングに存在しない場合、マッピングはすべての FIWARE service に影響します。

$ cat /path/to/conf/name_mappings.conf
{
   "serviceMappings": [
      {
         "servicePathMappings": [
            {
               "originalServicePath": "/myservicepath1",
               "newServicePath": "/new_myservicepath1",
               "entityMappings": [
                  {
                     "originalEntityId": "myentityid1",
                     "originalEntityType": "myentitytype1",
                     "newEntityId": "new_myentityid1",
                     "newEntityType": "new_myentitytype1",
                     "attributeMappings": [
                        {
                           "originalAttributeName": "myattributename1",
                           "originalAttributeType": "myattributetype1",
                           "newAttributeName": "new_myattributename1",
                           "newAttributeType": "new_myattributetype1"
                        }
                     ]
                  }
               ]
            }
         ]
      }
   ]
}

関連する別の動作に注意する必要があります。新しい名前のいずれかが存在しない場合は、元の名前がマッピングで使用されます。つまりマッピングはありません。この例では、元のサービスパスは決して変更されません。newServicePath が欠けているからです :

$ cat /path/to/conf/name_mappings.conf
{
   "serviceMappings": [
      {
         "originalService": "myservice1",
         "newService": "new_myservice1",
         "servicePathMappings": [
            {
               "originalServicePath": "/myservicepath1",
               "entityMappings": [
                  {
                     "originalEntityId": "myentityid1",
                     "originalEntityType": "myentitytype1",
                     "newEntityId": "new_myentityid1",
                     "newEntityType": "new_myentitytype1",
                     "attributeMappings": [
                        {
                           "originalAttributeName": "myattributename1",
                           "originalAttributeType": "myattributetype1",
                           "newAttributeName": "new_myattributename1",
                           "newAttributeType": "new_myattributetype1"
                        }
                     ]
                  }
               ]
            }
         ]
      }
   ]
}

最後に、元の名前はJavaベースの正規表現をサポートしています。たとえば、すべてのサービスパスの名前が等しくなるようにするには、単に originalServicePathの値として /.* を使用します :

$ cat /path/to/conf/name_mappings.conf
{
   "serviceMappings": [
      {
         "originalService": "myservice1",
         "newService": "new_myservice1",
         "servicePathMappings": [
            {
               "originalServicePath": "/.*",
               "newServicePath": "/new_all",
               "entityMappings": [
                  {
                     "originalEntityId": "myentityid1",
                     "originalEntityType": "myentitytype1",
                     "newEntityId": "new_myentityid1",
                     "newEntityType": "new_myentitytype1",
                     "attributeMappings": [
                        {
                           "originalAttributeName": "myattributename1",
                           "originalAttributeType": "myattributetype1",
                           "newAttributeName": "new_myattributename1",
                           "newAttributeType": "new_myattributetype1"
                        }
                     ]
                  }
               ]
            }
         ]
      }
   ]
}

さらに、上記の Java ベースの正規表現は、新しいエンティティ ID でも使用できます。たとえば、数字で連結された文字列として記述されている特定のエンティティ ID の名前を変更したい場合、その文字列を置き換えたい番号を維持します :

{
    "serviceMappings": [{
        "originalService": "service",
        "newService": "new_service",
        "servicePathMappings": [{
            "originalServicePath": "/subservice",
            "newServicePath": "/new_subservice",
            "entityMappings": [{
                "originalEntityType": "myentitytype",
                "originalEntityId": "(myentityid)([0-9]*)",
                "newEntityId": "new_myentityid$2",
                "attributeMappings": []
            }]
        }]
    }]
}

トップ

名前マッピングとグループ化のルール¶

お分かりのように、名前マッピング機能は既に存在するグループ化規則と非常によく似ています。どちらも Flume インターセプタであり、どちらも通知された特定の名前要素を変更できます。したがって、違いは何ですか？主に :

名前マッピング	グループ化ルール
通知された FIWARE service、FIWARE service path、エンティティIDs、エンティティ・タイプ、属性名、および属性タイプの変更を許可します l 通知された FIWARE service path と、エンティティIDとエンティティタイプの連結を変更することを許可します。これは宛先と呼ばれます
プレーンな Flume `Event`s はインターセプトされ、`NGSIEvent`s はチャネルに入れられます。インターセプタは元の通知を解析する必要があるため、`NGSIEvent` にはNGSIEventには既に解析された元の通知と、元の通知のマップされたバージョンが含まれていて、通知を解析するためにシンクをが解放します	プレーンな Flume `Event`s がインターセプトされ、プレーン `Event` がチャネルに入れられます。したがって、グループ化インターセプタが既にそれを解析したにもかかわらず、シンクは通知を解析しなければなりません
期待されている `nable_content_mappings` 機能は、将来的に実装されます。このようなコンテンツマッピングは、すでにマップされているバージョンを `NGSIEvent`s の元の通知で利用します	このような機能は、現在のグループ化インターセプタコードに基づいて実装することは非常に困難です

重要な注意 : リリース1.6.0以降、グループ化ルールは名前マッピングのために推奨されなくなりました。詳細はこちらをご覧ください。

トップ

参考文献¶

cygnus-ngsi エージェントの Flume 拡張機能カタログで、このカスタムインターセプタに関する特定のドキュメントを確認してください。

トップ