際際滷

際際滷Share a Scribd company logo
Custom Policies
In Mule 4 vs Mule 3
Technical Architect, Mulesoft
Sarvesh Kotra
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
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
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
How?
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
1. Configure mavens settings.xml to use Archtype
2. Use the archetype to create a custom policy project
Prerequisites
 An XML template
It contains the implementation of the policy using Mules 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 templates 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
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
Policy A & B are applied on API with with F1
Policy execution order
YAML configuration file
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
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
https://github.com/mulesoft-catalyst/circuit-breaker-policy-mule-4
Sample files
 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
Below changes are needed for maven to upload policy to exchange
1. Settings.xml
2. Distribution management in pom.xml
Publish to Exchange
Apply
Demo
Q&A
Quiz
Go to menti.com
Code: 6561 6443
Thank You

More Related Content

Custom policies columbus ohio 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
  • 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 mavens 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 Mules 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 templates 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
  • 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
  • 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