---
schema_version: "1"
id: a3483611307a46ea769e74c7fea65fb636e632d618b9b0274c96091a65435072
title: Migrating Filters
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.4/migration-filters.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.4/migration-filters
source_site: docs.mulesoft.com
content_type: documentation
content_hash: c64cc086ada0d97c173e2bdf94bad00487c613b28109226c50aaf7bef7585f45
description: MuleSoft Documentation Site
release: "4.4"
latest: false
---
---
product: Mule Runtime
version: 4.4
---

# Migrating Filters

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Mule 4 does not use `filters` anymore. The functionality provided by filters in Mule 3 can be
achieved by using the [Validation Module](https://docs.mulesoft.com/validation-connector/latest/).

## Applying Filters

In Mule 3, when a message was filtered, the flow ended silently at that point.

The Validation module fails the flow when a condition is not met, which makes the migrated flow
handle the `VALIDATION` error.

The flow with the source for sending the response has to account for the `VALIDATION` error, which
you can do by setting a variable in an error handler for validation errors, for example:

Mule 4 example

```xml
<flow name="flow">
    ...
    <validation:is-true expression="#[...]"/>
    ...
    <error-handler>
        <on-error-propagate type="MULE:VALIDATION">
            <set-variable variableName="filtered" value="true"/>
        </on-error-propagate>
    </error-handler>
</flow>
```

You can then query the set variable in the source’s error response builder to send an appropriate
response to the client. For instance, the `http:listener` source might be something like this:

Mule 4 example

```xml
<flow name="flow">
    <http:listener config-ref="listenerConfig">
        <http:error-response statusCode="#[if (vars.filtered) 400 else 500]"
                             reasonPhrase="#[if (vars.filtered) 'Bad Request' else 'Internal Server Error']">
            <http:body>#[error.description]</http:body>
        </http:error-response>
    </http:listener>
    ...

    <validation:is-true expression="#[...]"/>
    <error-handler>
        <on-error-propagate type="MULE:VALIDATION">
            <set-variable variableName="filtered" value="true"/>
        </on-error-propagate>
    </error-handler>
</flow>
```

In this case, a 400 (Bad Request) code will be returned if the event is filtered.

## Migrating Custom or complex Filters

Most likely, any custom or complex/nested filters you used can be migrated to use the expression
language. The DataWeave script can be externalized to a file if the same filter needs to be in
several places.

For cases where you filter data in ways that DataWeave does not support, you should use the Java
module or the Scripting module and use custom code to perform the filtering.

## See Also

[Validation Module](https://docs.mulesoft.com/validation-connector/latest/)

[DataWeave Language](https://docs.mulesoft.com/mule-runtime/4.4/dataweave)

[Scripting Module](https://docs.mulesoft.com/scripting-module/latest/)

[Java Module](https://docs.mulesoft.com/java-module/latest/)