Kontakt

Ansicht
Dokumentation

ABENBDL_VALIDATIONS - BDL VALIDATIONS

ABENBDL_VALIDATIONS - BDL VALIDATIONS

Fill RESBD Structure from EBP Component Structure   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

- validation

validation ValName on save { CUD1; CUD2; ... }
                         $| { field Field1, Field2, ... ; }

Effect

Checks the consistency of RAP business object instances based on trigger conditions. A validation is automatically invoked by the RAP framework if the trigger condition of the validation is fulfilled. Trigger conditions can be modify operations (create, update, delete) CUD1; CUD2; ..., or modified fields Field1; Field2; .... Validations are always invoked during the save sequence at the end of a transaction and this is indicated by the mandatory addition on save. An invoked validation can reject inconsistent instance data from being saved and return messages to the consumer. Validations must be implemented in the RAP handler method FOR VALIDATE in the local ABAP behavior pool (ABP).

Trigger Conditions

There can be one or more trigger conditions. The trigger conditions can be changes of field values or the execution of one of the standard operations create, update, or delete. When one of these operations is executed for a draft instance or for an active instance, validations with the respective trigger operations are triggered. Multiple trigger conditions can be combined.

  • create: validation is executed when an instance is created.
  • update: validation is executed when an instance is updated.
Update works only in combination with the trigger operation create.
  • delete: validation is executed when an instance is deleted.
  • field: validation is executed when the value of the specified field(s) Field1, Field2, ... are changed by a create or update operation. The fields that are used for the trigger conditions must belong to the same entity the validation is assigned to.

Validation Fails, Reactions

If a validation fails for a certain entity instance, the following reactions occur:

  • The operation fails and the complete content of the transactional buffer of the current RAP LUW is rejected. A RAP LUW is committed to the database only if all data changes are consistent. One inconsistency leads to a rejection of all the content in the transactional buffer.
  • no further data changes are possible as long as the invalid instances aren't corrected. An invalid entity instance must either be corrected using an update operation, or the transactional buffer must be cleared using the EML statement ROLLBACK ENTITIES. The reason for this is that the COMMIT ENTITIES statement aborts the save sequence in case of invalid instances and the transactional buffer is not emptied.

Availability

Not available for unmanaged, non-draft RAP BOs.

Development guide for the ABAP RESTful Application Programming Model, section about Validations.

Notes

  • The execution order of validations is not fixed. If there is more than one validation triggered by the same condition, the execution order is not predictable.
  • It is not allowed to use EML MODIFY statements in the implementation of validations.

Example

The following example shows a managed BDEF that defines the validation ValidateBuyerId.

The validation is implemented in the ABAP behavior pool. It checks if the buyer ID specified in a sales order is valid by checking whether this buyer ID exists in the database table that lists all business partners. It is triggered as soon as the field BuyerId is changed. If the buyer ID is not valid, the data changes are rejected and An error message is returned.

EML access 1: valid instances are committed to the database, for invalid instances, an error message is returned.

The program DEMO_CDS_VALIDATION accesses the business object using EML. It creates three BO instances - one of them is valid, two are invalid. The valid entity instance is committed to the database, while for the invalid instances, error messages are returned. The valid entity instance is created in a different RAP LUW than the invalid ones. If all three entity instances were created in one RAP LUW - in this case, with the same COMMIT ENTITIES statement - all three of them would be rejected.

Result: valid instances are committed to the database, for invalid instances, an error message is returned.

IMAGE @@ABDOC_VALIDATION.png@@443@@240@@

EML access 2: if a RAP LUW contains only one inconsistent instance, the complete content of the transactional buffer is rejected.

The program DEMO_CDS_VALIDATION_1 demonstrates that validations accept or reject data changes per RAP LUW. It creates the same three BO instances as the report DEMO_CDS_VALIDATION, one of them valid, the other two invalid.

Code snippet:

Since this RAP LUW contains two inconsistent instances, all data changes are rejected, even the valid instance.

Result: The valid instance is not committed to the database.

IMAGE @@ABDOC_VALIDATION_FAILED.png@@427@@110@@

EML access 3: if an invalid instance is not corrected or deleted proactively, No further data changes are possible.

The program DEMO_CDS_VALIDATION_2 demonstrates how an invalid instance blocks further changes:

  • it creates one valid instance and commits it to the database.
  • it tries to create an invalid instance. This is rejected by the validation.
  • it tries to create another valid instance. This is rejected. It is required to first correct or delete the invalid instance.

Code snippet:

Result: only the first valid instance is committed to the database. The second valid instance is blocked.

IMAGE @@ABDOC_VALIDATION_FAILED_1.png@@330@@104@@

The example above is explained in detail in the executable example CDS BDL - validation.






Vendor Master (General Section)   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Length: 10090 Date: 20240426 Time: 233946     sap01-206 ( 139 ms )