Skip to Content

New developments in Netweaver RFC communication


During the last one or two years, a couple of new features have been added to the RFC communication protocol. In this blog I will describeย  for which release they were added to the SAP kernel, and how they can be used by external programs, with a focus on the NetWeaver RFC Library, which is going to support these new features starting with release 7.20. Development of that library is getting started now, so this blog will continuously grow as we go along.

Background Communication (bgRFC)

The standard qRFC protocol has a couple of shortcomings like a high/aggressive usage of resources (work processes), a danger of running into deadlocks when queues become blocked and a certain inflexibility that makes it difficult to use for a wide variety of scenarios. (In fact in the past qRFC has been “mis-used” for quite a number of use cases for which it was not designed, leading to problems like performance bottlenecks, resource starvation, deadlocks.)

To overcome these shortcomings, a new kind of asynchronous RFC communication has been developed in SAP kernel 7.10, which provides the semantics for executing logical units of work “exactly once” or “exactly once in order”: the so-called bgRFC protocol. With enhancement pack 2, bgRFC is planned to be downported to SAP kernel 7.01, and starting with NW RFC Library release 7.20 external programs will also be able to use it.

Class-Based Exceptions

Starting with SAP kernel 7.10, remote-enabled function modules may throw “real” ABAP OO exceptions instead of the well-known classic exceptions. A remote system can catch these exception objects and query their attributes. (Remotely invoking the exception object’s methods is not yet possible, however. That will be a next step in the direction of a true “remote method invocation concept”.)

The NW RFC Library 7.20 will also enable external C programs to catch these ABAP exception objects and query their attributes (if the external program is the client) or to create an exception and throw it back to the ABAP system (if the external program is the server).

Communication via basXML

Another feature of the 7.10 kernel is communication via a new serialization format, basXML. It was meant to provide a more efficient and unified format for function modules that use many complex and nested structures and tables as their importing and exporting parameters. If a function module specifies in its attributes, that it wants to use basXML serialization, and if that feature is available on both communication partners (a switch in the RFC destination in SM59 is necessary here), then the complete payload will be serialized in the new format.

The NW RFC Library already supports this format right from the first release 7.10. You as the application programmer should not notice much of a difference here, as this is handled “under the hood”. The only noticable difference should be a slight change in performance: slightly worse performance, if the function module in question has only standard “flat” parameters (in this case basXML should be turned off), and slightly better performance for function modules with many complex parameters.

Update on recent features

Meanwhile the first two patch levels of NW RFC SDK 7.20 have been released to public, and they brought quite a number of fixes and improvements. A complete list is given in the notes 1511382 and 1511433. Here I just want to highlight a few features which I think will be very beneficial for RFC applications.

Performance improvement for DDIC lookups in the backend.

In previous releases, an external program had to perform one roundtrip for every function module plus one additional roundtrip for each structure/table that this function module was referencing. If a program is using 5 different FMs with 10 structures/tables each, this sums up to 50 roundtrips to the backend, which costs a substantial amount of time during initialization of the program. In long running processes, which look up their metadata once in the beginning and then use it for days or even weeks, this is not a problem. However, in short-lived processes, which are started quite often, perform only a handful of RFC calls and then die again, this overhead can cost more execution time than the actual “business logic”.

To improve this situation, there is now a new DDIC lookup FM on ABAP side (RFC_METADATA_GET) and a new set of functions in the NW RFC library, which leverages this FM (RfcMetadataBatchQuery plus a few helper functions for iterating through the result set of the batch query). Using this function, you can lookup all DDIC definitions for all function modules/structures and tables that your program may need during its lifetime with one single roundtrip to the backend. See SAP note 1456826 for the prerequisites on ABAP side, and the doxygen documentation of RfcMetadataBatchQuery for how to use this feature.

For very short-lived processes that are started thousends of times in short order, even the above process might be too slow. These programs then should not lookup their metadata in the backend, but hard-code it internally instead, using the set of APIs around RfcCreateFunctionDesc,RfcCreateTypeDesc and RfcAddFunctionDesc.

Index-based access to structure/table/function module fields

Like in JCo and NCo you can now set and get field and parameter values by index instead of by name. This should be quite a performance improvement, if you have loops over big tables, where thousends of fields need to be accessed.

Information about the type of an incoming RFC call

Using the function RfcGetServerContext, you can now access some important information from inside your currently executing server function (function of type RFC_SERVER_FUNCTION): you can see, whether you are currently running in the context of a synchronous RFC call, a tRFC/qRFC or a bgRFC. In the later cases you will also get access to the TID or the Unit ID. This should make it much easier to write multi-threaded server programs that can handle tRFC/qRFC/bgRFC in such a way that they preserve “transactional security” (i.e. execution once and only once).

