Building an API custom policy can enhance your app’s capabilities. We walk through the four stages of custom-policy creation in this blog.
Application program interfaces (APIs) connect human needs with technology’s power. Whenever you use an app on your phone, an API carries your command to the system or server that can meet your need.
Obviously, that makes APIs extremely important. Not having an API is like not having a waiter in a restaurant who can take your order and deliver it to the kitchen. But what if you have a waiter, but the restaurant has changed its menu overnight without telling them?
That’s what can happen when apps change over time. You have to update the API that relays those messages to deliver them as efficiently, or even at all. But how can you update an API without rewriting it completely?
Fortunately, modern integration platforms like Mulesoft Anypoint have a solution. They allow application developers to meet the challenge by creating “custom policies” for APIs, without making changes to the underlying code. It’s like changing the menu without changing the process of ordering food — the waiter still writes down your order and takes it to the kitchen in the same way, you just get a different result.
Our Centric India team created a way to do this after an insurance company asked us to enhance the logging capability of an app that was already in use. Our client didn’t want to change anything else about the way the app worked. By creating a custom policy in Mulesoft, we took an existing API and made it more valuable by extending its functionality.
Creating custom API policies is a great skill to have, and you can get started by understanding the four stages of custom-policy creation:
- Develop the policy
- Package the policy
- Upload the policy to the exchange server
- Apply the policy to the API
In this blog, we will walk you through each of these stages in detail so you can begin creating custom policies, too.
1. Develop the Policy
Start by setting the project up with the required files. Mulesoft uses the Maven archetype by default to ensure you use consistent best practices.
To set up the project, add the following section in settings.xml
<profiles>
<profile>
<id>archetype-repository</id>
<repositories>
<repository>
<id>archetype</id>I
<name>Mule Repository</name>
<url>https://repository-master.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>
Then, use the “mvn archetype” below to copy the required files into the project:
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-SNAPSHOT –Dpackage=mule-policy
This command will set up the project with the required files as per the “api-gateway-custom-policy-archetype” from the repository linked to the archetype-repository in the profiles.
The Project Structure should appear as:
my-custom-policy/
├── my-custom-policy.yaml
├── mule-artifact.json
├── pom.xml
└── src
└── main
└── mule
└── template.xml
Template.xml contains the implementation of the policy using Mulesoft’s Mule XML schema language. Write your logic in this file.
My-custom-policy.yaml defines the configurable parameters of the policy. The Mulesoft Anypoint manager uses this file to render the user interface (UI) that displays the inputs for the policy. Write your configuration in this file.
Meanwhile, pom.xml defines the policy dependencies. The packaging type needs to be “Mule-policy.” Pom.xml may define any other Maven plugin that helps to manage the development lifecycle of the Maven project.
Resources files are optional files the policy may depend upon, such as the configuration and configuration properties files.
The mule-artifact.json descriptor contains information about the app, its configuration setting, the required Mule version, class loader information, and the Secure Property tags.
2. Package the Policy
Next, add the plugin below in pom.xml:
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>${mule.maven.plugin.version}</version>
<extensions>true</extensions>
</plugin>
Use “mvn clean install” to package your application and create the deployable jar file, adding the organization id in the exchange URL as shown here:
<properties>
<mule.maven.plugin.version>3.2.7</mule.maven.plugin.version>
<exchange.url>https://maven.anypoint.mulesoft.com/api/v1/organizations/{organization_id}/maven</exchange.url>
</properties>
3. Upload the Policy to Exchange
Finally, update settings.xml in your maven .m2 directory with your Exchange credentials:
Use “mvn deploy” to push the deployable jar to the Exchange. After successful deployment, the policy will be visible as an asset in Exchange.
4. Apply the Policy to the API
Apply your custom policy like any other existing policy. You can find your custom policy with your custom tag after the policy name:
Use Case: Logging Request and Response Payload
For any already deployed API, you can now log request and response payload or other parameters without changing any code, simply by applying your new custom policy to your API.
Below are the sample template.xml and my-custom-policy.yaml files for this use case:
Template.xml file:
my-custom-policy.yaml:
Conclusion
Creating a custom policy is a quick way to provide flexibility so you can meet changing business needs or app requirements. It allows you to enhance API requests and responses without making any other changes to the API’s source code. Plus, custom policies are transportable. You can reuse them for multiple APIs.
Your data and digital assets are valuable. That’s why you must integrate and expose them across your enterprise to make the most of your technology investments. Custom policies are one way to do that.
