topic dynamic method call over RFC function module in Application Development and Automation Discussions

dynamic method call over RFC function module

Former Member — Wed, 04 Apr 2012 11:26:42 GMT

Hello!

this is my first post ever, so please be gentle with me

i have the following question:

i want to create a function module, which is RFC-able and all it should do is import the method name which i will call dynamically and the parameter table which is necessary to call the method with the correct parameters.

defining the method name as an importing parameter type string for the function module is possible, so whenever the user choses to e.g. press the button logon i will import the proper method name (e.g. LOGON).

2nd i need the parameters which is of type abap_parmbind_tab and here the system (in the SE37) cries that generic types are not allowed for RFC function modules and i have absoluteley no idea of how i can fix this matter.

so in short: is it in general possible to create such a RFC function module which will call dynamically the method + the correct parameters via abap_parmbind_tab?

thanks a lot in advance,

dominik

Re: dynamic method call over RFC function module

Private_Member_49934 — Wed, 04 Apr 2012 12:20:12 GMT

Hi Dominik,

I really liked your idea

I think in your case it won't be possible to include abap_parmbind_tab type parameters.

VALUE of the type REF TO DATA. And references are not allowed in RFC FMs.

What I think can be done.

1) get the list of all the methods which are wrapping in the RFC FM.

2) add all the parameter of all the method in you FM interface ( Nor referecne type )

3) In the FM based on the FM name passed populate the local variables ABAP_PARMBIND_TAB and make the dynamic call

Re: dynamic method call over RFC function module

matt — Wed, 04 Apr 2012 12:54:47 GMT

I've done exactly what you required, and encountered the same problem. To resolve it I converted the value into hexadecimal before calling the RFC. Within the RFC, I convert the hex value back to whatever type the parameter requires.

Re: dynamic method call over RFC function module

matt — Thu, 05 Apr 2012 13:59:10 GMT

I was wrong. This is what you need: cl_abap_container_utilities=>fill_container_c

It returns a string, and then you have to convert that into a table of fixed length characters, so you can rebuild the string at the other end, and then use read_container_c to recover that data. Which could even be a structure or a table..

Re: dynamic method call over RFC function module

SuhaSaha — Thu, 05 Apr 2012 15:31:44 GMT

Hello,

I think this is a problem every developer has to face when he/she tries to use dynamic elements with RFC!

Matthew Billingham wrote:
  ... you have to convert that into a table of fixed length characters, so you can rebuild the string at the other end ...

Imo defining the return table of "fixed length characters" will always be a problem - something i faced a few weeks back

BR,

Suhas

Re: dynamic method call over RFC function module

matt — Fri, 06 Apr 2012 07:01:05 GMT

Not a problem.

You've converted your data into a string. You cut the string into, say, 256 character portions, so it'll fit into a table of CHAR256. For the last slice, you record how many bytes of the field are actually used.

I.e. assume your string is 'abcdefghijklm', and your table is CHAR8. Then you end up with

abcdefgh

ijklm

To recover the string, you just need the table with these chars, and 5, so you get the length of the string right. This is pretty much the same as what's done for sending binary data as MIME.

Believe me, it works - I've done it! (I should say that using cl_abap_container_utilities was Otto Gold's idea.).

matt

Re: dynamic method call over RFC function module

Former Member — Mon, 04 Jun 2012 12:11:39 GMT

just wanted to finish my thread off. maybe it is helpful for others.

what we have done is following:

created a RFC FM.
only purpose is to pass the import parameters through to another FM which is representing our 'Main' Function.
there we unwrap our import parameters and call the proper methods.

it may sound a little bit 'dirty' but a big advantage is that we do not have to deploy the RFC all the time whenever we change something in it.

i do not know how much performance we will lose with this - if you are interested i can set up some measurements (which i will be able to do in 2 weeks).

Re: dynamic method call over RFC function module

OttoGold — Tue, 09 Oct 2012 12:39:26 GMT

Hi , friends,

