Invoking the Function
After a function is created and configured, you can trigger the function execution through RESTful APIs or cloud service events.
- RESTful API: Functions are triggered by calling APIs.
- Cloud service events: Functions are triggered by cloud service triggers.
Functions can be invoked synchronously or asynchronously, depending on whether the client needs to wait for the processing result.
Synchronous invocation: After a client invokes a function, FunctionGraph executes the function immediately and returns a response and execution result to the client.
Scenarios:
Synchronous invocation is suitable for scenarios that require real-time response.
Example 1: Real-time data processing and query
Use synchronous invocation to obtain real-time data (such as order status and payment result) and process requests and return results immediately.
Example 2: Instant interaction and control
Use synchronous invocation to obtain operation results (such as message sending success) immediately.
Asynchronous invocation: After a client invokes a function, FunctionGraph queues the requests and directly returns responses to the client without waiting for the function execution result. FunctionGraph processes the queued requests one by one when the server is idle.
In asynchronous invocation scenarios, the client cannot detect the function execution result in real time. For details about how to obtain the request result or set retry upon failure, see Asynchronous Notification Policy. You can also use the asynchronous execution API instead.
Scenarios:
Asynchronous invocation is suitable for tasks that can be processed later, do not require real-time response, and may take a long time or require a large number of resources. This approach enhances system responsiveness and throughput while ensuring reliable task execution.
Example 1: media processing and conversion
- Image compression and format conversion: After an image is uploaded, the system asynchronously processes the image in the background, compresses, crops, or converts the image format, and stores the processed image in a specified location.
- Video transcoding and editing: After a video is uploaded, the system asynchronously transcodes, edits, or adds watermarks to the video in the background. Asynchronous invocation frees up system resources during lengthy operations.
Example 2: data processing and integration
- ETL tasks (data cleaning and conversion): Extract data from databases periodically, cleanse, convert, and load the data to the target storage service or analysis platform. Reports are generated upon completion with notifications. Asynchronous invocation prevents system blocking and improves processing efficiency.
- Log analysis and statistics: After system logs are collected, log analysis, exception detection, and statistics are performed asynchronously in the background. Results are stored or sent to monitoring systems upon completion. Asynchronous invocation ensures that the system can run properly during peak hours.
Notes and Constraints
- A function with synchronous invocation is executed for up to 15 minutes.
- A function with asynchronous invocation is executed for up to 3 days. For longer execution duration, submit a service ticket.
You can customize the execution timeout on the function details page. For details, see Basic Settings. The execution timeout must be less than the maximum execution duration.
- If the end-to-end execution latency exceeds 90s, you are advised to use asynchronous invocation. If synchronous invocation is used, no responses can be received after 90s due to gateway restrictions.
Function Trigger Invocation Mode
Triggers can be invoked synchronously or asynchronously. For details about function invocation, see Invoking the Function.
- Synchronous invocation: After a client invokes a function, FunctionGraph executes the function immediately and returns a response and execution result to the client.
- Asynchronous invocation: After a client invokes a function, FunctionGraph queues the requests and directly returns responses to the client without waiting for the function execution result. FunctionGraph processes the queued requests one by one when the server is idle.
Trigger |
Invocation Mode |
---|---|
API Gateway (dedicated) |
Synchronous. You can change it to asynchronous. For details, see Configuring Asynchronous Invocation. |
API Connect (APIC) |
Synchronous. You can change it to asynchronous. For details, see Configuring Asynchronous Invocation. |
Timer |
Synchronous (default and cannot be changed) |
Cloud Trace Service (CTS) |
Asynchronous (default and cannot be changed) |
Document Database Service (DDS) |
Asynchronous (default and cannot be changed) |
Data Ingestion Service (DIS) |
Asynchronous (default and cannot be changed) |
DMS (for Kafka) |
Asynchronous (default and cannot be changed) |
Kafka (Open-Source) |
Asynchronous (default and cannot be changed) |
DMS (for RabbitMQ) |
Asynchronous (default and cannot be changed) |
GeminiDB Mongo |
Asynchronous (default and cannot be changed) |
Log Tank Service (LTS) |
Asynchronous (default and cannot be changed) |
Simple Message Notification (SMN) |
Asynchronous (default and cannot be changed) |
EventGrid (EG) |
Asynchronous (default and cannot be changed) |
Configuring Asynchronous Invocation
The following uses an APIG trigger as an example. Ensure you have created a function and configured an APIG trigger.
- Log in to the FunctionGraph console, and choose Functions > Function List in the navigation pane. Click a function name to go to its details page. Choose Configuration > Triggers.
- Click the APIG trigger name to go to the APIG console.
Figure 1 Clicking a trigger name
- Click Modify in the upper right.
Figure 2 Clicking Modify
- Click Next. On the Basic Information page, change the Invocation Mode to Asynchronous.
Figure 3 Changing the invocation mode
- Click Finish to save the settings.
Retry Mechanism
If synchronous or asynchronous invocation fails, do as follows:
- Synchronous invocation
- Asynchronous invocation
You can configure the maximum number of retries and the maximum message validity period (up to 24 hours) by referring to Asynchronous Notification Policy.
FunctionGraph will retry a function based on these two parameters.
Idempotency
In programming, idempotency means that an application or component can identify duplicate events and prevent duplication, inconsistency, and data loss. If you want to keep a function idempotent, you need to design the function logic to correctly handle repeated events.
Idempotent function logic helps reduce the following problems:
- Unnecessary API calls
- Code processing time
- Data inconsistency
- Restrictions
- Latency
Ensure that your function code can process the same event multiple times without causing duplicate transactions or other unnecessary side effects in case of abnormal calls, retry of client, or retry within dependent functions.
Helpful Links
- Invoke functions using APIs. For details, see Executing a Function Synchronously and Executing a Function Asynchronously.
- For details about FAQs about function invocation, see Function Invocation FAQs.
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