Skip to Content


This week SAP released the next generation of C/C++ based RFC connectivity toolkits: the SAP NetWeaver RFC SDK 7.10 (short: NW RFC SDK). Compared to the “classical” RFC SDK (which has been available since SAP R/3 Release 2.1!) this new version brings a substantial set of new features and simplifications, which we hope will make the life of C developers, who need to interface with SAP systems, much easier. This blog aims at giving an overview over these features.

The first thing to point out is: the NW RFC SDK has been a complete re-design from scratch. This allowed to throw over board some old ballast (e.g support for COM/DCOM) and to make things easier at those points, where the old architecture had made the handling of certain tasks tedious and complicated (e.g the processing of nested structures). However this also means that the API has changed incompatibly.
So people, who want to migrate existing RFC applications to the new SDK, will need to adjust their coding as well as their “way of thinking”: some things are now achieved by quite different concepts, especially in handling the input/output parameters and in the RFC Server case. So it’s not just a matter of “replacing this function call by that one”.

The new SDK now offers virtually all possibilities, which the R/3 kernel on the other side supports. E.g when connecting to a 7.00 backend, you can work with “ABAP Messages” (E-, A- and X-Messages); however, this feature is not yet available with a 4.6C backend, simply because the kernel doesn’t support it yet.
One other implication of the fact that the implementation of the RFC protocol in the R/3 kernel has changed over time, is: we didn’t want to have too many “if-elses” and special treatments in the new code. Therefore the decision was made to “cut off” at a certain point. So the NW RFC SDK only supports backend releases from 4.0B onwards. If you still need to connect to a 3.1I system, you will unfortunately need to stick to the classical SDK. However we hope this will not be too much a limitation (the number of 3.1I systems is slowly approaching zero) and the advantages gained by this decision will benefit 99% of the users.

So what are now the improvements that the NW RFC SDK has to offer?

  1. You no longer need to worry about getting the correct structure definitions for your imports, exports and tables. One API call fetches the complete definition of a function module from the backend DDIC and caches it for later use. (Metadata and repository functionality kind of like in JCo.)
  2. Setting and reading parameter values is simplified and unified, which makes it now possible to work with nested structures as well as tables defined under IMPORTING/EXPORTING.
  3. No need to worry about codepages anymore. You simply work with one character data type in your application, and the RFC lib automatically chooses the correct codepage for you, depending on the backend (Western European, Japanese, Kyrillic, Unicode, etc, etc).
  4. Working with ABAP Exceptions, ABAP Messages or System Failures is now fully supported.
  5. Simplified support for tRFC/qRFC. It is now possible to create tRFC transactions consisting of multiple steps (function modules).
  6. A simpler programming model
  7. Support for IPv6
  8. And I probably forgot a few…

The NW RFC SDK can be downloaded as described in note 1025361. Documentation will follow soon (keep an eye on that note for updates). To get started, read the header file “sapnwrfc.h” and the demo programs included in the SDK. The above note describes also, where to download doxygen documentation and a development guide in PDF format.

The first successful projects based upon the NW RFC SDK have been Piers Harding’s NetWeaver RFC gives the Next generation Ruby and Perl Connectors: wrappers around the NW RFC SDK, which allow to do RFC communication from within Ruby and Perl programs. We hope that the new RFC SDK, as well as the “scripting connectors”, will get a “warm reception” in the SAP community and will enable many new projects, which would otherwise have been difficult (or impossible) to achieve. And even if you already have a satisfactory RFC application based on the old SDK, it may be worth taking a look at the NW RFC SDK, as it might simplify your coding and ease the maintenance!

Well, that’s what I can say for a starter. Feedback is of course highly wellcome, but please understand that I have a fulltime job, a wife and a kid to take care of… So I may not be too quick in answering all questions. Professional questions and bug reports can of course always be sent to SAP via an OSS message under “BC-MID-RFC”.

The Q&A section of this blog is becoming kind of crowded now, therefore I started a new blog, introducing a couple of upcoming new features of the NW RFC Library: New developments in Netweaver RFC communication You are all invited to start asking questions there…!

