Table statement Obslete while using FM

[Former Member]

Hi Experts,

While creating Function Module I am aware that use of table statement is obslete in ECC 6.

But I want to know the reason behind it.

I am creating a FM for an Inbound FM. Just wanted to know if the Use of table parameter affect it in future.

Thanks an advance!!!

[naimesh_patel]

By using the TABLES parameters, you are creating the table with the HEADER LINE. So, from your program / FM / method if you pass the internal table without the header line, it would create a empty header line while processing the FM.

Even though this is just the warning, I would suggest to use the IMPORTING / CHANGING parameters instead of the TABLES. You can create a Table Type for your structure and use it as the types to define this parameter.

From the message long text of "TABLES Parameters are obsolete.

TABLES parameters are table parameters. Table parameters are obsolete CHANGING parameters that are typed as internal standard tables with a header line. If an internal table without a header line or a table body is passed as an actual parameter to such a formal parameter, an empty header line is generated in the function module. If an internal table with a header line is used as an actual parameter, both the table body and the header line are passed to the function module. In the case of formal parameters defined with TABLES, no value transmission is possible.
Formal parameters defined with TABLES can be replaced by formal parameters defined with CHANGING. A local work area can be created in the function module  for the internal table using the addition LIKE LINE OF itab of the DATA statement in the function module.

Regards,

Naimesh Patel

[SuhaSaha]

Hello Naimesh,

But AFAIK you cannot use table types in RFC enabled FMs

Any ideas why this is so? Ever since i have encountered this problem, i have been wondering "why" ?

BR,

Suhas

[Former Member]

Hi Naimesh,

I understand why we do not use table parameter in a Function Module.

But my question is regarding the FM used for processing inbound IDOC Function module.

For a inbound FM we use a constant parameter structure, in case we go for a change by use of Changing parametrs we will have to handle the same in the code inside FM.

Please advice if this change is recommended.

Thanks

[naimesh_patel]

For the inbound FM, which you create in the process code needs to be created with the TABLES parameter only. Because ALE framework calls this FM dynamically with passing the TABLES parameters. Bun inside your Inbound FM, if you create another FM than use the IMPORTING / CHANGING parameters instead of the TABLES.

Regards,

Naimesh Patel

[naimesh_patel]

Yes, I came across this problem before. If I recollect clearly, system has the problem with the structures which are not flat i.e. Deep or nested.

I guess, by using the TALBES parameters system knows how much memory it has to allocate where as the table type needs no initial memory. If you try to use the STRING parameter also in RFC, system would complain.

Regards,

Naimesh Patel

[SuhaSaha]

Hello Naimesh,

If you try to use the STRING parameter also in RFC, system would complain

Bingo !!

I was complaining & cursing SAP that day for not allowing to pass string to RFCs. Your explanation regarding memory allocation sounds good. But why does this have to be restricted to RFCs only?

Cheers,

Suhas

[naimesh_patel]

Your explanation regarding memory allocation sounds good. But why does this have to be restricted to RFCs only?

May be inside SAP, system knows the memory allocated to that variable and it doesn't have to send / receive that chunk over the network.

Regards

Naimesh Patel

[Clemenss]

Hi Suhas,

who told you that you cannot use table types in RFC enabled FMs?

We do exactly this without facing any problems.

Regards,

Clemens

[Former Member]

Hi Namesh,

Thanks for your explanation about the inbound FM using tables.

This is exactly wat I was looking for.

I willl continue using the "Tables Parameters" while creating the inbound Function Module using Process code but restrict to use then in case of any other custom FM developed.

[Former Member]

Hello Clemens,

Thats right. Even we created RFC enabled function modules using table types without any problem, though our version was 4.6c. Not exactly sure if it causes any problems in the ECC versions

Vikranth

[SuhaSaha]

Hello Clemens,

Try creating an RFC using a table type, it will not allow you to activate the FM (although it does not give you an error message). FYI i am in ECC5.0.

@Naimesh: I tried creating an importing param in an RFC using a tably type, i get this info message: "Parameter XXX(type XXX) can reduce performance in RFC".

BR,

Suhas

[naimesh_patel]

Yes Suhas, it gives us the warning as a information message when we try to use the Deep / nested data types in RFC. Check the long text of this message.

Regards,

Naimesh Patel