1. Log in to the Serverless console and select Function Service from the left navigation bar.
2. Select the region where to create a function at the top of the page and click Create to enter the function creation process.
3. Choose to create a new function using a template. Filter for WebFunc in the search box to view all HTTP-triggered Function templates. Select the template you wish to use and click Next. As shown in the figure below:
4. On the Configuration page, you can view and modify the specific configuration information of the template project.
5. Click Complete to create the function.
Once the function is created, you can view the basic information of the HTTP-triggered Function on the Function Management page, and access it via the access path URL generated by the API gateway.
Creating custom function
1. Log in to the Serverless console and select Function Service from the left navigation bar.
2. Select the region where to create a function at the top of the page and click Create to enter the function creation process.
3. Choose to create a new function from scratch and fill in the basic function configuration, as shown in the figure below:
Function Type: Select "HTTP-triggered Function".
Function name: Enter the name of your function.
Region: enter your function deployment region.
Runtime Environment: Here, using Nodejs framework as an example, select "Nodejs 12.16".
4. In Advanced Settings, view other required configuration items.
Namespace: the default namespace is used by default. You can select another namespace for deployment.
Start Command: For HTTP-triggered Functions, you must configure the scf_bootstrap startup file for your project to ensure that the Web Server can start normally in the function environment. You can choose the default framework template provided by SCF, or use a custom template to write your own start command. For more details, refer to Startup File Instructions.
5. In Trigger Configuration, triggers currently only support API Gateway triggering and will automatically create triggers according to the default configuration.
6. Click Complete to create the function.
Once the function is created, you can view the basic information of the HTTP-triggered Function on the Function Management page, and access it via the access path URL generated by the API gateway.
Cloud test
Method 1
Method 2
Method 3
You can open the access path URL in your browser. If it can be accessed normally, it indicates that the function has been created successfully. As shown in the following figure:
On the function code page, you can assemble specific HTTP requests for testing through the testing capability. You can determine whether the function has been successfully deployed by examining the HTTP response results.
Note
The console invokes and tests the function by using the gateway API. If the test fails, the API will automatically execute the retry logic for up to 4 retries. Therefore, you will see multiple execution logs for one failed request.
You can use other HTTP testing tools such as CURL and Postman to test the HTTP-triggered Function you have successfully created.
Viewing logs
For HTTP-triggered Functions, the returned body information of each request will not be automatically reported to the log. You can customize the reporting in the code through statements such as console.log() or print() in your programming language.
For PHP, as all inputs are automatically used as the body, you need to run the following command to output the log to stdout and complete log reporting:
<?php
$stdout=fopen("php://stderr","w");
fwrite($stdout,"123\n");
?>
On the details page of a created function, select Log Query to view its detailed logs. For more information, please see Viewing Execution Logs.
View monitoring data
On the details page of a created function, select Monitoring Information to view metrics such as function invocations and execution duration. For more information, please see Monitoring Metric Descriptions.
Note
The minimal granularity of monitoring statistics collection is 1 minute. You need to wait for 1 minute before you can view the current monitoring record.
Common Errors and Solutions
Common errors can be categorized into two types: User Errors and System Errors.
User errors: the execution failure is caused by improper user operations; for example, the sent request does not meet the standard, the commands in the bootstrap file are incorrect, the correct port is not listened on, or the internal business code is incorrectly written. The returned error code is 4xx.
Platform errors: the execution failure is caused by internal errors of the SCF platform. The returned error code is 500.
The table below describes the possible scenarios of request errors and function errors, so that you can quickly troubleshoot problems. For more information on error codes, please see Function Status Code.
2xx status codes
Status Code
Return Message
Description
200
Success
The function has executed successfully. If you see this return code, but the return message does not match your expectations, please verify the correctness of your code logic.
4xx Status Code
Status Code
Return Message
Description
404
InvalidSubnetID
The subnet ID is invalid. Check whether the network configuration of the function is correct and whether the subnet ID is valid.
405
ContainerStateExitedByUser
The container process has exited normally. Please verify the correctness of your startup file. For more details, refer to the Troubleshooting Guide.
406
RequestTooLarge
The request body size is too large. The upper limit for sync request events is 6 MB.
410
The HTTP response body exceeds the size limit.
The size of function response body exceeds the upper limit of 6 MB. Adjust it and try again.
430
User code exception caught
A user code execution error occurs. Based on the error log on the console, check the error stack of the code and see whether the code can be executed properly.
433
TimeLimitReached
The function execution time has exceeded the timeout configuration. Check whether there are time-consuming operations in the business code, or adjust the execution timeout period on the function configuration page.
439
User process exit when running
The user process exits accidentally. Based on the error message, find out the cause and fix the function code.
446
PortBindingFailed
No listening port is specified. Check whether your business code listens on port 9000.
499
kRequestCanceled
The user manually interrupts the request.
5xx Status Code
Status Code
Return Message
Description
500
InternalError
Internal error. Please try again later. If the problem persists, contact us for assistance.
Notes on local debugging
When debugging in a local container, in order to ensure consistency with the standard container environment in the cloud, you need to pay attention to the limits of readable and writable files in the local environment. The local container startup command is as follows:
Note
This command is for reference only. Please modify it with your own image environment.
