Content based routing is where the message routing endpoint is determined by the contents of the message at runtime. Instead of using an Azure Logic App workflow to determine where route the message, I decided to use Azure APIM and a custom policy. The main objective of using an APIM policy was to allow me to add or update the routing information through configuration rather than code and to add a proxy API for each of the providers API endpoints.
Below is the high level design of the solution based on Azure APIM and custom policies. Here the backend ERP system sends a generic PO message to the PO Routing API which will then forward the message onto the suppliers proxy API based on the SupplierId contained in the message. The proxy API will then transform the generic PO to the correct format before being sent to the supplier’s API.
The main component of this solution is the internal routing API that accepts the PO message and uses a custom APIM Policy to read the SupplierId attribute in the message. The outbound URL of this API is then set to the internal supplier proxy API by using a lookup list to find the matching reroute URL for the SupplierId. This lookup list is a JSON array stored as a Name-Value pair in APIM. This allows us to add or update the routing information through configuration rather than code.
Here is the structure of the URL lookup list which is an array of JSON objects stored as a Name-value pair in APIM.
[
{
"Name": "Supplier A",
"SupplierId": "AB123",
"Url": https://myapim.azure-api.net/dev/purchaseorder/suppliera
},
{
"Name": "Supplier B",
"SupplierId": "XYZ111",
"Url": https://myapim.azure-api.net/dev/purchaseorder/supplierb
},
{
"Name": "SupplierC",
"SupplierId": "WAK345",
"Url": https://myapim.azure-api.net/dev/purchaseorder/supplierc
}
]PO Routing API
The code below is the custom policy for the PO Routing API. This loads the above JSON URL Lookup list into a variable called “POList”. The PO request body is then loaded into a JObject type and the SupplierId attribute value found. Here you can use more complex queries if the required routing values are scattered within the message.
Next the URL Lookup list is converted into a JArray type and then searched for the matching SupplierId which was found in the request message. The variable “ContentBasedUrl” is then set to the URL attribute of the redirection object. If no errors are found then the backend url is set to the internal supplier’s proxy API and the PO message forwarded on.
// Get the URL Lookup list from the Name-value pair in APIM
<set-variable name="POList" value="{{dev-posuppliers-lookup}}" />
<set-variable name="ContentBasedUrl" value="@{
JObject body = context.Request.Body.As<JObject>(true);
// Create an JSON object collection
try
{
// Get the AccountId from the inbound PO message
var supplierId = body["Purchase"]?["SupplierId"];
var jsonList = JArray.Parse((string)context.Variables.GetValueOrDefault<string>("POList"));
// Find the AccountId in the json array
var arr = jsonList.Where(m => m["SupplierId"].Value<string>() == (string)supplierId);
if(arr.Count() == 0 )
{
return "ERROR - No matching account found for :- " + supplierId;
}
var url = ((JObject)arr.First())["Url"];
if( url == null )
{
return "ERROR - Cannot find key 'Url'";
}
return url.ToString();
}
catch( Exception ex)
{
return "ERROR - Invalid message received.";
}
}" />
<choose>
<when condition="@(((string)context.Variables["ContentBasedUrl"]).StartsWith("ERROR"))">
<return-response>
<set-status code="400" />
<set-header name="X-Error-Description" exists-action="override">
<value>@((string)context.Variables["ContentBasedUrl"])</value>
</set-header>
</return-response>
</when>
</choose>
<set-backend-service base-url="@((string)context.Variables["ContentBasedUrl"])" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>Supplier Proxy API
A proxy API is created for each of the suppliers in APIM where the backend is set to the suppliers API endpoint. The proxy will typically have the following policies.
The primary purpose of this proxy API is to map the generic PO message to the required suppliers format and to manage any authentication requirements. See my other blog about using a mapping function within a policy https://connectedcircuits.blog/2019/08/29/using-an-azure-apim-scatter-gather-policy-with-a-mapping-function/ There is no reason why you cannot use any other mapping process in this section.
The map in the Outbound section of the policy takes the response message from the Suppliers API and maps it to the generic PO response message which is then passed back to the PO Routing API and then finally to the ERP system as the response message.
Also by adding a proxy for each of the supplier’s API provides decoupling from the main PO Routing API, allowing us to test the suppliers API directly using the proxy.
The last step is to add all these API’s to a new Product in APIM so the subscription key can be shared and passed down from the Routing API to the supplier’s proxy APIs.
Enjoy…
