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列目)の値が同じデータです。