Nav

Pointcuts Reference (Jul 2017)

A custom policy must contain a pointcut declaration. Pointcuts control the scope of a policy application and they use regular expressions to indicate what flows in the application are affected by a policy.

If you’re applying your policy to APIs that are deployed in Anypoint Platform, then set your pointcut to the default properties apiName and apiVersion. This action guarantees that your policy is applied to only the API that you’re activating the policy. This is what your pointcut should look like:


         
      
1
2
3
<pointcut>
   <api-platform-gw:api-pointcut apiName="{{ apiName }}" apiVersion="{{ apiVersionName }}"/>
</pointcut>

Setting your pointcut to a broad regular expression such as regex=”.*” may have undesirable effects.

Applying this policy to a single API through the platform, might actually affect other APIs you’re deploying as well.

If you’re using your policies in an on-site deployment, then you might want to modify the pointcut to apply your policy to multiple APIs simultaneously.

Enabling Resource Level Policies

If your API runs on Mule 3.8.4 and later, use the following code to include resource level policies:


        
     
1
2
3
4
5
6
7
8
9
10
11
12
  {{#pointcutData}}
    <pointcut>
      <api-platform-gw:api-pointcut apiName="{{apiName}}" apiVersion="{{apiVersionName}}"/>
      <resource methodRegex="{{methodRegex}}" uriTemplateRegex="{{uriTemplateRegex}}"/>
    </pointcut>
  {{/pointcutData}}

{{^pointcutData.length}}
  <pointcut>
    <api-platform-gw:api-pointcut apiName="{{apiName}}" apiVersion="{{apiVersionName}}"/>
  </pointcut>
{{/pointcutData.length}}

Also, include the following property in the YAML: resourceLevelSupported: true

Customizing a Pointcut

In a pointcut you can reference the following kinds of elements:

  • Endpoints

  • Apps

  • Resources

If several elements are specified inside a single pointcut, then they are implemented as if you were using an AND expression.


        
     
1
2
3
4
<pointcut>
   <resource uriTemplateRegex="/items/.*" />
   <resource methodRegex="GET" />
</pointcut>

If several elements are specified in separate pointcut parent elements, they are implemented as if you were using an OR expression.

Reference Apps


         
      
1
2
3
<pointcut>
   <app regex=".*" />
</pointcut>

Reference Endpoints


        
     
1
2
3
<pointcut>
   <endpoint regex=".*" />
</pointcut> 

The following example uses values from properties:


        
     
1
2
3
<pointcut>
    <endpoint regex="http://localhost:${http.port}/gateway/.*" />
</pointcut>

This example is also valid:


        
     
1
2
3
<pointcut>
   <endpoint regex="http\:\/\/localhost:${http.port}\/gateway\/.*" />
</pointcut>

For the two previous examples to work you have to define http.port when starting Mule or in your wrapper.conf file, define something like this:

wrapper.java.additional.4=-Dhttp.port=8081

If http.port is defined at application level, a parse exception occurs when you apply the policy.

Reference Resources


        
     
1
2
3
<pointcut>
   <resource methodRegex=".*" />
</pointcut>

You can reference specific methods (GET, POST, PUT, etc.).

For example: <resource methodRegex=”P.*” /> applies to all POST, PUT and PATCH methods.

Example using defaults:


        
     
1
2
3
<pointcut>
   <resource uriTemplateRegex=".*" />
</pointcut>

In this example you can specify the path from the baseUri specified on the RAML file.

Example filtering of the first level of resources:


        
     
1
2
3
<pointcut>
    <resource uriTemplateRegex="/items/.*" />
</pointcut>

You can only use the Java classes that are provided by Mule.

Although you can use any message processor that is available in Mule to build your custom policy, you can only use the Java classes that are provided by Mule. Unlike building a Mule application, you can’t define and call a custom Java class when building a custom policy, as you have no way of bundling the custom Java class with your policy.

In this topic: