All Products
Search

This Product

    Configure triggers and events

    Document Center

    Configure triggers and events

    Last Updated: May 31, 2019

    Different formats are used for the parameter configuration files of different triggers. This topic provides samples of these formats and describes the attributes they support. In addition, the event object formats of the events triggers that are sent to function interfaces differ by trigger. Therefore, this topic also lists and describes the different formats of event objects.

    Currently, the following two types of triggers are supported:

    For triggers that are created in Function Compute, you can use the fcli to enter shell mode and run the mkt command to create a trigger. The parameters of this command are as follows:

    1. >>> mkt --help
    2.       --etag string              trigger etag for update
    3.       --help
    4.   -r, --invocation-role string   invocation role
    5.   -s, --source-arn string        event source arn
    6.   -c, --trigger-config string    trigger config file
    7.   -t, --type string              trigger type, support oss now (default "oss")

    Note: The --trigger-config parameter configuration files for different triggers have different formats.

    HTTP triggers

    HTTP triggers differ from other triggers in that the function signatures are request and response objects, rather than event objects. Therefore, HTTP triggers do not use the event format.

    For more information, see HTTP trigger.

    Configure a trigger

    Trigger example: httpTrigger.yml

    1. triggerConfig:
    2.     authType: anonymous
    3.     methods: ["GET", "POST"]

    Trigger parameters:

    • authType indicates the authorization mode. Valid values:
      • anonymous: indicates that the server does not require authorization and allows access by any user.
      • function: indicates that the server requires authorization. HTTP request headers must include a signature and timestamp.
    • methods indicates the request method supported by the HTTP trigger. Valid values:
      • GET: HTTP GET method
      • POST: HTTP POST method
      • HEAD: HTTP HEAD method
      • PUT: HTTP PUT method
      • DELETE: HTTP DELETE method

    OSS triggers

    For more information, see OSS event trigger.

    Configure a trigger

    Trigger example: ossTrigger.yml

    1. triggerConfig:
    2.     events:
    3.         - oss:ObjectCreated:PostObject
    4.         - oss:ObjectCreated:PutObject
    5.     filter:
    6.         key:
    7.             prefix: source/
    8.             suffix: .png

    Trigger parameters:

    • events indicates the type of an event for which OSS triggers function execution. Valid values:
      • oss:ObjectCreated:*
      • oss:ObjectCreated:PutObject
      • oss:ObjectCreated:PutSymlink
      • oss:ObjectCreated:PostObject
      • oss:ObjectCreated:CopyObject
      • oss:ObjectCreated:InitiateMultipartUpload
      • oss:ObjectCreated:UploadPart
      • oss:ObjectCreated:UploadPartCopy
      • oss:ObjectCreated:CompleteMultipartUpload
      • oss:ObjectCreated:AppendObject
      • oss:ObjectRemoved:DeleteObject
      • oss:ObjectRemoved:DeleteObjects
      • oss:ObjectRemoved:AbortMultipartUpload
    • filter filters OSS events. Only OSS objects that meet the filter conditions can trigger the function. The conditions include the following attributes:
      • key: The filter can filter objects by key, which includes the following attributes:
        • prefix: matches the prefix.
        • suffix: matches the suffix.

    Event format

    1. {
    2.   "events": [
    3.     {
    4.       "eventName": "ObjectCreated:PutObject",
    5.       "eventSource": "acs:oss",
    6.       "eventTime": "2017-04-21T12:46:37.000Z",
    7.       "eventVersion": "1.0",
    8.       "oss": {
    9.         "bucket": {
    10.           "arn": "acs:oss:cn-shanghai:1237050315505689:bucketname",
    11.           "name": "bucketname",
    12.           "ownerIdentity": "1237050315505689",
    13.           "virtualBucket": ""
    14.         },
    15.         "object": {
    16.           "deltaSize": 122539,
    17.           "eTag": "688A7BF4F233DC9C88A80BF985AB7329",
    18.           "key": "image/a.jpg",
    19.           "size": 122539
    20.         },
    21.         "ossSchemaVersion": "1.0",
    22.         "ruleId": "9adac8e253828f4f7c0466d941fa3db81161e853"
    23.       },
    24.       "region": "cn-shanghai",
    25.       "requestParameters": {
    26.         "sourceIPAddress": "140.205.128.221"
    27.       },
    28.       "responseElements": {
    29.         "requestId": "58F9FF2D3DF792092E12044C"
    30.       },
    31.       "userIdentity": {
    32.         "principalId": "262561392693583141"
    33.       }
    34.     }
    35.   ]
    36. }

    Log Service triggers

    For more information, see Log Service trigger.

    Configure a trigger

    Trigger example: slsTrigger.yml

    1. triggerConfig:
    2.     sourceConfig:
    3.         logstore: "etl-log"
    4.     jobConfig:
    5.         maxRetryTime: 3
    6.         triggerInterval: 60
    7.     functionParameter:
    8.         a: "b"
    9.         c: "d"
    10.     logConfig:
    11.         project: "ali-fc-test"
    12.         logstore: "test-store"
    13.     enable: true

    Trigger parameters:

    • sourceConfig is the data source configuration parameter, which includes the following attributes:
      • logstore: The name of the Log Service logstore that is used as the data source. The trigger regularly subscribes to this Logstore and sends the data to Function Compute for custom processing. After this parameter is created, it cannot be modified. For more information, see Logstore operations.
    • jobConfig is the task configuration parameter, which includes the following attributes:
      • triggerInterval: The interval at which Log Service triggers function execution. Valid values: [3, 600]. Unit: second. For example, triggerInterval: 60 indicates that this function reads the locations of data that occurred in the last 60 seconds in each shard at intervals of 60 seconds. The incremental data triggers executing this function. In the function, the user-defined logic reads the shard data and performs computation. If your Logstore shards have a high traffic volume (over 1 Mbit/s), we recommend that you set a shorter trigger interval to ensure the data volume processed by each function execution is of a reasonable size. For more information, see Shard operations.
      • maxRetryTime: The maximum number of retries that is allowed for a single trigger. Value range: [0, 100]. When Log Service triggers function execution according to the set trigger interval, the trigger interval must elapse before Log Service can attempt to trigger the function again if the following situations occur: (1) Errors occur (such as insufficient permissions, network failure, or function execution exception); (2) The operation is still unsuccessful after the the maximum number of retries is reached. The impact of retries on the business varies according to the implementation logic for the specific function code.
    • functionParameter: Log Service uses this configuration content as a part of input function event parameters. The way in which this function is used is determined by the function’s custom logic. Different types of functions have different requirements for function configurations. For the vast majority of provided function templates, you must read the instructions when entering your parameters. The default value is null ({}).
    • logConfig is the log file configuration for the trigger, which includes the following attributes:
      • {project}: The name of the Log Service project. For more information, see Project operations.
      • logstore: The name of the Logstore in which logs are stored.
    • enable indicates whether the trigger is enabled. Valid values: true and false.

    Event format

    1. {
    2.    "parameter":{
    3.       "a":"b",
    4.       "c":"d"
    5.    },
    6.    "source":{
    7.       "endpoint":"http://cn-shanghai-intranet.log.aliyuncs.com",
    8.       "projectName":"vangie-fc-test",
    9.       "logstoreName":"fc-test",
    10.       "shardId":0,
    11.       "beginCursor":"MTUyMzI2NzI5NDY1NjI4MzgzNg==",
    12.       "endCursor":"MTUyMzI2NzI5NDY1NjI4MzgzNw=="
    13.    },
    14.    "jobName":"05c79f637c6b46eaa85911cae032cf47551af7bb",
    15.    "taskId":"d22697c0-2a41-4d35-b27c-dccec8856768",
    16.    "cursorTime":1523323454
    17. }

    Timer triggers

    Configure a trigger

    For more information, see Timer trigger.

    Trigger example: timerTrigger.yml

    1. triggerConfig:
    2.     payload: "aaaaa"
    3.     cronExpression: "0 1/1000 * * * *"
    4.     enable: true

    Trigger parameters:

    • payload is content of the event that is triggered in any text format. It is used as an input parameter each time the function is triggered.
    • cronExpression is a Cron expression. For more information, see Cron expression value description.
    • enable indicates whether the trigger is enabled. Valid values: true and false.

    Event format

    1. {
    2.    "triggerTime":"2018-04-10T01:31:00Z",
    3.    "triggerName":"t1",
    4.    "payload":"abcde"
    5. }

    CDN events trigger

    For more information, see CDN events trigger.

    Configure a trigger

    Trigger example : cdn_events_trigger.yml

    1. triggerConfig:
    2.     eventName: “LogFileCreated”
    3.     eventVersion: “1.0.0”
    4.     notes: “cdn events trigger test”
    5.     filter: 
    6.         domain: {“www.taobao.com”,”www.tmall.com”}

    Trigger parameters:

    • eventname is the CDN event that triggers the function execution.
    • eventVersion is the CDN event version that triggers the function execution .
    • Note is the CDN event descriptions.
    • Filter: is the filters.

    The following eventName, eventVersion and filter keys are supported:

    Event Name Event Version Filter Key Description
    CachedObjectsRefreshed 1.0.0 domain RefreshObjectCaches.
    CachedObjectsBlocked 1.0.0 domain CDN resources blocked
    CachedObjectsPushed 1.0.0 domain PushObjectCache
    LogFileCreated 1.0.0 domain DescribeCdnDomainLogs
    CdnDomainStarted 1.0.0 domain StartCdnDomain
    CdnDomainStopped 1.0.0 domain StopCdnDomain

    The filter must contain at least one pair. The format is as follows:

    1.     filter: 
    2.         Key 1: {value a, value b}
    3.         Key 2: {value c, value d}

    Event format

    Event formats for CachedObjectsRefreshed, CachedObjectsPushed, and CachedObjectsBlocked:

    1. {
    2.     "events": [
    3.         {
    4.             "eventName": "CachedObjectsRefreshed",// The event type.
    5.             "eventVersion": "1.0.0",  // The event version. Currently, only 1.0.0 version is available.
    6.             "eventSource": "cdn", // The event source name.
    7.             "region": "cn-hangzhou", // The region. Default value: "cn-hangzhou".
    8.             "eventTime": "2018-03-16T14:19:55+08:00",// The event occurrence time.
    9.             "traceId": "cf89e5a8-7d59-4bb5-a33e-4c3d08e25acf",// The ID of the event source, used for debugging.
    10.             "resource": {
    11.                 "domain": "example.com"// The domain of the resource.
    12.             },
    13.             "eventParameter": {
    14.                 "objectPath": [
    15.                     "/2018/03/16/13/33b430c57e7.mp4",// The resource identifier.
    16.                     "/2018/03/16/14/4ff6b9bd54d.mp4"// The resource identifier.
    17.                 ],
    18.                 "createTime": 1521180769,// The refresh start time.
    19.                 "domain": "example.com",// The domain of the resource.
    20.                 "completeTime": 1521180777,// The refresh end time.
    21.                 "objectType": "File",  // The refresh type. Valid values: File and Directory.
    22.                 "taskId": 2089687230 // The refresh task ID.
    23.             },
    24.             "userIdentity": {
    25.                 "aliUid": "1xxxxxxxxxx" // The user ID.
    26.             }
    27.         }
    28.     ]
    29. }

    Event format for LogFileCreated:

    1. {
    2.     "events": [
    3.         {
    4.             "eventName": "LogFileCreated",// The event type.
    5.             "eventSource": "cdn",// The event source name.
    6.             "region": "cn-hangzhou",// The region. Default value: "cn-hangzhou".
    7.             "eventVersion": "1.0.0",// The event version.
    8.             "eventTime": "2018-06-14T15:31:49+08:00",// The event occurrence time.
    9.             "userIdentity": {
    10.                 "aliUid": "1xxxxxxxxxxxx" // The user ID.
    11.             },
    12.             "resource": {
    13.                 "domain": "example.com"// The domain name.
    14.             },
    15.             "eventParameter": {
    16.                 "domain": "example.com",// The domain name.
    17.                 "endTime": 1528959900,// The end time of the log file.
    18.                 "fileSize": 1788115,// The log file size.
    19.                 "filePath": "http://cdnlog.cn-hangzhou.oss.aliyun-inc.com/www.aliyun.com/2017_12_27/www.aliyun.com_2017_12_27_0800_0900.gz?OSSAccessKeyId=xxxx&Expires=xxxx&Signature=xxxx",// The log file address.
    20.                 "startTime": 1528959600// The start time of the log file.
    21.             },
    22.             "traceId": "c6459282-6a4d-4413-894c-e4ea39686738" // The ID of the event source, used for debugging.
    23.         }
    24.     ]
    25. }

    Event formats for CdnDomainStarted and CdnDomainStopped:

    1. {
    2.     "events": [
    3.         {
    4.             "eventName": "CdnDomainStarted", // The event type.
    5.             "eventVersion": "1.0.0",  // The event version.
    6.             "eventSource": "cdn", // The event source name.
    7.             "region": "cn-hangzhou", // The region. Default value: "cn-hangzhou".
    8.             "eventTime": "2018-03-16T14:19:55+08:00",// The event occurrence time.
    9.             "traceId": "cf89e5a8-7d59-4bb5-a33e-4c3d08e25acf",// The ID of the event source, used for debugging.
    10.             "resource": {
    11.                 "domain": "chongshi.alicdn.com"
    12.             },
    13.             "eventParameter": {                
    14.                 "domain": "chongshi.alicdn.com",
    15.                 "status": "online" // The domain status.
    16.             }, 
    17.             "userIdentity": {
    18.                 "aliUid": "12345678"// The user ID.
    19.             }
    20.         }
    21.     ]
    22. }

    For more information, see [CDN events trigger] (73333).

    MNS topic triggers

    Configure a trigger

    For more information, see MNS topic trigger.

    Trigger example: mnsTrigger.yml

    1. triggerConfig:
    2.     notifyContentFormat: STREAM
    3.     notifyStrategy: BACKOFF_RETRY
    4.     filterTag: testTag

    Trigger parameters:Trigger parameters:

    Parameter Constraint Default value Type Description
    notifyContentFormat STREAM, JSON STREAM String Optional. The format of the event pushed as the input parameter for the function.
    notifyStrategy BACKOFF_RETRY, EXPONENTIAL_DECAY_RETRY BACKOFF_RETRY string Optional. For more information, see NotifyStrategy.
    filterTag A string of no more than 16 characters. None String Optional. This parameter describes the tag that is used to filter messages in the subscription (only messages with consistent tags are pushed). If you do not restrict messages to the function, you do not need to set tags.

    Event format

    For more information, see MNS topic trigger.

    RDS triggers

    Configure a trigger

    For more information, see RDS trigger.

    Trigger example: rdsTrigger.yml

    1. triggerConfig:
    2.     subscriptionObjects: ["db1.table1", "db1.table2"]
    3.     retry: 1
    4.     concurrency: 2
    5.     eventFormat: json

    Trigger parameters:

    Parameter Constraint Default value Type Description
    subscriptionObjects None None String The subscription object. Currently, subscription objects are supported down to the table level. Function execution can be triggered only by updating the tables. For example, the parameter is as follows:[“db1.table1”, “db2.table2”]
    retry [0, 3] 3 Integer The number of retries. If failure persists after a specified number of retries, skip the failed event and continue subsequent calls.
    concurrency [1,5] 1 int The number of concurrent calls. If you are concerned about the event sequence, set this parameter to 1. The functions will be called in the sequence that the transaction commits in the binlog. If you are not concerned about the event sequence, set this parameter to a larger value to increase concurrencies and improve performance.
    eventFormat json, protobuf protobuf String The format of an event.

    Event format

    For more information, see RDS trigger

    Table Store triggers

    For more information, see Table Store trigger

    Event format

    Table Store triggers use the CBOR format to encode incremental data and construct a Function Compute event. The incremental data event format is as follows:

    1. {
    2.     "Version": "string",
    3.     "Records": [
    4.         {
    5.             "Type": "string",
    6.             "Info": {
    7.                 "Timestamp": int64
    8.             },
    9.             "PrimaryKey": [
    10.                 {
    11.                     "ColumnName": "string",
    12.                     "Value": formated_value
    13.                 }
    14.             ],
    15.             "Columns": [
    16.                 {
    17.                     "Type": "string",
    18.                     "ColumnName": "string",
    19.                     "Value": formated_value,
    20.                     "Timestamp": int64
    21.                 }
    22.             ]
    23.         }
    24.     ]
    25. }

    Trigger parameters:

    • Version indicates the payload version. Valid value: Sync-v1.
    • Records indicates the set of incremental data rows in the table, which includes the following attributes:
      • Type: The data row type, including PutRow, UpdateRow, and DeleteRow.
      • Info: The basic information of the data row, which includes the following attributes:
        • Timestamp: The last time this row was modified, in UTC time.
        • PrimaryKey: The primary key array, which includes the following attributes:
          • ColumnName: The name of the primary key column.
          • Value: The content of the primary key column, which supports integer, string, and blob.
        • Columns: The column attribute array, which includes the following attributes:
          • Type: The column attribute, which includes Put, DeleteOneVersion, and DeleteAllVersions.
          • ColumnName: The name of the column.
          • Value: The column value, which supports integer, boolean, double, string, and blob.
          • Timestamp: The last time this column was modified, in UTC time.

    Event example:

    1. {
    2.     "Version": "Sync-v1",
    3.     "Records": [
    4.         {
    5.             "Type": "PutRow",
    6.             "Info": {
    7.                 "Timestamp": 1506416585740836
    8.             },
    9.             "PrimaryKey": [
    10.                 {
    11.                     "ColumnName": "pk_0",
    12.                     "Value": 1506416585881590900
    13.                 },
    14.                 {
    15.                     "ColumnName": "pk_1",
    16.                     "Value": "2017-09-26 17:03:05.8815909 +0800 CST"
    17.                 },
    18.                 {
    19.                     "ColumnName": "pk_2",
    20.                     "Value": 1506416585741000
    21.                 }
    22.             ],
    23.             "Columns": [
    24.                 {
    25.                     "Type": "Put",
    26.                     "ColumnName": "attr_0",
    27.                     "Value": "hello_table_store",
    28.                     "Timestamp": 1506416585741
    29.                 },
    30.                 {
    31.                     "Type": "Put",
    32.                     "ColumnName": "attr_1",
    33.                     "Value": 1506416585881590900,
    34.                     "Timestamp": 1506416585741
    35.                 }
    36.             ]
    37.         }
    38.     ]
    39. }

    API Gateway triggers

    For more information, see API Gateway trigger.

    Event format

    Input format

    When Function Compute is used as a backend service of API Gateway, API Gateway uses a fixed mapping structure to send the request parameter to the input parameterevent of Function Compute. Function Compute obtains and processes the desired parameter according to the following structure. The mapping structure of the request parameter is as follows:

    1. {
    2.     "path":"api request path",
    3.     "httpMethod":"request method name",
    4.     "headers":{all headers,including system headers},
    5.     "queryParameters":{query parameters},
    6.     "pathParameters":{path parameters},
    7.     "body":"string of request payload",
    8.     "isBase64Encoded":"true|false, indicate if the body is Base64-encode"
    9. }

    Parameters:

    • isBase64Encoded=true indicates that API Gateway uses Base64 to encode the body content transmitted to Function Compute. Then, Function Compute uses Base64 to decode the body content.
    • isBase64Encoded=false indicates API that Gateway does not use Base64 to encode the body content transmitted to Function Compute.

    Event example:

    1. {
    2.    "body":"",
    3.    "headers":{
    4.       "X-Ca-Api-Gateway":"BDB46B3A-71A7-447B-B20B-28C594426407",
    5.       "X-Forwarded-For":"106.11.231.99"
    6.    },
    7.    "httpMethod":"GET",
    8.    "isBase64Encoded":false,
    9.    "path":"/fc",
    10.    "pathParameters":{
    12.    },
    13.    "queryParameters":{
    15.    }
    16. }

    Output format

    To output content that API Gateway can parse, Function Compute standardizes its output content. For example, it can return the output content in JSON format:

    1. {
    2.     "isBase64Encoded":true|false,
    3.     "statusCode":httpStatusCode,
    4.     "headers":{response headers},
    5.     "body":"..."
    6. }

    Parameters:

    • When the body content is binary data, you must use Base64 to encode the body content in Function Compute and set isBase64Encoded=true. API Gateway uses Base64 to decode body content with the attribute isBase64Encoded=true and then transmits it to the client.
    • If body does not need to be encoded using Base64, you can set isBase64Encoded to false.
    • In the Node.js version of Function Compute, you must set callback based on the specific situation.
      • To return a request success message: callback{null,{“statusCode”:200,”body”:”…”}} `
      • To return a request exception message: callback{new Error(‘internal server error’),null}
      • To return a client error: callback{null,{“statusCode”:400,”body”:”param error”}}
    • If the format of the result that is returned by Function Compute does not conform to these requirements, API Gateway returns 503 Service Unavailable to the client.

    DataHub triggers

    For more information, see DataHub trigger.

    Event format

    1. {
    2.   "eventSource": "acs:datahub",
    3.   "eventName": "acs:datahub:putRecord",
    4.   "eventSourceARN": "/projects/test_project_name/topics/test_topic_name",
    5.   "region": "cn-hangzhou",
    6.   "records": [
    7.     {
    8.       "eventId": "0:12345",
    9.       "systemTime": 1463000123000,
    10.       "data": "[\"col1's value\",\"col2's value\"]"
    11.     },
    12.     {
    13.       "eventId": "0:12346",
    14.       "systemTime": 1463000156000,
    15.       "data": "[\"col1's value\",\"col2's value\"]"
    16.     }
    17.   ]
    18. }

    Trigger parameters:

    • eventSource is the event source. Valid value: acs:datahub.
    • eventName is the event name. Valid value: acs:datahub:putRecord.
    • eventSourceARN is the event source ID, which includes the DataHub project and topic names. For example: /projects/test_project_name/topics/test_topic_name.
    • region is the region of the event source’s DataHub, such as cn-hangzhou. For more information, see Regions and zones.
    • records is a list of records included in the event, which includes the following key values:
      • eventId: The record ID in the format shardId:SequenceNumber.
      • systemTime: The timestamp when this event starts to be stored in DataHub.
      • data: The data content of the event. For Tuple-type topics, the data type of this field is “List”. Here, each list-type element corresponds to each field value of each topic for the string-type data. For Blob-type topics, the data type of this field is “String”.

    IoT triggers

    For more information, see IoT trigger.

    Event format

    The event content that IoT Hub sends to Function Compute is non-encapsulated IoT message content. For example, you can use the following Java example to push messages to IoT topics:

    1. PubRequest request = new PubRequest();
    2. request.setProductKey("VHo5FRjudkZ");
    3. request.setMessageContent(Base64.getEncoder().encodeToString("{\"hello\":\"world\"}".getBytes()));
    4. request.setTopicFullName("/VHo5FRjudkZ/deviceName/update");
    5. request.setQos(0);
    6. PubResponse response = client.getAcsResponse(request);
    7. System.out.println(response.getSuccess());
    8. System.out.println(response.getErrorMessage());

    The event received in Function Compute is:

    1. {
    2.   "hello": "world"
    3. }
    Free Trial Free Trial