アクション

アクションは、処理されたデータの取り扱い方法を定義するためにルールに追加できます。ルールは1つ以上のアクションに対応でき、アクションはデータの送信先を示す定義済みのコネクターとともに設定する必要があります。

アクションの追加

ルールを作成した後、New Rule ステップページの Next ボタンをクリックして、New Action (Sink) ステップページに進みます。そのページで、Connector ドロップダウンボックスから関連付けるコネクターを選択します。選択したコネクターの種類に応じて、異なるアクション設定オプションが表示されます。詳細なアクション設定例は、Add Republish Action および Add Action for Forwarding Data to Target Services を参照してください。

ルールは複数のアクションに関連付けることが可能です。アクション作成を完了するために Confirm をクリックすると、Successful new rule ポップアップが表示されます。別のアクションを追加したい場合は、Back to Rules をクリックして戻り、別のコネクターを選択してください。例えば、あるアクションはデータを 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 クライアントやブローカーはメッセージ内容を効率的に解析できます。
     • 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 を参照してください。

ターゲットサービスへのデータ転送アクションの追加

処理結果を関連付けたコネクターを使ってターゲットサービスに転送するアクションも追加できます。New Action ステップページで、コネクターのドロップダウンリストからターゲットコネクターを選択してください。アクション設定の詳細については、Ingest MQTT Data into HTTP Server および Stream MQTT Data into Apache Kafka を参照してください。

フォールバックアクション

注意

フォールバックアクション機能は、EMQX バージョン 5.91 以降の Dedicated および Dedicated Flex エディションで利用可能です。

任意のアクションに対して、最大2つまでのフォールバックアクションを定義できます。これらのフォールバックアクションは、プライマリアクションがメッセージの処理に失敗した場合にトリガーされます。この仕組みにより、メッセージを別のシンクや再パブリッシュアクションなどの二次ターゲットにリダイレクトできるため、データの信頼性と可観測性が向上します。

フォールバックアクションは以下の用途に利用できます：

• 失敗したメッセージをバックアップデータシステム（例：別のシンク）に転送する。
• 失敗したメッセージを監視用トピックに再パブリッシュし、トラブルシューティングやアラートに活用する。
• プライマリアクションの一時的な問題によるデータ損失を最小限に抑える。

主な特徴

• フォールバックアクションは、プライマリアクションがメッセージの処理に失敗した場合にのみトリガーされます。失敗には配信エラー、バッファオーバーフロー、リクエストTTLの期限切れが含まれます。
• フォールバックアクションは自身の設定に関わらず、常に非同期リクエストモードで動作します。
• 2つのフォールバックアクションが定義されている場合、同時にトリガーされます。EMQX Cloud は順番に試行したり、最初の成功で停止したりしません。
• フォールバックアクションは通常のアクションと同じバッファリング機構を共有しており、メッセージはリクエストTTLまで、またはバッファオーバーフローが発生するまでリトライされます。
• フォールバックアクションはさらに別のフォールバックアクションをトリガーしません。フォールバックアクション自体が失敗した場合、そのフォールバックアクションに設定されたフォールバックアクションはトリガーされません。
• フォールバックアクションによるメッセージ処理は、プライマリアクションやそのアクションをトリガーした元のルールのメトリクスに影響を与えません。