Configuring Asynchronous Execution Notification
Overview
Functions can be invoked synchronously or asynchronously. In asynchronous mode, FunctionGraph sends a response immediately after persisting a request. The request result cannot be known in real time. To retry when an asynchronous request fails or obtain asynchronous processing results, configure asynchronous settings.
Scenario
- Retry: By default, FunctionGraph does not retry if a function fails due to a code error. If your function needs retry, for example, if third-party services often fail to be invoked, configure retry to improve the success rate.
- Result notifications: FunctionGraph automatically notifies downstream services of the asynchronous execution result of a function for further processing. For example, storing execution failure information in OBS for cause analysis, or pushing execution success information to DIS or triggering the function again.
Procedure
- Log in to the FunctionGraph console. In the navigation pane, choose Functions > Function List.
- Click the function to be configured to go to the function details page.
- Choose Configuration > Configure Async Notification. On the displayed page, click Edit next to Asynchronous Notification Policy.
Figure 1 Configuring an asynchronous notification policy
- Set parameters by referring to Table 1. For example, specify FunctionGraph for Target Service.
Figure 2 Setting parameters
Table 1 Parameter description Parameter
Description
Asynchronous Execution Notification Policy
- Max. Retries: maximum number of retries when asynchronous invocation fails. Value range: 0–3. Default value: 1.
- Max. Validity Period (s): maximum lifetime of a message in seconds. Value range: 1–86,400.
Success Notification
Target Service: to which a notification will be sent if a function is executed successfully.
- FunctionGraph
- OBS
Failure Notification
Target Service: to which a notification will be sent if a function fails to be executed.
- FunctionGraph
- OBS
- Click OK.
- Set an agency that allows FunctionGraph to access the target service.
- To avoid cyclic invocation, do not set two functions as asynchronous execution targets of each other.
Configuration Description
For details about how to set the target for asynchronous invocation, see Table 2. The following shows an example:
{ "timestamp": "2020-08-20T12:00:00.000Z+08:00", "request_context": { "request_id": "1167bf8c-87b0-43ab-8f5f-26b16c64f252", "function_urn": "urn:fss:xx-xxxx-x:xxxxxxx:function:xxxx:xxxx:latest", "condition": "", "approximate_invoke_count": 0 }, "request_payload": "", "response_context": { "status_code": 200, "function_error": "" }, "response_payload": "hello world!" }
Parameter |
Description |
---|---|
timestamp |
Time when the invocation starts. |
request_context |
Request context. |
request_context.request_id |
ID of an asynchronous invocation request. |
request_context. function_urn |
URN of the function that is to be executed asynchronously. |
request_context.condition |
Invocation error type. |
request_context. approximate_invoke_count |
Number of asynchronous invocation times. If the value is greater than 1, function execution has been retried. |
request_payload |
Original request payload. |
response_context |
Response context. |
response_context.statusCode |
Code returned after function invocation. If the code is not 200, a system error occurred. |
response_context.function_error |
Invocation error information. |
response_payload |
Payload returned after function execution. |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot