1.0 Overview

I have searched high and low for articles that talk about applying API gateway custom policies on the on-premise Mule runtimes but could find none, and when there are articles that talk about creating custom policies, it does not demonstrate how it could be applied, and that's really frustrating. I have written this article to help developers learn how they could do this step by step.

I have created two artifacts to test the custom policy and they are (source codes to the mentioned artifact are available via the following links):

• Mule Test API — This is a test API to apply the policy against.
• API Policy XML — This is the XML policy that will be used by the built-in API gateway (in the Mule on-premise runtime) to intercept and filter request/traffic going to the Mule Test API

2.0 Creating the Mule Test API

The Mule Test API is a simple API that accepts get request to a resource called /test.

It returns the following JSON payload every time a GET request is being made to the /test resource.

It will always return the same payload unless its traffic is intercepted by the custom policy.

3.0 Creating the Custom Policy

The custom policy is a simple one, it intercepts request going to the “Test API” via the API gateway and decides if it will honor the request and pass it through. Figure 3.0a shows the policy XML that has been created for this demo. There is logically 3 sections in the file, from top to bottom as depicted by the picture is 1) the processing logic 2) the entry point and 3) the application or resource from which to apply this policy against.

Figure 3.0a

The policy simply interrogates the “kian” HTTP query parameter. If the query parameter contains the value “kian,” then the policy will allow the intercepted request to be passed onward to the “Test API,” else it will return a message “You shall not pass!” (coming from NZ, this is like a common meme we use).

4.0 Deployment and Starting the On-Prem Mule Runtime

As of this writing, you would be able to obtain a version of the Mule runtime if your organization has a CloudHub account, and you can download a version of the runtime to run on your local machine from the MuleSoft support website (depicted in Figure 4.0a).

Figure 4.0a

Once you have downloaded it, extract the zip file to your local C: drive if you are using windows (I'm using the 3.9.1 version).

You will need to build the test application by executing the mvn clean package command in the “Test API” project folder. Once that is done, go to the target folder and copy the zip file over to the apps folder (marked as 2 in Figure 4.0b).

Then place the policy XML file in the policy folder (marked as 3 in Figure 4.0b).

Figure 4.0b

Once all of this is done, you will need to start up your Mule runtime. If you have placed it in the folder structure that is similar to mine, you will need to run the following start command from the bin folder in your on-premise Mule runtime.

mule -M-Danypoint.platform.gatekeeper=disabled

Once you have executed the command, you will see Mule runtime starting up (figure 4.0c).

Figure 4.0c

Once your on-premise Mule runtime is up and running, you will see the following message in your command prompt (Figure 4.0d).

Figure 4.0d

5.0 Testing the Policy

Once your Mule runtime is up and running, it is now time to test the policy. If you use chrome browser and browse to the following URL, http://localhost:8081/api/test?kian=kian you will see the following output (Figure 5.0a).

Figure 5.0a

But if you change the value to something other than “kian” as in http://localhost:8081/api/test?kian=gandalf then you will see that the configure policy is being applied (Figure 5.0b).

Figure 5.0b

6.0 Conclusion

From this experiment, there are a few things that are being implied when it comes to Mule’s “API gateway”:

• API Gateway is built into the Mule runtime. When we start the Mule runtime, it is also implicitly starting the API Gateway.
• All request actually goes through API gateway before it reaches the Mule applications that are deployed in the app folder. If you don't put in a policy to intercept request, then all request would go through the API gateway and hit it's predestined endpoints.
• Developers could construct complex response mechanism via a Mule processor chain in the policy XML file to deal with policy violation.