Interesting question every then and now – do we need to purchase a middleware or do a point-to-point integration?
When I recall all the CTA related scenarios, there probably wasn’t any, where we wouldn’t propose ESB in the picture. But worth to know that these solutions don’t have any budget constrains which makes real life decision a bit different.
A great article has been published on SalesforceBen related to this and this exact article was the reason for my blog post.
All the points in the article are valid, but the real life might be different, like on our last project.
Imagine a company, which has existing Salesforce implementation, connected to their DWH via Pentaho, because that’s a tool they know and use for everything. Now they are entering phase 2 with 8 more integrations and the question is obviously on the table.
The answer is not that clear anymore, once you describe the integrations:
- Company register, when they are creating a new account in SF they want to just enter its identification number and get all the details from the government run register – no typing, no extra clicks, load also relevant contacts;
- Being able to check the company health via a dedicated provider – click on a link, it will open the website with already filtered out the respective company. There is no write back of data into the system, just visual check how it looks now and whether we can proceed with doing business with the company;
- eSignature of orders (think DocuSign or similar);
- LinkedIn integration as additional source of contacts;
- Sending SMS based on activities done in the system and as a reminder for meetings;
- Integration with mass mail sending system;
And the list goes on. What might have look pretty clear at the beginning – 8 separate systems to integrate with obviously might be a great reason for purchasing ESB solution.
But when you describe the system and use cases it isn’t so clear to me anymore.
You ask why?
Let’s go one by one:
- You will need to develop the custom LWC component which would wrap the logic and user interaction. You can call the end system directly from here or call ESB which would call the system. Added value? When you will change the data provider you can just change the mapping on the ESB level and not touch the SF side at all. But how often that would happen and is it really easier than change the logic in the Apex controller or Flow? Because we would not use any other benefit of ESB – such as retry, load balancing, etc. We might still use it to store the debug or track the usage off-platform, but we can probably do it easily on SF side as well;
- This is just a URL link with some identifier – most likely the company identification number – at the end, no added benefit of opening the URL via ESB which would just redirect elsewhere;
- eSignature and all the following share one main reason – most likely there is already an existing AppExchange app, which handles that, you can just install and configure it and be up and running. Do you really want to develop your own LinkedIn integration (impossible) or integrate the emailing system from scratch? There is no point and the ESB doesn’t provide any value here.
When does it make sense?
To me the use cases are pretty clear when typically looking in the mirror as the typical company slowly evolves and add additional systems in the landscape. What made sense to do point-to-point at the beginning (like connecting SF to DWH directly) suddenly doesn’t make much sense as you need to develop each integration on its own, update all the data mapping on multiple places if new tables are added, etc.
Once you have complex integration where you need to query one system, based on results query another one, transform data and then act on them – that might be great use case.
When you have a lot of calls going here and there and you might be able to use ESB as some kind of cache to save on the SF calls.
When you need to update data during night based on external system it makes sense to run it off-platform and don’t waste scheduled job development on SF side.
When it is happening in the background and you need to have a way to retry failed operations – it might be easier to do on ESB side rather than develop on SF side.
When you need to connect to on-prem systems and IT isn’t willing to open a firewall to you – you will most likely want to run this operation from inside and just call out to Salesforce.
Not the easiest decision
What looked like an easy choice at the beginning isn’t that easy at the end. You rarely have all the information at start, the fixed system landscape, understanding of the complete data flow. Starting point-to-point might be easier and then, a few years down the road, you will realize it wasn’t the best choice and you should redo everything. Sad, but probably no one should be blamed, that’s life.