Pi Erpperf[1]

ERP PerformanceInterface to the PI System

Version 1.0.0.1Rev B

How to Contact Us

Phone (510) 297-5800 (main number)(510) 297-5828 (technical support)

Fax (510) 357-8136

E-mail [email protected]

World Wide Web http://www.osisoft.com

Mail OSIsoftP.O. Box 727San Leandro, CA 94577-0427USA

OSI Software GmbH Hauptstrae 30 D-63674 Altenstadt 1Deutschland

OSI Software, LtdP O Box 8256Symonds StreetAuckland 1035 New Zealand

OSI Software, Asia Pte Ltd152 Beach Road#09-06 Gateway EastSingapore, 189721

Unpublished – rights reserved under the copyright laws of the United States.RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph I(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013

Trademark statement—PI is a registered trademark of OSIsoft, Inc. Microsoft Windows, Microsoft Windows for Workgroups, and Microsoft NT are registered trademarks of Microsoft Corporation. Solaris is a registered trademark of Sun Microsystems. HP-UX is a registered trademark of Hewlett Packard Corp.. IBM AIX RS/6000 is a registered trademark of the IBM Corporation. DUX, DEC VAX

and DEC Alpha are registered trademarks of the Digital Equipment Corporation.PI_ERPperf.doc

2004-2005 OSIsoft, Inc. All rights reserved777 Davis Street, Suite 250, San Leandro, CA 94577

http://www.osisoft.com/

mailto:[email protected]

Table of Contents

Introduction....................................................................................................................1Reference Manuals......................................................................................................2

Supported Features......................................................................................................2

Diagram of Hardware Connection................................................................................4

Principles of Operation.................................................................................................5Function Module “/OSI/MON_SERVER_INFO”............................................................6

Function Module “/OSI/MON_SYSTOPER_INFO”.....................................................12

Function Module “/OSI/MON_RESPONSE_TIME”.....................................................13

Installation Checklist...................................................................................................23

SAP Add-on and Support Package Installation.........................................................25SAP Add-on................................................................................................................25

Prerequisites...........................................................................................................25

Preparation.............................................................................................................26

Installation..............................................................................................................26

Password................................................................................................................26

Language Support..................................................................................................26

Support Packages for the SAP Add-on......................................................................27

SAP User Account Creation and Configuration........................................................29

Test Function Modules via SAP Front End................................................................31

Interface Installation....................................................................................................37Naming Conventions and Requirements....................................................................37

Interface Directories...................................................................................................37

The PIHOME Directory Tree...................................................................................37

Interface Installation Directory................................................................................38

Interface Installation Procedure..................................................................................38

Installing the Interface as an Windows Service..........................................................38

Installing the Interface Service with PI-Interface Configuration Utility....................38

Installing the Interface Service Manually................................................................40

ERP Performance Interface to the PI System iii

Digital States................................................................................................................43

PointSource..................................................................................................................45

PI Point Configuration.................................................................................................47Point Attributes...........................................................................................................47

Tag.........................................................................................................................47

PointSource............................................................................................................47

PointType...............................................................................................................47

Location1................................................................................................................47

Location2................................................................................................................47

Location3................................................................................................................47

Location4................................................................................................................47

Location5................................................................................................................48

InstrumentTag........................................................................................................48

ExDesc...................................................................................................................49

Scan.......................................................................................................................49

Shutdown................................................................................................................49

Step........................................................................................................................50

Descriptor...............................................................................................................51

EngUnits.................................................................................................................51

Windows Performance Counter Configuration.........................................................53

I/O Rate Tag Configuration..........................................................................................55Monitoring I/O Rates on the Interface Node...............................................................55

Configuring I/O Rate Tags with PI-ICU (Windows).....................................................55

Configuring I/O Rate Tags Manually..........................................................................56

Configuring the PI Point on the PI Server...............................................................56

Configuration on the Interface Node.......................................................................57

Startup Command File.................................................................................................59Configuring the Interface with PI-ICU.........................................................................59

ERPperf Interface Tab................................................................................................61

General Parameters...................................................................................................67

Other UniInt Parameters.........................................................................................68

Command-line Parameters.........................................................................................69

Sample PIERPperf.bat File........................................................................................77

Interface Node Clock...................................................................................................81

ERP Performance Interface to the PI System iv

Security.........................................................................................................................83

Starting / Stopping the Interface.................................................................................85Starting Interface as a Service...................................................................................85

Stopping Interface Running as a Service...................................................................85

Buffering.......................................................................................................................87Configuring Buffering with PI-ICU (NT-Intel)...............................................................87

Configuring Buffering Manually..................................................................................90

Example piclient.ini File..............................................................................................91

Appendix A: Error and Informational Messages.......................................................93Message Logs............................................................................................................93

Messages...................................................................................................................93

Interface Startup Error............................................................................................93

Point Loading Errors...............................................................................................94

RFC Error Message................................................................................................95

System Errors and PI Errors.......................................................................................96

Appendix B: RFC and BAPI Descriptions..................................................................97Introduction.................................................................................................................97

External Function Modules.........................................................................................98

Function Module ‘/OSI/MON_SERVER_INFO’.......................................................98

Function Module ‘/OSI/MON_SYSTOPER_INFO’................................................104

Function Module ‘/OSI/MON_RESPONSE_TIME’................................................108

Internal Function Modules........................................................................................116

Function Module ‘/OSI/MON_ GET_APPLINFO’..................................................116

Function Module ‘/OSI/MON_ GET_ SYSTLOG’..................................................118

Appendix C: Specific Point Configuration...............................................................121

Appendix D: Hierarchy Builder Program.................................................................127Introduction...............................................................................................................127

Theory of Operation.................................................................................................128

InstrumentTag Attribute........................................................................................128

UniInt-based.........................................................................................................128

SAP Performance Hierarchy.................................................................................129

Hierarchy Example...............................................................................................133

PI Module Database Entries.................................................................................139

Module and Alias Deletions..................................................................................139

ERP Performance Interface to the PI System v

Table of Contents

Effective Dates for Modules..................................................................................139

Point Processing Delay.........................................................................................140

Installation Checklist for Hierarchy Builder...............................................................140

Program Installation.................................................................................................141

Program Parameters................................................................................................141

Startup Parametrs.................................................................................................141

Command-line Parameters...................................................................................142

Starting / Stopping the Program...............................................................................143

Multiple Copies of the Program............................................................................145

Appendix E: Sample PI-ProcessBook Displays......................................................147Introduction...............................................................................................................147

Viewing Data from /OSI/MON_SERVER_INFO.......................................................148

Viewing Data from /OSI/MON_SYSTOPER_INFO...................................................149

Viewing Data from /OSI/MON_RESPONSE_TIME..................................................149

Changing the Displayed SAP Instance....................................................................153

Revision History...........................................................................................................155

vi

IntroductionThe OSIsoft ERP Performance Interface (PI-ERP Performance) connects to an SAP R/3 system, extracts the system performance information out of the SAP R/3 system via remote-enabled function modules, and stores such information to the PI Server. The PI-ERP Performance Interface should run on a different node than the SAP R/3 system. It gathers the performance data regardless of the underlying database system or operating system environment. This interface connects to a central instance of an SAP system and communicates to all other instances (dialog, spool, etc.) within the R/3 system communications. The interface does not need to connect to each instance independently.

PI-ERP Performance uses Remote Function Calls (RFC) to remotely invoke the customized BAPI or RFC-enabled function modules on the SAP R/3 server that provide the performance data. Upon receiving the data, the Interface reads each performance record, and based on the obtained data, it can automatically create PI points if they do not already exist on the PI Server. PI-ERP Performance then writes values to these points.

PI-ERP Performance runs on Windows NT 4.0, Windows 2000, or Windows XP operating systems. Unless otherwise noted, the remainder of this document uses the term "Windows" to refer to all three.

PI-ERP Performance requires:

PI Server

PI-SDK/PI-API

RFC-enabled Function Modules developed by OSIsoft for extracting performance information out of the SAP R/3 system. SAP Add-on packages that contain these Function Modules are part of this interface, but are delivered on their own CD to be installed on the monitored SAP R/3 system. The guideline for installing the SAP Add-on packages is discussed in Appendix C. Any enhancement and/or bug fixes for the RFC function modules will be delivered as support packages.

Librfc32.dll. This DLL is included in the SAP Remote Function Call Software Development Kit (RFC SDK). Thus, the RFC SDK must be installed on the interface node. The SAP GUI or Front End contains the RFC SDK, thus can be installed on the interface node to satisfy this requirement.

There is no special hardware required by this interface.

The direction of data flow is uni-directional; that is, from the SAP R/3 system to the PI Server. The RFCs are only read and at no time write to any R/3 tables.

The function modules provided by OSIsoft are certified by SAP for the SAP Enterprise System (4.7). The function modules are also compliant with SAP systems with earlier versions 3.1G, 3.1H, 3.1I, 4.0A, 4.0B, 4.5A, 4.5B, 4.6A, 4.6B, 4.6C. Therefore, the PI-ERP Performance interface supports all the aforementioned versions of the SAP system.

ERP Performance Interface to the PI System 1

Reference Manuals

OSIsoft PI Server manuals

PI-API manual

PI-SDK manual

UniInt3.x End User Document

Vendor Standard R/3 Basic technical guides

Supported FeaturesFeature Support

Part Number PI-IN-ERP-PM-NT

Platforms Windows NT 4.0 / 2000 / XP

APS Connector Currently Available No

PI Point Types String / digital /float64 / float32 / float16 / int32 / int16

Sub-second Timestamps No

Sub-second Scan Classes No

Automatically Incorporates PI Point Attribute Changes

Yes

Exception Reporting Yes

Outputs from PI No

Inputs to PI: Scan-based / Unsolicited / Event Tags

Scan-based

Maximum Point Count Maximum point count of PI server

Uses PI-SDK Yes

PINet to PI 3 String Support N/A

* Source of Timestamps From PI Server machine or from the time information contained in the returned tables

History Recovery No

Failover No

* UniInt-based Yes

* Vendor Software Required on PI Interface Node

Yes

Vendor Software Required on the SAP R/3 No


Feature Support

system

Vendor Hardware Required No

* Additional PI Software Included with Interface

Yes

Device Point Types Not Applicable

*See paragraphs below for further explanation

Source of TimestampsThe clock on the computer running the PI Server provides the source of the timestamps for the data sent by PI-ERP Performance. The Interface writes a timestamp that reflects the time at which it calls the function module to retrieve the table. The only exceptional cases are for the data returned in the table “BUFFER_STAT” by function module “/OSI/MON_SERVER_INFO”, table “ADUMPINFO” by function module “/OSI/MON_SYSTOPER_INFO”, and the data returned in table “STATINFO” and table “TIMEINFO” from function module “/OSI/MON_RESPONSE_TIME”. These three tables include fields containing time information that is used as the timestamp. See “Principles of Operation” section for details.

UniInt-basedUniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by our developers, and is integrated into many interfaces, such as PI-ERP Performance Interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.

The UniInt3.x End User Document is a supplement to this manual.

Vendor Software Required on PI Interface NodeLibrfc32.dll is required on the PI Interface Node. This DLL is contained in the SAP RFC SDK and thus can be installed via the installation of the SAP RFC SDK on the PI Interface Node.

Additional PI SoftwareRFC-enabled Function Modules developed by OSIsoft must be installed on the central instance of the monitored SAP R/3 system. These function modules are used to extract performance information out of the SAP R/3 system and are provided via SAP Add-on packages.

In addition, the Interface package includes a hierarchy builder program, hierarchbuild.exe. This program uses the PI Module Database to generate a hierarchical relationship among the PI points serviced by the Interface.


Introduction

Furthermore, a standalone utility, PISAPLogon.exe, is provided to create an encrypted SAP Logon File, which consists of the client number, username and password needed for opening an RFC connection from the interface to the SAP R/3 system.

Diagram of Hardware Connection

4

SAP R/3 Central Instance

BOR

Customized Performance

BAPI’s

SAP R/3 Server

PI-ERP Performance Interface

(PI API, PI SDK and librfc32.dll)

Interface Node

(Windows)

PI ServerPI Server Node

(Windows or Unix)

SAP R/3 Dialog Instance

SAP R/3 Application Server

SAP R/3 Database Instance


SAP R/3 Spool Instance

SAP R/3 Batch Instance



RFCCall

RFCCall RFC

CallRFCCall

Principles of OperationThe PI-ERP Performance Interface connects to an SAP R/3 system, retrieves the performance information from the SAP R/3 system by RFC/BAPI functions, creates necessary PI points based on the obtained SAP performance data and stores the data into a PI server.

PI-ERP Performance uses remotely-enabled function modules to extract the performance information. Three function modules have been developed by OSIsoft for this purpose: /OSI/MON_SERVER_INFO, /OSI/MON_SYSTOPER_INFO, /OSI/MON_RESPONSE_TIME. The details of the function modules are described in “Appendix B: RFC and BAPI Descriptions.” These function modules are provided as SAP Add-on packages together with the Interface, but delivered on a separate CD so that they can be installed on the central instance of the monitored SAP R/3 system.

At start up, the Interface connects to the SAP R/3 server and extracts the performance information using the RFC mechanism then closes the RFC connection once the information is retrieved. The Interface can automatically create necessary PI points according to the obtained data if they do not already exist. The performance data are then parsed and stored to corresponding PI points. If a point already exists for a particular record of the returned table, the Interface will not add a new point or edit the point attributes of the existing point.

This Interface supports scan-based data collection. All the points in this Interface are scan-based points, i.e. at a specified scan frequency the Interface opens an RFC connection to the SAP system and calls the function module(s) to retrieve the necessary table(s) then closes the RFC connection after the data are obtained.

The performance data returned by RFC and BAPI functions are in the format of an SAP table. A total of 16 tables can be obtained using three function modules. In order to record the SAP performance information to the PI server, each data entry in the returned tables is parsed. See the “PI Point Configuration” section for detailed descriptions about point configuration for each table returned by the three function modules.

Function modules “/OSI/MON_SYSTOPER_INFO” and “/OSI/MON_RESPONSE_TIME” need to specify a time range, starting time and ending time, for extracting the data out of SAP. When the Interface calls these two function modules to extract data tables, it uses the current time on the local system as the ending time and the current time minus the scan interval as the starting time. The scan interval for each scan class is configured via command-line parameters.

Command-line parameters, in the format of /<table name>=1 are used to specify for which tables the Interface should automatically create PI points. Each table corresponds to one scan class. This interface requires that 16 scan classes be defined regardless of how many tables are to be obtained. See the “Command-line Parameters” section for a more detailed discussion.

This interface automatically creates PI points according to the command-line parameter settings. However, if a point is manually deleted from the PI Server by the user, the Interface will not automatically create it again unless the Interface is stopped and restarted or the user recreates the point manually. Therefore, if the user does not want to collect data for some points, OSIsoft does not recommend deleting the points from PI Server. Instead, the user can set the “Scan” attribute of these points to off. See the “Point Attributes” section for the detailed descriptions about “Scan” attribute.


The Interface will never edit the point attributes. So if any of the point attributes of a point is modified by the user, the Interface will not change it back to its original settings automatically.

A tagname prefix can be specified by the user via the command-line parameter /tag_prefix=prefix, which will be used for all the points created by this interface. For example, if the prefix is specified as PRD_, then all points created by the Interface will have tagnames starting with PRD_. It is strongly recommended that a prefix be specified for each instance of the Interface. See the “Command-line Parameters” section for more detail.

Below are the details of each function module and their returned tables. Included is a discussion about what information should be obtained from each table and how the PI points are specified based on the returned data.

Function Module “/OSI/MON_SERVER_INFO”The purpose of this function module is to allow users to extract all the important server information such as Buffer statistics, Kernel information, Version data, Operating System data, etc. from the SAP R/3 system. This function module can return six data tables: SYSTEM_LIST, KERNEL_INFO, VERSION_INFO, OS_MONITOR, VERSION_COMP, and BUFFER_STAT. The PI server time at the time that this function module is called is used to timestamp all data coming from the returned tables except for table BUFFER_STAT. BUFFER_STAT table includes fields containing time information that is used as the timestamp.

Table SYSTEM_LISTThis table returns information about all the SAP application servers/instances that are available in a particular SAP system. The name list of the available application servers/instances can be obtained in the NAME field of the table. This is the only field of interest to this interface and its structure is shown below. See Appendix B: RFC and BAPI Descriptions for the details about all the returned fields and table structure of SYSTEM_LIST.

Field Type Length Description

NAME CHAR 20 Server name. This name is usually made up of the computer name, System ID (SID) and system number. It usually corresponds to the internal RFC destination of the application server.

Upon receiving this table, the Interface automatically creates a digital PI point for each server found in the list, if they do not yet exist, and a value indicating the availability of the servers is sent to the PI server. The digital PI points are associated with the Digital State Set SAPInstanceStatus, which is created by the Interface and is defined as:

Digital Set: SAPInstanceStatus

Value Digital State

0 Not Available

1 Available


If a server is found in the list, a value of 1, Available, is written to the PI tag. Otherwise, 0, Not Available, is sent to the PI tag. A timestamp from the PI server that reflects the time at which /OSI/MON_SERVER_INFO is called is used as the timestamp for the data.

The field “NAME” is used as a key field for defining the PI points. The tagname of a PI point consists of “_Availability” appended to the application server name obtained from field “NAME”: SERVERNAME_Availability. Furthermore, tagname prefix for all points created by this interface may be specified as a command-line parameter. For example, if the prefix is specified as PRD_, then the tag name created by the Interface for this table will be PRD_SERVERNAME_Availability. If no prefix is defined, no prefix will be added to tagnames. In the rest of this manual, for simplicity we assume that no prefix is specified for tagnames.

For example, the returned NAME field of a SYSTEM_LIST table is as follows.

NAME

sap1_DEV_00

sap2_DEV_00

Upon receiving this table, the PI-ERP Performance Interface will automatically create two PI points if the points don’t exist yet. The tagnames for these two points and their values are:

PI Tagname Value Digital State

sap1_DEV_00_Availability 1 Available


The next time when the Interface executes /OSI/MON_SERVER_INFO, the obtained SYSTEM_LIST table has SERVERNAME field as:

NAME

sap1_DEV_00

sap3_DEV_00

The interface then automatically creates one PI point for server “sap3_DEV_00.” The tagnames and values for the PI points become:

PI Tagname Value Digital State


sap2_DEV_00_Availability 0 Not Available


The suggested update frequency for table “SYSTEM_LIST” is daily, at the end of the day.

Table KERNEL_INFOThe information about the SAP Kernel is obtained from this table. The interface captures the information provided in the following three fields of KERNEL_INFO table and stores the data into the PI server:


Principles of Operations


SERVERNAME CHAR 20 Application Server name

KERN_REL CHAR 80 Kernel release

KERN_PATCHLEVEL CHAR 80 Kernel patch level

The data returned in fields “KERN_REL” and “KERN_PATCHLEVEL” are combined into one string and stored in a single PI point. The “SERVERNAME” field is used as a key field for defining the PI points. The PI tagname is created by concatenating the value of the key field “SERVERNAME” and “_Kernel_Info”: SERVERNAME_Kernel_Info.

For example, the received table has the following content:

SERVERNAME KERN_REL KERN_PATCHLEVEL

Sap1_DEV_00 46D 1575

Sap2_DEV_00 46D 1575

Two PI points are created and the corresponding values archived to are:

PI Tagname Value

Sap1_DEV_00_Kernel_Info 46D_1575

Sap2_DEV_00_Kernel_Info 46D_1575

The suggested update frequency for table “KERNEL_INFO” is daily, at the end of the day.

Table VERSION_INFOVersion information about the Operating System, SAP Application and Database are contained in this table. The fields of interest are:


SERVERNAME CHAR 20 Application server name

SAPVERSION CHAR 80 SAP version

For this table, the information returned in the field “SAPVERSION” is saved to the PI tag. The key field for defining the PI points is the field “SERVERNAME.” Therefore, the tag name consists of the value in “SERVERNAME” concatenated with “_SAPVersion”: SERVERNAME_SAPVersion. For each server found in the obtained table, one point is created to store the “SAPVERSION” data.

For example, if the returned table has the following entries:

SERVERNAME SAPVERSION

sap1_DEV_00 46C

sap2_DEV_00 46C

The points and their values are:

PI Tagname Value

8

sap1_DEV_00_SAPVersion 46C

sap2_DEV_00_SAPVersion 46C

The suggested update frequency for table “VERSION_INFO” is daily, at the end of the day.

Table OS_MONITORThis table provides information about Operating System/Hardware information such as total physical memory, used memory, etc. The fields of interest in this table are:



USR_TOTAL INT4 10 Total percentage of CPU for user processes (SAP)

IDLE_TOTAL INT4 10 Total percentage of idling CPU

FREE_MEM INT4 10 Total free memory in Kbytes.

PHYS_MEM INT4 10 Total physical memory in Kbytes.

The key field for defining PI points is the field “SERVERNAME” and the data returned in the fields “USR_TOTAL,” “IDLE_TOTAL,” “FREE_MEM,” and “PHYS_MEM” are stored in the PI server. Therefore, the following four PI points are created for each record entry in the table: SERVERNAME_Usr_Total, SERVERNAME_Idle_Total, SERVERNAME_Free_Mem, and SERVERNAME_Phys_Mem.

For example, if the extracted OS_MONITOR table contains the following data:

SERVERNAME USR_TOTAL IDLE_TOTAL FREE_MEM PHYS_MEM

sap1_DEV_00 53 47 1981224 4062760

sap2_DEV_00 64 36 2391846 5298380

Eight PI points are created. Their tagnames and values are:

PI Tagname Value

sap1_DEV_00_Usr_Total 53

sap1_DEV_00_Idle_Total 47

sap1_DEV_00_Free_Mem 1981224

sap1_DEV_00_Phys_Mem 4062760

sap2_DEV_00_Usr_Total 64

sap2_DEV_00_Idle_Total 36

sap2_DEV_00_Free_Mem 2391846

sap2_DEV_00_Phys_Mem 5298380

The suggested update frequency for table “OS_MONITOR” is every five minutes.



Table VERSION_COMPThis table contains the Release and Patches information for the Application Component in the SAP system. The fields of interest are:


COMPONENT CHAR 30 Software component

RELEASE CHAR 10 SAP R/3 Release

EXTRELEASE CHAR 10 Support Package level of a software component

The data in fields “RELEASE” and “EXTRELEASE” are combined together into a single string and are stored in the PI tag. The “COMPONENT” field is used as the key field to define the name of the PI point. The tagname of the PI point consists of the value in the “COMPONENT” field appended to “Supp_Pkg_Level_”: Supp_Pkg_Level_COMPONENT.

For example, if the following data are returned in table VERSION_COMP:

COMPONENT RELEASE EXTRELEASE

SAP_HR 46C 0006

SAP_BASIS 46C 0043

SAP_APPL 46C 0043

SAP_ABA 46C 0043

Thus, four PI points are created. The tag names and values of these points are:

PI Tagname Value

Supp_Pkg_Level_SAP_HR 46C_0006

Supp_Pkg_Level_SAP_BASIS 46C_0043

Supp_Pkg_Level_SAP_APPL 46C_0043

Supp_Pkg_Level_SAP_ABA 46C_0043

The suggested update frequency for table “VERSION_COMP” is daily, at the end of the day.

Table BUFFER_STATThis table contains the snapshot of the buffer statistic information at the time the function is executed. The table structure is:



AREA_NAME CHAR 40 Area name description

ANALYSIS_DATE DATS 8 Analysis Date (Snapshot Date)

ANALYSIS_TIME TIMS 6 Analysis Time (Snapshot Time)

HITRATIO DEC 7 Hit rate SAP buffer percentage

ALLOC_SIZE INT4 10 Allocated space in Kbytes

10

FREE_SIZE INT4 10 Available space in Kbytes

FREE_SIZE_PECT DEC 7 Free/Available space in percentage

SWAPS INT4 10 No. of objects swapped

The key fields used for defining the names of the PI points are “SERVERNAME” and “AREA_NAME.” There are five fields of interest in this table. These fields are: “HITRATIO,” “ALLOC_SIZE,” “FREE_SIZE,” “FREE_SIZE_PECT,” and “SWAPS.” Therefore five pieces of data will be sent to PI for each “SERVERNAME” and “AREA_NAME” combination. The tagnames of the five PI tags created are: SERVERNAME_AREA_NAME_Hit_Ratio, SERVERNAME_AREA_NAME_Alloc_Size, SERVERNAME_AREA_NAME_Free_Size, SERVERNAME_AREA_NAME_Free_Size_Pct, SERVERNAME_AREA_NAME_Swaps.

The date and time information returned in the fields of “ANALYSIS_DATE” and “ANALYSIS_TIME” are used as the timestamp for the obtained data.

For example, from a BUFFER_STAT table defined as follows:

SERVERNAME AREA_ NAME

ANALYSIS_DATE

ANALYSIS_TIME

HITRATIO ALLOC_SIZE

FREE_SIZE

FREE_SIZE_PECT

SWAPS

sap1_DEV_00 Program 02/06/2004 16:06:01 99.4076 256507 83517 33.41 0

sap1_DEV_00 Screen 02/06/2004 16:06:01 99.4971 8594 7504 89.76 0

Ten PI points are created with the following tagnames and values:

PI Tagname Value Timestamp

sap1_DEV_00_Program_Hit_Ratio 99.4076 Feb-06-2004 16:06:01

sap1_DEV_00_Program_Alloc_Size 256507 Feb-06-2004 16:06:01

sap1_DEV_00_Program_Free_Size 83517 Feb-06-2004 16:06:01

sap1_DEV_00_Program_Free_Size_Pct 33.41 Feb-06-2004 16:06:01

sap1_DEV_00_Program_Swaps 0 Feb-06-2004 16:06:01

sap1_DEV_00_Screen_Hit_Ratio 99.4971 Feb-06-2004 16:06:01

sap1_DEV_00_Screen_Alloc_Size 8594 Feb-06-2004 16:06:01

sap1_DEV_00_Screen_Free_Size 7504 Feb-06-2004 16:06:01

sap1_DEV_00_Screen_Free_Size_Pct 89.76 Feb-06-2004 16:06:01

sap1_DEV_00_Screen_Swaps 0 Feb-06-2004 16:06:01

The suggested update frequency for table “BUFFER_STAT” is every 5 minutes.

Function Module “/OSI/MON_SYSTOPER_INFO”The purpose of “/OSI/MON_SYSTOPER_INFO” is to extract the daily/weekly/monthly system operation information such as number of spools, ABAP dump analysis, batch input, and system log information. The data retrieved by this function module are returned in four tables: SPOOLINFO, ADUMPINFO, UPDV1INFO, and SYSLGINFO. The obtained tables contain the corresponding spool, ABAP dump, terminated update request, and system log information within the specified data and time range.



/OSI/MON_SYSTOPER_INFO has an input parameter MANDT that specifies the client number and returns only the data associated with the specified client for tables SPOOLINFO, ADUMPINFO, and UPDV1INFO. Table SYSLGINFO is client-independent, i.e., the MANDT parameter does not change the obtained data for this table. The client number can be specified via a command-line parameter /mandt=X. Usually X is set to “*”, which means all clients so this is the default setting. For more details, see the “Command-line Parameters” section.

This function module retrieves data for a specified time range. For each table, the Interface uses the current time on the local interface node when the function module is executed as the ending time of the time range and the current time minus the corresponding scan interval as the starting time for the function module to extract data. Also the ending time is used as the timestamp for the obtained data, except for the user name and the error id of table “ADUMPINFO.” For these two values, the obtained table provides a timestamp.

The suggested update frequency for all tables returned by function module “/OSI/MON_SYSTOPER_INFO” is daily, usually after midnight.

Table SPOOLINFOThis table contains the spool information for an SAP system. The information of interest is the total number of spool requests, which is the number of the entries in the table. Therefore, the Interface counts the number of record entries in the returned table and stores this number to a PI point. The tagname for the PI point is: Spool_Count. The value of the point is the number of the entries in the table.

Table ADUMPINFOThis table provides the ABAP Dump information. The information of interest is the total number of the ABAP Dump entries for each application. The table contains the field of AHOST that is the name of application server:


DATUM DATS 8 Date of the ABAP dump

UZEIT TIMS 6 Time of the ABAP dump

AHOST CHAR 32 Name of application server

UNAME CHAR 12 User name

ERRID CHAR 30 Error id of an ABAP dump

The key field for defining a PI point is “AHOST.” Three PI points are created for each application server returned in “AHOST” and the tag names are: AHOST_ABAPDump_Count, AHOST_ABAPDump_User, and AHOST_ABAPDump_ErrorID. For AHOST_ABAPDump_Count, the Interface counts the number of entries for each application server, timestamps it with the ending time that the function module call uses, then stores this value to PI. For AHOST_ABAPDump_User and AHOST_ABAPDump_ErrorID, the data in fields “UNAME” and “ERRID” are recorded respectively. The time value returned in fields “DATUM” and “UZEIT” is used as the timestamp for the values of AHOST_ABAPDump_User and AHOST_ABAPDump_ErrorID.

For example, if the returned ADUMPINFO table at 11/18/2003 17:00:00 is as follows:

12

DATUM UZEIT AHOST UNAME ERRID

11/18/2003 06:57:59 sap1 WSMITH TIME_OUT

11/18/2003 15:29:36 sap1 BADAMS TIME_OUT

Three PI points are created with the following PI tagnames. Their values and timestamps are:

PI Tagname Timestamps Values

sap1_ABAPDump_Count Nov-18-2003 17:00:00 2

sap1_ABAPDump_User Nov-18-2003 06:57:59Nov-18-2003 15:29:36

WSMITHBADAMS

sap1_ABAPDump_ErrorID Nov-18-2003 06:57:59Nov-18-2003 15:29:36

TIME_OUTTIME_OUT

Table UPDV1INFOThe terminated Update request is provided by this table. The information of interest is the number of terminated Updated requests. A PI point is created for recording this number. The tagname is: Failed_Update_Count. The interface counts the number of terminated Update requests in the returned table and sends the number to the PI tag.

Table SYSLGINFOThe system log is listed in this table. The interface counts the number of log entries in this table for each application server. The field of interest is:



The field is used as the key field for defining the PI points. Thus, the tagname is: SERVERNAME_System_Log_Count. The number of entries for each application server in the obtained table is counted and recorded in the PI tag.

Function Module “/OSI/MON_RESPONSE_TIME”The purpose of “/OSI/MON_RESPONSE_TIME” is to extract the performance response time information such as response time for various task types, application response time, and user statistical data. The data retrieved by this function module are returned in six tables: RESPINFO, USERINFO, TRANINFO, STATINFO, APPLINFO, and TIMEINFO.

Similar to the function module “/OSI/MON_SYSTOPER_INFO”, the function module “/OSI/MON_RESPONSE_TIME” also retrieves data for a specified time range. In this interface, the current time on the local interface node when the function module is called is used as the ending time of the time range and the current time minus the scan interval for each table is the starting time. The ending time is used as the timestamp for the values stored in PI, except for table “STATINFO” and table “TIMEINFO”. These two tables include fields containing time information that is used as the timestamp.



Table RESPINFOThis table provides performance response time sorted by task type. It lists the total dialog steps, the response time, the CPU time, and the wait time for a particular task type. The fields of interest are:



TASKTYPE CHAR 7 Task type or work process type. I.e. Background, Dialog, RFC, AUTO etc

COUNT DEC 15 Number of dialog steps.

MRESPTI DEC 15 Average response time per dialog step in Milliseconds

MCPUTI DEC 15 Average CPU time per dialog step in Milliseconds

MQUEUETI DEC 15 Average dispatcher wait time per dialog step in Milliseconds

MDBCALLTI DEC 15 Average DB request time per dialog step in Milliseconds

The key fields for defining PI points are “SERVERNAME” and “TASKTYPE”. The data in fields “COUNT,” “MRESPTI,” “MCPUTI,” “MQUEUETI,” and “MDBCALLTI” are recorded in PI tags. Thus, five categories of PI points are created for this table and their tag names are: SERVERNAME_Task_TASKTYPE_Count, SERVERNAME_Task_TASKTYPE_Avg_Response_Time, SERVERNAME_Task_TASKTYPE_Avg_CPU_Time, SERVERNAME_Task_TASKTYPE_Avg_Queue_Time, SERVERNAME_Task_TASKTYPE_Avg_DBCall_Time.

For example, if the obtained RESPINFO table is as follows:

SERVERNAME TASKTYPE COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

sap1_DEV_00 AUTOABA 280 1795 1390 4 186

Five PI points are created for the data in this table. Their tag names and values are:

PI Tagname Value

sap1_DEV_00_Task_AUTOABA_Count 280

sap1_DEV_00_Task_AUTOABA_Avg_Response_Time 1795

sap1_DEV_00_Task_AUTOABA_Avg_CPU_Time 1390

sap1_DEV_00_Task_AUTOABA_Avg_Queue_Time 4

sap1_DEV_00_Task_AUTOABA_Avg_DBCall_Time 186

In addition to the performance response time sorted by task type for each application server of the target SAP system, this table also returns the total performance response time for all the servers sorted by task type and the total performance response time for all

14

the servers and all the task types. For example, the obtained RESPINFO table is as follows:

SERVERNAME TASKTYPE COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

ALL TOTTASK 995 3256 2599 8 347

TOTAL AUTOABA 380 2031 1868 5 218

TOTAL DIALOG 615 1225 731 3 129

sap1_DEV_00 AUTOABA 280 1795 1390 4 186

sap1_DEV_00 DIALOG 342 743 539 1 75

sap2_DEV_00 AUTOABA 100 236 478 1 32

sap2_DEV_00 DIALOG 273 482 192 2 54

The data in the first row for server name “ALL” and task type “TOTTASK” are the total performance response times for all the application servers and all the task types. The data in the second and third row are the total performance response times for all the application servers for task type AUTOABA and task type DIALOG, respectively. Therefore, for this table, a total of 35 points: 5 points for each row of data are created for recording the performance information.

Because the performance statistics in SAP is updated hourly, the suggested update frequency for table “RESPINFO” is every one hour after the hourly scheduled performance collector job is SAP is executed.

Table USERINFOThis table provides the total dialog steps, the response time, the CPU time and the wait time for a particular user. The fields of interest are:



USER CHAR 12 User/Account ID.






The key fields for defining PI points are “SERVERNAME” and “USER”. The data in fields “COUNT”, “MRESPTI”, “MCPUTI”, “MQUEUETI”, and “MDBCALLTI” are recorded in the PI server. Thus, 5 categories of PI points can be created for this table and their tag names are: SERVERNAME_USER_Count, SERVERNAME_USER_Avg_Response_Time, SERVERNAME_USER_Avg_CPU_Time, SERVERNAME_USER_Avg_Queue_Time, and SERVERNAME_USER_Avg_DBCall_Time.



For example, if the obtained USERINFO table is as follows:

SERVERNAME USER COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

sap1_DEV_00 JSMITH 624 671 125 1 452


PI Tagname Value

sap1_DEV_00_JSMITH_Count 624

sap1_DEV_00_JSMITH_Avg_Response_Time 671

sap1_DEV_00_JSMITH_Avg_CPU_Time 125

sap1_DEV_00_JSMITH_Avg_Queue_Time 1

sap1_DEV_00_JSMITH_Avg_DBCall_Time 452

In addition to the performance response time sorted by user account for each application server of the target SAP system, this table also returns the total performance response time for all the servers sorted by user and the total performance response time for all the servers and all the users. For example, the obtained USERINFO table is as follows:

SERVERNAME USER COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

ALL TOTUSER 995 3256 2599 8 347

TOTAL JSMITH 380 2031 1868 5 218

TOTAL PLOPEZ 615 1225 731 3 129

sap1_DEV_00 JSMITH 280 1795 1390 4 186

sap1_DEV_00 PLOPEZ 342 743 539 1 75

sap2_DEV_00 JSMITH 100 236 478 1 32

sap2_DEV_00 PLOPEZ 273 482 192 2 54

The data in the first row for server name “ALL” and task type “TOTUSER” are the total performance response times for all the application servers and all the users. The data in the second and third row are the total performance response times for all the application servers for user JSMITH and user PLOPEZ, respectively. Therefore, for this table, a total of 35 points: 5 points for each row of the data are created for recording the performance information.

The suggested scan frequency for this table is every one hour because the performance statistics in SAP is updated hourly.

Because the Interface creates five points for every user, it can generate a lot of points for a large SAP system with many users.

Table TRANINFOThis table provides the total dialog steps, the response time, the CPU time and the wait time for a particular transaction. The fields of interest are:


16


TCODE CHAR 40 Name of transaction code

BTCJOB CHAR 32 Background job name if applicable for the transaction






The key fields for defining PI points are “SERVERNAME” and “TCODE”. The data in fields “COUNT”, “MRESPTI”, “MCPUTI”, “MQUEUETI”, and “MDBCALLTI” are recorded in PI tags. Thus, 5 categories of PI points can be created for this table and their tagnames are: SERVERNAME_Transaction_TCODE_Count, SERVERNAME_Transaction_TCODE_Avg_Response_Time, SERVERNAME_Transaction_TCODE_Avg_CPU_Time, SERVERNAME_Transaction_TCODE_Avg_Queue_Time, SERVERNAME_Transaction_TCODE_Avg_DBCall_Time.

For example, if the obtained TRANINFO table is as follows:

SERVERNAME TCODE COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

sap1_DEV_00 ST03 2 736 63 0 225


PI Tagname Value

sap1_DEV_00_Transaction_ST03_Count 2

sap1_DEV_00_Transaction_ST03_Avg_Response_Time 736

sap1_DEV_00_Transaction_ST03_Avg_CPU_Time 63

sap1_DEV_00_Transaction_ST03_Avg_Queue_Time 0

sap1_DEV_00_Transaction_ST03_Avg_DBCall_Time 225

In addition to the performance response time sorted by user account for each application server of the target SAP system, this table also returns the total performance response time for all the servers and all the transactions. For example, if the obtained TRANINFO table is as follows:

SERVERNAME TCODE COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

ALL TOTTRAN 995 3256 2599 8 347

sap1_DEV_00 RFC 280 1795 1390 4 186ERP Performance Interface to the PI System 17


sap1_DEV_00 ST03 342 743 539 1 75

sap2_DEV_00 SE37 100 236 478 1 32

sap2_DEV_00 SM35 273 482 192 2 54

The data in the first row for server name “ALL” and task type “TOTTRAN” are the total performance response time for all the application servers and all the transaction codes. Therefore, for this table, a total of 25 points: 5 points for each row of the data are created for recording the performance information.

The suggested scan frequency for this table is every hour because the performance statistics in SAP are updated hourly.

Since this table returns data for every transaction executed by users and the Interface creates five points for each transaction, it is has the potential of creating a large number of points for a big SAP system.

Table STATINFOThis table contains the high resolution information regarding user, report/ABAP program statistics. The information is similar to that obtained from ST03 Workload Analysis on “Single Stat Records”. The fields of interest are:



STARTDATE DATS 8 Start date. Format YYYYMMDD

STARTTIME TIMS 6 Start time. Format HHMMSS

RESPTI DEC 15 Response time in ms

REPORT CHAR 40 Report name

ACCOUNT CHAR 12 User id

MANDT CLNT 3 Client number

The key fields for defining PI points are “SERVERNAME,” “REPORT,” “ACCOUNT,” and “MANDT.” The data in the field “RESPTI” is recorded in a PI tag. Thus, the tag name for the PI point created to store the data in this table is: SERVERNAME_REPORT_ACCOUNT_MANDT_Response_Time, and the response time returned in field “RESPTI” is stored as the point value in PI.

For example, if the obtained STATINFO table is as follows:

SERVERNAME STARTDATE STARTTIME RESPTI REPORT ACCOUNT MANDT

sap1_DEV_00 02/18/2004 00:57:59 54 SAPMSSY2 SAPSYS 000

One PI point is created for the data in this table. The time value returned in fields “STARTDATE” and “STARTTIME” is used as the timestamp for the values recorded in PI. The tagname, timestamp and value are:

PI Tagname Timestamp Value

18

sap1_DEV_00_SAPMSSY2_SAPSYS_000_Response_Time

Feb-18-2004 00:57:59 54

The suggested scan frequency for this table is daily, usually after midnight.

The output from the STATINFO table is the detailed workload analysis from ST03’s “Single Stat Records,” thus it has the potential of creating a point for every iteration of every user’s dialog steps within a running transaction. Therefore, a large number of points may be generated for recording data from this table.

Table APPLINFOThis table provides the performance responses data sorted by application components. The fields of interest are:



KL_NAME CHAR 20 Application component

COUNT DEC 15 Number of dialog steps

RESPTI DEC 15 Average response time per dialog step in Milliseconds

CPUTI DEC 10 Average CPU time per dialog step in Milliseconds

QUEUETI DEC 10 Average dispatcher wait time per dialog step in Milliseconds

DBTI DEC 10 Average DB request time per dialog step in Milliseconds

The key fields for defining PI points are “SERVERNAME” and “KL_NAME.” The data in fields “COUNT,” “RESPTI,” “CPUTI,” “QUEUETI,” and “DBTI” are recorded in the PI server. Thus, 5 categories of PI points can be created for this table and their tagnames are: SERVERNAME_KL_NAME_Count, SERVERNAME_KL_NAME_AVG_Response_Time, SERVERNAME_KL_NAME_ AVG_CPU_Time, SERVERNAME_KL_NAME_ AVG_Queue_Time, SERVERNAME_KL_NAME_ AVG_DBCall_Time.

For example, if the obtained APPLINFO table is as follows:

SERVERNAME KL_NAME COUNT RESPTI

CPUTI QUEUETI DBCALLTI

sap1_DEV_00 Basic Components 1406 305 182 1 50

Five PI points are created for the data in this table. Their tagnames and values are:

PI Tagname Value

sap1_DEV_00_Basic Components_Count 1406

sap1_DEV_00_Basic Components_Avg_Response_Time 305

sap1_DEV_00_Basic Components_Avg_CPU_Time 182

sap1_DEV_00_Basic Components_Avg_Queue_Time 1



sap1_DEV_00_Basic Components_Avg_DBCall_Time 50

In addition to the performance response time sorted by application component for each application server of the target SAP system, this table also returns the total performance response time for all the servers sorted by application component and the total performance response time for all the servers and all the application components. For example, the obtained APPLINFO table is as follows:

SERVERNAME KL_NAME COUNT RESPTI

CPUTI QUEUETI DBCALLTI

ALL TOTAPPL 995 3256 2599 8 347

TOTAL Basic Components 380 2031 1868 5 218

TOTAL Controlling 615 1225 731 3 129


sap1_DEV_00 Controlling 342 743 539 1 75


sap2_DEV_00 Controlling 273 482 192 2 54

The data in the first row for server name “ALL” and task type “TOTAPPL” are the total performance response times for all the application servers and all the application components. The data in the second and third row are the total performance response times for all the application servers for application component “Basic Components” and application component “Controlling,” respectively. Therefore, for this table, a total of 35 points: 5 points for each row of the data are created for recording the performance information.

The suggested scan frequency for this table is daily, usually after midnight.

Table TIMEINFOThis table returns the performance response data in a time range. The fields of interest are:



TTYPE RAW 1 Task type. (Dialog, Update, RFC, Background, etc.)

TIME CHAR 7 Time range. I.e. 00 – 01, 01 – 02, 02 – 03 etc

COUNT INT4 10 Number of dialog steps

MRESPTI DEC 15 Average response time in Milliseconds

MCPUTI DEC 15 Average CPU time in Milliseconds

MQUEUETI DEC 15 Average dispatcher wait time in Milliseconds

MDBCALLTI DEC 15 Average DB request time in Milliseconds

The key fields for defining PI points are “SERVERNAME” and “TTYPE.” The data in fields “COUNT,” “MRESPTI,” “MCPUTI,” “MQUEUETI,” and “MDBCALLTI” are recorded in PI. Thus, 5 categories of PI points can be created for this table and their

20

tagnames are: SERVERNAME_TTYPE_Count, SERVERNAME_TTYPE_Avg_Response_Time, SERVERNAME_TTYPE_Avg_CPU_Time, SERVERNAME_TTYPE_Avg_Queue_Time, SERVERNAME_TTYPE_Avg_DBCall_Time.

The data obtained in this table is summary information in hourly intervals that are identified by “TIME” filed. The interface parses out hourly data and stores all data for the same application server and task type from different time ranges to a single tag with different timestamps. The beginning time of the hourly interval returned in field “TIME” and the PI server time at which the function module is called are used together to determine the timestamp for the obtained data.

For example, if the obtained TIMEINFO table is as follows:

SERVERNAME TTYPE TIME COUNT MRESPTI MCPUTI MQUEUETI

MDBCALLTI

sap1_DEV_00 01 00-06 202 752 170 2 148

sap1_DEV_00 01 06-07 3 1 5 0 0

sap2_DEV_00 02 00-06 5 164 106 0 73

Additionally, the function module is called by the Interface on Oct. 20, 2003. “00-06” returned in “TIME” field means from Midnight to 6:00 AM and “06-07” means from 6:00 AM to 7:00 AM. Ten PI points are created for the data in this table. Their tagnames, values and corresponding timestamps are:

PI Tagname Timestamps Values

sap1_DEV_00_01_Count Oct-20-2003 00:00:00Oct-20-2003 06:00:00

2023

sap1_DEV_00_01_Avg_Response_Time Oct-20-2003 00:00:00Oct-20-2003 06:00:00

7521

sap1_DEV_00_01_Avg_Time Oct-20-2003 00:00:00Oct-20-2003 06:00:00

1700

sap1_DEV_00_01_Avg_Queue_Time Oct-20-2003 00:00:00Oct-20-2003 06:00:00

20

sap1_DEV_00_01_Avg_DBCall_Time Oct-20-2003 00:00:00Oct-20-2003 06:00:00

1480

sap2_DEV_00_02_Count Oct-20-2003 00:00:00 5

sap2_DEV_00_02_Avg_Response_Time Oct-20-2003 00:00:00 164

sap2_DEV_00_02_Avg_Time Oct-20-2003 00:00:00 106

sap2_DEV_00_02_Avg_Queue_Time Oct-20-2003 00:00:00 0

sap2_DEV_00_02_Avg_DBCall_Time Oct-20-2003 00:00:00 73In addition to the performance response time sorted by task type for each application server of the target SAP system, this table also returns the total performance response time for all the servers sorted by task type and time range and the total performance response time for all the servers and all the task types for the time range of 00-24. For example, the obtained TIMEINFO table is as follows:


MDBCALLTI

ALL 00 00-24 217 954 324 3 247




MDBCALLTI

TOTAL 01 00-06 209 789 213 3 174

TOTAL 01 06-07 3 1 5 0 0

TOTAL 02 00-06 5 164 106 0 73

sap1_DEV_00 01 00-06 202 752 170 2 148

sap1_DEV_00 01 06-07 3 1 5 0 0

sap2_DEV_00 01 00-06 7 37 43 1 26

sap2_DEV_00 02 00-06 5 164 106 0 73

The data in the first row for server name “ALL” and task type “00” are the total performance response times for all the application servers and all the task types for the time range 00-24. The data in the second, third and fourth rows are the total performance response times for all the application servers for task type 01 from 00-06, task type 01 from 06-07, and task type 02 from 00-06, respectively. Therefore, for this table, a total of 25 points are created for recording the performance information.

The scan frequency for this table should be daily, starting after midnight.

22

Installation ChecklistFor those users who are familiar with running PI data collection interface programs, this checklist helps you get the PI-ERP Performance interface running. If you are not familiar with PI interfaces, return to this section after reading the rest of the manual in detail.

1. Install Add-on and Support Packages onto the central instance of the SAP R/3 system.

2. Create and configure an SAP user account that will be used for this interface to open the RFC connection with the SAP system.

3. Test all three function modules against the target SAP system via SAP Front End. Verify that all the function modules are working and can successfully retrieve data.

4. Install the PI-Interface Configuration Utility (which installs PI-SDK and PI-API)

5. Verify that PI-SDK and PI-API have been installed.

6. Install the interface.

7. Choose a point source.

8. Configure Windows Performance Counters to monitor scan class performance. (Note: These are not the standard UniInt-based performance points.)

9. Configure I/O Rate tag.

10. Use PI-ICU to configure command-line parameters.

11. Set interface node clock.

12. Set up security.

13. Run PISAPLogon.exe to specify the SAP logon information (client number, user, and password) that the interface will use to make the RFC connection to the SAP R/3 system.

14. Start the interface without buffering.

15. Verify data.

16. Stop interface, start buffering, start interface.


SAP Add-on and Support Package Installation

SAP Add-onThree OSIsoft RFC-enabled function modules retrieve performance data from SAP systems. The function modules are: /OSI/MON_SERVER_INFO, /OSI/MON_SYSTOPER_INFO, and /OSI/MON_RESPONSE_TIME. These function modules must be installed on the central instance of the SAP R/3 system – the application server that runs the message server.

The function modules are provided as SAP Add-on packages and we provide several add-on packages to accommodate different versions of the SAP system. Install the add-on package corresponding to the version of your SAP system. The names of the add-on packages and the compliant SAP versions are given in the following table:

SAP Add-on Package SAP System Version

OSI11E31 3.1G, 3.1I, 3.1H

OSI11D40 4.0A, 4.0B

OSI11C45 4.5A, 4.5B

OSI11B46 4.6A, 4.6B, 4.6C

OSI11A47 Enterprise (4.7)

Prerequisites

Current Versions of Kernel, TP, and R3transMake sure that your system contains the current versions of Kernel, TP, and R3trans.

Current SPAM/SAINT UpdateMake sure that the most recent SPAM/SAINT Update has been imported into your system. Compare the short text of the last SPAM/SAINT Update imported with that of the SPAM/SAINT Update in the SAP Service Marketplace. If the version of the SPAM/SAINT Update in the SAP Service Marketplace is more recent, import it.

Read SAP Notes and DocumentationRead the SAP Notes 097630, 097629, 173814, 400280 and online documentation of the Add-on Installation Tool (SAINT).

Free Space in Transport DirectoryThe transport directory needs approximately 1MB of free space.


Check Component, Support Package, and Add-on VersionsThe following elements must be installed on the SAP system node, dependent on the version of the SAP system.

SAP System Components Support Packages Add-ons

3.1G, 3.1I, 3.1H SAP_BASIS 31H SAPKB31H01 PI_2003_1_31H

4.0A, 4.0B SAP_BASIS 40B SAPKB40B01 PI_2003_1_40B

4.5A, 4.5B SAP_BASIS 45B SAPKB45B01 PI_2003_1_45B

4.6A, 4.6B, 4.6C SAP_BASIS 46C SAP_BASIS 46C SP 1 PI_2003_1_46C

Enterprise (4.7) SAP_BASIS 620 SAP_BASIS 620 SP 1 PI_BASIS 2003_1_620

Preparation1. Mount the Add-on Installation CD.

2. Load the package corresponding to the version of your SAP system onto you system.

For more information on how to load installation packages, first run transaction SAINT from the SAP Front End and click on “Online Help (Shift F1)” to open the SAINT online help documentation. In the SAINT online help, navigate to “Loading Installation Packages.”

The documentation for the Add-on Installation Tool (SAINT) can also be found on the SAP help website:

http://help.sap.com/saphelp_47x200/helpdata/en/78/d18d38e9cf9e67e10000009b38f842/frameset.htm

Installation1. Log on to the SAP system from client 000 and as a user other than SAP* or DDIC,

but having SAP_ALL authorization.

2. Start the installation using the Add-on Installation Tool (transaction SAINT).

For more information on how to install the Add-on packages, run transaction SAINT from the SAP Front End and click on “Online Help (Shift F1)” to open SAINT the online help document. In the SAINT online help, navigate to “Installing and Upgrading Add-ons using the Add-on Installation Tool.”

The help document is also available on SAP help website:

http://help.sap.com/saphelp_47x200/helpdata/en/18/e08d38dfc44765e10000009b38f842/frameset.htm

PasswordNo password is required for installing the Add-on

Language SupportThe PI-ERP Performance Interface only supports English (EN).






Support Packages for the SAP Add-onIn accordance with the SAP certificate, any enhancement and/or bug fixing made for the RFC-enabled function modules will be delivered as support packages. Customers can obtain the support packages from OSIsoft Technical Support website or request a CD for the support packages.

The support packages must be installed with the Support Package Manager - SPAM in SAP (see online documentation to support package manager for uploading and installing support packages). The website is:

http://help.sap.com/saphelp_47x200/helpdata/en/a7/a7a932845c11d2b421006094b9ea64/frameset.htm




SAP User Account Creation and ConfigurationThe PI-ERP Performance Interface needs to open an RFC connection to the SAP system so that it can extract the data via the RFC-enabled function modules installed on the SAP system. In order for the interface to connect to the SAP system, an SAP user account (for example, IT_MON) must be specified via the PISAPLogon.exe utility.

The SAP System Administrator must first create an SAP user account (e.g., IT_MON) in SAP transaction SU01 as a normal dialog user with no authorizations or roles, then assign the standard SAP authorization roles SAP_BC_BASIS_ADMIN and SAP_BC_DWB_ABAPDEVELOPER to the user via SAP transaction PFCG. Make sure that all lights are green in the screen “Change role: Authorization” before activating the roles. If an authorization is yellow, modify the authorization with the value “*” (all values). After assigning the initial password to the SAP user account, logon to the SAP system with that username and password and assign the permanent password. (The SAP logon procedure will ask automatically.) The permanent password will be used as a parameter for the PI-ERP Performance Interface.


Test Function Modules via SAP Front EndThis interface invokes the function modules /OSI/MON_SERVER_INFO, /OSI/MON_SYSTOPER_INFO, and /OSI/MON_RESPONSE_TIME to retrieve the performance data from the SAP system. Therefore, in order for the interface to collect the SAP performance data, the function modules must work properly.

These function modules can be tested using SAP Front End. The detailed steps are as follows:

1. Start SAP Front End from Windows Start Programs SAP Front End SAPlogon to bring up the following dialog box:


2. If the target SAP system does not show up in the list, add it by clicking on the “New” button. A new dialog box will pop-up to be filled in with the required information about the target SAP system:

3. Select the SAP system that the interface is monitoring and click on the “Logon” button.


4. In the following dialog box, type in the same Client number, User and Password as used in the interface command-line parameters /rfc_dest=x, /user=x, and /pwd=x. Hit the “Enter” key or the green check button at the top left corner.

5. In the next dialog box, type in “SE37” and click on the green check button at the top left corner or hit the “Enter” key:


Test Function Modules via SAP Front End

6. In the next dialog box, input the name of the function module that to test and hit “F8” or click on the third button from the left that is located below “Function Builder: Initial Screen”.

7. Type in “X” for the “Value” field of all import parameters as shown below then hit “F8” or the first button from the left located below “Test Function Module: Initial Screen” to execute the function module and see if any error arises.

34

8. Repeat Step 6 and 7 for the next function module. You can hit “F3” or click on the green backwards button at the top to go back to the dialog box shown in Step 6.


Interface InstallationOSIsoft recommends that interfaces be installed on PI Interface Nodes instead of directly on the PI Server node. A PI Interface Node is any node other than the PI Server node where the PI Application Programming Interface (PI-API) has been installed (see the PI-API manual). With this approach, the PI Server need not compete with interfaces for the machine’s resources. The primary function of the PI Server is to archive data and to service clients that request data.

After the interface has been installed and tested, Bufserv should be enabled on the PI Interface Node (once again, see the PI-API manual). Bufserv is distributed with the PI-API. It is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when communication to the PI Server is lost. Communication will be lost when there are network problems or when the PI Server is shut down for maintenance, upgrades, backups, or unexpected failures.

In most cases, interfaces on PI Interface Nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.

The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and interfaces as manual services that are launched by site-specific command files when the PI Server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI Server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI Server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI Server node. See the UniInt End User Document for special procedural information.

Naming Conventions and RequirementsIn the installation procedure below, it is assumed that the name of the interface executable is pierpperf.exe and that the startup command file is called pierpperf.bat.

It is customary for the user to rename the executable and the startup command file when multiple copies of the Interface are run. For example, one would typically use pierpperf1.exe and pierpperf1.bat for interface number 1, pierpperf2.exe and pierpperf2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in a file that has the same root name.

Interface Directories

The PIHOME Directory TreeThe PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the WinNT directory. A typical pipc.ini file contains the following lines:[PIPC]PIHOME=c:\pipc


The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.

Interface Installation DirectoryPlace all copies of the Interface into a single directory. The suggested directory is:PIHOME\interfaces\ERPperf\Replace PIHOME with the corresponding entry in the pipc.ini file.

Interface Installation ProcedurePrior to installing the PI-ERP Performance Interface, you should have already imported the RFC-enabled function modules provided by OSIsoft into the central instance of the R/3 system.

The PI-ERP Performance Interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000. When running on Windows NT 4.0 systems, the PI-ERP Performance Interface setup program will install the Windows Installer itself if necessary. To install, run the ERPperf_x.x.x.x.exe installation kit.

Installing the Interface as an Windows ServiceThe PI-ERP Performance Interface service can be created with the PI-Interface Configuration Utility, or can be created manually.

Installing the Interface Service with PI-Interface Configuration UtilityThe PI-Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service:


Service Configuration

Service nameThe Service to Add box shows the name of the current interface service. This service name is obtained from the interface executable.

Display nameThe Display Name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of the OSI suite of products.

Service TypeThe Service Type indicates whether the interface service will start automatically or need to be started manually on reboot.

If the Auto option is selected, the service will be installed to start automatically when the machine reboots.

If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.

If the Disabled option is selected, the service will not start at all.

Generally, interface services are set to start automatically.

DependenciesThe Installed services list is a list of the services currently installed on this machine. Services upon which this Interface is dependant should be moved into the Dependencies

list using the button. For example, if API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left. Often interface services also depend on a vendor program, such as the Fisher-Rosemount

chipservice. To remove a service from the list of dependencies, use the button, and the service name will be removed from the “Dependencies” list.

When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.

Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.

- Add buttonTo add a dependency from the list of Installed services, select the dependency name, and click the Add button.

- Remove buttonTo remove a selected dependency, highlight the service name in the Dependencies list, and click the Remove button.


Interface Installation

The full name of the service selected in the Installed services list is displayed below the Installed services list box.

CreateThe Create button adds the displayed service with the specified Dependencies and with the specified Startup Type.

Remove The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out.

Start or Stop ServiceTo Start or Stop an interface service, use the Start button and a Stop button on the ICU toolbar. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.

The status of the Interface service is indicated in the lower portion of the PI-ICU dialog.

Installing the Interface Service ManuallyOne can get help for installing the interface as a service at any time with the command:PIERPperf.exe –help

Change to the directory where the PIERPperf.exe executable is located. Then, consult the following table to determine the appropriate service installation command.

Windows Service Installation Commands on a PI Interface Node or a PI Server node

with Bufserv implemented

Manual service PIERPperf.exe –install –depend “tcpip bufserv”

Automatic service PIERPperf.exe –install –auto –depend “tcpip bufserv”

Windows Service Installation Commands on a PI Interface Node or a PI Server node

without Bufserv implemented

Manual service PIERPperf.exe –install –depend tcpip

Automatic service PIERPperf.exe –install –auto –depend tcpip

When the interface is installed as a service on the PI Server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will repeatedly attempt to connect to the PI Server until it is successful.

Note: Interfaces are typically not installed as automatic services when the interface is installed on the PI Server node.

40

Status of the ICU Status of the

Interface Service

Service installed or uninstalled

Check the Microsoft Windows services control panel to verify that the service was added successfully. One can use the services control panel at any time to change the interface from an automatic service to a manual service or vice versa.


Digital StatesFor more information regarding Digital States, refer to the Data Archive Manuals.

Digital State SetsPI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI digital tags and editing digital state sets, see the PI Server manuals.

An interface point that contains discrete data can be stored in PI as a digital tag. A Digital tag associates discrete data with a digital state set, as specified by the user.

This interface automatically creates the Digital State Set SAPInstanceStatus with the following settings.

Value Digital State String

0 Not Available

1 Available

This set is used for tags from table SYSTEM_LIST, which is returned by function module /OSI/MON_SERVER_INFO, to indicate the availability of an SAP instance (i.e., application server).

System Digital State SetSimilar to digital state sets is the system digital state set. This set is used for all tags, regardless of type to indicate the state of a tag at a particular time. For example, if the interface receives bad data from an interface point, it writes the system digital state bad input to PI instead of a value. The system digital state set has many unused states that can be used by the interface and other PI clients.


PointSourceThe PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For example, one may choose the letter S to identify points that belong to the PI-ERP Performance Interface. To implement this, one would set the PointSource attribute to S for every PI Point that is configured for the PI-ERP Performance Interface. Then, if one uses /ps=S on the startup-command line of the PI-ERP Performance Interface, the PI-ERP Performance Interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of S. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps argument.

Case-sensitivity for PointSource AttributesIf the interface is running on a PINet node and the Server node is a PI 3 system, use a capital letter (or a case-insensitive character such as a number, a question mark, etc.) for the PointSource attribute when defining points. For all other scenarios, one does not need to be careful with the case of the PointSource.

In all cases, the point source character that is supplied with the /ps command-line argument is not case sensitive. That is, /ps=S and /ps=s are equivalent. One only needs to be careful with the case of the PointSource during point definition, and only if the interface will be running on a PINet node communicating to a PI 3 Server.

No point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character. Several subsystems and applications that ship with PI 3 are associated with default point source characters. The Totalizer Subsystem uses the point source character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Either do not use these point source characters or change the default point source characters for these applications. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.


PI Point ConfigurationThe PI point is the basic building block for controlling data flow to and from the PI Data Archive. A single point is configured for each measurement value that needs to be archived. Use the point attributes below to define what data to transfer.

Note: PI points are created by the interface according to the specifications detailed below.

Point Attributes

TagA tag is a label or name for a point. Any tag name can be used in accordance to the normal PI point naming conventions. In this interface, the PI points created by the interface will have tag names as described in “Principles of Operation”

PointSourceThe PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line argument and the “Point Source” section.

PointTypeThis interface supports float16, float32, float 64, int16, int32, digital, and string PointTypes.

Location1Location1 indicates to which copy of the interface the point belongs.

Location2This Interface does not use Location2.

Location3This Interface does not use Location3.

Location4Location4 defines the scan class for the PI point. The scan class determines the frequency at which input points are scanned for new values. For more information, see the description of the /f=x flag in the section called “Startup Command File.”

The PI-ERP Performance Interface automatically creates the necessary PI points based on the received tables and updates values of the points according to the data in the returned tables. The interface assigns a scan class number to Location4 of the points when they are created and all the points from one table belong to the same scan class. The scan frequency corresponding to each scan class is defined in the startup command file. The interface can retrieve up to 16 tables via the function modules and it requires


that 16 scan frequencies be specified in the startup command file, even if data from some of the tables will not be stored in PI.

The Location4 values for each table returned by the 3 function modules are listed below:

Function Module Table Location4

/OSI/MON_SERVER_INFO SYSTEM_LIST 1

KERNEL_INFO 2

VERSION_INFO 3

OS_MONITOR 4

VERSION_COMP 5

BUFFER_STAT 6

/OSI/MON_SYSTOPER_INFO SPOOLINFO 7

ADUMPINFO 8

UPDV1INFO 9

SYSLGINFO 10

/OSI/MON_RESPONSE_TIME RESPINOF 11

USERINFO 12

TRANINFO 13

STATINFO 14

APPLINFO 15

TIMEINFO 16

When the interface creates PI points for an obtained table, Location4 for these points will have the value defined in the above table. For example, points generated for “SYSTEM_LIST” have Location4=1.

Location5The Interface does not use Location5.

InstrumentTagThe InstrumentTag is limited to 1024 characters.

When a point is created, the PI-ERP Performance Interface adds the function module and the table name with which the point is associated to InstrumentTag of the point. The values in the key field(s) for defining the PI point are also specified in the InstrumentTag. In addition, a name indicating what type of value is stored for the PI point is specified in the InstrumentTag.

For example, a point is generated for table “BUFFER_STAT” that is retrieved by “/OSI/MON_SERVER_INFO” to record the number of objects swapped. The InstrumentTag for this point is specified by the interface as:FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2= AREA_NAME; VALUE=Swaps;


Note that the specified “SERVERNAME” for “KEY1” is the value returned in field “SERVERNAME” and the “AREA_NAME” in “KEY2” is the value returned in field “AREA_NAME”. For example, the obtained “BUFFER_STAT” table has the following content:

SERVERNAME AREA_NAME Swaps

sap1_DEV_00 Program 0

sap2_DEV_00 Screen 1

Two PI points are created with the following InstrumentTags:

PI Tagname InstrumentTag

sap1_DEV_00_Program_Swaps

FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=sap1_DEV_00; KEY2=Program; VALUE=Swaps;

sap2_DEV_00_Screen_Swaps FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=sap2_DEV_00; KEY2=Screen; VALUE=Swaps;

For the detailed descriptions about InstrumentTag setting for each point, see the “Interface-specific Point Configuration” section.

ExDesc

Performance Points

Note: The PI-ERP Performance interface must not use standard UniInt-based Performance Points because they will cause confusion in the Hierarchy Builder utility. See the “Windows Performance Counter Configuration” section for an alternative.

ScanBy default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.

There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.

ShutdownThe shutdown attribute is used only if the server node is a PI 3 system.

The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of a power failure. For additional information on shutdown events, refer to PI Server manuals.


PI Point Configuration

Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat=Shutdown command-line argument is specified.

One can disable SHUTDOWN events from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Server manuals.

Bufserv It is undesirable to write shutdown events when Bufserv is being used. Bufserv is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when the Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when PI is shut down, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.

Interface-specificAll the points automatically created by this interface have the Shutdown attribute equal to 1, except for the points from table SYSTEM_LIST, KERNEL_INFO, and VERSION_INFO (i.e., Location1=1, 2, 3, respectively). The points from these three tables provide basic system information for the SAP system, so in order to avoid confusion to the SAP system administrator, the Shutdown attribute is set to 0 for these points.

StepThe step attribute defines how the archived values are interpolated. The default behavior, step OFF (0), treats archived values as a continuous signal. Adjacent archived values are linearly interpolated. For example, at 12:00:00, the value 101.0 is archived and at 12:01:00, the value 102.0 is archived. A request for the archive value at 12:00:30 would return 101.5.

A step attribute of ON (1) treats the archived values discretely. Adjacent archived values are not interpolated; an archived value is assumed constant until the next archived value.

For example:

At 12:00:00, the value 101.0 is archived, At 12:01:00, the value 102.0 is archived,

A request for the value at 12:00:30 would return 101.0.

In general, the PI-ERP Performance Interface sets the step attribute OFF for the points that it automatically creates, except for the points for table “TIMEINFO”. The points for table “TIMEINFO” retrieved by function module “/OSI/MON_RESPONSE_TIME” should have the step attributes ON.

DescriptorThe descriptor is a text field. In this interface, when a point is automatically created by the interface, descriptive information about the point is put in the descriptor attribute.

50

EngUnitsThe engineering unit string describes the units of the measurement. For all the points automatically created by this interface, an appropriate engineering unit is added for each point based on the type of data returned, i.e. average response time per dialog step has Milliseconds for the engineering units.


Windows Performance Counter ConfigurationMany UniInt-based interfaces support performance points. That is, performance points are configured to monitor the amount of time in seconds that an interface takes to complete a scan for a particular scan class. However, for the PI-ERP Performance Interface, you should not configure any PI Performance points because they will be picked up by the Hierarchy Builder utility. Instead, to monitor the amount of time that the PI-ERP Performance Interface takes to complete a scan, use Windows Performance Counters and the PI-Performance Monitor Interface.

From the PI-Perfmon Interface Point Creation utility, first select "PI-ERP Performance" from the list of Performance objects:


Windows Performance Counter Configuration

Then, select the Scan Time performance object and a particular scan class. In the example below, Scan Class 4 is selected.

54

I/O Rate Tag ConfigurationAn I/O Rate point can be configured to receive 10-minute averages of the total number of exceptions per minute that are sent to PI by the interface. An exception is a value that has passed the exception specifications for a given PI point. Since 10-minute averages are taken, the first average is not written to PI until 10 minutes after the interface has started. One I/O Rate tag can be configured for each copy of the interface that is in use.

Monitoring I/O Rates on the Interface NodeFor Windows and UNIX nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.

Configuring I/O Rate Tags with PI-ICU (Windows)The PI-Interface Configuration Utility (PI-ICU) provides a user interface for creating and managing IORates Tags.

PI-ICU currently allows for one I/O Rate tag to be configured for each copy of the interface that is in use. Some interfaces allow for multiple I/O Rates tags.

Enable IORates for this InterfaceThe Enable IORates for this interface check box enables or disables IORates for the current interface. To disable IORates for the selected interface, uncheck this box. To enable IORates for the selected interface, check this box.

Tag StatusThe Tag Status column indicates whether the IORates tag exists in PI. The possible states are:

Created – This status indicates that the tag exist in PI

Not Created – This status indicates that the tag does not yet exist in PI

Deleted – This status indicates that the tag has just been deleted

Unknown – This status indicates that the ICU is not able to access the PI Server

In FileThe In File column indicates whether the IORates tag listed in the tag name and the event counter is in the IORates.dat file. The possible states are:

Yes – This status indicates that the tag name and event counter are in the IORates.dat file


No – This status indicates that the tag name and event counter are not in the IORates.dat file

Event CounterThe Event Counter correlates a tag specified in the iorates.dat file with this copy of the interface. The command line equivalent is /ec=x, where x is the same number that is assigned to a tag name in the iorates.dat file.

TagnameThe tag name listed under the Tagname column is the name of the IORates tag.

SnapshotThe Snapshot column holds the snapshot value of the IORates tag, if the IORates tag exists in PI. The Snapshot column is updated when the IORates/Status Tags tab is clicked, and when the interface is first loaded.

Right Mouse Button Menu OptionsCreateCreate the suggested IORates tag with the tag name indicated in the Tagname column.

DeleteDelete the IORates tag listed in the Tagname column.

RenameOptionally specify a new name for the IORates tag listed in the Tagname column.

Add to FileAdd the tag to the IORates.dat file with the event counter listed in the Event Counter Column.

SearchAllow the user to search the PI Server for a previously defined IORates tag.

Configuring I/O Rate Tags ManuallyThere are two configuration steps.

Configuring the PI Point on the PI ServerCreate an I/O Rate Tag with the following point attribute values.

Attribute Value

PointSource L

PointType float32

Compressing 0

ExcDev 0


Configuration on the Interface NodeFor the following examples, assume that the name of the PI tag is erpperf001, and that the name of the I/O Rate on the home node is sy_io_erpperf001.

1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the \WinNT directory. If both are specified, the PIPCSHARE entry takes precedence.

Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.

Add a line in the iorates.dat file of the form:sy_io_erpperf001, x

where sy_io_erpperf001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. X can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.

2. Set the /ec=x flag on the startup command file of the interface to match the event counter in the iorates.dat file.

The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.


Startup Command FileCommand-line arguments can begin with a / or with a -. For example, the /ps=S and –ps=S command-line arguments are equivalent.

For Windows, command file names have a .bat extension. The Windows continuation character (^) allows one to use multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of flags is unlimited, and the maximum length of each flag is 1024 characters.

Configuring the Interface with PI-ICU

Note: PI-ICU requires PI 3.3 or greater.

The PI-Interface Configuration Utility provides a graphical user interface for configuring PI interfaces. If the interface is configured by the PI-ICU, the batch file of the interface (pierpperf.bat) will be maintained by the PI-ICU and all configuration changes will be kept in that file. The procedure below describes the necessary steps for using PI-ICU to configure the PI-ERP Performance Interface.

From the PI-ICU menu, select Interface, New, and then Browse to the PIERPperf.exe executable file. Then, enter values for Point Source and Interface ID#. A window such as the following results:

“Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name and it will be the display name in the services menu.

Click on Add.

You should then see a display such as the following:


Startup Command File

Note that in this example the Host PI System is localhost, which means that the interface will be configured to communicate with the local PI Server. However, if you want the interface to communicate with a remote PI Server, you can do this by selecting ‘Connections…’ item from PI-ICU menu and make it your default server. If you do not see the remote node in the list of servers, you can add that in.

Once you add the interface to PI-ICU, near the top of the main PI-ICU screen, the Interface Type should be erpperf. If not, use the drop-down box to change the Interface Type to be erpperf.

Click on Apply to enable the PI-ICU to manage this copy of the PI-ERP Performance Interface.

60

The next step is to make selections in the interface-specific tab (i.e. “erpperf”) that allow you to enter values for the startup parameters that are particular to the PI-ERP Performance Interface. Any items with a background of yellow indicate a missing or invalid entry. These items are required items and must be entered correctly.

Since the PI-ERP Performance Interface is a UniInt-based interface, in some cases the user will need to make appropriate selections in the UniInt tab. This tab allows the user to access UniInt features through the PI-ICU and to make changes to the behavior of the interface.

If you want to set up the interface as a Windows Service, you can do that by using the Service tab. This tab allows you to configure the interface to run as a service as well as to start and stop the interface. You can also run the interface interactively from the PI-ICU. To do that go to menu, select the Interface item and then Start Interactive.

For more detailed information on how to use the above-mentioned and other PI-ICU tabs and selections, please refer to the PI-Interface Configuration Utility User Manual. In the next section we will describe the selections that are available from the erpperf tab. After you have made your selections on the PI-ICU GUI, you will need to press the Apply button in order for PI-ICU to make these changes to the interface’s startup file.

ERPperf Interface TabSince the startup file of the PI-ERP Performance Interface is maintained automatically by the PI-ICU, you should use the ERPperf tab to configure the startup parameters and not



make changes in the file manually. The following is the description of interface configuration parameters used in the PI-ICU Control and corresponding manual parameters.

General

1. Create Encrypted SAP Logon File – This button is used to invoke a standalone utility (PISAPLogon utility) to create an encrypted SAP Logon File which consists of the client number, username and password needed for opening an RFC connection to the SAP R/3 system. After clicking on this button the following dialog box will appear.

62

1

23456

789

1011

12

13

Fill in the SAP Logon Client, SAP Logon User and SAP Logon Password. Once the information is entered then click on the “Save As …” button. This will bring up the following box. The default filename is already filled in as “pisaplogon.pas”. You may change this is you wish. You will also have to navigate to the directory where you want to store this file. A suggested location is PIHOME\Interfaces\ERPperf\ where PIHOME is usually C:\Program Files\PIPC\ or C:\PIPC\.

After choosing a name and location click on the save button. If the file already existed in this location you will rececive the following dialog. Click yes to replace it.



Finally you will get the following showing where the file was saved and its name. Remember this path and filename as you will need it in the next step.

2. Encrypted SAP Logon File – This box is used to place the path and filename of the saved encrypted SAP Logon File. Notice the small button with three periods at the end of this box. Clicking this button will bring up a browse dialog which can be used to choose the folder and filename of the encrypted SAP Logon file. (/SAPLOGONFILE=path\filename)

3. SAP Node – This is used to specify the host name of the target SAP R/3 System. It can be a host name or IP address of the machine on which the target SAP system resides. The small box at the end with the three periods can be used to browse for the system. (/SAPHOST=hostname or IP address)

64

4. System Number - This optional parameter is the system number (0-99) of the target SAP R/3 system. The default is 0. (/SYSNR=x)

5. Gateway - The optional gateway parameter specifies the host name of the SAP gateway. Enter the host name for the gateway in the text box or use the triple dot button to browse to and select the gateway node. If the gateway is not specified, the gateway is assumed to be on the SAP node. (/GWHOST=gateway hostname)

6. Gateway Service - This optional parameter specifies the gateway service. If not specified, the service “sapgw##” where ## = the system number is assumed. (/GWSERVICE=gateway service)

7. Retry unsuccessful scans – Interval, Number of retries, Minimum scan period: Usually if the interface fails to obtain the performance data from the SAP system due to SAP problems, network problems or other reasons, the values for this scan are missed and the interface will wait until the next scan to next retrieve data. Because some of the scan intervals for this interface can be long (e.g. daily), you can configure the interface to try multiple times to extract the data at one scan so that if it fails at the first attempt it does not have to wait until the next scan. The Interval (in seconds) between each retry, the Number of times to retry, and the Minimum scan period (in seconds) that qualifies for retry can be specified in the Retry Unsuccessful Scans section of the erpperf General tab.

8. The default values are Interval =300, Number of retries =5 and Minimum scan period = 86400. This means that by default the interface will try at most 5 times to extract data at one scan. The time interval between each attempt is 300 seconds and the interface will only retry for scan classes with scan periods greater than or equal to 86400 seconds.

9. When the interface is trying to retrieve data for one scan, the data updating for other scan classes can be delayed. Therefore, it is recommended to set the retry parameters so that the interface will try multiple times only for long scan classes and the maximum number of retries should be limited. (/RETRY=x,y,z)



10. Interface debugging - Check the Interface debugging box to send extra interface specific messages to the pipc.log file for debugging purposes.(/DBG)

11. SAP Trace On - If the SAP trace level is 0 no trace is written. If it is 1 the RFC library traces all activities into a file ‘dev_rfc’ in the actual working directory. (/SAPTRACE=0 or 1)

12. Client for data extraction - Enter a client number if you want to retrieve SPOOLINFO, ADUMPINFO, and UPDV1INFO data for that specific client only. Leave blank if you want to extract data for all clients. (/MANDT=x)

13. Additional Parameters - This text box is included so that any additional parameters added to the interface in the future can be configured. Before the ICU Control is modified to handle them. Arguments should be entered into the additional arguments textbox in command line format with each argument starting with either a / or - character.

Tag CreationSelect which tables you want the interface to automatically create PI points for by checking the table name in the ‘Automatically Create PI Points For:’ pane.

1. Create PI Points for all Tables - To select all tables check Create PI Points for all Tables. This will cause the control to check all the tablename boxes.

66

1 2

2. Start all tagnames with – This is used to specify a tagname prefix for all the points associated with this instance of the interface. It is highly recommended to specify a prefix to make it easier for to categorize and group points. (/TAG_PREFIX=prefix)

General ParametersThe following parameters can be configured on the General PI-ICU tab shown below:

Point sourceThe point source is used to identify points for this interface and is a required parameter. The point source that is assigned with this parameter corresponds to the pointsource attribute of individual PI points. The interface will attempt to load only those PI points with the appropriate point source. The point source is generally a single character but if the PI-SDK is enabled can be more than one character. The point source is case insensitive. The command line equivalent is /ps=x.

PI Host This is the PI server node. Select the PI server from the drop down list. If the server is not listed in the drop down list, use the triple dot button to browse to the Connections Dialog and add the server. The added server will then be available in the drop down list. The command line equivalent is /host=hostname[:port].



Interface ID #This required parameter is an integer that is used to identify a particular copy of an interface. The ID should match the value in Location 1 of points for this copy of the interface. This identifier is also added to the header that is used to identify error messages as belonging to a particular interface. The command line equivalent is /id=x

Scan classesScan classes determine the frequency of data collection. Because each received table corresponds to one scan class. The PI-ERP Performance Interface requires that 16 scan classes must be specified, even if the interface is not recording data from all 16 tables.

A scan class is specified as the period followed by an optional offset in the format hh:mm:ss, hh:mm:ss. The offset indicates when to start the first data collection and the period indicates how often thereafter to collect data.

To create a new scan class press the new scan class button and enter the desired scan class value in the field provided and hit enter. To delete a scan class, select it from the

list and press the delete button .

The first scan class in the list defines the first scan class of the interface; the second entry in the list defines the second scan class, and so on. All PI Points that have Location 4 set to 1 will receive input values at the frequency defined by the first scan class in the list. Similarly, all points that have Location4 set to 2 will receive input values at the frequency specified by the second scan class, and so on. To change the order of the scan classes in the list, select the scan class to be moved and press the appropriate arrow key

.

The command line equivalent is /f.

Other UniInt ParametersOther optional parameters that can be configured on the UniInt tab include:

Enable PI-SDKBy default, the PI-SDK is disabled. If the PI-SDK is enabled, the ExDesc tag attribute can be 1024 characters long instead of 80 characters long. In addition, the ExcMin and ExcMax tag attributes will be full 32-bit values, and the point source can have more than one character. To enable the PI-SDK select the Enable radio button in the PI-SDK section of the UniInt tab. The command line equivalent is /pisdk=x.

Queue DataExceptions can be queued before they are sent to the PI Server node. Queuing exceptions causes the interface to be more efficient, if the interface is on a separate computer from the PI Server. However, it will slightly delay the update of the snapshot value if the data rate is low. The maximum queue size is close to 4000 bytes. The queue is flushed between scans if it is not filled. To use this option check “Queue data” in the Data Handling section of the UniInt tab. The command line equivalent is /q.

Write Digital State to Tags on ShutdownThe interface can be configured to write a digital state to each PI point serviced by the interface when the interface shuts down. To use this option check “Write status to tags on

68

shutdown” in the Data Handling section of the UniInt tab and select the required digital state from the dropdown list. If this option is not checked nothing will be written to the interface points when the interface shuts down. The command line equivalent is /stopstat=digstate.

Command-line ParametersParameter Description

/SAPlogonfile=file

Required

Default: none

In order for the interface to connect to the SAP system, the user must use PISAPLogon utility to specify the SAP logon information. The PISAPLogon utility is a standalone utility that allows a user to set the SAP logon information for opening an RFC connection from the interface to the SAP R/3 system: the client number, the user name and the password. After the SAP logon information is filled in by the user, the utility will then encrypt the information and save it to a user-specified file. You can start the utility by directly running PISAPLogon.exe that is installed in the interface directory or using PI-ICU. Refer to “ERPperf Interface Tab” section for the details.

The name and the full path of the file that contains the encrypted SAP logon information are specified by the /SAPlogonfile=name flag.

For example, if the SAP logon information is saved in file saplogon.pas and the file is in C:\PIPC\Interfaces\ERPperf directory, set

/SAPlogonfile="C:\PIPC\Interfaces\ERPperf\saplogon.pas"

/SAPhost=hostname

Required

Default: none

The /SAPhost flag is used to specify the host name of the target SAP R/3 system. It can be a host name or IP address of the machine on which the target SAP system resides.

/sysnr=x

Optional

Default: 0

The /sysnr flag is used to identify the system number (0-99) of the target SAP R/3 system. In general, this is 0. Thus, if not specified, a default number of 0 is used.

/gwhost=gateway hostname

Optional

Default: host name specified by /SAPhost

The /gwhost flag is used to specify the host name of the SAP gateway. If not specified, the host name specified by /SAPhost is used, i.e., the gateway is assumed to run at hostname.

/gwservice=gateway service

Optional

Default: sapgw<sys#>

The /gwservice flag is used to specify the gateway service. If not specified, the service “sapgw##” with ## = ‘sysnr’ is assumed.

/SAPtrace=#

Optional

Default: 0

The /SAPtrace flag is used to specify the SAP trace level. 0, no trace is written. 1, the RFC library traces all activities into a file ‘dev_rfc’ in the actual working directory. If not specified, the default trace level is set to 0.



Parameter Description

/tag_prefix=prefix

Optional

Default: none

The /tag_prefix flag is used to specify a tag name prefix for all the points associated with this instance of interface. For example, if /tag_prefix=PRD_ is presented, the interface will add “PRD_” in front of the tag name for all the points that the interface generates, i.e., the tag names of all the points automatically created by this interface will start with “PRD_”. If this flag is absent, none tag prefix will be added to the tag names.

It is highly recommended to specify the /tag_prefix flag so that it is easier for you to categorize and group the points. When there are more than one instance of PI-ERP Performance Interface running, you must specify a different /tag_prefix for each instance of the interface. Otherwise, two PI-ERP Performance Interface will try to generate tags with the same name, which will fail and cause data loss.

/SYSTEM_LIST=x

Required

Default: none

The /SYSTEM_LIST is used to specify whether the interface will automatically create necessary PI points for table “SYSTEM_LIST” upon receiving the table data or not.

/SYSTEM_LIST=0 means the interface will not automatically create points for recording data from table “SYSTEM_LIST”. The values of the existing points will still be updated by the interface.

/SYSTEM_LIST=1 means the PI points for table “SYSTEM_LIST” will be generated automatically by the interface.

/KERNEL_INFO=x

Required

Default: none

The /KERNEL_INFO is used to specify whether the interface will automatically create necessary PI points for table “KERNEL_INFO” upon receiving the table data or not.

/KERNEL_INFO=0 means the interface will not automatically create points for recording data from table “KERNEL_INFO”. The values of the existing points will still be updated by the interface.

/KERNEL_INFO=1 means the PI points for table “KERNEL_INFO” will be generated automatically by the interface.

/VERSION_INFO=x

Required

Default: none

The /VERSION_INFO is used to specify whether the interface will automatically create necessary PI points for table “VERSION_INFO” upon receiving the table data or not.

/VERSION_INFO=0 means the interface will not automatically create points for recording data from table “VERSION_INFO”. The values of the existing points will still be updated by the interface.

/VERSION_INFO=1 means the PI points for table “VERSION_INFO” will be generated automatically by the interface.

70


/OS_MONITOR=x

Required

Default: none

The /OS_MONITOR is used to specify whether the interface will automatically create necessary PI points for table “OS_MONITOR” upon receiving the table data or not.

/OS_MONITOR=0 means the interface will not automatically create points for recording data from table “OS_MONITOR”. The values of the existing points will still be updated by the interface.

/OS_MONITOR=1 means the PI points for table “OS_MONITOR” will be generated automatically by the interface.

/VERSION_COMP=x

Required

Default: none

The /VERSION_COMP is used to specify whether the interface will automatically create necessary PI points for table “VERSION_COMP” upon receiving the table data or not.

/VERSION_COMP=0 means the interface will not automatically create points for recording data from table “VERSION_COMP”. The values of the existing points will still be updated by the interface.

/VERSION_COMP=1 means the PI points for table “VERSION_COMP” will be generated automatically by the interface.

/BUFFER_STAT=x

Required

Default: none

The /BUFFER_STAT is used to specify whether the interface will automatically create necessary PI points for table “BUFFER_STAT” upon receiving the table data or not.

/BUFFER_STAT=0 means the interface will not automatically create points for recording data from table “BUFFER_STAT”. The values of the existing points will still be updated by the interface.

/BUFFER_STAT=1 means the PI points for table “BUFFER_STAT” will be generated automatically by the interface.

/SPOOLINFO=x

Required

Default: none

The /SPOOLINFO is used to specify whether the interface will automatically create necessary PI points for table “SPOOLINFO” upon receiving the table data or not.

/SPOOLINFO=0 means the interface will not automatically create points for recording data from table “SPOOLINFO”. The values of the existing points will still be updated by the interface.

/SPOOLINFO=1 means the PI points for table “SPOOLINFO” will be generated automatically by the interface.

/ADUMPINFO=x

Required

Default: none

The /ADUMPINFO is used to specify whether the interface will automatically create necessary PI points for table “ADUMPINFO” upon receiving the table data or not.

/ADUMPINFO=0 means the interface will not automatically create points for recording data from table “ADUMPINFO”. The values of the existing points will still be updated by the interface.

/ADUMPINFO=1 means the PI points for table “ADUMPINFO” will be generated automatically by the interface.




/UPDV1INFO=x

Required

Default: none

The /UPDV1INFO is used to specify whether the interface will automatically create necessary PI points for table “UPDV1INFO” upon receiving the table data or not.

/UPDV1INFO=0 means the interface will not automatically create points for recording data from table “UPDV1INFO”. The values of the existing points will still be updated by the interface.

/UPDV1INFO=1 means the PI points for table “UPDV1INFO” will be generated automatically by the interface.

/SYSLGINFO=x

Required

Default: none

The /SYSLGINFO is used to specify whether the interface will automatically create necessary PI points for table “SYSLGINFO” upon receiving the table data or not.

/SYSLGINFO=0 means the interface will not automatically create points for recording data from table “SYSLGINFO”. The values of the existing points will still be updated by the interface.

/SYSLGINFO=1 means the PI points for table “SYSLGINFO” will be generated automatically by the interface.

/RESPINFO=x

Required

Default: none

The /RESPINFO is used to specify whether the interface will automatically create necessary PI points for table “RESPINFO” upon receiving the table data or not.

/RESPINFO=0 means the interface will not automatically create points for recording data from table “RESPINFO”. The values of the existing points will still be updated by the interface.

/RESPINFO=1 means the PI points for table “RESPINFO” will be generated automatically by the interface.

/USERINFO=x

Required

Default: none

The /USERINFO is used to specify whether the interface will automatically create necessary PI points for table “USERINFO” upon receiving the table data or not.

/USERINFO=0 means the interface will not automatically create points for recording data from table “USERINFO”. The values of the existing points will still be updated by the interface.

/USERINFO=1 means the PI points for table “USERINFO” will be generated automatically by the interface.

/TRANINFO=x

Required

Default: none

The /TRANINFO is used to specify whether the interface will automatically create necessary PI points for table “TRANINFO” upon receiving the table data or not.

/TRANINFO=0 means the interface will not automatically create points for recording data from table “TRANINFO”. The values of the existing points will still be updated by the interface.

/TRANINFO=1 means the PI points for table “TRANINFO” will be generated automatically by the interface.

72


/STATINFO=x

Required

Default: none

The /STATINFO is used to specify whether the interface will automatically create necessary PI points for table “STATINFO” upon receiving the table data or not.

/STATINFO=0 means the interface will not automatically create points for recording data from table “STATINFO”. The values of the existing points will still be updated by the interface.

/STATINFO=1 means the PI points for table “STATINFO” will be generated automatically by the interface.

/APPLINFO=x

Required

Default: none

The /APPLINFO is used to specify whether the interface will automatically create necessary PI points for table “APPLINFO” upon receiving the table data or not.

/APPLINFO=0 means the interface will not automatically create points for recording data from table “APPLINFO”. The values of the existing points will still be updated by the interface.

/APPLINFO=1 means the PI points for table “APPLINFO” will be generated automatically by the interface.

/TIMEINFO=x

Required

Default: none

The /TIMEINFO is used to specify whether the interface will automatically create necessary PI points for table “TIMEINFO” upon receiving the table data or not.

/TIMEINFO=0 means the interface will not automatically create points for recording data from table “TIMEINFO”. The values of the existing points will still be updated by the interface.

/TIMEINFO=1 means the PI points for table “TIMEINFO” will be generated automatically by the interface.

/mandt=x

Optional

Default: extract data for all clients

The /mandt flag specifies a client number and the function module /OSI/MON_SYSTOPER_INFO call will retrieve SPOOLINFO, ADUMPINFO, and UPDV1INFO data for that specific client. /mandt=* means data for all clients will be returned. If no /mandt=x is specified, the default is also to extract data for all clients.




/retry=x,y,z

Optional

Default : do not retry

Usually if the interface fails to obtain the performance data from the SAP system due to SAP problems, network problems or other reasons, the point values for this scan are missed and the interface will wait until the next scan to retrieve the data. However, because some of the scan intervals for this interface can be long, such as 24 hours (daily), the /retry flag is provided to allow the interface to try multiple times to extract the data at one scan so that if it fails the first time, it does not have to wait until the next scan. /retry specifies the interval (x) in seconds between each retry, the maximum times (y) for retry, and the minimum scan period (z) in second that qualifies for retry. For example,

/retry=300,5,86400

means that the interface will try at most 5 times to extract data at one scan if it fails to retrieve data at the first time. The time interval between each attempt is 300 seconds and the interface will only do this for scan classes with scan time period greater than or equal to 86400 seconds. If the /retry is not present, the default setting for the interface is equivalent to /retry=300,5,86400.

When the interface is trying to retrieve data for one scan, the data updating for other scan classes can be delayed. Therefore, it is recommended to set the /retry parameters so that the interface will try multiple times only for scan classes with large time periods and the maximum times for allowed re-attempt should be limited.

/dbg

Optional

Default: no general debug messages logged

If /dbg flag is present in the command line, the interface is enabled to log the debugging messages. This option allows the interface to print general debugging messages about the interface running condition.

/ps=x

Required

Default: none

The /ps flag specifies the point source for the interface. X is not case sensitive and can be any single character. For example, /ps=S and /ps=s are equivalent.

The point source that is assigned with the /ps flag corresponds to the PointSource attribute of individual PI Points. The interface will attempt to load only those PI points with the appropriate point source.

/id=x

Required

Default: none

The /id flag is used to specify the interface identifier.

The interface identifier is a string that is no longer than 9 characters in length. UniInt concatenates this string to the header that is used to identify error messages as belonging to a particular interface. See the section called “Error and Informational Messages” for more information.

UniInt always uses the /id flag in the fashion described above. This interface also uses the /id flag to identify a particular interface copy number that corresponds to an integer value that is assigned to Location1. For this interface, one should use only numeric characters in the identifier. For example,

/id=1

74


/f=SSor/f=SS,SSor /f=HH:MM:SSor/f=HH:MM:SS,hh:mm:ss

Required for reading scan-based inputs

Default: none

The /f flag defines the time period between scans in terms of hours (HH), minutes (MM), and seconds (SS). The scans can be scheduled to occur at discrete moments in time with an optional time offset specified in terms of hours (hh), minutes (mm), and seconds (ss). If HH and MM are omitted, then the time period that is specified is assumed to be in seconds.

Each instance of the /f flag on the command line defines a scan class for the interface. There is no limit to the number of scan classes that can be defined. Because in the PI-ERP Performance Interface, each received table corresponds to one scan class. Therefore, it is required that you must specify 16 scan classes no matter the interface is set to record the data from all 16 tables or not. The first occurrence of the /f flag on the command line defines the first scan class of the interface, the second occurrence defines the second scan class, and so on. PI Points are associated with a particular scan class via the Location4 PI Point attribute. For example, all PI Points that have Location4 set to 1 will receive input values at the frequency defined by the first scan class. Similarly, all points that have Location4 set to 2 will receive input values at the frequency specified by the second scan class, and so on.

Two scan classes are defined in the following example:/f=00:01:00,00:00:05 /f=00:00:07or, equivalently:/f=60,5 /f=7The first scan class has a scanning frequency of 1 minute with an offset of 5 seconds, and the second scan class has a scanning frequency of 7 seconds. When an offset is specified, the scans occur at discrete moments in time according to the formula:

scan times = (reference time) + n(frequency) + offset

where n is an integer and the reference time is midnight on the day that the interface was started. In the above example, frequency is 60 seconds and offset is 5 seconds for the first scan class. This means that if the interface was started at 05:06:06, the first scan would be at 05:06:10, the second scan would be at 05:07:10, and so on. Since no offset is specified for the second scan class, the absolute scan times are undefined.

The definition of a scan class does not guarantee that the associated points will be scanned at the given frequency. If the interface is under a large load, then some scans may occur late or be skipped entirely. See the section called “Performance Point Configuration” for more information on skipped or missed scans.Wall Clock SchedulingScan classes that strictly adhere to wall clock scheduling are now possible. This feature is available for interfaces that run on Windows and/or UNIX. Previously, wall clock scheduling was possible, but not across daylight savings time. For example, /f=24:00:00,08:00:00 corresponds to 1 scan a day starting at 8 AM. However, after a Daylight Savings Time change, the scan would occur either at 7 AM or 9 AM, depending upon the direction of the time shift. To schedule a scan once a day at 8 AM (even across daylight savings time),



Parameter Descriptionone should use /f=24:00:00,00:08:00,L. The ,L at the end of the scan class tells UniInt to use the new wall clock scheduling algorithm.

/host=host:port

Optional, but highly recommended

Default: port and host on pilogin.ini or piclient.ini

The /host flag is used to specify the PI Home node. Host is the IP address of the PI Sever node or the domain name of the PI Server node. Port is the port number for TCP/IP communication. The port is always 5450 for a PI 3 Server and 545 for a PI 2 Server. It is recommended to explicitly define the host and port on the command line with the /host flag. Nevertheless, if either the host or port is not specified, the interface will attempt to use defaults.

Defaults:

The default port name and server name is specified in the pilogin.ini or piclient.ini file. The piclient.ini file is ignored if a pilogin.ini file is found. Refer to the PI-API manual for more information on the piclient.ini and pilogin.ini files.

Examples:The interface is running on a PI Interface Node, the domain name of the PI 3 home node is Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host flags would be:/host=marvin /host=marvin:5450 /host=206.79.198.30/host=206.79.198.30:5450

/stopstator/stopatat=digstate

Default:/stopstat=”Intf shut”

Optional

If the /stopstat flag is present on the startup command line, then the digital state Intf shut will be written to each PI Point when the interface is stopped.

If /stopstat=digstate is present on the command line, then the digital state, digstate, will be written to each PI Point when the interface is stopped. For a PI 3 Server, digstate must be in the system digital state table. For a PI 2 Server, where there is only one digital state table available, digstate must simply be somewhere in the table. UniInt uses the first occurrence in the table.

If neither /stopstat nor /stopstat=digstate is specified on the command line, then no digital states will be written when the interface is shut down.

Examples:/stopstat=”Intf shut”

The entire parameter is enclosed within double quotes when there is a space in digstate.

76


/ec=x

Optional

Default: 1

The first instance of the /ec flag on the command line is used to specify a counter number, x, for an I/O Rate point. If x is not specified, then the default event counter is 1. Also, if the /ec flag is not specified at all, there is still a default event counter of 1 associated with the interface. If there is an I/O Rate point that is associated with an event counter of 1, each copy of the interface that is running without /ec=x explicitly defined will write to the same I/O Rate point. This means that one should either explicitly define an event counter other than 1 for each copy of the interface or one should not associate any I/O Rate points with event counter 1. Configuration of I/O Rate points is discussed in the section called “I/O Rate Tag Configuration.”

/q

Optional

Default: do not queue

When the /q flag is present, Snapshots and exceptions are queued before they are sent to the PI Server node.

The maximum queue size is close to 4000 bytes. The queue is flushed between scans if it is not filled.

Sample PIERPperf.bat FileThe following is an example file:rem Sample startup command file for the PIERPperf Interfaceremrem Required Parametersrem /SAPlogonfile=x File that contains SAP logon informationrem /SAPhost=x Host name of target SAP systemrem /SYSTEM_LIST=# SYSTEM_LIST tablerem /KERNEL_INFO=# KERNEL_INFO tablerem /VERSION_INFO=# VERSION_INFO tablerem /OS_M0NITOR=# OS_MONITOR tablerem /VERSION_COMP=# VERSION_COMP tablerem /BUFFER_STAT=# BUFFER_STAT tablerem /SPOOLINFO=# SPOOLINFO tablerem /ADUMPINFO=# ADUMPINFO tablerem /UPDV1INFO=# UPDV1INFO tablerem /SYSLGINFO=# SYSLGINFO tablerem /RESPINFO=# RESPINFO tablerem /USERINFO=# USERINFO tablerem /TRANINFO=# TRANINFO tablerem /STATINFO=# STATINFO tablerem /APPLINFO=# APPLINFO tablerem /TIMEINFO=# TIMEINFO tablerem /ps=c Point source characterrem /id=# Interface identifcation numberrem /f=x Scan frequency – 16 requiredremrem Recommended Parametersrem /sysnr=# System # of target SAP R/3 system



rem /gwhost=x Host name of the SAP gatewayrem /gwservice=x Gateway service of the SAP systemrem /SAPtrace=# SAP trace levelrem /tag_prefix=x Prefix for tag namesrem /mandt=x Client number for /OSI/MON_SYSTOPER_INFOrem /retry=#,#,# Retry parameters when a scan failsrem /dbg Debug messagesrem /host=<hostname>:port# Name & port of PIrem /stopstat=”Intf Shut” Intf Shut to pts at Intf shutdownremrem Sample command line.\PIERPperf.exe /ps=S /id=1 /host=pimachine:5450 ^

/stopstat=“Intf Shut” ^/SAPlogonfile=“C:\PIPC\Interfaces\ERPperf\pisaplogon.pas” ^ /SAPhost=sapmachine /tag_prefix=SAP_ ^ /SYSTEM_LIST=1 /f=24:00:00,00:05:00,L ^/KERNEL_INFO=1 /f=24:00:00,00:06:00,L ^/VERSION_INFO=1 /f=24:00:00,00:07:00,L ^/OS_MONITOR=1 /f=00:05:00,00:08:00,L ^/VERSION_COMP=1 /f=24:00:00,00:09:00,L ^/BUFFER_STAT=1 /f=00:05:00,00:10:00,L ^/SPOOLINFO=1 /f=24:00:00,00:11:00,L ^/ADUMPINFO=1 /f=24:00:00,00:12:00,L ^/UPDV1INFO=1 /f=24:00:00,00:13:00,L ^/SYSLGINFO=1 /f=24:00:00,00:14:00,L ^/RESPINFO=1 /f=01:00:00,00:02:00,L ^/USERINFO=1 /f=01:00:00,00:03:00,L ^/TRANINFO=1 /f=01:00:00,00:04:00,L ^/STATINFO=1 /f=24:00:00,00:16:00,L ^/APPLINFO=1 /f=24:00:00,00:26:00,L ^ /TIMEINFO=1 /f=24:00:00,00:27:00,L

The above command line tells the Interface to:

Service PI points whose PointSource is S and Location1 is 1.

Send values to the PI Server named pimachine.

Write Intf Shut to its list of points upon exit.

Connect to the SAP server named sapmachine. The SAP logon information for opening an RFC connection is stored in file pisaplogon.pas that is located in C:\Program Files\PIPC\Interfaces\ERPperf directory. Also as default, the system number of the target SAP system is set to 0, the host name of the SAP gateway is assumed to be the same as the SAP server name sapmachine, the gateway service is sapgw00, and the SAP trace level is 0 (turned off).

Create points and record data for all 16 tables. The tag names for all points created by the interface will start with prefix “SAP_”.

78

Note that the time offset for the scan classes is specified so that the time interval between scan class 14 and 15 is quite long. That is because table STATINFO, which corresponds to scan class 14, usually contains a large amount of data and needs a longer time to retrieve and process. It may take an even longer time to retrieve table STATINFO in an SAP system depending on the size of the system and the number of users. Run function module /OSI/MON_RESPONSE_TIME via SAP Front End to estimate the time needed for retrieving this table.


Interface Node ClockThe correct settings for the time and time zone should be set in the Date/Time control panel. If local time participates in Daylight Savings, from the control panel, configure the time to be automatically adjusted for Daylight Savings Time. The correct local settings should be used even if the interface node runs in a different time zone than the PI Server node.

Make sure that the TZ environment variable is not defined. The currently defined environment variables can be listed by going to Start | Settings | Control Panel, double clicking on the system icon, and selecting the environment tab on the resulting dialog box. Also, make sure that the TZ variable is not defined in an autoexec.bat file. When the TZ variable is defined in an autoexec.bat file, the TZ variable may not appear as being defined in the System control panel even though the variable is defined. Admittedly, autoexec.bat files are not typically used on Windows, but this does not prevent a rogue user from creating such a file and defining the TZ variable unbeknownst to the System Administrator.


SecurityIf the home node is a PI 3 Server, the PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Data Archive. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Server manuals.Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy Database used prior to PI version 3.3. The Trust Database maintains all the functionality of the proxy mechanism while being more secure.See “Trust Login Security” in the chapter “PI System Management” of the PI Universal Data Server System Management Guide.

If the interface cannot write data to a PI 3 Server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Serve, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.


Starting / Stopping the InterfaceThis section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.

Starting Interface as a ServiceIf the interface was installed a service, it can be started from PI-ICU, the services control panel or with the command:PIERPperf.exe –start

To start the interface service with PI-ICU, use the button on the PI-ICU toolbar.

A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. One is that the service may not be able to find the command-line arguments in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See the section “Appendix A: Error and Informational Messages,” for additional information.

Stopping Interface Running as a ServiceIf the interface was installed a service, it can be stopped at any time from PI-ICU, the services control panel or with the command:PIERPperf.exe –stopThe service can be removed by:PIERPperf.exe –remove

To stop the interface service with PI-ICU, use the button on the PI-ICU toolbar


BufferingPI Interface Node buffering consists of a buffering process which runs continuously on the local node, a PI-API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.

Note: Change the Local Security Policy on Windows XP. 1. Open “Administrative Tools” from the control panel. 2. Open “Local Security Policy” from administrative tools. 3. Browse to “Security Options” under “Local Policies.” 4. Double click on “System Objects: Default owner for objects created by members of the Administrators group.” 5. Change the dropdown from “Object Creator” to “Administrators group.”

The behavior of Bufserv should now be the same on XP as it was for Window NT4 and 2000.

Configuring Buffering with PI-ICU (NT-Intel)Buffering is enabled through the PI-Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI-API will not buffer data, sending data directly to the home node.

The API Buffering… dialog allows the user to view and configure the parameters associated with the API Buffering (bufserv) process. The user can start and stop the API Buffering process from the Service tab:

Service TabThe Service tab allows for some API Buffering service configuration. For further configuration changes, use the Services applet.


Service NameThe Service name displays the name of the API Buffering Service.

Display NameThe Display name displays the full name associated with the API Buffering service.

Log On AsLog on as indicates the Windows user account under which the API Buffering service is setup to start automatically on reboot, or manually.

PasswordPassword is the name of the password for the Windows user account entered in the Log on as:above.

Confirm passwordYou must reenter the password again to verify you have typed it correctly both times.

DependenciesThe Dependencies lists the Windows services on which the API Buffering service is dependent.

Dependent ServicesThe Dependent services area lists the Windows services that depend on bufserv to function correctly.

Start / Stop ServiceThe Start / Stop buttons allow for the API Buffering service to be started and stopped. If the service is not created, this box will show Not Installed.

After a change is made to any of the settings on the Settings tab, the OK button must be clicked to save these settings, and then the service must be stopped and restarted for the changes to be picked up by bufserv.

Service Startup TypeThe Startup Type indicates whether the API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.

If the Auto option is selected, the service will be installed to start automatically when the machine reboots.

If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.

If the Disabled option is selected, the service will not start at all.

Generally, the API Buffering service is set to start automatically.

Create/Remove ServiceThe Create / Remove buttons allow for the creation or removal of the API Buffering service. Clicking the Create button will cause the service to be created using the Log on


as and passwords given. Once the service is created the Start / Stop buttons will be activated.

Settings TabThe Settings tab allows for configuration of the 7 configurable settings used by API Buffering. Default values are used if no other value is provided.

Enable API BufferingEnables the API Buffering feature.

Maximum File SizeMaximum buffer file size in kilobytes before buffering fails and discards events. Default value is 100,000. Range is 1 to 2,000,000.

The Use Default button places the default value into the text box. To keep this value, click the Apply button.

Send RateSend rate is the time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds). Default value is 100. Range is 0 to 2,000,000.


