EML – Entity Manipulation Language
Entity Manipulation Language (in short: EML) is a part of the ABAP language that is used to control the business object’s behavior in the context of ABAP RESTful Application programming model. It provides a type-save read and modifying access to data in transactional development scenarios.
Business objects implemented with the ABAP RESTful architecture, based on the behavior definition and the interaction phase and save sequence in behavior pools, can be consumed not only through the OData protocol (e.g., Fiori UIs or Web APIs) but also directly in ABAP using the EML syntax.
Business objects implemented with the ABAP RESTful architecture, based on the behavior definition and the interaction phase and save sequence in behavior pools, can be consumed not only through the OData protocol (e.g., Fiori UIs or Web APIs) but also directly in ABAP using the EML syntax.
EML Syntax The EML syntax consists of three major statements:
➯ MODIFY ENTITIES
➯ READ ENTITIES
➯ COMMIT ENTITIES
➯ READ ENTITIES
➯ COMMIT ENTITIES
MODIFY ENTITIES
This statement includes all operations that change data of entities. This is handled by the statement MODIFY ENTITIES, which provides the following operations:
● create
● create by association
● update
● delete
● actions, that is, any modify operation that cannot be covered with create, update, or delete
Syntax – Short form
MODIFY ENTITY EntityName
CREATE FROM it_instance_c
CREATE BY \association_name FROM it_instance_cba
UPDATE FROM it_instance_u
DELETE FROM it_instance_d
EXECUTE action_name FROM it_instance_a
[RESULT et_result_a]
[FAILED ct_failed]
[MAPPED ct_mapped]
[REPORTED ct_reported].You can use the short form of the MODIFY statement in special cases when calling modify operations for one entity only – without any relation to a business object.
Syntax – long form
MODIFY ENTITIES OF RootEntityName
ENTITY entity_1_name " entity alias name
CREATE FROM it_instance1_c
CREATE BY \association1_name FROM it_instance1_cba
UPDATE FROM it_instance1_u
DELETE FROM it_instance1_d
EXECUTE action FROM it_instance1_a [RESULT et_result_a]
ENTITY entity_2_name " entity alias name
CREATE FROM it_instance2_c ...
ENTITY entity_3_name " entity alias name ...
[FAILED ct_failed]
[MAPPED ct_mapped]
[REPORTED ct_reported]. The different operations can be mixed within one EML statement. It is possible, for example, to combine a create, update and action operation of an entity (even related to the same instance(s)) in one statement.
READ ENTITIES
This statement includes all operations that do not change data of entities (read-only access).
● read: for read access to entities by using a key
● read by association: for read access to child entities by using parent key(s).
● read by association: for read access to child entities by using parent key(s).
Syntax – short form
READ ENTITY EntityName
FROM it_instance
RESULT et_result BY \association_name FROM it_instance_rba
RESULT et_result_rba LINK et_link_rba
[FAILED ct_failed]
[REPORTED ct_reported]. The short syntax directly specifies the EntityName (CDS view name). The consumer using EML has therefore read access to data for this entity only. The read-by-association operation provides an additional target variable that follows after the LINK keyword addition
Syntax – long form
READ ENTITIES OF RootEntityName
ENTITY entity_1 " entity alias name
FROM it_instance_1
RESULT it_result
BY \association1_name FROM it_instance_rba
RESULT et_result_rba
LINK et_link_rba
ENTITY entity_2_name " entity alias name
FROM it_instance_2 ...
ENTITY entity_3_name " entity alias name ...
[FAILED ct_failed]
[REPORTED ct_reported].The long form READ ENTITIES allows you to group read operations for multiple entities of a business object in that is specified by RootEntityName
COMMIT ENTITIES
Modify operations that are executed within a behavior pool or by an ABAP program, do not cause any data changes at the database level. This is because they are applied only to the transactional buffer and the buffer content disappears at the end of the ABAP session. This means the save sequence must be triggered in this case.
The save sequence is triggered by the COMMIT ENTITIES statement. The runtime infrastructure translates this statement into the save chain starting with finalize( ) performing the final calculations before data can be persisted. If the subsequent check_before_save( ) call is positive for all transactional changes, the point-of-no-return is reached. From now on, a successful save() is guaranteed by all involved BOs. After the point-of-no-return, the adjust_numbers( ) call can occur to take care of late numbering. The save( ) call persists all BO instance data from the transactional buffer in the database .
The save sequence is triggered by the COMMIT ENTITIES statement. The runtime infrastructure translates this statement into the save chain starting with finalize( ) performing the final calculations before data can be persisted. If the subsequent check_before_save( ) call is positive for all transactional changes, the point-of-no-return is reached. From now on, a successful save() is guaranteed by all involved BOs. After the point-of-no-return, the adjust_numbers( ) call can occur to take care of late numbering. The save( ) call persists all BO instance data from the transactional buffer in the database .
Syntax – Short form
COMMIT ENTITIES.Syntax – Long form
COMMIT ENTITIES
[RESPONSE OF root_entity_name_1
[FAILED ct_failed]
[REPORTED ct_reported]]
[RESPONSE OF root_entity_name_2
[FAILED ct_failed]
[REPORTED ct_reported]]. COMMIT ENTITIES saves all BOs that were changed within the LUW
