Wednesday, June 20, 2018

Applying Custom Policies in On-prem Mule Runtime 3.9.1

1.0 Overview

I have searched high and low for articles that talks about applying api gateway custom policies on the on-prem mule runtimes, but could find none and when there are articles that talks 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 artifact 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-prem 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.
{
   "message": 
"test called"
}
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 torp 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 on ward 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 web site (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’am 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 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 form the bin folder in your on-prem 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 prem 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 it 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 is being implied when it comes to Mule’s “API gateway”:-

  1. API Gateway is built into the mule runtime, when we start the mule runtime it is also implicitly starting the API Gateway.
  2. All request actually goes through API gateway before it reaches the mule applications that is 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 predestine endpoints.
  3. Developers could construct complex response mechanism via a mule processor chain in the policy xml file to deal with policy violation.

7 comments:

  1. Policy for rate throttling https://gist.github.com/kianting/548bb861025637cd9575fa65075fe0d8

    ReplyDelete
  2. Policy for rate limiting https://gist.github.com/kianting/cb11e984a4b326829b9a3021128993c6

    ReplyDelete
  3. Hello Kian,

    Nice blog! I am editor at Java Code Geeks (www.javacodegeeks.com). We have the JCG program (see www.javacodegeeks.com/join-us/jcg/), that I think you’d be perfect for.

    If you’re interested, send me an email to eleftheria.drosopoulou@javacodegeeks.com and we can discuss further.

    Best regards,
    Eleftheria Drosopoulou

    ReplyDelete
  4. Thanks for sharing this blog.This article gives lot of information.
    Mulesoft Online Training
    Mulesoft Training in Hyderabad



    ReplyDelete
  5. I like your post very much. It is very much useful for my research. I hope you to share more info about this. Keep posting mulesoft online training

    ReplyDelete
  6. This concept is a good way to enhance the knowledge.thanks for sharing.. Great article.
    Mulesoft Training in Hyderabad
    Mulesoft Online Training

    ReplyDelete