この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
IoT Coreのルールアクションには「DynamoDB」と「DynamoDBv2」があります。
「ん? 何がどう違うの???」となったので、実際に試してみました。
DynamoDBを準備する
次のDynamoDBテーブルを作成します。
- テーブル名: iot_sample
- パーティションキー: id(文字列)
アクション:DynamoDBのとき
IoTルールの作成
次のIoTルールを作成します。
SQL
SELECT
timestamp() as aws_timestamp,
principal() as id,
* as payload
FROM
'/topic/sample'
アクション
パーティションキーの値を一意にするために、${principal()}
を設定しています(デバイスを区別するため)。
もしトピック内にデバイスを特定する何らかのIDがあるなら、topic(2)
等を使用すると良さそうです。
- パーティションキーの値: ${principal()}
- この列にメッセージデータを書き込む: received_data
テストデータを送信
テスト画面からテスト用のデータを送信します。
{
"device_timestamp": 1234567890,
"id": "test001",
"aaa": "xxx",
"bbb": "yyy"
}
DynamoDBの内容
下記となりました。結構な入れ子構造になります。received_data
の中にSQLのSELECT
で設定した値があります。
{
"id": "AROAIKGLCRYMLEVR6OZIS:cm-fujii.genki",
"received_data": {
"aws_timestamp": 1581861030455,
"id": "AROAIKGLCRYMLEVR6OZIS:cm-fujii.genki",
"payload": {
"aaa": "xxx",
"bbb": "yyy",
"device_timestamp": 1234567890,
"id": "test001"
}
}
}
アクション:DynamoDBv2のとき
IoTルールの作成
次のIoTルールを作成します。
SQL
SQLは先程と同じです。
SELECT
timestamp() as aws_timestamp,
principal() as id,
* as payload
FROM
'/topic/sample'
アクション
指定する項目はありません。
テストデータを送信
テスト画面からテスト用のデータを送信します。内容は先程と同じです。
{
"device_timestamp": 1234567890,
"id": "test001",
"aaa": "xxx",
"bbb": "yyy"
}
DynamoDBの内容
下記となりました。SQLのSELECT
で設定した値をそのままPutItem()
した形になっています。
{
"aws_timestamp": 1581861607856,
"id": "AROAIKGLCRYMLEVR6OZIS:cm-fujii.genki",
"payload": {
"aaa": "xxx",
"bbb": "yyy",
"device_timestamp": 1234567890,
"id": "test001"
}
}
SQLを少し変えてみる(DynamoDBv2)
DynamoDBv2は、SQLのSELECT
で設定した値をそのままPutItem()
した形です。
ということは、DynamoDBのパーティションキーとその値を自由にできます(受信したJSONデータの内容)。
SQL
SELECT
*
FROM
'/topic/sample'
テストデータを送信
{
"device_timestamp": 1234567890,
"id": "test001",
"aaa": "xxx",
"bbb": "yyy"
}
DynamoDBの内容
受信したJSONデータの内容にパーティションキーであるid
があるため、そのまま格納されました。
{
"aaa": "xxx",
"bbb": "yyy",
"device_timestamp": 1234567890,
"id": "test001"
}
さいごに
DynamoDBv2を使えば、痒いところに手が届きそうです。スッキリしました。