Skip to Content

NetWeaver RFC gives the Next generation Ruby and Perl Connectors

SAP has undertaken a project to re-engineer the RFC SDK (creating the SAP NetWeaver RFC SDK), which is good news for the Connectors (RFC APIs).

This means that eventually – all the RFC connectors, and 3rd party products will need to be updated to use the new under-carriage.


So whats the big deal?

RFC is a stable technology, and has been for many years, so I can understand why this revelation may not seem very exciting. What is exciting is the unprecedented level of cooperation, understanding and good will that has come out in a relatively short time, as I have moved through the process of redeveloping the Ruby and Perl RFC Connectors. The result is (and will be more so), a better fit in terms of how the SDK works with Dynamic Languages, allowing the API that the Dynamic Languages offer for RFC connectivity, to better reflect the nature of those programming languages. For example – there are better features in the new NW RFC SDK that allow for easy translation of ABAP types to Ruby/Perl types.



New Features

If we set aside the rationalisation, and simplification of the NW SDK (which is a bonus in itself), there are new features of the NW SDK that can be drawn upon –

  • unicode in the core, with utf-8 to utf-16 conversion tools
  • intelligent ABAP <=> X helper functions to ease type translations
  • deep structures
  • interface discovery
  • interface, and structure caching


This has lead to a complete overhaul of the Ruby, and Perl Connectors, with the aim to take advantage of the new NW SDK features, and to produce connectors that create a more intuitive bond between the underlying RFC API, and the natural features of each Dynamic Language.


Call for testers

As the new Ruby and Perl RFC Connectors are a complete rewrite and Alpha, I am calling for testers/early adopters from the Community.



Obtaining the Connectors, and Netweaver RFC SDK

Download the new sapnwrfc connector for Ruby, and get the new RFC SDK, port your applications to it, and let me know how you get on. I’m interested in usability feedback, problems, and feature requests.


For Ruby – download from the RAA. Follow the instructions in the included README file. Documentation is available Here. A GEM install package for Win32 has been built available here.

For Perl – download from CPAN. Again – follow the instructions in the included README file. Documentation is available Here. A PPM install package for Win32 has been built available here.

If you are interested in trialling/testing the new connectors, then along with the installing the new connectors (above) you will need to obtain the new Netweaver RFC SDK. in order to do this, please register your interest through the comments, ensuring that I know how to contact you, and what your platform requirements are, and with the help of the NW RFC team I will get the relevant details to you (Please see notes below).


Ruby Examples

There are plenty of examples in the tests/ directory of the sapnwrfc download, but here is a basic walk through of the new API:

# specify a YAML base config file or pass connection
# parameters directly to rfc_connect()
SAPNW::Base.config_location = './config_file.yml'
conn = SAPNW::Base.rfc_connect

# get the system and connection details
attrib = conn.connection_attributes
$stderr.print "Connection Attributes: #{attrib.inspect} "

# lookup the dictionary definition of an Function Module
$stderr.print "Parameters: #{fds.parameters.keys.inspect} "

# create an instance of a Function call
fs = fds.new_function_call

# populate the parameters - structures and table rows now take hashes of field name/value pairs
fs.IMPORTSTRUCT = { 'I' => 123,
'C' => 'AbCdEf',
'STR' => 'The quick brown fox ...',
'XSTR' => ["deadbeef"].pack("H*") }

# execute the RFC call
$stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect} "
$stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect} "


Config file (refer to the sap.yml file in the download):

sysnr: "01"
client: "001"
user: developer
passwd: developer
lang: EN
trace: 2


Test it out – and give your feedback.


Perl Examples

