Have you ever needed to integrate your pride and joy, your Salesforce org, with another system? It could be either the other system calling into your org, or the org calling out to the other system. Or both.
You’ve probably tried to avoid adding Apex to your org, but you feel that integrations are one
area where it’s difficult not to resort to using code. You try to talk to an Apex developer, but they blind you with technical jargon about handler classes and http status codes. Seems familiar?
Let’s take a look at some best practices, and hopefully unpack some of the terminology along the way.
The practices we recommend include:-
When an external system makes a call into your org, your org will need to handle a number of scenarios. These include authenticating the credentials that are passed in with the call, validating that the URL that the external system has used is valid for your org, checking that any data passed in is valid, etc. Thankfully, Salesforce takes care of a lot of this.
While you might be able to configure the other system to use Salesforce’s standard APIs, the chances are that you will need to define a web service in your org that passes the data received to some Apex that will validate the data, and then perform whatever processing is required.
When your org needs to call out to an external system, there are also a number of scenarios that need to be handled. The other system may be down for maintenance, an upgrade may mean that the service you are calling no longer recognises the data that your org is sending over, the system is bogged down and takes ages to process your request and send something back to your org, etc. You get the picture.
It is important to keep a record of any attempt to call in to, or out of, your org – at a minimum, the IP address the call came from or went to, the data that was passed in, whether the data was valid, the status of the processing, the status code returned, and any data returned.
The main method of communicating between systems uses http, which has a set of status codes that can indicate whether the call was successful or not. If not, the code should give a general indication of what type of problem has occurred. In this case, a message should also be sent back giving more details of the issue.
We recommend keeping a record of both successful calls and failures. The successful calls will help you to make sure you keep within your daily incoming API call limit for your org. The failed calls will help you identify trends in errors.
Some monitoring of these records is important. You may have someone who checks this for new failure records regularly, or have someone notified automatically.
The status code returned from a call out to another system can be used to determine whether any follow-up action needs to be taken if a call is not successful.
When calling some external systems, if a call fails, it should be tried again. For other systems, it may not be necessary to do so.
The business needs to decide for each type of integration whether any failed call-outs should be retried. If so, should it be a person who clicks a button to make the call out again, or should the system do that automatically? How soon should the next attempt be made, and how many attempts should be made before concluding that the call is not going to succeed just now?
If you want this automated, then this will require some Apex to run a scheduled job to check for unsuccessful calls, determine which ones are due to be retried and make the call again. This is where keeping records of the calls really pays.
If there is an error in the processing of an outgoing call, and the call log record includes whether the failure occurred when actually making the call, or in dealing with the response, then when you come to retry the processing, the code will know whether to make the call again, or just pick up the processing of the response from the first time around.
Some of your calls out to external systems may need to be performed at regular times each day, week or month. This processing can be set up in Salesforce by creating scheduled jobs to run the relevant Apex code. However, sometimes you may want to make a callout when a record is updated.
As Salesforce can’t predict how quickly an external system will respond to a call, it doesn’t allow call-outs to be made as part of the processing of a record update. However, you can schedule a job to run the Apex to perform the callout immediately after the record update has completed. In most cases, this shouldn’t make any difference, but if you want to give feedback to the user on the result of the callout, this can make things a bit more complicated.
You will want to thoroughly test your integration, and do it at different levels.
With Apex, you must create tests that check that the code does what you want it to do. These tests are run as part of the deployment process when you deploy a change set containing the Apex code to your production org. They can also be run manually at any time. It is good practice to run your Apex tests regularly to check that no other change in your org has impacted the processing that the Apex performs.
The Apex tests can simulate different responses to a call out without actually invoking the external system. This means that you can be confident that the Apex code can handle all of the various scenarios that you need it to.
For incoming calls, Salesforce receives the data being sent and passes it to the Apex code that has been configured to handle the request. Because Salesforce handles all of the plumbing, that means the Apex tests just have to focus on the functional logic of the integration.
To summarise, when it comes to integrations, having a brief understanding of Apex terminology, being prepared for call-out scenarios, keeping a record of call successes and failures, knowing when to make call-outs and testing, will in theory set up up for integration success.
If you would like to hear more about Salesforce Integrations, please get in touch with us here.
Photo by Ashkan Forouzani on Unsplash
Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.
