Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 

Whenever structures or internal tables with many fields are involved in an sap2sap integration i usually carry out it using remote runtime data-typing, as i've shown in my two blogs:

This approach avoids data dictionary redundancy across systems and saves also a lot of time in data dictionary creation if involved structures contain dozens or hundreds of fields. Recently, thanks to the work of hans.pettersson (and previously also thanks to my colleague fabrizio.gemma), i realized that the solution was limited to simple structures; simple in the sense that weren't managed fields defined as:

  1. structure include

  2. nested structures

  3. nested internal tables

For example (considering all above cases) a structure defined as:


Although a simple structure is the most common case i decided to put my hands on code once again, starting from Hans's work, to handle all these cases. At first glance i thought it was a really hard work but i was wrong; in fact, once reviewed my old code, it has been very easy. I did a few simple fixes to my zcl_dyn_remote_type_builder=>get_components method to achieve the goal. Now the method is able to handle following internal data types:

  1. 'h' internal table (cl_abap_elemdescr=>typekind_table)

  2. 'u' structure (cl_abap_elemdescr=>typekind_struct1)

  3. 'v' deep structure (cl_abap_elemdescr=>typekind_struct2)

and create recursively the related abap components by means of usuals zcl_dyn_remote_type_builder=>create_struct_type and zcl_dyn_remote_type_builder=>create_table_type methods. It was necessary to call ddif_fieldinfo_get function module specifying the "all_types flag". It was also necessary to handle the returned internal table "lines_descr" for nested internal table data typing. At last i used the lfield field returned in dfies_tab to distinguish between fields added as structure include (.include field in picture) and fields of a structure included (the struc1 field in picture). Below a snippet of the new code:

* build elements

call function 'DDIF_FIELDINFO_GET' destination i_rfcdest
tabname = i_struct
all_types = 'X'
x030l_wa = ls_x030l
lines_descr = lt_lines
dfies_tab = lt_fields
not_found = 1
internal_error = 2
others = 3.


loop at lt_fields into ls_dfies where not lfieldname cs '-'.


* build elements

case ls_dfies-inttype.

* build table types

when cl_abap_elemdescr=>typekind_table.

read table lt_lines into ls_line with key typename = ls_dfies-rollname.
read table ls_line-fields into ls_lfield with key tabname = ls_line-typename.

lo_table = zcl_dyn_remote_type_builder=>create_table_type( i_rfcdest = i_rfcdest
i_struct = ls_lfield-rollname ).
ls_comp-type = lo_table.

* build structure types

when cl_abap_elemdescr=>typekind_struct1 or cl_abap_elemdescr=>typekind_struct2.

lo_struct = zcl_dyn_remote_type_builder=>create_struct_type( i_rfcdest = i_rfcdest
i_struct = ls_dfies-rollname ).
ls_comp-type = lo_struct.

* build element types (also for fields in included structures)

when others.

lo_elem = zcl_dyn_remote_type_builder=>get_elemdescr( i_inttype = ls_dfies-inttype
i_intlen = lv_intlen
i_decimals = lv_decimals ).
ls_comp-type = lo_elem.


append ls_comp to result.



My saplink nugg is available there.

Recently i spent a little bit of my free time to modernize my code, reviewing and rewriting it in a full object oriented way. I also improved it with additional features for both remote typing and querying.

The new nugg can be downloaded there. There's a program named zsrqldemo showing some code examples.

1 Comment