Disable Outbound Policies

In Mule 4, you can apply policies to both outgoing and incoming HTTP requests.

Policies applied to outgoing HTTP requests are known as outbound policies. You implement them by defining an http-policy:operation block in the policy template, specifying the execution components.

Mule runtime engine then applies the operation block of every policy that is applied to an API to every HTTP requester element defined in a Mule application.

In the case of the HTTP proxy, there is only one HTTP Requester defined to which an outbound policy is applied.

Because Mule applications that implement APIs might invoke several external services, you can define more than one HTTP Requester for such APIs. In that case, outbound policies are applied to each one of the HTTP requests that the application performs.

The following example illustrates a Mule application flow implementing an API:

<flow name="implementation">
   <http:listener config-ref="http-config" path="api"/>

   <http:request method="GET" url="http://service-1" />
   <logger message="#[payload]" level="INFO"/>
   <http:request method="POST" url="http://service-2" />
</flow>

Every time the Mule application is invoked, two HTTP requests to external services are executed.

In this next example, a Mule policy is applied to the previous example by adding a header to the HTTP request:

<http-policy:operation>
   <http-transform:add-request-headers>
       <http-transform:headers>#[{'new-header': 'the-value'}]</http-transform:headers>
   </http-transform:add-request-headers>

   <http-policy:execute-next/>
</http-policy:operation>

Every time the Mule application is invoked, the Mule policy is executed twice: once when invoking service-1 and again when invoking service-2. Each HTTP request includes an additional header called new-header, which is added by the policy.

Now imagine a scenario in which service-1 needs the additional header for authentication, but service-2 rejects incoming requests that have unexpected headers.

In Mule 4.3.0, you can meet these requirements by specifying the annotation api-gateway:disablePolicies="true" in any of the Mule application’s HTTP requesters, resulting in the Mule policy engine not executing policies for that annotated requester.

When using the annotation api-gateway:disablePolicies="true", you must specify the following namespace in the application:

xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway"

As a result, your application flow looks like the following:

<flow name="implementation">
   <http:listener config-ref="http-config" path="api"/>

   <http:request method="GET" url="http://service-1" />
   <logger message="#[payload]" level="INFO"/>
   <http:request method="POST" url="http://service-2" api-gateway:disablePolicies="true" />
</flow>

By specifying the annotation on the HTTP requester that invokes service-2, the policy is not applied. Therefore, the additional header is not appended to that particular HTTP request.

If a Mule application with the annotation is deployed to a Mule version prior to 4.3.0, the annotation has no effect and the policies are not disabled. However, the application is still deployed.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub