Introduction to Platform Events in Salesforce

Hello Trailblazers,

In this post we're going to learn about platform events. Platform Events are a part of salesforce's enterprise messaging platform. In short, we can say that a platform event is an event using which applications can communicate with each other inside and outside of salesforce. 

Therefore, it can be used to send messages/notifications from one app to another within salesforce and also we can send messages to other applications which are outside of salesforce, thereby using it as a means to integrate salesforce with other systems.

What is an Event-Driven Software Architecture?

In order to understand platform events, we should know what an event-driven software architecture looks like. It's described very well in the original salesforce documentation in detail. We're going to focus on some of the important stuff here.

An event driven architecture consist of an Event Bus i.e. the service which ensures the delivery of the event in the correct order 🚌. It consist of multiple Event Channels through which the event travel. We also have an Event Producer i.e. the application which will fire the event and an Event Consumer i.e. the application which will receive the event. Each event will have an Event Message which is the actual information the event is carrying. And That's All. As simple as that!

Why and When should I use platform events?

When a system/application request salesforce for the latest information of some records let's say by hitting the API, there is a separate connection established between the requestor application and salesforce. 

Let's consider a hypothetical scenario where you are creating/updating leads. When a condition is fulfilled (let's say personal info is updated) you need all the updated lead information to be synced with 5-10 external systems in near-real time. 

Now, for each such system (requestor application) there will be a separate connection to salesforce maybe via REST API (or any other mechanism) and this connection also depends on the availability of the service. Let's say if the service (i.e. salesforce api if the external system is requesting information) is not available for some time (maybe a few seconds) due to any reason, the requests to get the latest information will fail for some of the systems while the other systems will remain up to date. This leads to Inconsistency between receiver systems.

So, in this case, we can say:

1. The availability of the service is critical
   
   
2. To add (integrate with) a new system, we need to establish a separate connection

However, if we have an event based model, Salesforce (Event Producer) can fire a platform event - each time the lead record is created/updated and it's satisfying the condition. It's not necessary for salesforce to know who's consuming the event, there can be 5, 10, 15, 20..... consumers who would like to receive the same information. Even if an external system is not available for some time, the events fired will still remain in the event bus and can be received/consumed once the system is available again. If salesforce (producer system) is not available, it can fire the events once it's back and publish it to the event bus.

Therefore, we can say:

1. The availability of service is not critical. If the producer is not available, it's fine as it'll publish the events to the bus when it's available again and similarly if the consumer is not available for some time, it can also retrieve the events from the same event bus when it's back
   
   
2. Adding/integrating a new system is fairly easy as we don't need to establish a separate connection to the service (event producer). The new consumer can simply connect to the event bus and can start receiving events
   
   
3. The only consideration/dependency between event producer and consumer here is the format of the event message content as it'll be the same for all consumers

Note: Each platform event message consist of a ReplayId using which we can identify the event. We can also replay the stream of events after a particular event using the replay id.

Types of Platform Events

There are two types of platform events:

1. Standard Platform Events
   
   
2. Custom Platform Events
   
   

Standard Platform Events

Standard platform events consist of some limited events that are pre-defined by salesforce. Most of these events are published in response to an action that occured in the org or to report errors. A good example of a standard platform event is BatchApexErrorEvent which can be fired by our batch class to report any errors that are encountered. You can implement the Database.RaisesPlatformEvents interface in your batch class to fire these events and capture them in your event subscriber to log details of the errors that are encountered.

A full list of standard platform events is available here. Apart from this list, the Change Data Capture Events (CDC) also comes under standard platform events and can be used to notify when a record is created, updated, deleted OR undeleted from recycle bin. We'll need a separate blog post to cover CDC in detail, let me know in the comments down below if you're interested in the same.

Custom Platform Events

Custom Platform Events are user-defined events that can be used to convey any specific information that you would like to publish using platform events. Defining a custom platform event is very similar to defining a custom object in salesforce. You can specify the name of the platform event, the field names and their types. There are also some limitations if we compare it to a salesforce objects:

• These event records cannot be viewed in salesforce directly so we don't have a page layout for them.
  
  
• Out of the CRUD operation, only CREATE and READ are valid for platform events. You CANNOT UPDATE or DELETE a platform event record.
  
  
• Published event messages cannot be rolled back
  
  
• The type of fields for platform event objects are limited. Only Checkbox, Date, Date/Time, Number, Text and Text Area (Long) fields are supported

All the above points, kind of makes sense as well, because once you fire a platform event record and it's published to the event bus, now it can be read by any subscriber so there is no point of updating or deleting an event which is already published. Also, rollbacking a platform event is also risky because the publisher is not aware of the subscribers, so we can't say which subscriber has already consumed it and which hasn't. Lastly, we don't really need fields like: lookup, master-detail and other field types in platform events which we have in custom objects.

Publishing Platform Events

We have two options for publishing platform events:

1. Publish Immediately - Platform events are published as they're fired. They won't wait for the current transaction to complete successfully. A good use case can be if you want to create error log (custom object to store errors) records when an exception is thrown. You can fire a platform event with the error message and it's published immediately. Therefore, an error log record will be created when this platform event is received (a separate transaction) even when the actual transaction is rolled back because of an exception.
   
   
2. Publish After Commit - Platform events are published only after a transaction commits successfully. Let's say you want to send an email when something happens, so you want to be sure that the transaction is completed successfully before you fire a platform event which is subscribed by a flow (let's say) and it sends an email. In this case, Publish After Commit is a better option.

Before we wrap up this post, I would like to tell you about some more important points about platform events:

1. Platform Events can be High Volume or Standard Volume. In API version 45.0 and later, all new custom platform events are high volume by default, so we'll focus mainly on that. A big difference between high volume and standard volume platform events is: High Volume platform events are stored in the event bus for 3 days whereas Standard Volume platform events are stored in the event bus for 1 day. The higher retention time makes the integration more robust as the system can be down for some time (due to any issue), can be up again and receive the event messages it lost when it was down
   
   
2. The order in which the events are published remains the same - as we specify at the time of publishing these events, when you're publishing multiple events in the same publish call. If you're publishing multiple events separately using different calls to publish(), the order is not guaranteed.
   
   
3. Platform Events are suffixed with __e
   
   
4. Each platform event message has a replay id using which it can be replayed from the event bus.
   
   
5. Some important terms include: Event Bus, Event Channel, Event Producer, Event Consumer and Event Message (we discussed all of these above in the Event-Driven software architecture section)

Ok, enough of theory and this was the only theory I wanted to share before we deep dive into practical stuff - actually fire and subscribe to platform events which we'll do in the similar upcoming posts.

That's all for this tutorial. I hope you liked it, let me know your feedback in the comments down below. You can connect with my on Connections app by scanning the QR code given below:

Or search in the code scanner screen using my username: rahulmalhotra

Happy Trailblazing!!