The derived types for actions identify the action via the name of the entity and the name of the action, separated by the tilde (~) character.

 

Derived Data Types

Overview of Derived Data Types for Import and Result

 

The structure types of derived data types depend on the RAP BO entity and the operations. They contain components of RAP BO entities, that is, persisted key and data field values that retain their original line type. However, derived types contain additional components that do not derive their type from the entity. They have special, tailor-made line types that provide additional information required in the context of transactional processing. The names of those additional components begin with % to avoid naming conflicts with components of the CDS entities.

 

Let us consider a RAP BO entity that consists of five fields, named field1, field2, and so on, of which the first two fields are key fields.

 

If we look at the derived data types for operation Read, we can see that the result contains all five fields, whereas the derived data type FOR READ IMPORT contains only the key fields. The same is true for the derived type for operation Delete.

 

On the other hand, the types for Read, Import, Update, and Create contain a generated substructure of generic name %control. This substructure has as many components as there are fields in the RAP BO entity. The names of the components are identical to the fields in the entity but their data type is ABAP_BEHV_FLAG. % is used in certain cases to specify which fields are requested or provided.

 

Components %cid and %cid_ref are needed for situations where the values for the key fields of newly created instances are not provided by the consumer, but calculated by the BO logic (internal numbering). In such a situation, the coding calling the Create operation, has to provide unique string values for %cid to identify the new instances. The framework returns a table with the mapping of %cid values and the calculated key values.

In addition to the physical components, derived types also contain component groups. They begin with % too and serve the purpose of summarizing groups of table columns under a single name. For example, %data summarizes all elements of the related entity (CDS view).

 

Technically, the component groups are named includes and the components can be addressed by the name of the include.

 

In the example in the figure, Component Groups in Derived Types, field2 is addressed directly as part of the named include %tky, and as part of the named include %data. Because %tky is part of %data, the field can even be addressed as component %tky of named include %data.

 

Response Operands

Response Operands

 

In addition to the input and result operands, EML statements use a set of response operands to provide feedback on the outcome of an operation. While the types of the operands for input and result depend on the entity and the individual operation, the type of the response operands only depends on the RAP business object, identified by the name of its root entity. Currently, there are three response operands, but not all are available for all EML statements.

 

Responses are imported by adding keywords FAILED, REPORTED, or MAPPED to the EML statement. These keywords have to be followed by a deep structure of the related derived data type for the RAP BO root entity. The import of responses is optional.

 

EML offers the following response operands:

• FAILED is used for logging instances for which an operation has failed. The related derived type is RESPONSE FOR FAILED.
• REPORTED is used for returning messages. These messages are either related to a specific instance or static, that is, independent from a specific data set.
• MAPPED is used to map the calculated key values of created instances to the provided temporary IDs (component %cid). It is only relevant for CREATE operations.

 

Overview of Derived Data Types for Response