You must be Logged on to comment or reply to a post.
  • Hi!

    I went through the functions in the NW SDK, and they seem much much simpler to understand and use compared to the librfc32 library.

    However, I have a few queries on how the following can be done. Currently, these are preventing me from re-writing my app to use the NW SDK:

    (a) no API for determining whether a connection handle is valid.
    (b) i dont see a way for determining which parameters are optional for an RFC.
    (c) also, how do i get the description for a RFC parameter? will extendedDescription always be a wchar if i use SAPWithUnicode?
    (d) there’s no function to convert a GUID to a RFC_TID and vice versa
    (e) in RfcInstallTransactionHandlers, what is the sysId parameter? it wasnt there in librfc32u.

    • Hi Mustansir,
      let me try to answer your questions:

      a) We thought that this is no longer necessary, because RfcInvoke() does it automatically and returns RFC_INVALID_HANDLE, if you try to use a connection that has already been closed. (RfcCallReceive() in the old SDK did the same, so in my opinion RfcIsValidHandle() has never been really necessary.)
      So instead of having two places, where some error handling needs to be done (after RfcIsValidHandle() and after RfcCallReceive()), you need only one place for error handling, if you do something like this:

      perform_call: rc = RfcInvoke(handle, …);
      switch (rc){
         case RFC_INVALID_HANDLE:
            handle = RfcOpenConnection(…);
            if (handle != NULL) goto perform_call;
            // otherwise there is a network problem to
            // the backend, so we just fall through:
            // Do whatever you need to do, when the
            // backend can’t be reached.
         case RFC_ABAP_EXCEPTION:
         case RFC_ABAP_MESSAGE:
            // Do whatever you need to do, when the
            // backend returns an error message
         case RFC_OK:
            // Process the outputs.

      This should be much more elegant than working with RfcIsValidHandle.

      b) From RFC point of view ALL parameters are optional…! Neither the RFC layer nor the R/3 Kernel will throw an error, if a non-optional parameter is missing. This is only “cosmetics” used on ABAP application side.
      How ever if you really need that information, you can call RFC_GET_FUNCTION_INTERFACE. The last field of the table “PARAMS” contains an ‘X’, if the parameter is optional.

      c) First you need to use RfcGetFunctionDesc(), and then you can use RfcGetParameterCount(), RfcGetParameterDescByIndex() or RfcGetParameterDescByName() to get an RFC_PARAMETER_DESC for each parameter.

      The struct member void* extendedDescription is not used by the RFC library, neither set nor read. It is meant for usage by the application programmer (that’s you!). You can store any additional information in it you like. The idea is to help programmers that write UIs: for example they could store information about possible values for an F4-Help at this central point.

      d) Right. In the old RFC SDK this function was meant for integrating the COM/DCOM connector into the RFC library. (So only for Windows.) That has been thrown over board. If you want to do tRFC, you should either use RfcGetTransactionID() or have your own algorithm for creating unique 24-digit TIDs.

      e) This is the “System ID” of the backend, from which you want to receive tRFCs. In the old RFC SDK you could install the transaction handlers only “globally”, and then they were used for every backend. The new SDK allows you to install different handlers for for different backends.
      If you want the old behaviour, just pass the wildcard “*” as sysId.

      Best Regards, Ulrich

      • Hi Ulrich.

        Firstly, thanks a lot for replying :).

        Your comments on (b) and (d) are fine, I was expecting your reasoning, thanks.

        Regarding (a), let me give you a little more information on my scenario. My application was using connection pooling, and so, when a RFC call had to be made to the backend, I was obtaining a connection from the pool, (my own local pool), first checking if it was valid (using RfcIsValidHandle), and if so, reusing it, else, i would get rid of it and then open a new connection to add to the pool, (or ask for another connection from the pool).
        Anyway, since RfcIsValidHandle is no longer present, what I have decided to do is, I’ll use RfcGetConnectionAtrributes (I currently dont remember the exact function name in the NW SDK), and will check the return code of that to figure out if the connection is “clean” or not. My only concern is, that this call will be more expensive than the older RfcIsValidHandle call (though I’m not certain and cant verify until my prototype is ready) .. any thoughts?

        Regarding (c), I actually meant, how to get the comments (Short Text / Long Text) associated with the parameters in the RFC? Earlier that was obtainable via the ParamText field I think ..

        Once again, thanks a lot for your response 🙂


        • Hello Mustansir,
          actually last time I told you nonsense: in RfcInstallTransactionHandlers you
          need to pass NULL (not “*”) as sysId, if you want the global behaviour…

          Regarding a) I can see your point.

          However be warned that RfcIsValidHandle only checks, whether the value of that pointer has been obtained from the lib and hasn’t been closed yet. It doesn’t do a ping, so it wouldn’t notice, if a firewall had “silently” cut the connection in the meantime. We are still discussing this.

          c) Ah, now I get it. You mean the field “RFC_U_FUNINT.Paramtext”, which RfcGetFunctionInfoAsTable returned in the old lib.

          Here the same applies as to the field “Optional”: in order to keep the new lib “lean”, this information has been declared superfluous and has been removed for better efficiency…

          However it is easy to get the information. After RfcGetFunctionDesc, simply call RFC_GET_FUNCTION_INTERFACE with the same FUNC_NAME and evaluate the last two fields of the table “PARAMS”: PARAMTEXT and OPTIONAL. Then you can store the necessary information (plus anything else that you may need) in the RFC_PARAMETER_DESC.extendedDescription pointer for later reference.

          Best Regards, Ulrich

          • Hi Ulrich.

            Thanks a lot for your response 🙂

            I’ll be checking this blog back often, so please do add a comment when you and your team come to a decision on how to determine if a connection is valid by pinging the target system (you’ve mentioned “we are still discussing this”).

            one last question – is there an ETA by which the guide to the NW SDK will be put up online? in the SAP online library?


          • Hi!

            One more thing I forgot to mention in my reply, ragarding the ParamText parameter:

            some time back we had contacted SAP for information on using the RFC “RPY_BOR_TREE_INIT”. we were using this RFC for BAPI browsing, but the way we were interpreting it seemed different from the way SAP GUI was interpreting it, since we were never able to come up with the exact same tree as the BAPI Explorer. we contacted SAP for documentation on how to use and interpret the results of RPY_BOR_TREE_INIT. We were told that SAP would not be giving us information or support on it, since RPY_BOR_TREE_INIT is not a released RFC.

            Since then, we have decided to avoid using any un-released RFCs in our application. Unfortunately, RFC_GET_FUNCTION_INTERFACE is also an un released RFC. I know that the SDK internally uses this RFC for metadata retrieval, but at least we know that the SDK will be supported 🙂


        • Hello Mustansir,
          here is an update of what has happened the last two weeks:

          1) First of all regarding the RfcIsValidHandle(): we decided that this alone is not of much use: it only checks, whether a handle is still in the RFC librarie’s list of handles. If an application can’t remember, whether it already closed a handle or not, then this application has other problems to worry about… 🙂
          Therefore the decision was made to offer a new API RfcPing(), which really checks the connection on TCP/IP level. This is the only way to determine, whether a connection is still alive. (RfcGetConnectionAttributes only returns the cached attributes, but a firewall may have closed the connection meanwhile without notifying the two endpoints.)

          2) Patch level 1 of the NW RFC SDK will be released soon, probably next week. It’ll contain quite a number of new APIs (and a few bug fixes). For a detailed list see SAP note 1056472, which will be released together with the SDK.
          For you one new API will be particularly interesting, as you are implementing connection pools: RfcResetServerContext(). This basically does what the old RfcCleanupContext() did: resetting the user session in ABAP without closing the connection.

          3) The Param Short Text (and the “is optional” information) will not be added to the new SDK. When we voted about this, the main opinion was: this only consumes unnecessary memory and 99% of all users will never need it. So you’ll need to bite into the sour apple and use RFC_GET_FUNCTION_INTERFACE… (But I can console you: that FM hasn’t been changed in decades! So there shouldn’t be any risk. After all: every SAP connector, from the RFC library over JCo and .NET Connector to the Business Connector, depends on that FM, so SAP would never change it, it would just cause too much chaos…)

          Best Regards, Ulrich

          • Hello Mustansir,

            one more update: I again have to retract my words… After second thought we decided to fulfill your wish and to build the two fields “parameterText” and “optional” into RFC_PARAMETER_DESC.

            The motivation is clear: if we want to increase the acceptance of the new library, it should provide about the same functionality that the old one provided… 🙂

            Best Regards, Ulrich

  • I have downloaded new NW RFC SDK 7.10 and compile companyClient.c example.<br/>But when I run example segfault occured.<br/>Here my steps on SuSe 10.2:<br/>host:nwrfcsdk/demo> gcc -g -I../include -L../lib companyClient.c -lsapnwrfc<br/>host:nwrfcsdk/demo> env LD_LIBRARY_PATH=../lib ./a.out<br/>stderr initialized<br/>Segfault occured<br/><br/>Here gdb backtrace:<br/>(gdb) bt<br/>#0  STL::basicstring<unsigned short, STL::chartraitsWhat’s wrong?

    • Hello Dmitriy,
      the crash happens in RfcOptions::parseConnString(), which is where the connectionParams array is read. Therefore my first guess is: have you shortened the array, let’s say to 5 elements? The paramCount value is still 6, so in that case the parseConnString() would read beyond the end of the connectionParams array, causing the crash.

      Best Regards, Ulrich

      • Hello Urlich.
        I have just extracted distribution of NW RFC SDK and compiled companyClient.c without any changes in sources.

        But I found the problem. NW RFC required all strings in UTF16, but if run compilation without any defines resulting binary using ASCII characters.

        So the are problems:
        1) Why compilation doesn’t fail without required defines, if only unicode strings required?
        2) If I try to compile with -DSAPwithUNICODE on Linux (SuSe 10.2) I get
        error: ‘_U16_LIT_cU’ was not declared in this scope
        for ‘cU’ macro expansion.

        I have replaced all ‘cU’ macros to equivalent RfcUTF8ToSAPUC calls in example and they have started working.

        • Hello Dmitriy,
          ah, now I see what’s wrong. Yes, if the SAPwithUNICODE is not set, all SAP_UC variables are only half as long as they should be, and when the RFC library tries to read the full length, it causes the segmentation fault…

          Ok, the problem with the cU macro can be explained easily: Linux does not have a “wchar_t” type like the one on Windows. (On Windows wchar_t is UTF-16, while on Linux it’s a 4-byte UCS4, I believe.) Therefore on Linux an additional step is necessary between the pre-processor and the compiler step. See notes 1056696 (and 763741) for the details.

          Best Regards, Ulrich

  • Hello Urlich.

    How switch off tracing in NW RFC SDK 7.10 ?
    When I run any example, in current directory rfcXXXX.trc files has appeared.
    I have tried many variants:
      – specify login parameter ‘trace’=’0’ in RfcOpenConnection
      – set RFC_TRACE=0 eviroment variable
      – create sapnwrfc.ini file with RFC_TRACE=0 line. Run with and without RFC_INI eviroment variable.
      – add to programm nlsui_set_trace(NULL,(NlsuiTraceLevel)0) call

    Also I can’t switch off tracing for Python connector.

    • Hi Dmitriy,
      you are always seeing trace entries for RfcRecord.fillField(), right? That’s a bug, which will be fixed in patch 1.

      I will update this blog, once patch level 1 is available for download. Should be very soon now.

      Regards, Ulrich

  • I have tried nwrfc with vs2005(sp1),its great.
    and except
    1)not define SAPwithUNICODE
    2)RfcRecord::fillField trace always on

    I have encountered:
    RFC_CONVERSION_FAILURE: Could not convert from 8400 codepage to 4103 codepage
    I am not familier with unicode, nor IBM icu lib.
    can you give me any clue?
    thanks again.

    • After some try&fail,I found the problem is in EKPO-TXZ01 field.Out user mantained some long text which have been truncated to 40 bytes and the last chinese char is half and broken.After enlarge my extracting table`s crosponding field to char64 size,it gose well without problem.
    • Hello Yilong,
      good that you like the NW RFC SDK…!
      Yes, the handling of non-Unicode R/3 systems like 8000/8300/8400 sometimes is a bit difficult. The problem is that in these R/3 systems a “CHAR40” field is not really “40 characters”, but only “40 bytes”… But you found the solution already.

      The tracing bug will be fixed in the upcoming patch level 1. Stay tuned for news.

      Regards, Ulrich

      • Thank you very much for such quick reply.:)
        Yesterday I also find that if you want some import parameter left to its default value,an explicit call to RfcSetParameterActive with 0 must be made or that param will be bland padded.

        and in sapnwrfc.h around line 262 its a
        RfcGetVersion api but using depends I found no implmentation in dll. 

        I am using rfc to extract r/3 table to sqlserver and using reporting service to generate web report and I am very glad to help you test this new nwrfc lib.

        • Hello Yilong,
          yes, this behavior is indeed a bit unexpected… The reason is as follows: the RFC SDK allocates and initializes the memory areas for all skalar params. (In case of CHAR it’s initialized to blanks.) It doesn’t keep track, whether a user changes this memory later via RfcSetChars(), and then simply sends all data over to the ABAP side. ABAP apparently doesn’t recognize the initial values (blanks) as an empty field and therefore uses that value instead of the default value…

          In patch level 1 we’ll change this behavior, so that all skalar parameters remain inactive untill RfcSetChars/Int/Num…() has been called for that parameter. This should then have the expected results!

          RfcGetVersion has been forgotten in the export list of the dll… Will also be fixed in patch 1.

          Best Regards, Ulrich

          • hi Ulrich,
            thanks again for your reply:)
            yesterday when I made a call, I encountered the following time out error:
            Error calling function: 3
            TIME_OUT: Time limit exceeded.
            I am not sure its my abap side timeout or nwrfc timeout.
            If its nwrfc timeout,can i change the limit value?
          • Hi Yilong,
            the NW RFC library has no timeout. Must be an R/3 workprocess timeout. See SM21, ST22 or the workprocess traces.

            Regards, Ulrich

    • Dear Ulrich, the nwrfcsdk is great, and our team is ready to shift our rfcsdk to this nwrfc lib.
      But after your init delivery, and some active bug reports, we are here waiting for patch 1…
      You may reach me at li.chengzhe[AT]
      btw,the previous comment “yilong chen” is also a member of our dev team.
      Thanks alot and hope we may help you with some test work.
  • Dear Ulrich,
        When I use RfcSetString to set a nagetive  number string to a BDC type variable, seems there is a convertion bug.
    -1.1  ==> -11
    -1.23 ==> -12.3
  • Hello Ulrich.

    Does NW RFC 7.10 support connection over SapRouters?

    I have tested connection with rfcping from old rfc:
    rfcping ashost=/H/ sysnr=14
    They work with success.

    When I set this connection string in loginParamers for RfcOpenConnenction function, I get following error:

    LOCATION    SAP-Gateway on host cirt1 / sapgw14
    ERROR       hostname

    TIME        Tue Oct  9 13:47:12 2007
    RELEASE     640
    COMPONENT   NI (network interface)
    VERSION     37
    RC          -2
    MODULE      niuxi.c
    LINE        329
    DETAIL      NiPGetHostByName: hostname
                not found
    SYSTEM CALL gethostbyname
    COUNTER     2

    Which loginParameters needed for connection over SapRouter?

    Regards, Dmitriy.

  • Hi all,
    I guess it’s about time I answer some of the questions that have accumulated in the last couple of weeks…

    First of all: after an unfortunately very long delay we finally finished Patch level 1! Validation is currently in process and I expect the download file to be available on the usual SMP page next week.

    The problem with the SAPRouter is known for some time now and has been fixed. And the incorrect BCD conversion as well. See note 1056472 for a complete list of patches and new features.


    • My Dear Ulrich:
      You know that? Checking this blog for your good news is almost my first job every morning. 🙂
      I have been using nwrfclib in our home-made web  report site for data retrivel for several month, it`s working good. Thanks again.
      And now with patch 1, I am going to do some web order entry page via BAPI.Hope everything gose well.
      I know you are busy, if any thing that I can help, you may reach me at
  • Hi Ulrich.

    I have tried new patch 1 of NW RFC 7.10.
    They now works over saprouters for me.
    But one problem stayed, rfcXXX.trc files still appeared with content:
    “RfcRecord::fillField was invoked for RFCTYPE_TABLE”

    I have checked under Win IA32 and Linux IA32 versions.

    Regards, Dmitriy.

    • Hi Dimitri,
      yes, unfortunately this one fell through the cracks! Apparently no one took care of that one. I only noticed during testing last week, and as I didn’t want to delay the release any further (it’s already 5 months late, and some people have been waiting for some of the critical stuff like SAPRouter communication and the BCD conversions!) I let it slip through. However, it’s not going to stay that way… Internal tracing is still the weak point and needs to be changed a bit, before it’s in its final state.

      I hope it’s only a minor blemish.

      Best Regards, Ulrich

    • Hi Dmitriy,
      there’s not much difference here to the classic RFC SDK: instead of the old RFC_OPTIONS you use the new structure RFC_CONNECTION_PARAMETER and add an entry like this:

      connParam[0].name = cU(“dest”);
      connParam[0].value = cU(“C11”);

      And then use RfcOpenConnection() instead of the old RfcOpen():

      handle = RfcOpenConnection(connParam, 1, &errorInfo);

      The “sapnwrfc.ini” file works just the same as it did in the old RFC SDK.

      PS: There is a pdf documentation available now for the NW RFC SDK: see  –> SAP NetWeaver RFC Library. It also documents the ini file.

      Regards, Ulrich

      • Hi Ulrich.

        Thanks for the link on documentation.

        I have tried DEST parameter and sapnwrfc.ini, but have no success.

        I have compiled and runned
        stfcDeepTableServer.c from examples, add ‘MY_SERVER’ RFC destination in SM59. Go in SE37, open SFTC_DEEP_TABLE functional module, run it in debug mode with specified RFCDestination ‘MY_SERVER’ and get response from runned stfcDeepTableServer programm. So, all configured and working normal.

        Now I have writen own C-program that uses NW RFC, and try call ‘SFTC_DEEP_TABLE’ function with RFCDestination ‘MY_SERVER’ without succes. I have tried many variants: explicit setting connectionParam, sapnwrfc.ini. All times I get response from original SFTC_DEEP_TABLE abap function.

        How call my RFC server function (in this case ‘SFTC_DEEP_TABLE’ on RFCDestination ‘MY_SERVER’) from my NW RFC client?

        Regards, Dmitriy

      • Hi Ulrich.

        I try invoke function on my destination:

        RFC_ERROR_INFO errorInfo;
        RFC_CONNECTION_PARAMETER connParam[1];
        connParam[0].name = cU(“dest”);
        connParam[0].value = cU(“SPRX”);

        handle = RfcOpenConnection(connParam, 1, &errorInfo);

        But RfcOpenConnection returns NULL. Here content errorInfo:
        message:Incomplete logon data.

        My sapnwrfc.ini (get from documentation):

        I have created and tested ‘SPRX’ RFCDestination in SM59 with type T and registered mode. And I have successful execution if calling my function from ABAP.

        What I doing wrong?
        Please, help me.

        Regards, Dmitriy.

        • Hello Dmitriy,
          ah, now I understand, what you are trying to do! “Extern-to-extern” communication…

          Unfortunately here I have to say: extern-to-extern communication has been disabled in the NW RFC Library for security reasons. Communication now only works between “library and R/3 kernel”, but no longer between “library and library”.

          So if you want to communicate between two C programs, you will need to do it using a direct socket, not via RFC.
          Best Regards, Ulrich

  • Hi Ulrich.

    I need write multi-threaded RFC server, but documentation doesn’t clear in this aspect.
    As I see in example stfcDeepTableServer.c, main thread calls RfcListenAndDispatch in loop. In documentation written that RfcListenAndDispatch waiting connections, calling implementations and return result of implementation.

    What will happened if during running of implementation new calls has arrived? They will be queued?
    And how in NWRFC serve simultaneous calls?

    Regards, Dmitriy

    • Hi Dmitriy,
      yes, multithreading is supported (and it’s even the recommended way to write a server). All you need to do is, to put the RfcRegisterServer() and the entire “dispatch loop” into a separate thread.

      > What will happened if during running of implementation new calls has arrived? They will be queued?
      > And how in NWRFC serve simultaneous calls?
      As long as the RFC_CONNECTION_HANDLE is still busy in your “server function”, the RFC connection on R/3 side will be in “busy state”, so the R/3 kernel cannot send a second request. The R/3 workprocess waits for a specific time (which can be customized via a profile parameter, I think) and if still no free RFC connection for that RFC destination is available after that time, the CALL FUNCTION … DESTINATION … statement in ABAP will abort with a timeout.

      Basically, what you have to do is, setup N separate threads, each of which will create a new RFC_CONNECTION_HANDLE via RfcRegisterServer() and use these handles in an RfcListenAndDispatch()-loop. Then the R/3 side knows there are N active connections which it can use for sending simultaneous RFC requests to your server.

      I hope I was able to explain this properly?!
      Best Regards, Ulrich

  • Hi Ulrich.

    I have ABAP program that exporting string parameter. When size of return string above 255 characters function RfcGetStringLength reporting approximately half of source size (for example source size:8921, returning: 4588). RfcGetString and RfcGetChars also return half size of original string, even with right sizes they have called.
    I have checked TCP traffic, complete string was sended to client.
    NWRFC client compilled with -DSAPwithUNICODE, I have tested on SuSe Linux 10.3 and Win2000.

    How to fix this?

    P.S. Thanx for threading explanations, all works for me.

    Regards, Dmitriy

    • Sorry, I was wrong.

      Described error has appeared when ABAP function module exports structure with string fields.

      When functional module exports string – all works fine.

      Regards, Dmitriy

      • Besieds, when exports char128 field, RfcGetString will not trim the right blank, but when char/text128 in tables fields, RfcGetString will trim right blank.
        In Jco 2.1.8 both case the tailing spaces will be trimed and return zero-terminated string.
        In my understanding, getString will trim the right blank no matter from Chars or String, while getChars will padding buffer with tailing spaces.
    • Hi,
      both of these issues (incorrect string length and incorrect trimming of trailing blanks) look like bugs. I’ll keep you posted, when we’ll be able to provide the next patch.

      Regards, Ulrich

  • Hi Ulrich,

    How to fill a Field of SAP-Type “QUAN” im my C++application? (for example: BAPI_PP_HDRLEVEL-Yield)
    Is it possible to use RFC_DECF16?
    Exists a function in the NWRFCSDK to convert a Float/Int to RFC_DECF16?

    Best Regards, Tim

    • Hello Tim,
      there are several possibilities here: the easiest is probably to just use
      RfcSetString(functionHandle, “YIELD”, “123.45”, 6, &errorInfo);
      The RFC library will then automatically convert the string “123.45” to a BCD number.

      Using RFC_DECF16 is also possible. For converter functions (int/float/double to DECF16 and vice versa) see the header file sapdecf.h, which comes with the NW RFC SDK.

      You may also use RfcSetFloat(), but here there is the problem that the conversion of a “double” (which is IEEE4 floating point) to a BCD number (which is “fixed point”) will lead to rounding inaccuraries.

      Regards, Ulrich

  • Hi,

    I’m trying to use function RfcGetFunctionDesc for two RFC enabled functions in SAP. In one case it works all right. But when I try for the second one I get error 20 (RFC_INVALID_PARAMETER). The only thing I change in code is the function name.
    What might be the reason why RfcGetFunctionDesc returns error 20 (RFC_INVALID_PARAMETER)?

      • Hi Ulrich,

        I sent my code through this link.

        To add details of my problem: within error text I found: “inconsistence in description detected: non-unicode length is too small”.
        Is there any way I can control type of SAP inbound call (Unicode, non-Unicode)?

        • Hmm, this error message is quite interesting…! Normally you should not need to care about Unicode/Non-Unicode, the RFC lib should do it automatically. So this may be a bug here. But can’t say for sure now, will need to wait until I get the time to look at the example.

          What is your backend release and is it Non-Unicode?

          Regards, Ulrich

          • By decremental reduction of parameter list of this function I found out that this error is raised when I add table parameters in SAP like this:
            *”  TABLES
            *”      TAB_DAT TYPE  DATUM_RANGE_TAB

            Is it possible to use table parameters?

          • Hello Bartlomiej,
            I think I finally know what the problem is. Of course using tables in RFC is no problem, that’s a standard feature. The problem rather seems to be an inconsistency in your DDIC. I tried to reproduce it here, but our 6.40 test system doesn’t have the types “CCVX_MATNR_TAB” and “DATUM_RANGE_TAB”?! Are these standard SAP types or custom developments?
            Anyway, I think one of these types must be broken: the error message “non-unicode length is too small” is throw, if the total length of a structure is smaller than the sum of all field-lengths of that structure. So something must be incorrectly defined in the DDIC here.

            To test whether this theory is ok, can you change the two tables to TYPE BAPIRET2? This is an old structure, that should be ok in any case. Once we know which of the types has a problem, we can then take a closer look at it.

            Regards, Ulrich

          • Hi Ulrich,

            Both types are SAP standard (at least its creator is SAP).
            I changed them to BAPIRET2 and problem disapeared.
            Thank you for you help.

            Regards, Bart³omiej

          • Hi Bartlomiej,
            ok, that shows there’s something wrong with these structures. I recommend to look at their attributes. Here the “Package” field should give you an idea, to which application these structures belong, and then you can open a message on the corresponding OSS component for that application.

            Best Regards, Ulrich

  • Hi,

    I get following error from RFCOPenConnection:
    “ESAPException: code: 3 group: 2 key: CALL_FUNCTION_NOT_FOUND message:
    Function module “R” not found.”

    It started to popup suddenly, earlier everything worked OK. I found no notes about mysterious function “R”. What can be the reason of it?

    I’m on 4.7 Enterprise (SAPKB62055).

    Bart³omiej Ko³odziej

    • Hello Bartlomiej,
      very strange. No idea at the moment.
      Can you find any log messages regarding this error in the backend’s system log (SM21) or shortdump log (ST22)?

      I know that during logon the function module “RFCPING” is executed. Perhaps the name of that function module is for some reason truncated to “R”, so that the backend no longer recognizes it?! Has the backend been converted from Unicode to non-Unicode recently? In that case a possible explanation would be, that your RFC program still “thinks” the system is Unicode and consquently sends the function module name in Unicode format (two bytes per char). That would then be
      52 00 46 00 43 00 50 00 49 00 4E 00 47 00
      R     F     C     P     I     N     G
      The backend system (being now non-Unicode) would then interprete the second byte of the character “R” as the terminating zero of the string… 🙂

      In that case a simple restart of the RFC application would suffice: it should then fill it’s metadata cache freshly from the backend’s DDIC and recognize the system as non-Unicode.

      Regards, Ulrich

      • I got logs for this from SM21 for this problem. If you open upload link for them I can send you the files.
        Nothing found in ST22 for this problem.
        • Hello Bartlomiej,
          I’m expecting a baby any day now, and then I’ll be gone for two months… Can you open an OSS ticket for this problem and attach the logs there? Then my other colleagues from the RFC team can take over as necessary and complete the investigation.
          Component is BC-MID-RFC.

          Best Regards, Ulrich

  • Hi,

    Is is possible to use other values then “DE” and “EN” for “lang” in RfcOpenConnection? I try to connect in “PL” but I get error: “Use one of installed languages: (case sensitive)”. Is it a feature of NW RFC SDK or something is misconfigured on my Windows system?


    • Hello Bartlomiej,
      in general it is possible to use “every” SAP logon language with the NW RFC SDK.

      The error message “Use one of installed languages: (case sensitive)” is an error coming back from the R/3 backend. So this means that “PL” is not installed on the R/3 system to which you are trying to connect.

      Regards, Ulrich

  • Hi Ulrich.

    I’ve write desktop application that using NW RFC library. On many computers under WinXP, Win2k, Vista all work correct.
    But I have one client under Vista Home Premium, that can’t connect to R/3 via NW RFC. Here error from RfcOpenConnection:






    LOCATION    CPIC (TCP/IP) on local host with Unicode

    ERROR       gethostname failed

    TIME        Fri Mar 14 08:30:57 2008

    RELEASE     710

    COMPONENT   CPIC (TCP/IP) with Unicode

    VERSION     3

    RC          485

    MODULE      r3cpic.c

    LINE        11417

    SYSTEM CALL NiMyHostName

    COUNTER     3








    NW RFC version 7.10 patch 1
    All connection parameters is correct. From this computer user can connect to R/3 via SAP Logon.
    Connection will performed via SAP Routers.

    Best wishes,

    • Hello Dmitriy,
      looks like a more difficult problem. I recommend to open an OSS message under BC-MID-RFC for this. (You should also provide the exact Vista version and the network/hostname settings on that machine, so we can reproduce it on an identical machine overhere.)

      In general I can say, the NW RFC SDK has not yet been tested/released for Vista. We plan to release a “Vista validated” version this summer.

      Best Regards, Ulrich

    • Hello Bartlomiej,
      the server functionality of the NW RFC library only accepts RFC requests from an R/3 application server. “Extern-to-extern communication” is no longer supported.
      Here it looks like another external RFC client (JCo- or RFC lib-based) tried to connect to your RFC server.

      Regards, Ulrich

  • Hello,

    i built a small .net wrapper for the nwrfcsdk using C++/CLI and Visual Studio 2008. If i use this wrapper from within my c# application sometimes i get the exception “AccessViolationException” at RfcListenAndDispatch. This exception means that there is something reading or writing from/to protected memory.

    At first i thought that this can be some threading issue, but recently i saw it with one single thread too.

    I’m using the nwrfcsdc 7.1 and VisualStudio 2008. Are there any problems of the nwrfcsdk in combination with .Net?

    • Hello Roland,
      there’s one known problem regarding the combination NW RFC SDK + VisualStudio 2008: if you use some of the functions from sapuc.h (e.g strlenU, printfU, etc), it will lead to an access violation. Therefore my first guess is, that one of your server implementation functions (which get called internally from RfcListenAndDispatch) is using such a function.

      Solution: replace the “U-functions” from sapuc.h with the corresponding Windows “w-functions” from wchar.h. (E.g wprintf instead of printfU.) On Windows the SAP_UC data type is equivalent to wchar_t.

      Another question: why are you using the NW RFC SDK? On you’ll also find a “SAP .NET Connector”, which eliminates the necessity of writing your own wrapper around the NW RFC SDK.

      Regards, Ulrich

      • Hello Ulrich,<br/><br/>first, thank you for your fast answer.<br/>I don’t use any U function anywhere. I’ve coded a single function wich converts strings from .Net into SAP_UC ones:<br/><br/>static SAP_UC ConvertToSAPString(System::String^ csString)<br/>{<br/>    //Prevent nullpointer<br/>    if(csString == nullptr){ csString = String::Empty; }<br/><br/>    //Allocate space for result string<br/>    SAP_UC* result = new SAP_UC[csString->Length + 1];<br/><br/>    //Converts the string itself using a .Net char array<br/>    for(int loop=0 ; loop<csString->Length ; loop++)<br/>    {<br/>        result[loop] = csString[loop];<br/>    }<br/><br/>    //Write null-terminating character to the end of the string<br/>    result[csString->Length] = 0;<br/><br/>    return result;<br/>}<br/><br/>If i don’t need that strings anymore i delete them using delete[]. This should be the correct way, isn’t it?<br/><br/>To your question: I’m not using the “SAP .Net Connector” because it don’t offers the functionality we need. We need an api where we can dynamically say, what functions to call. In the .net connector that names musst be clear at compile time. Another reason is that it seems to be obsolete. It’s .Net 1.1, no 64 Bit support and so on.

        • Hello Roland,
          other than that I have no initial ideas. Which means we need a closer analysis…

          Are you able to produce any coredumps/Dr.Watson information, which would show us a stack trace?

          If you can reproduce it in the debugger, can you set a breakpoint at the beginning and the end of your server implementation? This would then allow us to isolate the error, i.e. it could be in RfcListenAndDispatch *before* calling the server function, it could be in the server function itself and it could be in RfcListenAndDispatch *after* calling the server function.

          Also if you are able to create a small minimal testcase (without C#), I can analyze it overhere.

          Regards, Ulrich

          • Hello Ulrich,

            i get the exception within the debugger as well, but within the c# debugger… i think that is no much use for you.

            The error pops up very little times. Sometimes my test application runs more days without interruption and without errors. And sometimes it breaks just after a minute.

            As you wrote, i will create a little testcase using just C++/Cli for you to analyze the error


          • So, it’s ready for testing.
            You find a little test example at

            It can be started in both modes, as c++ executable (Just set compile options to exe) and as .Net executable (Just compile c# project and set the c++ project’s mode to dll)

            If i run the example with c++, i get no accessviolation, but i recognized that there are internally some c++ exceptions thrown. Maybe these ones are responsible for the error?

            If i run the example with c#, i get the accesvialation. Just click ok on the messagebox very often and you will see it, too.

            By the way, i don’t have included the nwrfcsdk. You need to copy the library files for 32 bit into /RfcTestLibrary/rfclib/lib_32 and the dlls into /Debug and /TestCSStarter/Bin/Debug

            I hope that is all you need


          • Hello Roland,
            I tried to look at your example today, but I could not open the project: we don’t have VS 2008, yet, here at SAP…

            However, from looking at the code I have one idea, what the problem might be:
            In FunctionDescLookup() you return one hard-coded function description handle for all lookup requests. You say that the backend system will only execute this one function module on your server, but what if for some strange reason some other function module would be executed on that RFC destination? RfcListenAndDispatch() would create an RFC_FUNCTION_HANDLE from your s_serverFunctionDesc and then try to write the input data of the other function module into that RFC_FUNCTION_HANDLE, which could easily lead to a crash. And no one can guarantee, that the SAP system sends only requests for this one function module to the RFC destination of your server program!

            I recommend to check the functionName parameter inside FunctionDescLookup() and return RFC_NOT_FOUND, if the name doesn’t match the expected function name. That will eliminate problems like the above.

            If that doesn’t fix the problem, there are a few other points to try:

            1. If it is really the case, that the application doesn’t crash as C++ application, only as C#, then this seems to indicate, that the problem is not inside the sapnwrfc.dll, but in the interoperability of C++ and C#. But that would be for Microsoft to debug, not us…

            2. Do try to create a crash dump file using the Microsoft tools described at
            I can send you a debug version of sapnwrfc.dll and a pdb file, then we can see the exact stack trace at the point of the crash.

            Best Regards, Ulrich

          • You can just copy the sources into a new VS 2005 project, this should be no problem.

            The return of RFC_NOT_FOUND or the new sdk version do not fix the problem, it’s still here.

            I think it would be the easiest way for us if you send me the debug-version and pdf file. If it’s an interop problem, i would clearly see it then

          • Hello Ulrich,

            thank you for the debug dll, but my problem is now i can’t execute my program with it. Each time i wan’t to start it with the debug dll and lib file, a error message pops up. It says that the programm requested an unusual abort. May be it can’t load the dll, or something?

            I uploaded the testproject for VisualStudio 2005 for you: You have to copy the rfc sdk files into the directorys described some posts ago.

            I will try it again tomorrow, maybe i will get it working then.


          • Hello Roland,
            I’ve seen the error about the “abort in an unusual way” before. So far it has always been caused by this: the correct version of the C runtime (msvcrt80.dll) was missing on that computer. But in your case the correct version must be installed, as otherwise the optimized sapnwrfc.dll wouldn’t work either?!
            Ah, wait a moment: please check your project properties under “C/C++  –> Code Generation”. Does “Runtime Library” say “Multi-threaded Debug DLL (/MDd)”? In this case switch it to “Multi-threaded DLL (/MD)”, that should fix it. Windows can’t run a process in debug mode, if two modules have different runtime settings. So your executable needs to use the same setting as the sapnwrfc.dll, which was compiled with /MD.

            I looked at the VS2005 project and I have another idea, what you could try: I noticed that in the Preprocessor settings the “Preprocessor Definitions” include only WIN32 and _DEBUG. You also need to specify SAPwithUNICODE here, otherwise all SAP_UC data types have only one byte per char instead of two. This would then explain the sporadic crashes: lets say your function module has a CHAR10 field. As long as this field is filled with only 5 chars, everything is fine, but when a funciton call arrives from the backend, where this field is filled with 6 or more chars, the RFC lib will write beyond the boundaries of the array, when filling the data container, and this will cause the access violation.
            And also set the definition SAPonNT.

            Best Regards, Ulrich

          • Hello Ulrich,

            i changed /MDd into MD, but this doesn’t fix the problem. I have added the parameters SAPwithUNICODE and the other one directly to the comandlineparemters of the C++ compiler.

            There was some sap note where the compiler params on windows are documented, i think. I will search and try these ones today afternoon.

            Another question: Can you reproduce the error on your machine with my VS2005 project?


          • Hello Ulrich,

            ok, i tried this now with some combinations of compile parameters, nothing seems to work here. Maybe the problem is not the sapnwrfc.dll but one of the other dlls. Maybe they are incompatible with the current debug version?

            In the meantime i have tried to wrap some parts of the nwrfc sdk with pure .Net interop, meaning that i don’t use any c++/cli code and let .Net doing all the work for me. Most wrappers i saw are based on this technique, so that should work fine. But after executing a example program i got the same AccessViolationException, on the same place as before.

            So, it seems to be an error in .Net or in the rfcsdk. We’ve desided to downgrade to the old version of the sdk, because we need the rfc-functionality very soon.

            Regards, Roland

          • Hello Dev,
            yes, SAPwithUNICODE is mandatory! Internally the NW RFC library uses two-byte-per char for everything. So if you omit that pre-processor parameter, it means that you are passing arrays of size one-byte-per char to the lib, and it will certainly write past the end of an array at some point.

            Note however, that this does not effect the ability to communicate with non-Unicode backends: the NW RFC lib (and your programs) work the same independently of whether the backend is Unicode or non-Unicode. (This is one of the big benefits in my opinion: one program supports several backend versions and no adjustment of the external program is necessary, if backends get upgraded.)

            Regards, Ulrich

    • Hello Ken,
      yes, the NW RFC lib can be used for communication with 4.6C backends, and this is fully supported.

      However in practise there may be a few problems: 4.6C is a “special” release in so far as there are two “flavors” of this release in existence:
      o  the original 4.6C (4.6C kernel + 4.6C ABAP part)
      o  4.6C updated with a backward compatible 4.6D kernel

      The NW RFC lib (or more precisely the function RfcGetFunctionDesc()) uses a DDIC feature, which has changed between ABAP 4.6C and 4.6D. In the beginning the distinction between these two cases was not yet done correctly in the NW RFC lib. See also SAP Note 1056472, point 10, where one particular problem has been fixed for patch level 1. Another problem with 4.6C/4.6D has just been discovered last week and will be patched with patch level 3.

      In general I have to say: it may happen that the function RfcGetFunctionDesc() fails when trying to retrieve a function metadata description from a 4.6C or 4.6D DDIC. If you find during testing that one of the function modules your application wants to use, is affected by this problem, just open a message under BC-MID-RFC, so we can fix it.

      Best Regards, Ulrich

  • Hi,
    I’m using this NW RFC for having some BAPI calls on the remote sap system.
    I wonder if there is an option to encrypt the session I working with, because during my calls I create some passwords and some data that I don’t want to be sent as plain text!!!
    • Hello Shlom,
      the answer to your question could be “SNC”. SNC is to RFC, what https is to http. You need another library (the sapcryptolib or third-party implementations like Secude, Kerberos, Microsoft NTLM…) and a corresponding certificate. Also the backend system needs to be setup to use the same mechanism.

      Details can be found in the “SNC User’s Guide”: –> Security in Detail –> Secure User Access –> Authentication & Single Sign-On.

      Once SNC is set up on R/3 side, it’s quite easy to use on RFC library side. (See the hints in sapnwrfc.h or also my article in the March/April issue of SAP Professional Journal…)

      Best Regards, Ulrich

    • tx. if the R/3 system is not configured to work with SNC it will not work?
      2. usually SAP systems support SNC by default – is this common used?
      3. If I have some program that does some BAPI calls already – will I have a lot of changes for using SNC or just little changes in the connetion?
      4. can you give me some code example for how to create encrypted session?

      tx in advance!

      • Hello Shlom,
        1. Right.
        2. As a matter of fact, it’s a bit of an effort to setup SNC on R/3 side. Better ask the sysadmin of your target system.
        3. On external side it’s quite easy:

        • install the security product
        • set the environment variable SNC_LIB, so the RFC lib can find it
        • add the SNC parameters (see documentation of RfcOpenConnection) to the set of logon parameters

        That’s it.
        4. No code changes necessary compared to the “plain” communication.

        Regards, Ulrich

  • Hello. I have some troubles with codepages. Get information about own codepage is simple via function GetConnectionAttributes, but I don’n know to set it. Thank you for your advices.
    • Hello George,
      the answer is easy: you should no longer need to set any codepages, therefore the NW RFC lib does no longer allow you to set it…!

      The lib automatically chooses the correct codepage for the current backend and that should solve all problems (in theory). At most it should be necessary to set the correct logon language (like JA for Japanese) to give the RFC lib a hint, if multiple languages are possible.

      If you think, something doesn’t work right in your particular scenario and you can’t get the data accross the line correctly, you should open a support ticket on BC-MID-RFC, so we can investigate it closer.

      Regards, Ulrich

  • Hello,
    I have problem with strings conversion. How to convert SAP strings (SAP_UC*) to C strings (char* or std::string). I haven’t found any articles about this topic. There are specials functions (for example strstrU or mallocU), but other C components (like occi for Oracle support) using C strings.

    Best regards. George

    • Hello George,
      if you have only ASCII data (because the backend R/3 is “EN” only), then just use RfcSAPUCToUTF8(). For all codepoints below 0x7F ASCII and UTF-8 are equivalent.

      Otherwise (i.e you have Eastern or Western European special chars or even Japanese), the answer depends on your platform. Windows, Unix or Linux?

      Regards, Ulrich

        • Hello George,
          on Linux support for UTF-8 is pretty much built into the OS, so the first try would be, if you can perhaps feed the UTF-8 bytes directly into the occi functions.

          If that doesn’t work, check out the following:

          On Linux (and most Unix) the SAP_UC type is an unsigned short containing UTF-16LE. You can use the iconv functions to convert either from UTF-16LE to ISO-8859-X, or from UTF-8 to ISO-8859-X.

          Best Regards, Ulrich

  • Hello,

    can somebody help me?
    I have made a software in visual c++ 2005 using sapnwrfc.lib (release: i use the library in the file NWRFC_2-20002217.SAR, Version:7.11 patch 0). This software uses more and more memory each time I call RfcOpenConnection and RfcCloseConnection. Then I made a an other software with this simple loop:

    RFC_CONNECTION_HANDLE myconnection;
    myconnection = RfcOpenConnection( loginParams, 8, &errorInfo);
    if (myconnection != NULL)
    RfcCloseConnection( myconnection, &errorInfo);

    and it also uses more memory at each step of the loop. I suppose, I have to free memory used by myconnection handle, but how to do this ?

    Thanks in advance


    • Hello Pol,
      in fact, we already found a memory leak in RfcCloseConnection(), which will be fixed in the upcoming 7.11 patch level 1.

      It could be, that this is the same thing you are reporting. However, the one that got fixed now, is only a few bytes. You would need a large number of iterations of your loop to actually feel it. So either you are opening&closing A LOT of connections, or you still found something different?! In any case you should repeat your test after the next patch (which will come out in one or two weeks), and if it didn’t go away, we’ll need to profile it in more detail.

      Best Regards, Ulrich

      • Hello Ulrich,

        Thank for your response,
        I’m waiting impatiently this new patch,
        I’m writing a software for real time data bases synchronisation between SAP systems and external data bases. This software must run 24/24 hours and 7/7 days, it’s the reason why I can not have a memory leak.
        In this software, there are a lot of threads some of them use a client connexion for data from external data bases to sap, and the others are server connexions for datas from SAP to external data bases.

        I think that there is probably a another problem with RfcInvoke when we use it with a large amount of data parameters. I will before check my software before post a new message on the blog,  if this is right.

        Thanks in advance for your help.

        • Hello Pol,
          the next patch level (which is now called 7.11 PL 1) has been released yesterday. See the standard download note for an updated link. Let me know, whether that shows an improvement for your memory issue.

          Regards, Ulrich

  • Hello,
    I can not switch trace on.
    I use RfcOpenConnection with parameter “trace” set to 1,
    After when i check connexion attributes with RfcGetConnectionAttributes, trace is set to 1, but the software does not generate any trace file. Why ?
    Thanks in advance.
    • In patch level 2 tracing had been turned off, because it was only annoying instead of useful. In patch level 3 (which was released yesterday, see the standard download note for an updated link) tracing was completely redesigned. See the documentation of the new function RfcSetTraceLevel() in the header or in the doxygen documentation.

      Best Regards, Ulrich

      • Hi Ulrich,

        1. If I don’t have the RfcSetTrace in my H files – does it mean that I don’t have the 2rd level patch?
        2. How can I know which patch level I have – the version of sapnwrfc.dll is 7110.0.15.6533
        I extracted NWRFC_2-20002217.SAR

        3. Is there any way to avoid creating the trace in my rfcsdk?

        tx in advance,

  • Hi all,
    this is the 100th comment on this blog, and it should be the last one… As the comments are getting more and more difficult to disentangle, I’ve started a new blog: see the link given in the updated last paragraph of the current blog.

    Please keep questions coming in via that new blog!

    Best Regards, Ulrich

    • Hi:
      I need to expose SAP remote function calls to Visual Basic 6 applications using nwrfcsdk. However, programmers of VB6 don’t want to directly call SAP rfc functions and send/receive SAP data formats, they would like to call a C++ DLL COM which calls the nwrfcsdk library, moves data to a C++ array of structures and pass it to VB programs.
      Before trying to attempt a solution to this requirement in the suggested way, I would like to know if it’s a recommended way or if there is a better and optimal one. If yes/no, I would like to receive some guidelines/recommendations before starting.
      My best regards.
    • Sorry, no updates on this one. We are trying to get approval for a free SDN download for years now, but SAP’s bureaucracy ****.

      Be patient, it can only be a matter of centuries now. Until then, only registered S-Users can download from the SMP as described in note 1025361.

      Best Regards, Ulrich

  • Hello Former Memberh,

    We have a multithreaded application where we create the server using RfcRegisterServer API. If we start single application everything works fine or multiple application after 30 sec. it works fine. However, if we start the application in parallel mode( without any delay between two processes) the connection between two server gets changed and on the same handle, I can see the batch jobs name changed between two server connection. Here with I am attaching one document with more information.


    From our application, we start the batch job and batch job executes the ABAP report to collection data. but due wrong ABAP report name is assigned it is giving the dump.



    Here both process start one batch job and execute the ABAP report to collet the data. However due the batch jobs name it is not executing the correct where condition which is passed from client.


    Question : Is they any parameter which we need to set so the job name will not be switched between two connections.

    Why the connection id’s switching the jobs name.