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?