Validation rules

Level 1: Type

As discussed earlier in this article, conformance to a type, be it built or custom, simple or complex, can be considered a validation rule. For example, an integer element will not accept the value "ABC".

Conformance to these types cannot be overridden.

Level 2: Entity validation rules

These rules are used to test the value of a field, usually based on an expression involving one or more other fields in the record.

They rarely used because of their limited practical uses. They cannot be overridden.

Level 3: Before processes

There are two types of before processes:

• beforeSaving: a pre-commit interception of the record for purposes of additional validation, including possible rejection, in some external process. It can also optionally alter the record before it is committed.
• beforeDeleting: a pre-deletion intercept. It can be used to prevent records from being deleted in a user-defined set of circumstances.

An MDM process, as you will recall from the Talend MDM Integration class, is not directly part of the model. However, it is associated with an MDM entity by the following naming convention: 'beforeSaving' + '_entity' or 'beforeDeleting' + '_entity'. For example: 'beforeSaving_person' for an entity named 'person'.

It will be instantiated when a record is inserted, edited, or deleted using:

• The Talend MDM Web UI
• The integration layer with components or the MDM REST API. It is not recommended, as this validation should be performed in the integration layer before it is sent to Talend MDM. A before process will not scale to the sorts of high volume scenarios typically dealt with using the integration layer. This is because a before process usually instantiates a batch Job and there is an overhead to doing this.

In summary, a before process can be used to add any validation you desire to your MDM model. However, it should only be used for the Talend MDM Web UI, and the process instantiated should be as fast and efficient to execute as possible, so as not to frustrate users.

Level 4: Integration layer

Once in the integration layer, ETL or ESB services/routes, you can perform any validation you like, and thus this is out of scope for this document.

To avoid replicating the model (level 1) and validation rules (level 2), you can leverage the MDM REST API. A record can be validated against the model without attempting to commit it by using the MDM REST API validate service.

For more information, see How to validate MDM data records against the master storage through the REST API.