I am afraid that I must confirm the problem with the fixed length. I learnt the hard way (one of the tools I`ve built does not work over RFC at one of our customers despite the fact it worked just fine on my internal systems). I am researching the problem now and to me the XML option (CALL TRANSFORMATION ID) sounds like the best thing we can do.

I am sorry for misleading recommendation, Matt, the container operation thing is not safe.

Hope this helps other people too, I have seen tons of questions about the topic in last hours.

For further information about the XML option I recommend and the contribution and the feedback thread:

http://scn.sap.com/thread/53916

http://scn.sap.com/docs/DOC-10106

I haven`t tested it in production environment yet, but originally used the string container for "any structure" and some structures just didn`t work out.

Cheers Otto

Re: dynamic method call over RFC function module

Former Member — Wed, 10 Oct 2012 17:25:48 GMT

Hello Dominik,

I know its not nice to re open a closed discussion. But, since you are calling methods dynamically and your RFC is generic, how would you handle object instantiation?. Some objects might implement a singleton, others may not, would this not be an issue?.

Please do correct me if I am getting wrong somewhere.

Thanks,

Venkat.

Re: dynamic method call over RFC function module

Former Member — Wed, 10 Oct 2012 20:03:11 GMT

only purpose is to pass the import parameters through to another FM which is representing our 'Main' Function.

Ok , So I missed this point. So you would be creating another FM where the actual object instantiation and the method call would happen. This FM would be application specific I would assume. It would be more like "An Object - message interface".- Sort of theoretical OO programming, where Objects listen and react to messages .

Thanks,

Venkat.

Re: dynamic method call over RFC function module

matt — Fri, 19 Oct 2012 08:28:08 GMT

So why doesn't it work at your customer? I've used the same technique with one of my clients and it is fine. I'm taking a standard table with records comprising flat fields. I don't know its structure until runttime, but need to pass the data to an RFC FM (along with the typing information).

I've a container structure defined in the data dictionary:

RECORD_NUMBER INT4

COMPONENT_NUMBER INT4

CHAR_REC_NUMBER INT4

CHAR_DATA CHAR255

RECORD_LENGTH INT4

Then I use this code where <t_data> is a generic table and <s_data> is type any, but is a non-deep structure:

ls_container is type the container structure, and lt_container is a standard table of it.

* Convert each line to a string, then convert into the container format
LOOP AT <t_data> ASSIGNING <s_data>.
    ls_container-record_number = sy-tabix.
    DO.
      ls_container-component_number = sy-index.

      ASSIGN COMPONENT ls_container-component_number OF STRUCTURE <s_data> TO <field>.
      IF sy-subrc IS NOT INITIAL.
        EXIT.
      ENDIF.
      cl_abap_container_utilities=>fill_container_c( EXPORTING im_value = <field> IMPORTING ex_container = l_converted ).

      DO.
        ls_container-char_rec_number = sy-index.
        l_len = STRLEN( l_converted ).
        IF l_len LT c_container_width.
          ls_container-record_length = l_len.
          ls_container-char_data = l_converted.
          INSERT ls_container INTO TABLE lt_container.
          EXIT.
        ENDIF.

        ls_container-record_length = c_container_width.
        ls_container-char_data = l_converted(c_container_width).
        INSERT ls_container INTO TABLE lt_container.

        l_converted = l_converted+c_container_width.
        IF l_converted IS INITIAL.
          EXIT.
        ENDIF.
      ENDDO.
    ENDDO.
ENDLOOP.

At the receiving end, I decode it_data - which is my table of the container structure type. l_record is a string.

* Convert the data from the interface into the right format
sort it_data by record_number component_number char_rec_number.
loop at it_data into ls_data.
    if ls_data-record_length gt 0.
      concatenate l_record ls_data-char_data(ls_data-record_length) into l_record.
    endif.

    at end of component_number. " New component
      assign component ls_data-component_number of structure <s_outdata> to <field>.
      cl_abap_container_utilities=>read_container_c( exporting im_container = l_record
                                                     importing ex_value = <field> ).
      clear l_record.
    endat.

    at end of record_number.
      insert <s_outdata> into table <t_outdata>.
    endat.

endloop.

<t_outdata> is a table of the same structure as <t_data>. (likewise <s_outdata> and <s_data> ).