When data is placed on to an Enterprise Service Bus (ESB), it really should be validated to ensure that data which is accepted is accurate and correct. This is a fairly common strategy and I’ve seen it in a number of Mule applications. The big question is – Where should this validation logic be? In a transformer? In a router? In a service?
There is no silver bullet for this but there are a few situations where one option makes more sense than another:
- What do you want to do with the message if it is invalid? There are various options available to you but which will be driven by the business needs.
- Forward the invalid message to an alternative endpoint. In this case, you need to choose which messages are invalid. This implies a filtering mechanism. Use a filter (perhaps you may need to implement your own) and use the <catch-all-strategy> to forward rejected messages to the alternative endpoint.
- Ignore invalid messages. You need to choose which messages are valid and ignore the rest. This implies a filtering mechanism too. Use a filter and don’t configure a <catch-all-strategy>
- Return invalid messages to sender. You still need to choose which messages to return. Use a service to perform the validation and output one of two things – a valid message or an error. Bounce the error off an empty service to force it to be returned to the sender. This pattern is documented here
- What do you want to do with the message if it is a valid type but is incomplete? Such a situation would occur if the objects received are of the expected type but don’t contain the right data.
- Any one of the options above are still possible.
- Add default values. This approach suggests that you want to start off with an object that will be changed to include default values. This is a transformation.
Best Practise in any integration or Service Oriented Architecture (SOA) is to cleanse the data before it gets placed on the bus – these are the different approaches you may wish to look into.