Get Example source ABAP code based on a different SAP table
• VALIDATION ON SAVE ABAP_BDL_BODY
ABAP_RAP - validation
ABAP_SYNTAX validation ValName on save { CUD1; CUD2; ... } $| { field Field1, Field2, ... ; }
What does it do? 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. ABAP_NOTE 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. ABAP_NOTE If a field is tagged with the RAP field characteristic notrigger$[:warn$], it must not be used in a trigger condition.
Validation Fails, Reactions If a validation fails for a certain entity instance, the following reactions occur:
An error message can be written to the reported structure of the MODIFY ENTITIES statement.
An entry is returned in the failed and reported structures of the COMMIT ENTITIES statement.
The operation fails and the complete content of the transactional buffer of the current RAP transaction is rejected. A commit to the database happens 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.
ABAP_AVAILABILITY
Managed RAP BOs
Unmanaged and draft-enabled RAP BOs. ABAP_CAUTION Not available for unmanaged, non-draft RAP BOs. ABAP_AVAILABILITY_END
ABAP_FURTHER_INFO Development guide for the ABAP RESTful Application Programming Model, section about Validations.
Latest 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. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF that defines the validation ValidateBuyerId. BDEF DEMO_SALES_CDS_SO_1 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 class CL_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 transaction than the invalid ones. If all three entity instances were created in one RAP transaction - 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 transaction contains only one inconsistent instance, the complete content of the transactional buffer is rejected. The class CL_DEMO_CDS_VALIDATION_1 demonstrates that validations accept or reject data changes per RAP transaction. It creates the same three BO instances as the report DEMO_CDS_VALIDATION, one of them valid, the other two invalid. Code snippet: ABEXA 01536 Since this RAP transaction 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 class CL_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: ABEXA 01537 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 ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA The example above is explained in detail in the executable example RAP BDL - validation . ABAP_EXAMPLE_END
