Configuring the EMP Platform Event Queue (Version 2)
When you configure the EMP platform event queue, you can choose to use legacy version 1 settings, or the newer version 2 settings, which support more flexible queues. The details in this procedure cover how to use version 2 settings. To use version 2 settings, follow the steps in Configuring the EMP Platform Event Queue (Version 1) to create a custom setting record, and see the examples and parameter tables in this topic for the logic to implement in the Default Value field to configure queue definitions.
Default Version 2 Queue Settings
{
"id": "update_event_callback_only",
"version": "2",
"callback_option": "callback_only",
"same_transaction": true,
"expression": {
"event": ["eq", "update_event"]
},
"threads": 4,
"exclusive_operation": "THE_OPERATION_FULL_IDENTIFIER_IS_HERE",
"operation": "THE_OPERATION_FULL_IDENTIFIER_IS_HERE".
"type": "master"
}
"id": "update_event_callback_only",
"version": "2",
"callback_option": "callback_only",
"same_transaction": true,
"expression": {
"event": ["eq", "update_event"]
},
"threads": 4,
"exclusive_operation": "THE_OPERATION_FULL_IDENTIFIER_IS_HERE",
"operation": "THE_OPERATION_FULL_IDENTIFIER_IS_HERE".
"type": "master"
}
Version 2 settings use the following parameters.
|
Parameter
|
Value
|
||
|---|---|---|---|
|
id
|
Unique queue ID. No two queues can have the same value.
|
||
|
version
|
Can be any value except v1, which is reserved for Version 1 settings. If not specified, the value defaults to v1.
|
||
|
callback_option
|
• accept: Used to configure queues that can process both callback and non-callback platform events. Default value.
• reject: Used to configure queues that cannot process callback platform events.
• callback_only: Used to configure queues that process only callback platform events.
|
||
|
same_transaction
|
Whether records included in callback platform events, such as platform events that contain SOQL payloads with multiple record IDs, are processed in the same transaction. When set to false, callback platform events are processed in separate transactions.
|
||
|
threads
|
The number of threads that can be used to process platform events. If not specified, by default, only one thread is used to process platform events in the queue.
|
||
|
type
|
Can be transaction or master. If not specified, master is the default.
|
||
|
exclusive_operation
|
The operation to be used to detect platform event dependencies, so that two dependent PEs are not processed at the same time.
|
||
|
operation
|
Optional operation to determine whether the queue processes platform events based on their payloads. If the operation returns true, platform events are processed in the queue.
|
||
|
expression
|
Valid conditions:
• object: Used to specify the objects supported by this queue, with valid subconditions in and eq, for example:
◦ "object:["in",["Account","Contact"]] means that the expression is evaluated as true for the Account or Contact objects.
◦ "object":["eq","Account"] means that the expression is evaluated as true only for Account objects.
• event: Used to specify the events supported by this queue, with the same valid subconditions as for the object condition.
• and: Used to specify that all conditions in the expression must be satisfied to trigger platform event processing.
◦ Valid subconditions are the same as for the expression parameter.
• or: Used to specify that any one condition in the expression must be satisfied to trigger platform event processing.
◦ Valid subconditions are the same as for the expression parameter.
• PE field path: The payload field path, separated with periods (.) and the same valid subconditions as for the object and event conditions, for example payload.fields.SVMXC__State__c.
|
Example Multi-Thread V2 Queue Setting
The following example shows how to configure a wo_and_event queue setting with a maximum of 6 threads, where platform event dependency checks are executed by the svmx_platform_event_dependency_check operation.
"_pe_queues": [
{
"id": "wo_and_event",
"expression": {
"object": [
"in",
[
"SVMXC__SVMX_Event__c",
"Event",
"SVMXC__Service_Order__c"
]
]
},
"exclusive_operation": "svmx_platform_event_dependency_check",
"callback_option": "reject",
"type": "transaction",
"threads": 6,
"version": "v2"
}
]
{
"id": "wo_and_event",
"expression": {
"object": [
"in",
[
"SVMXC__SVMX_Event__c",
"Event",
"SVMXC__Service_Order__c"
]
]
},
"exclusive_operation": "svmx_platform_event_dependency_check",
"callback_option": "reject",
"type": "transaction",
"threads": 6,
"version": "v2"
}
]
Example Version 2 Queue Setting
The following example shows how to configure a queue that satisfies the following condition:
OR(object: contact, event: update_event, AND(object: SVMXC__Service__Order__c, payload.fields.SVMXC__State__c: CA))
{
"id": "testqueue",
"version": "v2",
"expression": {
"or": [
{
"object": [
"in",
[
"contact"
]
]
},
{
"event": [
"eq",
"update_event"
]
},
{
"and": [
{
"object": [
"in",
[
"SVMXC__Service_Order__c"
]
]
},
{
"payload.fields.SVMXC__State__c": [
"eq",
"CA"
]
}
]
}
]
},
"callback_option": "accept"
}
"id": "testqueue",
"version": "v2",
"expression": {
"or": [
{
"object": [
"in",
[
"contact"
]
]
},
{
"event": [
"eq",
"update_event"
]
},
{
"and": [
{
"object": [
"in",
[
"SVMXC__Service_Order__c"
]
]
},
{
"payload.fields.SVMXC__State__c": [
"eq",
"CA"
]
}
]
}
]
},
"callback_option": "accept"
}
You can mix Version 1 and Version 2 configurations in the same setting. The logic flow is as follows.
1. Iterate Version 1 queues:
a. If the support_callback condition is passed, the objects condition is evaluated, and if passed, the platform event is processed. If not, then:
b. The event_types condition is evaluated, and if passed, the platform event is processed. If not, then:
c. The operations condition is evaluated, and if passed, the platform event is processed. If not, then:
2. Iterate Version 2 queues:
a. Evaluate if this queue is configured with the accept callback option. If not, then:
b. Platform events are processed by the _fallback queue.
For more information: