When you integrate OSS with Function Compute, you can use OSS events to trigger functions that perform custom data processing. This topic describes the limitations, event types, and triggering rules for OSS triggers in Function Compute.
Background information
OSS and Function Compute integrate seamlessly through an OSS trigger. You can write functions to handle OSS events. When an event of a specified type occurs in OSS, the corresponding function is automatically triggered. For example, you can configure a function to handle PutObject events. When you call the OSS PutObject API operation to upload an image to an OSS bucket, the function is automatically triggered to process the image.
After you integrate OSS with Function Compute, you can invoke various functions to process image or audio data and write the results back to various storage services. This architecture allows you to focus on your function logic while the system handles massive amounts of data in real time with high reliability and large-scale parallelism.
Limitations
Only an EventBridge-based OSS trigger supports configuring multiple object prefixes and object suffixes.
Regular expressions are not supported in the object prefix and object suffix of a native OSS trigger or an EventBridge-based OSS trigger.
Only an EventBridge-based OSS trigger lets you associate more than 10 OSS triggers with a single bucket.
As a best practice, avoid associating more than 10 triggers with a single bucket. If you need more triggers, create a new bucket and configure the triggers for it.
Event definitions
When OSS captures a relevant event, it encodes the event information into a JSON string and passes it to the event handler function. For more information about the OSS event notification format, see the linked documentation.
The following table lists the supported OSS event definitions. Each event type corresponds to an ObjectCreated, ObjectRemoved, or ObjectModified API operation. A successful call to one of these API operations triggers the function once.
Event type | Event name | Description |
ObjectCreated | oss:ObjectCreated:PutObject | Triggered by calling the PutObject API to upload an object. For more information, see PutObject. |
oss:ObjectCreated:PutSymlink | Triggered by calling the PutSymlink API to create a symbolic link to a target object in OSS. You can use this symbolic link to access the target object. For more information, see PutSymlink. | |
oss:ObjectCreated:PostObject | Triggered by calling the PostObject API to upload an object to a bucket by using an HTML form. For more information, see PostObject. | |
oss:ObjectCreated:CopyObject | Triggered by calling the CopyObject API to copy an object in OSS. For more information, see CopyObject. | |
oss:ObjectCreated:InitiateMultipartUpload | To transfer data by using the MultipartUpload feature, you must first call the InitiateMultipartUpload API to initialize a multipart upload. For more information, see InitiateMultipartUpload. | |
oss:ObjectCreated:UploadPart | After a multipart upload event is initiated, you can upload data in parts based on the specified object name and upload ID. For more information, see UploadPart. | |
oss:ObjectCreated:UploadPartCopy | The UploadPartCopy API operation uploads a part by copying data from an existing object. For more information, see UploadPartCopy. | |
oss:ObjectCreated:CompleteMultipartUpload | After all data parts are uploaded, you must call the CompleteMultipartUpload API to complete the multipart upload. For more information, see CompleteMultipartUpload. | |
oss:ObjectCreated:AppendObject | The AppendObject API operation is called to upload an object by appending data. For more information, see AppendObject. | |
oss:ObjectCreated:* | Triggered by a successful call to any of the preceding ObjectCreated API operations. | |
ObjectRemoved | oss:ObjectRemoved:DeleteObject | Triggered by calling the DeleteObject API to delete an object. For more information, see DeleteObject. |
oss:ObjectRemoved:DeleteObjects | Triggered by calling the DeleteMultipleObjects API to delete multiple objects in one request. For more information, see DeleteMultipleObjects. | |
oss:ObjectRemoved:AbortMultipartUpload | Triggered by calling the AbortMultipartUpload API to cancel a multipart upload. For more information, see AbortMultipartUpload. | |
ObjectModified | oss:ObjectModified:UpdateObjectMeta | Triggered by calling the UpdateObjectMeta API to modify an object's metadata. Note Currently, this event is supported in the following regions: China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), and China (Chengdu). |
ObjectReplication | oss:ObjectReplication:ObjectCreated | A write operation that occurs during data replication. |
oss:ObjectReplication:ObjectModified | An overwrite operation that occurs during data replication. | |
oss:ObjectReplication:ObjectRemoved | A delete operation that occurs during data replication. |
Triggering rules
Avoid trigger loops
When you use an OSS trigger, be careful to avoid trigger loops. A common scenario is when an object upload to an OSS bucket triggers a function. The function then processes the object and writes one or more new objects back to the same bucket, which in turn triggers the function again, creating an execution loop.
To prevent unnecessary costs from trigger loops, we recommend that you configure an object prefix or an object suffix. For example, you can set the object prefix for source objects to src and the object prefix for processed objects to dst. This ensures that the processed objects do not trigger the function again. If you do not set an object prefix or suffix, the trigger matches objects with any prefix or suffix. For more information, see Step 1: Create an OSS trigger.
Native OSS trigger rules
To prevent a single event from firing multiple triggers in the same bucket, Function Compute enforces the following configuration rules for a bucket:
The combination of the trigger event, object prefix, and object suffix must be unique.
You can create a new trigger only if its combination of
trigger event + object prefix + object suffixdoes not conflict with any existing triggers.
The following examples describe the configuration rules for a native OSS trigger.
Existing trigger | New trigger | Creation status | Description | ||||
Trigger Event | Object Prefix | Object Suffix | Trigger Event | Object Prefix | Object Suffix | ||
oss:ObjectCreated:PutObject | source | zip | oss:ObjectCreated:* | source | zip | Failure | Failure. The new trigger's wildcard event ( |
source1 | zip1 | Success | The new trigger and the existing trigger have conflicting event types, but their Object Prefix and Object Suffix values do not match. | ||||
oss:ObjectCreated:PutObject | source | zip | Failure | The new trigger and an existing trigger have the same event type, Object Prefix, and Object Suffix. | |||
source | 1zip | Failure | |||||
source1 | zip | Failure | |||||
source | None | Failure | If the event type and Object Prefix of a new trigger match those of an existing trigger, and you do not specify an Object Suffix, the new trigger matches objects with any suffix, such as .zip objects. In this case, the Object Suffix is also considered a match. | ||||
None | zip | Failure | The event type and Object Suffix of the new trigger match those of an existing trigger. If the Object Prefix is not set, the trigger includes objects with the prefix 'source', which means the Object Prefix also matches. | ||||
source1 | zip1 | Success | The event type and Object Prefix of the new trigger match those of an existing trigger, but the Object Suffix does not match. | ||||
1source | 1zip | Success | The event type and Object Suffix of the new trigger match those of an existing trigger, but the Object Prefix does not match. | ||||
oss:ObjectCreated:PostObject | source | zip | Success | Success. The event types do not conflict, so the trigger can be created regardless of the path filter. | |||
The object prefix is matched from the beginning of the object name, and the object suffix is matched from the end of the object name.
A new trigger cannot be created if its settings conflict with an existing trigger. A conflict occurs only if the new trigger's event type and its path filter (prefix and suffix) both overlap with an existing trigger's settings.
Event type conflicts
Existing event type | New event type | Conflict description |
|
|
|
|
|
Path matching conflicts
Existing path | New path | Conflict description |
|
| The prefix does not match, but the suffix matches. The paths do not conflict. |
|
| The prefix matches, but the suffix does not match. The paths do not conflict. |
|
| The prefix matches, and the suffix matches. The paths conflict. |
If you want a single OSS event type to trigger different functions for different processing tasks, you can create an EventBridge-based OSS trigger.
FAQ
Related documents
Configure a trigger
For details on configuring and using native OSS triggers and EventBridge-based OSS triggers, see Configure a native OSS trigger and Configure an EventBridge-based OSS trigger.
Trigger-related topics
If you want to check which event triggered a function, you can print the event type in your function logs. For more information, see Log management.
If you want to invoke one function from another, you can use an API to call the target function. For more information, see Can functions invoke each other?.
Tutorials
If you need to automatically unzip ZIP files uploaded to OSS, see Use Function Compute to automatically unzip ZIP files uploaded to OSS.