Author: Jitendra Bafna
Introduction
Dedicated Load Balancer is an optional component within the Anypoint Platform and it is used to route the HTTP and HTTPS traffic to multiple applications deployed to CloudHub workers in the VPC.
To create dedicated load balancer, you must first create the Anypoint VPC which can be mapped to the multiple environments and same dedicated load balancer can be used for different environment and you can multiple DNS for same dedicated load balancer (i.e. api-dev.example.com and api-test.example.com)
Applying Mapping Rules on Dedicated Load Balancer
Mapping rules are used on dedicated load balancers to translate input URI to call applications deployed on CloudHub. A pattern is a string that defines a template for matching an input text. Whatever value is placed within curly brackets ({ }) is treated as a variable. Variable names can contain only lowercase letters (a-z) and no other characters. Variable values can contain the characters a-z0-1.&?-_, but can’t contain slashes.
Let’s consider we have 2 DNS (i.e. api-dev.example.com and api.test.example.com) setup on dedicated load balancer.
api-dev.example.com is for Dev environment whereas api-test.example.com is for Test environment.
Use Case 1:
We are receiving request on DLB https://api-dev.example.com/ecommerce/v1.0/invoice and need to redirect to http://org-ecommerce-api.cloudhub.io/v1.0/invoice (i.e. cloudhub application name will be org-ecommerce-api)
We can use the below mapping rule to achieve this.
| Input Path | Target App | Output Path | Protocol |
| /{app} | org-{app}-api | /v1.0 | http |
This above rule will be applied when requests come on DLB and route to the CloudHub application in the VPC.
https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ⇒ http://org-ecommerce-api.cloudhub.io/v1.0/invoice
But here we have some problems that on our DLB, we have setup 2 DNS one for Dev and another for Test. Now, how DLB will know this is a request needs to route to Dev or Test application because the same rule will be applied for both.
To avoid this, we will be using subdomain in the next use case.
Use Case 2:
In this case, we will be using subdomain for routing the request to the correct environment from DLB.
Our application name format must be org-app-subdomain (i.e. org-ecommerce-api-dev for dev environment and org-ecommerce-api-test for test environment) when deploying to CloudHub workers in VPC .
So, our mapping rule will look like this.
| Input Path | Target App | Output Path | Protocol |
| /{app} | org-{app}-{subdomain} | /v1.0 | http |
subdomain is variable to map any subdomain.
https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ⇒ http://org-ecommerce-api-dev.cloudhub.io/v1.0/invoice (CloudHub Dev Environment)
https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ⇒ http://org-ecommerce-api-test.cloudhub.io/v1.0/invoice (CloudHub Test Environment)
In this use case, we solve the issue of routing the request from DLB to the correct environment.
Let’s consider another scenario where you want to route the request to CloudHub on the basis of application version. We will see this in the next Use Case.
Use Case 3:
In this case, when we will deploy application to CloudHub, it will be in format org-app-subdomain-version (e.g. org-ecommerce-api-dev-v1-0 for Dev environment and org-ecommerce-api-test-v1-0 for Test environment).
Whenever we will get request on DLB, then version in url will be v1.0, v2.0 but when you deploy application on CloudHub it doesn’t allow to use “.” in application name and that is reason we are using “-” in the version of the application deploying to CloudHub.
So, our mapping rule will look like this.
| Input Path | Target App | Output Path | Protocol |
| /{app}/v{versiona}.{versionb} | org-{app}-{subdomain}-v{versiona}-{versionb} | /v1.0 | http |
https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ⇒ http://org-ecommerce-api-dev-v1-0.cloudhub.io/v1.0/invoice (CloudHub Dev Environment)
https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ⇒ http://org-ecommerce-api-test-v1-0.cloudhub.io/v1.0/invoice (CloudHub Test Environment)
DLB will apply the first matching rule regardless of more exact matching rules available. A rule defined first, at index 0has higher priority against other rules defined after it. The higher the index assigned, the less priority the mapping rule has.
This is how you can apply mapping rules on MuleSoft dedicated load balancer.