Event Notification & Callback – Salesforce Integration Design Pattern

In my last article, I explained an integration design pattern for simple integration requirement. You can consider this article as continuation of other article, and I would be discussing an integration requirement that may not be simple. If you have not read the other article, then you can read it here: Salesforce Platform Events – No code integration solution.

As always, I would be discussing this with a real-life integration requirement. I would explain the requirement, discuss the possible solutions and the integration design pattern that I use for similar requirements.

Integration Requirement

Salesforce is system of record to create quotes. Each quote may have one or more line-items, and, in some case, it may have large number of quote line-items. Once the quote is accepted by client, it is converted to an order and all quote line-items are converted as order line-items.

Once a new order is generated in Salesforce, we have to send the order details along with all order line-items to back-end systems for fulfillment. Once the order is created in fulfillment system, an Order Id and Line-Item Ids are generated in fulfillment system, and it is updated on Order and Order Line-Item records in Salesforce for cross-referencing. These IDs are used to update fulfillment status in Salesforce. Updating Fulfillment status back in Salesforce is not in scope of this article and it is going to be pretty straightforward using standard Salesforce REST API.

Potential Solutions

Now we know the requirement, and it is time to explore the options. We can have different solutions to meet this integration requirement. No solution is bad and there could be a specific circumstance when that may be the best solution. I am going to share few options that I explored and then decided to go with the option that I thought would be better fit for this.

• We can have an APEX Class that calls an HTTP API and send order along with order line-items. Salesforce need to develop a complex APEX service to extract, transform and send. This can be good solution and I saw this in several engagements. This may not be scalable if we have to send Order data to more than one system. Because of complexity of APEX, it may create challenges in maintenance and any future enhancement requirements.
• We can have middleware tool to query periodically for any new order and will have middleware to pull the order and order-items using Salesforce standard REST API. This does not require any development at Salesforce. It may take some time for order to reach fulfillment. Also, this requires regular polling by middleware even there is no order in system. Also, in some cases you need to pull data from multiple objects, and it may be difficult to use standard REST API.
• Create a Salesforce APEX batch class that sends order and order details to an HTTP API every-night. This also requires writing complex APEX
• Notification and Call-back. In this approach Salesforce would notify middleware about a new order in Salesforce. Once Middleware receives the notification, it calls back Salesforce and pulls the order details. We can send the notification using outbound message or platform events. Also to pull-back order details, middleware can use standard REST API or salesforce APEX service.

Integration Design Implemented

As you see, we can have multiple solutions to same integration requirement and these solutions may be the best solution for specific circumstances. For example, if there is no middleware you have to use APEX based solution. If you refer the above solution diagram, then you know what I prefer as long as we have middleware system for similar requirements.

I decided to use “Event Notification & Call-back” as design pattern for this requirement. Few years back, I was using outbound message to send the notification but now with Platform Event I prefer to publish a platform event message with Order Id and let the middleware or external system to callback Salesforce and pull the order details along with order line-items.

We can use standard REST API or custom APEX service to get the order details. It all depends on complexity of your payload and if you would like to do some pre-processing before generating the payload. I would list down the solution flow below: –

1. A sales user converts an existing quote to order and a new order with order line-items are created in Salesforce
2. New order triggers the APEX code or record triggered flow
3. APEX code or Salesforce Lightning Flow publishes a Salesforce Platform Event with Order Id
4. A middleware flow listening platform event using CometD gets the notification for new order
5. A middleware flow calls Salesforce API (APEX Service or standard REST API) and pulls order and related data
6. Middleware flow uses native connector (or API) to create order and order line-items in backend system
7. Middleware flow calls-back Salesforce standard REST API to update cross-referencing IDs in Salesforce for future interactions.

Conclusion

Not all integration requirements are same and so single solution may not be ideal solution for all your business needs. Fortunately, Salesforce offers so many different development options and with power of partner applications like middleware you get everything to design solution for your integration requirements.