User Guide : Best Practices : Common Integration Techniques : Data Validation
 
Share this page                  
Data Validation
You can improve the overall quality of your data by adding a few relatively easy to implement business rules. These are perfect examples of the kinds of things that must be done as user-defined functions are stored in Script Library files.
Zip codes, emails, mailing addresses, and names are a few examples of the type of data often stored in standardized formats. You can conform to these standards and conventions using the rich library of string, substitute, parsing, and other available functions.
You can use Regular Expression syntax as provided in the previous zip code validation example to build a collection of your own powerful and reusable validation rules. For more details, see Regular Expressions.
Lookups can also be used for data validation when you have to compare a value in the source data with an external source. For example, code tables. You can also make calls to third-party web service APIs or external code objects to perform validation rules.
Event Condition Action rules
To save unnecessary processing time, you must run validation rules before performing transformation operations. You can leverage the Event Condition Action rule builder to effectively use the processing engine. The conditional rule can be used to directly process the incoming record to a different target with a different set of field mappings.
For example, calling the user-defined function shows how to use the Condition Expression to validate zip codes. If the expression resolves to True, then the OutputRecord action is called and the field mappings for Target 1 are used.
If the expression resolves to False, then the Reject action is called. You can use the Reason Code parameter to assign an integer value as a code for the reject for subsequent use.
By calling the Reject action, you have triggered an event named, RecordRejected. This event can then be used to perform the OutputRecord operation using a different set of target field expressions by associating it with a different target connection and schema.
This is one example of effectively using the Event Condition Action rules to perform data validation and reject source data that otherwise requires some remediation. In this case, a literal string is hard-coded in the target field expression to indicate the problem but you can use any pre-defined function, script, or external code to fix the problem in an automated fashion.
The Event Condition Action rules gives flexibility to perform actions such as how and when you need based on your use case. You can also create your own UserDefinedEvent to trigger an operation using any business logic for which you have requirements. For more details, see Configuring Map Events.