Migrating API Policies
In Mule 4, policies underwent major changes. A full explanation of them is available in Custom Policy General Reference (Nov 2017)
In 3.x, the logic inside a particular policy is split in two blocks, one that is executed before the next policy or flow, the other executed after it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 <?xml version="1.0" encoding="UTF-8"?> <policy online="false" xmlns="http://www.mulesoft.org/schema/mule/policy" xmlns:mule="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:api-platform-gw="http://www.mulesoft.org/schema/mule/api-platform-gw" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/policy http://www.mulesoft.org/schema/mule/policy/current/mule-policy.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/api-platform-gw http://www.mulesoft.org/schema/mule/api-platform-gw/current/mule-api-platform-gw.xsd"> <before> <mule:set-payload value="(pre)"/> </before> <after> <mule:set-payload value="(post)"/> </after> <pointcut> <api-platform-gw:api-pointcut apiName="sampleApi" apiVersion="1.0.0"/> </pointcut> </policy>
In Mule 4, policies are no longer separated in a
after block. They now work as a flow with an explicit jump to the next policy or flow that has to be defined in it.
Same behavior can be achieved in Mule 4 with the following config:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:http-policy="http://www.mulesoft.org/schema/mule/http-policy" xmlns="http://www.mulesoft.org/schema/mule/core" 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-policy http://www.mulesoft.org/schema/mule/http-policy/current/mule-http-policy.xsd"> <http-policy:proxy name="policy-deployment"> <http-policy:source propagateMessageTransformations="true"> <set-payload value="(pre)"/> <http-policy:execute-next/> <set-payload value="(post)"/> </http-policy:source> </http-policy:proxy> </mule>
A few things to notice:
Logic is placed in the same block. Injecting behavior before the flow can be achieved just by putting logic before the
execute-nextelement. To injecting behavior after the flow, you put logic after that element.
propagateMessageTransformationsattribute in the
http-policy:sourceelement: Starting in Mule 4, changes to the Mule message (payload or attributes) before executing the flow are not propagated to it by default. To enable this,
propagateMessageTransformationshas to be set to
pointcutelements are no longer defined in the policy config file. Now, they are resolved by the API Gateway when policies are fetched from API Manager.
Endpoint and App
pointcut elements are no longer available, and there is no replacement to them.
In 3.x, once the policy is defined, the result is an XML file that has to be uploaded to API Manager.
In Mule 4, once the policy behavior is defined, the policy has to be packaged into a policy template JAR and uploaded to Exchange in order to make it available in API Manager.
How to create a Maven project to generate the policy template JAR is explained here: Custom Policy Development Reference (Nov 2017)
How to upload the JAR to Exchange is explained here: To Upload a Policy to Exchange (Nov 2017)
Just like before, once the policy template JAR is in Exchange, it will appear in API Manager for APIs that belong to the same organization where the JAR was uploaded.