Preface – This post is part of the SAP ABAP RAP series.
Table of Contents
Introduction
SAP Entity Manipulation Language (EML) is an ABAP language that is used to control the behavior of business objects in the context of the RESTful Application Programming model (also called SAP ABAP RAP). The business objects developed with the SAP ABAP RAP model can be consumed not only by OData protocol (Web API, Fiori UI) but also in ABAP using EML statements.
There are two flavors of EML:
- Standard API: Uses signature of business object entities
- Generic API: Used for dynamic consumption of the business object
The Generic API is used for the dynamic integration of business objects into other frameworks, such as the Cloud Data Migration Cockpit. Generic API is not in our scope. We will focus on Standard API’s.
The Standard API’s are used when target business object is statically specified. It provides READ and MODIFY statements for the access of transactional scenarios of objects and COMMIT access for triggering save sequence. Using these syntaxes we will be able to perform the transactional behavior ( Create, Update, Delete, Actions, Read ) of business objects that are defined in Behaviour Definition.
SAP EML Scenarios
The following table gives you an overview of different SAP EML scenarios:
| Scenario | Description | Relevant EML statements |
| Develop(BO with IN LOCAL MODE within its own behaviour pool) | In EML develop scenario, when you provide the functionality for your own BO in its own behaviour pool, you use IN LOCAL MODE. It bypasses the access control, authorization control and feature instance control. You can use it with CRUD and Actions. | · READ/READ by ASSOCIATION
· CREATE/CREATE BY ASSOCIATION · UPDATE/UPDATE BY ASSOCIATION · DELETE/DELETE BY ASSOCIATION · EXECUTE · AUGMENTING BY ASSOCIATION |
| Consume (BO from other behaviour pool/ released objects) | In consume scenario, you can use EML to consume other BO in or released BO’s. Here, you are not allowed to used IN LOCAL MODE. | · READ/READ by ASSOCIATION
· CREATE/CREATE BY ASSOCIATION · UPDATE/UPDATE BY ASSOCIATION · DELETE/DELETE BY ASSOCIATION · EXECUTE · GET PERMISSION · SET LOCK |
| Test | To test the BO outside of ABAP behaviour pool, you can use EML statements. Here, it is mandatory to add COMMIT statement to end RAP LUW. When in case of implementation inside behaviour pool, save it is done by the framework and we need not to write explicit COMMIT there. | · READ/READ by ASSOCIATION
· CREATE/CREATE BY ASSOCIATION · UPDATE/UPDATE BY ASSOCIATION · DELETE/DELETE BY ASSOCIATION · EXECUTE · GET PERMISSION · SET LOCK · COMMIT ENTITIES · ROLLBACK ENTITIES |
SAP EML Syntax
SAP EML syntax has three major sections:
- READ
- MODIFY
- COMMIT
READ syntax
READ is used to retrieve the data or you can say read the data of the entity. The syntax supports:
- Read: Read the entity
- Read by association: Read child entity using parent key
Short syntax –
READ ENTITY EntityName [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance RESULT et_result BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_rba RESULT et_result_rba LINK et_link_rba [FAILED ct_failed]. where, EntityName: specifies the CDS view entity FIELDS: specifies the direct read for the given fields RESULT: used to store the retrieved data in variable LINK: used to store the key pair that is used for read by association operation Failed: used to store the response about failed retrieve (key-value, fail cause etc)
Long syntax-
READ ENTITIES OF RootEntityName ENTITY entity_1 " entity alias name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_1 RESULT it_result BY \association1_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_rba RESULT et_result_rba LINK et_link_rba ENTITY entity_2_name " entity alias name [FIELDS ( ...... ENTITY entity_3_name " entity alias name ... [FAILED ct_failed].
The long syntax allows you to club READ operation of multiple entities of Business Object specified by RootEntity name at one go. Also, we can use alias names of entities defined in Behavior Definition.
Example:
READ ENTITIES OF /dmo/i_travel_m ENTITY travel FIELDS ( travel_id agency_id customer_id booking_fee total_price currency_code ) WITH CORRESPONDING #( keys ) RESULT DATA(ct_read_result) FAILED DATA(ct_failed) REPORTED DATA(ct_reported).
MODIFY syntax
MODIFY statement is used when we want to perform the change of data in entities. It includes:
- Create
- Create by association
- Update
- Delete
- Execute (for Action)
Short syntax-
MODIFY ENTITY EntityName CREATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it instance_crt CREATE BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_cba UPDATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_upd DELETE FROM it_instance_del EXECUTE action_name FROM it_instance_act [RESULT et_result_a] [FAILED ct_failed] [MAPPED ct_mapped] [REPORTED ct_reported].
Long syntax-
MODIFY ENTITIES OF RootEntityName ENTITY entity1_name CREATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance1_crt CREATE BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] itinstance1_cba UPDATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] itinstance1_u DELETE FROM it_instance1_del EXECUTE action FROM it_instance1_act [RESULT et_result] ENTITY entity2_name CREATE FROM it_instance2_crt ... ENTITY entity3_name ... [FAILED ct_failed] [MAPPED ct_mapped] [REPORTED ct_reported].
The long syntax allows clubbing multiple MODIFY operations of entities specified by RootEntity of the business object. We can specify alias names for entities if they are defined in behaviour definition.
Example
MODIFY ENTITIES OF /dmo/i_travel_m ENTITY travel CREATE FIELDS ( travel_id agency_id customer_id begin_date end_date booking_fee total_price currency_code description overall_status ) WITH lt_create MAPPED ct_mapped FAILED ct_failed REPORTED ct_reported.
COMMIT syntax
The COMMIT syntax is used along with the MODIFY statement. As MODIFY statement does not change the data at database level, it is required to call COMMIT after MODIFY to persist the database changes.
The modify statement set the data to transaction buffer and buffer data gets cleared after the ABAP session is closed. That means we need to trigger save sequence to save the data from the transactional buffer to the database. This trigger is called by executing the COMMIT statement. For save sequence methods you can refer to our previous articles.
Simple syntax-
COMMIT ENTITIES.
Long syntax-
COMMIT ENTITIES [RESPONSE OF rootentityname1 [FAILED ct_failed] [REPORTED ct_reported]] [RESPONSE OF rootentityname2 [FAILED ct_failed] [REPORTED ct_reported]].
Using long syntax we can call COMMIT for multiple entities by explicitly specifying RootEntity names. Whereas, the simple syntax COMMIT ENTITIES will also work for multiple entities in the same LUW. Here we need to specify the RootEntity name.
0 Comments