Purpose
Using "Classic RFC" vs. using "Netweaver RFC" in GuiXT

Background
Two different Remote Function Call (RFC) protocols are available in current SAP systems

  • Classic RFC
  • NWRFC (Netweaver RFC)

NWRFC is the newer one. The official SAP support for Classic RFC ended in 2016, although the interface is still contained in all SAP kernel versions including the latest S4HANA systems (as of 2018).

Changing a C-program from the Classic RFC interface to NWRFC is not an easy task, since NWRFC takes a rather different approach which is based on metadata (function interface and dictionary structure info), making a true re-programming and testing necessary.

GuiXT supports both Classic RFC and NWRFC, without making any script changes necessary. If Classic RFC is available (technically: "librfc32.dll" can be loaded), GuiXT uses Classic RFC, otherwise NWRFC.  If you do not want to rely on this automatism you can specify


N
WRFC  Yes
or

NWRFC No

i
n "guixt.ini".

F
or all SAP GUI versions prior to and including SAP GUI 7.50 PL2, "librfc32.dll" was part of the SAP GUI installation. With PL3 of SAP GUI 7.50 the "librfc32.dll" is actually removed from the PC.

If you want to stay with Classic RFC in GuiXT even with SAP GUI 7.50 PL3 and above, you may copy "librfc32.dll" into one of the folders on the PC where it can be loaded from.

In 64 Bit Windows:

  • C:\Program Files (x86)\SAP\FrontEnd\SAPgui
  • C:\Windows\SysWOW64

For your convenience, if "librfc32.dll" is not found in a local folder, GuiXT tries to load it from the script folders, including SAP Web Repository and SAP Mime Repository. This makes it possible to store "librfc32.dll" at a central place, like the scripts, given that you want to use Classic RFC for all GuiXT users. For loading "librfc32.dll" from a script folder you need GuiXT version 2018 Q1 2 or above.

 

Performance considerations

When a function is called up the first time in a process, NWRFC reads the corresponding metadata: the function interface and the dictionary structures for all parameters. The metadata are read by the NWRFC layer on the caller side, using one RFC call "RFC_GET_FUNCTION_INTERFACE" and possibly many calls "DDIF_FIELDINFO_GET". The metadata are then cached in the process. So if a user does not completely close SAP GUI the calls are as fast as Classic RFC, but each first call after starting SAP GUI can take a couple of seconds.

Here are some figures for the function "BAPI_USER_GET_DETAIL":

RFC via a LAN connection, first call takes around 2 seconds. Please note that the first call to a different function will again need new metadata.
 

The same Call in a new SAP GUI mode, same SAP GUI process. Even the first call is now fast.

 

Here via Internet connection to a different SAP system. The metadata are read again, which takes 5 seconds this time.

An RFC trace ( transaction ST01) shows that many metadata calls are executed the first time a script calls "BAPI_USER_GET_DETAIL":


   ... (more)

 

Classic RFC does not show this overhead, since no metadata are needed on the client side.

 

The internet access with Classic RFC show she same behaviour, i.e. there is no big delay for the first call.

 

User authorizations

With NWRFC you need to give the users the authorization to read the function interface and the dictionary structures, in addition to the authorizations for the function that you are calling.

Here is the protocol from transaction STAUTHTRACE:

For Classic RFC the user only needs the authorizations for the function that is called up in the script:


Recommendation

In the long run it will become necessary to use NWRFC due to the end of support situation for Classic RFC. Maybe we will see some performance improvements for NWRFC in the future concerning metadata caching outside of the process.

At present it remains an option to stay with Classic RFC for a while, especially if you call up several different functions in your scripts and expect that the users do not let the SAP GUI process on over night.

Components
GuiXT