Primary Memory Buffer SizePrimary memory buffer size is the size in bytes of the Primary memory buffer. Default value is 32768. Range is 64 to 2,000,000.



Buffering

Secondary Memory Buffer SizeSecondary memory buffer size is the size in bytes of the Secondary memory buffer. Default value is 32768. Range is 64 to 2,000,000.


Max Transfer ObjectsMax transfer objects is the maximum number of events to send between each SENDRATE pause. Default value is 500. Range is 1 to 2,000,000.


Pause RateWhen buffers are empty the buffering process will wait for this number of seconds before attempting to send more data to the home node. Default value is 2. Range is 0 to 2,000,000.


Retry RateWhen the buffering process discovers the home node is unavailable it will wait this number of seconds before attempting to reconnect. Default value is 120. Range is 0 to 2,000,000.


Max Theoretical Send RateThis is the theoretical max send rate which is calculated like this:max = MAXTRANSFEROBJS / SENDRATE * 1000Default value is 5000. This value is automatically calculated for the user and can not be changed.

There are no additional steps needed to install buffering after installing the PI-API. The delivered PI-API library supports both buffered and un-buffered calls.

Configuring Buffering ManuallyBuffering is enabled through the use of a configuration file, piclient.ini. Unless this file is modified to explicitly enable buffering, the PI-API will not buffer data, sending data directly to the home node.

