The validation module provides an easy way to verify message content matches criteria. It has advantages over filters like providing traceability through customizable exception messages and types. Validators throw ValidationExceptions by default but allow customizing the exception and message. Validators can be used via message processors or MEL functions. Common validators validate fields like emails, sizes, numbers, and check for empty or null values. The All validator allows validating multiple conditions and returning a single error with all failure descriptions.
2. The Validation module provides an easy out-of-the-box way to verify that the
content of a message in your flow matches a given set of criteria.
The Difference Between Mule's Filter Component and Validation Module
The main advantage of the Validation Module over using filters is
traceability, as filters all raise identical exceptions, making it hard for us to
know where the exception was caused. So if we have two filters in the same
flow, we cannot know which one failed and we cannot customize the
exception type. Validators, on the other hand, raise an exception with a
meaningful message attached, so we can customize the exception type.
Note: This feature is supported by the Mule run-time as of Mule ESB 3.7.0
in both Community and Enterprise editions.
9/3/2017 Ankit Lawaniya 2
3. The validations module was designed following these principles:
 If the message doesn’t meet the specified criteria, the validation fails
and a ValidationException is thrown.
 By default, this exception has a meaningful message attached. You
can optionally customize this message and change the type of
exception thrown, as long as the new exception type has a constructor
that overrides Exception(String).
 In case you want to throw an Exception type that lacks this
constructor, or in which its creation is not trivial, or in which you
want it to contain additional information
9/3/2017 Ankit Lawaniya 3
4.  There are two ways of using a validator: through a Message Processor, or
through a MEL function.
9/3/2017 Ankit Lawaniya 4
5. Below is not the complete list of Validators; please refer to the
MuleSoft article on Validation components for the complete list.
 Email Address Validator
<validation:is-email email=”#[json:email]” />
 Not Empty check Validator
<validation:is-not-empty value=”#[json:employeeId]”
message=”Employee Id is mandatory to supply” />
 Size Validator
<validation:validate-size value=”#[json:age]” min=”2″ max=”3″
message=”Please provide correct age” />
 Not Null Validator
<validation:not-null expression=”#[value]” value=”#[payload]” />
 Number Validator
<validation:is-number value=”#[json:Id]” numberType=”INTEGER”
message=”ID can not be String or any other data Type” />
9/3/2017 Ankit Lawaniya 5
6. There are scenarios in which you may want to evaluate several conditions,
out of which more than one could fail simultaneously. In these cases, it’s ideal
to generate a single error that contains all of the descriptions.
The solution is the All Validator.
Let’s walk through how to use All Validator in a Mule application. In this
example, we are receiving the JSON Request through an HTTP call from the
REST client, which will be validated against the ALL Validator Component.
9/3/2017 Ankit Lawaniya 6
13. Below is the exception thrown for the validation failure:
Root Exception stack trace:
org.mule.extension.validation.api.MultipleValidationException: ID
can not be String data Type
Name can not contain Integer value and other special charectors
Please provide correct age
ankit.lawaniyalive.com is not a valid email address
at
org.mule.extension.validation.internal.ValidationStrategies.all(Vali
dationStrategies.java:71)
9/3/2017 Ankit Lawaniya 13
