Salesforce Platform Events – An Event-Driven Architecture

Author

mirketa

January 13, 2022

Platform events make it easier to communicate changes and respond to events. Publishers and subscribers communicate through platform events. One or more participants can listen to the same event and act. In an event-driven architecture, each service publishes an event when it updates or creates data. This helps applications to maintain data consistency and integrity across multiple services without using distributed transactions.

Here are some key terms to remember:

Event: An event is a significant state change in a business process.
Event Message: An event message or notice contains information about the event.
Event Producer: The publisher of event messages across the channel is known as the event producer. Channel:
The channel through which the message is sent by the event producer.
Event Bus: To get the message, the event attendee subscribes to the channel. In Salesforce, this is referred to as the event bus.
Event Consumer: The subscribers to the channel who receive messages from the channel.

Learn more about platform events.

SObject like Salesforce Entity
suffix: __e
ReplayId to play a specific event
Only the Check Box, Date, Date / Time, Number, Text, and Text Area fields are available.
Publisher / subscriber – based communication
No query is needed.
Non-uniform play load
Define events with different playloads

Considerations for publishing platform events

Publish an event in read-only mode
In read-only mode, publishing a standard volume platform event raises an exception and does not publish the event.
Persistence of HighVolume platform events
Events are queued and buffered, and Salesforce tries to publish the event asynchronously. In rare cases, event messages may not be saved on the distributed system during the first or subsequent attempt. This means that the event is not delivered to the subscriber and cannot be recovered.

Platform Events and APEX:

Mixed DML operations, too many SOQL queries, too many DML statements, CPU timeouts: There are reasons for Salesforce governor limits, but even if you follow best practices, you can exceed them. A good developer will explore all the tools available on the platform to find the best approach to solving the problem they are facing

Publish Platform Events using Apex:

You can publish event messages from a Force.com app or an external app using Apex or Salesforce APIs and you can subscribe from the Salesforce or external apps or use long polling with cometD as well.

Subscribe to platform events using APEX

Apex Trigger: Writes an “after insert” Apex trigger to the event object to subscribe to incoming events. Triggers receive event notifications from various sources, whether exposed via Apex or the API.

Apex Batch:

Considerations for publishing and subscribing to platform events using Apex

Only support for triggers after insertion
Infinite trigger loops and limits
Publish the event to Apex by setting the text field to an empty string
Platform Event Trigger: OwnerId Field for New Record
No email support from platform event triggers
Repetition of past events

Platform events make it easier to communicate changes and respond to events. You can use platform events to break the Salesforce governor’s limits.

Pranshu Goyal, Director of Products at Mirekta, states: “We envision DSM to be used by every small to a medium-sized organization dealing with bad data and want to get rid of duplicates easily with no cost. We have faced issues dealing with duplicates in our organization. That inspired us to make a solution that is not only simple to use but can be used widely to make the organization’s data clean to make them more efficient and productive. We want DSM to be a solution for every organization looking for duplicate management capability better than the Salesforce out-of-the-box solution with no additional cost.”