MuleSoft Meetup

1. Custom Policies
In Mule 4 vs Mule 3
Technical Architect, Mulesoft
Sarvesh Kotra

2. Agenda
1. What is/Why custom policies
2. When they can be used
3. How to develop
4. How to test
5. How to publish
6. How to apply
7. Demo
8. Q&A

3. What is/Why a custom policy
1. Policies enable you to enforce regulations with no modification to the code
implementation
2. They help manage security, control traffic, and improve adaptability of your
APIs. For example, a policy can control authentication, access, allotted
consumption, and service level access (SLA).
3. Custom policies can be used to apply your specific business/technical
requirements to APIs with no modification to the code implementation.
4. Custom policies will extend the functionality of Mule application at the time of
execution.
5. These can be shared and reused

4. 1. Security - Mutual Auth policy, URL validation
2. Analytics - Custom JSON logging policy
3. Control traffic - Dedupe based on metadata
4. Transformation - Changing response (Headers/Payload)
5. Extending a default policy
When they can be used

5. How?

6. 1. Develop the policy
2. Test the policy
3. Package the policy
4. Publish policy assets to Exchange.
5. Apply the policy to any API through API Manager.
Steps

7. 1. Configure maven’s settings.xml to use Archtype
2. Use the archetype to create a custom policy project
Prerequisites

8. ● An XML template
It contains the implementation of the policy using Mule’s XML schema
language.
● A YAML file
It defines the configurable parameters of the policy. Anypoint API Manager
uses this file to render the UI to display inputs for the policy.
● The template’s pom.xml file
It defines policy dependencies. The packaging type needs to be mule-policy.
The pom.xml file may define any other Maven plugin that helps to manage the
development lifecycle of the Maven project.
● Resources
Optional files that the policy depends on, such as certificates and
configuration properties files.
● The mule-artifact.json descriptor
Understanding project structure

9. XML Template structure
Should contain http-policy:source or a
http-policy:operation element
inject instructions before an HTTP Listener event fires
executed before the start of a flow with an HTTP Listener.
trigger other policies or the application flow
executed after the flow completes

10. Policy A & B are applied on API with with F1
Policy execution order

11. YAML configuration file

12. Depending of the type of the parameter, the UI will render a different type of input such as:
○ text boxes
○ radio buttons
○ checkboxes
Some rendered elements require additional configurations. The list of elements that require additional configurations are:
○ String: Any string expected.
○ Expression: A DataWeave expression starting with #[ and finished with ] is expected.
○ Boolean: true or false.
○ Int: A number is expected.
Parameter types

13. Each policy parameter defined in a YAML Configuration file will be available as a HandleBars variable for resolving the final
policy configuration.
The primitive types can be referenced from the policy template using curly brackets: {{{myproperty}}}
https://handlebarsjs.com/
Handlebars

14. https://github.com/mulesoft-catalyst/circuit-breaker-policy-mule-4
Sample files

15. ● Place jar file in %MULE_HOME%/policies/policy-templates
● Create below JSON file and place in %MULE_HOME%/policies/offline-policies
○ Policy template information
Specify the Exchange groupId, assetId, and version of the template used to deploy the offline policy definition.
○ IDs of the APIs that the policy will be applied to
○ A list of resources that the policy will be applied to
○ Order of the policy
○ Parameters if the defined template is using handlebars variables
Test - Apply and Test in Offline mode

16. Below changes are needed for maven to upload policy to exchange
1. Settings.xml
2. Distribution management in pom.xml
Publish to Exchange

17. Apply

18. Demo

19. Q&A

20. Quiz
Go to menti.com
Code: 6561 6443

21. Thank You