Skip to Content

For system and application administrators, identifying issues in the
system as soon as they occur can be key to keeping these issues from
ballooning into outages.  There are many tools on the market to alert you to these kinds of
issues, but those tools often are expensive, unwieldy, inflexible, or
simply unreliable.

In the 1999/2000 timeframe, I was using a major commercial software package for monitoring SAP systems.  It seemed, however, that often times when we had a crisis in our monitored systems, the monitoring software also had an issue that prevented it from alerting us.

For those of us that have been administering systems for many years, the natural inclination when necessary functionality is unavailable or unacceptable is to be proactive by writing your own programs to get the information you need, often with some form of scripting. Scripting is available in many flavors nowadays – shell, perl, python, php, ruby, java, etc. Although I’m not a developer by trade, I have been writing scripts for many years to accomplish these tasks with great success.

As a result, I decided to script a backup to our ineffective commercial software package, and
I chose perl as the language to use, primarily due to its ability to
effectively parse text files.

I scheduled regular background jobs in the R/3 systems to print standard transaction codes such as SM21, ST22, ST03, ST04, SM66, and more.  I sent these spool outputs to a Unix print queue, and my script took them from there, parsed the output looking for key text, and deleted them when finished.

This method proved effective and reliable for years.  However, thanks to Piers Harding coding the perl interface to SAP’s RFC SDK in 2003, it became possible to connect directly to an SAP system from a perl script.  This allowed me to cut out the reliable though kludgy print spool middleman.

I’ve been using perl scripts to interface with SAP systems in production ever since. This has allowed me to alert relevant parties when background jobs fail; when the systems gets an excessive number of short dumps, or short dumps with specific errors; when certain errors pop up in the system log; or even to alert on application or database performance issues, among other things. What I will attempt to do in this series of blogs is to relate my experiences, along with a bit of instruction, for those that may be interested in doing the same.

I’ll start with the initial configuration of the scripting environment. I’ve always executed my scripts on either Unix or Linux, and my development environment today is Linux, so that’s where I’ll focus. The configuration on Linux takes only a few minutes, as most of the tools come standard. If you’re going to use Windows, I would say good luck, and you’ll need to download a good perl distribution, as well as a C compiler (make/nmake) to compile the necessary perl modules, since these do not come standard with the operating system.

Step 1, assuming your perl and C compiler are in place, would be to download the SAP Netweaver RFC SDK. To do this, you must have a valid S-user account at Here are the instructions to obtain this, per note 1025361 :
The installation files for the SAP NW RFC SDK are available on the SAP Service Marketplace: Next, download the SAPNW::Rfc module with the perl CPAN module, or directly from CPAN’s website at . Currently, the latest version would be sapnwrfc-0.24.tar.gz, but this may change at any time, so please ensure yours is up to date.

After unpacking this file somewhere on your system, you’ll need to compile and install it as follows.  First, cd to the directory you unpacked it to.  Then:

dhull@localhost ~]$ perl Makefile.PL --source /usr/sap/nwrfcsdk
dhull@localhost ~]$ make

At this point, you’ll want to find the file ‘sap.yml’ in the same directory and correct the parameters in it to connect to your test system. You’ll need to change the application server name, system number, client, username and password. Then, continue:

dhull@localhost ~]$ make test

This step will test the module build and its ability to access the system you provided connectivity information for. At the end, you should see something like:

All tests successful, 1 test skipped.
Files=12, Tests=6689, 56 wallclock secs ( 7.92 cusr +  0.77 csys =  8.69 CPU)

Provided this is the case, continue the install with:

dhull@localhost ~]$ sudo make install

(sudo used here for root access necessary for installing the module)

Next, you may want some non-standard modules for the scripts you’ll be writing. They’re not required of course, but they can be helpful. Some of the ones I typically use are Date::Calc for calculating the difference between two date/time values (eg: to calculate the duration of a background job), DBI and DBD::Oracle to connect to an Oracle database and insert the data I’m retrieving from my monitored system (there are other modules for every database on the market), and Mail::Sender for sending email alerts. All of these modules can be installed manually, or with perl’s CPAN module (included with virtually every perl distribution) as follows:

dhull@localhost ~]$ perl -MCPAN -e shell
cpan> install Date::Calc

Now, if you’ve followed these steps successfully, you’ve got a working scripting environment from which to interface with your SAP systems!

In my Perl and SAP Adventures, Part 2, part two of this series, I’ll cover the of writing a simple script.


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Piers Harding
    Hi David – thanks for blogging about this.  Can I add a couple of things.  It’s probably better to point people to on CPAN, as this is the official repository.
    Also, I’m fortunate to have a client at the moment, who can fund me to improve the code base, and documentation for sapnwrfc (for Perl).
    Piers Harding.
    1. Community User Post author
      Certainly, Piers… I have updated the link to point to CPAN’s website instead of yours for the module download.

      That’s great news about future improvements to the perl module!  Though I must admit, I haven’t had any issues with it thus far, other than my own poor coding skills.  🙂


  2. Mingzuo Shen
    had to install a bunch of modules on FC10
    before being able to compile sapnwrfc-0.24.

    would be great to learn more about the printing
    method. How to schedule and redirect the
    output to a printer.
    I use Perl a lot, but recently started to
    work (and learn) in basis.

    1. Community User Post author
      I am writing this as a multi-part blog series in which I will detail my own learning process as pertains to perl/SAP, as well as to go through the process of writing a fully functional script to read an application server’s system log, so stay tuned!


    1. Community User Post author
      Yes, it seems that Piers Harding has updated the SAPNW::Rfc module, and the new version requires perl 5.10.  This was not a requirement with the module I used, as I’m still on 5.8.  If upgrading to 5.10 is an issue, you can use the version of SAPNW::Rfc that I used (0.24).


  3. Uwe Gehring

    can anyone update this nice blog with info how to succeed on Win32 platform? I can install all pieces, but they won’t work together. When I do a

    perl -Msapnwrfc

    I’ll get this:

    Can’t load ‘C:/Perl/site/lib/auto/SAPNW/Connection/Connection.dll’ for module SA
    PNW::Connection: load_file:Diese Anwendung konnte nicht gestartet werden, weil d
    ie Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die
    Anwendung neu installieren at C:/Perl/lib/ line 202.
    at C:/Perl/site/lib/ line 11
    Compilation failed in require at C:/Perl/site/lib/ line 11.
    BEGIN failed–compilation aborted at C:/Perl/site/lib/ line 11.
    Compilation failed in require.
    BEGIN failed–compilation aborted.

    I put everything I found in the lib subdirectory of the Res. Kit into WINDOWS\system32 but this didn’t help.



Leave a Reply