Type Mapping

The need for Field Mapping

 

Whenever existing code and its data types are to be reused in behavior pools of business objects, you need to perform a mapping between CDS field names and types and the corresponding legacy field names and types.

 

In the example, the existing code is a function module with a changing parameter. The parameter of this function module is typed with d437_s_struct, which is a structure type with components comp1, comp2, and so on. The RAP BO defines an entity d437_i_entity with fields named field1, field2, and so on.

 

Inside the handler methods, the RAP BO data is available in data objects that are based on derived types for the entity. To hand the information over to the function module, it has to be copied into a data object based on structure type d437_s_struct and, because the component types are not identical, normal CORRESPONDING does not help here.

Field Mapping in Behavior Definition and ABAP

 

In RAP, it is possible to define a central, declarative mapping in the behavior definition and to use this mapping in the behavior implementation with a special variant of the CORRESPONDING expression.

 

This technique is particularly interesting for the unmanaged implementation type, which essentially represents a kind of wrapper for existing legacy functionality. But, with the managed implementation type, it can happen, for example, that the code for a determination or validation already exists, but is based on "old" (legacy) data types.

 

In the example, the behavior definition contains a mapping statement for structure type d437_s_struct with the pairs of entity fields and structure components.

 

The ABAP coding in the behavior implementation defines a data object ls_struct, which is typed with d437_s_struct and a data object ls_entity typed with a derived structure type for entity d437_i_entity.

 

When copying information from ls_entity to ls_struct, the mapping is used in a CORRESPONDING expression with the addition MAPPING FROM ENTITY. When copying information from ls_struct to ls_entity, the addition MAPPING TO ENTITY is used instead.

 

Control Mapping

The Need for Control Type Mapping

 

In some legacy scenarios, as well as the dictionary type directly corresponding to the entity, there is a second dictionary type that contains the same components, but all of them have data type C(1).

 

This type is then used to indicate the fields in the main structure that are accessed by an operation (update, read, and so on).

 

When calling such existing code, the actual parameter for such a control structure has to be filled with the values from the %CONTROL structure in the derived types.

 

As well as the possibly different field names, you have to consider the different concepts for bool-like types that are used in RAP and in legacy code. Where ABAP traditionally uses type C(1) with values 'X' and ' ' (Space), RAP uses the more modern approach of type X(1) with values hexadecimal values #01 and #00.

 

This could lead to rather lengthy coding. In the example, only the first component of %control is mapped to the first component of the legacy control structure ls_structx.

Control Mapping in Behavior Definition and ABAP Coding

 

It is possible to include a mapping definition for the control structure in the mapping for statement for the data structure. To do this, add keyword control, followed by the name of the legacy control structure.

 

In ABAP, add keywords USING CONTROL inside the CORRESPONDING expression if you want to populate a legacy control structure based on component %control of a derived data type.