The content of this page has been automatically translated by AI. If you encounter any problems while reading, you can view the corresponding content in Chinese.
The rule engine allows you to configure forwarding rules to forward eligible data reported by devices to TencentDB for MongoDB. After you create an instance in the TencentDB for MongoDB console or through TencentCloud API, device messages can be written to the corresponding TencentDB for MongoDB set.
Note:
The replica set instance version must not exceed v4.0, and the sharding instance version must be v4.0 or later.
Configuration
Follow the operation guide to create rules and filter data, then add behavior operations and select forwarding to TencentDB for MongoDB.
Note:
When using for the first time, users will be prompted to authorize access to MongoDB. You need to click Authorize Now to continue creating.
Enter the Add Behavior page and select the "Data Forwarding to Cloud Database (MongoDB) Option".
After successful authorization, you need to configure the TencentDB for MongoDB instance information. As shown below, the configuration is divided into the following steps:
1.1 Select the region and TencentDB for MongoDB instance. If there are no instances under the account, click create instance to jump to the TencentDB for MongoDB console to create one.
1.2 Enter the username of the TencentDB for MongoDB instance. The default username on the MongoDB official website is mongouser.
1.3 Enter the login password of the TencentDB for MongoDB instance.
1.4 Enter the name of the database to be written to.
1.5 Enter the name of the set to be written to.
Resending Mechanism
The resending mechanism is used to send the message again in case of a failure in the message forwarding process, which makes sure that the message is received. The details are as follows:
If message forwarding fails, the system will retry forwarding at intervals of 1s, 3s, and 10s in sequence. If all three retries fail, the message will be discarded.
If you have configured the "action for forwarding failure", then after three unsuccessful retries, the message will be forwarded again according to the configured action. If forwarding still fails, the message will be discarded.