As with Ruby, there are plenty of examples in the software download in the t/* directory. Again – here is a taster showing the new API:

use sapnwrfc;
use Data::Dumper;

# specify a YAML base config file or pass connection
# parameters directly to rfc_connect()
my $conn = SAPNW::Rfc->rfc_connect;

# lookup the Function Module
my $fds = $conn->function_lookup("STFC_DEEP_STRUCTURE");

# initialise a call instance
my $fs = $fds->create_function_call;

# set the parameters
$fs->IMPORTSTRUCT({ 'I' => 123,
'C' => 'AbCdEf',
'STR' => 'The quick brown fox ...',
'XSTR' => pack("H*", "deadbeef")});

# invoke the Function Module and then play with the results
$stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect} "
$stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect} "
print STDERR "RESPTEXT: ".Dumper($fs->RESPTEXT)." ";
ok($c eq 'AbCdEf');
print STDERR "ECHOSTRUCT: ".Dumper($fs->ECHOSTRUCT)." ";

# cleanup


Config file format is the same as for Ruby – refer to the sap.yml file in the download:

sysnr: "01"
client: "001"
user: developer
passwd: developer
lang: EN
trace: 2


Test it out – and give your feedback. The best place would be to carry on the discussion through the /community [original link is broken].

Special thanks go to:

  • Ulrich Schmidt for fielding all my questions, and the whole of the NW RFC Team (NW AS ABAP Connectivity), for their support, and quick response.
  • Olivier Boudry – building and testing
  • and lastly (but by no means least) Craig Cmehil for tirelessly getting people together and making it all possible.



More recent Notes:-)

SAP has released the official NW RFC SDK. For more details read SAP NW RFCSDK – it’s here!.



 The permanent home for the NW RFC SDK is now:

  -> Entry by Application Group

    -> Additional Components

      -> SAP NW RFC SDK

        -> SAP NW RFC SDK 7.11

          -> SAP NW RFC SDK 7.11

You must be Logged on to comment or reply to a post.
  • Congrats on this, Piers.  It’s great to see you working directly with some of the guys at SAP to make this happen.

    I will be happy to help testing.  I can test doing some Ruby on both NW04 and NW04s.  I will need the Windows RFC SDK.


  • Piers –

    For keeping your eye on the REAL ball, much congratulations and gratitude should come your way.

    Often times, what advances IT (or a particular company) is NOT new technology tricked-out in whatever buzzwords and bling happen to be in fashion.

    It is new technology stripped to its unglamorous essenatials.

    Of course, it is also to SAP’s credit that as a company, it recognizes the need to deliver unglamourous technology as well as the rest of the glam stuff cluttering up SDN and too many other web-sites.


  • To all “volunteers” out there:

    The new SAP NW RFC SDK will be delivered through the usual official channels (SAP Market Place) soon (hopefully in the beginning of Q2, but please don’t take this as a “legally binding statement”…).

    For now there are pre-release versions available for download via SAPMats container. During the ramp-up phase the following 7 platforms will be supported: Windows x86 32bit, Windows x86 64bit, Windows Itanium, Linux x86 64bit, Solaris SPARC 64bit, HP-UX PA-RISC 64bit and AIX 64bit.

    The following OS releases have been used for compiling/testing the SDK: Windows 2003, SuSE SLES9, RedHat EL4, Solaris 10, HP-UX 11.23, AIX 5.3. (Others may be ok, except for two: Windows Vista and SuSE SLES10. There are just too many incompatibilities compared to Win2003/SLES10 respectively. So please don’t try these yet, they will most definitely lead to problems.)

    So for all of you volunteering as testers for Piers’ Ruby and Perl Connectors: check the download links at the end and have fun!
    If you have trouble compiling the Connectors on the Unix Platforms, Piers and me will certainly try to help you.

    I also want to thank Piers for making this happen! He really put in a lot of determination and hard work! Originally we only planned to do the Ruby Connector, but then he “caught fire” and did the Perl Connector as an “encore”…
    Thanks a lot!

    Ulrich, RFC team

    ______________________________________________     6188986 byte     6605960 byte 7926295 byte    9550190 byte   12450563 byte  12884211 byte

    (AIX is still causing a bit of a problem at the moment, but I will provide the last missing link as soon as we got it to compile…)

    • Funny you should mention Python – I’ve been debating where I would place Python in my priorities to get done.  Python has always been the Connector that I had the least user contact from, so I have always assumed that it was the least used.  But – something interesting that I read recently – is this:
      I think Python maybe picking up a bit of traction, because of Perl6 issues with Perl, and the fact that it is used by some high profile outfits such as Yahoo, and Google.
      So- yes – Python is in the pipeline – but I’ve got my hands full with Ruby, and Perl, and looking for a new job at the moment.
  • Please note the download links have been updated to the latest available, and the AIX SDK has been added.
    Eventually these will all be replaced with the proper product download links.
  • Filling importing RFC-parameter of type Char with a perl’s number leads to RFC call error.

    $p = 8000000324; $rc->PARAM{$p}; # Bad
    <>; m/\d+/; $p = $& $rc->PARAM{$p}; # Bad

    $p = ‘8000000324’; $rc->PARAM{$p}; # Good
    $p = 8000000324; $p.=”; $rc->PARAM{$p}; # Good

    It’s likely to be converted automatically, because every string might looks like a number.

    PS. Thanks for a great job.

    • in the case of RFC type CHAR, then it should generate an error if the value passed in is not a string (internal a PV).  Infact for all the RFC primitive types (INT, CHAR, NUMC, etc), sapnwrfc expects the closest Perl scalar type as an input value – hence the error you see when you give a CHAR type an int.
      • Well, I see. But this behaviour is unexpected as far as it contradicts perl’s ideology. Type conversion is implicit and adaptive, it aims not to produces errors if it can be handled by most expected way.

        Inexperienced perl’s user as a rule does not know, that string literal ’11’ implicitly converted to int. And perl does not destine to surcharge one.

        Experienced user should always add a trick conversion .” for every CHAR argument, because, if a string looks like a number, perl every time converts it to INT. While loading data provided by user input or a file, we must not expect that every string contains at least one non-digit.

        So, in my opinion, it natural to check and convert types in connection.dll. At least INT to CHAR. It costs just a few if clauses but gives a real comfort fot users.

        • While what you say is perfectly true, IMO I prefer the type checking in place, as it guards against a certain type of silent failure by not coercing input values into the required source type, without the user knowing.
          • Well, than you for explanation. I was too rough that perl converts string to int every time. It occurs just when it needed.

            Nevertheless concerning NUMC ABAP type it’s true, because validating user or file input with /\d+/, result gets type IV and one needed to convert it back to PV before using with the module.

            Excuse me for insistence, but converting INT to CHAR will never cause an error or any kind of mistake, as well as INT to FLOAT.

          • Yes – I accept that.  There are definitely exceptions to this that should be applied.  NUMC could take int, and string, and yes – FLOAT could take int as well as double.
          • Converting INT to fixed length CHAR is right padded with spaces. And it’s just what the SvPV() do. It’s most natural.

            Just the same way INT converts to FLOAT by the SvNV().

            Converting INT to NUMC is left padded with zeros. AFAIK, there is no corresponding function in perl API. It needs special, but quite simple, handling.

            On the contrary, providing CHAR for a NUMC argument of an RFC f.m. is possibly erroneous and may raise an exception.

            Any conversion should cause an exception in case of data length overflow. E.g. converting INT > 99 to NUMC(2). 

            But why not to convert CHAR to INT when it possible and raise an exeption otherwise? If a perl user have had declarative tools to keep a variable strictly typed and to perform explicit convertion, I’d agree with you. But preventing implicit conversion from pure numerical CHAR to INT in perl doesn’t improve safety but just complicate perl code.

            In any case, a perl user will always use $_.=” for char arguments and $_+=0 for integer. And it’s has almost the same effect as an implicit conversion, let alone additional runtime warnings before RFC call fails.

            On the other hand, I’m agree that while adding .=” and +=0 a user will be obliged to take a look on a f.m. interface definition. And these additions leave traces of argument types and plays role of type declaration that missed in perl syntax.

            Well, it’s rather philosophic issue.

          • Passing String to NUMC allows the new SAP NW RFC SDK to handle the validation of the data – infact this shows another one of the design principles that I wanted to achieve with the sapnwrfc – namely creating a thin veneer over the SAP NW RFC SDK.  There is bound to be a trade off in this approach verses trying to achieve a natural Perl, Python, or Ruby approach.  At the moment, the level I have implemented across these 3 languages makes the underlying code very similar indeed – a bonus IMO in that it not only makes it easier to maintain all of them, but makes the knowledge a user gains from one transferable to another.
  • Any plans to port this to HP UNIX on  the IA64 platform?  I assume that the HP-PARISC package can run in ‘compatibility/emulation mode’ on IA64 but it would be better to have a native port distribution.
    • Platform availability is largely dependent on what SAP intend to support, crossed with what Perl/Ruby/Python support exists.  Once you have those two things lined up, I’m happy to help out with working through what compile time issues you may come across build the sapnwrfc package/s .
  • Hi
    I am developing a small rails applications; I dont want to store userid/password in the yml file but would like to get it from user and connect; how do I do that? I tried using SAPNW::Base.rfc_connect(with parameters like :user => “XXX”) and it does not work

    Any help is appreciated

    • If you overload the method SAP4Rails::Base#load_config to return a Hash of config of your choice, thne you should be able to inject connection data of your choice.