Data validation is one of the most common uses of business rules. Data validation rules are usually the first rules written when getting started with InRule® because they are the easiest to comprehend and implement. And, quite frankly, they just might be the most important. None of your other rule logic is relevant if you cannot first guarantee that the data you are working with is valid and accurate.
This post will walk you through a recommended pattern for writing validation rules, as well as highlight how to push any validation exceptions back to the calling application. This second part is key because while it is important to catch problem data, it’s also necessary to surface this information back to the calling application, and ultimately the end-user, so that they can respond accordingly.
Structure your Data
Let’s use the following example where we have a data model that represents a simple Patient record. While the Patient record is the basis for the data model, you’ll want to supplement it with an additional child collection that will be used to store the validation messages.
Each validation message will minimally consist of a Level field i.e. Information, Warning, Error, and a Message field to capture the custom text as specified by the person writing the rule. Of course, you can add additional fields to provide more specificity or classification of the validation in question.
Structure your Rule Sets
For easier maintenance and isolation, separate your data validation rules into its own rule set. The implementation should follow the standard pattern of first clearing out the validation messages collection, then executing the actual validation logic, and, optionally, stopping the remaining rules from executing if validation exceptions are encountered.
Structure your Rules
Now, of course, you have options in how you want to define your validation logic – Language Rules, Decision Tables or using the built-in functions. Below is an example of a Language Rule that verifies the Patient ID field to ensure (a) it is populated and (b) it has a value in a specified range. You’ll want to branch these separate bits of logic into their own evaluations in order to then add unique validation messages that pertain to the specific exception, i.e. “Null or empty” or “Not within range.” Again, this is important because the calling application will want to display these messages back to the user, so specificity will be critical, so having one catch-all message of “Bad ID” is probably not going to fly.
Now Tell Me What Went Wrong
In a production environment, your application code can use the InRule APIs to execute your rules against a given record. You’ll notice after the call to the ApplyRules method, you can access and iterate through the collection of Validation Messages. You may want to filter by message level or some other custom field you may have included in the validation message entity or just process them all.
It’s a fairly simple pattern to implement but one that will go a long way towards providing easier maintenance of the rules and a consistent communication point between the rules and your application.
Look for future posts on InRule Patterns & Practices as we identify new ways to help our user community navigate the product and implement consistent and reliable business rule frameworks.
