trailhead

Understand Event-Driven Software Architecture

Lightning bolt icon used to indicate that the content is for Lightning Experience

Attention, Trailblazer!

Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Lightning Experience.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

Learning Objectives

After completing this unit, you’ll be able to:
  • List the components of event-based software architecture.
  • Explain the benefits of an event-driven software architecture.
  • Describe use cases for the Platform Events feature.
  • Describe the characteristics of a platform event.

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.

Note

Note

If you haven’t already, complete the API Basics module before you work on this module. Familiarity with the concepts of Streaming API is a prerequisite for this module.

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. Non-required disclosure: Salesforce is fast, but not as fast as the speed of light!

In the 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.
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 over a channel. 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. Also called an event bus in Salesforce.
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.

A diagram showing components of event-based systems: event producers, which feed information into the event bus, which sends messages to the event consumers

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.

In this diagram, a product order app publishes an order event to an event bus. Various vendor apps subscribe to the event bus and receive the event.

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.

An external vendor app publishes a platform event message for a merchandise return request. In Salesforce, a trigger subscribes to the event bus and receives the event.

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.

In this diagram, an app in Salesforce publishes a platform event. A trigger subscribes to this event channel and receives the event.

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 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 to consume events. Also, Visualforce and Lightning component apps can subscribe to events using CometD. As an alternative to code, you can publish events with declarative tools, such as Process Builder and Cloud Flow Designer. Finally, external apps publish events using the sObject API and consume events using CometD clients. 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 Check mark
Include user-defined payloads Check mark Check mark
Publish events via one or more APIs Check mark Check mark
Publish events via Apex Check mark
Subscribe via CometD Check mark Check mark
Subscribe via Apex triggers Check mark
Publish declaratively using Process Builder and flows Check mark

In the next unit, we go over defining a platform event and publishing events.

retargeting