Mule 4 Custom Policy Workflow

Custom Policies are policies that anyone can develop and apply to their APIs, with the intention of extending existing functionality or defining new ones.

The current workflow to get a working policy for Mule 4 that can be applied in Anypoint Platform consists of:

Develop the policy.
Package the policy.
Upload the resulting policy assets to Exchange.
Apply the policy to any API through API Manager.

Setting up a project with the archetype

The first step to develop a custom policy consists in setting up a project with the required files.
The easiest way to gather all your required files is by using the maven archetype. This archetype creates all the necessary files for you. Then, use Maven to package your custom policy into a deployable JAR.

The Maven archetype is not currently available in a Maven Central Repository, so you need to configure your Maven settings to find the archetype in one of MuleSoft’s repositories.

One way to do so is by configuring Maven’s settings.xml with the following section:

 <profiles>
   <profile>
     <id>archetype-repository</id>
     <repositories>
       <repository>
         <id>archetype</id>
         <name>Mule Repository</name>
         <url>https://repository.mulesoft.org/nexus/content/repositories/public</url>
         <releases>
           <enabled>true</enabled>
           <checksumPolicy>fail</checksumPolicy>
         </releases>
         <snapshots>
           <enabled>true</enabled>
           <checksumPolicy>warn</checksumPolicy>
         </snapshots>
       </repository>
     </repositories>
   </profile>
 </profiles>

Once Maven is configured:

Create a new directory where the custom policy project will live.
Go to that directory in the command line.
Execute the following command:
```
mvn -Parchetype-repository archetype:generate \
-DarchetypeGroupId=org.mule.tools \
-DarchetypeArtifactId=api-gateway-custom-policy-archetype \
-DarchetypeVersion=1.2.0 \
-DgroupId=${orgId} \
-DartifactId=${policyName} \
-Dversion=1.0.0 \
-Dpackage=mule-policy
```
Replace:
- ${orgId} with the Anypoint Platform Organization Id where the policy will be uploaded.
  - Get your organization ID from Access Management > Organization:
    
    Click the name of your organization.
    
    Copy the UUID from the browser address. For example, copy 2a4b93c3-7899-4ea7-9374-f787744d8784 from the URL.
- ${policyName} with the desired name for the custom policy.
Before finishing, Maven asks you to set up:
- policyDescription: A brief description of your policy.
- policyName: The identifier name of your policy.
  
  You can create a policy that supports encryption by passing the -DencryptionSupported=true property.
  See Custom Policy Encryption for more information.

After running the command, the project’s directory will have a structure similar to:

my-custom-policy/
├── my-custom-policy.yaml
├── mule-artifact.json
├── pom.xml
└── src
   └── main
       └── mule
           └── template.xml

Those four files are the basic ones needed for having a working policy.

pom.xml
- groupId is defined as the organization ID used with the archetype. This value must remain as it is.
- mule-policy packaging, so packager plugin can successfully build the JAR.
- distributionManagement section is defined pointing to user’s Exchange.
- mule-maven-plugin responsible of packaging the policy into a deployable jar
- maven-deploy-plugin configured to deploy both the resulting jar and the YAML when uploading the policy to Exchange
mule-artifact.json exists for the mule-maven-plugin. This is the same file you need for Mule applications.
my-custom-policy.yaml renders the policy configuration UI. If this file is not provided, the policy won’t be able to be applied through API Platform’s UI.
template.xml where the actual logic of the policy and Mule configuration that defines the policy behavior.

The archetype, by default, generates a basic policy that sets the returned HTTP Response payload to a “Hello World!” message. That is implemented with the following configuration:

XML element

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:http="http://www.mulesoft.org/schema/mule/http"
     xmlns:http-policy="http://www.mulesoft.org/schema/mule/http-policy"
     xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
              http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
              http://www.mulesoft.org/schema/mule/http-policy http://www.mulesoft.org/schema/mule/http-policy/current/mule-http-policy.xsd">

   <http-policy:proxy name="{{{policyId}}}-custom-policy"> (1)
       <http-policy:source> (2)
           <http-policy:execute-next/> (3)
           <set-payload value="Hello World!" />
       </http-policy:source>
   </http-policy:proxy>
</mule>

1	Basic structure for defining a policy. `{{{policyId}}}` refers to a HandleBars variable. HandleBars is a templating framework that allows users to create more complex policies.
2	Source refers to inbound HTTP requests. The other option is to define logic for an outbound HTTP request.
3	Explicit element which indicates that the next policy or flow should be executed. Any element placed before it will be executed before jumping to the next, and any element placed after that will be executed after returning from the next.

Now that the project is set, you can update the logic as necessary with your requirements.
The policy engine is powerful and enables you to do things like modifying HTTP requests and responses, logging, caching, throttling, and almost any other integration that you can do with the Mule runtime engine.

Mule 4 Custom Policy Workflow

Setting up a project with the archetype

See Also