You are viewing an older version of this topic. To go to a different version, use the version menu at the upper-right. +

Studio Filters

What are Filters?

Mule Studio bundles more than a dozen Filters that determine whether a message can proceed through an application flow. The simplest filters implement basic logic operators (such as and, or, and not), but these simple elements can be combined in various ways to specify complex logical conditions.

Custom Filters

In addition to applying standard filters, you can create a custom filter to specify a precise set of conditions a message must satisfy before it can continue through the flow.

Global Filters

You can also create a global filter that specifies a set of conditions that the message must meet at points along the flow specified by the Filter Ref building block.

Bundled Filters

Filters Description Reference



The three And/Not/Or logic filters express simple logic. When required to express complex logic, these three filters can be used in combination with other filters.

Logic Filter Reference



References a user-implemented filter class.




Filters against an exception of a specified type.




Filters against a range of expressions.


Filter Ref

Filters against a range of expressions.


Idempotent Message

This filter ensures that a flow receives only unique messages.




Applies specified criteria to a message to determine whether it should be processed

Message Filter Reference


Message Property

Evaluates message properties to determine whether that message should be processed.

Message Property Filter Reference



Evaluates the payload type of a message to determine whether it should be processed.



Applies a regular expression pattern to the message payload to determine whether it should be processed.

Regex Filter Reference


Schema Validation

Uses the JAXP libraries, to validate a message against a schema.

Schema Validation Filter Reference


Wildcard Filter

Matches string messages against a wildcard pattern.

Wildcard Filter Reference

About Filter Logic

When a message fails to satisfy the conditions specified by a filter, that filter returns a null value, which causes the processing of that particular message to halt. In other words, the message is rejected and undergoes no further processing.

When a message satisfies the conditions specified by a filter, that filter passes the payload of the message to the next building block in the flow, and processing of that particular message continues.

When you place a filter immediately after an HTTP endpoint configured for a request-response pattern, and no response has been configured for the flow, Mule uses as a response the result returned by the final message processor in the flow, which is null.

Configuring Filters

This section covers only those configuration activities common to all filters. For configuration activities that apply only to individual filters, click one of the links in the Reference column of the table Bundled Filters.

As for all Studio building blocks, you configure Filters in two major steps:

  1. Drag the filter from the Palette to the Message Flow canvas, then set its position within the sequence of building blocks that make up the application flow.

  2. Provide values for the required fields on the various tabs in the filter’s Properties pane.

The Properties panes for most of the bundled filters contain only two tabs: General and Documentation. The Custom filter also includes a Spring tab (See: below, left).

To view the filter’s Properties pane, double-click the filter icon on the Message Flow Canvas, or right-click the icon, then select Properties from the context menu.


Typically, the General tab displays a Display name field which, by default, is populated with the name of the filter (such as Custom, Wildcard, or Not). Although you can accept this generic name, you have an opportunity to enter a meaningful name that appears in the Mule Management Console and also displays below the filter icon on the Message Flow canvas. This filter-specific description can prove useful when you or some other developer updates the filter settings at a later time.

The General tab typically contains additional required fields, which vary according to the type of filter you are configuring. For example, Filter Ref (See: above, left center) requires you to create a new template called a global element or to specify an existing global element from a drop-down list. The Expression filter (See: above, right center) requires you to specify an expression and Schema Validation (See: above, right) requires you to specify Schema Locations. For guidance on populating these fields, consult the Bundled Filters for the specific type of filter you are developing.

When you are satisfied with the values you have entered in the various fields of the Properties pane, click OK to commit the information.