- SAP Community
- Groups
- Interest Groups
- Application Development and Automation
- Discussions
- Re: SAP netweaver RFC - am I missing something obv...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
SAP netweaver RFC - am I missing something obvious here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2016 Jan 19 1:29 PM
- SAP Managed Tags
- ABAP Connectivity
Hi,
We're trying to create an extremely simple RFC server application using the netweaver RFC connector, based on Ulrich Schmidt's clear instructions here.
However we're having some fairly basic issues with these, plus the demo code provided with the NWRFC zip file, stfcDeepTableServer.c.
According to OSS note 1056696, the functions in sapuc.h are no longer available since VS2008 as many of the Unicode functions have been replaced in the standard library wchar.h, and that "the datatype SAP_UC is functionally equivalent to wchar_t*".
Unfortunately several of the standard rfc methods such as RfcGetString and RfcGetTable use SAP_UC in their method parameters.
How can we use the netweaver RFC library if these methods depend on a deprecated code? We can't even compile the demo program as-is. Is there a newer SDK available? Presumably we're not the only ones facing this issue, especially given that Visual Studio 2005 is no longer legally available.
Thanks for your help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2016 Jan 20 7:58 PM
- SAP Managed Tags
- ABAP Connectivity
Hi,
the main question of this post has already been answered in a different thread, but for others searching for the same issue it is probably better to repeat it here:
Basically it's a misunderstanding. The fact that the functions in libsapucum.dll (defined in sapuc.h) cannot be used in newer Visual Studio versions, does not mean that the RFC functions, which use the type SAP_UC, can no longer be used. In fact it should work without much effort: just include sapnwrfc.h as usual and use parameters of type wchar_t (or even SAP_UC, it doesn't matter, as sapnwrfc.h contains a "typedef wchar_t SAP_UC" somewhere in its interiors).
So sapnwrfc.dll does not have a dependency to the (deprecated) libsapucum.dll. And you only need to make sure that your program will stay independent of libsapucum.dll (by using the standard Microsoft "wide-character functions" for processing any Unicode strings that you get from the sapnwrfc.dll).
Untill a newer version of the NW RFC SDK is available, this approach only has one slight disadvantage, if you program for multiple platforms at once: on the Unix platforms by using libsapucum.so, you can write "platform-independent" code that compiles and runs everwhere, independent of whether the platform uses 2-byte Unicode (like AIX), 4-byte Unicode (like Solaris) or UTF8-based Unicode where one char could be between 1 and 5 bytes (like Linux). But for Windows you need an #ifdef and use different code...
BTW, one more comment for Windows: in Part 1 (page 4) of the series you cited above, there are sample settings for a Visual Studio project using sapnwrfc.dll. Even though they have been created for VS 2005, they should still work with VS 2008, 2010 and 2013, if you just omit the linker reference to libsapucum.lib. (I haven't tried VS 2015, yet.) Most of the Microsoft wchar-functions are contained in libs that are already automatically linked to your project (like kernel32.lib or user32.lib). Only some rare functions should need an explicit linker reference to something else.
Best Regards, Ulrich
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2016 Jan 20 7:58 PM
- SAP Managed Tags
- ABAP Connectivity
Hi,
the main question of this post has already been answered in a different thread, but for others searching for the same issue it is probably better to repeat it here:
Basically it's a misunderstanding. The fact that the functions in libsapucum.dll (defined in sapuc.h) cannot be used in newer Visual Studio versions, does not mean that the RFC functions, which use the type SAP_UC, can no longer be used. In fact it should work without much effort: just include sapnwrfc.h as usual and use parameters of type wchar_t (or even SAP_UC, it doesn't matter, as sapnwrfc.h contains a "typedef wchar_t SAP_UC" somewhere in its interiors).
So sapnwrfc.dll does not have a dependency to the (deprecated) libsapucum.dll. And you only need to make sure that your program will stay independent of libsapucum.dll (by using the standard Microsoft "wide-character functions" for processing any Unicode strings that you get from the sapnwrfc.dll).
Untill a newer version of the NW RFC SDK is available, this approach only has one slight disadvantage, if you program for multiple platforms at once: on the Unix platforms by using libsapucum.so, you can write "platform-independent" code that compiles and runs everwhere, independent of whether the platform uses 2-byte Unicode (like AIX), 4-byte Unicode (like Solaris) or UTF8-based Unicode where one char could be between 1 and 5 bytes (like Linux). But for Windows you need an #ifdef and use different code...
BTW, one more comment for Windows: in Part 1 (page 4) of the series you cited above, there are sample settings for a Visual Studio project using sapnwrfc.dll. Even though they have been created for VS 2005, they should still work with VS 2008, 2010 and 2013, if you just omit the linker reference to libsapucum.lib. (I haven't tried VS 2015, yet.) Most of the Microsoft wchar-functions are contained in libs that are already automatically linked to your project (like kernel32.lib or user32.lib). Only some rare functions should need an explicit linker reference to something else.
Best Regards, Ulrich
Bluesky