There are no additional steps needed to install buffering after installing the PI-API. The delivered PI-API library supports both buffered and un-buffered calls.

Note: When buffering is configured to be on, the bufserv process must be started before other programs using the PI-API, so that these programs can access the shared buffering resources. Any program that makes a connection to a PI Server has this requirement even if it does not write to PI.

90

Configuration of buffering is achieved through entries in the piclient.ini file. The file is found in the dat subdirectory of the PIHOME directory (typically c:\pipc\dat) under Windows. This file follows the conventions of Microsoft Windows initialization files with sections, keywords within sections, and values for keywords. All buffering settings are entered in a section called [APIBUFFER]. To modify settings, simply edit the piclient.ini file in a text editor (Notepad on Windows) to the desired values.

The following settings are available for buffering configuration:

Keywords Values Default Description

BUFFERING 0,1 0 Turn off/on buffering. OFF = 0, ON = 1,

PAUSERATE 0 – 2,000,000 2 When buffers are empty the buffering process will wait for this long before attempting to send more data to the home node (seconds)

RETRYRATE 0 – 2,000,000 120 When the buffering process discovers the home node is unavailable it will wait this long before attempting to reconnect (seconds)

MAXFILESIZE 1 – 2,000,000 100,000 Maximum buffer file size before buffering fails and discards events. (Kbytes)

