Actions

Actions can be appended to a rule to define how the processed data is handled. A rule can correspond to one or more actions, and actions need to be set with defined connectors, which means where the data is sent.

Add Actions

After you have created the rule, click the Next button on the New Rule step page to proceed to the New Action (Sink) step page. On that page, select the associated Connector from the Connector dropdown box. The page will display different action configuration options based on the type of associated Connector selected. See the detailed action configuration examples in Add Republish Action and Add Action for Forwarding Data to Target Services.

A rule can be associated with multiple actions. When you click Confirm to complete the action creation, a Successful new rule pop-up appears. If you want to add another action, you can click Back to Rules to proceed and select another Connector. For example, one action can forward data to Kafka while another action sends data to an HTTP service.

Add Republish Action

The following steps demonstrate how to add an action to republish the original messages received from a topic to another topic, such as a/1.

1. Select Republish from the Connector dropdown box.
2. Configure the following settings:
   • Topic: Set the target topic, a/1 in this example.
   • QoS: Set the QoS of the republished message, 0 in this example;
   • Retain: Set whether to forward this message as a retained message; for this tutorial, keep the default setting, false;
   • Payload: Enter ${payload}, indicating the republished message will have the same payload as the original message, without any modifications.
   • MQTT 5.0 Message Properties: Click the toggle switch to configure the user properties and MQTT properties as necessary. The properties options allow you to add rich message metadata descriptions for the republished message.
     • Payload Format Indicator: Enter a value to indicate whether the payload of the message is in a specific format. When the value is set to false, the message is considered as undetermined bytes. When set to true, it indicates that the payload within the message body is UTF-8 encoded character data. This will help MQTT clients or MQTT servers parse message content more efficiently without the need for explicit formatting or type identification for the message body.
     • Message Expiry Interval: Enter a value (in seconds) to specify a time interval after which the message should expire and be considered invalid if it hasn't been delivered to the intended recipient.
     • Content Type: Enter a value to specify the type or format of the payload content within the republished message (MIME type), for example, text/plain represents a text file, audio/aac represents an audio file, and application/json signifies an application message in JSON format.
     • Response Topic: Enter the specific MQTT topic to which you want the response message to be published. For example, if you want responses to be sent to a topic named "response/my_device," you would enter: response/my_device.
     • Correlation Data: Enter a unique identifier or data to correlate a response message with the original request message. For example, you could enter a unique request identifier, a transaction ID, or any other information that is meaningful in your application context.
3. Click Confirm to complete the action creation.
4. In the Successful new rule pop-up, click Back to Rules to complete the rule creation.

To create and test a complete data integration process with a message republish action, see Message Republish.

Add Action for Forwarding Data to Target Services

You can also add actions to forward the processed results to target services using associated Connectors. On the New Action step page, select the target Connector from the Connector drop-down list. For details on the action configuration, see Ingest MQTT Data into HTTP Server and Stream MQTT Data into Apache Kafka.

Fallback Actions

Note

The Fallback Actions feature is available for EMQX versions 5.91 and later in the Dedicated edition.

You can define one or two (at most) fallback actions for any given action. These fallback actions will be triggered when the primary action fails to process a message. This mechanism helps improve data reliability and observability by allowing messages to be redirected to secondary targets such as another Sink or a republish action.

Fallback actions can be used to:

• Forward failed messages to a backup data system (e.g., another Sink).
• Republish failed messages to a monitoring topic for troubleshooting or alerting.
• Minimize data loss in the event of temporary issues with the primary action.

Key Characteristics

• Fallback actions are triggered only when the primary action fails to process a message. Failures include delivery errors, buffer overflow, and request TTL expiry.
• They always operate in asynchronous request mode, regardless of their own configuration.
• If two fallback actions are defined, they will be triggered concurrently. EMQX Platform does not attempt them one-by-one or stop at the first success.
• Fallback actions share the same buffering mechanism as regular actions, meaning messages are retried up to their request TTL or if there is buffer overflow.
• Fallback actions do not trigger further fallback actions. If a fallback action itself fails, its own configured fallback actions (if any) will not be triggered.
• Processing of messages by fallback actions do not affect metrics of their primary actions or of the original rule that triggered the primary action.