Contact
Contact Us
All Insights

Event-Driven Architectures at Texas Dreamin’: Part 3

Event-Driven Architectures for the Salesforce Platform

By: Nathan Neikirk, Salesforce Consultant

Event Driven Architecture’s, including Pub/Sub APIs and Streaming APIs, are fundamental and widely adopted across various platforms and technologies. Salesforce has developed specific implementations of these patterns tailored to its platform’s unique requirements and capabilities. These implementations utilize Salesforce’s infrastructure and offer features optimized for Salesforce environments, while adhering to the core principles of pub/sub and streaming practices widely used in the industry. In this section, I’ll delve into how Salesforce enables event-driven solutions, emphasizing its support for decoupled interactions among multiple systems using Platform Events.

This is Part 3 of a series to walk through Event Driven Architecture with insights from Texas Dreamin’ sessions and Salesforce leading practices to better equip you for future implementations for Event-Driven.

Event-Driven Architectures at Texas Dreamin’: A 4-part Series

Part 1: Introduction to Event Driven Architecture (vs. Point to Point)

Part 2: Classifying Event-Driven Architectures

Part 3: Event Driven Architecture in Salesforce

  • Platform Events
  • Configuration & Publishing
  • Replaying and Monitoring

Part 4: Should YOU implement Event Driven Architectures?

Platform Events

Salesforce Platform Events establish a Pub/Sub event-driven architecture where changes or updates within one system component can trigger actions across other parts of the system or external systems. These events are transient by nature, lacking a defined duration but contain data that subscribers can receive in near real-time. Additionally, they are retained on the platform for up to 72 hours to support replay functionality. Platform Events reside within a channel or a stream, are observable by multiple subscribers, and are impermanent entities that signify occurrences meant for observation once published. To summarize:

  • Customizable Message Contents: Users can customize the contents of Platform Events to include relevant data that needs to be communicated across systems.
  • Responsibility Ends at Publishing: Once a Platform Event is published, the user’s responsibility for that event ends. Subscribers are responsible for consuming and acting upon these events as needed.
  • Support for Large Data Volumes and Streaming: Platform Events are designed to handle large volumes, making them suitable for scenarios where real-time or near real-time data updates are required.
  • Enhancing Salesforce Integration: Platform Events can enhance the integration capabilities of Salesforce with external systems by providing a standardized way to communicate events and trigger actions based on those events.

Configuring Platform Events

  • Like creating a Custom Object, you define a Custom Platform Event by naming it and adding custom fields that define its structure and data attributes.
  • Custom Platform Events support a subset of primitive data types and field types available in Salesforce, enabling customization of event data structures.
  • Unlike Custom Objects, Custom Platform Events do not have Page Layouts, Record Types, or the capability to store individual records. They are purely meant for messaging and do not store data persistently.
  • Salesforce provides predefined events with standard fields, known as Standard Platform Events. Examples include AssetTokenEvent for OAuth 2.0 authentication monitoring and BatchApexErrorEvent for reporting batch Apex job errors.

Platform Event Publishing Methods

When you create a new Platform Event in Salesforce, you will have two options when specifying event publish behavior:

  • Publish Immediately – This option publishes the platform event immediately, regardless of whether the transaction that triggered the event succeeds or not. This means that the platform event is broadcasted as soon as it is triggered, irrespective of the final success or failure state.
    • Platform Events with this publish behavior are ideal for use-cases such as Logging, where you want to publish the event regardless of whether the transaction succeeds and commits.
  • Publish After Commit – This option publishes the platform event only if the transaction successfully commits. This ensures that subscribers receive data from the transaction once it’s finalized.
    • Platform Events with this publish behavior are ideal for use-cases requiring data integrity and consistency post-commit.
  • Custom Platform Events can be created using Apex, Flow Builder, or external APIs. Similarly, events can be subscribed to on the platform via Apex triggers, point-and-click tools, or externally via the Pub/Sub API. When an event is published, subscribers execute associated business logic.
  • Standard Platform Events are published by Salesforce in response to application actions or batch Apex job errors. Subscribers can receive these events using appropriate subscription mechanisms supported by the event.
  • Since the Spring 21’ Salesforce release, Platform Events are published asynchronously.

