Ansicht
Dokumentation

ABAPEML_CORRESPONDING - EML CORRESPONDING

Vendor Master (General Section)   PERFORM Short Reference  
This documentation is copyright by SAP AG.

CORRESPONDING, Type Mapping for

    ${ ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY ) $}
  $| ${ out_d_type = CORRESPONDING ${dtype$|#$}( ntype MAPPING TO ENTITY ) $}
  $| ${ ntype = CORRESPONDING ${dtype$|#$}( in_d_type USING CONTROL ) $}
  $| ${ ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY USING CONTROL ) $}
  $| ${ in_d_type = CORRESPONDING ${dtype$|#$}( ntype CHANGING CONTROL ) $}.

Variants:

1. ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY ).

2. out_d_type = CORRESPONDING ${dtype$|#$}( ntype MAPPING TO ENTITY ).

3. ntype = CORRESPONDING ${dtype$|#$}( in_d_type USING CONTROL ).

4. ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY USING CONTROL ).

5. in_d_type = CORRESPONDING ${dtype$|#$}( ntype CHANGING CONTROL ).

Effect

The variants of the CORRESPONDING operator are used for creating structures or internal tables with type mapping in ABAP in the context of RAP. The type mapping functionality is targeted at applications that have, on the one hand, RAP BOs based on CDS entities and, on the other hand, further types that are typically older and implement the behavior of the RAP BOs or parts of it. It is especially relevant for the implementation type unmanaged that incorporates existing functionality into RAP. Yet, it can also be relevant for managed, for example, when using code for determinations or validations that already exist but which are based on older, non-RAP types, i. e. types that are not derived from the BDEF.

RAP requires BDEF derived types for the communication of RAP BO providers and RAP BO consumers. When including non-BDEF-derived types, the variants of the CORRESPONDING operator are responsible for matching them to the input (for example, TYPE TABLE FOR UPDATE) and output (for example, TYPE TABLE FOR READ RESULT) of BDEF derived types. A type mapping is needed if the types include field names that differ from the RAP BO or if the control information (%control) is available in non-BDEF-derived types. Instead of having many individual specifications using the CORRESPONDING operator, the variants with the additions for the type mapping help boost the maintenance and reduce errors.

As a prerequisite, the mapping must be specified in the BDEF. For more information, see the CDS BDL documentation on Mapping.

Notes on the syntax:

• ntype: Types that are not derived from the BDEF.

• dtype: It can be a structured type or a table type.

• #: It is a symbol for the operand type. This specification is only possible if the data type required in an operand position is unique and completely identifiable. The operand type must be a structure type or a table type.

• out_d_type: Output BDEF derived type, for example, TYPE TABLE FOR READ RESULT or TYPE STRUCTURE FOR READ RESULT.

• in_d_type: Input BDEF derived type, for example, TYPE TABLE FOR UPDATE or TYPE STRUCTURE FOR UPDATE.
  
  

Variant 1

ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY ).

Effect

Used for the mapping of a RAP input derived type (in_d_type) to a non-BDEF derived type (ntype). As a prerequisite, the mapping for the non-BDEF derived type must be specified in the BDEF.

Example

The following code demonstrates the assignment of an input derived type to a non-BDEF derived type using the addition MAPPING FROM ENTITY.

Variant 2

out_d_type = CORRESPONDING ${dtype$|#$}( ntype MAPPING TO ENTITY ).

Effect

Used for the mapping of a non-BDEF derived type (ntype) to a RAP output derived type (out_d_type). As a prerequisite, the mapping for the non-BDEF derived type must be specified in the BDEF.

Example

The following code demonstrates the assignment of a non-BDEF derived type to an output derived type using the addition MAPPING TO ENTITY.

Variant 3

ntype = CORRESPONDING ${dtype$|#$}( in_d_type USING CONTROL ).

Effect

Type mapping variant that respects the %control component of BDEF derived types. in_d_type must be a BDEF derived type that includes the %control component. Only those fields for which the corresponding %control field have been marked as enabled are respected by the mapping, i. e. if a specific %control field is marked as disabled (e. g. the field is initial) in in_d_type, the mapping is not applied to it on the non-BDEF-derived type ntype. There is no mapping required for the non-BDEF derived type in the BDEF if its components have the same field names as the ones from the BDEF-derived type.

Example

The following code demonstrates the assignment of an input derived type to a non-BDEF derived type using the addition USING CONTROL. The %control component of a particular field is not selected, hence, this field is not assigned.

Variant 4

ntype = CORRESPONDING ${dtype$|#$}( in_d_type MAPPING FROM ENTITY USING CONTROL ).

Effect

Type mapping variant that takes the %control component of BDEF derived types into consideration. in_d_type must be a BDEF derived type that includes the %control component. Only those fields for which the corresponding %control field have been marked as enabled are considered for the mapping, i. e. if a specific %control field is marked as disabled (e. g. the field is initial) in in_d_type, the mapping is not applied to it on the non-BDEF-derived type ntype. The variant is used if the components of the non-BDEF derived type have different field names than the ones from the BDEF-derived type. Thus, a mapping is required for the non-BDEF derived type in the BDEF with the notation control.

Example

The following code demonstrates the assignment of an input derived type to a non-BDEF derived type using the addition MAPPING FROM ENTITY USING CONTROL.

Variant 5

in_d_type = CORRESPONDING ${dtype$|#$}( ntype CHANGING CONTROL ).

Effect

Type mapping variant that fills the %control structure of a BDEF-derived type based on a non-BDEF-derived type that does not include control information, i. e. if a field of ntype is left initial, the statement leaves the corresponding %control component of the field initial (00). Vice versa, if a field of ntype is provided with a value, the statement sets the corresponding %control component of in_d_type as enabled (01).

There is no mapping required for non-BDEF derived types in the BDEF if their components have the same field names as the ones from the BDEF-derived types. If non-BDEF derived types have different field names and a mapping from non-BDEF-derived types to input BDEF-derived types is required, a mapping in the BDEF must be defined (with the notation control) and a second CORRESPONDING statement with the addition MAPPING TO ENTITY must precede the statement with CHANGING CONTROL. In doing so, the first CORRESPONDING statement with the addition MAPPING TO ENTITY is responsible for mapping the field names and the second statement with CHANGING CONTROL is responsible filling the %control structure. This mapping variant is only possible for BDEF-derived types in the input since all of them include %control structures.

Example

The following code demonstrates the assignment of a non-BDEF derived type to an input derived type using the addition CHANGING CONTROL.

The example - CORRESPONDING, Type Mapping demonstrates the different variants with a simple managed RAP BO.

ROGBILLS - Synchronize billing plans   ABAP Short Reference  
This documentation is copyright by SAP AG.

Length: 11987 Date: 20240426 Time: 153458     sap01-206 ( 198 ms )