EML consists of statements that you can use to manipulate the data of a business object. You use the READ ENTITIES statement to read data; for all other operations, you use the MODIFY ENTITIES statement with the corresponding addition UPDATE, CREATE, or DELETE.
You can only use the CREATE, UPDATE, and DELETE operations if the behavior definition of the business object contains the corresponding use create, use update, or use delete directive. Trying to use a prohibited operation causes a syntax error.
To read data from a business object, you use the READ ENTITIES statement. The statement has two important parameters: one internal table containing the keys of the data that you want to read and another containing the results of the query.
These internal tables have special data types called derived behavior definition types. The system creates them automatically when a developer creates a behavior definition and they contain some or all of the fields of the business object along with further fields that control how the system processes a particular request. You declare the internal tables using the new addition TYPE TABLE FOR <operation> in the DATA statement.
The type TABLE FOR READ IMPORT contains the key field or fields of the business object. The %control structure is a generated structure that indicates which fields of the business object are actually used in the current operation. In many cases and, importantly, in our example, the system fills the structure automatically and you do not have to worry about it.
The type TABLE FOR READ RESULT contains all of the fields of the business object. This table contains the result set after the query has been executed.
The read import table contains a column for each key field of the business object, in this case, AirlineID. To read a particular airline, you add a row to the internal table containing its key. As well as the key field or fields, the table contains the columns %is_draft and %control. These are populated automatically by the RAP runtime; you do not have to do anything with them explicitly.
When you process a business object, using the READ ENTITIES OF or MODIFY ENTITIES OF statement, you must specify the name of the behavior definition. Technically speaking this is the name of the repository object with type behavior definition, not the name in the DEFINE BEHAVIOR statement. Consequently, you cannot use any alias name that the behavior definition might have. Once you have provided the name of the behavior definition, you must specify the name of the entity with which you want to work. Here, you do use the alias name if there is one.
The READ ENTITIES statement reads business object data according to the keys that you pass in the WITH addition. It returns the result in the internal table in the RESULT addition. In the statement, you can also specify which fields of the business object you need. In this example, we have used the ALL FIELDS addition to return all of the fields. However, if you only require a subset of the fields, you can use the variant FIELDS ( field1 field2 … ) to restrict the amount of data that is read. Note that, unlike in a SELECT statement, the field list is not comma-separated.
The result table contains all of the fields of the business object, along with the control field %is_draft. If your READ ENTITIES statement contains the FIELDS ( f1 … fn ) variant, only the fields that you requested will be filled. If you use the ALL FIELDS variant, the system provides the values of all of the fields.
If you want to update data, you declare an internal table with TYPE TABLE FOR UPDATE. This contains all of the fields of the business object and also the %control structure, although the system fills this automatically.
The MODIFY ENTITIES statement updates data in the RAP transactional buffer. In the UPDATE FIELDS addition, you specify which fields should be changed. In the WITH addition, you pass the internal table containing the data that you want to update.
Instead of using UPDATE FIELDS (list), you can use the variant UPDATE SET FIELDS. In this case, the system updates all non-key fields of the business object for which update_tab contains a non-initial value.
When you use EML outside the business object, you must use the COMMIT ENTITIES statement to persist the data in the database. Within the behavior implementation, the RAP framework performs the commit automatically.