Blogs

Piers Harding

NetWeaver RFC gives the Next generation Ruby and Perl Connectors
Piers Harding 
Business Card
Posted on Feb. 28, 2007 06:07 AM in Ruby, SAP NetWeaver Platform, Scripting Languages, Emerging Technologies, Perl
Subscribe.Subscribe
Print. Print
Permalink Permalink
Share
Share

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

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'
 SAPNW::Base.load_config
 conn = SAPNW::Base.rfc_connect

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

 # lookup the dictionary definition of an Function Module
 fds = conn.discover("STFC_DEEP_STRUCTURE")
 $stderr.print "Parameters: #{fds.parameters.keys.inspect}\n"

 # 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
 fs.invoke
 $stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect}\n"
 $stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect}\n"

 

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

ashost: ubuntu.local.net
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()
 SAPNW::Rfc->load_config;
 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
 $fs->invoke;
 $stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect}\n"
 $stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect}\n"
 print STDERR "RESPTEXT: ".Dumper($fs->RESPTEXT)."\n";
    ok($c eq 'AbCdEf');
 print STDERR "ECHOSTRUCT: ".Dumper($fs->ECHOSTRUCT)."\n";

 # cleanup
 $conn->disconnect;

 

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

ashost: ubuntu.local.net
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 Forums.

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

 

Notes/Updates:

 The permanent home for the NW RFC SDK is now:

http://service.sap.com/patches

  -> Entry by Application Group

    -> Additional Components

      -> SAP NW RFC SDK

        -> SAP NW RFC SDK 7.11

          -> SAP NW RFC SDK 7.11

 

Piers Harding   is just another old SAP Hack

Comment on this article
Comment on this weblog
Showing messages 1 through 29 of 29.
Titles Only Main Topics Oldest First

  • How to pass user and password
    2007-09-07 13:27:16 BW Consultant Business Card [Reply]

    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
    thanks

    • How to pass user and password
      2007-09-08 00:23:39 Piers Harding Business Card [Reply]

      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.


      Cheers.

  • Availability for HP IA64
    2007-08-14 08:55:59 Richard Bernat Business Card [Reply]

    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.
    • Availability for HP IA64
      2007-08-14 09:14:46 Piers Harding Business Card [Reply]

      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 .
  • Perl's Int to RFC's Char conversion
    2007-04-25 03:41:12 sibrin w Business Card [Reply]

    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.

    • Perl's Int to RFC's Char conversion
      2007-04-26 02:26:48 Piers Harding Business Card [Reply]

      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.
      Cheers.
      • Perl's Int to RFC's Char conversion
        2007-05-29 08:47:28 sibrin w Business Card [Reply]

        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.


        • Perl's Int to RFC's Char conversion
          2007-05-29 20:56:21 Piers Harding Business Card [Reply]

          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.
          Cheers.
          • Perl's Int to RFC's Char conversion
            2007-05-29 22:56:22 sibrin w Business Card [Reply]

            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.

            • Perl's Int to RFC's Char conversion
              2007-05-30 00:48:10 Piers Harding Business Card [Reply]

              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.
              Cheers.
              • Perl's Int to RFC's Char conversion
                2007-05-30 11:32:32 sibrin w Business Card [Reply]

                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.



                • Perl's Int to RFC's Char conversion
                  2007-05-30 12:00:41 Piers Harding Business Card [Reply]

                  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.
                  Cheers.
  • NW RFC SDK updates and AIX
    2007-03-27 09:58:24 Piers Harding Business Card [Reply]

    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.
    Cheers.
  • Python?
    2007-03-06 04:46:37 Andrew Barnard Business Card [Reply]

    And news to share about support for Python?
    • Python?
      2007-03-06 06:05:55 Piers Harding Business Card [Reply]

      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: http://radar.oreilly.com/archives/2007/03/pycon_a_hiring.html.
      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.
      Cheers.
      • Python?
        2007-03-08 06:15:20 Brian Macauley Business Card [Reply]

        I might be interested in testing a Python implementation in a Django, TurboGears or Pylons set up.


        • Python?
          2007-03-08 06:51:00 Piers Harding Business Card [Reply]

          OK. If you send me an email with your contact details, I'll let you know when the Python implementation is done.
          Cheers.
  • NW RFC libraries for testers
    2007-03-01 07:46:04 Ulrich Schmidt SAP Employee Business Card [Reply]

    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


    ______________________________________________


    nwrfcsdk_win_x86_32.zip 6188986 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=TI7VTUFNCADPPHVYFW0CBQH6DNRHEJW7UBSAZLM0B0YGQO6HWI


    nwrfcsdk_win_x86_64.zip 6605960 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=ZG4NY7NFDMY1PH53BQOQASSFCZ60ZQMX1DUFQUC34ZG4JEXZ4O


    nwrfcsdk_win_itanium_64.zip 7926295 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=6QUX96UFYLMP9YSCTIR0XN8MK2I93PRKWDK3QM11KJ7Z89HDSF


    nwrfcsdk_sun_sparc64.zip 9550190 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=GRXV7IUJT87E4VODPKUCA7YGUSF065LU6C39K5E90Q14XWV4T6


    nwrfcsdk_hp_parisc64.zip 12450563 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=G45LDHIRKZ7CKYP2T3LSR4F9NGW2ZMDSYFMWNGDZJOG2EO1ZRQ


    nwrfcsdk_linux_x86_64.zip 12884211 byte
    https://sapmats-de.sap-ag.de/download/download.cgi?id=JE0XUKENDS1YCAOOFFLOMEZ3BJLQIHJM33DCN1G2JWJ11N9REK


    (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...)

  • Testing
    2007-02-28 09:54:58 Stefan Huettenrauch SAP Employee Business Card [Reply]

    Hi Piers,


    awesome!!
    I am looking forward to dive into it.


    I am working with an IDESPortalNWDH (EP 6.0 NW04) and have a windows machine.
    (stefan.huettenrauch@sap.com)


    Thanks for everything
    Stefan

  • Piers - this is REAL technology!
    2007-02-28 09:47:25 David Halitsky Business Card [Reply]

    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.


    Regards
    djh



  • Count me in for testing
    2007-02-28 07:27:02 Ed Herrmann Business Card [Reply]

    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.


    -ewH

  • Awesome!
    2007-02-28 06:40:53 Alvaro Tejada Galindo SAP Employee Business Card [Reply]

    Thanks for this great new Piers!!! I already answer your mail, so I hope I can be a tester -;) That would be great!


    Greetings,


    Blag.

Showing messages 1 through 29 of 29.