Skip to main content

When should we use Platform Events vs SOAP/REST APIs

Introduction

This post is an extension of a Question on Salesforce Stack Exchange and the discussion around the same. With so much attention on this topic, I thought of putting a comparison of when to use Platform Events vs. APIs (REST/SOAP) when it comes to Integration. The post describes the basics of both features and how they compare with each other and scenario when those are used.
If you happen to come across this post, do leave your feedback and recommendations.

Let’s Get Started

What is Platform Event?

Simply speaking, it is Salesforce’s approach of implementing an Event Driven Architecture. While I am not going into details of the architecture itself, this approach leads towards a Pub/Sub (Publisher/Subscriber) model. The model establishes a “Publisher” which publishes any data change using events (or messages), which is subscribed by one or more “Subscribers” which listen on those events and accordingly take action.

So When Do I Use It?

Whenever you want to implement a Pub/Sub model. As an example, let’s say you want to integrate Salesforce with multiple External Systems, and that you only want the External Systems to receive data from Salesforce whenever say an Opportunity reaches to stage Qualified (while you can use callouts/outbound messaging but that will mean Salesforce takes care of every callout in that case), this is where you can use Platform Events.

In this case, whenever there’s an update, you just Publish an Event and then Subscribers which keep on listening to the Event, perform actions as required whenever they get the notification. Also you just don’t want to publish a ton of information with the Event itself, rather only a notification as “What changed”, and then leave it to the Subscriber to decide what they want to do with “What changed”.
You can also use Platform Events when you want an External System notify Salesforce to act upon something, where the External Event “Publishes” the change on the Salesforce Event Bus and then Salesforce listens to those Events and acts upon accordingly.

How does Platform Event compare to REST/SOAP APIs?

There is no direct relationship between Platform Event or REST/SOAP APIs. They co-exist serving different purposes.
REST/SOAP APIs are way to expose a “(Web) Service” over HTTP. That means when someone calls an API, the caller expects certain details to be transferred either to them or to Salesforce based on the request. As an example, you provide an Account Id to get details back from an Account or you write to Salesforce objects on certain conditions. A Web Service is targeted to provide information around the data as compared to what an Event message consists of. While you can always transfer data using Platform Events, but consider if you need to transfer a full Opportunity details – you will end up creating those many fields on a Platform Event object which already exists on an Opportunity, definitely not a good design!
And then and most importantly, Platform Events are “transient” in nature, i.e., they are retained only for 24 hours, whereas a Service is always available to an end system is available On-Demand.
A very basic image to highlight how both Platform Event and Services are patterned in Salesforce.
Salesforce Events and APIs

When should I use Platform Events vs. APIs?

Platform Events

  • When you want to design a Pub/Sub integration model
  • When you don’t want to transfer lot of data
  • When you only want to “notify” a subscriber with an event or message with minimal information for them to act upon
  • When you want your notification to be transient in nature
Remember, even in case of Platform Events, to transfer data on a larger scale, you still need APIs.

REST/SOAP APIs

  • When you are building a true Web Service
  • When you are dealing with data instead of a simple notifications
  • When you want the service/data available across the lifecycle

Comments

Popular posts from this blog

Define & View Custom Big Object

Define a Custom Big Object: You can define custom big objects with Metadata API or in Setup. After you define and deploy a big object, you can view it or add fields in Setup. After you’ve deployed a big object, you can’t edit or delete the index. To change the index, start over with a new big object. To define a big object in Setup, see Salesforce Help. View a Custom Big Object in Setup After you’ve deployed your custom big object, you can view it by logging in to your organization and, from Setup, entering  Big Objects  in the  Quick Find  box, then selecting  Big Objects . Click the name of a big object, to see its fields and relationships. View a Custom Big Object in Setup After you’ve deployed your custom big object, you can view it by logging in to your organization and, from Setup, entering  Big Objects  in the  Quick Find  box, then selecting  Big Objects . Click the name of a big object, to see its fields and ...

Publish Paltform Events

Publishing Platform Events The Salesforce enterprise messaging platform offers the benefits of event-driven software architectures. Platform events are the event messages (or notifications) that your apps send and receive to take further action. Platform events simplify the process of communicating changes and responding to them without writing complex logic.  Publishers and subscribers communicate with each other through events.  One or more subscribers can listen to the same event and carry out actions. Here we will see how many ways you can able to publish the platform events in Salesforce.  After a platform event has been defined in your Salesforce org, publish event messages from a Salesforce app using processes, flows, or Apex or an external app using Salesforce APIs.Here is the simple platform event object we will be using in the examples here Here are the different ways you can able to publish the platform events in Salesforce Option 1: Using Proces...

Platform Events in Batch Apex

Fire Platform Events from Batch Apex Classes Introduction  With winter 19 release you can able to fire the platform events from the batch apex.Batch Apex classes can opt in to fire platform events when encountering an error or exception. Clients listening on an event can obtain actionable information, such as how often the event failed and which records were in scope at the time of failure. Events are also fired for Salesforce Platform internal errors and other uncatchable Apex exceptions such as LimitExceptions, which are caused by reaching governor limits. An event record provides more granular error tracking than the Apex Jobs UI. It includes the record IDs being processed, exception type, exception message, and stack trace. You can also incorporate custom handling and retry logic for failures. You can invoke custom Apex logic from any trigger on this type of event, so Apex developers can build functionality like custom logging or automated retry handling. To fire a ...