Last Updated on 30/05/2021 by Patryk Bandurski
Last time I described connectivity scenario when Salesforce was reaching MuleSoft API exposed via Shared Load Balancer. What do we need to take into consideration when we slightly change our infrastructure and purchase a Dedicated Load Balancer? There are some vital changes that we should be aware of. In this article, I point out at every aspect that you should know so that Salesforce won’t have any difficulties with consuming our APIS. Let’s get started.
Architecture
Let start with the architecture from a high-level perspective. As you can see, down below, we are exposing our API via DLB. Only HTTPS incoming traffic is allowed. Next, the DLB is translating the URI based on the mapping rules to the appropriate Mule XAPI application.
Below you can see agreed URIs to MuleSoft applications deployed on CloudHub. I have two domains for production usage and one for test purposes. The first two addresses are using my own subdomain. How to setup Dedicated Load Balancer to use your domains – read this article. For testing purposes, as you can see I do not use my subdomain. In other words, I stick with the original domain of DLB. You can recognize this by *.anypointdns.net domain
From this perspective, all should work well. Let’s implement this.
Anypoint Platform setup
I need to create two dedicated load balancers. One for production and the second one for non-production usage. For the DLB I can assign as many domains as I like. As a result, to the production DLB, I attach certificates api.patryk.bandurski.com and api.warsaw-group.com. Non-production DLB will have, for now, a self-signed certificate as I can’t purchase a certificate for the domain anypointdns.net.
In the diagram above, you can see the expected certificate installation. Why *.anypointdns.net is included? Although I have defined my subdomains, I can still access DLB via its original URI. I marked this using red color as all in all it won’t be signed by a valid CA.
Salesforce
Registering remote site
Salesforce can call APIs that have the domain registered in remote site settings. There is a major difference between the URI structure used by SLB and DLB. Below you can see two address bars. The first one is for DLB the second one SLB. Using Shared Load Balancer you have the name of the API put as a subdomain. Whereas DLB uses anypointdns.net domain or your own. The rest is put in the path. DLB has routing capabilities that can be based on the input pattern, and then delegate calls to appropriate MuleSoft applications. This can be achieved by using Mapping Rules.
Usage of DLB has one major adventage. We can register only one site. In my case it is https://api-pb.lb.anypointdns.net for test environment.
Test environment
Connectivity test
We can either write simple APEX on the developer console that makes a call to our service or ask Salesforce Developer to do so. Sample code you can find on my GitHub 
here. Okay so what happens when Salesforce try GET https://api-pb.lb.anypointdns.net/exchange-portal/api/v1/exchange-rates?
Oh noes! It doesn’t work. Call MuleSoft specialist we have a serious issue
SSL certificates in Salesforce
According to the Salesforce documentation when calling external service over HTTPS, Salesforce will trust only the host signed by Certification Authority (CA). What is more, the CA must be one of the accepted ones. The full list, accepted by SFDC, is here.
What that this implies? Production architecture should work fine, as APIs will be published under my own domain. I did not plan to expose my test APIs under own domain. In order to remove the obstacle, I need to do this. Below is the target Anypoint Platform configuration.
Target AP configuration
For non-production DLB I have installed test.ambassadorpatryk.com CA-signed certificate. From now on, Salesforce should call https://test.ambassadorpatryk.com URI.
Below, are depicted target URI for production and test environment. As you can see all the URI are under my own subdomains with CA-signed certificates.
Summary
As you can see, something that should work may don’t work as you expect. In this case, Salesforce, the consumer of the APIs, has its requirements on the calling 3rd party service. First, the MuleSoft experience API must be in registered remote sites and must present itself with a valid CA-signed certificate from one of the accepted CA Authorities.
I hope that the presented case can help you with deciding on your target architecture and assumption that can boost your project and reach the goal … customer success.