Salesforce Event-Driven Architecture Using Platform Events

When it comes to integration, the most familiar one is point-to-point integration. Two applications are tightly coupled in a point-to-point integration. When your application landscape continues to evolve, you cannot continue making point-to-point integrations. In no time, you will run into a deeply-nested application landscape, which is difficult to maintain and is not scalable. That is when you can look into the event-driven architecture. If your requirement is not real-time, event-driven architecture helps you set up loosely-coupled systems that interact with each other by consuming real-time events. 

In Salesforce, event-driven architecture is implemented using platform events. Platform event as the name suggests, is associated with an event, and is used to exchange data in real-time within Salesforce and between Salesforce and external systems.  

Platform Event

Platform events can be created similarly to how you create custom objects in Salesforce. The difference is that you will have __e as the suffix in the API name, instead of __c for the custom object. You can add custom data to platform events using custom fields. When you create a new platform event, you have two options for publishing, 

1. Publish immediately — As the name sounds, if this option is chosen then the platform event is published immediately, irrespective of whether the transaction that publishes the event succeeds or not.
2. Publish after commit — With this option, the platform event is published only if the transaction is successful. This is useful in instances when the subscriber needs the data involved in that transaction. 

The platform event follows a publish/subscribe modal. The following are the key components in an event-driven architecture that involves a platform event. 

• Event — The platform event itself. This event is meaningful in a business process as it indicates a change in state within the process.
• Event Producer/Publisher — This is the system that publishes platform events. For example, an order management system that publishes an event when an order has been placed.
• Event Bus — This is the channel/queue for the events. Events that are being placed in this queue are processed in a first-in-first-out manner. 
• Event Consumer/Subscriber — This is the system that subscribes to platform events. For example, when an order event has been placed, it could be subscribed by the order fulfillment system. 

Publish Platform Events

You can publish platform events in the following ways:

1. Flow — Use flows to publish a platform event. You just have to use the 'Create Records' element and select the appropriate platform event in your flow. 
2. Apex — Use Apex to publish platform events. Create a new instance of the event, similar to how you create an instance for a custom object record. To publish the event, use EventBus.Publish method that accepts the platform event instances. 

order_event__e orderEvent = new order_event__e();
orderEvent.orderNumber__c = '1234';
List<Database.SaveResult> results = EventBus.publish(orderEvent);

    3. API — External systems can use Salesforce APIs such as SOAP, REST, or Bulk API 2.0 to publish platform events. The same way you insert an object record, you can publish a platform event. For example you can use following REST API POST call to publish the order_event__e platform event. 

/services/data/v60.0/sobjects/order_event__e/ 

Subscribe to Platform Events

You can subscribe to platform events in the following ways. It is important to note that each of these subscriptions runs in a separate transaction from the transaction that published the event message. 

1. Salesforce flow — You can create a platform event-triggered flow to subscribe to a platform event. You can also configure an auto-launched flow to subscribe to a platform event. More details can be found here.  

2. Salesforce trigger — If you are subscribing to a platform event within Salesforce, you can do that using a Salesforce trigger. You should only use the after-insert trigger though. After an event is published, the after-insert trigger is fired. The trigger runs under an Automated Process (default) entity or a user you select in the event configuration. 

3. Lightning Web Component — Use the empApi component in your lightning web component to subscribe to a platform event. You should not use the empApi component in components that are used by a large number of users because you will run into concurrent cometD client limit. 

Common Use Cases of Platform Events 

1. Loosely coupled integrations — You can integrate Salesforce with an external system using a platform event. This lets you avoid point-to-point integrations and gets you into a publish/subscribe modal. Third-party applications can also publish/subscribe to platform events via public APIs. You no longer need to write complex webservice classes. A flow or apex trigger can publish a platform event and third-party applications can subscribe to it and vice versa. 

Example: If you want to send lead details to an external system when a certain criteria is met, you would have to consume third-party APIs. Now, with a platform event, you just have to publish a platform event and let the third-party application subscribe to it. 

2. Break context in apex transactions — Another common application of a platform event is to break context in a long-running apex transaction. This is generally useful when you are worried about hitting the Salesforce governor limit. 

Example: If you have a lead trigger that processes a bunch of lead management logic, you could consider publishing a platform event at some point in that transaction so that a new transaction is initiated, which gets you a new set of governor limits. 

3. To go around Salesforce limitations — Platform events can help overcome limitations such as Queueable jobs not being able to call a future method or perform DML before a callout. By initiating a new transaction upon publishing a platform event, it provides greater flexibility.

Example: If you have an existing queueable job that updates the lead, which in turn fires a future method, you will run into an error that queueable cannot call a future method. In order to handle this scenario, you can fire a platform event to break the context from the trigger and run the future method. 

4. Exception handling and logging — In your apex trigger or web service class, if you perform a DML to insert exception logs and then a callout, you will run into the Salesforce error, "You have uncommitted work pending. Please commit or rollback before calling out." You can get around this error by publishing a platform event and inserting the exception log in the new context.

Things to Keep in Mind While Implementing Platform Events

1. Platform events support only after-insert triggers
2. Be careful when publishing platform events from triggers — you could run into infinite loops. For example, if you publish a platform event from the trigger associated with the same event object, you will run into an infinite loop. 
3. In the platform event context, by default, the ownerId of the newly created records is set to a system user called Automated Process. To set this field to another value, you can configure the trigger to run as another user. More details are here. 
4. Platform event allocation details can be found here.

Conclusion

The platform event is a great resource to execute your event-driven architecture. With platform events, you can establish loosely coupled applications in your application landscape, which provides greater flexibility in your integrations. While you can publish platform events via the API or by calling the event.publish method, you can subscribe to a platform event using a trigger, flow, or cometD.