MAXTRANSFEROBJS

1 – 2,000,000 500 Maximum number of events to send between each SENDRATE pause.

BUF1SIZE 64 – 2,000,000

32768 Primary memory buffer size. (bytes)

BUF2SIZE 64 – 2,000,000

32768 Secondary memory buffer size. (bytes)

SENDRATE 0 – 2,000,000 100 The time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds)

In addition to the [APIBUFFER] section, the [PISERVER] section may be used to define the default PI server and an optional time offset change that may occur between the client and server.

Keywords Values Default Description

PIHOMENODE string none Windows default server is in pilogin.ini

DSTMISMATCH 0 – 2,000,000 0 The time that the server and client local time offset is allowed to jump. Typically, 3600 if the nodes are in time zones whose DST rules differ (seconds)


Buffering

Example piclient.ini FileOn Windows the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds meaning wait 10 minutes after losing a connection before retrying.

On Windows a piclient.ini file might look like:[APIBUFFER]BUFFERING=1MAXFILESIZE=100000; The PI-API connection routines have a 1 minute default timeout.RETRYRATE=600

92

Appendix A:Error and Informational Messages

A string PI-ERPperf ID is pre-pended to error messages written to the message log. ID is a configurable identifier that is no longer than 9 characters and is specified using the /id flag on the startup command line.

