Hello all, It’s been a long time I have written anything. I was busy, too much of research and work :). I have some breathing time so, thought to utilize the time with a simple post. This time I am going to talk about “Deliver Custom Notifications with Platform Events”. It’s Generally available now and anyone with a proper platform can use it. Salesforce’s enterprise messaging platform provides the delivery of secure and scalable custom notifications within the platform and from external sources. This change applies to both Lightning Experience and Salesforce Classic.The platform provides an event-driven messaging architecture to enable apps to communicate inside and outside of Salesforce. Platform events simplify the process of communicating changes and responding to them without needing to write complex logic. Publishers and subscribers communicate with each other through events. Multiple subscribers can listen to the same event and carry out different actions.
What is Platform Events
Platform Event’s are messages, that are sent via the platform to it’s subscriber. Platform events are part of Salesforce’s enterprise messaging platform. This is an event-driven architecture. Where we can send the events as messages to salesforce components or even out side salesforce. By using platform events, publishers can send customized event data through Apex or an API.
Subscribers can receive custom notifications from Salesforce or an external system using Apex or CometD clients. Based on the event’s contents, subscribers can process custom business logic, such as sending an email or logging a case. For example, a software system monitoring a printer can make an API call to publish an event when the ink is low. The printer event can contain custom fields for the printer model, serial number, and ink level. The event is processed in Salesforce by an Apex trigger that places an order for a new cartridge.
You will need “Customize Application” to define an event.
Deliver Custom Notifications with Platform Events
From Setup, enter Platform Events in the Quick Find box, then select Platform Events. It will simply look like a custom object, because it is actually a sObject, just as other custom objects we build.
Once you save the name, you will notice the API name of the event which will have “__e” at the end. This is the identifier that this is a Event object. You can build fields and triggers and so on. But the field will have the same “__c” extension.
The fields cannot have all the usual data types we see in the platform yet. But, I assume other data types may be added in future.
You will see a new standard field on this object called “ReplayId” . This field identifies platform event record and is used to get stored events that are within the retention window. A subscribed CometD client can retrieve past events using the ReplayId field. SOQL queries aren’t supported.This will be auto-generated by the system. The ID is unique for the org and the channel.
How to Publish the Platform Events
The platform events can be sent using processes, flows, or Apex or an external app using Salesforce APIs.
-
Publish Event Messages with Processes
-
Publish Event Messages with Flows
-
Publish Event Messages with Apex
-
Publish Event Messages with Salesforce APIs
To publish using Process Builder add a Create a Record action to the appropriate process. Let’s look at a quick exmaple. In this example we will use a case status. So as and when the case status changes, we will send that status using this Event.
To publish event messages, add a Record Create or a Fast Create element to the appropriate flow. Where you’d usually pick an object to create, select the platform event.
Example : Create an Event after the case status has been updated:
You can use “EventBus.publish” method in Apex to create an Event.
Example: Let’s send a Case update using the Demo_Platform_Event__e we created here.
List
demoEvent.add(new Demo_Platform_Event__e(Status__c=’Closed’,CaseNumber__c=’Case Number from SOQL or Parameters’);
// Call method to publish events
List
// Inspect publishing result for each event
for (Database.SaveResult sr : results) {
if (sr.isSuccess()) {
System.debug(‘Successfully published event.’);
} else {
for(Database.Error err : sr.getErrors()) {
System.debug(‘Error returned: ‘ +
err.getStatusCode() +
‘ – ‘ +
err.getMessage());
}
}
}
Note : This is a non-transnational function. As a result, you can’t roll back published events. Because event publishing is equivalent to a DML insert operation, DML limits and other Apex governor limits apply.
You can use API methods as well to create events. I like REST API more so will give example of REST here, but you can use SOAP as well.
You can consume the webservice and create an event using the below format:
/services/data/v41.0/sobjects/
Example :
/services/data/v41.0/sobjects/Demo_Platform_Event__e/
Request Body :
{
“CaseNumber__c” : “XZO-5”,
“Status__c” : “Closed”
}
You can use workbench to fire this;
Subscribing to Platform Events
So, you could send and event successfully. Let’s check how we can subscribe and utilize this event we just fired.
You can subscribe to these events in various ways such as Apex, CometD,Flow etc. But in the interest of time, I will explain the Apex method.
You can write a trigger on the Demo_Platform_Event__e object to collect and action the event.
It’s simple as other triggers we usually write:
// Trigger for catching Demo_Platform_Event__e events.
trigger Subscription on Demo_Platform_Event__e (after insert) {
// Iterate through each notification.
for (Demo_Platform_Event__e event : Trigger.New) {
//TODO: Add your logic to pickup the details in this event
}
}
Conclusion
So, this is it for now : Deliver Custom Notifications with Platform Events. Hope you liked playing with it. This event can be considered as webhook in general. As webhook just sends event to it’s subscribers, so does the Platform Event. Hoping to see more improvements to this in future. Please post your comments about this articles in the comment box.
Thanks keep reading and sharing…
Leave a Reply