Understand Event-Driven Software Architecture
Learning Objectives
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, a CometD-based tool, and Pub/Sub API. 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.
- To learn about CometD, check out the Streaming API Developer Guide.
- To learn about Pub/Sub API, check out the Pub/Sub API Documentation.
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 Platform API Basics Trailhead module, we use the analogy of radar on a pirate’s ship to represent event detection. This analogy works well for the streaming of change data capture 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.
EventA 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.
Event message
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.
Event producer
The publisher of an event message. For example, an order placement app.
Event channel
A stream of events on which an event producer sends event messages and event consumers read those messages. For platform events, the channel is for one platform event or a custom channel that groups event messages for multiple platform events.
Event consumer
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.
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 as won 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 for specific products. 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. The vendor responsible for shipping the specific product creates the shipment.
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 Flow Builder. 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 |
|---|---|---|
| Location | Location__c | Text Length: 100 |
| Urgent | Urgent__c | Checkbox |
| News Content | News_Content__c | Text Area (Long) |
Platform Events and Salesforce Objects
A platform event is a special kind of Salesforce entity, similar in many ways to a Salesforce object. An event message is an instance of a platform event, similar to how a record is an instance of a Salesforce object. Unlike with records, you can’t update or delete event messages or view them 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 Emp API Lightning component to consume events. As an alternative to code, you can publish events with the Flow Builder declarative tool. External apps publish events using the sObject API or Pub/Sub API, and consume events using CometD or Pub/Sub API. As you can see, there is a lot of flexibility in how you choose to use Platform Events!
Use platform events in these 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
Another type of streaming event is a change data capture event. This event contains changes of Salesforce records for create, update, delete, and undelete operations. For more information, see the Change Data Capture Basics Trailhead module. For a comparison of event types, see Streaming Event Features in the Streaming API Developer Guide.
In the next unit, we go over defining a platform event and publishing events.
