Getting metadata for FMs where data structure elements also have structure

[Former Member]

Hi,

I'm sorry if this is a double post, but I added this initially to a thread that was already set to answered, and I'm not sure of the protocol - if there will be any further responses if that is the case, so I'm opening this new threas as well.

I've been using RFC_GET_FUNCTION_INTERFACE and RFC_GET_STRUCTURE_DEFINITION successfully for a number of years, but now I have a problem. Some FMs, like /POSDW/CREATE_TRANSACTIONS_EXT, have parameters that have structures, whose elements also have structure. But RFC_GET_STRUCTURE_DEFINITION does not give a handle to get the structure of a returned data element.

Does anybody know how I can work around this?

[Former Member]

Hi,

I'm sorry if this is a double post, but I added this initially to a thread that was already set to answered, and I'm not sure of the protocol - if there will be any further responses if that is the case, so I'm opening this new threas as well.

I've been using RFC_GET_FUNCTION_INTERFACE and RFC_GET_STRUCTURE_DEFINITION successfully for a number of years, but now I have a problem. Some FMs, like /POSDW/CREATE_TRANSACTIONS_EXT, have parameters that have structures, whose elements also have structure. But RFC_GET_STRUCTURE_DEFINITION does not give a handle to get the structure of a returned data element.

Does anybody know how I can work around this?

[uwe_schieferstein]

Hello Ulf

One possible option is to recursively loop over the records of the FIELDS table which have a "non-flat" ABAPTYPE.

Regards

Uwe

[former_member266380]

Hi,

I think you can use the code similar to the one below...

some of the things not covered in this are

1. all types for which CALL FUNCTION 'RFC_GET_NAMETAB' is not returning result, you can call CALL FUNCTION 'RFC_GET_STRUCTURE_DEFINITION' directly. I have not covered that in this code. Hope this is helps in resolving your issue.

Also, the code is not optimized. So there is some scope for optimization of this code.

REPORT ZTEST_GET_SREUCTURE.

DATA : PARAMS type table of RFC_FUNINT,

ls_params like line of params.

data: NAMETAB type table of X031L,

ls_NAMETAB like line of NAMETAB.

data: FIELDS type table of RFC_FIELDS,

ls_fields like line of fields.

CALL FUNCTION 'RFC_GET_FUNCTION_INTERFACE'

EXPORTING

FUNCNAME = 'fm_test_fm'

TABLES

PARAMS = PARAMS

.

IF SY-SUBRC <> 0.

ENDIF.

loop at params into ls_params.

CALL FUNCTION 'RFC_GET_NAMETAB'

EXPORTING

TABNAME = LS_PARAMS-TABNAME

TABLES

NAMETAB = NAMETAB

.

IF SY-SUBRC <> 0.

ENDIF.

loop at NAMETAB into ls_NAMETAB.

CALL FUNCTION 'RFC_GET_STRUCTURE_DEFINITION'

EXPORTING

TABNAME = LS_NAMETAB-ROLLNAME

TABLES

FIELDS = FIELDS

.

loop at fields into ls_fields.

write: ls_fields-FIELDNAME.

endloop.

endloop.

endloop.

[Former Member]

I should say that I'm calling these RFC functions from the RFC C library with an external program, so I'm not looking to exeute this in an ABAP environment - although the principles are similar.

The last answer, the use of RFC_GET_NAMETAB, gives me the necessary structure reference that RFC_GET_STRUCTURE_DEFINITION does not, thanks for that.

The solution is still rather complex. I need to use RFC_GET_STRUCTURE_DEFINITION to get the structure initially - this is because the table reference found in RFC_GET_FUNCTION_INTERFACE only works with RFC_GET_STRUCTURE_DEFINITION and not RFC_GET_NAMETAB.

Then if I find a secondary structure, then I need to use the table name returned by RFC_GET_STRUCTURE_DEFINITION for an element (which is the parent table name) to input to RFC_GET_NAMETAB. Then the roll name is the name of the secondary structure. This can be input to RFC_GET_STRUCTURE_DEFINITION, etc., and it all can be made to work recursively.

Maybe there is a function somewhere that could be used to cross-reference the table names in a better way, but this works OK for now.