Top 7 Things To Know About Validation

• Mendix

January 20, 2016

In my previous blog, I gave a few reasons to consider building validation by design. Before diving into available technology and tools, next articles will cover top 7 things to know about validation, regardless of how validation is implemented.

Scope

The starting point of validation is a business rule defined over one or more business objects. From technical point of view a business object is realized as one or more Mendix entities (a.k.a. information objects) that are also enriched with attributes. Therefore, when developing a validation rule, one of the most apparent technical properties is that the rule may require single or multiple values as input. The first case is the most simple as input value typically comes from an attribute of a single entity. In the second case, the values may belong to attributes of the same or different objects (records in database terms). It is important to emphasize that objects may be instances of the same or different entities.

It follows that a validation is intra-object if it uses one or more attributes that belong to the same object.

Figure 1: Validate that attribute “Remark” is provided if needed, given the reason of the cancellation message.

In the above example, a validation rule checks if value of attribute Remark is sufficient given the value of another attribute Reason. The validation only fails if Remark is empty and the selected reason is “Other”. Both attributes Remark and Reason belong to the same object of entity Cancellation.

Figure 2: Validate status of the current reminder based on status of the previous reminder

In contrast, inter-object validation requires access to attributes of multiple objects. Objects can be of the same entity or of different entities. Validation may need to access attributes of objects, or simply establish if one or more object exist.

The above figure shows a validation rule that checks the status value of the current reminder object, given the status of the previous object. Validation succeeds if the last status was “Initial” and current one is “_Final”. In all other cases the validation fails. The two inputs of the rule are provided by attributes from two different objects of the same entity Reminder.

Composability

Within an application, validation can be used in different places, typically when interacting with users or systems and managing objects. Depending on usage, not all, but selected validation rules may be needed. Naturally it would be the best to select and re-use available rules with minimum effort.

A highly composable validation system allows any of its components to be selected and re-assembled in various combinations to satisfy specific needs.

A single validation that is not composed of any other validation is known as atomic. On the other hand, a validation that is composed of two or more validations (not per se atomic ones) is sometimes called compound validation.

Figure 3: A compound validation

The above figure illustrates a compound validation, consisting out of two atomic rules, each performing a simple validation on an attachment object. If needed, the assembly of the contained validations can be easily modified.

Technical/Business

It is useful to distinguish validations that are common across all business data. These are related to basic data types, such as strings, integers, currency, etc… and are known as technical validations. They are found basically in all data persistence services (i.e. databases). By its generic nature, a technical validation usually is atomic and has a scope of a single attribute within an object.

While extremely useful, technical validation is not sufficient to cover all needs for correct business data. The rest, also known as business validation, is shaped by needs of a specific business.

A simple example is age of an adult allowed to drive. While basic type for age is integer, the minimum age in the Netherlands is 17 years and depending on application domain, maximum age might be desirable too.

Note that term business does not per ce refers to vertical domains such as banking, finance or insurance. A business can also belong to a horizontal domain, such as Java. An example of application for Java domain is a software factory.

To Be Continued…

In the next article I will continue exploring the domain of validation. Feel free to send your comments to info@pinkelephant.co.uk.

Article by Andriy Levytskyy, BPM Consultant at Pink Elephant Netherlands.