SFDC Stop - Always the latest about Salesforce


Full Tutorial Series with videos, free apps, live sessions, salesforce consulting and much more.


Telegram logo   Join our Telegram Channel

Tuesday 3 December 2019

HTTPCalloutFramework - A light weight framework for Apex HTTP Callouts

Hello Trailblazers,

I recently launched a new framework for simplifying apex HTTP callouts known as HTTPCalloutFramework. I open sourced it on GitHub and it's freely available now. In this post, I am going to talk about the functionality and advantages of this framework.

Overview

HTTPCalloutFramework helps you to simplify your apex HTTP callouts by storing all the metadata required for the callout as a record in a custom metadata named as:- HTTPCalloutConfiguration. This metadata stores the following essential information:-
  1. API Endpoint
  2. Request Method (GET/POST...)
  3. URL Parameters
  4. Header Parameters
  5. Request Body
  6. Request Timeout
This framework also includes two reusable mock classes that can be used while writing test classes for callouts:-
  1. HTTPCalloutServiceMock:- This mock class is used when there is a single callout within the code that's covered by the test method.
  2. HTTPCalloutServiceMultiMock:- This mock class is used when there are multiple callouts within the code that's covered by the test method.
These mock classes consists of constructors and methods that can be used to setup a mock response. For an example implementation you can have a look at HTTPCalloutServiceTest class that is used to cover the code in our service class.

Installation

To install this framework in your org, you need to go to the github repository here. Click on the Deploy to Salesforce button as shown below:-


As you click on that button, you'll be taken to a screen as shown below:-

Choose the correct environment and click on the Login to Salesforce button on the top right side. If you're using this tool for the first time, you'll see a screen asking for necessary permissions for deployment as below:-


Click on allow. You will see another screen as shown below:-


This screen is displaying all the metadata that will be deployed to your org. Click on the Deploy at the top right corner. Clicking on this button will deploy the framework to your org. You'll see the messages on the page on clicking deploy button as shown below:-


As you can see above, the deployment is successfully completed, in case there is an error, it'll be shown and the deployment will fail.

Congratulations..!! You have successfully installed HTTPCalloutFramework in your org

Usage

This metadata is mainly used in a service class known as HTTPCalloutService. While creating an instance of this class you can pass the developer name of custom metadata in the constructor and it will automatically fetch the data from HTTPCalloutConfiguration record and set it in the HTTP request.

Suppose, you need to add a request body yourself each time you're making a request as it's dynamic, you can do that easily by using the getter and setter methods in the service class. For ex:- For request body, we have setRequestBody() and getRequestBody() methods that can be used.

While using this framework You should only focus on the stuff that's dynamic while making a callout as the static data can be stored easily in the custom metadata and will be picked automatically by our service class.

Let's have a look at the example code and learn how by using this framework, we can reduce code. In this example, I am going to connect to another Salesforce Org - Playful Bear Org from my Salesforce Org - Curious Racoon Org and query contacts.

There are better ways to do this like:- Using named credentials etc. However, I am doing it solely by writing code for demo purposes.

So, if you want to connect to a different salesforce environment from apex you'll do something as shown below:-

As you can see above, I have simply created a wrapper for the token response in order to get the access token. The code in line no. 10 to 18 is used to hit the token URL and get the response from it. However, the code in line no. 20 to 26 is used to get the actual response by querying the contact from other org.

The other way around can be by using the HTTPCalloutFramework. Let's have a look at the below code:-

As you can see above, I can get the token very easily by using the code shown in line no. 10 to 11. I can query the contacts from other org and get the response from line no. 13 to 18. I have made two custom metadata records, one for authentication and other for querying as shown below:-



If I don't consider the wrapper, the total no. of lines of code a developer has to write without using the framework:- 16 and while using the framework its:- 8. So, we got to know that you can reduce your code to half along with the additional benefits like:- there will be minimal or no change in code in future as most of the details are stored in the custom metadata itself.

Not only this, if multiple developers are working on integrations to connect with the same systems, they can do the authentication stuff in just two lines of code which is common to all of them, there is no need to create a common method or anything like that. Also, for any change in the headers, or metadata we don't need to go to the code and change that you can simply do that in the custom metadata itself. Therefore, the advantages can be summarized as:-


  1. Lines of code are reduced.
  2. Request metadata can be updated without any change in code.
  3. Code reusability is implemented automatically.
  4. Data from static APIs can be fetched using two lines of code.
  5. Getter and setter methods make it easy for us to update the request before sending.
  6. Mock classes are available for handling single and multiple requests in the code covered by a test method while working on test classes.
  7. Named credentials support.

Even if you're using named credentials for the authentication part, it's easy to setup the request in the custom metadata. Let's have a look at the below code that's using named credentials for authentication and is making the same request:-


As you can see above, I have just given my metadata developer name in the constructor i.e. :- PlayfulBearQueryAPIWithNamedCredentials, updated the request URL with my query and displayed the response in debug. It's working fine. Now let's have a look at the custom metadata record for the same:-


You can see that I have specified the request method as GET and the request timeout in miliseconds. However, you can see that the request URL is:- http://callout:Playful_Bear_2/services/data/v47.0/query/?q=

As it's starting from callout: we got to know that it's using named credentials for authentication. The named credential record for playful bear org is given below:-


So, in this way, using both the named credentials and framework, I can even reduce my code more and perform my callouts more easily.

With this blog, I hope you got an idea of how can the HTTPCalloutFramework helps you in managing your REST callouts from Salesforce and how you can install and use it. There are two mock classes also present in the framework that I wanted to describe about but it'll be a very long post in that case. I recommend you to have a look at the test class for my service class here. In this test class, I have used both the mock classes:- HTTPCalloutServiceMock.cls and HTTPCalloutServiceMultiMock.cls for covering single and multiple callouts in the code covered by test methods. You can use these classes too while creating a test class as these are generic mocks. If you still need an example of using these mocks, let me know in the comments down below.

If you liked this framework, make sure to bookmark it on GitHub and show your support by clicking on the Star button present here. Also, share this post among your network and let me know your feedback in the comments section.

Happy Trailblazing..!!

3 comments:

  1. Rahul, wonder if you have seen this problem before. I have used your integration framework with a couple of APIs with bearer token authentication. Adding the token to the Header field of the Metadata type record worked just perfect. Now I'm developing a new api connection against an endpoint that requires two headers for authentication. I added these two in the metadata type recoed header field with the following format:

    Ocp-Apim-Subscription-Key: key
    Authorization: basic key

    I can see that the headers are being set to the request:

    |DEBUG|@@@headers from service are: {Authorization= basic key, Ocp-Apim-Subscription-Key= key)

    but when the request is sent I get the following response back:

    "Bad Request
    HTTP Error 400. The request is badly formed"


    The strange thing is if I set both headers "manually" to a HttpRequest via setHeader method the api gets successful response 200. Have you experienced any similar issue setting headers to the metadata record? Thanks a lot in advance!

    ReplyDelete
    Replies
    1. Hi,

      I haven't faced that issue before. I am wondering now why it's coming maybe it's a whitespace issue but I have removed whitespaces as well if I remember correctly. Can you join our telegram group or DM me on telegram so that we can discuss about this in detail ?

      Link:- https://t.me/sfdcstopdiscuss

      Delete