Mule soft esb – data validation best practices

2.  Validation of data in ESB application at
different layers of message processing is a
requirement which is quite frequent. Often,
the validation logic is implemented at
different layers which is time consuming and
also prone to errors. Therefore, it is
necessary to separate domain model and the
validation logic, further to it, it also has to be
aimed for reuse with the help of framework.

4. This blog post focuses to bring the goodness of JSR303 Bean
Validation model [Hibernate RI], Spring framework’s support for
custom validation and a blend on how it will work in MuleSoft ESB.
From an ESB point of view, the validation requirements are:
 Provide uniform approach to validate different type of payloads
supporting REST, SOAP, XML, Java VO and other types of
payloads
 Provide support for field level validations (example: validate
inbound message attributes)
 Provide support for custom validations (based on business logic)
 Support context specific messages for validation errors from
configuration files
 Raise validation errors for handling alternate flow of execution
 Inject validators as pluggable components in flow

5. Mule supports validations to an extent but that is
not sufficient; for example
 The validator pattern from Mule supports
validation using MEL which is barely sufficient;
forcing to write MEL for every attribute and has
no option to wire to an error code/message
 The JSON validator checks whether the input
JSON is formatted. It does not support features to
apply a constraint like checking the length of an
attribute, for null value or for an empty string,
etc.

6.  Java Bean Validation (JSR303) is a framework
as part of Java EE. The bean validation
defines meta model and API for data
validation. The implementation is done
through annotations and is extensible, which
can be reused by simply adding annotations
to the domain model.
// Example – define constraints to a bean
public class Person {
@NotNull (message=’ERR-BS-001’)
public class Person {
@NotNull (message=’ERR-BS-001’)
@Size(min=1, max=16)
private String firstName;
@NotNull (message=’ERR-BS-002’)
@Size(min=1, max=16)
private String lastName;

7. Spring framework supports JSR303 bean validations and
support for custom validation. Some of the advantages upon
using Spring Validators are mentioned below:
 Spring framework is a natural choice of Mule for DI – No
additional set-up is required
 Custom Spring Validators can be injected to a Mule ESB
flow so as to validate business logic
 Supports JSR 303 validation by making use of a reference
implementation like Hibernate Validator API or Apache
BVal API
 Link validation errors using Spring property placeholders
for error messages which are context specific

8.  A validation framework is necessary, which
binds annotation validators, custom
validators and error message handler.

9. To validate annotations, JSR303 RI is required in the
library. Hibernate Validator or Apache’s BVal can be
used to support annotation based validations.
 To validate concrete domain models, Spring
framework’s ValidationUtils class should be used
(from springframework.validation package). The
ValidationUtil’s method should invoke a custom
validator thus providing FieldErrors.
 The ExceptionFactory consolidates the FieldErrors
from different validators, fetches the attribute name
and message ID and loads the message from the
message source.
 Custom validators to the ValidationUtils should be
injected as Spring beans in Mule.
 Exception factory should use Spring’s
PropertiesFactoryBean to load error messages at
runtime.

10.  It might be possible to use annotations in
order to validate REST requests by using
@Valid annotation. Mule ESB 6.1 has
upgraded Jersey version 2.11 (RI) which
supports validation using @Valid annotation
prior to a REST method invocation (like in
Spring MVC).
// update user profile after validation
@POST
@Consumes( MediaType.APPLICATION_JSON_VALUE
)
public boolean updateProfile( @Valid UserProfile m
Profile )
//…
}