1.2.4. Message Routerのルールファイル

Message Routerはトピックで受信したデータに対して、MongoDBの「どのコレクション」に「どんな操作をする」か、をJSON形式のファイルで定義します。

このファイルをルールファイルと言い、既定ではconf/msgrouter/配下に以下のファイルが存在します。

rule_edge_upstream.json
edge_upstreamトピックに届いたデータに対して、どのコレクション振り分けるのか、どのような操作(追加、更新、削除)を行うのかを定義します。
rule_ma_upstream.json
ma_upstreamトピックに届いたデータに対して、どのコレクション振り分けるのか、どのような操作(追加、更新、削除)を行うのかを定義します。このファイルはICEの内部実装が使用するファイルです。
rule_mng_upstream.json
mng_upstreamトピックに届いたデータに対して、どのコレクション振り分けるのか、どのような操作(追加、更新、削除)を行うのかを定義します。このファイルはICEの内部実装が使用するファイルです。

ルールファイルは次のJSONフォーマットで記述します。

[
    {
        "data_pattern": {
            "type": "event_data",
            "payload": {
                "type": "foo"
            }
        },
        "collection": "event_data",
        "command": "update",
        "filter_keys": [
            "edge_id", "payload.type"
        ]
    },
    ...(省略)
]

data_patternからfilter_keysまでが1つの振り分けルールのオブジェクトです。

ルールはルート直下の配列に複数定義することができます。定義できるルールの数に上限はありません。

ルールのオブジェクトは次の属性を持ちます。

data_pattern

JSON形式のMQTTのメッセージのフィルタです。

data_pattern配下に定義された全ての属性と同じ値を持つJSONメッセージをこのルールで処理します。属性名の比較は値と型両方の一致を確認しており、値の比較は大文字と小文字区別します。

例えば、前述のルール定義を読み込んだ状態で下記のデータ例がフローから届くと、type属性とpayload.type属性の両方の値がルールと届いたデータの間で完全合致するため、マッチと判定されます。

data_pattern配下に存在しない属性は比較対象になりません。そのため、data_patternが空の場合は全てデータがマッチします。

あるルールのフィルタがデータにマッチした場合、そのルールより後ろに定義されたルールは処理されません。すべてのルールのフィルタにマッチしなかった場合は、何も処理されません。

  • データ例

    {
        "type": "event_data",
        "payload": {
            "id": "sample_x00001",
            "type": "foo"
        }
    }
    
collection

処理を行うMongoDBのコレクション名です。この属性は省略できません。

存在しないコレクション名を指定した場合、後述のcommand定義によりinsertやupdateしたタイミングで自動でコレクションが生成されます。

command

MongoDBに対して行う処理の内容です。この属性は省略できません。insert, update, deleteのいずれかを定義します。

それぞれ、設定した場合の処理内容は以下を参照下さい。

属性 処理概要
insert コレクションにデータを挿入する
update コレクションのデータを更新する。更新対象のデータが無い場合は挿入する。
delete コレクションのデータを削除する。
filter_keys

update, deleteする場合に、更新または削除するDBのデータを選択するフィルタ条件です。insertの場合は定義不要です。

filter_keysに定義した全ての属性に関して、メッセージのデータとDBのデータの値が合致する場合、そのDBのデータが更新や削除の対象になります。

DBに合致するデータが無い場合、updateは指定されたデータを挿入します。deleteはデータの削除を試行しますが、条件に合致するデータが無いため、結果的に何も削除されません。

値はstring型の配列で指定します。次の定義例では、2つの属性(①edge_id属性と②payload属性配下のid属性)をフィルタ条件に設定しています。この例のように、オブジェクトでネストされた属性をフィルタ条件 指定するには、.で属性名を区切ります。

"filter_keys": [
    "edge_id", "payload.id"
]

ルールファイルが存在しない場合や、フォーマットを逸脱している場合は、ルールファイルで定義されたルールは全て無視されます。また、ルールファイルは自動的な再読込は行われません。ルールを反映する場合はサービス を再起動してください。

1.2.4.1. 振り分けルール

標準のルールファイルで定義するメッセージの振り分けと加工のルールを次の表に示します。

  • edge_upstreamトピック
MQTT メッセージのタイプ (json.typeの値) MongoDB 操作 MongoDB コレクション名 MongoDB update,delete対象の指定条件
event_data insert event_data なし
  • mng_upstreamトピック
MQTT メッセージのタイプ (json.typeの値) MQTT アプリケーションタイプ (json.app_typeの値) MongoDB 操作 MongoDB コレクション名 MongoDB update,delete対象の指定条件
edge_register   update edge_info edge_id
edge_update   update edge_info edge_id
object_register   update object_info edge_id, object_id, object_type
object_update   update object_info edge_id, object_id, object_type
object_unregister   delete object_info edge_id, object_id, object_type
operation_response ua insert op_result なし
operation_response ma insert ma_op_result なし
  • ma_upstreamトピック
MQTT トピック名 MQTT メッセージのタイプ (json.typeの値) MongoDB 操作 MongoDB コレクション名 MongoDB update,delete対象の指定条件
ma_upstream event_data insert ma_event_data なし

例えば、MQTTブローカーのmng_upstreamのトピックにtype属性の値がedge_register(1列目)のデータがpublishされたら、そのデータをMongoDBのedge_info(4列目)コレクションにupdate(3列目)します。 このとき、update対象になるデータはpublishされたデータとedge_id属性(5列目)の値が同じデータです。