Messaging Architecture With Salesforce

• Share this article

• FB
• Twitter
• Linkedin
• Email

Distributed software development has been growing rapidly in the world over the past years. However, distributed systems are difficult to debug and understand, they will keep up with the increasing requirements forced by e-business. That is where Event Driven Architecture allows you to work with multiple applications.

Let’s tell you more about how Event Driven Architecture evolved from the traditional point-to-point model in Java Message Service (JMS) and Salesforce platform events.

Messaging: What is it?

In programming, messaging is the exchange of a piece of data (specially formatted data that describes events, gives requests and replies) between system components or different applications which may or may not run in the same platform.

As a concrete example let’s take a Post Office and a Postman. You are sending a message via POST to your friend. So you are a client who is sending a message and your friend is a client who is receiving the message. But we need to have a middleware (Postman) who can take your message and send it to your friend. This postman is the Message Oriented Middleware.

1. It is a loosely coupled communication; It doesn’t matter who the sender and receiver are. In the diagram above, Application A sends a message indicating a particular destination to Application B. Let’s assume that in the future application A is replaced with a different application: application C. This new program will send the same messages and application B will continue to process them. The program doesn’t need to know there is a new application sending orders.
2. Asynchronous Messaging: Asynchronous messaging means that sender does not expect an immediate response from client and message will arrive automatically to the client when they become available. There can be a response or not, but the sender will carry out his remaining tasks.
3. Reliable Delivery: It makes sure that a message is delivered without any data loss.

Point-to-Point (P2P) Integration challenges

Point-to-Point Integration is a very common solution that allows multiple systems to communicate via a request-response model. This is mainly implemented with APIs.

P2P integration can be a lightweight and a good solution to connect everything when your organization has only a few components. Unfortunately if the company grows and the number of applications used become massive, P2P integration will be a headache and become quickly unmanageable. Inclusion and removal of entities to the communication will be time consuming. Dependency on every integration point makes its maintenance heavy. There will be an inconsistency in the data exchange format.

What can be the solution?

Event Driven Architecture (EDA)

Event Driven Architecture is a software architecture pattern focused on events. Events are the quick way to exchange data between multiple points. EDA is a design pattern built around the production, detection and reaction to events that take place in time. An event can be defined as a significant change and state. The actions are taken based on the event.

Eg: If there is an event which says that a new message has arrived, a specific action will be triggered to process this message. Once the message is processed, the system will trigger another event which says ‘messages processed’. Based on the processed messages another service, listening to that event, can be triggered. All the services can interact with each other using Event Bus.

Components of Event Driven Architecture

• Event: A change in state that is meaningful in a business process.
• Event message: A message that contains data about the event. Also known as an event notification.
• Event Producer: The publisher of an event message over a channel (Produces or Publishes events)
• Event Consumer: The subscriber of an event message over a channel (Subscribes or Listens to event ,takes the event and process with them )
• Event Bus: A stream of events on which an event producer sends event messages and event consumers read those messages.

Event Driven Architecture (EDA) vs Peer-to-Peer architecture (P2P)

One of the most important features that differentiate the EDA architecture from P2P is the centralized communication channel: “Event Bus”. This architecture is scalable and loosely coupled, because it is very easy to add multiple producers or multiple consumers. At the same time, if you want to remove consumers or producers from the communication it doesn’t impact or affect any other entities involved in the particular communication.

It is built around the concept of queue which is “First In First Out”: the first request in the queue will have the first answer as well as the last request will have the last answer. In PTP model, one message is delivered to one receiver only. But it doesn’t mean you should only have one receiver. The queue might have multiple receivers and senders but only one receiver may consume each message.

2. Publisher-and-subscriber Messaging

1. In a Publisher-and-subscriber Messaging environment, there is a queue instead of a topic. Publisher sends the message and topic replicates the message into as many subscribers as we have. It creates copies of a single message and delivers it to all subscribers. It is like delivering newspapers to everyone.

Integrate Salesforce Using Platform Events

Salesforce Platform Events

With the help of Salesforce Platform Events we can have the ability to implement the event driven architecture. Publishers don’t know anything about subscribers and vice versa. This gives us the possibility of implementing an event driven architecture, which is suitable for large distributed systems. Platform events simplify the process of communicating changes and responding to events. One or more consumers can listen to the same event and carry out actions. With an Event-driven architecture each service publishes an event whenever it updates or creates data. Other services can subscribe to events.

Creating Platform Events in Salesforce :

• We can integrate different systems with Salesforce. Salesforce application and the external application can act as producers or consumers
• The platform events are like Sobjects (Salesforce Entities) that we can create within our Salesforce
• It is almost like creating custom object. But it is not the same as custom object
• Platform Events are suffixed with “__e”
• There is a standard field called “ReplayID” which we get when we create platform events..This ID is very important to replay the same event. Let’s assume that if the consumer was down for a certain period of time, we can point to the event bus with the last replay ID and replay all those events and consume them back
• With the platform events we can define different types of events for different types of integration using custom object fields and types. Data types for platform events are limited to only specific types

Publishing /Subscribing to Platform Events

In Salesforce we can either act as a publisher or subscriber.

Tools to publish event:

• Process Builder
• Flows
• Apex
• API (REST/SOAP)

Tools to subscribe event:

• Process Builder
• Flows
• Apex Trigger
• CometD

Real World Scenario

The above image shows two applications. One is a food ordering application in Salesforce where all the details are related to an orderstore in this application. The other one is an external application which is responsible for delivering the food.

Let’s take a look into this path:

• Once the food is ready to collect, the Salesforce application will change the status of an order into “Ready Collect”.
• This will notify via an external application the delivery company that the food is ready, so they can collect the food.
• Once they collected the food they notify back to the food ordering system in Salesforce so the Salesforce application will change the status into “Food Collected”.
• Once the food is collected, it will be delivered and the external application will notify the Salesforce application again to let everyone know the food is delivered.
• So the Salesforce application again change the status into “Delivered”.
• In case the delivery is failed, the external application notifies that the delivery is failed. So the Salesforce application will change the status into “Delivery Failed”.
• In this case the Salesforce application is a publisher and the external application is a subscriber.
• In order to publish an event we can use an apex method called EventBus.Publish(). This allows you to publish a particular event.
• When the food is collected you should be listed or subscribed to the event raised by the external application and based on that we need to prepare some processing logic which updates the status.
• In this case theSalesforce application is the subscriber and the external application is the publisher. In order to determine if the delivery was a success or if it failed we can use Process builder or Apex trigger.

Publishing Events

1.Publishing Events

Publishing using Apex

Subscribe to Platform Event using Apex

Refire Event Triggers with EventBus.RetryableException

Platform Events

More news about

• Salesforce