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:
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:
'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:
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.