Understand Event-Driven Software Architecture
Before You Start This Module
We know you're eager to get started! But before you settle in to work through this module, you should be familiar with some concepts to be able to complete this module.
This module shows you how you can publish platform events using Apex, REST API, flows, and processes. Also, you can subscribe to platform events using Apex triggers, flows, processes, a Lightning component, and a CometD-based tool. To be able to understand this module, you should be familiar with at least one of these technologies. To be able to perform the hands-on challenge in this module, you should have knowledge of Apex triggers. Here is a list of a trail and modules you can take to learn Apex.
- If you don't have prior knowledge of an object-oriented programming language, take this trail: Build Apex Coding Skills trail
- If you're familiar with an object-oriented programming language, check out these modules: Apex Basics & Database, Apex Triggers, and Apex Testing.
Understand Event-Driven Software Architecture
Has your order system shipped a package? Do your printer cartridges need replacing? Whatever you want to be notified about, the Salesforce enterprise messaging platform provides the delivery of secure and scalable custom notifications within Salesforce and from external sources. With platform events, you can monitor your systems and communicate changes to other systems.
The paradigm of event-based communication revolves around a publisher-subscriber model—a sender broadcasts a message that one or more receivers capture. It’s like radio transmission—a transmitter tower broadcasts a radio signal, and receivers get the signal if they’re tuned to the right frequency.
Much like radio transmission, event-based communication flows from the sender to the receiver. Events get sent whether or not receivers are listening, and receivers don’t acknowledge it when they receive an event. Event-based communication takes place in real-time—or, more accurately, in near-real time. Radio waves travel at the speed of light, but event-based software and hardware systems typically have some latencies.
In the Lightning Platform API Basics module, we use the analogy of radar on a pirate’s ship to represent event detection. This analogy works well for the streaming of PushTopic events, which are based on changes in Salesforce records. That communication model requires only a subscriber. But with platform events, there are two parties to the communication: a sender and a receiver. They are two of the components of an event-driven architecture.
Components of Event-Driven Systems
Before we go any further, let’s define some terms.Event
A change in state that is meaningful in a business process. For example, placement of a purchase order is a meaningful event, because the order fulfillment center expects to receive a notification before processing an order.
A message that contains data about the event. Also known as an event notification. For example, an event message can be a notification about an order placement containing information about the order.
The publisher of an event message over a channel. For example, an order placement app.
A stream of events on which an event producer sends event messages and event consumers read those messages.
A subscriber to a channel that receives messages from the channel. For example, an order fulfillment app that is notified of new orders.
The following diagram illustrates an event-based software architecture.
Unlike request-response communication models, software architecture built on an event-driven model decouples event producers from event consumers, thereby simplifying the communication model in connected systems. No requests need to be made to a server to obtain information about a certain state. Instead, a system subscribes to an event channel and is notified whenever new states occur. Any number of consumers can receive and react to the same events. When an event occurs, systems obtain this information and can react to it in near-real time. Systems that send events and others that receive the events don’t have dependencies on each other, except for the semantics of the message content.
The Salesforce enterprise messaging platform offers the benefits of event-driven software architecture. Platform events are the event messages that your apps send and receive. They simplify the process of communicating changes and responding to them without requiring you to write complex logic. Publishers and subscribers communicate with each other through platform events. One or more subscribers can listen to the same event and carry out actions.
Say a news agency called Cloud News sends events to subscribed clients with the latest breaking news about traffic and road conditions in a mountain retreat destination. The contents of those events are not just the news items themselves but also related details such as whether a piece of news is urgent, and the location of the incident. Subscribers can receive these events and determine what actions to take based on the urgency of the news.
All this sounds good, but what are some real-world cases when you can use platform events? Of course, the use of platform events isn’t restricted to a news agency. Following are a few useful applications.
Examples of When to Use Platform Events
Let’s take a look at a few business scenarios that use platform events. In these scenarios, Salesforce and external systems communicate through platform event messages. In the first scenario, an app in Salesforce notifies external order fulfillment apps of a product shipment order. In the second scenario, an external product app notifies Salesforce of merchandise returns. The last scenario shows how event messages are used within Salesforce by using triggers.
Platform to External App: Order Fulfillment in a Vendor App
When an opportunity closes in Salesforce, your company has won a deal with a customer. Let’s say you use vendors to ship products associated with an opportunity. Each vendor has an external app that processes shipment orders. The external app listens to platform events. When an opportunity closes, a trigger, which is part of a product order app in Salesforce, fires and publishes a platform event message. Each vendor app is notified of the event and creates a shipment order for a specific product.
External App to Platform App: Process Merchandise Returns in Salesforce
Let’s say someone wants to return purchased merchandise to a vendor. An external system sends merchandise return requests to Salesforce for processing. The external system publishes a platform event to alert Salesforce to the merchandise return. An event listener (a trigger) in Salesforce receives the event and performs some actions. For example, the trigger might alert the sales representative to the return, and send a confirmation email to the customer.
Platform to Platform: Reassign Lead Records
When a lead is assigned in Salesforce, a lead trigger fires and checks open opportunities and cases related to the lead owner. Based on the related records, the trigger publishes an event that is received by a Salesforce app. Based on the event information, the app reassigns the lead and creates a Chatter post.
In this scenario, you can perform the same actions using other Salesforce features, such as Process Builder or flows. But by using platform events, you benefit from an event-based programming model and a standard way of programming across your apps.
Platform Event Characteristics
Now that you have an idea of when to use platform events, let’s dive deeper into their components and characteristics.
You define the custom data that platform events contain. Just like custom objects, you define platform events in Salesforce. You create a platform event definition by giving it a name and adding custom fields. Here is a sample definition of custom fields for a news event for the Cloud News agency.
|Field Label/Name||Field API Name||Field Type|
|News Content||News_Content__c||Text Area (Long)|
Platform Events and sObjects
A platform event is a special kind of Salesforce entity, similar in many ways to an sObject. An event message is an instance of a platform event, similar to how a record is an instance of a custom object. Unlike with custom objects, you can’t update or delete event records, or view event records in the Salesforce user interface.
You can set read and create permissions for platform events. You grant permissions to users in profiles or in permission sets.
Using Platform Events in Native and External Apps
Platform events enable the flow of event messages within Salesforce and to or from external apps. Apps on the Salesforce platform use an Apex method to publish events and an Apex trigger or the empApi Lightning component to consume events. As an alternative to code, you can publish events with declarative tools, such as Process Builder and Flow Builder. External apps publish events using the sObject API and consume events using CometD. As you can see, there is a lot of flexibility in how you choose to use Platform Events!
Differences Between Platform Events and Other Streaming Events
What about other streaming events? Other events include PushTopic and generic events. With PushTopic events, clients receive messages about changes in Salesforce records based on a predefined query. With generic events, you can send and receive arbitrary message content (payloads) not necessarily tied to Salesforce records. Platform events are similar to generic events but offer more powerful customization. With platform events, you can publish any custom data. You define the schema of event data at a granular level as typed fields. Also, you can use platform events in native Salesforce platform apps and external apps alike. Use platform events in the following cases:
- To send and receive custom event data with a predefined schema
- To publish or subscribe to events in Apex
- For the flexibility of publishing and processing events on and off the Salesforce platform
This table compares the features of generic events and platform events.
|Feature||Generic Event||Platform Event|
|Define event schema as typed fields||
|Include user-defined payloads|
|Publish events via one or more APIs|
|Publish events via Apex||
|Subscribe via CometD|
|Subscribe via Apex triggers||
|Publish declaratively using Process Builder and Flow Builder||
In the next unit, we go over defining a platform event and publishing events.