Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How BAPI Tables parameters are passed by reference

Former Member
0 Kudos

Hi Gurus,

I have a genuine doubt regarding BAPI parameters. I would like to point out the genreal rules of bapi like,

1. BAPI parameters should be passed by value. (Because they are rfc fm's. So both systems will be in different servers. This is the normal scenario.)

2. But the tables parameters in BAPI can't be passed by value. Instead they are passed by reference.

3. I know they use some kind of delta mechanism to transfer tables parameters to remote servers.

So gurus I would like to know what exactly happens when a tables parameter is passed. And also I didn't understand the delta mechanism. Kindly guide me.

Thanks in advance,

Jerry Jerome

1 ACCEPTED SOLUTION

Sandra_Rossi
Active Contributor
0 Kudos

You'll see in [SAP Library - RFC - Parameter Handling in Remote Calls|http://help.sap.com/saphelp_nw04s/helpdata/en/22/042551488911d189490000e829fbbd/frameset.htm] that tables are not passed by reference when you use RFC. It also explains the delta.

When you make a remote function call, the system handles parameter transfer differently than it does with local calls.

TABLES parameters

The actual table is transferred, but not the table header. If a table parameter is not specified, an empty table is used in the called function.

The RFC uses a delta managing mechanism to minimize network load during parameter and result passing. Internal ABAP tables can be used as parameters for function module calls. When a function module is called locally, a parameter tables is transferred u201Cby reference". This means that you do not have to create a new local copy. RFC does not support transfer u201Cby referenceu201D. Therefore, the entire table must be transferred back and forth between the RFC client and the RFC server. When the RFC server receives the table entries, it creates a local copy of the internal table. Then only delta information is returned to the RFC client. This information is not returned to the RFC client every time a table operation occurs, however; instead, all collected delta information is passed on at once when the function returns to the client.

The first time a table is passed, it is given an object-ID and registered as a "virtual global table" in the calling system. This registration is kept alive as long as call-backs are possible between calling and called systems. Thus, if multiple call-backs occur, the change-log can be passed back and forth to update the local copy, but the table itself need only be copied once (the first time).

2 REPLIES 2

Sandra_Rossi
Active Contributor
0 Kudos

You'll see in [SAP Library - RFC - Parameter Handling in Remote Calls|http://help.sap.com/saphelp_nw04s/helpdata/en/22/042551488911d189490000e829fbbd/frameset.htm] that tables are not passed by reference when you use RFC. It also explains the delta.

When you make a remote function call, the system handles parameter transfer differently than it does with local calls.

TABLES parameters

The actual table is transferred, but not the table header. If a table parameter is not specified, an empty table is used in the called function.

The RFC uses a delta managing mechanism to minimize network load during parameter and result passing. Internal ABAP tables can be used as parameters for function module calls. When a function module is called locally, a parameter tables is transferred u201Cby reference". This means that you do not have to create a new local copy. RFC does not support transfer u201Cby referenceu201D. Therefore, the entire table must be transferred back and forth between the RFC client and the RFC server. When the RFC server receives the table entries, it creates a local copy of the internal table. Then only delta information is returned to the RFC client. This information is not returned to the RFC client every time a table operation occurs, however; instead, all collected delta information is passed on at once when the function returns to the client.

The first time a table is passed, it is given an object-ID and registered as a "virtual global table" in the calling system. This registration is kept alive as long as call-backs are possible between calling and called systems. Thus, if multiple call-backs occur, the change-log can be passed back and forth to update the local copy, but the table itself need only be copied once (the first time).

Former Member
0 Kudos

hi thanks to everyone...