Message LogsThe location of the message log depends upon the platform on which the interface is running. See the UniInt End User Document for more information.

Messages are written to PIHOME\dat\pipc.log at the following times.

When the interface starts many informational messages are written to the log. These include the version of the interface, the version of UniInt, the command-line parameters used, and the number of points.

As the interface retrieves points, messages are sent to the log if there are any problems with the configuration of the points.

If the /dbg is used on the command line, then various informational messages are written to the log file.

Messages

Interface Startup ErrorIf the interface immediately exits upon startup, the most likely cause is that required command line parameters are not specified. PI-ERP Performance Interface requires the following command line parameters:

/ps= (point source character)

/id= (interface identifaction number)

/f= (scan frequency)

/rfc_dest= (client number for RFC conncetion to SAP system)

/user= (user for RFC connection to SAP system)

/pwd= (password for RFC connection to SAP system)

/SAPhost= (host name of the target SAP system)

/SYSTEM_LIST= (flag for SYSTEM_LIST table)

/KERNEL_INFO= (flag for KERNEL_INFO table)

/VERSION_INFO= (flag for VERSION_INFO table)

/OS_M0NITOR= (flag for OS_MONITOR table)

/VERSION_COMP= (flag for VERSION_COMP table)


/BUFFER_STAT= (flag for BUFFER_STAT table)

/SPOOLINFO= (flag for SPOOLINFO table)

/ADUMPINFO= (flag for ADUMPINFO table)

/UPDV1INFO= (flag for UPDV1INFO table)

/SYSLGINFO= (flag for SYSLGINFO table)

/RESPINFO= (flag for RESPINFO table)

/USERINFO= (flag for USERINFO table)

/TRANINFO= (flag for TRANINFO table)

/STATINFO= (flag for STATINFO table)

/APPLINFO= (flag for APPLINFO table)

/TIMEINFO= (flag for TIMEINFO table)

If you omit either of these parameters, the interface exits.

There are other reasons for the interface exiting upon startup. For example, the following messages may be found in the log file: Interface id (-2) must be a positive integer

Another command line parameter required by this interface is /f= (scan frequency)

and the interface requires that 16 scan classes must be specified in the command line parameter. If less than 16 scan frequencies are specified in the interface startup file, the interface will exit with the message such as: fatal> Only 8 scan classes defined in the command line. You

must specify 16 scan classes

Point Loading ErrorsEach PI point for the PI-ERP Performance Interface is defined for recording specific values from a particular table obtained via one of the three RFC function module. Therefore, the InstrumentTag attribute is used to specify the function module(FM), the table name(TBL), the key field(KEY1, KEY2, …), and the value to obtain(VALUE). See the “Interface-Specific Point Configuration” section for the detailed descriptions about InstrumentTag setting for each point. If the InstrumentTag attribute of a point does not contain correct settings for these parameters, the interface will write error messages to the log file.

For example, if the function module (FM=) is not specified in InstrumentTag, you will find the error message such as: Tag sapmachine_PRD_00_Availability(1320) refused: RFC

function module (FM= ) is not specified in InstrumentTag

This interface uses three function modules: /OSI/MON_SERVER_INFO, /OSI/MON_SYSTOPER_INFO, /OSI/MON_RESPONSE_TIME. If a function module other than these three is specified in InstrumentTag, the following message will be logged:


Tag sapmachine_PRD_00_Availability(1320) refused: [FM=SERVER_INFO] is invalid

If the table (TBL=) is not specified in InstrumentTag, you will find the error message such as: Tag sapmachine_PRD_00_Availability(1320) refused: RFC table

(TBL= ) is not specified in InstrumentTag

PI-ERP Performance Interface retrieves data for 16 SAP tables. If an incorrect table name is used for table specification in InstrumentTag, the following message will be logged: Tag sapmachine_PRD_00_Availability(1320) refused:

[TBL=TABLE_NAME] is invalid

Each point of this interface must have valid KEY fields following the rules described in “Interface-Specific Point Configuration”. If the KEY field specification in InstrumentTag is not correct, the following message will be logged: Tag sapmachine_PRD_00_ Kernel_Info(1317) refused: the KEY

fields specification in InstrumentTag is invalid

If the value code (VALUE=) is not specified in InstrumentTag, you will find the error message such as: Tag sapmachine_PRD_00_ Kernel_Info(1317) refused: VALUE= is

not specified in InstrumentTag

“Interface-Specific Point Configuration” section has detailed specification about the value code for each point. If the value code specification in InstrumentTag is not correct, the following message will be logged Tag sapmachine_PRD_00_ Kernel_Info(1317) refused:

[VALUE=version] is invalid

The PI-ERP Performance Interface can retrieve up to 16 tables of SAP performance data and it uses 16 different scan classes for each table. Therefore, each table must correspond to the scan class defined by the interface and PI points for each table must have Location4 equal to this scan class number. If the Location4 attribute of a point does not match the scan class defined by the interface, the point is rejected. Refer to the section “Point Configuration” for the definition of Location4(i.e., scan class) for each table. Tag sapmachine_PRD_00_ Kernel_Info(1317) refused:

TBL=KERNEL_INFO; this means Location4 must be 2

RFC Error MessageErrors may occur when the RFC function modules are called. The interface prints detailed error messages including the name of the function module that caused the error, the error code, the state of the RFC connection, the text message describing the error, and the internal description of the RFC connection.

For example, if the message log file contains entries such as:RFC error: RfcOpen

key: RFC_IO5


Appendix A: Error and Informational Messages

status: CODE=CM_PRODUCT_SPECIFIC_ERROR STATUS=??? DATA=??? ID=???

Message: connection closed

internal status: IO HANDLE=3 DRV=EXT LINE=425 CODE=5

These messages mean that an RFC error has happened when calling the function RfcOpen due to the lost connection to the SAP system.

Note: Whenever an RFC error occurs while an RFC function module is called, the first step to do for trouble-shooting is to test the RFC function module via SAP Front End. Refer to “Test Function Modules in SAP Front End” for the detailed steps about how to run the test using SAP Front End.

System Errors and PI ErrorsSystem errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers.

On Windows, descriptions of system and PI errors can be obtained with the pidiag utility:

\PI\adm\pidiag –e error_number

96

Appendix B:RFC and BAPI Descriptions

IntroductionThe purpose of the customized BAPI or RFC function modules provided by OSIsoft SAP Add-on packages is to enable external systems to gather SAP systems data such as system log, buffer statistics, workload statistics, and database from any database system or operating system environment.

It is a part of OSIsoft ERP Performance Interface for SAP Solutions to the PI System. The BAPI or RFC function modules provided are for use by the OSIsoft ERP Performance Interface for SAP Solutions to the PI System only.

This interface refers to the following SAP transactions that are provided through BAPIs or the RFC-enabled function modules:

No.

SAP Transaction Remarks

1. SM51 - List of SAP Systems Lists all SAP systems.2. OS06 - Local Operating System Activity Serves as the Operating System monitoring

tool. If more than one server available, make sure all data are extracted for the servers. Refer to OS07.

3. OS07 - Remote Operating System Activity

Monitors remote servers.

4. SM13 - Display Update Records Displays update records.5. SM21 - Online System Log Analysis System Log for the period entered.6. SM35 - Batch Input Monitoring Batch Input Session overview and monitoring.7. SP01 - Output Controller Spool results.8. ST02 - Setups/Tune Buffers Tune Summary Analysis.9. ST03 - Performance, Statistics,

WorkloadWorkload Analysis.

10. ST04 - DB Performance Monitor Database Performance Analysis – link to ST03.11. ST07 - Application monitor Application monitoring – User distribution12. ST22 - ABAP dump analysis Dump analysis.

These transactions can apply to different types of data. This appendix provides examples for retrieving data from the SAP system.

The prerequisite for this interface is a fully functional SAP system. The SAP system should include the above transactions, a running saposcol service, and the hourly scheduled performance collector job, COLLECTOR_FOR_PERFORMANE_MONITOR.

* There may be more than one BAPI or RFC-enabled function module required to meet the above data requirement. One objective of the design of the BAPI or RFC-enabled function module is to limit the total number of modules needed by grouping the relevant data as much as possible.

Note


Mode of interaction: BAPI or RFC-enabled Function Modules

Frequency: Online or on interval basis (to be determined)

External Function ModulesThere are three main modules that provide the interface functionality. They are:

/OSI/MON_SERVER_INFO - get SAP server information

/OSI/MON_SYSTOPER_INFO - get SAP system operating information

/OSI/MON_RESPONSE_TIME- get Performance data response information

These objects can be used with all SAP releases regardless of the underlying database management system. They work with all databases supported by SAP.

These modules are RFC enabled. External applications can access the data through the interfaces.

This appendix describes the technical details of each of the function modules.

Note

There are two other function modules that support the multiple application server scenarios:

/OSI/MON_GET_APPLINFO - RFC to get remote application information

/OSI/MON_GET_SYSTLOG - RFC to get system log information

These function modules are called internally in the main function module, they are cannot be called explicitly by an external program.

The technical details of these function modules are described in this appendix as well.

Function Module ‘/OSI/MON_SERVER_INFO’Description

The purpose of this function is to allow a user to extract all the important server information such as kernel data, database data, version data, and operating system data.

The data provided by this function module fulfills the EWA (Early Watch Report) section 1.0 and 5.0 standards.

FunctionalityYou can use this function module to output the following system data:

System list structure

Kernel information

SAP versions information

Local/OS monitor information

Database releases information

Operating systems information

Application software patch level information

Release status of software component


Support pack information

Buffer statistic information

The tables in this section provide details of these data structures.

The above data can be seen in various SAP transactions, for example, SM51, OS06, ST02, and Systems -> Status.

Technical Attributes

Function Module : /OSI/MON_SERVER_INFO

Short Text : Get Server and Buffer Statistic Information

Function Group : /OSI/MON

Development Class : /OSI/MON

Main Program : /OSI/SAPLMONI

Include Program : /OSI/LMONU01

Frequency : Online

Processing Type : Remote-Enabled Module (RFC Enabled)

Import Parameters : 1. SYSTEM Default ‘’2. KERNEL Default ‘’3. VERSION Default ‘’4. OS Default ‘’5. RELEASE Default ‘’6. BUFFER Default ‘’

Export Parameters : NoneChanging : None

Tables : 1. SYSTEM_LIST STRUCTURE /OSI/MONSERV0

2. KERNEL_INFO STRUCTURE /OSI/MONSERV1

3. VERSION_INFO STRUCTURE /OSI/MONSERV2

4. OS_MONITOR STRUCTURE /OSI/MONSERV3

5. VERSION_COMP STRUCTURE /OSI/MONSERV4

6. BUFFER_STAT STRUCTURE /OSI/MONSERV5

Exceptions : NOTHING_SPECIFIED

Import Parameters

No. Field Type Length Description1. SYSTEM CHAR 1 Enter an ‘X’ if System List information is needed.2. KERNEL CHAR 1 Enter an ‘X’ if Kernel Information is needed.3. VERSION CHAR 1 Enter an ‘X’ if Version Information is needed.4. OS CHAR 1 Enter an ‘X’ if Operating System Information is

