Things to Remember When Implementing InfoSphere MDM Server Validations

Validation is an important aspect of any application or system. Validations could arise as part of functional requirements (e.g., business rules) or non-functional requirements (e.g., maintain data integrity). Data validation is a process of ensuring that a program operates on clean, correct and useful data.

In any MDM implementation, data validation plays an important role. Since MDM deals with maintaining consolidated view of entities, it is critical that the data stored is valid and meets all business rules.

IBM’s MDM Server comes with a robust and easily customizable validation framework. MDM Server validations can be broadly classified into two types: 1) External validations 2) Internal validations

First, let us talk about what are External validations

External validations are the first level of validation. The validation rules are configured in database tables, the definition metadata is retrieved at runtime by validation engines for execution.

The different Types of external validations are:

a) Fixed type data validation - The actual validation functions are written in java and the validations can be configured on Business Object level or Element level (Business object attribute). This targets data of a typed Java class. The data type is not changeable at deployment or runtime.

b) Variable type data validation – This targets data of a typed XML schema. The data type is changeable at deployment or runtime.

c) Context only validation – This does not support a group or element specification. Therefore, transaction type needs to be specified. It is expected that the validator already knows the type of data that requires validation.

MDM comes with 70+ validation functions for validating Business objects and its elements. For e.g., functions like - Mandatory, Maximum Length, Allowed Value, etc. A single validation function can be used to validate N number of attributes by linking the element and the function through database configuration. MDM also gives provision to define brand new functions of our own.

The most important tables used in configuring external validations are as below:

V_FUNCTION – holds the actual definition of the function (function name, java class name, etc).

V_ELEMENT_VAL – links the element (Business object attribute) and functions so that the element is validated upon.

V_GROUP_VAL – links the Group (Business object) and functions so that the group is validated upon.

V_ELEMENT_PARAM – parameters, if any, for element validation

V_GROUP_PARAM – parameters, if any, for group validation

EXTRULE – all validations need to refer to a rule. If the outcome of the rule is true, then the validation rules are executed, else they are skipped.

Once the external validations are defined, they can be turned ON or OFF by executing SQL statements or by using Business Admin UI client.

Internal validations

Internal validations are the second level of validation and are part of Business objects (validateAdd () and validateUpdate() methods). They can be further classified into two types a) Controller level internal validation and b) Component level internal validation.

When it comes to internal validations, the Controller level validations are executed first. If any of external validation fails, then the error messages would be returned to the caller and the execution of internal validations would be skipped. Component-level validations are second level of internal validation. They are executed only when there are no exceptions found in controller level validations.

Should we have internal validation rules at the controller level or component level?

MDM developers who are new to the platform always have this confusion. From performance point of view, it is good to do as much validation as possible at controller level, and also avoid any database calls in controller level validations. e.g., date validations, mandatory fields, non-update field checks, code table validations etc., can be placed at controller level. Please note that there can be some exceptions to this rule; for instance foreign key checks can only be validated at the component level.

All validations that involve database calls can be put under component level validation e.g., unique data check, etc.

Out of Box PartyAddress entity has validations like addressLineOne and City are mandatory, partyId must be valid, address usage type must be valid code type etc. Validations for addressLineOne, City and AddressUsageType are present as part of controller level validations, and validations for PartyId are present as party of Component level validations.

How should we decide whether to go for external or internal validations?

During MDM customizations, creating a new external validation function will definitely add more development effort compared to internal validations. So, what should be the criteria to decide whether to go for external validations or internal validations? If we answer ‘yes’ to any of the below, then we should consider using external validations:

1) If we need flexibility to turn ON or OFF certain rules, as and when required.

2) If a validation is specific to a particular source feed, the rule may apply for other feeds as well over the time. e.g., all the customers coming from “Source A” must have Phone numbers. And over the time, this rule might hold good for the source feed coming from “Source B” as well.

Let us consider an example where in we have to create new Addition – XPassportInfoBObj as part of MDM customization. Following validations need to be applied for XPassportInfoBObj:

1) Passport Number must be unique

2) Passport Number is mandatory field

3) PassportBObj need to refer to valid Person

4) Passport dates must be valid

5) External system need to be called to validate passport number. No validation rules need to be applied for passport information coming from source feed x, y, z.

So based on the above discussions

a) Validations #5 must be a part of external validations

b) Validations #2, 4 must be part of Controller level internal validations

c) Validations #1, 3 must be part of Component level internal validations

For any further queries or discussions, feel free to post comments or contact me at satish@infotrellis.com