Here at Synaptic AP, we LOVE Salesforce® data integrations. And yes, we know that makes us look like complete nerds. We just can’t help it. In this post, we share with you some cool things we have learned, as well as tell you about some new Salesforce® features that could make your upcoming Salesforce® data integration a little easier.
Named Credentials Rock
Named Credentials, which were introduced in Spring ’15, allow you to simplify the code needed to make callouts to external systems. When you set one up, you specify all the required authentication parameters and then all your code has to do is reference the name of the named credential. This is especially helpful when you are dealing with oAuth connections, which are much trickier to authenticate.
For example, consider the scenario where I am trying to make a callout to another Salesforce® org using oAuth. Prior to Named Credentials, I would need to create a remote site setting and then specify all the authentication details in the actual code. This could have amounted to as much as 50 lines of code. With a named credential (see image below) I only need to define the credential, along with a Connected App and Authorization Provider. I can initiate the callout with only 5 lines of code. Not only is it less lines of code, but this is a much more secure solution.
Consider Going Asynchronous With Queueable Apex
When you make a callout to an external service, by default the method you use must wait for a response before executing any other code. As you can imagine, this can lead to all sorts of blocking problems. To avoid this, Salesforce® allows you to annotate the method with @future(callout=true) and this will allow it to run asynchronously. Your code will run on a separate thread and no blocking will occur.
Future methods are great and very easy to implement, but you should also consider using Queueable Apex, which was introduced in Winter 15. Queueable Apex has a number of benefits that make it very appealing. One is the ability to use complex objects such as sObjects or Apex objects. Future methods are limited to only primitive data types.
Queueable Apex combines some of the best features of Batch Apex with future methods. In some cases, it can perform faster than a future method and it offers the ability to chain jobs. This means you can add a job to the queue and then when it completes add another one.
However, we caution you if choosing to chain your queueable jobs. It is possible for you to get into a scenario where you are adding jobs to the queue faster than you can cancel them. This can potentially put your org into a sort of endless loop. To avoid this, consider using a toggleable switch in the form of a custom setting that can be used to halt processing if necessary.
Rest is Best
If you are just beginning your integration and find yourself considering whether to use SOAP or REST for your callouts, we suggest you go with REST. When combined with JSON, REST is much simpler to use and the best part is that it is usually always faster than using SOAP.
SOAP, which is XML-based is good for applications that require a formal contract and in some cases you may not have a choice in whether to use it. But if you do have a choice, then consider REST. REST uses a stateless architecture, which makes it very efficient and reads can be cached for even better performance.
Don’t Forget about Outbound Messaging
A huge advantage to using the Salesforce® platform is the fact that so much can be done declaratively. Outbound messaging has been around for a long time, but it is often overlooked when doing integrations. Combined with a workflow rule, it can be used to send messages to external web services when records are created or updated.
If you don’t have the resources to deal with a lot of code and your integration scenario is pretty simple, Outbound Messaging can be a good way to go.