翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# HTTP
HTTPS (`http`) アクションは、MQTT メッセージからウェブアプリケーションまたはサービスを指すことができる HTTPS エンドポイントにデータを送信します。
## 要件
このルールアクションには、以下の要件があります。
+ ルールエンジンが HTTPS エンドポイントを使用する前に、それらの HTTPS エンドポイントを確認して有効にする必要があります。詳細については、「[HTTP アクションの送信先](http-action-destination.md)」を参照してください。
## パラメータ
このアクションで AWS IoT ルールを作成するときは、次の情報を指定する必要があります。
`url`
HTTP POST メソッドを使用してメッセージを送信する HTTPS エンドポイント。ホスト名の代わりに IP アドレスを使用する場合は、IPv4 アドレスである必要があります。IPv6 アドレスはサポートされません。
[置換テンプレート](iot-substitution-templates.md)をサポート: はい
`confirmationUrl`
(オプション) 指定した場合、確認 URL AWS IoT を使用して一致するトピックルールの送信先を作成します。HTTP アクションで使用する前に、HTTP アクションの送信先を有効にする必要があります。詳細については、「[HTTP アクションの送信先](http-action-destination.md)」を参照してください。置換テンプレートを使用する場合は、アクションを使用する前に HTTP `http`アクションの送信先を手動で作成する必要があります。 は のプレフィックス`confirmationUrl`である必要があります`url`。
`url` との関係および `confirmationUrl` は、次のように記述されます。
+ `url` がハードコードされており、 が指定されていない場合`confirmationUrl`、 `url`フィールドは暗黙的に として扱われます`confirmationUrl`。 は のトピックルールの送信先 AWS IoT を作成します`url`。
+ `url` と `confirmationUrl`がハードコードされている場合、 は で始まる`url`必要があります`confirmationUrl`。 は のトピックルールの送信先 AWS IoT を作成します`confirmationUrl`。
+ `url` に置換テンプレートが含まれている場合は、`confirmationUrl` を指定し、`url` は `confirmationUrl` で始まる必要があります。に置換テンプレート`confirmationUrl`が含まれている場合は、アクションを使用する前に HTTP `http`アクションの送信先を手動で作成する必要があります。`confirmationUrl` に置換テンプレートが含まれていない場合、 は のトピックルールの送信先 AWS IoT を作成します`confirmationUrl`。
[置換テンプレート](iot-substitution-templates.md)をサポート: はい
`headers`
(オプション) エンドポイントへの HTTP リクエストに含めるヘッダーのリスト。各ヘッダーには、以下の情報が必要です。
`key`
ヘッダーのキー。
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`value`
ヘッダーの値
[置換テンプレート](iot-substitution-templates.md)をサポート: はい
ペイロードが JSON 形式の場合、デフォルトのコンテンツタイプは application/json です。それ以外の場合は、application/octet-stream です。キー content-type (大文字と小文字を区別しない) でヘッダー内の正確なコンテンツタイプを指定することで、上書きできます。
`auth`
(オプション) `url` 引数で指定されたエンドポイント URL に接続するためにルールエンジンが使用する認証。現在、サポートされている認証タイプは署名バージョン 4 のみです。認可の詳細については、「[HTTP 承認](https://docs.aws.amazon.com/iot/latest/apireference/API_HttpAuthorization.html)」を参照してください。
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`enableBatching`
(オプション) HTTP アクションメッセージを特定の URL に対する 1 つのリクエストに処理するかどうか。値は true または false にすることができます。バッチ処理の詳細については、[「HTTP アクションメッセージのバッチ処理](http_batching.md)」を参照してください。
ブール値
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`batchConfig`
(オプション) バッチ処理の設定。有効にしたら、`batchConfig`パラメータを指定する必要があります。`batchConfig` パラメータを指定しない場合、デフォルト値が使用されます。
`maxBatchOpenMs`
送信メッセージが他のメッセージがバッチを作成するのを待機する最大時間 (ミリ秒単位）。設定が高いほど、バッチ処理された HTTP アクションのレイテンシーが長くなります。
最小値: 5 ミリ秒。最大値: 200 ミリ秒。
デフォルト値: 20 ミリ秒
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`maxBatchSize`
1 回のアクション実行でまとめてバッチ処理されるメッセージの最大数。
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
最小値: 2 メッセージ。最大値: 10 メッセージ
デフォルト値: 10 メッセージ
`maxBatchSizeBytes`
メッセージバッチの最大サイズ、バイト単位。
最小値: 100 バイト。最大値: 131,072 バイト
デフォルト値: 5,120 バイト
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
ペイロードが JSON 形式の場合、デフォルトのコンテンツタイプは application/json です。それ以外の場合は、application/octet-stream です。キー content-type (大文字と小文字を区別しない) でヘッダー内の正確なコンテンツタイプを指定することで、上書きできます。
## 例
次の JSON の例では、HTTP アクションを使用して AWS IoT ルールを定義します。
```
{
"topicRulePayload": {
"sql": "SELECT * FROM 'some/topic'",
"ruleDisabled": false,
"awsIotSqlVersion": "2016-03-23",
"actions": [
{
"http": {
"url": "https://www.example.com/subpath",
"confirmationUrl": "https://www.example.com",
"headers": [
{
"key": "static_header_key",
"value": "static_header_value"
},
{
"key": "substitutable_header_key",
"value": "${value_from_payload}"
}
]
}
}
]
}
}
```
```
"http": {
"url": "https://www.example.com/subpath",
"confirmationUrl": "https://www.example.com",
"headers": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"enableBatching": true,
"batchConfig": {
"maxBatchOpenMs": 123,
"maxBatchSize": 5,
"maxBatchSizeBytes": 131072,
}
},
"errorAction": {
"http": {
"url": "https://www.example.com/subpath",
"confirmationUrl": "https://www.example.com"
// batchConfig is not allowed here
}
}
```
## HTTP アクションの再試行ロジック
AWS IoT ルールエンジンは、次のルールに従って HTTP アクションを再試行します。
+ ルールエンジンは、1 回以上メッセージの送信を試みます。
+ ルールエンジンは、最大で 2 回再試行します。最大試行回数は 3 回です。
+ 次の場合、ルールエンジンは再試行を試行しません。
+ 前回の試行で 16,384 バイトを超える応答が提供された場合。
+ ダウンストリームウェブサービスまたはアプリケーションが試行後に TCP 接続を閉じた場合。
+ 再試行を含むリクエストを完了するための合計時間が、リクエストタイムアウト制限を超えた場合。
+ リクエストが 429、500～599 以外の HTTP ステータスコードを返した場合。
**注記**
再試行には、[標準データ転送コスト](https://aws.amazon.com/ec2/pricing/on-demand/)が適用されます。
## 関連情報
+ [HTTP アクションメッセージのバッチ処理](http_batching.md)
+ [HTTP アクションの送信先](http-action-destination.md)
+ ブログの*モノのインターネット AWS*で、 [からウェブサービス AWS IoT Core にデータを直接ルーティング](https://aws.amazon.com/blogs/iot/route-data-directly-from-iot-core-to-your-web-services/)する
# HTTP アクションメッセージのバッチ処理
バッチ処理を使用して、1 つのリクエストで複数の HTTP アクションメッセージを送信できます。
## 概要:
バッチ処理を使用すると、 AWS IoT Core ルールエンジンから HTTP エンドポイントにバッチでメッセージを送信できます。この機能は、HTTP アクションの実行数を減らすことでコストを削減し、新しい接続の確立に関連するオーバーヘッドを減らすことで効率を向上させるのに役立ちます。
**注記**
バッチ処理された HTTP アクションは 1 つのアクションとして計測されます。 AWS IoT Core ルールエンジンからダウンストリームサービスに出力されるバッチ処理されたアウトバウンドペイロードのサイズに基づいて、5 kiB 単位で計測されます。詳細については、[AWS IoT Core 料金表ページ](https://aws.amazon.com/iot-core/pricing/) を参照してください。
IoT ルールアクションの定義でバッチ処理を有効にすると、次のパラメータを設定できるようになります。
`maxBatchOpenMs`
送信メッセージが他のメッセージがバッチを作成するのを待機する最大時間 (ミリ秒単位）。設定が高いほど、バッチ処理された HTTP アクションのレイテンシーが長くなります。
最小値: 5 ミリ秒。最大値: 200 ミリ秒。
デフォルト値: 20 ミリ秒
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`maxBatchSize`
1 回の IoT ルールアクション実行でまとめてバッチ処理されるメッセージの最大数。
最小値: 2 メッセージ。最大値: 10 メッセージ
デフォルト値: 10 メッセージ
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
`maxBatchSizeBytes`
メッセージバッチの最大サイズ、バイト単位。
最小値: 100 バイト。最大値: 131,072 バイト
デフォルト値: 5120 バイト
[置換テンプレート](iot-substitution-templates.md)をサポート: いいえ
**重要**
複数のバッチパラメータを指定すると、最初の制限に達するとバッチ処理が完了します。たとえば、最大バッチオープン時間として 100 ミリ秒、最大バッチサイズとして 5 kiB を指定し、ルールエンジンが 100 ミリ秒以内に 2 kiB のみをバッチ処理する場合、2 kiB バッチが作成されて送信されます。
## バッチでの HTTP ヘッダーの使用
HTTP アクションでヘッダーを使用する場合、バッチ処理されたリクエストは、バッチに追加された最後のメッセージ (最後に発行したメッセージではない) のヘッダー値を使用します。次のいずれかのヘッダー値を使用することをお勧めします。
+ バッチ内のすべてのメッセージで同一
+ すべてのメッセージに適用可能 (認証情報など)
ヘッダーは HTTP リクエストとともに送信され、メッセージ本文の一部ではありません。
**注記**
バッチ処理が有効になっている場合:
バッチ処理されたリクエストには、バッチが JSON 配列として送信されるため、 `Content-Type: application/json`ヘッダーが自動的に含まれます。
バッチ内の最後のメッセージが、発行した最後のメッセージであることを保証することはできません。これは、バッチに書き込まれた最後のメッセージです。
## ペイロードの例
次の例は、HTTP エンドポイントに送信されるバッチ処理されたメッセージペイロードの構造を示しています。
```
[
{
"user_id": "user1",
"steps_today": 1000
},
{
"user_id": "user2",
"steps_today": 21000
},
{
"user_id": "user8",
"steps_today": 1500
},
...
]
```
## 制限事項
バッチ処理の制限は次のとおりです。
+ AWS IoT Core は、メッセージの全体的な順序付けを保証しません。バッチ処理は各ホストでローカルに実行されるため、バッチ内のメッセージが受信された順序とは異なる順序で処理される可能性があります。
+ AWS IoT Core は、受信者側でメッセージ処理をサポートしていません。ダウンストリームサービスがデータをバッチで受け入れて処理するように設定されていることを確認するのはお客様の責任です。
+ クロスアカウントバッチ処理は、メッセージが同じリソース識別子 (HTTP URL またはリソース ARN) 宛てであってもサポートされていません。
+ AWS IoT Core は、バッチサイズが指定した設定を満たすことを保証するものではありません。バッチは、タイミングとメッセージフローに基づいて設定された制限よりも小さい場合があります。
+ バッチ処理が有効になっている場合、バイナリペイロード (UTF-8 以外のデータ) はサポートされていません。UTF-8 テキストペイロード (JSON など) のみが受け入れられます。バイナリデータを送信するには、base64 でエンコードしてから HTTP アクションに送信し、受信エンドポイントでデコードします。たとえば、IoT ルールの[エンコード関数](iot-sql-functions.html#iot-function-encode)を使用してバイナリペイロードをエンコードできます。または、IoT デバイスでバイナリペイロードをエンコードして公開することもできます AWS IoT Core。
## バッチ処理のエラーアクション
エラーアクション定義で別のバッチロジックを定義することはできません。ただし、プライマリアクションでバッチ処理ロジックを定義している場合、エラーアクションはバッチ処理をサポートします。
バッチリクエストが失敗すると、 AWS IoT Core ルールエンジンは [HTTP アクションの再試行ロジック](https-rule-action.md#https-rule-action-retry-logic)に従います。最後の再試行後、失敗したバッチ全体に対してエラーアクションが呼び出されます。
バッチ処理が有効になっているエラーメッセージの例を次に示します。
```
{
"ruleName": "FailedTopicRule",
"topic": "topic/rulesengine",
"payloadsWithMetadata": [
{
"id": 1,
"cloudwatchTraceId": "bebd6d93-6d4a-899e-9e40-56e82252d2be",
"clientId": "Test",
"sourceIp": "10.0.0.0",
"base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0="
},
{
"id": 2,
"cloudwatchTraceId": "af94d3b8-0b18-1dbf-2c7d-513f5cb9e2e1",
"clientId": "Test",
"sourceIp": "10.0.0.0",
"base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0="
},
{
"id": 3,
"cloudwatchTraceId": "ca441266-c2ce-c916-6aee-b9e5c7831675",
"clientId": "Test",
"sourceIp": "10.0.0.0",
"base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0="
}
],
"failures": [
{
"affectedIds": [
1,
2,
3
],
"failedAction": "HttpAction",
"failedResource": "https://example.foobar.com/HttpAction",
"errorMessage": "HttpAction failed to make a request to the specified endpoint. StatusCode: 500. Reason: Internal Server Error."
},
{
"affectedIds": [
3
],
"failedAction": "S3Action",
"failedResource": "amzn-s3-demo-bucket",
"errorMessage": "Failed to put S3 object. The error received was The specified bucket does not exist"
},
{
"affectedIds": [
3
],
"failedAction": "LambdaAction",
"failedResource": "arn:aws:lambda:us-west-2:123456789012:function:dummy",
"errorMessage": "Failed to invoke lambda function. Received Server error from Lambda. The error code is 403"
}
]
}
```
**注記**
バッチ処理されたアクションの失敗は、より大きなエラーアクションペイロードも生成するため、サイズによるエラーアクションの失敗の可能性が高くなる可能性があります。`ErrorActionFailure` メトリクスを使用して、エラーアクションの失敗をモニタリングできます。詳細については「[ルールアクションのメトリクス](metrics_dimensions.md#rule-action-metrics)」を参照してください。
## を使用した HTTP アクションメッセージのバッチ処理 AWS CLI
### バッチ処理によるルールアクションの作成または更新
1. 適切な AWS CLI コマンドを使用して、ルールを作成または更新します。
+ 新しいルールを作成するには、[create-topic-rule](https://docs.aws.amazon.com/cli/latest/reference/iot/create-topic-rule.html) コマンドを使用します。
```
aws iot create-topic-rule --rule-name myrule --topic-rule-payload file://myrule.json
```
+ 既存のルールを更新するには、 [replace-topic-rule](https://docs.aws.amazon.com/cli/latest/reference/iot/replace-topic-rule.html) コマンドを使用します。
```
aws iot replace-topic-rule --rule-name myrule --topic-rule-payload file://myrule.json
```
1. トピックルールペイロードで enableBatching パラメータを true に設定して、バッチ処理機能を有効にします。
```
{
"topicRulePayload": {
"sql": "SELECT * FROM 'some/topic'",
"ruleDisabled": false,
"awsIotSqlVersion": "2016-03-23",
"actions": [
{
"http": {
"url": "https://www.example.com/subpath",
"confirmationUrl": "https://www.example.com",
"headers": [
{
"key": "static_header_key",
"value": "static_header_value"
},
{
"key": "substitutable_header_key",
"value": "${value_from_payload}"
}
],
"enableBatching": true,
"batchConfig": {
"maxBatchOpenMs": 100,
"maxBatchSize": 5,
"maxBatchSizeBytes": 1024
}
}
}
]
}
```
1. バッチ処理パラメータを設定します。すべてのバッチパラメータを指定する必要はありません。1、2、または 3 つのバッチパラメータすべてを指定できます。バッチパラメータを指定しない場合、ルールエンジンはそのパラメータをデフォルト値で更新します。バッチパラメータとそのデフォルト値の詳細については、[「HTTP パラメータ](https-rule-action.md#https-rule-action-parameters)」を参照してください。
# HTTP アクションの送信先
HTTP アクションの送信先は、ルールエンジンがトピックルールからデータをルーティングできるウェブサービスです。 AWS IoT Core リソースは、 のウェブサービスを記述します AWS IoT。送信先リソースは、異なるルールで共有できます。
AWS IoT Core が別のウェブサービスにデータを送信する前に、サービスのエンドポイントにアクセスできることを確認する必要があります。
## 概要:
HTTP アクションの送信先は、確認 URL と 1 つ以上のデータ収集 URLs。送信先リソースには、ウェブサービスの確認 URL が含まれています。HTTP アクションを設定するときは、データを受信するエンドポイントの実際の URL とウェブサービスの確認 URL を指定します。送信先が確認されると、トピックルールは、SQL ステートメントの結果を HTTPS エンドポイントに送信します (確認 URL ではない)。
HTTP アクションの送信先は、次のいずれかの状態になります。
有効
送信先は確認済みで、ルールアクションによって使用できます。送信先をルールで使用するには、送信先は、`ENABLED`の状態である必要があります。有効にできるのは、「DISABLED」ステータスの送信先のみです。
無効
送信先は確認されましたが、ルールアクションでは使用できません。これは、確認プロセスを再度実行することなく、エンドポイントへのトラフィックを一時的に防止する場合に便利です。無効にできるのは、有効ステータスの送信先のみです。
IN\$1PROGRESS
送信先の確認は進行中です。
ERROR
送信先の確認がタイムアウトしました。
HTTP アクションの送信先を確認して有効にすると、アカウントの任意のルールで使用できます。
## HTTP アクションの送信先の管理
次のオペレーションを使用して、HTTP アクションの送信先を管理できます。
### HTTP アクションの送信先の作成
HTTP アクションの送信先を作成するには、 `CreateTopicRuleDestination`オペレーションを呼び出すか、 AWS IoT コンソールを使用します。
送信先を作成すると、 は確認 URL に確認リクエスト AWS IoT を送信します。確認リクエストの形式は次のとおりです。
```
HTTP POST {confirmationUrl}/?confirmationToken={confirmationToken}
Headers:
x-amz-rules-engine-message-type: DestinationConfirmation
x-amz-rules-engine-destination-arn:"arn:aws:iot:us-east-1:123456789012:ruledestination/http/7a280e37-b9c6-47a2-a751-0703693f46e4"
Content-Type: application/json
Body:
{
"arn":"arn:aws:iot:us-east-1:123456789012:ruledestination/http/7a280e37-b9c6-47a2-a751-0703693f46e4",
"confirmationToken": "AYADeMXLrPrNY2wqJAKsFNn-…NBJndA",
"enableUrl": "https://iot.us-east-1.amazonaws.com/confirmdestination/AYADeMXLrPrNY2wqJAKsFNn-…NBJndA",
"messageType": "DestinationConfirmation"
}
```
確認リクエストの内容には、以下の情報が含まれます。
arn
確認する HTTP アクションの送信先の Amazon リソースネーム (ARN)。
confirmationToken
によって送信された確認トークン AWS IoT Core。この例のトークンは切り捨てられます。トークンは長くなります。 AWS IoT Coreで目的地を確認するには、このトークンが必要です。
enableUrl
トピックルールの送信先を確認するために参照する URL。
messageType
メッセージのタイプ。
### HTTP アクションの送信先の確認
エンドポイントの確認プロセスを完了するには、 AWS CLIを使用している場合、確認 URL が確認リクエストを受信した後、次のいずれかの手順を実施する必要があります。
1.
**送信先がメッセージを受信する準備ができていることを確認する**
HTTP アクションの送信先が IoT メッセージを受信する準備ができていることを確認するには、確認リクエスト`enableUrl`で を呼び出すか、 `ConfirmTopicRuleDestination` API オペレーションを実行して確認リクエスト`confirmationToken`から を渡します。
1.
**トピックルールのステータスを有効に設定する**
送信先がメッセージを受信できることを確認したら、`UpdateTopicRuleDestination` API オペレーションを実行してトピックルールのステータスを `ENABLED` に設定する必要があります。
AWS IoT コンソールを使用している場合は、 をコピー`confirmationToken`し、 AWS IoT コンソールの送信先の確認ダイアログに貼り付けます。その後、トピックルールを有効にできます。
### 新しい確認リクエストの送信
送信先の新しい確認メッセージをアクティブ化するには、`UpdateTopicRuleDestination` を呼び出 して、トピックルールの送信先のステータスを `IN_PROGRESS` に設定します。
新しい確認リクエストを送信した後、確認プロセスを繰り返します。
### HTTP アクションの送信先の無効化と削除
送信先を無効にするには、`UpdateTopicRuleDestination`を呼び出して、トピックルールの送信先のステータスを `DISABLED` に設定します。無効状態のトピックルールは、新しい確認要求を送信しなくても、再度有効にすることができます。
HTTP アクションの送信先を削除するには、 を呼び出します`DeleteTopicRuleDestination`。
## 認証機関のサポート
**注記**
自己署名証明書はサポートされていません。
HTTP アクションの送信先の HTTPS エンドポイントは、[AWS プライベート認証機関](https://www.amazontrust.com/repository/)と [Lets Encrypt ](https://letsencrypt.org/certificates/)の両方によって発行された証明書をサポートします。