needed.5. RELEASE CHAR 1 Enter an ‘X’ if Release Information is needed.6. BUFFER CHAR 1 Enter an ‘X’ if Buffer Information is needed.


Appendix B: RFC and BAPI Descriptions

Exception

No.

Exception Description

1. NOTHING_SPECIFIED

This exception occurs when there is no option chosen or when there is an error that is not specified in the error list.

Table structure

1. Server List Information

Export Table Name : SYSTEM_LIST

Refer Structure : /OSI/MONSERV0

Table Information : This table lists all the SAP servers in a particular SAP installation instance. The corresponding transaction in SAP is SM51.

Frequency of Access : Daily. At the End Of The Day.

Pre-condition : To get this information, mark ‘X’ on the Import Parameter SYSTEM.

SAP Transaction(s) : SM51

Table Structure

No. Field Type Length Description1. NAME CHAR 20 Server name. This name is usually made up of the

computer name, DB name and system number.2. HOST CHAR 20 Host. Name of the computer on which the server runs.3. SERV CHAR 20 Service.4. MSGTYPES RAW 1 Message types.5. HOSTADR RAW 4 Host IP address.6. SERVNO RAW 2 Service port number.

Note

This table has multiple entries if more than one application server is installed.

2. Kernel release Information

Export Table Name : KERNEL_INFO


Table Information : This table lists information about the kernel.

Frequency of Access : Daily. At the end of the day.

Pre-condition : To get this information, mark ‘X’ on the Import Parameter KERNEL.

SAP Transaction(s) : SM51 -> Release Information

Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application Server name2. KERN_REL CHAR 80 Kernel release

100

No. Field Type Length Description3. KERN_DBLIB CHAR 80 Kernel DB library4. KERN_COMP_ON CHAR 80 Kernel compare on5. KERN_COMP_TIME CHAR 80 Kernel compare time6. KERN_PATCHLEVEL CHAR 80 Kernel patch level7. KERN_SUPPORTLEVEL CHAR 80 Kernel support level8. KERN_SOURCEID CHAR 80 Kernel source id9. COMPUTERNAME CHAR 30 Computer name10. DBMSTYPE CHAR 20 DBMS type11. MYNAME CHAR 20 My server name12. NUMPROCESSOR CHAR 10 Number of processor13. OS CHAR 30 Operating System14. PPID CHAR 10 PPID15. PRARCHITECH CHAR 10 Processor architecture16. PRIDENT CHAR 50 Processor identification17. PRILEVEL CHAR 10 Processor level18. PRREVISION CHAR 20 Processor revision19. SAPLOCALHOST CHAR 30 SAP local host20. MEMORY INT4 10 Memory in MB21. LICENSE CHAR 10 Installation/License number

Note

In multiple application server environments, this table returns kernel release information for each application server.

3. Systems, Application, and Database Version Information

Export Table Name : VERSION_INFO


Table Information : This table lists the operating system, SAP application version, and database information.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter VERSION.

SAP Transaction(s) :1. Menu path: System -> Status2. SM51 -> Release Information

Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. SAPVERSION CHAR 80 SAP version3. OPERATINGSYST CHAR 80 Operating system4. MACHINETYPE CHAR 80 Machine type5. NODENAME CHAR 80 Node name6. SAPSYSTEMID CHAR 80 System identification7. DATABASESYST CHAR 80 Database system8. DATABASENAME CHAR 80 Database name9. DATABASEHOST CHAR 80 Database host



10. DATABASEOWNR CHAR 80 Database owner11. IPADDRESS CHAR 80 IP address12. KERNELREL CHAR 80 Kernel releases13. DATABASELIB CHAR 80 Database library14. KERNELCOMP CHAR 80 Kernel compilation15. KERNELLEVL CHAR 80 Kernel level16. SUPPORTVER CHAR 80 Support level17. SUPPORTDBMS CHAR 80 Support DBMS18. VALIDOPSYST CHAR 80 Valid operating system19. OPSYSTREL CHAR 80 Operating system release20. ABAPLOADVER CHAR 80 ABAP load version21. CUALOADVER CHAR 80 CUA load version22. KERNELKIND CHAR 80 Kernel kind

Note

In multiple application server environments, this table returns information for each application server.

4. Operating System/Hardware overview

Export Table Name : OS_MONITOR


Table Information :This table lists operating system information such as total physical memory, used memory, and total users for each category.

Frequency of Access : Periodically. Every 5 minutes.

Pre-condition : To get this information, mark ‘X’ on the Import Parameter OS.

SAP Transaction(s) : OS06

Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. TYPE INT2 5 Type in saposcol result structure3. NBR_CPU INT4 10 Total number of CPU4. USR_TOTAL INT4 10 Total percentage of CPU for user processes (SAP)5. SYS_TOTAL INT4 10 Total number of system6. IDLE_TOTAL INT4 10 Total percentage of idling CPU7. FREE_MEM INT4 10 Total free memory in Kbytes.8. PHYS_MEM INT4 10 Total physical memory in Kbytes.

Note

In multiple application server environments, this table returns operating system information for each application server.

Get this information every 5 minutes in order to monitor the trend of the system utilization rate over a period of time and subsequently determine the optimum resource allocation.

5. Release Status of Software Components in System

102

Export Table Name : VERSION_COMP


Table Information : This table lists release and patch information for the application component in the SAP system.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter RELEASE.

SAP Transaction(s) : Menu path: System -> Status

Table Structure

No. Field Type Length Description1. COMPONENT CHAR 30 Software component2. RELEASE CHAR 10 SAP R/3 release3. EXTRELEASE CHAR 10 Support Package level of a software

component4. COMP_TYPE CHAR 1 Value component Type

Note

The application component release and patch information remains the same even if there is more than one application server.

6. Buffer Statistical information

Export Table Name : BUFFER_STAT


Table Information : This table returns a snapshot of buffer statistics at the point the function is executed.

Frequency of Access : Periodically. Every 5 minutes

Pre-condition : To get this information, mark ‘X’ on the Import Parameter BUFFER.

SAP Transaction(s) : ST02

Table Structure

No.


1. SERVERNAME CHAR 20 Application server name2. NAME CHAR 5 Area name3. AREA_NAME CHAR 40 Area name description4. STARTUP_DATE DATS 8 Last System Startup Date5. STARTUP_TIME TIMS 6 Last System Startup Time6. ANALYSIS_DATE DATS 8 Analysis Date (Snapshot Date)7. ANALYSIS_TIME TIMS 6 Analysis Time (Snapshot Time)8. HITRATIO DEC 7 Hit rate SAP buffer percentage9. ALLOC_SIZE INT4 10 Allocated space in Kbytes10. FREE_SIZE INT4 10 Available space in Kbytes11. FREE_SIZE_PECT DEC 7 Free/Available in percentage12. MAX_OBJCTS INT4 10 Number of entries in the namespace.13. FREE_DIR INT4 10 Number of available entries in the



namespace.14. FREE_DIR_PECT DEC 7 Free/Available Space Percentage15. SWAPS INT4 10 No. of objects swapped16. DB_ACCESS INT4 10 No. of database accesses

Note

In multiple application server environments, this table returns buffer information for each application server.

The hit ratio in the buffer statistic is calculated based on the overall average from the start of the system (STARTUP DATE AND TIME) until the most current snapshot time (executed time).

Function Module ‘/OSI/MON_SYSTOPER_INFO’Description

The purpose of this function is to allow a user to extract daily, weekly, or monthly system operation information such as number of spools, ABAP dump analysis, batch input, and system log information.


FunctionalityYou can use this function module to output the following system operating data:

Spool information

ABAP Dump Analysis

Update V1 and V2 information

System Log information


The above data can be seen in SAP transactions SP01, ST22, SM35, SM13, and SM21.


Function Module : /OSI/MON_SYSTOPER_INFO

Short Text : Get System Operation information





Frequency : Online


Import Parameters : 1. MANDT Default ‘*’2. SPOOL Default ‘’3. DUMP Default ‘’4. UPD_V1 Default ‘’5. SYSLOG Default ‘’

104

6. FROMDATE Default SY-DATUM7. FROMTIME Default ‘000000’8. TODATE Default SY-DATUM9. TOTIME Default ‘235959’

Export Parameters : 1. NRSPOOL2. ERSPOOL3. NPSPOOL4. NRUPDV15. NRSYSLG

Changing : None

Tables : 1. SPOOLINFO STRUCTURE /OSI/MONSYST0

2. ADUMPINFO STRUCTURE /OSI/MONSYST1

3. UPDV1INFO STRUCTURE /OSI/MONSYST3

4. SYSLGINFO STRUCTURE /OSI/MONSYST4


Import Parameters

No.


1. MANDT CHAR 3 Determine the client data to be retrieved.2. SPOOL CHAR 1 Enter an ‘X’ if Spool information is needed.3. DUMP CHAR 1 Enter an ‘X’ if ABAP Dump info is needed.4. UPD_V1 CHAR 1 Enter an ‘X’ if Update information is needed.5. SYSLOG CHAR 1 Enter an ‘X’ if system log info is needed.6. FROMDATE DATS 8 Enter the Start date of the data to be accessed.7. FROMTIME TIMS 6 Enter the Start time of the data to be accessed.8. TODATE DATS 8 Enter the End date of the data to be accessed.9. TOTIME TIMS 6 Enter the End time of the data to be accessed.

Export Parameters

No. Field Type Length Description1. NRSPOOL INT4 10 Total number of Spool jobs.2. ERSPOOL INT4 10 Total number of Erroneous Spool job.3. NPSPOOL INT4 10 Total number of Not printed Spool job.4. NRUPDV1 INT4 10 Total number of Update Request.5. NRSYLOG INT4 10 Total number of System Logs.

Exception

No. Exception Description1. NOTHING_SPECIFIED This exception occurs when there is no option chosen or when

there is an error that is not specified in the error list.



Table Structure

1. Spool Request Information

Export Table Name : SPOOLINFO

Refer Structure : /OSI/MONSYST0

Table Information :

This table returns information about spool requests that occur within a specific timeframe. This module returns the total number of spool requests, including non-printed and erroneous spool requests.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter SPOOL.

SAP Transaction(s) : SP01

Table Structure

No. Field Type Length Description1. RQIDENT CHAR 10 Spool number2. RQCLIENT CLNT 3 Client for which object was generated3. RQ0NAME CHAR 6 Spool request: Name4. RQ1NAME CHAR 4 Spool request: Suffix 15. RQ2NAME CHAR 12 Spool request: Suffix 26. RQOWNER CHAR 12 User name7. RQCMODE CHAR 1 External mode of an SAP dialog8. RQFINAL CHAR 1 Spool request completed9. RQCRETIME CHAR 16 Time a spool request was created10. RQDELTIME CHAR 16 Time spool request was deleted11. RQDEST CHAR 4 Spool: Output device12. RQPJREQ INT2 5 Total Spool request13. RQPJDONE INT2 5 Number of output requests processed14. RQPJSERR INT2 5 Total erroneous Spool requests15. RQPJHERR INT2 5 Total not processed Spool requests

Note

This table may contain spool requests from multiple clients if there is more than one client in the SAP system. The spool information is centrally stored in the database, so the information in this table is the same even if there is more than one application server in the system.

2. ABAP Dump Analysis

Export Table Name : ADUMPINFO


Table Information : This table returns information about ABAP dumps that occur within a specific client within a specific timeframe.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter DUMP.

SAP Transaction(s) : ST22

106

Table Structure

No. Field Type Length Description1. DATUM DATS 8 Date of the ABAP dump2. UZEIT TIMS 6 Time of the ABAP dump3. AHOST CHAR 32 Name of application server4. UNAME CHAR 12 User name5. MANDT CLNT 3 Client name6. MODNO CHAR 1 External mode index7. SEQNO CHAR 3 Sequence number8. XHOLD CHAR 1 ‘X’ if ABAP dump to be hold9. ERRID CHAR 30 Error id of an ABAP dump10. FLIST CHAR 200 Long text of the error

Note

This table contains only header information, not the details of the ABAP dump data. This optimizes storage.

3. Terminated/Failed Update Request Information

Export Table Name : UPDV1INFO


Table Information : This table lists update requests that terminated within the execution period.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter UPD_V1.


Table Structure

No. Field Type Length Description1. VBKEY CHAR 32 Update and enqueue/dequeue2. VBMANDT CLNT 3 Client for update request3. VBUSR CHAR 12 User name in update request4. VBACCNT CHAR 12 Update accounting5. VBREPORT CHAR 40 Program that generated the update 6. VBTCODE CHAR 20 Transaction created the update request7. VBENQKEY CHAR 58 Enqueue key8. VBNAME CHAR 64 Name of the executing VB server9. VBCONTEXT CHAR 20 Update context (Code-page, DB node,)10. VBSTATE INT1 3 Global status of an update request11. VBCLIINFO INT1 3 Info on update client12. VBDATE CHAR 14 Date and time of update record13. VBTRANSID CHAR 32 Transaction ID14. VBETRANSID CHAR 32 Transaction ID15. VBETRANSLN INT4 10 Length of external transaction ID16. VBMODCNT INT4 10 Update module ID17. VBFUNC CHAR 30 Update function module



18. VBMODE CHAR 1 Execution mode of an update module19. VBRC INT4 10 Update return code

Note

This table includes only terminated or failed update requests. This information allows the system administrator to inform the respective module lead or users about the failed update and to re-process if necessary.

4. System Log Information

Export Table Name : SYSLGINFO


Table Information : This table lists the system logs for the time range.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter SYSLOG.


Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. FILE_NO NUMC 6 File number3. POS NUMC 10 File offset4. SENDER_ID CHAR 20 Instance name5. RECEVIVE_T CHAR 16 System log time stamp6. POS_CREATT CHAR 16 System log time stamp7. CENTDATA CHAR 180 System log8. AREA CHAR 2 System Log Messages – Area9. SUBID CHAR 1 System Log10. SLGFTYP CHAR 4 SysLog: LIKE structure RSLGETYP11. SLGTTYP CHAR 2 System log: SAP process name12. CLASID CHAR 1 Classification ID for Messages13. DEVCLASS CHAR 30 Development class14. T100ARBGB CHAR 20 Application area15. T100MSGNR CHAR 3 Message number16. ERRNO CHAR 6 Operating system17. MONBEW CHAR 2 System log monitoring category18. MONKAT CHAR 2 System log monitoring category19. TEXT CHAR 100 Description

Note

This table lists the entire system log within the import date and time range. It includes all types of system logs, including successful, warning, and erroneous system logs.

Function Module ‘/OSI/MON_RESPONSE_TIME’Description

108

The purpose of this function is to allow a user to extract performance response time information such as response time for various task types, application response time, and user statistical data.


The data returned by this function module is actually provided by the SAP performance collector, COLLECTOR_FOR_PERFORMANE_MONITOR. Therefore, this SAP performance collector must be running on the target SAP system in order for /OSI/MON_RESPONSE_TIME to successfully retrieve data from the SAP system.

FunctionalityYou can use this function module to output the following performance data and statistical data:

Performance Response Time – Overall

Performance Response Time – User profile

Performance Response Time – Transaction profile

Performance Response Time – User Statistics

Performance data – by Application module

Performance data by Time Statistics


The above data can be seen in SAP transactions ST02, ST03, ST07, and STAT.


Function Module : /OSI/MON_RESPONSE_TIME

Short Text : Get Performance Response Time InformationFunction Group : /OSI/MON




Frequency : Online


Import Parameters : 1. TASKS Default ‘’2. USERS Default ‘’3. TRANS Default ‘’4. STATS Default ‘’5. APPLI Default ‘’6. TIMES Default ‘’7. FROMDATE Default SY-DATUM8. FROMTIME* Default ‘000000’9. TODATE* Default SY-DATUM10. TOTIME* Default ‘235959’

Export Parameters : NoneChanging : NoneTables : 1. RESPINFO STRUCTURE /OSI/MONRESP0



2. USERINFO STRUCTURE /OSI/MONRESP13. TRANINFO STRUCTURE /OSI/MONRESP24. STATINFO STRUCTURE /OSI/MONRESP35. APPLINFO STRUCTURE /OSI/MONRESP46. TIMEINFO STRUCTURE /OSI/MONRESP5


Note: The parameters FROMTIME, TODATE, TOTIME are only relevant for the STATINFO table.

For the other five tables, RESPINFO, USERINFO, TRANINFO, APPLINFO, TIMEINFO, this function module will always return the data for the date specified in FROMDATE. The other three parameters do not have an effect on data obtained for these five tables. This data comes from the SAP performance collector, COLLECTOR_FOR_PERFORMANE_MONITOR.

For example, assume that the SAP performance collector was last run on 9/18/2004 10:00:00 a.m. This function module will return data as of 9/18/2004 10:00:00 a.m. until the SAP performance collector is run at the next scheduled time. It will ignore the time and date specified for FROMTIME, TODATE, and TOTIME.

Import Parameters

No. Field Type Length Description1. TASKS CHAR 1 Enter an ‘X’ if Tasks Response Time is needed.2. USERS CHAR 1 Enter an ‘X’ if User Response Time is needed.3. TRANS CHAR 1 Enter an ‘X’ if Transaction Response time is needed.4. STATS CHAR 1 Enter an ‘X’ if User Statistical data is needed.5. APPLI CHAR 1 Enter an ‘X’ if Application Statistical data is

needed.6. TIMES CHAR 1 Enter an ‘X’ if Time Statistical data is needed.7. FROMDATE DATS 8 Enter the Start date of the data to be accessed.8. FROMTIME TIMS 6 Enter the Start time of the data to be accessed.9. TODATE DATS 8 Enter the End date of the data to be accessed.10. TOTIME TIMS 6 Enter the End time of the data to be accessed.

Exception

No. Exception Description1. NOTHING_SPECIFIE

DThis exception occurs when there is no option chosen or when there is an error that is not specified in the error list.

Table structure

1. Performance Response Time (Overall)

Export Table Name : RESPINFO

Refer Structure : /OSI/MONRESP0

Table Information :

This table lists performance response time sorted by task type. It lists the total dialog steps, the response times, the CPU time, and the wait time for a particular task type within the time and date range.


110

Pre-condition : To get this information, mark ‘X’ on the Import Parameter TASKS.

SAP Transaction(s) : ST03 -> Goto -> Performance database -> Analyze this server -> Workload analysis

Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. TASKTYPE CHAR 7 Task type. I.e. Background, Dialog, RFC, AUTO

etc3. COUNT DEC 15 Number of dialog steps.4. RESPTI DEC 15 Total response time in Seconds5. MRESPTI DEC 15 Average response time in Milliseconds6. CPUTI DEC 15 Total CPU time in Seconds7. MCPUTI DEC 15 Average CPU time in Milliseconds8. QUEUETI DEC 15 Total Wait time in Seconds9. MQUEUETI DEC 15 Average dispatcher wait time in Milliseconds10. DBCALLTI DEC 15 Total Time for data base requests in Seconds11. MDBCALLTI DEC 15 Average DB request time in Milliseconds12. GUINETTIME DEC 15 Total GUI net time in Seconds13. AVGUINETTI DEC 15 Average GUI net time in Milliseconds14. GUITIME DEC 15 Total GUI time in Seconds15. AVGUITIME DEC 15 Average GUI time in Milliseconds16. GUICNT DEC 15 Total GUI count17. BYTES DEC 15 Total data requested in Bytes

Note

The response time data is collected and accumulated data from the SAP performance collector. If you need the response time for the day, then call this function module any time after the last run of the job, COLLECTOR_FOR_PERFORMANCE_MONITOR, and before its first run for the new day. For example, call it at 23:55:00, the end of the day.

This table returns separate information for each application server, if there is more than one in the SAP installation.

2. Performance Response Time - User Profile

Export Table Name : USERINFORefer Structure : /OSI/MONRESP1

Table Information :

This table lists the performance response times sorted by logon users for the particular day and time. It lists the total dialog steps, the response times, the CPU time, and the wait time for a particular user within the time and date range.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter USERS.




Table Structure

No.


1. SERVERNAME CHAR 20 Application server name.2. USER CHAR 12 User/Account ID.3. COUNT INT4 10 Number of dialog steps.4. RESPTI DEC 15 Total response time value in Seconds5. MRESPTI DEC 15 Average response time in Milliseconds6. CPUTI DEC 15 Total CPU Time value in Seconds.7. MCPUTI DEC 15 Average CPU time in Milliseconds8. QUEUETI DEC 15 Total Wait Time value in Seconds9. MQUEUETI DEC 15 Average dispatcher wait time in Milliseconds10. DBCALLTI DEC 15 Total time for data base requests in Seconds11. MDBCALLTI DEC 15 Average DB request time in Milliseconds

Note

The response time data is collected and accumulated from the SAP performance collector. If you need the response time for the day, then call this function module any time after the last run of the job, COLLECTOR_FOR_PERFORMANCE_MONITOR, and before its first run for the new day. For example, call it at 23:55:00, the end of the day.


3. Performance Response Time - Transaction Profile

Export Table Name : TRANINFORefer Structure : /OSI/MONRESP2

Table Information : This table lists the performance response time for the top 40 transactions within the date and time range.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter TRANS.


Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. TCODE CHAR 40 Name of transaction code3. BTCJOB CHAR 32 Background job name4. COUNT INT4 10 Number of dialog steps5. RESPTI DEC 15 Response Time value (ms)6. MRESPTI DEC 15 Av. response time (milliseconds)7. CPUTI DEC 15 CPU Time value (ms)8. MCPUTI DEC 15 Av. CPU time (milliseconds)9. QUEUETI DEC 15 Wait Time value (ms)10. MQUEUETI DEC 15 Av. dispatcher wait time

112

11. DBCALLTI DEC 15 Time for data base requests12. MDBCALLTI DEC 15 Av. DB request time (milliseconds)

Note



4. Performance Response Time - User Statistics (STAT)

Export Table Name : STATINFO


Table Information : This table lists user statistics within a specific timeframe. It allows you to track unauthorized transaction access.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter STATS.

SAP Transaction(s) : STAT

Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. RECNO INT2 5 No. of records (main + sub records)3. DISPCNT RAW 2 Count integer4. DATE DATS 8 Date5. STARTDATE DATS 8 Start date. Format YYYYMMDD6. STARTTIME TIMS 6 Start time. Format HHMMSS7. ENDDATE DATS 8 End date. Format YYYYMMDD8. ENDTIME TIMS 6 End time. Format HHMMSS9. RESPTI DEC 15 Response time in ms10. CPUTI DEC 10 CPU time in Milliseconds11. QUEUETI DEC 10 Wait time in Milliseconds12. WPID RAW 2 Work process id13. TASKTYPE RAW 1 Task type.14. TABLOAD RAW 1 Table load15. DYNPRONR CHAR 4 Dynpro number16. REPORT CHAR 40 Report name17. ACCOUNT CHAR 12 User id18. MANDT CLNT 3 Client number19. TCODE CHAR 20 Transaction code20. MEMUSED RAW 1 Memory used in Kbytes21. DBTI DEC 10 Database request time in Milliseconds22. LOADTI DEC 10 Load time in Milliseconds23. KBYTE DEC 10 Total data transfer in Kbytes



24. DBCHG DEC 10 Number of Database changes

Note

The statistical information for this table may be large depending on the time and date window. If the window is large and the activity within the window is large, the runtime may be slow. This table records and tracks all user activity.

5. Performance data by application module

Export Table Name : APPLINFO


Table Information : This table lists performance response data sorted by application components.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter APPLI.


Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. KL_NAME CHAR 20 Application component3. COUNT DEC 15 Number of dialog steps4. RESPTI DEC 15 Response time in Milliseconds5. CPUTI DEC 10 CPU time in Milliseconds6. QUEUETI DEC 10 Wait time in Milliseconds7. DBTI DEC 10 Database time in Milliseconds8. KBYTE DEC 10 Data transfer in Kbytes

Note



6. Performance data by Time Statistics

Export Table Name : TIMEINFO


Table Information :

This table lists performance response time for a specific time range. It allows you to prepare the load profile for the system, including database load distribution, CPU response time, and response time.


Pre-condition : To get this information, mark ‘X’ on the Import Parameter TIMES.

114


Table Structure

No. Field Type Length

Description

