We have converted code which used to use the classic RFC libraries to use the Netweaver RFC libraries. Because we are doing BC-XOM, we are executing outside of SAP and often we are executing on a server which does not host an SAP system.
The switch from having the RFC library available in archive form (.a) to shared objects may make good sense to SAP and many of its users, but is problematic to us. With the archive form, we were able to statically link the library to our program which performs callbacks and that was that. The program installed on a customer's machine and ran - no problem. With NWRFC, we are forced to link against libraries that are beyond our control. This causes potential stability problems. If the loader can't find the libraries, the program using them will simply fail to load and run. This program has other responsibilites besides SAP callbacks, so its failure has effects beyond loss of SAP function. We understand we can't redistribute RFC library binaries, so it is up to the customer to have them "properly" installed, even on non-SAP systems.
Issues:
- Where is the proper place to install/find these libraries on SAP systems?
- Should they already be there on an SAP system?
- Is there a defined, programatic way for a non-SAP program to locate the RFC libraries at install time or run time?? Do SAP systems always install at /usr/sap/SID or c:\SAP\SID ? (Guessing no...)
http://service.sap.com/sap/support/notes/1739797 says libraries should be placed into the DIR_EXECUTABLE directory. On our Linux testdrive system, I see RFC library files in /usr/sap/NPL/DVEBMGS42/exe and /usr/sap/NPL/SCS00/exe. There's a poor match between the library files in the RFCSDK and the exe directories:
/usr/sap/NPL/DVEBMGS42/exe # ls libicudata* libicudecnumber* libicui18n* libicuuc* libsapnwrfc* libsapucum*
ls: cannot access libicudecnumber*: No such file or directory
ls: cannot access libsapucum*: No such file or directory
libicudata.so.34 libicui18n.so.34 libicuuc.so.34 libsapnwrfc.so
I imagine the .sl.34 and .so.34 difference will be internally resolved. The absence of libsapucum and libicudecnumber concerns me because I'm supposed to link against those, right?? This test system is 3 years old... Guess I need to grab a current trial. Are we likely to get into trouble with trying to user older versions when compiled against a current library set?? I'm guessing we will not run pointed at the above directories. (I've been developing with the 720 patch 38 libraries.)
- Any recommendations installing on a non-SAP system? I'm guessing that one should just follow the system guidelines for adding a library in a system directory or create a new directory and add it to the system search path. Or put the libraries in our binaries directory if I can get the library search path to point there.
- Are there linker options for "lazy" runtime binding? In such a mode, references aren't resolved until they are actually encountered. So, if the program is not doing SAP things, it never hits the RFC calls and does not die if the libraries aren't right. I haven't found anything workable.
- Linker path options? I've played with the option RPATH (-rpath) to try to add the directory our binaries are in to the library search path. Unfortunately, our binary is setuid and that disables options like RPATH or environment variables like LD_LIBRARY_PATH for security reasons. Given that at link time we don't know where our application or the RFC libraries will reside, linker path options don't seem likely to be of much use.
At this point, I've decided to try using the dlopen(), dlsym() and dlclose() routines to manage the loading of the RFC libraries under program control. I will define function pointers to all RFC functions that we call, then use dlsym() to set them. I may be able to use macros to make the pointers appear under their normal function names, making the whole dynamic load thing transparent to the rest of the application. This should keeps the program self contained and avoid crashing if the libraries don't load. It also allows controlled searching of SAP directories (if there is a programatic way to determine where SAP keeps the RFC libraries.) The simple fallback will be to look in our own binaries directory, so the customer always has the simple option of plopping the RFC library files in there, or placing symlinks to the actual libraries. Maybe a symlink to the library directory...
Any suggestions would be greatly appreciated! If I've posted this in the wrong area please let me know so I can repost to the right place.
Thanks!
Rich