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 service.sap.com. 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:
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
-> <platform>
-> NWRFC_2-20004xxx.SAR

After downloading the NW RFC SDK for your platform, simply unpack it somewhere convenient for you. On my system, it is in /usr/sap/nwrfcsdk. If you're on Linux or Unix, you'll need your LD_LIBRARY_PATH variable to be set to the lib directory of the SDK both to build the perl module, as well as to execute the scripts.

dhull@localhost ~]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/sap/nwrfcsdk/lib

Next, download the SAPNW::Rfc module with the perl CPAN module, or directly from CPAN's website at cpan.org. 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 next blog, part two of this series, I'll cover the of writing a simple script.