1. SERVERNAME CHAR 20 application server name2. TTYPE RAW 1 Task type. (Dialog, Update, RFC, Background etc)3. TIME CHAR 7 Time range. I.e. 00 – 01, 01 – 02, 02 – 03 etc4. COUNT INT4 10 Number of dialog steps5. RESPTI DEC 15 Response time in Seconds6. MRESPTI DEC 15 Av. response time in Milliseconds)7. CPUTI DEC 15 CPU time in Seconds8. MCPUTI DEC 15 Av. CPU time in Milliseconds9. QUEUETI DEC 15 Wait time in Seconds10. MQUEUETI DEC 15 Av. dispatcher wait time in Milliseconds11. DBCALLTI DEC 15 Time for data base requests in Seconds12. MDBCALLTI DEC 15 Av. DB request time in Milliseconds13. GUINETTIME DEC 15 GUI net time in Seconds14. AVGUINETTI DEC 15 Av. GUI net time in Milliseconds15. GUITIME DEC 15 GUI time in Seconds16. AVGUITIME DEC 15 Av. GUI time in Milliseconds17. GUICNT DEC 15 GUI total count

Note

This table lists information consolidated by time range. The system consolidates the total response time and CPU time for all database or transaction requests throughout the day and arranges it in time range sequence by Task Type. The following are the valid Task Types:

01 - Dialog

02 - Update

04 - Background

06 - Update 2

07 - Spool

FE - RFC




Internal Function ModulesThere are two other function modules that support the multiple application server scenarios:

/OSI/MON_GET_APPLINFO - RFC to get remote application information

/OSI/MON_GET_SYSTLOG - RFC to get system log information

These function modules are called internally in the main function module, they are cannot be called explicitly by an external program.

Function Module ‘/OSI/MON_ GET_APPLINFO’Description

The purpose of this function is to get version and kernel information about a specific application server. This function supports the main function module ‘/OSI/MON_SERVER_INFO’ in multiple application server environments.

The ‘/OSI/MON_SERVER_INFO’ function module calls this function, which returns version and kernel information for each application server.

FunctionalityThe output of this function module provides the following raw information:

Kernel information

SAP versions information

Database release Information

Operating system Information

Note

Do not call this function from an external program. It supports the ‘/OSI/MON_SERVER_INFO’ in multiple application server environments.


Function Module : /OSI/MON_GET_APPLINFO

Short Text : RFC to get application Info. – called from /OSI/MON_SERVER_INFO



Main Program : /OSI/SAPLMON


Frequency : Online


Import Parameters : NoneExport Parameters : NoneChanging : NoneTables : 1. VERSION STRUCTURE THLINES

2. KERNEL STRUCTURE /OSI/MONSERV1Exceptions : NOT_FOUND

116

Table structure

1. Version raw Information

Export Table Name : VERSION

Refer Structure : THLINES

Table Information :

This table lists raw version and system data such as the SAP version, operating system type, machine type, node name, database system, and kernel release. It passes the raw data to the calling function module for further processing.

Frequency of Access :This function module is called by the main program ‘/OSI/MON_SERVER_INFO’. The raw data are further processed to provide accurate system information.

Table Structure

No. Field Type Length Description1. THLINES CHAR 80 Text line

Note

The table lists basic SAP system information such as the SAP version, operating system type, machine type, database system, kernel release, and kernel patch level. All the information is stored as text and passed to the calling function module, ‘/OSI/MON_SERVER_INFO’, where the information is further processed to provide accurate information.

2. Kernel release Information

Export Table Name : KERNEL_INFO


Table Information : This table returns information about the kernel.

Frequency of Access :

The main program, ‘/OSI/MON_SERVER_INFO’, calls this module. This kernel information is the same as the kernel information in section 2.1, except this is for a specific application server.


Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application Server name2. KERN_REL CHAR 80 Kernel release3. KERN_DBLIB CHAR 80 Kernel DB library4. KERN_COMP_ON CHAR 80 Kernel compare on5. KERN_COMP_TIME CHAR 80 Kernel compare time6. KERN_PATCHLEVEL CHAR 80 Kernel patch level7. KERN_SUPPORTLEVEL CHAR 80 Kernel support level8. KERN_SOURCEID CHAR 80 Kernel source id9. COMPUTERNAME CHAR 30 Computer name10. DBMSTYPE CHAR 20 DBMS type11. MYNAME CHAR 20 My server name12. NUMPROCESSOR CHAR 10 Number of processor



No. Field Type Length Description

13. OS CHAR 30 Operating System14. PPID CHAR 10 PPID15. PRARCHITECH CHAR 10 Processor architecture16. PRIDENT CHAR 50 Processor identification17. PRILEVEL CHAR 10 Processor level18. PRREVISION CHAR 20 Processor revision19. SAPLOCALHOST CHAR 30 SAP local host20. MEMORY INT4 10 Memory in MB21. LICENSE CHAR 10 Installation/License number

Note

This table returns kernel information about the application server named by the main function module, ‘/OSI/MON_SERVER_INFO’.

Function Module ‘/OSI/MON_ GET_ SYSTLOG’Description

The purpose of this function module is to get system log information about a specific application server. This function supports the main function module, ‘/OSI/MON_SYSTOPER_INFO’; its primary objective is to provide information in multiple application server environments.

It is called implicitly by the ‘/OSI/MON_SYSTOPER_INFO’ function module and returns the system log information for each application server.

FunctionalityThis function module outputs the system log for the application server requested by the main function module ‘/OSI/MON_SYSTOPER_INFO’.

Note

Do not call this function module from an external program. It supports the main function module, ‘/OSI/MON_SYSTOPER_INFO’, in multiple application server environments.


Function Module : /OSI/MON_GET_SYSTLOG

Short Text : RFC to get System Log Info. – called from /OSI/MON_SYSTOPER_INFO



Main Program : /OSI/SAPLMON


Frequency : Online


Import Parameters : NoneExport Parameters : NoneChanging : None

118

Tables : 1. SYSLGINFO STRUCTURE /OSI/MONSYST4Exceptions : None

Table structure

1. System Log Information

Export Table Name : SYSLGINFO


Table Information : This table returns the system log for the input date and time range.

Frequency of Access :

This function module is called by main program ‘/OSI/MON_SYSTOPER_INFO’. This system log information is the same as the system log information in section 2.2 except it is for a specific application server.


Table Structure

No. Field Type Length Description1. SERVERNAME CHAR 20 Application server name2. FILE_NO NUMC 6 File number3. POS NUMC 10 File offset4. SENDER_ID CHAR 20 Instance name5. RECEVIVE_T CHAR 16 System log time stamp6. POS_CREATT CHAR 16 System log time stamp7. CENTDATA CHAR 180 System log8. AREA CHAR 2 System Log Messages – Area9. SUBID CHAR 1 System Log10. SLGFTYP CHAR 4 SysLog: LIKE structure RSLGETYP11. SLGTTYP CHAR 2 System log: SAP process name12. CLASID CHAR 1 Classification ID for Messages13. DEVCLASS CHAR 30 Development class14. T100ARBGB CHAR 20 Application area15. T100MSGNR CHAR 3 Message number16. ERRNO CHAR 6 Operating system17. MONBEW CHAR 2 System log monitoring category18. MONKAT CHAR 2 System log monitoring category19. TEXT CHAR 100 Description

Note

This table lists the entire system log within the import date and time range for the requested application server.


Appendix C:Specific Point Configuration

The “Principles of Operation” section discussed what points should be created for the tables returned by the three function modules in this interface. This section describes the settings of important point attributes for each point generated by the interface.

Tag InstrumentTag Loc4 PtType

SERVERNAME_Availability* FM=/OSI/MON_SERVER_INFO; TBL=SYSTEM_LIST; KEY1=SERVERNAME; VALUE=Availability;

1 Digital

SERVERNAME_Kernel_Info* FM=/OSI/MON_SERVER_INFO; TBL=KERNEL_INFO; KEY1=SERVERNAME; VALUE=Kernel_Info;

2 String

SERVERNAME_SAPVersion* FM=/OSI/MON_SERVER_INFO; TBL=VERSION_INFO; KEY1=SERVERNAME; VALUE=SAPVersion;

3 String

SERVERNAME_Usr_Total FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=SERVERNAME; VALUE=Usr_Total;

4 Int32

SERVERNAME_Idle_Total FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=SERVERNAME; VALUE=Idle_Total;

4 Int32

SERVERNAME_Free_Mem FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=SERVERNAME; VALUE=Free_Mem;

4 Int32

SERVERNAME_Phys_Mem FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=SERVERNAME; VALUE=Phys_Mem;

4 Int32

Supp_Pkg_Level_COMPONENT FM=/OSI/MON_SERVER_INFO; TBL=VERSION_COMP; KEY1=COMPONENT; VALUE=Supp_Pkg_Level;

5 String

SERVERNAME_AREA_NAME_Hit_Ratio FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2=AREA_NAME; VALUE=Hit_Ratio;

6 Float32



SERVERNAME_AREA_NAME_Alloc_Size FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2=AREA_NAME; VALUE=Alloc_Size;

6 Int32

SERVERNAME_AREA_NAME_Free_Size FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2=AREA_NAME; VALUE=Free_Size;

6 Int32

SERVERNAME_AREA_NAME_Free_Size_Pct FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2=AREA_NAME; VALUE=Free_Size_Pct;

6 Float32

SERVERNAME_AREA_NAME_Swaps FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=SERVERNAME; KEY2=AREA_NAME; VALUE=Swaps;

6 Int32

Spool_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=SPOOLINFO; VALUE=Spool_Count;

7 Int32

AHOST_ABAPDump_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=AHOST; VALUE=ABAPDump_Count;

8 Int32

AHOST_ABAPDump_User FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=AHOST; VALUE=ABAPDump_User;

8 String

AHOST_ABAPDump_ErrorID FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=AHOST; VALUE=ABAPDump_ErrorID;

8 String

Failed_Update_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=UPDV1INFO; VALUE=Failed_Update_Count;

9 Int32

SERVERNAME_System_Log_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=SYSLGINFO; KEY1=SERVERNAME; VALUE=System_Log_Count;

10 Int32

SERVERNAME_Task_TASKTYPE_Count FM=/OSI/MON_RESPONSE_TIME;

TBL=RESPINFO; KEY1=SERVERNAME; KEY2=TASKTYPE; VALUE=Count;

11 Float64



SERVERNAME_Task_TASKTYPE_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=RESPINFO; KEY1=SERVERNAME; KEY2=TASKTYPE; VALUE=Avg_Response_Time;

11 Float64

SERVERNAME_Task_TASKTYPE_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=RESPINFO; KEY1=SERVERNAME; KEY2=TASKTYPE; VALUE=Avg_CPU_Time;

11 Float64

SERVERNAME_Task_TASKTYPE_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=RESPINFO; KEY1=SERVERNAME; KEY2=TASKTYPE; VALUE=Avg_Queue_Time;

11 Float64

SERVERNAME_Task_TASKTYPE_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=RESPINFO; KEY1=SERVERNAME; KEY2=TASKTYPE; VALUE=Avg_DBCall_Time;

11 Float64

SERVERNAME_USER_Count FM=/OSI/MON_RESPONSE_TIME;

TBL=USERINFO; KEY1=SERVERNAME; KEY2=USER; VALUE=Count;

12 Float64

SERVERNAME_USER_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=USERINFO; KEY1=SERVERNAME; KEY2=USER; VALUE=Avg_Response_Time;

12 Float64

SERVERNAME_USER_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=USERINFO; KEY1=SERVERNAME; KEY2=USER; VALUE=Avg_CPU_Time;

12 Float64

SERVERNAME_USER_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=USERINFO; KEY1=SERVERNAME; KEY2=USER; VALUE=Avg_Queue_Time;

12 Float64


Appendix C: Specific Point Configuration


SERVERNAME_USER_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=USERINFO; KEY1=SERVERNAME; KEY2=USER; VALUE=Avg_DBCall_Time;

12 Float64

SERVERNAME_Transaction_TCODE_Count FM=/OSI/MON_RESPONSE_TIME;

TBL=TRANINFO; KEY1=SERVERNAME; KEY2=TCODE; VALUE=Count;

13 Float64

SERVERNAME_Transaction_TCODE_Avg_Response_Time

FM=/OSI/MON_RESPONSE_TIME;

TBL=TRANINFO; KEY1=SERVERNAME; KEY2=TCODE; VALUE=Avg_Response_Time;

13 Float64

SERVERNAME_Transaction_TCODE_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=TRANINFO; KEY1=SERVERNAME; KEY2=TCODE; VALUE=Avg_CPU_Time;

13 Float64

SERVERNAME_Transaction_TCODE_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=TRANINFO; KEY1=SERVERNAME; KEY2=TCODE; VALUE=Avg_Queue_Time;

13 Float64

SERVERNAME_Transaction_TCODE_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=TRANINFO; KEY1=SERVERNAME; KEY2=TCODE; VALUE=Avg_DBCall_Time;

13 Float64

SERVERNAME_REPORT_ACCOUNT_MANDT_Response_Time

FM=/OSI/MON_RESPONSE_TIME;

TBL=STATINFO; KEY1=SERVERNAME; KEY2=REPORT; KEY3=ACCOUNT; KEY4=MANDT; VALUE=Response_Time;

14 Float64

SERVERNAME_KL_NAME_Count FM=/OSI/MON_RESPONSE_TIME;

TBL=APPLINFO; KEY1=SERVERNAME; KEY2=KL_NAME; VALUE=Count;

15 Float64

124


SERVERNAME_KL_NAME_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=APPLINFO; KEY1=SERVERNAME; KEY2=KL_NAME; VALUE=Response_Time;

15 Float64

SERVERNAME_KL_NAME_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=SERVERNAME; KEY2=KL_NAME; VALUE=CPU_Time;

15 Float64

SERVERNAME_KL_NAME_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=APPLINFO; KEY1=SERVERNAME; KEY2=KL_NAME; VALUE=Queue_Time;

15 Float64

SERVERNAME_KL_NAME_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME;

TBL=APPLINFO; KEY1=SERVERNAME; KEY2=KL_NAME; VALUE=DBCall_Time;

15 Float64

SERVERNAME_TTYPE_Count** FM=/OSI/MON_RESPONSE_TIME;

TBL=TIMEINFO; KEY1=SERVERNAME; KEY2=TTYPE; VALUE=Count;

16 Float64

SERVERNAME_TTYPE_Avg_Response_Time** FM=/OSI/MON_RESPONSE_TIME;

TBL=TIMEINFO; KEY1=SERVERNAME; KEY2=TTYPE; VALUE=Avg_Response_Time;

16 Float64

SERVERNAME_TTYPE_Avg_CPU_Time** FM=/OSI/MON_RESPONSE_TIME;

TBL=TIMEINFO; KEY1=SERVERNAME_TTYPE; VALUE=Avg_CPU_Time;

16 Float64

SERVERNAME_TTYPE_Avg_Queue_Time** FM=/OSI/MON_RESPONSE_TIME;

TBL=TIMEINFO; KEY1=SERVERNAME; KEY2=TTYPE; VALUE=Avg_Queue_Time;

16 Float64

SERVERNAME_TTYPE_Avg_DBCall_Time** FM=/OSI/MON_RESPONSE_TIME;

TBL=TIMEINFO; KEY1=SERVERNAME; KEY2=TTYPE; VALUE=Avg_DBCall_Time;

16 Float64


Appendix C: Specific Point Configuration

For these 3 points, the shutdown attribute is set to 0. All the other points have shutdown as 1 (true).

** For these 6 points, the Step attribute is set to ON. All the other points have Step set to OFF.

When the interface automatically creates the above points, the default values are used for the other point attributes.

Furthermore, if a tag name prefix is specified via command-line parameter in the interface startup command file, all tag names described in the above table will include this prefix. For example, if a prefix “PRD_” is defined, all the points created by this interface will have tagnames starting with “PRD_”. See “Startup Command File” section for more details.

126

Appendix D:Hierarchy Builder Program

IntroductionThe PI-ERP Performance Interface extracts system performance information from an SAP R/3 system and stores the data into a PI Server via PI points. However, as with all PI interface programs, PI-ERP Performance Interface is unaware of any hierarchal relationship that may exist among the points to which it writes data. For example, a user runs the Interface to monitor the performance of an SAP system containing two servers, called Bach and Chopin. The Interface writes performance data to points named:

Bach_SAPVersion

Bach_Phys_Mem

Bach_Free_Mem

Chopin_SAPVersion

Chopin_Phys_Mem

Chopin_Free_Mem

This user will probably want to view the performance data based on a hierarchy such as the following:

Servers

Bach

SAP Version

Physical Memory

Free Memory

Chopin

SAP Version

Physical Memory

Free Memory

In the terminology of the PI Module Database,

Servers is a Module Name;

Bach and Chopin are Sub Modules, and;

SAP Version, Physical Memory, and Free Memory are Aliases

Therefore, it is logical to associate the above PI points with the above aliases as follows:

Servers

Bach

SAP Version (Bach_SAPVersion)

Physical Memory (Bach_Phys_Mem)

Free Memory (Bach_Free_Mem)


Chopin

SAP Version (Chopin_SAPVersion)

Physical Memory (Chopin_Phys_Mem)

Free Memory (Chopin_Free_Mem)

By using the above structure, PI client programs such as PI-ProcessBook can display data according to a logical hierarchy. The Hierarchy Builder builds such a hierarchy. That is, it builds a hierarchical relationship among the points serviced by the PI-ERP Performance Interface. A later section of this appendix describes the hierarchical relationship in detail.

Hierarchy Builder runs on the same machine as the PI-ERP Performance Interface itself.

Theory of Operation

InstrumentTag AttributeFor points serviced by the PI-ERP Performance Interface, the InstrumentTag attribute contains information regarding the SAP performance data to be retrieved. For example, if a point named Bach_SAPVersion has the following InstrumentTag:FM=/OSI/MON_SERVER_INFO; TBL=VERSION_INFO; KEY1=Bach; VALUE=SAPVersion;

The Interface retrieves for the SAP server named Bach the SAP version number.

Another example is a point named Bach_Phys_Mem with the following InstrumentTag:FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach; VALUE=Phys_Mem;

This tells the Interface to retrieve for the SAP server named Bach the amount of Physical Memory.

Finally, for a point named Bach_Free_Mem with InstrumentTag:FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach; VALUE=Free_Mem;

The Interface retrieves for the SAP server named Bach the amount of Free Memory.

Accordingly, any program that can obtain the InstrumentTag attribute for the points Bach_SAPVersion, Bach_Phys_Mem, and Bach_FreeMem can build the following hierarchy in the PI Module Database:

Servers

Bach

SAP Version (Bach_SAPVersion)

Physical Memory (Bach_Phys_Mem)

Free Memory (Bach_Free_Mem)

The Hierarchy Builder is such a program.

UniInt-basedThe Hierarchy Builder is based on OSIsoft's UniInt program template. The startup command parameters to Hierarchy Builder are:

a point source (e.g., /ps=S),

an interface identification number (e.g., /id=1),


an SAP Instance name (e.g., /instance=Production),

a PI Server name and port number (e.g., /host=pimachine:5450) and

a frequency for checking point updates (e.g., /updateinterval=120).

The first three parameters are required while the last two are optional.

When you use the Hierarchy Builder, you must ensure that the following parameters

/ps

/id

/host

are identical to the ones for the PI-ERP Performance Interface.

When it first starts up, Hierarchy Builder receives a list of points for the given point source. For each point, Hierarchy Builder looks at the following attributes

Location1

InstrumentTag

Extended Descriptor

Location4

PointType

Hierarchy Builder uses these attributes to determine whether each point in the list is suitable for data collection by the PI-ERP Performance Interface. If the point is suitable, Hierarchy Builder parses the contents of the InstrumentTag to extract the necessary information for building the appropriate module, sub-module, and alias in the information hierarchy.

By default, Hierarchy Builder checks the PI Server every 120 seconds for point updates. (This interval of two minutes may be changed via the command-line parameter /updateinterval.) When it receives notice of a point update, the program then looks at the above point attributes and determines whether the point is suitable for use by the PI-ERP Performance Interface. Hierarchy Builder adds, modifies, or deletes aliases as appropriate.

SAP Performance HierarchyThe following notation describes the hierarchy that Hierarchy Builder builds:

Bold Module Name

Bold and Italics Instance of a Module

Normal Alias Name

Arial Font InstrumentTag specification of PI point

SAP Instances

SAP Instance Name

Spool Count FM=/OSI/MON_SYSTOPER_INFO; TBL=SPOOLINFO; VALUE=Spool_Count;

Failed Update Count FM=/OSI/MON_SYSTOPER_INFO; TBL=UPDV1INFO; VALUE=Failed_Update_Count;


Appendix D: Hierarchy Builder Program

Servers

ServerName

Available FM=/OSI/MON_SERVER_INFO; TBL=SYSTEM_LIST; KEY1=ServerName; VALUE=Availability;

Kernel Info FM=/OSI/MON_SERVER_INFO; TBL=KERNEL_INFO; KEY1=ServerName; VALUE=Kernel_Info; SAP Version FM=/OSI/MON_SERVER_INFO; TBL=VERSION_INFO; KEY1=ServerName; VALUE=SAPVersion;

User Time FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=ServerName; VALUE=Usr_Total; Idle Time FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=ServerName; VALUE=Idle_Total; Physical Memory FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=ServerName; VALUE=Phys_Mem; Free Memory FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=ServerName; VALUE=Free_Mem; System Log Count FM=/OSI/MON_SYSTOPER_INFO; TBL=SYSLGINFO; KEY1=ServerName; VALUE=System_Log_Count;

Areas

AreaName

Buffer Hit Ratio FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=ServerName; KEY2=AreaName; VALUE=Hit_Ratio;

Available Space FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=ServerName; KEY2=AreaName; VALUE=Free_Size;

Allocated Space FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=ServerName; KEY2=AreaName; VALUE=Alloc_Size;

Free Space FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=ServerName; KEY2=AreaName; VALUE=Free_Size_Pct;

Object Swapped FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=ServerName; KEY2=AreaName; VALUE=Swaps;

Tasks

TaskName

130

Dialog Steps FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1=ServerName; KEY2=TaskName; VALUE=Count;

Average Response Time FM=/OSI/MON_RESPONSE_TIME; TBL= RESPINFO; KEY1=ServerName; KEY2=TaskName; VALUE=Avg_Response_Time;

Average CPU Time FM=/OSI/MON_RESPONSE_TIME; TBL= RESPINFO; KEY1=ServerName; KEY2=TaskName; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time FM=/OSI/MON_RESPONSE_TIME; TBL= RESPINFO; KEY1=ServerName; KEY2=TaskName; VALUE=Avg_Queue_Time;

Average Database Request Time FM=/OSI/MON_RESPONSE_TIME; TBL= RESPINFO; KEY1=ServerName; KEY2=TaskName; VALUE=Avg_DBCall_Time;

Users

UserName

Dialog Steps FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=ServerName; KEY2=UserName; VALUE=Count;

Average Response Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=ServerName; KEY2=UserName; VALUE=Avg_Response_Time;

Average CPU Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=ServerName; KEY2=UserName; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=ServerName; KEY2=UserName; VALUE=Avg_Queue_Time;

Average Database Request Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=ServerName; KEY2=UserName; VALUE=Avg_DBCall_Time;

Transactions

TransactionCode

Dialog Steps FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1=ServerName; KEY2=TransactionCode; VALUE=Count;

Average Response Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1=ServerName; KEY2=TransactionCode; VALUE=Avg_Response_Time;

Average CPU Time



FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1=ServerName; KEY2=TransactionCode; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1=ServerName; KEY2=TransactionCode; VALUE=Avg_Queue_Time;

Average Database Request Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1=ServerName; KEY2=TransactionCode; VALUE=Avg_DBCall_Time;

Reports

ReportName

UserName

Mandt

Response Time FM=/OSI/MON_RESPONSE_TIME; TBL=STATINFO; KEY1=ServerName; KEY2=ReportName; KEY3=UserName; KEY4=Mandt; VALUE=Response_Time;

Applications

ApplicationName

Dialog Steps FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=ServerName_ KEY2=ApplicationName; VALUE=Count;

Average Response Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=ServerName; KEY2=ApplicationName; VALUE=Avg_Response_Time;

Average CPU Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=ServerName; KEY2=ApplicationName; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=ServerName; KEY2=ApplicationName; VALUE=Avg_Queue_Time;

Average Database Request Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1=ServerName; KEY2=ApplicationName; VALUE=Avg_DBCall_Time;

Task Types

TaskType

Dialog Steps FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1=ServerName; KEY2=TaskType; VALUE=Count;

Average Response Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1=ServerName; KEY2=TaskType; VALUE=Avg_Response_Time;

132

Average CPU Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1=ServerName; KEY2=TaskType; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1=ServerName; KEY2=TaskType; VALUE=Avg_Queue_Time;

