Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos


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...!

106 Comments
Former Member
0 Kudos
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,
shlom
eduardo_gironas
Participant
0 Kudos
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.
Eduardo.
Former Member
0 Kudos
All I care right now is where I can freely download the SDK for Windows.
Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
0 Kudos
Hello ulrich.schmidth,

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.
rbhuva
Participant
0 Kudos
Hello ulrich.schmidth,

How to use NWRFC SDK for an on Premise system from BTP platform.

 

Thanks,

Rajdeep Bhuva