Recursive DDIC structures

[CarstenKasper]

Hi everyone,

today I ran into a rather odd problem when defining my DDIC types.

What I want to do is rather simple: I want to read information about a folder that can have subfolders which can then again have subfolders and so on. Just like in the Windows file explorer.

Now my approach was rather straight forward:

1. Create a structure with some basic data.
2. Create a table type of that structure.
3. Now I went back to the structure from 1 and added another attribute named "subfolders" with the TYPE of 2.

Activation works well, no errors or warnings.

When I try to use this structure in my ABAP program it does not compile with the error "There is already a type called "My TableType Name".

Of course when I remove the attribute that I added in 3 everything works fine.

Anyone any ideas? Why does the structure activate? What is the best practice to do recursive structures in DDIC?

cheers Carsten

[kakshat]

Good question. I have never tried creating a recursive structure but it's understandable that it's leading to issues. Simply because it will lead to an infinite level of nesting. I am not sure why the system did not raise any warnings/errors while activating the structure but possibly that's a limitation of the system.

Thinking of alternatives, have you considered converting your recursive structure into a single flat table which has a column for 'Parent' to help identify parent-child relationships?

[Former Member]

why do you want a recursive stucture?

When you create a structure in DDIC, corresponding template is created in the database.

IT CAN NOT BE DYNAMIC.

In case you want a dynamic structure, it can be done only at runtime with the help of field symbols.

In case you want to create windows explorer kind of functionality, you can have a table/structure as:

Current_Folder XPrimary

Sub_folder         XPrimary

[CarstenKasper]

I do not want to create a dynamic structure, but a recursive one.

I do not want an "explorer kind of functionality", it is just meant as an example where it might be useful. If you feel better think of a tour to Disney Land. The tour consists of several distinctive groups. These groups can again consists of subgroups, which can have subgroups.... and so on.

In this particular case: I am calling a webservice that supplies to me an XML which is structured in this way: Hierarchical structure of folders with lots of subfolders. To keep things simple I tried to design the DDIC structure the same way.

My questions are:

Why does SE11 throw no error when I create and activate the structure?

Why does SE38/SE80/SE24 throw errors when the structure is used?

[Former Member]

I am not sure what your requirement is, but you can still create the required structure during runtime, get all required data and then process and post the data to the same to custom tables. In that case, you would not need a structure to be recursive.

The group example you have mentioned, i think is quite similar to the way hierarchy is maintained in OM(HR) using tables HRP1001. But it would be too complicated for XML file handling.

[CarstenKasper]

Hi Chinmay,

you are correct, I could do with dynamically created structures during runtime, but one big drawback would be that I want to have the strucutre as method parameter. Of course I could go with TYPE REF TO DATA there... Which leads me to having to interprete the strucutre in all following methods.I am trying to encapsulate the WebService call and make it as simple to use as possible.

I am lucky that I do not have to persist the data in any way. It is just for display purpose.

A hierarchical structure, which is well defined in the DDIC, is just my most favoured option. It would be so easy to handle.

Anyway I fear ABAP does not support this so I have to stick with either the solution I described below using TYPE REF TO or the one that Kumar pointed out with the PARENT column.

cheers Carsten

[CarstenKasper]

I am quite sure why recursive structures do not work in ABAP. My assumption:

All local data that is not a reference is directly allocated on the heap. With recursive structures this would crash the system.

Might this be correct?

My current solution to the problem is that I give the subfolders as a TYPE REF TO.

Example:

ZFOLDER

Attribute	Type	DDIC
NAME	TYPE	TEXT255
ID	TYPE	INT4
ACCESS	TYPE	CHAR10
SUBFOLDERS	TYPE REF TO	ZFOLDER_TAB

ZFOLDER_TAB

Is a table type of ZFOLDER.

Any better ideas?

cheers Carsten

[amy_king]

Hi Carsten,

Instead of a recursive DDIC structure, you could build your file directory with a recursive subroutine instead. The DDIC structure can be flat and need only have the row's unique ID, its parent's unique ID, and whatever data you want to display in the hierarchy. I did something similar to draw a WBS hierarchy using cl_salv_tree.

*&---------------------------------------------------------------------*
 *&      Form  DRAW_TREE
 *&---------------------------------------------------------------------*
 form draw_tree
         using iv_parent_id   type salv_de_node_key
                   is_node          type zstructure
                   it_hierarchy    type ztable_of_zstructure.
 
   data: lv_node_key  type salv_de_node_key.
 
   field-symbols: <hier> type zstructure.
 
 * Draw the current node
   perform draw_node
                using    iv_parent_id
                             is_node
                changing lv_node_key.
 
 * Draw all children of the current node by recursively calling
 * the current subroutine
   loop at it_hierarchy assigning <hier>
                                   where parent_id = is_node-id.
     perform draw_tree
                  using lv_node_key
                            <hier>
                            it_hierarchy.
   endloop.
 
 endform.                    " DRAW_TREE
 
 *&---------------------------------------------------------------------*
 *&      Form  DRAW_NODE
 *&---------------------------------------------------------------------*
 form draw_node
         using    iv_parent_id   type salv_de_node_key
                      is_node          type zstructure
         changing xv_key         type salv_de_node_key.
 
   data: lv_label          type lvc_value,
            lo_nodes        type ref to cl_salv_nodes,
            lo_new_node  type ref to cl_salv_node.
 
   lo_nodes = go_tree->get_nodes( ).   " go_tree is type ref to cl_salv_tree 
   lv_label = is_node-description.
 
   try.
       call method lo_nodes->add_node
         exporting
           related_node    = iv_parent_id
           relationship       = cl_gui_column_tree=>relat_last_child
           data_row           = is_node
           collapsed_icon  = is_node-icon
           expanded_icon  = is_node-icon
           row_style           = if_salv_c_tree_style=>default
           text                    = lv_label
         receiving
           node                  = lo_new_node.
 
       xv_key = lo_new_node->get_key( ).
 
     catch cx_root into lo_exception.
       ...
   endtry.
 
 
 endform.                    " DRAW_NODE

Cheers,

Amy

[CarstenKasper]

Hi Amy,

thanks for your input. I suppose the flat table approach you are going is the same that Kumar was talking about with the PARENT column.I am going to give that a try.

Though I am still wondering why I could activate the structure, but not use it in programs.

cheers Carsten

[SuhaSaha]

Hello Carsten,

I tried to replicate your situation. And here are a few observations -

• The program did syntax-check but gave an error during compilation.
• I got an "Update terminated" express document just after the compilation. I checked the document and it directed me to ST22
• ST22 - this finally answers why the compilation fails. ABAP runtime error DDIC_TYPE_RECURSION is raised because of the termination of the SAP Kernel function "GenerateType". Screenshot provided for your ready reference

There are a couple of SAP notes which might interest you -

• Note 1480102 - Recursive DDIC types
• Note 595069 - Recursive check of inconsistent DDIC runtime objects

Let me add the recursive check on the DDIC structure did not give any error either!

Your problem is similar to that of storing data of an IDoc. IDoc segments may be child segments(with lower hierarchy levels) & these child segments may have child segments of their own - pretty similar to your requirement, isn't it? I'll suggest you refer to the structure EDIDD when building yours - perhaps a better way to maintain child-parent relationship!

Hope this helps.

BR,

Suhas

[CarstenKasper]

Thank you for all the investigation effort you put into this!

Just had a look at the EDIDD structure. It seems to me that they to it by a character of length 1000. I think this is not really an option for me.

The first note you give states that structures can be recursive using TYPE REF TO. This leads me to believe that a normal TYPE is not supported. Probably going this way then.

cheers Carsten