Replaying Platform Events

  • Platform Events defined in API version 44.0 or earlier are officially defined as Legacy Standard-Volume Platform Events. In API version 45.0 and later, new event definitions are defined as High-Volume Platform Events by default. Standard-volume Platform Events are still supported by are not available for new Platform Event definitions. High-Volume platform events offer better scalability than standard-volume platform events.
  • High-Volume Platform Event messages are stored for 72 hours, allowing for event replay within that timeframe. Legacy Standard-Volume Platform Event messages are only stored for 24 hours.
  • Replay of Platform Events is only available through the Pub/Sub API. This allows subscribers to implement event replay functionalities into their applications or processes as needed.
  • Communication protocols, such as CometD or gRPC serve as the bridge between Platform Events and external systems, allowing real-time data synchronization and event-driven interactions.
  • These protocols supports a replay mechanism whereby subscribers can jump backwards in a stream of messages to a fixed point (using the ReplayID of the last event message the subscriber received) and have the message between that point and the present re-sent to the subscriber.
  • For example, if a client drops connection for an hour, it can replay all of the events created since the last even received event by supplying the event’s ReplayID. However, if the client drops connection longer than the event’s replay window, the client will be unable to replay the event.

What is Real-Time Event Monitoring and Standard Event Monitoring?

  • Real-Time Event Monitoring provides standard platform events that you can subscribe to for monitoring user activity in real time, such as logins and running reports.
    • For example, you can subscribe to the event channel for LoginEventStream to receive notifications when users log in.
  • Real-Time Event Monitoring allows you to detect unusual behavior sooner than with traditional Event Monitoring and take action if necessary. Traditional Event Monitoring doesn’t send real-time notifications. Instead, it stores user activity in a log that you have to manually query.
  • Traditional Event monitoring is accessed through the SOAP API and REST API by way of the EventLogFile object. Therefore, you can integrate log data with your own back-end storage and data marts to correlate information from multiple orgs and disparate systems.
  • Real-Time Event Monitoring is a user activity and application monitoring service available to Salesforce customers through the purchase of Salesforce Shield or Salesforce Event Monitoring add-on subscriptions.

Read the next article in the series

Resources:
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro_emp.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_monitor.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_svpe.htm
  • https://medium.com/salesforce-architects/the-new-salesforce-event-bus-f82165cb0585
  • https://www.salesforceben.com/salesforce-platform-events/
  • https://architect.salesforce.com/diagrams/design-patterns/publish-subscribe
  • https://trailhead.salesforce.com/content/learn/modules/realtime-event-monitoring/get-to-know-realtime-events-and-transaction-security
  • https://dzone.com/articles/salesforce-event-driven-architecture-using-platfor#:~:text=Publish
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro_other_events.htm
  • https://architect.salesforce.com/decision-guides/event-driven#When_Should_You_Not_Use_Event_Driven_Architectures_
  • https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/pubsub_api_streaming_api_comparison.htm
  • https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/cdc_event_diff_pubsub_cometd.htm
  • https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/using_resources_event_log_files.htm
  • https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_streaming.htm&type=5
  • https://trailhead.salesforce.com/content/learn/modules/platform_events_basics/platform_events_architecture
  • https://trailhead.salesforce.com/content/learn/superbadges/superbadge-events-sbu
  • https://www.absyz.com/introduction-to-streaming-api/
Texas Dreamin’ 2024 Special Thanks to:

Platform Events Revisited:

  • Rick Locke – Senior Technical Architect, Komodo Health
  • Jeremy Hayes – Senior Technical Architect, Komodo Health

Demystifying Pub/Sub API:

  • Federico Henderson – Salesforce Tech Lead, Altimetrik
  • Gabriel Juarez – Salesforce Tech Lead, Nearsure

Platform Events vs. Mixed DML, How Admins Can Win the Day:

  • Michelle Hansen – Principal, Slalom

Related Insights

Salesforce

Event-Driven Architectures at Texas Dreamin’: Part 4

| Article
Read More
Salesforce

Enhancing User Experience by Integrating DocuSign with Salesforce & Endur

| Customer Story
Read More
Salesforce

Event-Driven Architectures at Texas Dreamin’: Part 2

| Article
Read More
  • Hidden
  • This field is for validation purposes and should be left unchanged.