Many resort to the mind numbing process of uploading the custom policy to Anypoint Exchange, applying it to a running API and testing it manually. For every iteration you will then have to bump the version in your pom.xml, or possibly remove the policy from the API and then find the artifact in Anypoint Exchange to delete it and upload the same version again. Note that this only works if you delete it within 7 days.

Something that does make it a little bit easier is the fact that you can apply policies to running applications as offline policies.

Prerequisites

A (local) mule runtime engine

The runtime engine can of course run on a server but it is a bit easier to have it installed locally on your machine.

I will not go into details on how to setup a local mule runtime engine for local development purposes. There are plenty of blogs about it on the internet already.

Note that the runtime engine has to be registered with the Anypoint Runtime Manager using the amc_setup command.

An API in API Manager

This can be either a basic endpoint or a proxy endpoint, but you need to have an API set up in API Manager and get the API instance ID.

A Mule application linked to the API through the Autodiscovery

You also need a mule application running in your local runtime engine setup with autodiscovery to be connected with the managed API.

1

<api-gateway:autodiscovery apiId="19025669" ignoreBasePath="true" doc:name="API Autodiscovery" doc:id="3429b5c1-7ad2-407e-af40-e229c6630ef2" flowRef="api-main" />

Building a simple custom policy

This guide assumes that you have followed the instructions on the official documentation website and have a local director with your my-custom-policy and that you are able to build it using maven.

Applying your custom policy to your application

So it is time to look into how to apply your custom policy to your application without uploading it to Anypoint Exchange and applying it through the API Manager.

First step is to copy the policy jar file into the $MULE_HOME/policies/policy-templates.

1

cp target/my-custom-policy-1.0.0-mule-policy.jar $MULE_HOME/policies/policy-templates

Next you need to create a JSON file in $MULE_HOME/policies/offline-policies that is names the same as the policy ID, in our case my-custom-policy.json.

The template object in the JSON should contain the GAV from you policies pom.xml. And the api array is a array of API Instance IDs that the mule runtime engine should apply the policy to.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

cat << EOF > $MULE_HOME/policies/offline-policies/my-custom-policy.json
{
 "template" : {
   "groupId" : "xxxx-xxxx-xxxx-xxxxx-xxxxx",
   "assetId" : "my-custom-policy",
   "version" : "1.0.0"
 },
 "api": [
   {
     "id": "19025669"
   }
 ],
 "order": 1,
 "configuration" : {
 }
}
EOF

Once this JSON file is in place your runtime will automatically apply the policy to the APIs listed in the api array in the JSON file.

Updating the policy without restarting the mule runtime engine

You can now test your policy by calling the local API instance and see that the policy work as expected. If it doesn’t, do the changes needed to the policy project, rebuild using maven and copy an updated JAR file to $MULE_HOME/policies/policy-templates. There is no need to update the version in the project pom.xml.

1

cp target/my-custom-policy-1.0.0-mule-policy.jar $MULE_HOME/policies/policy-templates

After this you will have to remove the following directories (change the policy name and version to match yours) since the mule runtime engine keeps uses them as cache.

1
2

rm -rf $MULE_HOME/.mule/policy-templates/my-custom-policy-1.0.0
rm -rf $MULE_HOME/policies/my-custom-policy

Then touch the JSON file again to force the mule runtime engine to reapply the policy.

1

touch $MULE_HOME/policies/offline-policies/my-custom-policy.json

You should see in the console log from the mule runtime engine that the policy is reapplied and you can continue testing.