Diff B/W Normal Function Module & RFC Function Module if u take Export

[Former Member]

Hi all,

1. what is the Difference between Normal Function Module and RFC Function Module , if u take Export parameters as your consideration ?

2. Without SSCR, how do u get Access Key ?

Thanks in advance

Kamalini

[Former Member]

For Export Parameters, please read belwo details:

For normal (non-remote) function modules, if a parameter is not defined like an ABAP Dictionary field, it takes the data type of the actual parameter used at run-time. A remote function module, however, does not have this information available. As a result, all parameter fields for a remote function module must be defined as reference fields, that is, like ABAP Dictionary fields. (This applies to IMPORT, EXPORT, CHANGING and TABLES parameters.)

For character structures or fields, the caller's parameters need not be as long as expected by the called program. When incoming parameters are shorter, RFC simply pads them with blanks. This means that the ABAP Dictionary definition of character parameters need not be exactly the same on the calling and called sides. (However, the caller's parameters may not be longer than expected on the called side).

Below are the differences for TABLES parameter for RFC and Normal FM:

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

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 “by reference". This means that you do not have to create a new local copy. RFC does not support transfer “by reference”. 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).

I hope it helps.

Thanks,

Vibha

Please mark all the useful answers

[Former Member]

hI,

Function modules are routines with a defined interface, supporting optional parameters and labelled exceptions, intended to perform specific tasks encouraging re-use.

Functions that are remotely callable via SAP's proprietary remote function call (RFC) protocol, have additional technical restrictions, primarily that the parameters cannot be changing and/or passed by reference, as previously mentioned. When a function module is marked as RFC-enabled, SAP checks that the function's interface meets the restrictions and also generates an internal stub routine to allow the RFC communication to take place (but we don't really need to know anything about that stub).

When a function module raises an exception, control is passed back to the calling program. When the calling program is an external RFC client, the caller receives only a return code indicating that an application exception was raised and the name of the exception as an upper-case text string. The caller is then responsible for inspecting the exception text to see what kind of error occurred.

Hope this will help.

check these...

https://forums.sdn.sap.com/click.jspa?searchID=173040&messageID=2418218

https://forums.sdn.sap.com/click.jspa?searchID=173040&messageID=2730771

http://www.planetsap.com/RFC.htm

2. Without SSCR, how do u get Access Key ?

ACCESS KEY - First of all its provided by SAP. You can get the key from http://service.sap.com -> SAP SUPPORT PORTAL -> Keys & Requests -> SCCR Keys -> Registration. Here u can register a DEVELOPER or an OBJECT, by this time SAP will give the ACCESS KEYS.

**Note : To access http://service.sap.com u should have S number login or like that.

Only after obtaining that ACCESS KEY, SAP will allow the DEVELOPER to create some objects or change or modify Delivered objects.

Why ACCESS KEY - For creating or accessing any object some one should be responsible. Suppose, any issue arises with an object then can easily track the details who has created or modified.

there r 2 kind of keys

1) developer key (which allows u to create ,change Z programs

2) Access Key ,which is required to change SAP standard codes

To be able to change programs, programmers must be assigned a "Developer Key". This is linked to the user's id.

To change a standard SAP object (eg Function Module) you will be asked for an Access Key. You get this key from OSS. It allows SAP to keep a track of which standard objects you modify.

You will need to log onto OSS and register this object. Once you do this, you will be given the Access Key. no other way.

Regards

Kiran Sure

[Former Member]

Hi,

RFC is also a functional module but it is remote enabled that is from one system you can execute the RFC in another system. For this the radio button RFC in attributes column of the FM should be enabled.

In RFC parameters are only pass by value and there is no pass by reference parameter in RFC.

Function modules are routines with a defined interface. They support optional parameters intended to perform specific tasks encouraging re-use.

If u have a FM which is not RFC enabled, then you can copy this function module into your own ZFM and make it RFC enabled.

Hope this is helpful.

Reward points if useful.

Thanks.