Implementing Input Checks Using Validations

A validation is an optional part of the business object behavior that checks the consistency of business object instances based on trigger conditions. Validations, like actions, are defined in the behavior definition of the RAP BO and implemented in the behavior pool through a dedicated method of the local handler class.

A validation is implicitly invoked by the business objects framework if the trigger condition of the validation is fulfilled. Trigger conditions can be modify operations (create, update, delete) and modified fields. The trigger condition is evaluated at the trigger time, a predefined point during the BO runtime.

An invoked validation can reject inconsistent instance data from being saved by passing the keys of failed instances to the corresponding table in the FAILED structure. Also, a validation can return messages to the consumer by passing them to the corresponding table in the REPORTED structure.

Validations are defined in the entity behavior definition with the following statement: validation <validation_name> on save { <trigger_conditions> }.

It is mandatory to provide at least one trigger condition within the curly brackets.

The following trigger conditions are supported:

Create;

The validation is executed when an instance is created.

Update;

The validation is executed when an instance is updated.

Delete;

The validation is executed when an instance is deleted.

Field <field1>, <field2>, …;

The validation is executed when the value of one of the specified fields is changed by a create or update operation.

Multiple trigger conditions can be combined. The conditions are linked with OR that means at runtime it is sufficient that one of the trigger conditions is met.

The behavior definition in the example defines two validations. The first is triggered by any create or update operation. The other is triggered by any create operation or by changes to the CustomerID field.

If the behavior pool already exists when you add the validation definition, you can use a quick fix to add the missing method to the local handler class. To invoke the quick fix, the usual options are available: Choose the warning icon with light bulb, right-click the validation name and choose Quick Fix, or place the cursor on the name of the validation and press Ctrl + 1.

The implementation of a validation is contained in a local handler class as part of the behavior pool. This local class inherits from the base handler class CL_ABAP_BEHAVIOR_HANDLER.

The signature of a validation method is typed using the keyword FOR VALIDATE ON SAVE followed by the keys importing parameter. The type of the importing parameter is an internal table containing the keys of the instances that the validation is executed on.

Although not visible in the method definition, all validation handler methods have response parameters failed and reported. These parameters are deep structures and their types are derived from the definition of the related RAP BO. By adding the key values of an entity instance to the corresponding table in failed, you reject the instance data from being saved. If you reject an entity instance, it is mandatory, that you return a message to the consumer by adding the instance key and a message object to the corresponding table in the reported.