An SAP R/3 system writes its performance data into a file called a statistic file or stat file. CCMS (Computing Center Management System) gets its data out of this file, presummarizing it as it does so. IT Service Vision reads the statistic file directly to get more detailed data than CCMS.
Up until release 3.1h of SAP R/3 it was possible to read the stat file directly, but since release 4.0 the stat file is compressed and can only be read via SAP R/3 RFCs (Remote Function Calls) that decompress it while being read. These function calls also allow the data to be read directly from within the R/3 system without having to depend on an external copy of the stat file.
The IT Service Vision solution for reading SAP R/3 performance data consists of an ABAP program on each R/3 application server and a C program on the IT Service Vision server. The ABAP program wakes up every hour, reads the data and sends it to a port or socket to which the C program is attached. It also records the timestamp in a control dataset and uses that timestamp as the start time for subsequent extractions. The C program receives the data and stores it in an appropriate location on the IT Service Vision server ready to be processed overnight. The combination of the ABAP and C programs acts like a daemon process. It registers itself in the R/3 system on the application server by using a rfc-destination and a unique id.
The original support for reading the stat file is still available, but you will need to consider transitioning to the new RFC method, especially if Version 4 of R/3 is to be installed. Because the format of the extracted data files is different, you need to select different parameter values on the %CPPROCES macro to differentiate. To process the external copy of the stat file, continue to use TOOLNM=STATBIN. To process the newly extracted format, code TOOLNM=STATRFC. The two file formats are incompatible and cannot be mixed. That is, you cannot process RFC-generated data with TOOLNM=STATBIN and you cannot process a stat file with TOOLNM=STATRFC. But you can continue to use any or all SAP R/3 IT Service Vision tables using either method.
This is the information which was originally included in the Online Help which details the naming convention necessary for processing stat files. It has been copied here for your convenience.
When processing SAP R/3 stat files, there are some macro variables that are required and some that are optional. The one that is always required is SAPVER. This is used to specify the version of SAP R/3 that produced the stat file (it is not detectable from within the stat file). Different versions of R/3 have different formatted stat files, so this variable must be specified. For example, for version 3.1h you would code:
One of the optional macro variables is SAPPLAT. It must be used if you are processing data that has been generated (or your SAP R/3 system runs) on a Windows platform. If this is not the case, do not specify it. Code it as follows:
If you want to process multiple stat files (or a directory of raw data files) then your file names must conform to the naming conventions specified below. You also do not need to specify the other optional macro variables. In fact, if you do specify them, you will receive an error message and processing will stop.
- store all of the files in one directory or folder. This folder must not contain other non-SAP related data files.
- specify the RAWDATA= parameter with a value that includes the complete directory path to the folder where the files are located. For example, you might specify RAWDATA= /dept/cpd/ (on UNIX) or RAWDATA= c:\dept\cpd\ (on a PC).
- use the following naming convention for all of the raw data files in the directory that is specified by the RAWDATA= parameter:
In this example:
- system1 is the name of the SAP System to which the Application Server (identified by host) is connected
- host represents the host name of the SAP Application Server from which the file was generated
- sysnr represents the R/3 system number
- sap represents the extension to the filename. This could be .txt, .data, or any other file extension.
- The folder name and its preceding, high-level qualifiers can be named as you wish. For example, some customers choose to timestamp their directory names.
- the value of the RAWDATA= parameter must identify a PDS containing STAT files related to only one SAP system, such as payroll.sapdata,
- the PDS should contain a separate member for each SAP Application Server and the member names must represent the application server host name,
- specify the SAP System Name by using the SAPSYSNM macro variable,
- also specify the SAP System Number by using the SAPSYSNR macro variable,
- execute the %CPPROCES macro once for each SAP System, such that the RAWDATA= parameter identifies a different PDS. Re-specify the macro variable assignments for each execution as appropriate.
- SAP STAT files must be uploaded in binary form, to MVS data sets of fixed format (i.e., no blocking).
%let SAPHOST=sapsrv01; %let SAPSYSNM=sapsys99; %let SAPSYSNR=01;
If, within one SAS session, you call the %CPPROCES macro to process one raw data file and then call the %CPPROCES macro again to process multiple raw data files:
%let SAPHOST=; %let SAPSYSNM=; %let SAPSYSNR=;
This is because the SAPHOST, SAPSYSNM, and SAPSYSNR macro variables are global macro variables, and thus remain set until changed, so your values from the first execution might inadvertently be set for the second.
To process a single stat file, use the %CPPROCES as follows:
%let SAPVER=3.0c; %let SAPSYSNM=FINANCE; %let SAPSYSNR=01; %let SAPHOST=sapsrv01; %CPPROCES( sapr3s, collectr=sapr3, toolnm=statbin, rawdata=/usr/tmp/statfile.sap );
To process multiple stat files, use the %CPPROCES as follows:
%let SAPVER=3.0c; %CPPROCES( sapr3s, collectr=sapr3, toolnm=statbin, rawdata=/usr/tmp/statfiles/ );
The three main components of the interface are:
Installation and registration of these features requires SAP R/3 administrator privileges.
This is required. It should be the name of the RFC Destination (not the program associated with the destination) created in the previous step. The destination is case sensitive - the destination name may have been upper-cased by the SAP R/3 system.
- G_SDAT, G_STIM, G_EDAT, G_ETIM
These are optional, since the last hours data will be extracted by default. If you create an online variant (for testing purposes) they are required.
This is required. It points to the output directory on the IT Service Vision server where the RFC daemon will be running. Because the performance data contains no information about the SAP R/3 server name, sub-system number (gateway service) or system name, the directory name for the data from each application server must be uniquely named following this convention:
For example:/sapdata/c11_wktest01_20/ on a unix systemc:\sapdata\c11_wktest01_20\ on a PC system
where "c11" is the SAP R/3 system name, "wktest01" is the SAP server name and "20" is the SAP system number (also known as the gateway service number). The files within these directories will be dynamically named dependent on the data file being fetched and the timestamp of the fetch, as follows:pfnorm_20001027_190000_20001027_200000.dat
NOTE: The value for G_PATH must end in a slash (\ or /) because the generated file name is appended to its value. If a slash is not entered the program will look for a directory that doesn't exist.
This is required. It is used to point to the location of a control dataset that stores the timestamp of the last data extraction. The file is created (if it doesn't exist) and is written to by the SAP R/3 system (not the IT Service Vision server). The file should be called sapsave.dat and the path should again conform to follow the file-naming convention above. For example:
c:\temp\system-name_server-name_system-number\sapsave.dat if SAP R/3 is running on a PC
Do not schedule this batch variant yet. Once everything has been set up and tested, you will then want to schedule it to run every hour.
- the -a parameter should be set to the name of the program associated with the RFC Destination created above,
- the -g parameter should be set to the name of the SAP Gateway and
- the -x parameter should be set to the name of the Gateway service.
Note that the -a parameter refers to the Program associated with the RFC Destination, not the destination's name itself.
The SAP Gateway is normally the same as the name of the SAP R/3 Application Server and must appear in the local etc/hosts file. Its name and definition can be checked by scanning for its entry in the TCP services file on the R/3 Server.
The Gateway service should already be defined in the SAP R/3 Application Server's TCP services file - it must also be defined in the IT Service Vision server's TCP services file.
For testing, there is another parameter, -t, that produces a trace of the RFC program's activity in the directory where the shell script resides. Simply adding the -t parameter creates a file called dev_rfc (on UNIX) or dev_rfc.trc (on PC) in the directory in which the script was started. This trace file is appended to if it already exists. Be sure to clear or delete it before rerunning the script.
Example for the rfcstrt.sh script on Unix
sasrfcex -a wktest01.sasrexec -g wktest01 -x sapgw20
Example for the rfcex.bat batchfile on Windows NT
sasrfcex.exe -a wktest01.sasrexec -g 126.96.36.199 -x sapgw20
Then, on the SAP R/3 system, execute the batch variant of the ZSASITSV program. Data should be sent to the RFC and stored in the appropriately-named directories on the IT Service Vision server. You should see messages in the log window indicating success or failure.
If it succeeded, you should see files prefixed pfnorm in the location specified in the G_PATH parameter. You may also see files prefixed pfbtc - these can be safely ignored and should not take up much disk space, if any.
If it failed, a return code should appear in the SAP log. The most common failures are codes of:
- system failure - this could be where the name of the destination was not found or the program/script file was not running.
- communications failure - this could be an incorrect gateway or gateway service specification or that the SAP R/3 server was not found on the network.
To correct a failure, stop the script execution, change any parameters necessary and restart the script. Then, on the SAP R/3 server, re-execute the batch variant and re-check the log. More information can be found by browsing the dev_rfc file on the IT Service Vision server, even if the script is still executing.
To re-iterate, the data must be stored in directories according to the following naming convention:
The process macro will then parse the location for these values and store them in the data. For example:
/sapdata/c11_wktest01_20/ on a unix systemc:\sapdata\c11_wktest01_20\ on a PC system
where "c11" is the R/3 system name, "wktest01" is the SAP server name and "20" is the SAP system number (also known as the gateway service number). The files within these directories will be named automatically dependent on the data file being fetched and the timestamp of the fetch.
If the data is to be processed on an OS/390 or MVS system, the data should be uploaded there in binary form and stored in either a sequential file or a PDS. If a sequential file is chosen then the following naming convention must be used:
If a PDS is chosen, then the following naming convention must be used: If a PDS is chosen, then the following naming convention must be used:
In both cases, "c11" is the R/3 system name, "wktest01" is the SAP server name and "20" is the SAP system number (also known as the gateway service number). Notice that the system number must be prefixed with an N since MVS dataset qualifiers cannot start with a number. Also notice that the last qualifier or PDS member name can be suffixed with any number to distinguish it from other similar files or members.
The SAP R/3 data must be stored in a location whose name follows the naming conventions listed above. Failure to do so will cause the process macro to not find your data.
If you are currently processing stat file data and are implementing this new RFC support, you must change the external name of your SAPR3S table in your IT Service Vision data dictionary. The external name is used to match the R/3 table names with those of IT Service Vision's. Failure to do so will result in a failure of %CPPROCES. Use the following code to achieve the change:
%cpcat; cards4; update table name=sapr3s extname=PFNORM; stop; ;;;; %cpcat(cat=work.ddutl.sapr3.source); %cpddutl(entrynam=work.ddutl.sapr3.source);
In IT Service Vision 2.3, there is a new QuickStart Wizard for SAP R/3 data which can be used to easily load data and produce web galleries. This support also includes five new pre-summarized interval tables which provide better support for handling large data volumes. They are SAPHST, SAPSMT, SAPTSK, SAPSYS anbd SAPTRN. For more details, use the online GUI to explore the supplied data dictionary or just run the QuickStart Wizard.
There are three possibilities when processing data from SAP R/3 using the new RFC method:.
To specify any of these data locations, either:
For PC and UNIX, RAWDATA should refer to either the single file; single directory or parent directory. For MVS, RAWDATA should refer to either the single file or PDS name.
Use the %CPPROCES macro to process the data into the IT Service Vision PDB. Preceed the macro with a macro variable setting that specifies the version of SAP R/3 that is installed on the systems from where the data was extracted. Optionally, add another macro variable setting if (and only if) the data was generated on a Windows platform:
%let sapver = 4.0a; /* Version of SAP R/3 */ %let sapplat = WIN; /* Specify only if data was indeed */ /* generated on a Windows platform */ %cpproces(rawdata="sapdata/", collector=SAPR3, toolnm=STATRFC, dupmode=DISCARD);
For optimum performance, remember to clean out these files and/or directories for subsequent process executions.