{"id":33314,"date":"2021-10-21T13:00:35","date_gmt":"2021-10-21T17:00:35","guid":{"rendered":"https:\/\/centricconsulting.com\/?p=33314"},"modified":"2022-08-05T12:47:30","modified_gmt":"2022-08-05T16:47:30","slug":"how-to-make-your-own-mulesoft-api-custom-policy","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/how-to-make-your-own-mulesoft-api-custom-policy\/","title":{"rendered":"How to Make Your Own MuleSoft API Custom Policy"},"content":{"rendered":"

Building an API custom policy can enhance your app\u2019s capabilities. We walk through the four stages of custom-policy creation in this blog.<\/h2>\n
\n

Application program interfaces (APIs) connect human needs with technology\u2019s power. Whenever you use an app on your phone, an API carries your command to the system or server that can meet your need.<\/p>\n

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?<\/p>\n

That\u2019s 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.<\/strong> But how can you update an API without rewriting it completely?<\/p>\n

Fortunately, modern integration platforms like Mulesoft Anypoint<\/a> have a solution. They allow application developers to meet the challenge by creating \u201ccustom policies\u201d for APIs, without making changes to the underlying code. It\u2019s like changing the menu without changing the process of ordering food \u2014 the waiter still writes down your order and takes it to the kitchen in the same way, you just get a different result.<\/strong><\/p>\n

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\u2019t 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.<\/p>\n

Creating custom API policies is a great skill to have, and you can get started by understanding the four stages of custom-policy creation:<\/p>\n

    \n
  1. Develop the policy<\/li>\n
  2. Package the policy<\/li>\n
  3. Upload the policy to the exchange server<\/li>\n
  4. Apply the policy to the API<\/li>\n<\/ol>\n

    In this blog, we will walk you through each of these stages in detail so you can begin creating custom policies, too.<\/strong><\/p>\n

    1. Develop the Policy<\/h2>\n

    Start by setting the project up with the required files. Mulesoft uses the Maven archetype by default to ensure you use consistent best practices.<\/p>\n

    To set up the project, add the following section in settings.xml<\/strong><\/p>\n

    <profiles><\/span><\/code><\/p>\n

    \u00a0\u00a0 <profile><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0 <id><\/span>archetype-repository<\/id><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0 <repositories><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <repository><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <id><\/span>archetype<\/id>I<\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <name><\/span>Mule Repository<\/name><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <url><\/span>https:\/\/repository-master.mulesoft.org\/nexus\/content\/repositories\/public<\/url><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <releases><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <enabled><\/span>true<\/enabled><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <checksumPolicy><\/span>fail<\/checksumPolicy><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/releases><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <snapshots><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <enabled><\/span>true<\/enabled><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <checksumPolicy><\/span>warn<\/checksumPolicy><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/snapshots><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/repository><\/span><\/code><\/p>\n

    \u00a0\u00a0\u00a0\u00a0 <\/repositories><\/span><\/code><\/p>\n

    \u00a0\u00a0 <\/profile><\/span><\/code><\/p>\n

    \u00a0<\/profiles><\/span><\/code><\/p>\n

    Then, use the \u201cmvn archetype\u201d below to copy the required files into the project:<\/p>\n

    mvn \u2013Parchetype-repository archetype:generate\u00a0 \u2013DarchetypeGroupId= org.mule.tools \u2013DarchetypeArtifactId=api-gateway-custom-policy-archetype \u2013DarchetypeVersion = 1.2.0 \u2013DgroupId\u00a0 = ${orgId} \u2013DartifactId= ${policyName} \u2013Dversion=1.0.0-SNAPSHOT \u2013Dpackage=mule-policy<\/strong><\/p>\n

    This command will set up the project with the required files as per the \u201capi-gateway-custom-policy-archetype<\/strong>\u201d from the repository linked to the archetype-repository in the profiles.<\/p>\n

    The Project Structure should appear as:<\/p>\n

    my-custom-policy\/<\/strong><\/p>\n

    \u251c\u2500\u2500 my-custom-policy.yaml<\/strong><\/p>\n

    \u251c\u2500\u2500 mule-artifact.json<\/strong><\/p>\n

    \u251c\u2500\u2500 pom.xml<\/strong><\/p>\n

    \u2514\u2500\u2500 src<\/strong><\/p>\n

    \u2514\u2500\u2500 main<\/strong><\/p>\n

    \u2514\u2500\u2500 mule<\/strong><\/p>\n

    \u2514\u2500\u2500 template.xml<\/strong><\/p>\n

    Template.xml contains the implementation of the policy using Mulesoft\u2019s Mule XML schema language. Write your logic in this file.<\/p>\n

    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.<\/strong> Write your configuration in this file.<\/p>\n

    Meanwhile, pom.xml defines the policy dependencies. The packaging type needs to be \u201cMule-policy.\u201d Pom.xml may define any other Maven plugin that helps to manage the development lifecycle of the Maven project.<\/p>\n

    Resources files are optional files the policy may depend upon, such as the configuration and configuration properties files.<\/p>\n

    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.<\/p>\n

    2. Package the Policy<\/h2>\n

    Next, add the plugin below in pom.xml:<\/p>\n

    <plugin><\/strong><\/code><\/p>\n

    <groupId>org.mule.tools.maven<\/groupId><\/strong><\/code><\/p>\n

    <artifactId>mule-maven-plugin<\/artifactId><\/strong><\/code><\/p>\n

    <version>${mule.maven.plugin.version}<\/version><\/strong><\/code><\/p>\n

    <extensions>true<\/extensions><\/strong><\/code><\/p>\n

    <\/plugin><\/strong><\/code><\/p>\n

    Use \u201cmvn clean install\u201d to package your application and create the deployable jar file, adding the organization id in the exchange URL as shown here:<\/p>\n

    <properties><\/code><\/p>\n

    <mule.maven.plugin.version>3.2.7<\/mule.maven.plugin.version><\/code><\/p>\n

    <exchange.url>https:\/\/maven.anypoint.mulesoft.com\/api\/v1\/organizations\/{organization_id}\/maven<\/exchange.url><\/code><\/p>\n

    <\/properties><\/code><\/p>\n

    3. Upload the Policy to Exchange<\/h2>\n

    Finally, update settings.xml in your maven .m2 directory with your Exchange credentials:<\/p>\n

    Use \u201cmvn deploy\u201d to push the deployable jar to the Exchange. After successful deployment, the policy will be visible as an asset in Exchange.\"Custom<\/a><\/p>\n

    4. Apply the Policy to the API<\/h2>\n

    Apply your custom policy like any other existing policy. You can find your custom policy with your custom tag after the policy name:<\/p>\n

    \"Custom<\/a><\/p>\n

    Use Case: Logging Request and Response Payload<\/p>\n

    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.<\/strong><\/p>\n

    Below are the sample template.xml and my-custom-policy.yaml files for this use case:<\/p>\n

    Template.xml file:<\/p>\n

    \"Custom<\/a><\/p>\n

    my-custom-policy.yaml:<\/p>\n

    \"Custom<\/a><\/p>\n

    Conclusion<\/h2>\n

    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\u2019s source code. Plus, custom policies are transportable. You can reuse them for multiple APIs.<\/p>\n

    Your data and digital assets are valuable. That\u2019s why you must integrate and expose them across your enterprise to make the most of your technology investments<\/a>.<\/strong> Custom policies are one way to do that.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Building an API custom policy can enhance your app\u2019s capabilities. We walk through the four stages of custom-policy creation in this blog.<\/p>\n","protected":false},"author":344,"featured_media":33320,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","footnotes":""},"categories":[1],"tags":[20817,18616],"coauthors":[22999],"acf":[],"publishpress_future_action":{"enabled":false,"date":"2024-08-02 11:43:35","action":"change-status","newStatus":"draft","terms":[],"taxonomy":"category"},"_links":{"self":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/33314"}],"collection":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/users\/344"}],"replies":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/comments?post=33314"}],"version-history":[{"count":0,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/33314\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/media\/33320"}],"wp:attachment":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/media?parent=33314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/categories?post=33314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/tags?post=33314"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/coauthors?post=33314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}