This article intends to present an overview about Salesforce Platform Events feature, by describing the related concepts, software architecture and some implementation examples.
Concept
Platform Events (PEs) are basically scalable messages that contain data. In Salesforce, they are an entity similar to a sObject in the way that they also have system fields and can be customized by introducing new ones. However, PEs records cannot be updated, deleted and neither be displayed in the user interface.
A platform event is identified by the API Name suffix ‘__e’. For example, WIT_ProcessExec__e.
PEs can be a simple and yet powerful way to connect not only internal Salesforce apps but also to provide real-time data exchange with external systems.
Event-Driven Architecture
Event based communication works as publisher-subscriber model, where a sender can broadcast a message which can be captured by one or multiple listeners. Events are sent whether or not receivers are listening, and receivers don’t acknowledge it when they receive an event.
The following diagram illustrates an event-based software architecture:
The elements that compose this model are followingly presented:
Event
It’s an occurrence of something important, for example, the change of status of item or process.
Event message
A message that contains data with the details about an event.
Event producer
The publisher of an event message.
Event channel
A stream of events on which an event producer sends event messages and event consumers read those messages. For platform events, the channel is for one platform event and groups all event messages for that platform event.
Event consumer
A subscriber to a channel that receives messages from the channel.
Event bus
A communication and storage service that enables event streaming using the publish-subscribe model. The event bus enables the retrieval of stored event messages at any time during the retention window.
Availability
- Events can be published via one or more APIs (REST, SOAP for example);
- Apex supports events publishing;
- Apex triggers can subscribe events;
- Events can be declaratively published through Process Builder and Flow Builder;
Implementation Example
The following example presents the full implementation of an event, from the object schema definition to an APEX publishing and subscribing definition logic.
1. Specify Event Definition
As already mentioned, an event is somehow similar to an SObject in which some fields can be created. An event is created by accessing to Setup > Platform Events.
Configuration is started by setting a name to the event and the Publish Behavior, i.e., when should the event be published in a transaction [1].
Next, we can configure the kind of information we can/must store in the event, by creating custom fields. In this example, text fields Action and RecordId were created to be used to define a name of an action to be executed over some record.
2. Specify Subscription Logic
After event has been created and specified, we can now specify an APEX subscription logic to handle the events. In this example, we create a class WIT_EventTrigger_Handler in which is set all the logic and processing to be executed when an event is triggered.
As can be noted, the event object handling in APEX is similar to any other SObject.
Then, we create a trigger to subscribe the new event and apply the logic by executing the method previously presented.
So, in a simply way it is set a bulk-event solution that processes all the WIT_ProcessExec_e events published and executes some action over some specified record.
Note: After trigger creation, it is now also visible in the event definition screen.
3. Publish the event
In the publish logic perspective, we can follow an identical strategy by creating a class to set a bulk-solution to publish the events.
This way, whenever necessary to publish some event(s), its only necessary to invoke the new method.
Usage Considerations
PEs can be a very practical way to consider when designing big and complex processes, allowing them to be scalable and also avoid some common process limitations.
In the previous implementation example, it is demonstrated how a PE can be fully used in an internal Salesforce process, by publishing and also subscribing events using APEX.
In a real scenario it is very common to be confronted with many design challenges:
- Big business processes usually have many DML operations combined with API usage, where at some point in the flow, callouts must be executed, for example, to get some external data;
- Many times, that kind of operations must/should be asynchronously executed, due to complexity, business rules, external API availability, etc.;
- On top of that, it is common that those processes must also be executed in the context of batch execution;
- Therefore, when designing business processes with similar specifications, it is important to note that:
-
-
- DML operations cannot be executed prior to callouts, or else this will result in an error 'You have uncommitted work pending. Please commit or rollback before calling out' [2];
- Future methods cannot be executed from batch contexts [3];
- Future methods cannot invoke another future method [3]
-
-
Conclusion
PEs can then be used as solution to face above mentioned challenges in simple and powerful way through the publish/subscribe architecture, by allowing to split complex actions into smaller ones, chain them and separate context execution, solving in this way the limitations previously presented.
Sources
[2] - https://help.salesforce.com/articleView?id=000328873&type=1&mode=1