

Its software is cloud-based, which is why an expert IT team isn't needed to configure or manage it. Salesforce is the number one CRM platform in the world. In conclusion, you should study your concrete business case in order to decide whether to use Lightning Connect, REST callouts or copy your data into Salesforce.These are the different Salesforce integration options available to you (REST API, SOAP API, and Heroku Connect) In some cases you might consider the option of importing your data to Salesforce, and compare the pricing of Lightning Connect vs the pricing of storing the copied data, but bear in mind that if your external data changes, or if it has to be refreshed, for example, because new records are created in Salesforce, you will need some kind of synchronization between Salesforce and the external system, with the problems that this can entail. You don’t need synchronization: you don’t need to perform any synchronization between your external system and Salesforce, as data lives in your external system!.You don’t need storage: data is accessed in real-time from your external system, so, no storage is needed in Salesforce at all.Indeed in the application I developed for learning Lightning Connect I use two visualforce pages for showing data from the external system, so, using REST callouts would have been a good option for me!Īnd, instead of querying my external system with Lightning Connect, what about importing the external data into custom objects in Salesforce? If you use Lightning Connect: Obviously, if your business requirements don’t need any of these Salesforce capabilities, going for REST callouts can be the option for you. If you use a no high-volume external datasource, you can even enable Chatter feeds on External Object pages or navigate them in Salesforce1.Field Level Security is also available for them.Salesforce SOAP and REST APIs are available for external objects.

SFDC SOAP VS REST CODE
The changes I have made in the application code for doing the measurements can be seen in this commit. So, probably, the extra time taken by the no high-volume case is the time invested in creating this virtual Id an storying it in a table. As I spotted in my post about high-volume datasources, in a no high-volume datasource Salesforce assigns an Id over the scenes to each one of the external objects you access in the system (it stores an equivalence between the real ExternalIds of the objects and the “virtual” Ids it had assigned to them somehow). We can see as well that using a high volume external datasource gives better results than using a non-high volume one. This result makes sense, as there is an extra processing that the custom adapter code has to do to convert the SOQL query in a callout before performing the Http request. These are the results I have obtained for ten different loads of the same data (a list of nearby restaurants) in the three different cases I have described:Īs you can see, using a Lightning Connect custom adapter implies an overhead over using REST callouts in all the cases. This is, I will determine the average cost of each of the options calculating the ( total time – network time). I have measured the network time in order to be able of discriminating possible delays of my network connection. Network time: time since the Http request is performed until the Http response is deserialised into a list of restaurants, which is the same piece of code in the three cases.Total time: time since the restaurant service class performs either the callout or the SOQL query requests until the list of restaurants is returned to it.If you don’t know the differences between a high-volume and a no high-volume external datasource, you can take a look at this post.Ĭoncretely, for each of the scenarios I have measured:

The investigation has consisted of performing a set of measures using three different scenarios: REST Callouts, Lightning Connect custom adapter with high-volume external datasource and Lightning Connect custom adapter with no high-volume external datasource. There was still another question in the session that encouraged me to perform an investigation on the differences in performance of using a Lightning Connect custom adapter vs implementing the same behaviour through REST callouts.
SFDC SOAP VS REST HOW TO
Some weeks ago, in this post, I tried to solve one of the questions that was asked to me in London’s Calling presentation about how to unit test Lightning Connect apps.
