Service Board > Service Board for Implementers > Creating and Deploying a Service Board Instance > About SFDC-to-Max Sync Configuration > Working With Platform Event and Real-Time Sync Queues > Configuring the EMP Platform Event Queue (Version 2)
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
"_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"
}
]
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.
• reject: Used to configure queues that cannot process callback platform events.
• callback_only: Used to configure queues that process only callback platform events.
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.
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.
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.
type
Can be transaction or master. If not specified, master is the default.
Example Version 2 Queue Setting
The following example shows how to configure a queue that satisfies this 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"
}
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:
Was this helpful?