# アクション アクションは、処理されたデータの取り扱い方法を定義するためにルールに追加できます。ルールは1つ以上のアクションに対応でき、アクションはデータの送信先である定義済みのコネクターとともに設定する必要があります。 ## アクションの追加 ルールを作成した後、**New Rule** ステップページの **Next** ボタンをクリックすると、**New Action (Sink)** ステップページに進みます。そのページで、**Connector** ドロップダウンボックスから関連するコネクターを選択します。選択したコネクターの種類に応じて、異なるアクション設定オプションが表示されます。詳細なアクション設定例は、[Add Republish Action](#add-republish-action) および [Add Action for Forwarding Data to Target Services](#add-action-for-forwarding-data-to-target-services) を参照してください。 ルールは複数のアクションに関連付けることができます。アクション作成を完了するために **Confirm** をクリックすると、**Successful new rule** ポップアップが表示されます。別のアクションを追加したい場合は、**Back to Rules** をクリックして戻り、別のコネクターを選択してください。例えば、1つのアクションはデータを Kafka に転送し、別のアクションは HTTP サービスにデータを送信することが可能です。 ### Republish アクションの追加 以下の手順は、トピックから受信した元のメッセージを別のトピック（例：`a/1`）に再パブリッシュするアクションを追加する方法を示します。 1. **Connector** ドロップダウンボックスから **Republish** を選択します。 2. 以下の設定を行います： - **Topic**：ターゲットトピックを設定します。この例では `a/1`。 - **QoS**：再パブリッシュするメッセージの QoS を設定します。この例では `0`。 - **Retain**：このメッセージをリテインメッセージとして転送するかどうかを設定します。本チュートリアルではデフォルトの `false` のままにします。 - **Payload**：`${payload}` を入力します。これは再パブリッシュされるメッセージのペイロードが元のメッセージと同じであることを示し、変更は加えません。 - **MQTT 5.0 Message Properties**：必要に応じてユーザープロパティや MQTT プロパティを設定するためにトグルスイッチをクリックします。これらのプロパティオプションは、再パブリッシュされるメッセージに対して豊富なメタデータ記述を追加できます。 - **Payload Format Indicator**：メッセージのペイロードが特定の形式かどうかを示す値を入力します。`false` に設定するとメッセージは未定義のバイト列と見なされ、`true` に設定するとメッセージ本文のペイロードは UTF-8 エンコードされた文字データであることを示します。これにより MQTT クライアントや MQTT ブローカーがメッセージ内容を効率的に解析できます。 - **Message Expiry Interval**：メッセージが配信されなかった場合に無効とみなされるまでの有効期限（秒単位）を指定します。 - **Content Type**：再パブリッシュされるメッセージのペイロード内容のタイプまたはフォーマット（MIMEタイプ）を指定します。例として `text/plain`（テキストファイル）、`audio/aac`（音声ファイル）、`application/json`（JSON形式のアプリケーションメッセージ）などがあります。 - **Response Topic**：レスポンスメッセージをパブリッシュする特定の MQTT トピックを入力します。例えば、レスポンスを `"response/my_device"` というトピックに送信したい場合は `response/my_device` と入力します。 - **Correlation Data**：レスポンスメッセージと元のリクエストメッセージを関連付けるための一意の識別子やデータを入力します。例として一意のリクエストIDやトランザクションID、またはアプリケーションの文脈で意味のある任意の情報を入力できます。 3. **Confirm** をクリックしてアクション作成を完了します。 4. **Successful new rule** ポップアップで **Back to Rules** をクリックし、ルール作成を完了します。 メッセージの再パブリッシュアクションを含む完全なデータ統合プロセスの作成とテストについては、[Message Republish](./republish.md) を参照してください。 ### ターゲットサービスへのデータ転送アクションの追加 関連するコネクターを使用して処理結果をターゲットサービスに転送するアクションも追加できます。**New Action** ステップページで、コネクターのドロップダウンリストからターゲットコネクターを選択します。アクション設定の詳細については、[Ingest MQTT Data into HTTP Server](./http_server.md) および [Stream MQTT Data into Apache Kafka](./kafka.md) を参照してください。 ## フォールバックアクション ::: tip 注意 フォールバックアクション機能は、EMQX バージョン 5.91 以降の専用エディションで利用可能です。 ::: 任意のアクションに対して最大2つまでのフォールバックアクションを定義できます。プライマリアクションがメッセージの処理に失敗した場合に、これらのフォールバックアクションがトリガーされます。この仕組みにより、メッセージを別の Sink や再パブリッシュアクションなどのセカンダリターゲットにリダイレクトでき、データの信頼性と可観測性が向上します。 フォールバックアクションは以下の用途に利用できます： - 失敗したメッセージをバックアップデータシステム（例：別の Sink）に転送する。 - 失敗したメッセージを監視用トピックに再パブリッシュし、トラブルシューティングやアラートに活用する。 - プライマリアクションの一時的な問題によるデータ損失を最小限に抑える。 ### 主な特徴 - フォールバックアクションは、プライマリアクションがメッセージ処理に失敗した場合のみトリガーされます。失敗には配信エラー、バッファオーバーフロー、リクエストTTLの期限切れが含まれます。 - フォールバックアクションは自身の設定に関わらず常に非同期リクエストモードで動作します。 - 2つのフォールバックアクションが定義されている場合、同時にトリガーされます。EMQX プラットフォームは順番に試行したり、最初の成功で停止したりしません。 - フォールバックアクションは通常のアクションと同じバッファリング機構を共有しており、メッセージはリクエストTTLまで、またはバッファオーバーフローが発生するまでリトライされます。 - フォールバックアクションはさらに別のフォールバックアクションをトリガーしません。フォールバックアクション自体が失敗しても、そのフォールバックアクション（もし設定されていれば）はトリガーされません。 - フォールバックアクションによるメッセージ処理は、プライマリアクションやそれをトリガーした元のルールのメトリクスに影響を与えません。