Average Database Request Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1=ServerName; KEY2=TaskType; VALUE=Avg_DBCall_Time;

Application Hosts

ApplicationHostName

Error Count FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=ApplicationHostName; VALUE=ABAPDump_Count;

Username FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=ApplicationHostName; VALUE=ABAPDump_User;

Error ID FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=ApplicationHostName; VALUE=ABAPDump_ErrorID;

Components

ComponentName

Support Package Level FM=/OSI/MON_SERVER_INFO; TBL=VERSION_COMP; KEY1=ComponentName; VALUE=Supp_Pkg_Level;

Hierarchy ExampleThe following is an example of the hierarchy that Hierarchy Builder builds for the following startup command line: hierarchBuild.exe –ps=S –id=1 –instance=Production –host=pimachine:5450 -f=1 -f=2 -f=3 -f=4 -f=5 -f=6 -f=7 -f=8 -f=9 -f=10 -f=11 -f=12 -f=13 -f=14 f=15 -f=16

In the example hierarchy below, the name of the PI point (i.e., Bach_PRD_00_Phys_Mem) is shown after the alias. The Instrument Tag of this PI point follows.

SAP Instances

Production

Spool Count Spool_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=SPOOLINFO; VALUE=Spool_Count;

Failed Update Count



Failed_Update_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=UPDV1INFO; VALUE=Failed_Update_Count;

Servers

Bach_PRD_00

Available Bach_PRD_00_Availability FM=/OSI/MON_SERVER_INFO; TBL=SYSTEM_LIST; KEY1=Bach_PRD_00; VALUE=Availability;

Kernel Info Bach_PRD_00_Kernel_Info FM=/OSI/MON_SERVER_INFO; TBL=KERNEL_INFO; KEY1= Bach_PRD_00; VALUE=Kernel_Info; SAP Version Bach_PRD_00_SAPVersion FM=/OSI/MON_SERVER_INFO; TBL=VERSION_INFO; KEY1= Bach_PRD_00; VALUE=SAPVersion;

User Time Bach_PRD_00_Usr_Total FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach_PRD_00; VALUE=Usr_Total;

Idle Time Bach_PRD_00_Idle_Total FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach_PRD_00; VALUE=Idle_Total;

Physical Memory Bach_PRD_00_Phys_Mem FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach_PRD_00; VALUE=Phys_Mem; Free Memory Bach_PRD_00_Free_Mem FM=/OSI/MON_SERVER_INFO; TBL=OS_MONITOR; KEY1=Bach_PRD_00; VALUE=Free_Mem;

System Log Count Bach_PRD_00_System_Log_Count FM=/OSI/MON_ SYSTOPER_INFO; TBL= SYSLGINFO; KEY1=Bach_PRD_00; VALUE=System_Log_Count; Areas

Calendar

Buffer Hit Ratio Bach_PRD_00_Calendar_Hit_Ratio FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=Bach_PRD_00; KEY2=Calendar; VALUE=Hit_Ratio;

Available Space Bach_PRD_00_Calendar_Free_Size FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=Bach_PRD_00; KEY2=Calendar; VALUE=Free_Size;

Allocated Space

134

Bach_PRD_00_Calendar_Alloc_Size FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=Bach_PRD_00; KEY2=Calendar; VALUE=Alloc_Size;

Free Space Bach_PRD_00_Calendar_Free_Size_Pct FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=Bach_PRD_00; KEY2=Calendar; VALUE=Free_Size_Pct;

Object Swapped Bach_PRD_00_Calendar_Swaps FM=/OSI/MON_SERVER_INFO; TBL=BUFFER_STAT; KEY1=Bach_PRD_00; KEY2=Calendar; VALUE=Swaps;

Tasks

AL11

Dialog Steps Bach_PRD_00_Task_AL11_Count FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1=Bach_PRD_00; KEY2=AL11; VALUE=Count;

Average Response Time Bach_PRD_00_Task_AL11_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1=Bach_PRD_00; KEY2=AL11; VALUE=Avg_Response_Time;

Average CPU Time Bach_PRD_00_Task_AL11_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1=Bach_PRD_00; KEY2=AL11; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time Bach_PRD_00_Task_AL11_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1= Bach_PRD_00; KEY2=AL11; VALUE=Avg_Queue_Time;

Average Database Request Time Bach_PRD_00_Task_AL11_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME; TBL=RESPINFO; KEY1= Bach_PRD_00; KEY2=AL11; VALUE=Avg_DBCall_Time;

Users

Fred

Dialog Steps Bach_PRD_00_Fred_Count FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=Bach_PRD_00; KEY2=Fred; VALUE=Count;

Average Response Time Bach_PRD_00_Fred_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=Bach_PRD_00; KEY2=Fred; VALUE=Avg_Response_Time;

Average CPU TimeERP Performance Interface to the PI System 135


Bach_PRD_00_Fred_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1=Bach_PRD_00; KEY2=Fred; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time Bach_PRD_00_Fred_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1= Bach_PRD_00; KEY2=Fred; VALUE=Avg_Queue_Time;

Average Database Request Time Bach_PRD_00_Fred_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME; TBL=USERINFO; KEY1= Bach_PRD_00; KEY2=Fred; VALUE=Avg_DBCall_Time;

Transactions

AutoABAP

Dialog Steps Bach_PRD_00_Transaction_AutoABAP_Count FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1= Bach_PRD_00; KEY2=AutoABAP; VALUE=Count;

Average Response Time Bach_PRD_00_Transaction_AutoABAP_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1= Bach_PRD_00; KEY2=AutoABAP; VALUE=Avg_Response_Time;

Average CPU Time Bach_PRD_00_Transaction_AutoABAP_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1= Bach_PRD_00; KEY2=AutoABAP; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time Bach_PRD_00_Transaction_AutoABAP_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1= Bach_PRD_00; KEY2=AutoABAP; VALUE=Avg_Queue_Time;

Average Database Request Time Bach_PRD_00_Transaction_AutoABAP_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TRANINFO; KEY1= Bach_PRD_00; KEY2=AutoABAP; VALUE=Avg_DBCall_Time;

Reports

SAPMSSY1

Fred

200

Response Time Bach_PRD_00_SAPMSSY1_Fred_200_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=STATINFO; KEY1= Bach_PRD_00; KEY2=SAPMSSY1; KEY3=Fred; KEY4=200; VALUE=Response_Time;

Applications

136

BasisComponents

Dialog Steps Bach_PRD_00_BasisComponents_Count FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1= Bach_PRD_00; KEY2=BasisComponents; VALUE=Count;

Average Response Time Bach_PRD_00_BasisComponents_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1= Bach_PRD_00; KEY2= BasisComponents; VALUE=Avg_Response_Time;

Average CPU Time Bach_PRD_00_BasisComponents_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1= Bach_PRD_00; KEY2= BasisComponents; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time Bach_PRD_00_BasisComponents_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1= Bach_PRD_00; KEY2= BasisComponents; VALUE=Avg_Queue_Time;

Average Database Request Time Bach_PRD_00_BasisComponents_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME; TBL=APPLINFO; KEY1= Bach_PRD_00; KEY2= BasisComponents; VALUE=Avg_DBCall_Time;

Task Types

FE

Dialog Steps Bach_PRD_00_FE_Count FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1= Bach_PRD_00; KEY2=FE; VALUE=Count;

Average Response Time Bach_PRD_00_FE_Avg_Response_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1= Bach_PRD_00; KEY2=FE; VALUE=Avg_Response_Time;

Average CPU Time Bach_PRD_00_FE_Avg_CPU_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1= Bach_PRD_00; KEY2=FE; VALUE=Avg_CPU_Time;

Average Dispatcher Wait Time Bach_PRD_00_FE_Avg_Queue_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1= Bach_PRD_00; KEY2=FE; VALUE=Avg_Queue_Time;

Average Database Request Time Bach_PRD_00_FE_Avg_DBCall_Time FM=/OSI/MON_RESPONSE_TIME; TBL=TIMEINFO; KEY1= Bach_PRD_00; KEY2=FE; VALUE=Avg_DBCall_Time;

Application HostsERP Performance Interface to the PI System 137


Bach

Error Count Bach_ABAPDump_Count FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=Bach; VALUE=ABAPDump_Count;

Username Bach_ABAPDump_User FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=Bach; VALUE=ABAPDump_User;

Error ID Bach_ABAPDump_ErrorID FM=/OSI/MON_SYSTOPER_INFO; TBL=ADUMPINFO; KEY1=Bach; VALUE=ABAPDump_ErrorID;

Components

SAP_ABA

Support Package Level Supp_Pkg_Level_SAP_ABA FM=/OSI/MON_SERVER_INFO; TBL=VERSION_COMP; KEY1=SAP_ABA; VALUE=Supp_Pkg_Level;

PI Module Database EntriesThe Hierarchy Builder builds its hierarchy under the %OSI, ITMonitor module. For example,

Module and Alias DeletionsThe Hierarchy Builder does not delete modules or aliases. For example, if the PI-ERP Performance Interface no longer services a point, the Hierarchy Builder does not delete the corresponding alias and modules.

If you wish to delete aliases and modules, you must use the PI Module Database Editor.

138

Effective Dates for ModulesThe Hierarchy Builder makes use of the effective date feature of the PI Module Database so that you can keep track of the history of your SAP Hierarchy. Specifically, when Hierarchy Builder creates modules that are specific to your instance of the PI-ERP Performance Interface, it uses the current time as the effective date. Modules that are specific to the general hierarchy have an effective date of 1 second, 1 January 1970 UTC (Coordinated Universal Time).

In the example below, the modules in italics have an effective date that reflects the current time. The others have an effective date of 1 second, 1 January 1970.

SAP Instances

Production

Servers

Bach_PRD_00

Areas

Calendar

Components

The following table summarizes the values of the effective dates of the above example.

Font Effective DateBold 1 second, 1 January 1970 UTC

Italics previous time, e.g., 5-June-2004 08:25:20

Later on, if your SAP Hierarchy contains an Area named CUA, the Hierarchy Builder will create the appropriate module, but with an effective date that is the then current time. Of course, this effective date is different than the effective date of the modules named Production, Bach_PRD_00, and Calendar. This CUA module is shown underlined below.

SAP Instances

Production

Servers

Bach_PRD_00

Areas

Calendar

CUA

Components

The following table summarizes the values of the effective dates of the above example.

Font Effective DateBold 1 second, 1 January 1970 UTC



Italics previous time, e.g., 5-June-2004 08:25:20

Underline current time; e.g., 10-June-2004 12:14:10

In this manner, you will be able to see the change in the configuration of your SAP system.

Point Processing DelayWhen the Hierarchy Builder and the PI Server's PI Base Subsystem are running on the same machine, these two programs can use close to 100% of the machine's CPU during the creation of modules and aliases. To prevent a prolonged duration of this situation, the Hierarchy Builder will delay point processing. Specifically, when it discovers that it has processed 50 points in less than 30 seconds, Hierarchy Builder will wait 10 seconds before resuming point processing.

Installation Checklist for Hierarchy BuilderYou should follow the steps in the order listed below.

1. Obtain, install, and configure PI-ERP Performance Interface. The Hierarchy Builder program is distributed as part of the Interface.

2. Configure the program as a Windows service by running the command file installHierarchBuildService.bat.

3. Configure startup parameters for Hierarchy Builder by editing the startup command file.

4. If PI-ERP Performance Interface is not already running, start it.

5. Start Hierarchy Builder as a service.

6. Run the PI Module Database Editor to confirm that Hierarchy Builder built the appropriate modules, sub-modules, and aliases.

Program InstallationThe installation of the PI-ERP Performance Interface automatically installs the Hierarchy Builder.

Configuring the Program as a Windows ServiceTo configure the Hierarchy Builder as a Windows service, you can

run the installHierarchBuildService.bat file, or

manually enter commands yourself.

The next section describes the second of these two procedures.

Command Lines for Windows Service ConfigurationThe commands below are shown on two lines because of space limitations. However, you should type them all as a single line.

Manual Service

C:> hierarchBuild.exe –install –display "PI SAP Hierarchy Builder" –depend pinetmgr

140

Automatic Service

C:> hierarchBuild.exe –install –display "PI SAP Hierarchy Builder" –auto –depend pinetmgr

You can get help for configuring Hierarchy Builder as a service at any time by using the -help command line parameter. For example,

C:\program files\pipc\interfaces\erpperf\hierarchBuild.exe -help

Services Control PanelCheck the Microsoft Windows services control panel to verify that Hierarchy Builder was correctly added as a service. You can use the services control panel at any time to change the program from an automatic service to a manual service or vice versa.

Program Parameters

Startup ParametrsFor proper operation, the Hierarchy Builder requires various command-line parameters. Put these parameters, along with the name of the program executable, into a startup command file. For example,

hierarchBuild.exe /ps=S /id=1 /instance=Production

For Windows, various filename extensions are associated with command files. For example, .bat and .cmd are both acceptable. However, only the .bat extension is valid for a command file used by the Interface.

The name of the startup command file must be the name of the program executable, with the .exe extension replaced by the .bat extension. Thus, the startup command file for Hierarchy Builder will typically be hierarchBuild.bat. (The installation program installs a sample command file named hierarchBuild.bat.new. You should use this file as a template for your own hierarchBuild.bat.)

The contents of a PI Interface command file may contain the caret line continuation character (^). For example, a hierarchBuild.bat file with contents:hierarchBuild.exe ^ /ps=S ^ /id=1 ^ /instance=Productionis equivalent to the above example.

The maximum length of each line in a command file is 1024 characters. The number of parameters is unlimited, and the maximum length of each parameter is 1024 characters. If a value for a parameter contains a space, use a pair of double quotes to enclose both the parameter and its value. For example,

hierarchBuild.exe /ps=S /id=1 "/instance=Production 1"

Command-line ParametersThe Hierarchy Builder program requires a number of parameters for proper operation. These parameters may appear in any order on the command line. The slash character (/) precedes each parameter. For backwards compatibility, the dash character (-) may also precede each parameter.




/ps=x

Required

The /ps parameter specifies the point source character for the program. Each instance of Hierarchy Builder uses the /ps and /id parameters to identify uniquely its particular list of points to service. The value for the /ps parameter is not case sensitive. That is, /ps=X is identical to /ps=x.

The value of this parameter must match the one for the corresponding copy of the PI-ERP Performance Interface.

/id=x

Required

The /id parameter specifies the program identification number. Each instance of Hierarchy Builder uses the /ps and /id parameters to identify uniquely its particular list of points to service. In addition, the program uses the value of this parameter in the messages that it writes to the log file. For example, if you specify /id=1, then the message log file will have contents such as:

12-Dec-02 14:44:58

HierarchBuild 1> 125 points found for point source S


/instance=x

Required

The /instance parameter is a user-specified name of an SAP instance. The Hierarchy Builder uses the value of this parameter in the top level of the hierarchy that it builds.

If you are running multiple copies of the PI-ERP Performance Interface, you must ensure that the value of /instance is used only once among these multiple copies. For example, if you have

hierarchBuild1.exe /ps=S /instance=Production

then you cannot have the following:

hierarchBuild2.exe /ps=M /instance=Production

/f=x,x

16 occurrences required

The /f parameter normally defines a scan class number for an interface program. Even though Hierarchy Builder is not an interface program, it still needs 16 instances of this parameter in order for proper operation.

The 16 instances of /f do not need to coincide with the PI-ERP Performance Interface's. Thus, the easiest way to fulfill this requirement is the following:

hierarchBuild1.exe /f=1 /f=2 /f=3 /f=4 /f=5 /f=6 /f=7 /f=8 /f=9 /f=10 /f=11 /f=12 /f=13 /f=14 /f=15 /f=16

142


/host=host:port

Optional, but highly recommended

The /host parameter specifies either the IP address or the TCP/IP hostname of the machine on which the PI Server runs. The syntax for –host should include the port number for communications between the PI-API and PI Server. For example,

hierarchBuild.exe /ps=X /host=piserver:5450


/updateinterval=

Optiona)

The –updateinterval parameter specifies the frequency at which Hierarchy Builder checks for point updates from the PI Server. If you do not specify this parameter, the program uses a default value of 120 seconds.

The minimum value for /updateinterval is 1 and the maximum is 300.

Starting / Stopping the Program

Configure the Startup Parameters

Before starting the program either interactively or as a service, configure the startup parameters by editing the startup command file hierarchBuild.bat. (The installation program installs a sample command file named hierarchBuild.bat.new. You should use this file as a template for your own hierarchBuild.bat.)

Starting the Program InteractivelyYou should run Hierarchy Builder interactively only for testing purposes. Under normal circumstances, run the program as a Windows service.

To start the program interactively, open a Windows command prompt window and go to the directory where the hierarchBuild.exe and hierarchBuild.bat files are located. Then, run the command file. For example,

C:\program files\pipc\interfaces\erpperf> hierarchBuild.bat

To stop a copy of Hierarchy Builder that is currently running interactively, simply use Control-C.

Starting the Program as a ServiceTo start Hierarchy Builder as a Windows service, open a Windows command prompt window and type the following:C:> net start hierarchBuildThe operating system will then display a message informing you whether it has successfully started the Hierarchy Builder service.

Stopping the Program Running as a ServiceTo stop Hierarchy Builder as a Windows service, open a Windows command prompt window and type the following:



C:> net stop hierarchBuildThe operating system will then display a message informing you whether it has successfully stopped the Hierarchy Builder service.

Other Service-related CommandsTo determine whether Hierarchy Builder is currently running as a Windows service, use the -query parameter to hierarchBuild.exe. For example,

C:\program files\pipc\interfaces\erpperf> hierarchBuild.exe -query

The remove Hierarchy Builder from Windows's list of services, use the -remove parameter to hierarchBuild.exe. For example,

C:\program files\pipc\interfaces\erpperf> hierarchBuild.exe -remove

Multiple Copies of the ProgramIf you want to run multiple copies of the program, you need to copy and rename the executable and the startup command files. For example, you would typically have hierarchBuild1.exe and hierarchBuild11.bat for the first instance, hierarchBuild2.exe and pinetflow.bat for the second instance, and so on. The reason is that when the program runs as a service (e.g., hierarchBuild1), it looks for a command file (e.g., hierarchBuild1.bat) that has the same root name as the executable (e.g., hierarchBuild1.exe).

Similarly, you need to install each instance of the program as a service. For example,

Manual Service

C:> hierarchBuild1.exe –install –display "PI SAP Hierarchy Builder 1" –depend pinetmgr

Automatic Service

C:> hierarchBuild1.exe –install –display "PI SAP Hierarchy Builder 1" –auto –depend pinetmgr

Manual Service

C:> hierarchBuild2.exe –install –display "PI SAP Hierarchy Builder" –depend pinetmgr

Automatic Service

C:> hierarchBuild2.exe –install –display "PI SAP Hierarchy Builder 2" –auto –depend pinetmgr

144

Appendix E:Sample PI-ProcessBook Displays

IntroductionA PI-ProcessBook file PIERPperf_sample_pb.piw is provided with the PI-ERP Performance Interface. The purpose of the sample process displays is to quickly demonstrate the capabilities of the PI-ERP Performance Interface. However, before attempting the steps described here, you must already be familiar with using the PI System. In particular, you must know how to install and start PI data collection interface programs.

In order to use the sample PI-ProcessBook displays, you must have the following software installed and running:

1. PI Server v3.3 or higher.

2. The PI-ERP Performance Interface must be running and recording data to the PI server.

3. The Hierarchy Builder must be running on the same machine as the PI-ERP Performance Interface.

4. PI-ProcessBook must be v2.35 or higher


Viewing Data from /OSI/MON_SERVER_INFOAll information from the /OSI_SERVER_INFO function module is presented in a single display called “Server”.

“Server Information” displays data collected by the following tables:

SYSTEM_LIST

KERNEL_INFO

VERSION_INFO

OS_MONITOR

All servers in the SAP Instance are shown in server list. To view the performance of a server, select it from the list.

“Buffer Status” displays data collected by the BUFFER_STAT table. All servers and areas are shown in area list. To view the buffer statistics of an area on a specific server, select it from the list.

“Components” displays data collected by the VERSION_COMP table.

Note: KERNEL_INFO, VERSION_INFO and VERSION_COMP store values into string tags. These cannot be displayed natively by ProcessBook 2.35 so the values are displayed in labels or tables. These will not automatically update. To update these values press “Refresh”


Viewing Data from /OSI/MON_SYSTOPER_INFOAll information from the /OSI/MON_SYSTOPER_INFO function module is presented in a single display called “System Operation”.

“System Counters” displays data collected by the SPOOLINFO and UPDV1INFO tables.

“Log Entries” displays data collected by the SYSLGINFO table. To view the number of log entries on a server, select it from the list.

“ABAP Errors” displays data collected by the ADUMPINFO table. The view the error count of an application host, select it from the list. To view the actual ABAP dump errors over the time period shown in the “Error Count” trend, click “List ABAP Errors”.

Viewing Data from /OSI/MON_RESPONSE_TIMEInformation from the /OSI/MON_RESPONSE_TIME function module is presented in the following displays:

Task Type Response

User Response

Transaction Response

Report Response

Application Response

Task Response

“Task Type Response” displays data collection by the RESPINFO table. To view the response time of a task type on a server, select it from the list.


Appendix E: Sample PI-ProcessBook Displays

“User Response” displays data collection by the USERINFO table. To view the response time of a user against a server, select it from the list.

“Transaction Response” displays data collection by the TRANINFO table. To view the response time of a transaction on a server, select it from the list.

148

“Report Response” displays data collection by the STATINFO table. To view the response time of a user running a specific report, select it from the list. To view a list of response times experienced whilst running a report, over the time period shown in the “Report Response Time” trend, click “List Response Times”.

“Application Response” displays data collection by the APPLINFO table. To view the response time of an application on a server, select it from the list.


Appendix E: Sample PI-ProcessBook Displays

“Task Response” displays data collection by the TIMEINFO table. To view the response time of a task on a server, select it from the list.

150

Changing the Displayed SAP InstanceTo change the SAP instance that the displays represent, type the Module Database Path into the text box located at the top of each display. Press the “Refresh” button to update the display with the new instance.

Alternatively, to visually navigate to the root module, press the “…” button located between the text box and refresh button. The following dialog will be displayed:

Select the module corresponding to the desired instance and press “OK”.


Revision HistoryDate Author Comments

29-Sept-03 DC Initial draft using Skeleton version 1.12

05-Dec-03 DC Revised version 0.0.0.2

03-Mar-04 DC Added error messages.

24-Mar-04 DC Updated command-line parameters and KEY field specification in InstrumentTag.

19-May-04 DC Added Appendix D for testing function modules using SAP Front End and also added this test requirement in Installation Checklist and Appendix A for RFC error messages.

28-May-04 DC Change the version to 0.9.0.0 for pre-release beta

10-Jun-04 DC Added explanation for the RFC changes that can provide total data for RESPINFO, USERINFO, TRANINFO, APPLINFO, TIMEINFO. Updated the version of the RFCs to DEVK903015.

14-Jun-04 DC Added interface specific ICU startup command setting.

2-Sep-04 E Tam Add info on Hierarchy Builder program

12-Oct-04 DC Added installation guideline for the SAP add-on package and support package and the instruction for creating and configuring SAP user account according to the SAP certification requirements

5-Nov-04 DC Add appendix for PISAPlogon utility. Remove TABLESTAT from /OSI/MON_SYSTOPER_INFO, and delete command-line parameters: /tablestat and /tablestatnum, /setsaplogon

8-Nov-04 MPK Added section on Configuring interface with PI-ICU, updated section on Configuring Buffering with PI-ICU, made other minor modifications. Fixed headers and footers.

8-Nov-04 E Tam Cosmetic corrections to Hierarchy Builder section

11-Nov-04 DC Delete appendix for PISAPLogon utility because it is already explained in ICU section. Some minor corrections.

15-Nov-04 DC Add an appendix for RFC function specifications and an appendix for describing the sample PB display; Include PISAPLogon utility as Additional PI Software Included with Interface

15-Nov-04 E Tam Add System_Log_Count to Hierarchy Builder

16-Nov-04 DC Fix headers and footers for appendices.

17-Nov-04 MPK Version 1.0.0.0 Rev B: Changed ICU screenshots

04-Aug-05 DC Version 1.0.0.1: Recompiled interface with UniInt 4.0.0

05-Aug-05 Chrys Version 1.0.0.1: Minor formatting changes



Documents

Pi Erpperf[1]