Technical Articles
Entity Manipulation Language – EML | RAP Series
What is EML?
Entity Manipulation Language (EML) is a part of the ABAP language. It means that there are new syntaxes available in ABAP to
- control the business object’s behavior in the context of ABAP RESTful programming model, using ABAP code user can manipulate Business Object created using ABAP RAP model
- provides a type-save read and modifying access to data in transactional development scenarios.
Where EML comes into the picture
How EML syntaxes look like?
EML contains syntaxes to READ, MODIFY (Create, Update, Delete, Execute Actions) and COMMIT. Let’s understand each syntax step by step
READ ENTITIES
MODIFY ENTITIES – CREATE
MODIFY ENTITIES – UPDATE
MODIFY ENTITIES – DELETE
MODIFY ENTITIES – ACTION
Commit Entities syntax is clubbed with Modify syntaxes to logically complete the flow. LUW concept is there in all the MODIFY syntaxes.
MODIFY syntax manipulates Transactional Buffer and READ also get data from Transactional Buffer. In the case of Managed Behavior, managed runtime automatically populates data in Transactional buffer and in case of Unmanaged Behavior, a user needs to implement Transactional READ method of Behavior Implementation
Where is EML used?
Usually, Business objects that are implemented with the ABAP RESTful architecture based on the behavior definition and implementation of the interaction phase and save sequence in behavior pools can be consumed by means of OData protocol (Fiori UIs, or Web APIs)
Now to access them through ABAP code EML syntax is used.
The standard API is used whenever the “target” business object is statically specified. It provides code completion and static code checks. This typed API provides statements for read-only access to data (READ ENTITIES), as well as for modifying data access (MODIFY ENTITIES) and for triggering the save sequence (COMMIT ENTITIES), these all we saw above
The generic API is typically used for generic integration of business objects into other frameworks, such as the Cloud Data Migration Cockpit or the Process Test Framework.
What is the Use Case?
One of the uses cases of EML is the writing of test modules as ABAP Unit tests. As ABAP application developer, it gives you the ability to test the transactional behavior of business objects for each relevant operation that is defined in the behavior definition.
Another use-case is cross BO integration. Executing CRUDA operation of RAP based BO in another RAP based BO’ Implementation in exits like determination, validation, actions, etc.
From which release it is available?
EML – Entity Manipulation Language is available after 1902 Cloud release and 1909 on-premise release
Few points to note
- Multiple modify elements can be used in one MODIFY statement. The sequence of the operations is irrelevant.
- EML syntaxes for LUW concepts
- Authorizations will be automatically handled by these syntaxes, if a user needs to escape authorizations then just add syntax – IN LOCAL MODE
- READ by associations also works. From a parent entity, child entity can be read and vice versa.
Kindly share your thoughts on this blog and I will continue writing blogs on RAP topic.
Regards,
Yogesh Vijay
RAP Trainer, Development Learning
Hi
My question is a little out of the question. It seems to me that expanding the syntax of a language for each function instead of building a library on top of an existing language is a strange solution?
Hi Sergey,
In some sense you are right, however, when there is a new Programming Model came into the picture – which includes new artefacts like we have Behavior Definition, Behavior Implementation, etc then adding new syntaxes specific to that model is I guess fine.
I can think of that there must be some limitation to build on top of existing language one. Anyways I will try to pass on this question to the relevant team and hope we get some answers to it.
Thanks,
Yogesh Vijay
I very much agree with this point. Why not take the modern approach used in, e.g., Java, Python and JS, where the core functionality is extended through libraries rather than adding new syntax to the language?
Hi Stoyko,
What you are talking about is something totally different. Let say in python or java, if they introduce another library then you have new syntaxes right? For example, at one point of time if string library is added then string functions like concat, etc came into the picture. Similarly, with the new programming model, we have new artefact as Behavior definition and now to manipulate BO based on RAP there is new syntax. There is no existing library which was there which can be enhanced.
What's your thought?
Hey, Yogesh,
I agree my choice of words could be clearer – I meant new core syntax. Other than this, I think my point is pretty clear – as you mention, Python or Java introduce new features using libraries. The core syntax of the language is the same, however. And very simple at that. There’s mainly just variables, arithmetic operations, conditionals, loops, classes, and functions/methods.
Instead, what we see here in ABAP RAP is very different. Statements like READ ENTITIES OF, FAILED, REPORTED, etc. are now part of the core syntax. The language itself has been modified. If they were instead provided through a library as they would in Java or Python, it would be something like this:
rap.read_entities_of(), rap.failed(), rap.reported()
etc.
See the difference?
Another example would be how sin() in ABAP is a function part of the core syntax, but in Java it’s provided through the Math library. It’s not part of Java’s core syntax.
Best,
Stoyko
Also, if you're interested check out this video, from 9:15:
https://www.coursera.org/lecture/nand2tetris2/unit-3-11-perspective-29aEp
It speaks exactly about the topic at hand. More specifically, it mentions how Java is extended through libraries but the language itself has been practically unchanged since 1996 🙂
That's a very good explanation, you are right what we have in JAVA or python.
Here we can have libraries (usually we have using standard classes) but adding another artefact which simplifies user experience - If you see behavior definition, it is easy to understand what all operations are available for my Business Object.
otherwise behind the scene things are same.
I tried to build a simple development, just to update a table depending on some vendor conditions, so I included the management in a BAdI.
I had many problems at the moment of saving the data:
Workaround to save all data was implementing a new local class with data to save and a method to handle COMMIT, and from behaviour saver local class I call to this one.
This way, I can save the data at COMMIT and COMMIT ENTITIES.
The solution to write the changes if EML is called during COMMIT, is to perform DB modifications directly in the CREATE/UPDATE/DELETE methods when sy-oncom = 'P'
I think that EML needs to take a look at this.
Hi Jaime,
Doing this will break the LUW, we have actions also along with basic operations and an option of Unmanaged SAVE. This will create a problem in view
Here Commit work is implicitly handled by framework and ideally BAdI’s and BAPI or any FM should not contain COMMIT WORK inside.
Any other thought?
Hi Yogesh,
I think that I didn't express myself correctly.
I am not doing the COMMIT by my self, it is performed by a proxy class.
This is the call stack:
The "delete_company" method:
I can't execute the COMMIT ENTITIES in this situation
Hi Yogesh,
That's really helpful, thanks for sharing!
Hi Yogesh,
Thanks for the great sharing!
We are developing a prototype of the standard product, in current desgin, we want to directly provide a class with CRUD methods which developed with EML to interact with our RAP model(Managed mode), then expose this class as a API to our consumers.
In your opinion, is this kind of desgin acceptable?
Regards
Yeah, this kind of design is acceptable, it's like a wrapper. So ideally these EML syntaxes themselves work as API's but if you want to simplify the terminologies then its fine.
Just remember EML syntaxes works on KEYS, I mean you can read data only based on KEY fields, not like SQL selects.
Hi Yogessh,
Yes, we want our API consumers to use it as they used to use other normal classes, so we add a wrapper to hide EML syntaxes(e.g. MODIFY ENTITIES OF xxx)
Thank you for your comments and further reminder!
I will do exactly the same thing in my project. But apart from the specific API, we also would like to separate it for testing purposes. This way we can mock the BO results in the productive class, instead having to introduce data in DB and then test.
This way we will separate the tests: the EML entity will be tested in the RAP class.
The productive code will only takes care of the main logic, BO results will be mocked.
Regards, Raquel
This is incomplete. you did not talk about the deep create, modify things. Also the main problem is not EML it's quite easy the problem is when using it in RAP implementation- what is %key and %control when to use what those documentations are lacking.
Hi,
this is quite useful blog.
I have a query..I have raised an error in precheck method of the behaviour definition, and when I try to read the entities, the error that was raised earlier was not getting captured in the reported data..
Could you please let me know, if there is any limitation in the precheck?
HI
I have a question regarding the Cross BO Integration Use Case. How should the Commit Entities be handled? Calling Modify/Commit from within another Behaviour implementation throws an error.
Many thanks
If you are using Managed BO's then it is handled out of the box, however, if another case then you might need to create a RFC where you can handle Commit separately.
Thanks Yogesh.
I guess my issue arises because I have wrapped the logic for the BO EML in a class and calling the class from within the Behaviour Implementation. Should the logic be kept in the Behaviour implementation? Why should it matter if it is in a separate class?
Thanks Yogesh.helpful blog