This topic describes how to export data to an HTTP function of Function Compute by
using data outflow rules in the Message Queue for MQTT console.
Procedure
The following figure shows the steps to export data to an HTTP function of Function
Compute.
Create an HTTP function of Function Compute
For more information about how to create an HTTP function of Function Compute, see
Create an HTTP function and configure an HTTP trigger.
Note An HTTP function of Function Compute is used in the example of this topic. You can
use this topic as a reference to export data to other types of HTTP services.
Create a Message Queue for MQTT instance
For more information about how to create a Message Queue for MQTT instance, see Create an instance.
Notice Only Message Queue for MQTT instances in the US (Virginia) and US (Silicon Valley) regions support data outflow
to HTTP services. Make sure that your instances reside in the preceding regions.
Create a data outflow rule
Create a data outflow rule to export data from data source topics of Message Queue for MQTT to the HTTP function of Function Compute.
- Log on to the Message Queue for MQTT console. In the top navigation bar, select the region where the instance is located.
- In the left-side navigation pane, click Rules.
- On the Rules page, click Create Rule.
- On the Create Rule panel, click the Data Outflow tab.
- On the Data Outflow tab, configure the following parameters as prompted and click OK.
Type |
Parameter |
Required |
Example |
Description |
Rule Details |
Rule ID |
Yes |
fc_http_rule |
The ID of the rule. The value must meet the following requirements:
- It can contain only letters, digits, hyphens (-), and underscores (_) and must contain
at least one letter or digit.
- It must be 3 to 64 characters in length. If the value contains more than 64 characters,
it is automatically truncated.
|
Rule Description |
Yes |
The data is exported to the HTTP function of Function Compute. |
The description of the rule. |
State |
Yes |
Enable |
Specifies whether to enable the rule. Valid values:
|
Data Source |
Topic |
Yes |
fc-http-test |
The topic of the data source. |
Subscription Expression |
No |
None |
The expression of the subscription. If you do not specify Subscription Expression, all data under the data source topic is forwarded.
- The expression supports the following delimiters:
- Topic-level delimiter, which is a forward slash (/). Example: chat/teacher/room1.
- Single-level wildcard, which is a plus sign (+). Example: chat/+.
- Multi-level wildcard, which is a number sign (#). Example: chat/#.
- You can add a maximum of five expressions.
- The relationship between expressions is OR.
- The expression, excluding the supported delimiters, can contain only letters, digits,
hyphens (-), and underscores (_).
- The expression can be a maximum of 64 characters in length.
|
QOS |
No |
1 |
The service quality of data transmission. If you do not set QOS, all data is forwarded by default. Valid values:
- 0: indicates that data is distributed at most one time.
- 1: indicates that data reaches the service at least one time.
- 2: indicates that data is distributed only one time.
|
Message Validity Period |
Yes |
259200 |
The validity period of messages. If the TTL of a message is less than or equal to
the value, the message is pushed. Unit: seconds. Valid Values: 1 to 259200.
|
Flow Destination |
Type |
Yes |
HTTP |
The type of the destination to which you want export data. |
Endpoint |
Yes |
https://18807708****.cn-hangzhou.fc.aliyuncs.com/2016-08-15/proxy/fc_http_for_mqtt_test/fc_http_function_test/ |
The endpoint of the HTTP service. In this topic, the HTTP function of Function Compute
is used. Therefore, you must enter the path that stores the HTTP trigger of the HTTP
function of Function Compute.
Notice The endpoint can be only a public endpoint.
|
Retry Policy |
No |
None |
The retry policy after data outflow fails. If you do not set Retry Policy, no retries are performed by default.
- The system supports a maximum of five retries.
- The interval between retries is fixed to 60 seconds.
|
On the Rules page, you can view the created rule in the Rule ID column.
(Optional) Perform security verification
After you create a rule that exports data to the HTTP function of Function Compute,
Message Queue for MQTT generates a token for the rule. If you need to verify whether the HTTP requests that
the HTTP function of Function Compute receives are from Message Queue for MQTT, you can use the token to perform signature verification.
- On the Rules page in the Message Queue for MQTT console, find the rule in the Rule ID column and click Details in the Actions column.
- In the Flow Destination section, click the
icon and click the token to copy it.
- Modify the code of the HTTP function to verify the signature of the token based on
the token and the following information.
- The following code provides an example on HTTP requests:
SignatureVersion=1.0
&Format=JSON
&SignatureNonce=ec4f2ea2-78bf-41a7-b1f7-1c9ba30c4d9b160625039****
&Message={
"clientId":"GID_MQTT_CONSOLE@@@lmqshpre011606292****",
"payload":"dGVzdA==",
"qoslevel":"1",
"topic":"fc-http-test"
}
&Version=2020-04-16
&RuleId=fc-http-test
&Signature=8H0vF0fZWTHMSxJUGDF****
&SignatureMethod=HMAC-SHA1
&Timestamp=2020-11-24T20:39:50Z
- The following table describes the parameters in an HTTP request.
Parameter |
Type |
Example |
Description |
SignatureVersion |
String |
1.0 |
The version of the signature encryption algorithm. Set the value to 1.0. |
Format |
String |
JSON |
The format in which to return the response. Set the value to JSON. |
SignatureNonce |
String |
ec4f2ea2-78bf-41a7-b1f7-1c9ba30c4d9b160625039**** |
A unique, random number used to prevent replay attacks. You must use different random
numbers for different requests.
|
Message |
String |
|
The message content. |
clientId |
String |
GID_MQTT_CONSOLE@@@lmqshpre011606292**** |
The ID of the client. |
payload |
String |
dGVzdA== |
The message payload. To prevent HTTP request errors, Message Queue for MQTT Base64 encodes the message payload in the request. For example, if your original
message payload is test, the Base64-encoded content is dGVzdA==.
Notice If you need to retrieve the original message payload, you can call the Base64.decodeBase64()
method to Base64 decode the content.
|
qoslevel |
Integer |
1 |
The service quality of data transmission. |
topic |
String |
fc-http-test |
The topic of the data source. |
Version |
String |
2020-04-16 |
The version number of the API. The value is in the YYYY-MM-DD format. Set the value
to 2020-04-20.
|
RuleId |
String |
fc-http-test |
The ID of the rule. |
Signature |
String |
8H0vF0fZWTHMSxJUGDF**** |
The signature string of the API request. |
SignatureMethod |
String |
HMAC-SHA1 |
The encryption method of the signature string. Set the value to HMAC-SHA1. |
Timestamp |
String |
2020-11-24T20:39:50Z |
The timestamp of the request, which is in the date format. The time must be in the
ISO 8601 standard in the yyyy-MM-ddTHH:mm:ssZ format. In addition, the time must be
in UTC.
|
- For more information about the signature algorithm for HTTP requests, see Signature method.
Use the SDK to connect your terminal to Message Queue for MQTT
Use the SDK for Message Queue for MQTT to connect your terminal to Message Queue for MQTT. This way, the data of your terminal can be exported to the HTTP function of Function
Compute by using the data outflow rule. For more information about Message Queue for MQTT SDKs, see Download the SDK.