SAP EML TYPE MAPPING ABEXA



Get Example source ABAP code based on a different SAP table
  



ABAP_EML - CORRESPONDING, Type Mapping
This example demonstrates type mapping variants in ABAP_EML using the CORRESPONDING operator with a simple managed RAP BO.
Data model
The CDS data model consists of the root entity DEMO_MANAGED_ROOT_MAP and its child entity DEMO_MANAGED_CHILD_MAP which is not used in this example.
Root entity:
DDLS DEMO_MANAGED_ROOT_MAP
Behavior definition
The RAP behavior definition DEMO_MANAGED_ROOT_MAP is defined in RAP BDL as follows:
BDEF DEMO_MANAGED_ROOT_MAP
Behavior implementation
For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_MAP. It is not relevant in this example.

ABAP_SOURCE_CODE
DEMO CL_DEMO_RAP_EML_TYPE_MAPPING

ABAP_DESCRIPTION
Access with ABAP using EML
The above source code uses EML to access the RAP business object from an ABAP class. The following variants are covered:
ntype = CORRESPONDING dtype|#( in_d_type MAPPING FROM ENTITY ). An internal table typed with the input derived type TYPE TABLE FOR UPDATE gets filled, i. e. values for data fields are specified for a single line. A non-BDEF-derived type (i. e. a non-RAP-native DDIC type), which has different field names than those of the RAP BO, is given the values using the CORRESPONDING operator variant mentioned above. As a prerequisite, a mapping for the non-BDEF-derived type is specified in the BDEF. The output window shows two internal tables with the single line that gets created: one internal table typed with the derived type, the other one with the non-BDEF-derived type.
out_d_type = CORRESPONDING dtype|#( ntype MAPPING TO ENTITY ). An internal table typed with a non-BDEF-derived type gets filled, i. e. values for data fields are specified for a single line. The field names differ from those of the RAP BO. An internal table typed with the output derived type TYPE TABLE FOR READ RESULT receives the values using the CORRESPONDING operator variant mentioned above. As a prerequisite, a mapping for the non-BDEF-derived type is specified in the BDEF. The output window shows two internal tables with the single line that gets created: one internal table typed with the derived type, the other one with the non-BDEF-derived type.
Excursion: Syntax for non-BDEF control types The example uses the variant MAPPING FROM ENTITY and includes control information that is available in another non-BDEF-derived type. As a prerequisite, a mapping for the non-BDEF-derived type and the type that holds the control information is specified in the BDEF (MAPPING ... CONTROL ...). An internal table typed with the input derived type TYPE TABLE FOR UPDATE gets filled, i. e. values for data fields and the %control structure are specified. One component of the %control structure gets disabled. A non-BDEF-derived type, that has different field names than those of the RAP BO, receives the values using the CORRESPONDING operator variant mentioned above. As a second step, the partner control type receives the values from the %control structure. The output window shows the one line of the internal table as well as the %control structure for the derived type that get created. Likewise, the internal tables for the non-BDEF-derived type and the type control information is displayed demonstrating the effect of applying the CORRESPONDING operator variant. The field that is disabled in the %control structure is consequently left blank in the table typed with the partner control type.
ntype = CORRESPONDING dtype|#( in_d_type USING CONTROL ). An internal table typed with the input derived type TYPE TABLE FOR UPDATE gets filled, i. e. values for data fields and the %control structure are specified for a single line. One component of the %control structure gets disabled. A non-BDEF-derived type, that h same field names as those of the RAP BO, receives the values using the CORRESPONDING operator variant mentioned above. Here, the %control structure values are taken into consideration. A mapping for the non-BDEF-derived type is not needed in the BDEF in this case. The output window shows the data fields and the %control structure values that are specified for the derived type and the effect of applying the CORRESPONDING operator variant. The internal table typed with the non-BDEF-derived type receives the values. However, field1, which is marked as disabled in the %control structure of the derived type, does not contain a value.
ntype = CORRESPONDING dtype|#( in_d_type MAPPING FROM ENTITY USING CONTROL ). An internal table typed with the input derived type TYPE TABLE FOR UPDATE gets filled, i. e. values for data fields and the %control structure are specified for a single line. One component of the %control structure gets disabled. A non-BDEF-derived type, that h different field names than those of the RAP BO, receives the values using the CORRESPONDING operator variant mentioned above. Here, the %control structure values and the mapping are taken into consideration. As a prerequisite, a mapping for the non-BDEF-derived type must be specified in the BDEF in this case. The output window shows the data fields and the %control structure values that are specified for the derived type and the effect of applying the CORRESPONDING operator variant. The internal table typed with the non-BDEF-derived type receives the values. However, field2, which is marked as disabled in the %control structure of the derived type, does not contain a value.
in_d_type = CORRESPONDING dtype|#( ntype CHANGING CONTROL ). An internal table typed with a non-BDEF-derived type gets filled, i. e. values for data fields are specified for a single line. All data fields are specified except one. An internal table, that is typed with the input derived type TYPE TABLE FOR UPDATE, receives the values using the CORRESPONDING operator variant mentioned above. Since the non-BDEF-derived type's field names are the those of the RAP BO, a mapping for the non-BDEF-derived type is not need BDEF in this case. The output window shows the values of the data fields of the single line that is created for an internal table typed with a non-BDEF-derived type . The following two tables demonstrate the effect of applying the CORRESPONDING operator variant. The internal table typed with derived type receives the values. Due to the fact that a value has not been specified for a field in the non-BDEF-derived type, the %control structure of the derived type shows that the particular field is marked as disabled.
Excursion: Variant with CHANGING CONTROL including a preceding mapping An internal table typed with a non-BDEF-derived type gets filled, i. e. values for data fields are specified for a single line. All data fields are specified except one. An internal table, that is typed with the input derived type TYPE TABLE FOR UPDATE, receives the values using the CORRESPONDING operator variant with the addition USING CONTROl. The non-BDEF-derived type's field names are different from those of the RAP BO. A mapping for the non-BDEF-derived type is required in the BDEF. The mapping must be done separately in ABAP. In this example, a helper variable typed with the entity type is used for a separate statement with the CORRESPONDING operator and the addition MAPPING TO ENTITY succeeded by a statement with the addition CHANGING CONTROL also using the helper variable. The output shows the values of the data fields of the single line that is created for an internal table typed with a non-BDEF-derived type . The following two tables demonstrate the effect of applying the CORRESPONDING operator variant. The internal table typed with derived type receives the values. Due to the fact that a value has not been specified for a field in the non-BDEF-derived type, the %control structure of the derived type shows that the particular field is marked as disabled.