Event Driven Architecture (EDA) within Salesforce paradigm

In this post we will discuss Event Driven Architecture (EDA) overview and its implementation within Salesforce paradigm.

Event Driven Architecture (EDA) is a asynchronous software design pattern where a system A produces certain event notifications and interested consumer systems consume those event notifications, both producers and consumers systems are decoupled. Event processing takes in near real time and there are no point to point integration. Communication revolves around a publisher-subscriber model ,a sender publishes a message that one or more subscribers receivers that message.

Much like morning commute time traffic reports broadcast on radio channels, Radio station broadcast traffic report every 10 min’s or so on certain pre defined channel. We the commuters traveling in different cars tune into that channel to listen to that traffic report. All the subscribers to that radio channel receive same report.

Similarly in EDA, System A produces an event message on a certain event channel or a queue and many applications interested in that event message from system A subscribe to that channel to consume message.

Salesforce implements event driven architecture pattern with Salesforce enterprise messaging platform. This provides the delivery of secure and scalable custom event notifications within Salesforce and from external sources.
Salesforce enterprise messaging platform supports two types of notifications PushTopic Events and Platform Events

PushTopic events are generated when changes to Salesforce data create, update, delete, and undelete operations. Subscribers can limit the stream of events to only those events that match a subscription filter. A typical application of PushTopic events is refreshing the UI of a custom app from Salesforce record changes.

Platform Events events can be created by Salesforce or by external system in Salesforce. Two actors are involved in this pattern they are publisher and subscriber.
Any number of subscribers 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 produces events and others that consumes the events don’t have dependencies on each other.

Subscriber of platform event can be one be apex triggers, Process Builder and Flow, aura components with CometD.

In this example we show how we can have custom lightning component subscribe to platform event and displays toast message. We show list of alerts for a particular customer. Events are published using anonymous apex , and process is also used to subscribe to same event channel to read then events and create records in another custom object Alerts.

Use case: System A manages customer specific alerts, when some alert happens in System A it publishes platform event in Salesforce. Two subscribers to that event channel Lightning component and process react to the event when event is published.

Lightning component to display toast message and list of alerts

Salesforce Process subscribe to platform event

MuleSoft was used as middleware to read Platform events and publish them on Slack. Following is Mule flow configuration that subscribes to Salesforce platform event channel and publish events to slack channel.

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:dw="http://www.mulesoft.org/schema/mule/ee/dw" xmlns:slack="http://www.mulesoft.org/schema/mule/slack" xmlns:sfdc="http://www.mulesoft.org/schema/mule/sfdc" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/sfdc http://www.mulesoft.org/schema/mule/sfdc/current/mule-sfdc.xsd
http://www.mulesoft.org/schema/mule/slack http://www.mulesoft.org/schema/mule/slack/current/mule-slack.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/dw http://www.mulesoft.org/schema/mule/ee/dw/current/dw.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd">
    <sfdc:config name="SFDC__BasicAuth" username="xx@xxxx.com" password="xxxxxxx" securityToken="xxxxxxxxxxxxxx" doc:name="Salesforce: Basic Authentication"/>
    <slack:token-config name="Slack__Token_Configuration" accessToken="xxxxxxxxxxxxxxx" doc:name="Slack: Token Configuration"/>
    <flow name="sfdceventsFlow" initialState="started">
        <sfdc:replay-streaming-channel config-ref="SFDC__BasicAuth" streamingChannel="/event/DemoActivity__e"    doc:name="Salesforce (Subscribe to Platform Events)" replayId="-1" replayOption="ONLY_NEW"/>
        <logger message="#[message.payload]" level="INFO" doc:name="Logger Platform Event"/>
        <slack:post-message config-ref="Slack__Token_Configuration" channelId="XXXXXXX" username="SFDC" message="#[payload]" doc:name="Publish Platform Event to Slack"/>
    </flow>
</mule>