For example: the RFC_ON_COMMIT_TRANSACTION function needs to perform a database “commit work” exactly for the data belonging to the current TID. But in order to do this, the RFC_SERVER_FUNCTION(s) must already store the TID together with the data that it wrote into the database (or get access to the current DB connection corresponding to the current TID). Previously an RFC_SERVER_FUNCTION had no access to the current TID, so this was very difficult to achieve. (E.g. by having the RFC_ON_CHECK_TRANSACTION store the TID in thread-local storage or in a global hasmap, from where the RFC_SERVER_FUNCTION(s) could then get it. With the new RfcGetServerContext function it is now very easy to make the link-up between the current TID and the corresponding data payload processed in the various RFC_SERVER_FUNCTIONs.

More general information

Some people found the following articles about the concepts of NW RFC programming quite useful. Therefore I provide a reference to them here:


Part I — RFC Client Programming

Part II — RFC Server Programming

Part III — Advanced Topics

You must be Logged on to comment or reply to a post.
  • Great news. Will we see a JCo wrapper for it? Can bgRFC be used instead of tRFC? Is there also some work done in the area of (native) memory consumption when receiving IDOCs via JCO?

    BTW: is it planned to directly deliver XML IDocs?

    • Hello Bernd,

      > Will we see a JCo wrapper for it?
      In fact, there already is one: JCo 3.0 was released in July 08, and it supports basically the same features as the NetWeaver RFC SDK.

      Or let me be more precise: JCo 2.x had been a wrapper around the classic RFC Library, but JCo 3.0 is not a wrapper around the NW RFC Library! It’s a wrapper directly around the CPIC Library, all the “RFC stuff” is now done directly in Java. The main reason for this was: in the old (2.1) model the Function/IDoc data first needed to be created in Java, then it was passed to the RFC Library via JNI (so there was a second copy of the data in native memory) and finally it was serialized and written to the CPIC socket. Now in the new model (3.0) the Function/IDoc data is created in Java (as before), then serialized in Java and passed to the CPIC Library via JNI. That means the only native memory needed, is a 28K buffer, which receives a chunk of serialized data and writes it into the CPIC socket! This should be a huge performance improvement — and I think this answers you third question… ๐Ÿ™‚ A JCo 3.0 application will only need 28K of native memory per connection, no matter how big the IDoc (or function module) is.

      > Can bgRFC be used instead of tRFC?
      bgRFC will come in two variants: a type ‘T’ variant providing similar behaviour as tRFC and a type ‘Q’ variant, which is similar to the existing qRFC. As I said, the main reasons for introducing yet another protocol that is providing identical functionality of the existing tRFC/qRFC protocols were performance reasons on backend side. I.e. better scheduling algorithms and better resource (work process) management.

      > BTW: is it planned to directly deliver XML IDocs?
      No, currently only the SAP Business Connector is able to process XML IDocs out-of-the-box.

      Best Regards, Ulrich

  • Hey,

    I’ve played around several hours with the netweaver rfc sdk and I’m quite happy with it.

    Unluckily we need to use GUI-based transactions like CDESK or bapi_document_checkoutview and the parameter USE_SAPGUI=1 leads to the error SYSTEM_PREPARE_ATTACH_GUI not found (while connecting to ECC 6.0).

    I found SAP-Note 1258724 which adresses that topic and promises a solution with upcoming support packages.

    Astonishingly I can find a support packages for basis-releases 620 (SP 66), 701 and 710 but nothing for 700.

    1) is it correct that there is currently no release I can connect with NetWeaver RFC SDK w. GUI to?
    2) Will it be possible with 4.7 SP66 at 18.05.2009 (Release schedule for SP66)?
    3) Are there any plans to provide support packages for 700 too?

    I appreciate any answer as we currently need to decide which technology to use for a new project.

    Best Regards,


    • Hello Michael,
      I talked to the corresponding developer on ABAP side, and the situation is as follows:

      1) Yes, unfortunately we need to wait until the corresponding correction on backend side “has seen the light of day”, before the feature can be used.
      However, if you are concerned only about BAPI_DOCUMENT_CHECKOUTVIEW, I can perhaps give you an alternative solution: there is another function module CVAPI_DOC_CHECKOUTVIEW, which provides the same functionality and does not require a SAPGui, so that one would be better suited for external C/Java based applications!

      2) Enterprise 4.7 is based on SAP_BASIS 6.20, so the support package SAPKB62066, which is mentioned in note 1258724, can be used.

      3) The correction will also be made in releases 6.40 and 7.00, but the exact support package number, which will include it, is not yet known. It’s either the next or the one after the next. The note will be updated accordingly, once we know the schedule.

      Best Regards, Ulrich

      • Well, meanwhile all necessary support packages for using “RFC with SAPGui” have been released, so I thought I might update this post with the details:

        SAP_BASIS     46C     SAPKB46C58
        SAP_BASIS     620     SAPKB62066
        SAP_BASIS     640     SAPKB64025
        SAP_BASIS     700     SAPKB70020
        SAP_BASIS     701     SAPKB70103
        SAP_BASIS     710     SAPKB71008
        SAP_BASIS     711     SAPKB71102

        Regards, Ulrich

        • Hi Ulrich,

          I found the support packages some weeks ago and we already started some development.

          Thanks a lot for your help and support I’m really glad to see ppl like you @ SAP.

  • I met a problem with NW RFC SDK 7.11 when using RFCGetFunctionDesc to access a ABAP which is defined by myself. I used to access this function with RFC classic SDK successfully, however, when i use NW RFC SDK and use RFCGetFunctionDesc to access this ABAP function, it returns the “RFC_INVALID_PARAMETER” and with error message “inconsistence in description detected: non-unicode length is too small”. And My application can retrieve the function Description handle of other ABAP functions, I’m wondering if it’s a bug in NW RFC SDK

    I search the network and found someone has the same problem:

    Best Regards

    • Hello Ryan,
      > I’m wondering if it’s a bug in NW RFC SDK

      Not necessarily… In the other case you mentioned it turned out to be an inconsistency in the backend’s DDIC. So first you should try and search in that direction as well. Try to pinpoint which structure is causing that error (e.g. you could make a copy of that function module and then one by one delete all structures/tables from it, until the error disappears). Then take a close look at this structure in SE11 and check, whether you can see anything that’s broken. (If it’s a SAP structure, just open an OSS message under the corresponding application component. They will definitely cooperate with us in finding the problem, and you’ll get a patch, either of the structure definition on backend side, or of the NW RFC SDK…)

      If you are sure the structure is ok, open a message under BC-MID-RFC providing the exact structure definition, so we can debug it over here…

      Best Regards, Ulrich

      • Hello Ryan,
        if you have not made any further progress in this matter in the meantime, it may be worth trying the latest patch level 2: two more bugs in the DDIC lookup functions have indeed been found in the NW RFC SDK. See note 1278062, points 5 and 6.

        Regards, Ulrich

  • SAPNWRFC.DLL version 7110.17.5.39063 / SAP 6.40 – Unicode / Windows Xp
    When using function RfcInstallGenericServerFunction the callback
    RFC_FUNC_DESC_CALLBACK is called with RFC_ATTRIBUTES as one of the parameters. In the structure RFC_ATTRIBUTES the field cpicConvId is set wrongly.
    Question: Can anyone try this and tell me if they have the same issue ? (remark when using RfcGetConnectionAttributes on a client connection the field is set with a correct value).
    • Hi Alex,
      no, the classic RFC SDK will be discontinued in a couple of years, so you shouldn’t start new projects with it…

      The NetWeaver RFC SDK supports all backends down to R/3 4.0B. (Support for R/3 3.1I and for R/2 systems has been removed, so if you still need to communicate with any of those, you’ll have to use the classic SDK… But I doubt that any 3.1I or R/2 system is still running productively today?!)

      Regards, Ulrich

    • Hi Menelaos,
      I’m not exactly sure, but I think your problem is the following:

      >  repr(g.encode(‘utf8’)) -> “‘\\xce\\xb1\\xce\\xb2\\xce\\xb3′” (6 characters)

      No, it’s not “6 characters”, it’s “6 bytes”! (But only 3 characters: one Greek character is represented as 2 bytes in UTF-8. Perhaps for some strange reason Python interpretes each byte as a separate char and this is the reason, why we get the “string too long error”.

      I checked the binary representation of your UTF-8 data, and it is 100% ok: “UTF-8 CE B1 CE B2 CE B3” represents the same Greek characters as “UCS2 03B1 03B2 03B3” (alpha beta gamma). Therefore I think the problem must either be at the point where you pass the data to Python (I have no idea about Python, so I don’t know how this works and if something can go wrong here) or at the point where Piers’ connector converts the data from UTF-8 to wchar_t and passes it down to the NW RFC library.
      In any case I think we also need to involve Piers here, because if I write a plain C program and pass 10 Greek characters to RfcSetChars(), it works ok.

      Regards, Ulrich

  • Hi

    Do not know if this is correct place, Apologize if this is not proper place to post but did not find correct forum.

    We have C++ code that uses netweaver rfc library to call BAPI (“WS_DELIVERY_UPDATE_2”), with exact same data netweaver library call fails, but SE37 works. Call made with RFC library fails with “RfcInvoke to SAP has returned an error, Group ‘2’: Code ‘3’: Key ‘DBIF_RSQL_INTERNAL_ERROR’: Message ‘Internal error when accessing a table.”

    Stepped through debug in SE37 and using SAPGUI (when called from RFC lib) input data looks identical in both cases. Any pointers on where to look?

    Thanks in advance.

    • Hi Rakesh,
      this doesn’t look like an RFC related issue. The backend shortdumps with an SQL error. No idea why this happens only when calling the function module via RFC?!

      I guess the first step ought to be to find out, what the database is complaining about. The shortdump details should be in ST22. After we know *what* goes wrong, we can perhaps find the reason *why* it goes wrong.

      In any case, are you absolutely sure the inputs are identical? Usually if something works in SE37, but not via RFC, then the reason is one of those listed in my note 206068 (here perhaps point 2: inputs changed by a conversion exit?!)

      Also: user authorizations are the same in both cases?!

      Best Regards, Ulrich

      • Hi Ulrich

        Thanks for responding.

        – I ran both instances (SE37 and lib call) side by side and checked all input parameters to RFC and made sure they are same

        – ST22 indicates problem with invalid sign in BCD

        C  invalid sign in BCD number: 0
        C  Error converting decimal:  000000000000.000 HEX: 0000000000000000 input variable# 25, proc: ##Y4ECC60js50000003900000005597717495
        C  internal error in decimal conversion.
        B  ***LOG BZY=> unexpected return code 8          calling DbSl      [dbtran#14 @ 7617] [dbtran  7617 ]
        B  dbtran ERROR LOG (hdl_dbsl_error): DbSl ‘INS’
        B  RSLT: {dbsl=8, tran=4}
        B  FHDR: {tab=’VBFA’, fcode=130, mode=1, bpb=0, dbcnt=0, crsr=0,
        B          hold=0, keep=1, xfer=1, pkg=0, upto=0, init:b=0,
        B          init:p=00000000, init:#=0, wa:p=00000000, wa:#=392}
        B  dbtran ERROR LOG (hdl_dbsl_error): DbSl ‘INS’
        B  STMT: {stmt:#=0, bndfld:#=0, prop=0x45, distinct=0, select*=1,
        B          fld:#=41, alias:p=00000000, fupd:#=0, tab:#=0, where:#=0,
        B          groupby:#=0, having:#=0, order:#=0, primary=0, hint:#=0}
        B  CRSR: {tab=”, id=0, hold=0, prop=0x4,, fae:blk=0,
        B          con:id=0, con:vndr=9, val=2,
        B          key:#=6, xfer=1, xin:#=4, row:#=0, upto=0, wa:p=0X52E1CCF8}

        But when I check the data (from DB_XVBFAI) at point of insertion (just before failure occurs) in ABAB, the data again is identical. I copied data off to excel sheet if you want to take a look.

        – Authorizations are exactly same (same user)


      • Hello Ulrich

        Here an update, the problem goes away if a optional field that has default value is explicitly set before call (in C++). Wondering if you can shed light on how to handle optional BCD fields (and is it something to do with ‘conversion exit’ you referenced earlier?)

        Because shortdump indicated problem with BCD sign, I focused on all BCD fields in call.

        There is one field in a table (VBPOK->VOLUM) that has default value of ‘0.000’ defined and it is optional.

        It is was not being populated (explicitly in C++) before the call. When looking at data in ABAP debugger the data shows up as follows: Pay attention to HEX representation (single quotes around data are mine)

        When called from SE37
            [Default picked up by SE37]
            ‘0.000’ -> HEX ‘000000000000000C’

        When called from C++, with field **not populated** before call, but default picked up RFC library
            ‘0.000’ -> HEX ‘0000000000000000’

        When called from C++, with field **populated** with default value of ‘0.000’ before call:
            ‘0.000’ -> Hex ‘000000000000000C’

        In all cases non-HEX data shows up same ‘0.000’ in debugger, but HEX representation has “C” (presumably sign) in end or not.

        The questions is:

        Why should field need explicit default value populated in C++ to make “C” appear in HEX and fix problem in ABAP? Is focus on “C” in value red herring? 

        All other default HEX fields are behaving same but did not need to be populated to get around my specific issue.


        • Hello Rakesh,
          I must say: excellent work so far! So the problem seems indeed to be caused by the NW RFC lib setting an incorrect initial value for BCD fields.

          The BCD standard (see for example requires that the last nibble of the number needs to be the “sign”, where 0xC represents “+” and 0xD represents “-“. Having an initial value of all 0x00 is therefore invalid.

          The ABAP runtime apparently accepts this invalid value anyway and works ok with it, but lateron your database insists on the correct format.

          First question: are you using the latest version (7.11, Patch Level 5)? I remember that there have been a few patches for BCD-handling a while ago, in PL 2 as well is in 3. See for example SAP note 1359377, point 4. (Yes, I always refer to the “standard SAP notes”, that can be found under

          If you have the latest version, I’ll make a patch for this next week. Could you open an OSS message under BC-MID-RFC for this?

          In the meantime the workaround of explicitly setting the value should be ok. (Apparently the BCD-handler encodes “0.0” correctly, the problem is only that this handler is not applied when initializing the fields of the structure to zero.)

          Thanks and best Regards, Ulrich

          • Hello Ulrich

            Thanks for explanation.

            I do think I am using latest version. When I look at properties for sapnwrfc.dll, the
            ‘File Version’ is ‘7110.59.16.53218’ and
            ‘Product version’ is ‘711, patch 59, changelist 1101794’.

            So is that 7.11, Patch Level 5? Let me know if it latest version or not then I can open OSS message.


          • Hi Rakesh,
            PL 5 has this version:
            but I checked the code, and the problem is still in the latest version. I started creating a patch now. If you open an OSS message, I can give you a beta version for testing.

            Regards, Ulrich

    • The patch for the BCD sign bug has just been released to SAP Marketplace. See SAP note 1409906 for a list of all fixes contained in the patch.

      Best Regards, Ulrich

  • Hi Ulrich

    I am trying to code external server program, am using RfcRegisterServer() to register call, I receive calls well and good. If I get a network error (simulated by disconnecting client from network) the RfcListenAndDispatch() returns “RFC_COMMUNICATION_FAILURE”, so I re-register using RfcRegisterServer. The registration is successful (if network connectivity is established).

    At this point on SAP system, (using SMGW, “Goto->Logged on Clients”) I find that there is more then one registration for my external server program. One from before communication error and one from after. I tried calling RfcCloseConnection usin old handle to get rid of first registration (before communication error)  but that does not accomplish

    In classic RFC SDK there used to be call “RfcCancelRegisterServer” that de-registers all external server registrations based on name. I cannot find similar call in new library. Is there such a function?

    If not what is process to make sure none of older registrations (in SAP) linger around once network connectivity is lost?

    Thanks in advance for any pointers

    • Hello Rakesh,
      first of all, we had removed the API “RfcCancelRegisterServer” on purpose: it was a dangerous tool that could also be used for denial of service attacks. (A malicious program can use it to kill other program’s registrations.) So that’s not the solution.

      In a “perfect” network both endpoints of the connection should always be notified by the TCP/IP layer, if a connection breaks down. However, in real life this isn’t always the case… Depending on network hardware & topology, operating system, etc, it can well happen that the application layer of one side is never notified of a broken connection, until it actually tries sending something on the socket. Also there are buggy firewalls which accidentally drop connections from their connection tables and never send the necessary TCP notification to both endpoints.

      SAP has tried several strategies in the past to solve this problem. The current state of the art is described in note 1332022. Basically if you know that you are running in an “unstable” network environment (firewalls cutting connections after a timeout etc.), then you should set the profile parameter gw/reg_keepalive. The gateway will then periodically ping the connection and automatically remove broken ones from the list in SMGW.

      In addition you should also set the gw/process_external_ping, if the gateway has the necessary patch level. Then the NW RFC library can automatically send pings to the gateway and therefore has a chance to find out about broken connections, even in a case where the connection breaks down without a notification send to the “external” endpoint. (Otherwise we might get into a situation, where a connection gets broken, no endpoint gets notified and consequently the external program never registers a new connection, because it “thinks” the old one is still good.)

      Best Regards, Ulrich

    • Hello Ulrich

      We use RfcRegisterServer() to register external server program. When the calls are received, it works but we also need to know ‘dest’ and (or) ‘progName’. We use RfcGetConnectionAttributes() to get attributes of RFC_CONNECTION_HANDLE (in callback function). But ‘dest’ and ‘progName’ are always blank.

      Are they supposed to be filled in? If it matters, we register callback using RfcRegisterServer() and sysId NULL (first parameter).



  • I am trying to port existing RfcServer from classic RFC SDK to new library. RFC Server has IMPORT, EXPORT and TABLE parameters, I had to hard code metadata description as there is no function on SAP for it. There are no substructures for any parameters. All of the parameters (IMPORT, EXPORT and TABLE) have fields of type CHAR and INT.

    I am using latest SDK release 7110.74.17.19618(Note 1409906).

    The callback in nwRfclib always fails with error, “inconsistence in description detected: non-unicode length is too small”. I checked and re-checked the function definition parameter sizes and it seems correct.

    This same exact function defintion works fine in classic RFC SDK. I dumped full function definition from classic and new libraries and they look exactly same.

    Any pointers on how to debug issue in new RFC library?

    • Hi Rakesh,
      most probably an inconsistency between the Unicode length and non-Unicode length of a parameter. The classic RFC SDK worked in only one mode at the same time, so errors would go “uncaught” here. (You would notice errors in the Unicode length only by getting truncated data…) The NW RFC SDK however, keeps both definitions simultaneously, so it is able to detect errors.

      As a first step I recommend reading the chapter about “Hard-coded Metadata” in the following article:

      In particular, if you have an ABAP test system for playing around, you could create the function module their in SE37, use RfcGetFunctionDescription() against that system, dump out the result and compare it with your own definition.

      Best Regards, Ulrich

  • Hello,

    I am trying to develop a client application in visual c++ 2005 (express edition), using the NWRFC SDK (I am using the files in the file NWRFC_2-20002217.SAR version 7.1). The program compiles normaly but don’t run when I try to execute. it fails with the following message:

    Microsoft Visual C++ Runtime Library:
    Runtime Error!

    program: c:\…

    this application has requested the Runtime to tarminate it in an unusual way.
    Please contact the application’s support team for more information.

    If I remove the line with RfcOpenConnection (and also RfcCloseConnection), the execution works perfectly. I have been through this for a while, and actualy I don’t realy know what to do anymore.

    Thanks in advance,


    • Hello Landry,
      first idea: the runtime can’t find the three ICU libraries, or it finds a wrong version of them. Please make sure that the NW RFC SDK’s lib directory is in the path and that no other ICU libraries can be found in the path at runtime.

      Next I would strongly recommend you to upgrade to the current version. 7.1 patch 2 hasn’t been patched since June 2008. Just download 7.11 patch 8, it is backward compatible.

      If nothing helps, you could zip your VS project and mail it to me. (Address is in my Business Card.)

      Regards, Ulrich

      • Hello Ulrich,

        Thanks for your reply. I already had  NW RFC SDK’s lib directory in the VC++ path. I also removed the ICU libraries in the WIN\system32 directory but it didn’t change anything.

        I downloaded this version of the NW RFC SDK: NWRFC_8-20004550.SAR. I know that it is 7.11 but I don’t know how to check that it is the curent version. In any case, it doesn’t change anything too, I still have the same error.

        By the way, I didn’t find your email address in your business card ^^.

        Thanks again

        Best regards, Landry.

        • > By the way, I didn’t find your email address in your business card

          Oops, it was accidentally set to “hidden”… Should be visible now! Just send me your VS project.

          One more idea: did you install the Microsoft ATL patch on that machine? (See note 1375494.) Usually you get a different error, if that is missing, but it can’t hurt to double check this.

          Regards, Ulrich

          • Hello Ulrich,

            I saw that the Microsoft ATL patch was installed with the VC++ redistribuable version. I had already downloaded and installed the 2005 one ^^.

            Thanks for your address, i have just sent the VS project to you.

          • Hello Ulrich,

            I saw that the Microsoft ATL patch was installed with the VC++ redistribuable version. I had already downloaded and installed the 2005 one ^^.

            Thanks for your address, i have just sent the VS project to you.

            Best regards

          • Hello Landry,
            I think, I found the problem: in the Properties under “C/C++  –> Preprocessor” you added the flag
            -DSAP_UNICODE. First of all, the “-D” in front of it is wrong: Visual Studio automatically adds a \D
            in front of all preprocessor definitions. And next it should be spelled “SAPwithUNICODE”.

            Because of this the program was compiled in non-Unicode format, so the login parameters were
            in fact unsigned char (1 byte). The sapnwrfc.dll, however, expected wchar_t (2 bytes) and consequently
            read beyond the end of the buffer, causing an acess violation/buffer overrun.

            After I changed that, everything was ok. (Well, RfcOpenConnection returns the error code RFC_INVALID_PARAMETER,
            because the logon parameters you provide are empty, but that is ok.)
            I also had to add “libsapucum.lib” under “Linker –> Input –> Additional Dependencies”, so that the Unicode
            functions can be found during link step. But that was basically all that needs changing.

            Best Regards, Ulrich

          • Hello Ulrich,

            You were rigth, it works fine now :). I visibly did not understood the explanation about how to configure, in the NW_RFC_GUIDE.

            However, Thank you very much for your help :).

            Best regards, Landry

          • Hello Landry,
            by the way, a few more tips on how to setup your Visual Studio project for RFC programming can be found in the first part of the following article series. I’ll give the complete links to the series here, perhaps you find them interesting:

            Part I — RFC Client Programming

            Part II — RFC Server Programming

            Part III — Advanced Topics

  • Hello Ulrich

    We are using SapNwLib for calling some BAPI’s (from C++). Sapnwrfc.dll’s “production version” shows 711, patch 74, changelist 1133730.

    1. When trying to open connection to SAP using ‘RfcOpenConnection’, the call fails in some cases with message authorization message “User xxxx has no RFC authorization for function group SYST.” 

    Is there a list of “authorizations” that sapnwRfc library requires? If so is there a SAPNote that you can point us to?

    2. We set directory for RFC traces using RfcSetTraceDir(). So that we can control location of trace files. Even with RFC_TRACE=0 and TRACE=0 (in sapnwrfc.ini) and no trace related flag set in ‘RfcOpenConnection’, we get a trace file (just some basic OS information) on later calls to RfcOpenConnection. If we do not call RfcSetTraceDir(), then no trace files are generated.

    Is this by design?

    • Hi Rakesh,
      for authorizations that are necessary for RFC communication please see SAP note 460089.

      Regarding the trace file that get’s generated: I think the logic here is that if trace level or trace directory are changed in a running application, then this is logged (regardless of level) in order to make sure this information is available. (We had quite a few cases with the classic RFC library in the past, where we wanted to debug a customer problem and did not find the trace files. The customer kept claiming “no, there aren’t any files written”, when in fact he had changed the directory and the files were written in a different location…)

      But I’ll take a look at it for PL 9, there might still be something wrong.

      Regards, Ulrich

      • Hello Ulrich

        Thanks for SAP Note link.

        Another thing we noticed was that no matter what setting in sapnwRFc.ini for “RFC_TRACE_DIR” is, the library always seem to ignore value. Files always appear in current directory (what ever happens to be for application).

        On totally different note:
        We noticed memory leak in our application (multi-threaded) and random crashes around calls to RfcSetChars (that was used to set floating point values). We switched to RfcSetFloat() and issues no longer appear. All other uses of RfcSetChars() works fine. Wondering again if there is any known issue with it. Unfortunately I do not have sample application for you.


        • Hi Rakesh,
          I just tested this with the current version (patch level 8 from May, yours seems to be patch level 6 from Feb, so it might be a good idea to update, even though I don’t recall any fixes in the tracing stuff since then).

          And it worked ok?! The only conditions are: the directory must already exist (NW RFC lib won’t create a missing directory), and the entry in the .ini file must be there at startup of the process (adding RFC_TRACE_DIR at a later time and then calling RfcReloadIniFile() will not work: you can’t change trace dir or trace encoding in an already running program).

          Can you send me a little sample program + .ini file (+ perhaps instructions on what might be special when starting the program) so I can try and reproduce?

          The crashes with RfcSetChars() are hard to investigate without any further clues… It only uses local variables, so it should be reentrant. (Unless the same DATA_CONTAINER_HANDLE is used simultaneously in multiple threads? This should not be done anyway: if the current buffer for a structure or function is too small, both threads would do a realloc of the same memory, which could clearly result in crashes.) If you can confirm that not the same container is used in two simultaneous threads and you can get a stackdump or something, I could look at it closer.

          Regards, Ulrich

          • Hello Ulrich

            1. RFC_TRACE_DIR is there in ini at start of process. But still gets ignored. Log files get written to current dir.

            2. For RfcSetChars issue, I am pretty sure threads do not share DATA_CONTAINER_HANDLE.

            I will have someone else review code again and see if they notice anything. And will try to get sample code for you next week. Let me know if I can send to your listed email address.

            Thanks for you help.

          • Yes, my email is up to date. Please also include the .ini file. (And also please make a short test with the current patch level from SMP, just to make sure we were testing with the same version.)

            Regards, Ulrich

  • Hello Ulrich,

    I’m using the NW RFC-SDK 7.1 for accessing SAP application server and all standard functionality does work very well so far.
    Based on the given SDK documentation it should be possible to access nested tables or structures.
    So I’m trying for instance to access a table which is nested into another table.

    If I’m calling RfcGetTable by using the function handle, then this works fine.The returned handle is valid. But if I’m trying to call RfcGetTable for the nested table by using the previous retrieved table handle (I did set the table cursor to valid row and got a row handle), I’m getting an RFC error:
        Rfc Code   : 20
        Rfc Group  : 5
        Rfc Key    : RFC_INVALID_PARAMETER

    Unfortunately the SDK documentation does describe the correct way to handle this. I would expect that the row handle should be used to retrieve the handle for the nested table.

    Is this incorrect?

    If not, what’s the correct way to handle such situations?

    Many thanks in advance and
    best regards,
    Steffen Zimmermann

    • Hello Steffen,
      actually this is the way it should work.
      Can you share a code sample and the definition of the corresponding table from the DDIC?

      Best Regards, Ulrich

      • Hello Ulrich,
        I did build a small test program which I can provide you. It doesn’t represent my original test case, but results into the same issue.
        Here is the code snippet :
            // Perform function module
            printfU(cU(“\nPerform function module”));
            rc = RfcInvoke(globConnect, globFunc,&globErrInfo);
            if(rc != RFC_OK) errorHandler(rc,cU(“Error during calling of function module!”));

            // Retrieve field information
            rc = RfcGetTable(globFunc,cU(“E_T_FIELD”),&hLineType,&globErrInfo);
            if(rc != RFC_OK) errorHandler(rc,cU(“Couldn’t retrieve line type handle!”));
            rc = RfcGetTable(hLineType,cU(“RSDP0_S_FIELD”),&hFields,&globErrInfo);
            if(rc != RFC_OK) errorHandler(rc,cU(“Couldn’t retrieve fields handle!”));
        The second RfcGetTable call does fail in the same way like described before.

        Any idea why this happens?

        For this test case I’ve used the BW BAPI “RSDRI_INFOPROV_READ_RFC”.
        The table “E_T_FIELD” for instance does use a line type.

        Please let me know if it’s more helpful to provide the complete source.

        Many thanks in advance and
        best regards,
        Steffen Zimmermann

        • Hello Steffen,
          sorry, I don’t have access to a BW system, so I can’t check the metadata of the function module RSDRI_INFOPROV_READ_RFC.

          However, if the RfcGetTable() call fails, then this can only mean that the field “RSDP0_S_FIELD” is not a table! (RfcGetTable() would make sense only, if “E_T_FIELD” is a table that has a field “RSDP0_S_FIELD”, which is again a table.)

          However, you are talking about “line type”, so I think I begin to understand what you are trying to do… You are trying to get the “metadata” (the structure definition) of the table E_T_FIELD, is that correct? For this RfcGetTable() is the completely wrong function. It works with the *data* (the field values), not with the *metadata* (description of the field’s data types). I think you are mixing up these two concepts here…

          If you want to get an RFC_TYPE_DESC_HANDLE describing the line type of the “E_T_FIELD” table, use the following call:

          RFC_TYPE_DESC_HANDLE hFields = RfcDescribeType(hLineType, &globErrInfo);

          Or, alternatively, if you don’t have an instance of the “E_T_FIELD” table at hand, you can look up its metadata description in the backend’s DDIC:

          RFC_TYPE_DESC_HANDLE hFields = RfcGetTypeDesc(globConnect, “RSDP0_S_FIELD”, &globErrInfo);

          (Assuming that “RSDP0_S_FIELD” is the name of the DDIC structure definition upon which the table “E_T_FIELD” is based, and not the name of one of E_T_FIELD’s  fields…)

          For more info on how these two concepts, “data” and “metadata”, work in the NW RFC library, please see my SDN article at

          Best Regards, Ulrich

          • Hello Ulrich,
            thanks a lot for your answer.
            Due to the fact, that the function description did returned the table field as a “Table”, I had in mind to use RfcGetTable.
            Now it’s pretty clear what I’ve did made wrong.

            Thanks a again and
            best regards,
            Steffen Zimmermann

  • Hello!

    I’m trying to use the SAPNWRFC on Fedora Linux (64 Bit).

    Executing my (Python) programs are failing with a strange error message saying that the libraries etc. are missing.
    But they are there and correctly configured with ldconfig.

    After some investigations I found the reason:

    The security software SELINUX is blocking the RFC libraries to be loaded.

    One of the libs hasn’t been marked correctly:

    [root@myserver lib]# execstack -q lib*


    [root@myserver lib]# execstack -c

    [root@myserver lib]# execstack -q lib*

    As per manpage that marker could/should be set at compile time to avoid such problems (the other libs are already correct).


    Christian Ziemski

    • PS:
      After executing the above mentioned
      “execstack -c” command the RFC libraries are running again, even with enabled SELINUX.  ๐Ÿ™‚


      Christian Ziemski

      • Hello Christian,
        thanks for pointing that out. I have forwarded the information to our open source group maintaining these libraries. (The ICU libraries are open source from IBM, so the RFC team doesn’t maintain them directly.)

        Best Regards, Ulrich

      • Hello Christian,
        I got some more feedback from our Linux team on this. All four libicu* libraries were compiled in the same way, but apparently gcc uses its own “heuristic” on when to set the exec marker and when not, and for some reason it decided that libicudata doesn’t need one… For the current release the make file won’t be changed anymore:
        “It is technically possible to set the flag for the executable stack at compile time, but we would not do that as a patch on an already delivered release without a strong reason and then only after further in-depth analysis.”

        Furthermore, on an SAP system the Linux group recommends to use SELinux only in “permissive mode”, not in “enforcing mode”. See notes 1048303 and 1496410. That should solve the problem as well.

        Best Regards, Ulrich

        • Hello Ulrich,

          thanks for the feedback.

          Of course such a change would need further analysis on the ICU side.

          The main goal (make it known) is already reached now  ๐Ÿ˜‰

          Regarding SELinux:

          Setting SELinux to “permissive mode” more or less disables the additional security provided by it.

          That isn’t a solution most server admins would like…

          Fortunately that isn’t needed here with SAP NWRFC.

          BTW: Instead of setting “permissive mode” one possibly could create an additional SELinux policy to allow access required for SAP. That way “enforcing mode” would remain activated and SAP would work as well.

          With best regards


  • Hi there,
    when I’m trying to use RFC sdk Linux library (Debian/Ubuntu 10.10) I got this error:

    error: expected ‘;’ before string constant.

    Code caused this error:
    lp[0].name = cU(“aaaa”);

    It is cause by cU in this simple command if preprocessor attribute SAPwithUnicode is used.

    When I tried windows version it works fine, but I need linux version which is still giving me error.

    Thank you for your help. 

  • Hi Ulrich,
    I have no question for now, but would like to say thank you for the enhancement in the latest 7.20 SDK.
    Accessing parameters/fields by index, was the most missing functionality for me.

    Thanks a lot and best regards,
    Steffen Zimmermann

  • Hi Ulrich,
    I have another question regarding the usage of nested tables with NW RFC-SDK 7.20.
    In an earlier blog entry I’ve mentioned already the usage of LineTypes in my own
    ABAP code.
    Now I have some trouble get fields for a nested table. My function module has the
    following rough structure:

      LANGU         -> LANG:1               
      RETURN    Type=BAPIRET2
      DATA      Type=ZOPDATA (=LineType)
    LineType ZOPDATA:
      OPERATYPE       -> CHAR:8
      OPERADETAILS    Type=ZOPDETAILS (=LineType (Table))
    LineType ZOPDETAILS:
      FLD_OPRE    -> INT4
      FLD_OPCP    -> CHAR:2
      FLD_OPID    -> INT4
      FLD_OPDSC   -> CHAR:80
    If I’m loading the function description for this function module, then I can see the
    field OPERADETAILS as a table which should be correct. Furthermore I have no trouble
    to get the field description for ZOPDETAILS.
    But I couldn’t find a way to get the string for the field “FLD_OPDSC” for instance.
    If I’m calling this function module in an ABAP report, I don’t have any trouble.

    Is this kind of function definition not supported with the NW RFC-SDK?

    Or is it necessary to hardcode the function description and specify the fields
    of ZOPDETAILS as fields of ZOPDATA?

    Many thanks in advance and
    best regards,
    Steffen Zimmermann

    • Hi Steffen,
      should not be a problem. The code for calling this function module and reading the FLD_OPDSC values would roughly looks like this (error handling omitted for clarity):

      RFC_ERROR_INFO errorInfo;
      RFC_TABLE_HANDLE dataTable, detailsTable;
      SAP_UC fieldValue[81];

      conn = RfcOpenConnection(…);
      desc = RfcGetFunctionDesc(conn, cU(“Z_MY_FUNC”), &errorInfo);
      func = RfcCreateFunction(desc, &errorInfo);

      // Set imports

      RfcInvoke(conn, func, &errorInfo);
      RfcGetTable(func, cU(“DATA”), &dataTable, &errorInfo);

      while (RfcMoveToNextRow(dataTable, &errorInfo) == RFC_OK) {
          printfU(cU(“Processing next row of table DATA.\n”));
          RfcGetTable(dataTable, cU(“OPERADETAILS”), &detailsTable, &errorInfo);
          //Or: RfcGetTableByIndex(dataTable, 1, &detailsTable, &errorInfo);

          while (RfcMoveToNextRow(detailsTable, &errorInfo) == RFC_OK) {
              printfU(cU(“Processing next row of table OPERADETAILS.\n”));
              RfcGetString(detailsTable, cU(“FLD_OPDSC”), fieldValue, 81, NULL, &errorInfo);
              //Or RfcGetStringByIndex(detailsTable, 3, fieldValue, 81, NULL, &errorInfo);

              printfU(cU(“FLD_OPDSC = %s\n”, fieldValue);

      Best Regards, Ulrich

      • Hi Ulrich,
        thanks a lot for your sample code. It helped me to solve my problem. I did implement it in the right way, but got an error message (INVALID_RFC_PARAMETER) which indicates that a field was not available.
        Indeed I didn’t got any data back due to the bad test data. So my first assumption regarding wrong coding was not correct.
        However now it’s clear how to handle such situations.

        Thanks again and best regards,
        Steffen Zimmermann

  • Hi Ulrich,
    I have another question on the SDK regarding how to cancel a long running function call by using the NW RFC-SDK 7.20 PL 3.

    Right now, I’m performing function calls in threads and this allows me to stop the thread and re-establish a connection.

    Is this a good solution, or are there any other suggests from your side?

    Many thanks in advance and
    best regards,
    Steffen Zimmermannn

    • Hi Steffen,
      sorry, “real life” kept me from attending to my online responsibilities for quite a while…

      RfcCancel() has always been quite “dangerous” as it always leaves the ABAP side in an unknown state. It’s not a problem, if you only call a “Read Function Module”, but if you call an “Create/Update FM”, you can never be sure, at which point the call has been aborted. It may already have written to the database successfully, only partially or not at all… If you repeat the call at a later time, you may get a duplicate or an inconsistent state.

      For these reasons RfcCancel() has not been carried over from the classic RFC SDK to the NW RFC SDK. (However, possibly it will be included at a later time. Atm there are no plans for that though.)

      If you really can’t wait for ultra-long running calls (does it really happen, that a call “hangs” forever and never returns?!), the workaround with simply killing the thread is already quite ok. However, it means that the underlying TCP/IP socket will remain open indefinitely, perhaps until the entire process ends.
      If this happens thousands of times, it may become a problem (operating system and network card need to reserve resources for every socket etc).

      In such a case you could try calling RfcCloseConnection() on the corresponding handle, before killing the thread. (In general, it is dangerous to use a connection handle from inside two different threads, but if the RfcInvoke() has been stale for quite a long time, it’s probably safe to close the handle from another thread.)

      Best Regards, Ulrich

  • Hi Ulrich,

    I’ve tried to implement a password change handler by usage of “RfcInstallPasswordChangeHandler” from the NW RFC-SDK 7.20 PL 3.
    Now if I’m calling RfcOpenConnection() there is no call on the specified callback function although I just did reset the SAP user password, which normaly means a needed password change.
    I’ve tried to do the same with the “classic” RFC and had no problems to set a new password.
    So I guess there is no problem on the SAP Server self.

    Based on the SAP notes it should be possible with the NW RFC-SDK 7.20 PL2 and higher to use this handler also for RFC clients.

    Is there something which needs to be considered?

    Many thanks in advance
    and best regards,
    Steffen Zimmermann

    • Hi Steffen,
      there was indeed a bug in the PasswordChangeHandler. It was fixed in PL5 (see note 1591259 for details.) SO you should try the latest patch.

      Regards, Ulrich

  • Hi Ulrich

    Having peculiar issue with nwRfc library. Hope you can give some pointers on how to debug this. We use extensively for RFCs/BAPI calls without any issue. Discovered that for one specific RFC call nwrfcSdk fails where as old rfclib works. Both cases use exactly same data. Stepped into SAP using both old and new libraries and input data looks same. There are no errors either in client side or in SAP. Do you have suggestion as to how to debug this? RFC in question is ‘BBP_PMORDER_COMP_CREATE’. Any idea where else to look for?  Tried with latest library available on web site

    nwRfcSdk 7.20 – Patch-Level 5



    • Hello Rakesh,

      my first guess would be: could be a problem with an “optional parameter” causing different behaviour in the function module? I know that this has caused strange problems before. Basically the “default” for optional parameters has been switched around: in the old lib they were active by default, whereas in the NW lib they are inactive by default. Sometimes it makes a difference in ABAP, whether some parameter does not exist at all, or exists with an initial value… Especially, if the parameter is an optional table with header line…

      The NW RFC lib has a function RfcSetParameterActive() for controling this behaviour.

      Other than that I would recommend to open an OSS ticket under BC-MID-RFC, so it can be analyzed with real life data.

      Best Regards, Ulrich

  • Hi Ulrich,

    i’m on the move from classic lib to new nw rfc sdk.

    Unfortunatly program to port uses connection to external rfc programs (Type E, with GWServ, GWHost, TPNAMe and TPHOST).

    After a lot of time for searching how to do external RFC Server calls with new nw lib, i doubt this is possible with new nw lib …

    So could you please state if this feature has been canceld or post a small connection snipplet how to connect?


    • Hi Tom,

      in fact, the feature of “extern-to-extern” communication has been disabled in the NW RFC library for security reasons.

      Only workaround would be to create an empty function module stub with the identical signature on ABAP side, which just forwards the call coming in from the external RFC client program to the external RFC server program?! (That would at the same time allow to add user logon and an authority check for this scenario.)

      Best Regards, Ulrich

      • Hi Ulrich,

        thank you for clarification.

        I assume same applies to Java Connector?

        So for Java Connector and NW SDK an ABAP bridge is needed and Classic Lib will be only way for direct communication over RFC, correct?



        • Hi Tom,

          yes, same for Java Connector 3.0 and .NET Connector 3.0.

          (However, JCo 2.0 and NCo 2.0 are based on the classic lib, so they can still do it.)

          Regards, Ulrich

  • Hi Ulrich!

    Thank you for the valuable information and insights on the new SDK functionality.

    Are the two coding samples, that you mention in the PDF files, still downloadable for free anywhere? We are currently trying to send IDocs from a non-SAP system via Netweaver RFCSDK 7.2 to a Java-Only PI 7.3 EhP1. With the old RFCSDK implementation we get the an error concerning the function API_CREATE_TID. So we have to update the RFC client program, don’t we?

    Best regards,


    • Hello Heinrich,

      your question is related to the previous question by Tom X above: unfortunately the NetWeaver RFC SDK does currently not support communication with a non-ABAP communication partner, so using it with a Java-only PI will not work.

      Instead it is probably best to keep the implementation based on the old RFC lib, until a solution for that limitation is available. (Old RFC lib still supports extern-to-extern communication.)

      The error about API_CREATE_TID is probably caused by the fact that the old library function RfcCreateTransID(RFC_HANDLE handle, RFC_TID tid) tries to call that function module to obtain a TID from the “R/3 side”, but as the other side is no R/3, that function module does not exist?! In this case you could perhaps create a TID locally instead of using RfcCreateTransID(). (However, that is a bit tricky and error-prone, as most OSs provide a 16-byte GUID, and “converting” that into a 24-char GUID is possible but not easy…)

      On the other hand: the more I think about it, the more I expect that the “IDoc Adapter” on PI side should provide a “Java implementation” of API_CREATE_TID?! So the internal RFC call from within RfcCreateTransID() should work. Perhaps only the IDoc Adapter is not correctly installed?!

      But as I’m not a PI expert, you should contact PI support about this question. I know that just recently some work has been done to allow a Java-based PI to receive IDocs from non-ABAP partners, so this must be possible.

      Best Regards, Ulrich

      • Hi Ulrich!

        Thanks for the quick reply. So you’re saying that we should not use the netweaver RFC SDK, because the java-only PI is regarded as an external RFC server?

        The error message is

        “Unsupported function module API_CREATE_TID used with IDOCActivationSpec registered for XI_IDOC_DEWAS_XYZ on system hostname”

        We implemented SAP note 1729203, so PI is allowing the connection from the Non-SAP system. But now we are facing the above mentioned error.

        Maybe someone has an idea here?

        Best regards

        Heinrich Lieker

        • Hi Heinrich,

          yes, from a “technical point of view”, PI is an “external RFC server”….

          I just read note 1752276, and it mentions that PI supports communication with old RFC SDK based programs. So something seems to be wrong on PI side here. I would open an OSS ticket under BC-XI-CON-IDO and provide the above error message.

          Regards, Ulrich