Point to Point integration vs middleware

Question

I'm a newbie in integrations and I've been recently thinking about when to use Point to Point and middleware integrations. My goal is to somehow understand how to decide which one is the best when architecting a Salesforce org.

I've done some research online, but haven't found information with enough detail for me to fully understand what's going on.

My only experience with integrations was SAP calling GET method of a class with @RestResource annotation in Salesforce and retrieving about 1000 records a day. The reason why we did it this way was that they had a very strict security policy regarding their SAP, so instead of sending data from Salesforce to SAP, they wanted to retrieve it from Salesforce on their terms.

This article lists 3 examples of using middleware, which I do not understand.

• Scenario (1) Apex class calls a web service to complete its processing. Everything looks good until a large number of users start using it and the web service takes in excess of 5–10s to respond. Soon you start hitting the concurrent apex execution limit. You need to change your architecture to use outbound message to reach a middleware who would then call the web service. This kind of fire and forget integration pattern allows you to scale when you cannot control the performance of your downstream systems and external systems.

This seems like an Apex class that would be for example called from a Lightning Web Component. Why not use the Queueable interface for making callouts? And how would the middleware solve our issue - would it somehow make less callouts to a web service, because it would wait for an outbound message and then execute all the requests from Salesforce at once, making it a single callout?

• Scenario (2) What if you had to contact multiple external systems to complete a transaction in Salesforce. Without a middleware, you would have to write complex code to chain the different callouts and take care of maintaining the state of transaction. It is not only complex to code this, to implement re-try in this mix is a nightmare.

Does it mean that the middleware used here already has the solution for calling the external systems the author is talking about here? Basically the equivalent of middleware here is downloading an app on AppExchange instead of eventually building it yourself? The downside of this would be the cost of the middleware, wouldn't it? Also how is chaining using code different from buying a middleware software and then chaining with it?

• Scenario (3) Backend system A wants to push data into Salesforce, it ends up building all the code required to consume Salesforce’s Bulk API. Few months down the line, another Backend system B wants to push another set of data to Salesforce. With 3 releases a year, Salesforce goes ahead and upgrades the Bulk API to v2. Now you need to ask each of your backend systems to make this change to take advantage of the newer capabilities. A middleware would have accelerated your IT investment by localizing integrations to Salesforce in one place.

Would it really accelerate the investment, given that you'd have to buy licenses of that middleware system? Is it really an example of a situation that has to be 100% middleware based?

Answer 1

For me, this question is too opinion-based to be answered here, but here's an opinion-based answer all the same.

I recommend middleware when:

1. Data transformations are required; by putting this off-platform you can allow larger quantities of data to be transferred in a single interaction because you are not asking Salesforce to run some code that transforms the data. You also make it easier to adjust and adapt since middleware supports this sort of thing much more cleanly than anything you develop on-platform.

2. Data volumes are large; similar to point 1, middleware can help you shift more data on- and off-platform whilst not causing governor limit issues (other than, perhaps, API limit usages if you're not careful).

3. Data ownership is contentious; e.g. when records (or specific values within those records) are collectively owned by two or more systems, the middleware can help ensure correct synchronization between these multiple systems without hitting race conditions and spurious duplication.

4. There are more than 2 systems that must be synchronized; let's face it, you'll likely hit points 1, 2 or 3, above, anyway, but even if you don't and have more than 2 systems involved, it will be much easier to keep them synchronised if you can decouple that synchronization and control it using middleware that is designed to handle such synchronization.

5. As mentioned by @cropredy in a comment, middleware can make integration retry handling far easier, and can maintain a queue updates were one of the integration parties to become unavailable.

When not to use middleware:

1. You have just one, very simple integration needed, typically with little data transformation and one-way or with very simple and highly segregated data ownership for simple synchronization scenarios.

Of course, this situation could change as your solution evolves and you may find you need to adopt middleware anyway. So be prepared for this and keep the code for the integration as simple and as modular as possible to make it easy to remove again later.

Clearly there can be a learning curve to any middleware, as with any configuration-driven software (such as the Salesforce platform itself), and you may want to balance this against anticipated requirements and whether you have devs who already know how to use Salesforce's integration mechanisms.