Manual Monitoring SAP Environments

User Manual: Monitoring SAP Environments

Open the PDF directly: View PDF .
Page Count: 302

Download
Open PDF In Browser	View PDF

Monitoring SAP Environments
eG Enterprise v6

Restricted Rights Legend
The information contained in this document is confidential and subject to change without notice. No part of this
document may be reproduced or disclosed to others without the prior permission of eG Innovations Inc. eG
Innovations Inc. makes no warranty of any kind with regard to the software and documentation, including, but not
limited to, the implied warranties of merchantability and fitness for a particular purpose.
Trademarks
Microsoft Windows, Windows NT, Windows 2000, Windows 2003 and Windows 2008 are either registered trademarks
or trademarks of Microsoft Corporation in United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Copyright
©2014 eG Innovations Inc. All rights reserved.

Table of Contents
INTRODUCTION .................................................................................................................................................................................... 1
MONITORING THE SAP ABAP INSTANCE ................................................................................................................................... 2
2.1

Why Monitor the SAP AS ABAP System? ............................................................................................................................. 3

2.2

How does eG Enterprise Monitor the SAP AS ABAP System?............................................................................................. 4

2.3

The SAP Basis Layer................................................................................................................................................................. 6

2.3.1

Enqueue Status Test .......................................................................................................................................................... 7

2.3.2

R3 Buffers Test................................................................................................................................................................ 10

2.3.3

Memory Management Test ............................................................................................................................................. 20

2.3.4

Roll Page Test .................................................................................................................................................................. 23

2.4

The SAP Work Processses Layer ........................................................................................................................................... 26

2.4.1

Spool Service Test ........................................................................................................................................................... 28

2.4.2

Background Processes Test ............................................................................................................................................ 31

2.4.3

Background Services Test............................................................................................................................................... 32

2.4.4

Dialog Activity Test ........................................................................................................................................................ 34

2.4.5

Table Space Test.............................................................................................................................................................. 36

2.4.6

Database Buffer Test ....................................................................................................................................................... 38

2.4.7

Sap Group Lb Test .......................................................................................................................................................... 40

2.4.8

Sap Message Information Test ....................................................................................................................................... 42

2.4.9

Sap Messages Test........................................................................................................................................................... 43

2.4.10

Spool Processes Test ....................................................................................................................................................... 45

2.4.11

Spool requests Test.......................................................................................................................................................... 49

2.4.12

Work processes Test........................................................................................................................................................ 52

2.4.13

Update Performance Test ................................................................................................................................................ 57

2.4.14

R3 Database Log Test ..................................................................................................................................................... 59

2.4.15

Enqueue Test ................................................................................................................................................................... 63

2.4.16

Database consistency Test .............................................................................................................................................. 66

2.4.17

Update requests Test ....................................................................................................................................................... 68

2.4.18

Idoc wait monitor Test .................................................................................................................................................... 72

2.5

The SAP Workload Layer ....................................................................................................................................................... 77

2.5.1

Background jobs Test ...................................................................................................................................................... 78

2.5.2

Job statistics Test ............................................................................................................................................................. 82

2.5.3

Task Types Load Test ..................................................................................................................................................... 85

2.5.4

Transaction Load Test ..................................................................................................................................................... 98

2.6

The SAP Gateway Layer ....................................................................................................................................................... 111

2.6.1

IDoc Statistics Test........................................................................................................................................................ 111

2.6.2

qRFC Queues Test......................................................................................................................................................... 115

2.6.3

Gateways Test................................................................................................................................................................ 122

2.6.4

RFC Calls Test............................................................................................................................................................... 124

2.6.5

tRFC calls Test .............................................................................................................................................................. 126

2.6.6

Internet Communication Manager Test ....................................................................................................................... 129

2.7

The SAP Service Layer ......................................................................................................................................................... 134

2.7.1

Batch Inputs Test ........................................................................................................................................................... 135

2.7.2

Event linkages Test ....................................................................................................................................................... 141

2.7.3

R3 Dumps Test .............................................................................................................................................................. 144

2.7.4

R3 Status Messages Test ............................................................................................................................................... 146

2.7.5

Dialog Response Test .................................................................................................................................................... 148

2.7.6

R3 Connection Test ....................................................................................................................................................... 151

2.7.7

R3 Users Test................................................................................................................................................................. 153

2.7.8

R3 Log Test ................................................................................................................................................................... 155

2.7.9

Syslog errors Test .......................................................................................................................................................... 159

2.7.10

TemSe Test .................................................................................................................................................................... 162

2.7.11

CTS Monitor Test .......................................................................................................................................................... 164

2.7.12

New alerts in the last measure period .......................................................................................................................... 167

2.7.13

Performance Attributes for Monitors ........................................................................................................................... 172

2.8

The SAP Users Layer ............................................................................................................................................................ 180

2.8.1

User Load Test............................................................................................................................................................... 180

2.8.2

User logons Test ............................................................................................................................................................ 192

2.9
2.10

Viewing the SAP Alerts ........................................................................................................................................................ 195
Viewing the Performance Attribute Tree ......................................................................................................................... 199

MONITORING THE INTERNET TRANSACTION SERVER (ITS)........................................................................................ 200
3.1
3.1.1
3.2

The AGate Server layer ......................................................................................................................................................... 201
AGate Server Test ......................................................................................................................................................... 201
The AGate Service Layer ...................................................................................................................................................... 203

3.2.1

AGate Access Test ........................................................................................................................................................ 203

3.2.2

AGate Status Test .......................................................................................................................................................... 204

3.2.3

AGate Transactions Test ............................................................................................................................................... 205

MONITORING THE SAP WEB APPLICATION SERVER ....................................................................................................... 207
4.1

The SAP WAS Kernel Layer ................................................................................................................................................ 209

4.1.1

Kernel Config Test ........................................................................................................................................................ 210

4.1.2

Application Threads Test .............................................................................................................................................. 218

4.1.3

Cluster Connections Test .............................................................................................................................................. 221

4.1.4

Pool Data Aggregate Test ............................................................................................................................................. 224

4.1.5

System Threads Test ..................................................................................................................................................... 226

4.2

The Web Server Layer........................................................................................................................................................... 229

4.3

The SAP WAS Service Layer ............................................................................................................................................... 229

4.3.1

MBeans Cache Test ....................................................................................................................................................... 230

4.3.2

HTTP Connections Test ................................................................................................................................................ 232

4.3.3

HTTP Requests Test...................................................................................................................................................... 235

4.3.4

JMX Notify Queue Test ................................................................................................................................................ 237

4.3.5

Log Config Test ............................................................................................................................................................. 239

4.3.6

MBeans Register Test ................................................................................................................................................... 241

4.3.7

P4 Connections Test ...................................................................................................................................................... 243

4.3.8

P4 Usage Test ................................................................................................................................................................ 245

4.3.9

Sap WAS Beans Test .................................................................................................................................................... 247

4.3.10

Sap WAS Memory Test ................................................................................................................................................ 251

4.3.11

Sap WAS Sessions Test ................................................................................................................................................ 252

4.3.12

Sap WAS Transactions Test ......................................................................................................................................... 255

4.3.13

Timeouts Test ................................................................................................................................................................ 257

4.3.14

WasJndiRegistry Test.................................................................................................................................................... 259

4.3.15

WebContainer Test ........................................................................................................................................................ 261

MONITORING MAXDB .................................................................................................................................................................... 265
5.1
5.1.1
5.2

The MAXDB Net Layer ........................................................................................................................................................ 266
Db Connection Test ....................................................................................................................................................... 267
The MAXDB Memory Layer ............................................................................................................................................... 268

5.2.1

Db Data Area Stats Test ................................................................................................................................................ 268

5.2.2

Db Locks Test ................................................................................................................................................................ 270

5.2.3

Db Lock Waits Test....................................................................................................................................................... 273

5.2.4

Db Log Queue Test ....................................................................................................................................................... 274

5.2.5

Db Log Test ................................................................................................................................................................... 276

5.2.6

Db Oms Stats Test ......................................................................................................................................................... 278

5.3

The MAXDB Cache Layer ................................................................................................................................................... 280

5.3.1

Db Data Cache Test....................................................................................................................................................... 280

5.3.2

Db I/O Cache Test ......................................................................................................................................................... 282

5.4

The MAXDB Service Layer ................................................................................................................................................. 284

5.4.1

Db Session Cache Test .................................................................................................................................................. 285

5.4.2

Db Activity Test ............................................................................................................................................................ 287

5.4.3

Db I/O Stats Test ........................................................................................................................................................... 288

5.4.4

Db Query Test ............................................................................................................................................................... 290

5.4.5

Db Sessions Test............................................................................................................................................................ 292

CONCLUSION ..................................................................................................................................................................................... 294

Table of Figures
Figure 2.1: A SAP dual-stack system ...............................................................................................................................................................2
Figure 2.2: The structure of an ABAP application server ...................................................................................................................................3
Figure 2.3: The layer model of a SAP R/3 server ..............................................................................................................................................4
Figure 2.4: The tests associated with the R/3 Basis System layer .......................................................................................................................6
Figure 2.5: The Buffers Monitor tree-structure................................................................................................................................................ 12
Figure 2.6: Opening the SAPlogon tool .......................................................................................................................................................... 15
Figure 2.7: Clicking on the Logon button ....................................................................................................................................................... 15
Figure 2.8: Logging into the SAP Easy access console .................................................................................................................................... 16
Figure 2.9: Accessing the Client Maintenance node ........................................................................................................................................ 16
Figure 2.10: The Clients list........................................................................................................................................................................... 17
Figure 2.11: Opening the SAPlogon tool ........................................................................................................................................................ 18
Figure 2.12: Clicking on the Logon button ..................................................................................................................................................... 18
Figure 2.13: Logging into the SAP Easy access console .................................................................................................................................. 19
Figure 2.14: Navigating to the Control Panel node .......................................................................................................................................... 19
Figure 2.15: Viewing the SAP R/3 server instances......................................................................................................................................... 20
Figure 2.16: Elements of the SAP memory ..................................................................................................................................................... 24
Figure 2.17: The tests associated with the R/3 Components layer..................................................................................................................... 27
Figure 2.18: The Spool System Monitor ......................................................................................................................................................... 47
Figure 2.19: The tests mapped to the SAP Workload Layer ............................................................................................................................. 77
Figure 2.20: The tests associated with the SAP Gateway layer ....................................................................................................................... 111
Figure 2.21: The tests associated with the SAP Service layer ......................................................................................................................... 135
Figure 5.1: The detailed diagnosis of the Total number of alerts measure ....................................................................................................... 171
Figure 2.22: The detailed diagnosis of the Total number of performance attributes measure ............................................................................ 176
Figure 2.23: Selecting a system to login to.................................................................................................................................................... 177
Figure 2.24: Logging into the chosen system ................................................................................................................................................ 177
Figure 2.25: Double-clicking on the CCMS Monitor Sets sub-node ............................................................................................................... 178
Figure 2.26: Viewing the monitor sets and monitors...................................................................................................................................... 179
Figure 2.27: The tests mapped to the SAP Users layer................................................................................................................................... 180
Figure 2.28: The SAP Alerts page with the filter criteria ............................................................................................................................... 196
Figure 2.29: The SAP Alerts page displaying all alerts, regardless of status .................................................................................................... 197
Figure 2.30: The SAP Alerts page displaying only the active alerts ................................................................................................................ 198
Figure 2.31: The Metrics page ..................................................................................................................................................................... 199
Figure 3.1: The layer model of the AGate component of ITS ......................................................................................................................... 201
Figure 3.2: The tests associated with the AGate Server layer ......................................................................................................................... 201
Figure 3.3: The tests associated with the AGate Service layer ........................................................................................................................ 203
Figure 4.1: The SAP Web AS Architecture................................................................................................................................................... 207
Figure 4.2: The layer model of the SAP Web AS .......................................................................................................................................... 208
Figure 4.3: The tests associated with the SAP WAS Kernel layer................................................................................................................... 210
Figure 4.4: Determining the name and cluster ID of a server process ............................................................................................................. 214
Figure 4.5: The SAP Web Application Server ............................................................................................................................................... 215
Figure 4.6: The page showing a dispatcher ID and server ID ......................................................................................................................... 216
Figure 4.7: The instance.properties file......................................................................................................................................................... 217
Figure 4.8: The test executing on the Web Server layer ................................................................................................................................. 229
Figure 4.9: The tests associated with the SAP WAS Service layer ................................................................................................................. 230
Figure 5.2: Layer model of a MaxDB server ................................................................................................................................................. 266
Figure 5.3: The test associated with the MAXDB Net layer ........................................................................................................................... 267
Figure 5.4: The tests associated with the MAXDB Memory layer .................................................................................................................. 268
Figure 5.5: The tests associated with the MAXDB Cache layer ..................................................................................................................... 280
Figure 5.6: The tests associated with the MAXDB Service ............................................................................................................................ 285

INTRODUCTION

Introduction
'Simple' is one word that has never been used to refer to a SAP environment. In fact, with the introduction of the
SAP Enterprise architecture which comprises of multiple tiers of applications to allow for web-based access to SAP
services, IT infrastructures have become even more complex. Although it offers scalability, the SAP Enterprise
architecture makes SAP monitoring and management more challenging. In this architecture, the tight interdependencies between different tiers (web, J2EE, ABAP, database, etc.) implies that a problem in one tier can impact
the other tiers as well. Hence, a seemingly insignificant dip in the performance of one of the application tiers can
result in an administrator's worst nightmare - an infrastructure-wide slowdown! In such a scenario, the
administrator's challenge is how quickly can he/she find out where the problem is - Network? Firewall? Web/Citrix?
J2EE? ABAP instance? Database? - and resolve the problem quickly, so as to ensure high uptime.
The eG SAP monitor offers 100% web-based monitoring of every layer of each tier of the SAP environment from any
where, at any time. Be it a network router, a firewall, a SAP Internet Transaction server, a SAP ABAP instance, the
SAP Netweaver, or an Oracle database, the eG Enterprise suite includes customized models for all of these
infrastructure components. These models determine what metrics are collected, how often, how the results of the
monitoring are interpreted to provide proactive alerts, and how the metrics are correlated to determine where the
root-cause of problems lie.
This document discusses the monitoring model that eG Enterprise prescribes for each element in a typical SAP
infrastructure.

MONITORING THE SAP A BAP INSTANCE

Monitoring the SAP ABAP Instance
SAP NetWeaver is SAP's integrated technology computing platform and is the technical foundation for many SAP
applications since the SAP Business Suite. It provides the development and runtime environment for SAP applications
and can be used for custom development and integration with other applications and systems.
One of the vital components of SAP NetWeaver is its Application Platform, which is implemented by the SAP
NetWeaver Application Server (a.k.a, the SAP NetWeaver AS or the SAP NW AS).
The SAP NetWeaver Application Server can execute ABAP and/or Java programs, based on how you install the
server.
If you install the SAP Netweaver Application Server as an ABAP system, you will be able to run only ABAP programs
on that server. SAP ERP 6 is one example of a SAP business application that predominantly runs on NW AS ABAP. If
the SAP NW AS is installed as a Java system, then you will only be able to run Java programs on it. The SAP
NetWeaver Portal 7.0 application for instance, runs on NW AS Java. Alternatively, SAP NW AS can also be installed as
a dual-stack system, where both ABAP and Java programs can be run. For example, SAP PI 7.1 (Process Integration)
runs on a dual stack that includes both AS ABAP and AS Java platforms.

Figure 2.1: A SAP dual-stack system
To ensure that potential performance aberrations with the ABAP/Java systems are captured and resolved before
users complain, eG Enterprise provides two dedicated monitoring models – one for each of the installation modes of
the SAP NW AS. While the SAP ABAP Instance monitoring model focuses on the problems and performance of SAP
2

MONITORING THE SAP A BAP INSTANCE

NW AS ABAP system, the SAP WAS monitoring model focuses on the health and issues related to the SAP NW AS
Java system.
This chapter elaborately discusses the SAP NW AS ABAP system and the SAP ABAP Instance monitoring model that
corresponds to it.

2.1 Why Monitor the SAP AS ABAP System?
ABAP application servers are important software components of NetWeaver AS ABAP since all ABAP programs run on
these servers. These application servers execute ABAP applications and communicate with the presentation
components, the database, and also with each other, using the message server. The following diagram shows the
structure of an ABAP application server:

Figure 2.2: The structure of an ABAP application server
As can be inferred from Figure 2.2, a typical SAP NetWeaver ABAP framework is structured as a multi-tier
infrastructure, where the SAP GUI serves as the web front-end through which users login and place requests, the
ABAP application server serves as the middle-ware that processes the user requests and sends out responses to the
user, and a database server functions as the backend where processed data is stored for posterity.
If you zoom into the ABAP application server tier of Figure 2.2 above, you will notice that, in addition to several work
processes, the ABAP application server contains a dispatcher, a gateway and the shared memory. The tasks of these
components are briefly described in the following:
Work Processes: Work processes are components that are able to execute an application (that is,
one dialog step each). Each work process is linked to a memory area containing the context of the
application being run. The context contains the current data for the application program. This needs
to be available in each dialog step.
Dispatcher: The dispatcher is the link between the work processes and the users logged onto the
ABAP application server (that is, the SAP GUIs of theseusers). Its task is to receive requests for dialog
3

MONITORING THE SAP A BAP INSTANCE

steps from the SAP GUI and direct them to a free work process. In the same way, it directs screen
output resulting from the dialog step back to the appropriate user.
Gateway: This is the interface for the communication protocols of NetWeaver AS ABAP (RFC,
CPI/C). It can communicate with other ABAP application servers of the same NW AS, with other SAP
Systems, or with external non-SAP systems.
Shared Memory: All of the work processes on an ABAP application server use a common main
memory area called shared memory to save contexts or to buffer constant data locally. The resources
that all work processes use (such as programs and table contents) are contained in shared memory

Since these components are closely inter-related to each other, the problem in any one component can adversely
impact the performance of the other components, ultimately delaying the access to and the execution of ABAP
applications running on the AS ABAP application server. SAP administrators are therefore faced with the challenge of
not just proactively detecting such a slowdown, but also quickly and accurately diagnosing the reason for the same –
is it because the dispatcher is unavailable? is it because the gateway has failed? Is it owing to the lack of free work
processes? or is due to poor memory management by the ABAP system? This is where eG’s SAP AS ABAP Instance
monitoring model (see Figure 2.2) helps!

Figure 2.3: The layer model of a SAP R/3 server
This model determines what metrics are collected, how often, how the results of the monitoring are interpreted to
provide proactive alerts, and how the metrics are correlated to determine where the root-cause of problems lie.

2.2 How does eG Enterprise Monitor the SAP AS ABAP
System?
To collect the metrics, this SAP AS ABAP Instance model takes advantage of the CCMS SAP monitoring architecture.
Using SAP's CCMS interfaces, eG agents collect and report on hundreds of performance and availability metrics of all
the components of the SAP NW AS ABAP system - from the host operating system, to the network, to the critical SAP
processes, the SAP database, SAP background jobs, SAP users, trasactions, etc.
4

MONITORING THE SAP A BAP INSTANCE

The metrics so collected enable SAP administrators to find answers to queries that have for long hounded SAP ABAP
administrators:
SAP Service
Monitoring

Network & System
Monitoring

Web Application
Server Monitoring

SAP R/3 Server
Monitoring

SAP R/3 Database
Monitoring

Monitoring SAP R/3
Alerts

Monitoring
Performance
Attributes of the SAP
R/3 Server



Is the SAP service working well? What are the response times? Is any step
slowing down the entire service interaction?



Are the critical application processes running? What is their resource usage?



How is the network performance impacting the overall service performance?



Are the servers properly sized in terms of CPU, memory, disk activity, etc.?



Are there any critical alerts in the system event logs?



How many sessions are currently being handled by the SAP web/application
server, and are there sufficient processes configured to handle the load?



Is the workload properly balanced across SAP web application server
instances?



What is the processing time of critical transactions on the server?



Were there any errors while connecting to the R/3 server?



Is the application server’s memory adequately sized? Is the free memory too
low?



Are the buffers of the SAP R/3 server sized appropriately? Are there unusually
high swap ins/outs?



How many requests are queued waiting for free worker processes or data
locks?



What jobs are executing on the server ? Is the server adequately configured to
handle the load?



What time of day/day of week is the server activity at its peak and what jobs
are executing then?



Are there sufficient dialog processes configured to handle incoming user
requests?



Are there any ABAP dumps happening, indicating errors in the R/3 system?



Is the SAP R/3 database accessible? How are the critical cache hit ratios of the
database server?



Are any of the database tablespaces reaching capacity?



How many alerts have been raised on the SAP R/3 server? Are too many alerts
active?



Have too many red and yellow alerts been raised on the SAP R/3 server?



Have any alerts auto-completed?



How many performance attributes are available for each of the configured
monitors?



Does any monitor have too many red and yellow performance attributes? If so,
which monitor is this?



Which monitor has inactive performance attributes?

MONITORING THE SAP A BAP INSTANCE

This chapter will discuss the top 6 layers of the layer model depicted by Figure 2.2, as all the other layers have been
discussed in the Monitoring Unix and Windows Servers document.

2.3 The SAP Basis Layer
Using the tests depicted in Figure 2.4.3, administrators can assess the efficiency with which the SAP NW AS ABAP
system manages its memory resources.

Figure 2.4: The tests associated with the R/3 Basis System layer

MONITORING THE SAP A BAP INSTANCE

2.3.1

Enqueue Status Test

The Enqueue service allows ABAP applications to lock data so that only they can use it. The locking of the data
avoids parallel changes to the data, which would lead to data inconsistency. The enqueue work process is in charge
of the lock management system. It allows multiple application servers to synchronize their access to the database
and maintain data consistency. The locks are managed by the enqueue work process using a lock table that resides
in the main memory. The enqueue work process sets an SAP lock by writing entries in the lock table; but prior to
that, the enqueue work process checks the lock table to determine whether/not the requested lock object is already
locked, and if locked, what type of lock is active on the object.
While SAP supports many types of locks, from a performance perspective, the following types are most critical:
Exclusive: Exclusive locks are used to avoid parallel modification of the data, which means that
exclusively locked data can be displayed or modified by only one user.
Exclusive but not cumulative: Locks of this type can be called only once. So a lock request will be
rejected if an exclusive lock already exists.
Too many exclusive locks held for long durations can be detrimental to SAP system performance, as they can
block users from updating critical transactions. This is why, SAP administrators need to keep track of such locks,
promptly detect unreleased locks, and figure out the reasons for the same. To enable this lock analysis, eG
Enterprise provides the Enqueue Status test. For each exclusive lock type (i.e., exclusive and exclusive but not
cumulative), this test reports the number of locks of that type for which entries exist in the lock table and the
number of locks that have remained active over different time periods ranging from 1 hour to over 1 day. In the
process, the test points administrators to those lock types that were unreleased for significantly long time
windows, thus impacting SAP system performance. Detailed metrics provided by the test will lead administrators
straight to the exact locks that were held for broad time frames and the user who held them!

Purpose

For each exclusive lock type (i.e., exclusive and exclusive but not cumulative), this test
reports the number of locks of that type for which entries exist in the lock table and the
number of locks that have remained active over different time periods ranging from 1 hour
to over 1 day. In the process, the test points administrators to those lock types that were
unreleased for significantly long time windows, thus impacting SAP system performance.
Detailed metrics provided by the test will lead administrators straight to the exact locks that
were held for broad time frames and the user who held them!

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.

MONITORING THE SAP A BAP INSTANCE

14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.
15. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for each exclusive lock type and one set of results for an All descriptor that
reports aggregated performance results across all lock types

Measurement

Number of locks:

Measurement
Unit
Number

A low value is desired for this measure.
Compare the value of this measure
across lock types to know which lock
type contains the maximum number of
locks.

Percent

A low value is desired for both exclusive lock
types. A high value indicates that a majority
of the locks are exclusive locks, which is a
cause for concern.

Number

Normally, locks are automatically released
when transactions are committed or when
users finish working on the data. If locks
remain unreleased for long time periods, it
may not always be a cause for alarm, as it
may be owing to something as routine as
long-running background jobs that update
the database. Some other times, unreleased
locks can cause serious performance issues
to the SAP system.

Indicates the number of locks
of this type currently held.

Percentage of locks:
Indicates the percentage of
total locks currently held that
are of this type.
5 mins to 1 hour locks:
Indicates the number of locks
of this type that were held for
a duration between 5 minutes
to 1 hour.
1 hour to 1 day locks:

Number

Indicates the number of locks
of this type that were held for
a duration between 1 hour to
1 day.
Locks older than 1 day:

Interpretation

Number

Indicates the number of locks
of this type that were held for
over a day.

This is why, high values reported by any of
these measures cannot be ignored. In such
situations, it is best to immediately
investigate the reason why locks were held
for such a long duration. To know which
precise locks were unreleased by which user
and why, use the detailed diagnosis of this
measure.

MONITORING THE SAP A BAP INSTANCE

Some of the most common reasons for
unreleased locks are as follows:
Abnormal termination of the SAP
GUI: If users shut down their PCs
without logging off SAP, or if the
SAP GUI terminates for other
reasons, such as network or
communication problems, the user
session may remain active in the
SAP system. If this happens while
the user had lock entries, sometimes
these locks remain unreleased since
the user is no longer active in the
system. In these cases, you can
manually release the lock by
deleting it from the lock entry list, or
you can force log off the user from
the User Overview Monitor in the
application server where the user
was logged on.
Inactive SAP GUI: When users
currently working on the system
leave their presentation services
with unfinished transactions, locks
will not be released. You can release
such locks by deleting them from
the lock entry list, but only after
confirming that they are not coming
from important background jobs.
Problems in update processing:
When there are update modules
that are unprocessed by the syste,
these modules do not release the
locks. The update module releases
the locks only when the update
records have been completely
processed or they have abnormally
terminated with an error status.
Only update modules with status
INIT or AUTO can hold locks.

2.3.2

R3 Buffers Test

This test reports statistics relating to the SAP R/3 server's buffers. The goal of buffer setting is to have a sufficiently
large buffer to maintain a high hit rate and to do so with a low rate of swapping and a minimal effect on operating
system paging. The test contains values for the following SAP buffers, sorted by application server:
10

MONITORING THE SAP A BAP INSTANCE

Name of the MTE

Contents of the Buffer

Program

Compiled SAP programs

Generic Key

Wholly or partly buffered database tables

SingleRecord

Individual records from utilized database tables

Screen

Screen pages from ABAP programs

CUA

Menus and pushbuttons from the ABAP screen pages

TableDefinition

Table Definitions from the SAP R/3 Repository

FieldDescription

Field descriptions from the SAP R/3 Repository

InitialRecords

Initial record layout (initial values for the fields of a database
segment) for a table

ShortNameTAB

Combination of TTAB and FTAB buffers

In the table above, the term MTE stands for a Monitoring Tree Element. According to the SAP monitoring
architecture, every SAP component/sub-system requiring monitoring, such as the buffer system, the dialog system,
background processing etc., is termed as a Monitor. Each of these Monitors and their respective attributes are
organized in the form of a tree-structure known as the monitoring tree, where the Monitor itself will be the pivotal
node, and its key attributes the sub-nodes. Each of these attributes is otherwise referred to as a monitoring tree
element (MTE).
Figure 2.5 depicts the tree-structure of the Buffers Monitor. From this figure it can be inferred that the name of the
monitor, Buffers, is the primary node of the monitoring tree. Each of the buffer types, which are the sub-nodes of
Buffers, will therefore become MTEs. Similarly, the attributes such as DirectoryUsed, SpaceUsed, etc., that are
associated with every buffer type, also become MTEs. The eG agent executing the R3BufferTest reports the values of
these attributes only.

MONITORING THE SAP A BAP INSTANCE

Figure 2.5: The Buffers Monitor tree-structure

Purpose

Reports statistics relating to the SAP R/3 server's buffers

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every MTE

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Directory entries used:

Percent

The buffer directories point to the location of
the objects stored in the buffer. If one runs
out of directory entries , then no new objects
can be placed in the buffer, and the free
space cannot be used.

Percent

If the buffer size is less, then for many
requests the buffer cannot be used leading
to more swapping; therefore, the buffer size
has to be increased.

Percent

In general, poor buffer quality means that a
buffer is too small. If a buffer is too small,
then the chances increase that requested
objects (table entries, programs, and so on)
will not be found in it. The result is a lower
hit ratio, and, if the buffer is already full,
increased swapping.

The percentage usage of the
directory (number of entries)

Buffer space used:
The percentage of buffer
storage space been used
currently.
Hit ratio:
The percentage of database
queries that were met from
the buffer.

To improve the hit ratio, increase the size of
a buffer.
Buffer swaps:

Swaps/Min

The rate of swaps due to a
filled buffer.

Swapping increases as requested objects
force older objects out of the buffer.
Increase the size of the buffer if the swap
rate is very high and the hit ratio is low.

In order to extract metrics from within a SAP R/3 server, the SAP tests need to login to the server as a valid SAP
client. To achieve this, the tests take the CLIENTNAME as one of the parameters. As a SAP R/3 server can support
multiple clients, it is essential to determine which client you want a test to login as. Therefore, take a look at the list
of clients supported by the R/3 server being monitored, before specifying a CLIENTNAME. To do so, follow the
steps given below:
1.

From any SAP client, execute the SAPlogon tool using the menu sequence: Start -> Programs -> SAP Front End
-> SAPlogon (see Figure 2.6).

MONITORING THE SAP A BAP INSTANCE

Figure 2.6: Opening the SAPlogon tool
2.

Click on the Logon button in the dialog box that appears (see Figure 2.7), and login to the SAP R/3 server using
a valid user name and password (see Figure 2.8).

Figure 2.7: Clicking on the Logon button

MONITORING THE SAP A BAP INSTANCE

Figure 2.8: Logging into the SAP Easy access console
3.

Using the tree-structure in the SAP Easy Access console that appears (see Figure 2.9), navigate to the Client
Maintenance node. The node sequence to be used is: SAP menu -> Tools -> Administration -> Client
Administration -> Client Maintenance.

Figure 2.9: Accessing the Client Maintenance node
4.

Double-click on the Client Maintenance node in Figure 2.9.

A Display View "Clients" page will appear (see Figure 2.10), which will display the details of SAP clients. Any of
16

MONITORING THE SAP A BAP INSTANCE

the values of the Client column in this page, can be provided as the CLIENTNAME.

Figure 2.10: The Clients list

The eG agent connects to a particular instance of the SAP R/3 server to collect the desired metrics. To enable this
connection, all the SAP R/3 tests need to be configured with the name of the R/3 instance to connect to. For this
purpose, the SAP R/3 tests take an INSTANCENAME parameter. Before providing a value for this parameter, you
may want to take a look at all the instances currently configured on the R/3 server, so that you can decide which
instance name should be configured for the test. For this purpose, do the following:
1. From any SAP client, execute the SAPlogon tool using the menu sequence: Start -> Programs -> SAP Front
End -> SAPlogon (see Figure 2.6).

MONITORING THE SAP A BAP INSTANCE

Figure 2.11: Opening the SAPlogon tool
6.

Click on the Logon button in the dialog box that appears (see Figure 2.7), and login to the SAP R/3 server using
a valid user name and password (see Figure 2.8).

Figure 2.12: Clicking on the Logon button

MONITORING THE SAP A BAP INSTANCE

Figure 2.13: Logging into the SAP Easy access console
7.

In the tree-structure of the SAP Easy Access console that appears (see Figure 2.9), follow the node sequence:
SAP menu -> Tools ->CCMS->Control/Monitoring->Control Panel.

Figure 2.14: Navigating to the Control Panel node
8.

Double-click on the Control Panel node. A Display Server Statuses and Alerts page will appear, which will
display the details of the SAP servers. Any of the values of the Server Name column in this page can be
19

MONITORING THE SAP A BAP INSTANCE

provided as the value of the INSTANCENAME parameter.

Figure 2.15: Viewing the SAP R/3 server instances

2.3.3

Memory Management Test

This test monitors the basic functions of the SAP Memory Management System and advises on how best to configure
the system depending upon the platform used, the available resources, etc. It also sheds light on the hardware and
operating system usage.

Purpose

Monitors the basic functions of the SAP Memory Management System

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement
Unit

Measurement
Heap
memory
allocation:

total

The total size of heap
memory (private memory).

Interpretation

MONITORING THE SAP A BAP INSTANCE

Heap memory peak use:

Percent

A high watermark of heap
memory usage.
Heap memory recent peak
use:

Percent

The peak usage of heap
memory in recent times.
Heap
memory
usage:

actual

The percentage of
memory actually used.
Extended
allocated:

Percent

heap

memory

Indicates the total size of the
extended memory.
Extended
use:

memory peak

Percent

The high watermark of the
stack memory usage since
startup.
Extended
peak use:

memory

rec

Percent

Indicates the peak usage
achieved in the recent period
for extended memory.
High extended
usage:

memory

Percent

The actual usage of extended
memory.
High extended
attached:

memory

Percent

The percentage of extended
memory in user contexts that
is active in WPs now.
Number
of
memory slots:
The number
memory slots.

extended
of

Number

extended

MONITORING THE SAP A BAP INSTANCE

Extended
peak use:

memory

slot

Percent

Indicates the peak usage of
the extended memory slots.
Extended memory slot rec
peak use:

Percent

The peak usage of the
extended memory slots in
recent times.
Usage
of
memory slots:

extended

Percent

The percentage of extended
memory slots actually used.
Private work processes:

Number

The number of restarted
private work processes.
Dialog work
restarted:
The number of
dialog processes.

processes

Number

restarted

Non-dialog work process
restarts:

Number

The number of non-dialog
processes restarted.

2.3.4

Roll Page Test

Roll area and Paging area are two very important concepts of memory management. Roll area is a memory area with
a set size that belongs to a work process. It is located in the heap of the virtual address space of the work process.
Disk area (swap space) is used as an extension of the physical memory for temporary storage. When SAP tries to
keep track of processes requiring more physical memory than available, then data is moved to and from the swap
space. If only segments of the processes are so copied, it is called paging.
Figure 2.16 depicts the elements of the SAP memory.

MONITORING THE SAP A BAP INSTANCE

Figure 2.16: Elements of the SAP memory
This test extracts statistics specific to these two memory concepts.

Purpose

Extracts statistics specific to the roll area and paging area

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Paging area used:

Percent

Paging utilizes CPU resources, performs disk
reads / writes, and hence is considered an
expensive operation. However, paging itself
occurs only when the memory is low.
Therefore, if more paging area is used, it
means one has to kill some processes or
increase physical memory size.

Percent

When the context of a work process changes,
the data is copied from the roll area to a
common resource called the roll file. First the
process tries to occupy the roll area of the
memory. When roll area is full, extended
memory is used up by the process.

The percentage utilization of
the swap space (paging
area).

Roll area used:
The percentage of roll area
that has been used.

The default value is specified in transaction
RZ11, and is determined dynamically.
Roll area should not be changed manually.
If one has to still to make changes on one's
platform, keep in mind the following
dependencies:

 rdisp/ROLL_SHM should be
adjusted if ztta/roll_area is
changed.

 rdisp/ROLL_MAXFS must be
adjusted if ztta/roll_area is
changed.

 ztta/roll_area

must
be
larger than, or the same
size as ztta/roll_first.

2.4 The SAP Work Processses Layer
Numerous services execute on the R/3 server, each of which is crucial to its smooth functioning. The tests associated
with the R/3 Components layer (see Figure 2.17) monitor these critical services and report performance issues in their
operations (if any).

MONITORING THE SAP A BAP INSTANCE

Figure 2.17: The tests associated with the R/3 Components layer

MONITORING THE SAP A BAP INSTANCE

2.4.1

Spool Service Test

The Spool Service monitoring object contains the most important attributes about the spool system. This test
monitors the functioning of the spool system, and reports the extent of its utilization, the length of the wait queues,
etc.

Purpose

Monitors the functioning of the spool system, and reports the extent of its utilization, the length
of the wait queues, etc.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement
Utilization of the spool
work processes:

Measurement
Unit
Percent

The percentage utilization of
the spool work processes.

Interpretation

MONITORING THE SAP A BAP INSTANCE

Spool work processes:

Percent

Output requests are buffered in the
dispatcher queue on the spool server until a
free work process accepts them. A high value
for this measure therefore, indicates the nonavailability of idle work processes for
servicing the output requests in the
dispatcher queue. This, in turn, could be due
to a heavy workload on the spool server.

Percent

The spool requests queue takes output
requests from the dispatcher queue when a
free work process in the spool server accepts
the output request. A high value here, once
again indicates a heavy workload on the
server, due to which very few work processes
are free to accept the enqueued output
requests.

Percent

If a spool server has several spool work
processes, output requests can overtake each
other. To maintain the sequence of requests,
there are special work process-specific
request queues, each with requests for one
particular output device.

The number of spool work
processes.

Requests in the
service queue:

spool

The percentage of space in
the spool requests queue that
has been utilized.

Requests
in
processspecific request queues:
The percentage of space
being utilized in the special
spool request queues for
processing
requests
in
sequence.
Pages in spool requests
queue:

Number

The number of pages in the
spool requests queue.
Device cache used:

Percent

The device cache contains device definitions
and sever assignments for all work processes.
Entries are taken into the cache as required,
and can be removed again if the cache
becomes full.

Percent

The fixed device cache contains information
about the output devices for which there are
requests in the host spool system that have
not yet been reported as finished. The cache
must therefore contain at least as many
entries as the number of devices that can be
concurrently used.

Percent

The host spool requests limit the number of
requests in the host spool which can be
managed with the spool service. To minimize
database accesses, the list must be stored in
shared memory. It deals with status queries
for the current requests.

The percentage of the device
cache in use.

Fixed device cache area
used:
The percentage of space in
the fixed device cache that is
currently in use.

Host spool requests list
used:
The percentage of space in
the host spool requests list in
use.

MONITORING THE SAP A BAP INSTANCE

2.4.2

Background Processes Test

This test measures the extent of usage of the background processes.

Purpose

Measures the extent of usage of the background processes

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every background server of the SAP R/3 server being monitored

Measurement

Utilization of background
work processes:

Measurement
Unit
Percent

This measure and the System wide queue
length measure (of the BackgroundService
test) show if there is a serious bottleneck in
the background processing capacity. The
optimal situation is to maintain a high level of
utilization of the work processes and a short
wait queue.

Number

It does not make sense to have more than 23 work processes per CPU on a background
server, as these work processes will already
be fully utilizing the CPU. Set the number of
these processes using the system parameter
rdisp/wp_no_btc.

Jobs

An alert for this measure when there is a
short System wide queue length suggests
that the distribution of jobs is not optimal.
Only specify a target server if it is absolutely
necessary.

The percentage of the
background
processing
capacity currently utilized.
The value is averaged over
the
background
work
processes and by default,
averaged over the last hour.
Running
processes:

background

The number of background
work processes running on an
application server.
Server queue length:
The number of released jobs
that are explicitly to be
executed on this application
server, but for which there
are no free background work
processes.

2.4.3

Interpretation

Background Services Test

This test monitors the background services that are key to the smooth functioning of background processes.

Purpose

Monitors the background services that are key to the smooth functioning of background
processes

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

System
length:

wide

queue

Number

The number of jobs that are
waiting for free background
processes for their execution.
System
wide
free
background processes:

Background jobs are usually defined without
a target server specification. This ensures
optimal distribution of the workload from the
jobs. This attribute is the best for showing
capacity problems in background processing.
A short wait queue is the optimal situation.

Number

The
number
of
free
background work processes
in the entire system.
System wide
processes:

class

Number

The number of class A
background processes in the
entire system.

2.4.4

Dialog Activity Test

The Dialog service is the one which responds to the user requests to an R/3 server. This test reports performance
statistics pertaining to the Dialog service of the R/3 server.

Purpose

Reports performance statistics pertaining to the Dialog service of the R/3 server

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server.
To view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for
a server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port
is 3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

10.

INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view
the complete list of instances to choose from, do the follow the procedure discussed in
Page 17 of this document.

11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a
response from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query
the metrics, you need to specify the version of the SAP JCO library that the agent needs to
use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you
specify the ‘major version number’ alone against JCO VERSION – in the case of this
example, this will be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Utilization of the dialog
processes:

Percent

The percentage utilization of
the dialog work processes of
an application server.
Dialog work processes:

Number

The number of dialog work
processes.
Dispatcher
length:

wait

queue

Percent

With normal workload, this value is around
0%. A long wait queue is a sign that the
application server has too few work
processes or too high a CPU workload.

Secs

Long-running tasks can block other users'
dialog steps and can produce a general
degradation of dialog response time for
interactive users. Resolving this problem
requires analysis of long-running dialog steps.
Corrective measures include moving users to
another application server, asking users to
schedule long-running reports or other
actions as background jobs in off-peak time
periods, etc.

Steps/min

A high value combined with a high Dialog
process time points to a general overload; a
very low value, indicates an error.

The percentage utilization of
the dispatcher wait queue.
Long runners:
Indicates how long the longrunning dialog processes
have been running.

Dialog steps:
The number of dialog steps
per minute.
Users logged in:

Number

The number of users logged
in.

2.4.5

Table Space Test

This test monitors the database tablespaces.

Purpose

Monitors the database tablespaces

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

Outputs of the
test
Measurements
made by the
test

One set of results for every tablespace on the database

Measurement
Space free:

Measurement
Unit
MB

The amount of free space in
the database tablespaces.

Interpretation

MONITORING THE SAP A BAP INSTANCE

Space used:

Percent

The percentage of used up
area
of
the
various
tablespaces in the database.

2.4.6

Database Buffer Test

This test reports statistics pertaining to the buffer cache for database operations.

Purpose

Reports statistics pertaining to the buffer cache for database operations

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Buffer cache hit ratio:

Percent

Physical I/O takes significant amount of time
and also increases CPU resources required.
The database configuration should be tuned
to ensure that a required block will be most
likely in memory. The extent to which this is
achieved is measured using this measure.
Ratio should be 80% or higher. A lower value
indicates insufficient memory allocation to the
database buffer cache.

Percent

For a well-tuned database, this ratio is 90%.
A lower hit ratio may indicate that the
memory allocation to the library cache is
insufficient. A low value can degrade the
database performance.

Number

The changes made to the database are first
written to the redo log buffer. The database
then periodically writes batches of the redo
entries to the online redo log files. The lesser
the number of entries in the Redo Buffer, the
lesser the database changes are reflected in
the buffer. Therefore, there will be higher
disk reads and system performance will
decrease.

The percentage of time the
database server is able to
satisfy a request directly from
the cache.

Library cache hit ratio:
Library cache is a buffer that
contains the shared SQL and
PL/SQL areas. The library
cache hit ratio indicates the
percentage of shared SQL
statements being reparsed.
Redo log buffer entries:
The number of entries in the
redo log buffer describing
changes
made
to
the
database.

2.4.7

Sap Group Lb Test

The Sap Group Lb test automatically discovers the logon groups on a SAP message server, and monitors the status of
load balancing on each of the SAP R/3 application server(s) associated with a logon group.

Purpose

Monitors the status of load balancing on each of the SAP R/3 application server(s) associated
with a logon group

Target of the
test

The SAP Messaging server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

MESSAGEPORT - Specify the port number of the SAP Message server.

LIBRARY PATH - This test uses an lgtst command to extract critical statistics from the SAP
Message server. Specify the full path to the library files used in the execution of the lgtst
command.

COMMAND PATH - Specify the full path to the lgtst executable in the COMMAND PATH
text box.

Note:
The MESSAGEPORT, LIBRARYPATH and
applicable only to non-windows platforms.

Outputs of the
test
Measurements
made by the
test

COMMANDPATH

parameters

are

COUNT - Specify the number of SAP R/3 servers to be polled by the lgtst command, so as
to determine whether load balancing has been enabled on the R/3 server or not.

ISPASSIVE - If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

One set of results for every logon group discovered

Measurement
Unit

Measurement

Number
servers:

unique

Interpretation

Number

Indicates the number of
distinct application servers
that
are
currently
communicating under the
same group through the
Message Server.
Load balanced:

Percent

Indicates whether the SAP
logon group is load-balanced
or not.

If the value of this measure is 0, it means
that load-balancing is not enabled for the
logon group. The client's request will be
served by the dialog server which has first
taken up the request. The value 100 indicates
that the logon group is load-balanced.

MONITORING THE SAP A BAP INSTANCE

Note:

 This test uses an lgtst command to extract critical statistics from the SAP Message
server. With this command, you can check the active instances of your SAP System
and check existing logon groups directly at the operating system level. To ensure that
this test functions smoothly, the lgtst command needs to be copied to the
/opt/egurkha/bin directory (on Unix, or the \bin on Windows).

 Another pre-requisite for the smooth execution of this test is that, in the transaction
SMLG, the External RFC Permitted attribute will have to be defined for any one of the
logon groups on the SAP Message server.

2.4.8

Sap Message Information Test

The Sap Message Information test reveals whether the connection between the SAP R/3 server and the SAP
Messaging server is available or not.

Purpose

Reveals whether the connection between the SAP R/3 server and the SAP Messaging server is
available or not

Target of the
test

The SAP Messaging server

Agent
deploying the
test

An internal/external/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

MESSAGEPORT - Specify the port number of the SAP Message server.

LIBRARY PATH - This test uses an lgtst command to extract critical statistics from the SAP
Message server. Specify the full path to the library files used in the execution of the lgtst
command.

COMMAND PATH - Specify the full path to the lgtst executable in the COMMAND PATH
text box.

Note:
The MESSAGEPORT, LIBRARYPATH and
applicable only to non-windows platforms.
7.

Outputs of the
test

COMMANDPATH

parameters

are

One set of results for the SAP R/3 server being monitored

MONITORING THE SAP A BAP INSTANCE

Measurements
made by the
test

Measurement
Availability:

Measurement
Unit
Percent

Indicates whether a SAP R/3
application server is currently
available for communicating
with a SAP Message server.

Interpretation
If the value of this measure is 0, it means
that the R/3 application server can no longer
communicate with other R/3 servers
(especially if central instance and dialog
instance are installed in separate systems).
The value 100 indicates the availability of the
R/3 application server.

Note:

2.4.9

Sap Messages Test

The Sap Messages test reports the number of SAP R/3 servers that are communicating with the SAP Messaging
server.

Purpose

Reports the number of SAP R/3 servers that are communicating with the SAP Messaging server

Target of the
test

The SAP Messaging server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

MESSAGEPORT - Specify the port number of the SAP Message server.

LIBRARY PATH - This test uses an lgtst command to extract critical statistics from the SAP
Message server. Specify the full path to the library files used in the execution of the lgtst
command.

COMMAND PATH - Specify the full path to the lgtst executable in the COMMAND PATH
text box.

Note:
The MESSAGEPORT, LIBRARYPATH and
applicable only to non-windows platforms.

COMMANDPATH

parameters

are

DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for the SAP R/3 server being monitored

Measurement

Reachable
servers:

application

Measurement
Unit
Number

Indicates the number of
application servers that are
currently communicating with
the SAP Message server.

Interpretation

MONITORING THE SAP A BAP INSTANCE

Note:

2.4.10

Spool Processes Test

This test reports measures pertaining to the different request processing groups. For classification of the output
requests, we recommend that you assign both the spool servers and the output devices to different classes. By
having different spool servers that process different types (and priorities) of requests you can avoid, or at least
control, mutual obstruction of output requests. The Processing Groups MTE contains the possible processing groups:
MTE
ProcessingGroup Adm

Description
Spool administration

Notes
Examples:

tasks

Activation of delayed requests
Deletion of obsolete requests
Rerouting of requests in the case of
server failure

ProcessingGroup Reg

Normal requests

Normal requests are requests to devices that are
assigned to a spool server

ProcessingGroup Fro

Requests for front end
output devices

Front end output devices are defined by the user
at operating system level. In the R/3 system,
there must be only one output device with the
access method F (front end) which sends output
requests to the user's standard printer.

ProcessingGroup Vol

Requests classified as
mass printing

Mass printing means very large requests. Assign
these requests to a separate spool server, to
avoid the obstruction of other output requests.

ProcessingGroup Pro

Requests classified as

Assign the output requests that are required for

MONITORING THE SAP A BAP INSTANCE

ProcessingGroup Dsk

production printing

trouble free productive operation
production printing processing group.

the

Requests classified as
desktop printing

Assign printers at one's workspace to the desktop
printing processing group. As they are often not
available, they could obstruct other tasks. Do not
use this group for routine operations.

ProcessingGroup Tst

Requests classified as

Assign output devices which are a new device

test printing

type or for which configuration is being tested to
the test printing processing group.

In the table above, the term MTE stands for a Monitoring Tree Element. According to the SAP monitoring
architecture, every SAP component/sub-system requiring monitoring, such as the buffer system, the dialog system,
background processing etc., is termed as a Monitor. Each of these Monitors and their respective attributes are
organized in the form of a tree-structure known as the monitoring tree, where the Monitor itself will be the pivotal
node, and its key attributes the sub-nodes. Each of these attributes is otherwise referred to as a monitoring tree
element (MTE).
Figure 2.18 depicts the tree-structure of the Spool System Monitor. From this figure it can be inferred that the
monitor, Spool System, is the primary node of the monitoring tree. One of the sub-nodes of this monitor is
Processing Groups. This sub-node and each of the nodes within (i.e., the individual processing groups and their
attributes) will therefore become individual MTEs of the Spool System Monitor. The eG agent executing the
SpoolProcessTest extracts the values of the key attributes of each of the processing groups.

MONITORING THE SAP A BAP INSTANCE

Figure 2.18: The Spool System Monitor

Purpose

Reports measures pertaining to the different request processing groups

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server.
To view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for
a server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port
is 3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

10.

INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view
the complete list of instances to choose from, do the follow the procedure discussed in
Page 17 of this document.

11. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query
the metrics, you need to specify the version of the SAP JCO library that the agent needs to
use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you
specify the ‘major version number’ alone against JCO VERSION – in the case of this
example, this will be 2.x.
12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a
response from the SAP R/3 server. By default, this is set to 120 seconds.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every processing group on a SAP R/3 server

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Group work processes:

Number

The number of group spool
work processes.
Group jobs:

Number

The number of group spool
requests.
Group pages:

Number

Peak usage achieved in the
recent period for stack
memory.

2.4.11

Spool requests Test

The SAP System differentiates between two types of request when printing:


Spool request: A spool request is a document for which a print function has been selected. However, it
has not yet been output to a printer or another device. The output data for the print document is stored
partly formatted in a data store until an output request is created, that is, until it is sent to a particular
output device.
The spool system uses a spool request to store the print data temporarily and to access it. The data is
stored in a temporary format. You can also display the print document.
The system automatically assigns a 10-digit ID number to a spool request.



Output request: From the point of view of the SAP spool system, an output request outputs the print
data of a spool request to a particular output device.
Multiple output requests may exist for a single spool request. Each represents an instance of the output of
the same spool request. Each of these output requests may have different attributes, such as the target
printer or number of copies.
By differentiating between spool request and output requests, the spool system provides a means of
storing the data temporarily.

This test monitors the spool requests of the target SAP ABAP instance and reports how many spool requests were
created? Using this test, administrators may figure out how many spool requests were error prone. Apart from this,
you can figure out the number of output problems and output errors encountered by the output requests for a
corresponding spool request. This way, administrators may figure out what exactly caused the errors while
processing the spool requests and when exactly were the errors at their peak!

Purpose

Monitors the spool requests of the target SAP ABAP instance and reports how many spool
requests were created? Using this test, administrators may figure out how many spool requests
were error prone? Apart from this, you can figure out the number of output problems and
output errors encountered by the output requests for a corresponding spool request. This way,
administrators may figure out what exactly caused the errors while processing the spool
requests and when exactly were the errors at their peak!

Target of the

A SAP R/3 server
49

MONITORING THE SAP A BAP INSTANCE

test
Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view
the complete list of instances to choose from, do the follow the procedure discussed in Page
17 of this document.
11. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
14. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.

MONITORING THE SAP A BAP INSTANCE

15. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every processing group on a SAP R/3 server

Measurement
Unit

Measurement

Spool requests:

Requests

Indicates the number of spool
requests created during the
last measurement period.
Spool request rate:

Interpretation

These measures are a good indicator of the
load on the spool system.

Requests/sec

Indicates the rate at which
spool requests were created
during the last measurement
period.
Total number
errors:

spool

Requests

Ideally, the value of this measure should be
zero.

Requests/sec

A sudden/gradual increase in the value of this
measure indicates that the overall spool
system is error prone.

Requests

These output problems are encountered
while executing the output requests
corresponding a spool request. However, you
can infer that there was an output for the
request but problems were encountered
during printing.

Indicates the total number of
outstanding spool requests
with errors.
Spool error rate:
Indicates the rate of spool
requests with errors during
the last measurement period.
Total number of output
problems:
Indicates the number of
output problems encountered
by the output requests for a
corresponding spool request.

MONITORING THE SAP A BAP INSTANCE

Rate of output problems:

Requests/sec

A sudden/gradual increase in the value of this
measure indicates issues with output device
connectivity or printing issues.

Requests

The output errors occur when there is no
output for a particular output request.

Requests/sec

A sudden/gradual increase in the value of this
measure indicates issues with output device
connectivity or printing issues.

Requests

Ideally, the value of this measure should be
zero.

Indicates the rate at which
output
problems
were
encountered by the output
requests.
Total number of output
errors:
Indicates the number of
output errors encountered by
the output requests for a
corresponding spool request.
Rate of output errors:
Indicates the rate at which
the output errors were
encountered by the output
requests during the last
measurement period.
New spool errors:
Indicates the number of spool
requests with errors during
the last measurement period.

New output problems:

The detailed diagnosis of this measure if
enabled,
lists
the
request
number,
corresponding output request status, title,
output device, timestamp etc.,
Requests

The detailed diagnosis of this measure if
enabled, lists the spool request number,
output device, total output requests
processed, number of output problems,
number of requests with no printout,
timestamp etc.

Requests

Ideally, the value of this measure should be
zero.

Indicates the number of
output problems encountered
by the output requests during
the last measurement period.
New output errors:
Indicates the number of
output errors encountered by
the output requests during
the last measurement period.

2.4.12

Work processes Test

Work processes execute the individual dialog steps in R/3 applications. For each type of work process,
this test reports the numerical statistics of the work processes in various states. In addition, this test helps
administrators in analyzing the CPU utilization of the work processes so that resource intensive work
processes can be identified. This way, administrators may figure out how well the work processes are

MONITORING THE SAP A BAP INSTANCE

utilized in the target environment and what is really causing the slowdown of the environment – is it due to
the unavailability of free work processes? or are too many work processes on hold or in PRIV mode?
Purpose

Reports measures pertaining to the different request processing groups

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server.
To view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for
a server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port
is 3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

MONITORING THE SAP A BAP INSTANCE

12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a
response from the SAP R/3 server. By default, this is set to 120 seconds.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
14. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects
a problem. You can modify this frequency, if you so desire. Also, if you intend to disable
the detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.
15. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every processing group on a SAP R/3 server

Measurement

Free work processes:

Measurement
Unit
Number

Indicates the number of work
processes of this type that
are currently free.
Percentage of free work
processes:

Percent

Indicates the percentage of
work processes of this type
that are currently free.

Interpretation

A high value is desired for these measures.
Sufficient number of free work processes are
needed to handle sudden spikes in activity. It
is important that free dialog work processes
are available so that administrators will be
able to login and troubleshoot other issues.

MONITORING THE SAP A BAP INSTANCE

Work processes on hold:

Number

Indicates the number of work
processes of this type that
are currently on hold.

Work processes are held when a particular
user holds the work proceses while waiting
for some message. These processes cannot
be released to the free pool until the message
is received. Work processes on PRIV mode
are also counted as on hold. Some issues
can cause work processes to be held
indefinitely
thereby
severely
limiting/exhausting the number of free work
processes.
The detailed diagnosis of this measure if
enabled, lists the process ID, CPU utilization,
user, report being run, table being accessed,
elapsed time etc.,

Percentage
of
processes on hold:

work

Percent

A low value is desired for this measure. If
there is a sudden surge in the value of this
measure, then it would adversely affect the
performance of the server by exhausting the
number of free work processes. Using the
Work
processes
on
hold
measure
administrators may figure out the work
processes that are held for a longer duration
and examine the real cause.

Number

A work process enters PRIV mode when
either extended memory is exhausted or the
process has used the amount of memory
specified in ztta/roll_extension. The work
process then starts utilizing the heap area
which is not appreciated. If the memory
utilized is greater than the one set against
the abap/heaplimit profile parameter, then the
work process has to be restarted after
terminating the user (i.e., after user sign out
process). This will help administrators to
restore the work processes from the PRIV
mode.

Indicates the percentage of
work processes of this type
that are currently on hold.

Work processes in PRIV
mode:
Indicates the number of work
processes of this type that
are currently in PRIV mode.

A low value is desired for this measure. An
increasing trend in the value of this measure
indicates severe performance bottleneck.
The detailed diagnosis of this measure if
enabled, lists the process ID, user, report
being run, table being accessed, elapsed
time etc.,

MONITORING THE SAP A BAP INSTANCE

Percentage
of
work
processes in PRIV mode:

Percent

A low value is desired for this measure. The
system will automatically terminate the
executing transactions if more than a certain
percentage of work processes are in PRIV
mode and the user is inactive for a certain
period of time.

Number

Comparing the value of this measure across
the types helps you in identifying the work
processes type that is highly utilized. This
data can be very useful for capacity planning
and fine tuning.

Indicates the percentage of
work processes of this type
that are currently in PRIV
mode.
Running work processes:
Indicates the number of work
processes of this type that
are currently running.

The detailed diagnosis of this measure lists
the work process details thereby providing a
snapshot view of the work processes that are
currently executing.
Stopped work processes:

Number

Indicates the work processes
of this type that are currently
in Stopped state.

The work processes would be in Stopped
state when the work processes have been
aborted and are not to be restarted. This
usually happens because of a serious startup
issue for the work process which needs to be
fixed before the work process can be started
again.
The detailed diagnosis of this measure lists
the details about these work processes such
as the process ID, user, report being run,
table being accessed, elapsed time etc.,

Total number
processes:

work

Number

Comparing the value of this measure helps
administrators in planning the capacity of
each work processes type and fine tune it
accordingly.

Number

The detailed diagnosis of this measure if
enabled, lists the name of the work

Indicates the total number of
work processes of this type
that are configured to run.
Dumps:
Indicates the total number of
created
by
the
work
processes of this type during
the last measurement period.

Request queue utilization:

processes that had errors / dumps, the
CPU utilization, number of dumps
thrown, user, report running, table
accessed etc., Using these details
administrators can deduce the reason
behind the creation of dumps.
Percent

Indicates the percent of
request queue for the work
processes of this type that is
currently utilized.

A high value for this measure indicates a
sudden surge in the user activity which helps
administrators to validate the distribution of
work processes.

MONITORING THE SAP A BAP INSTANCE

CPU utilization:

Percent

Indicates the overall CPU
utilization
of
the
work
processes of this type.

This measure indicates service level CPU
utilization of the various services (work
process types) such as Dialog service, Update
service, Spool service etc., This mesure helps
administrators to identify the resource
intensive work processes and figure out the
real reason that is hogging the resources.
The detailed diagnosis of this measure if
enabled, provides a sorted list of work
processes by CPU utilization.

Waiting requests:

Number

Indicates the number of
requests for this work process
type that are waiting to be
processed.

2.4.13

A higher number of waiting requests results
in high dispatcher wait time and response
time. This helps to provision and distribute
work processes appropriately.

Update Performance Test

The update system is designed to reduce the workload of the SAP transactions when significant changes are made to
the database. The changes are carried out asynchronously - usually with short delays in between - by special update
work processes. This is why the update system is widely used in SAP transactions (by almost every transaction that
changes business data), although transactions also can change the data directly in the database.
This test tracks the performance of the update system on a SAP R/3 server.

Purpose

Tracks the performance of the update system on a SAP R/3 server

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
10. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
11. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
13. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP R/3 server being monitored

Measurement
Unit

Measurement
Response
updates:
The time
update.

time
taken

for

Secs

the

Interpretation

MONITORING THE SAP A BAP INSTANCE

Wait time of the update
process:

Secs

The wait time of the update
processes in the dispatcher
queue.
Utilization of the update
processes:

Percent

The percentage utilization of
the update work processes.

Update work processes:

Number

The
number
of
work
processes of type Update 1
(high priority) and Update 2
(low priority).

2.4.14

There must be atleast one Update 1 type
work process in the system.

R3 Database Log Test

The R3 Database Log Test monitors database logs for specific error patterns. This test is disabled by default. This
test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page using the menu sequence :
Agents -> Tests -> Enable/Disable, pick SAP R/3 as the Component type, set Performance as the Test type, choose
this test from the DISABLED TESTS list, and click on the >> button to move the test to the ENABLED TESTS list. Finally,
click the Update button.

Purpose

Monitors database logs for specific error patterns

Target of the
test

The SAP R/3 server database logs

Agent
deploying the
test

An internal agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured.
3. PORT – The port at which the server listens
4. ALERTFILE

- Specify the path to the database log file to be monitored. For eg.,

/usr/john/cejkxihy.sta. Multiple log file paths can be provided as a comma-separated list eg., /user/john/cejkxihy.sta,/tmp/log/sejkxsig.tse.
Also, instead of a specific log file path, the path to the directory containing log files can be
provided - eg., /user/logs. This ensures that eG monitors the most recent log files in the
specified directory. Specific log file name patterns can also be specified. For example, to
monitor the latest log files with names containing the string 'dblogs', the parameter
specification can be, /tmp/usr/*dblogs*. Here, '*' indicates leading/trailing spaces (as the
case may be). In this case, the eG agent first enumerates all the log files in the specified
path that match the given pattern, and then picks only the latest log file from the result set
for monitoring.
You can also configure the path in the following format: Name@logfilepath. Here, Name
represents the display name of the path being configured. Accordingly, the parameter
specification for the 'dblogs' example discussed above can be: dblogs@/tmp/db/*dblogs*.
In this case, the display name 'slogs' will alone be displayed as descriptors of the test.
Every time this test is executed, the eG agent verifies the following:
a.

Whether any changes have occurred in the size and/or timestamp of the log
files that were monitoring during the last measurement period;

Whether any new log files (that match the ALERTFILE specification) have been
newly added since the last measurement period;

If a few lines have been added to a log file that was monitored previously, then the eG
agent monitors the additions to that log file, and then proceeds to monitor newer log files
(if any). If an older log file has been overwritten, then, the eG agent monitors this log file
completely, and then proceeds to monitor the newer log files (if any).

5. SEARCHPATTERN - Enter the specific patterns of alerts to be monitored. The pattern
should be in the following format: :, where is
the pattern name that will be displayed in the monitor interface and is an
expression of the form - *expr* or expr or *expr or expr*, etc. A leading '*' signifies any
number of leading characters, while a trailing '*' signifies any number of trailing characters.
For example, say you specify BRSPACE:BR100* in the SEARCHPATTERN text box. This
indicates that "BRSPACE" is the pattern name to be displayed in the monitor interface.
"BR100*" indicates that the test will monitor only those lines in the database log which start
with the term "BR100".
A single pattern may also be of the form e1+e2, where +
signifies an OR condition. That is, the PatternName is matched if either e1 is true or e2 is
true.
Multiple search patterns can be specified as a comma-separated list. For example:
BRSPACE:BR100*,BRCONNECT:BR02*.

MONITORING THE SAP A BAP INSTANCE

If the ALERTFILE specification is of the format Name@logfilepath, then the descriptor for
this test in the eG monitor interface will be of the format: Name:PatternName. On the other
hand, if the ALERTFILE specification consists only of a comma-separated list of log file
paths, then the descriptors will be of the format: LogFilePath:PatternName.
If you want all the messages in a log file to be monitored, then your specification would be:
:*.

6. LINES - Specify two numbers in the format x:y. This means that when a line in the alert
file matches a particular pattern, then x lines before the matched line and y lines after the
matched line will be reported in the detail diagnosis output (in addition to the matched
line). The default value here is 0:0. Multiple entries can be provided as a comma-separated
list.
If you give 0:0,1:1 as the value for LINES and if the corresponding value in the
SEARCHPATTERN filed is like BRSPACE:BR100*,BRCONNECT:BR02* then:

 0:0 will be applied to BRSPACE:BR100* pattern
 1:1 will be applied to BRCONNECT:BR02* pattern
7. EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded from
monitoring in the EXCLUDEPATTERN text box. For example *critical*,*exception* . By
default, this parameter is set to 'none'.

8. UNIQUEMATCH - By default, the UNIQUEMATCH parameter is set to FALSE, indicating
that, by default, the test checks every line in the log file for the existence of each of the
configured SEARCHPATTERNS. By setting this parameter to TRUE, you can instruct the
test to ignore a line and move to the next as soon as a match for one of the configured
patterns is found in that line. For example, assume that Pattern1:*fatal*,Pattern2:*error* is
the SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE,
then the test will read every line in the log file completely to check for the existence of
messages embedding the strings 'fatal' and 'error'. If both the patterns are detected in the
same line, then the number of matches will be incremented by 2. On the other hand, if
UNIQUEMATCH is set to TRUE, then the test will read a line only until a match for one of
the configured patterns is found and not both. This means that even if the strings 'fatal' and
'error' follow one another in the same line, the test will consider only the first match and not
the next. The match count in this case will therefore be incremented by only 1.

MONITORING THE SAP A BAP INSTANCE

ROTATINGFILE - This flag governs the display of descriptors for this test in the eG
monitoring console.
If this flag is set to true and the ALERTFILE text box contains the full path to a specific
(log/text) file, then, the descriptors of this test will be displayed in the following format:
Directory_containing_monitored_file:. For instance, if the ALERTFILE
parameter is set to c:\eGurkha\logs\syslog.txt, and ROTATINGFILE is set to true, then,
your descriptor will be of the following format: c:\eGurkha\logs:. On the
other hand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of
the following format: : - i.e., syslog.txt: in
the case of the example above.
If this flag is set to true and the ALERTFILE parameter is set to the directory containing log
files, then, the descriptors of this test will be displayed in the format:
Configured_directory_path:. For instance, if the ALERTFILE parameter is
set to c:\eGurkha\logs, and ROTATINGFILE is set to true, then, your descriptor will be:
c:\eGurkha\logs:. On the other hand, if the ROTATINGFILE parameter
had been set to false, then the descriptors will be of the following format:
Configured_directory: - i.e., logs: in the case of the
example above.
If this flag is set to true and the ALERTFILE parameter is set to a specific file pattern,
then, the descriptors of this test will be of the following format:
:. For instance, if the ALERTFILE parameter is set to
c:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor will be:
*sys*:. In this case, the descriptor format will not change even if the
ROTATINGFILE flag status is changed .

ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.

Outputs of the
test
Measurements
made by the

One set of results for every SEARCHPATTERN

Measurement

Measurement
Unit
62

Interpretation

MONITORING THE SAP A BAP INSTANCE

test

Messages:

Number

Indicates the number of
messages of the configured
patterns that were added
to the database log when
the test was last executed.

2.4.15

The value of this measure is a clear indicator
of the number of “new” alerts that have
come into the monitored database logs.

Enqueue Test

The Enqueue service allows SAP R/3 applications to lock data so that only they can use it. Locking the data prevents
parallel changes to the same data, which would lead to data inconsistency. There is one instance of an enqueue
service for each system - this instance becomes the central instance of the system by virtue of having this service.
This Enqueue Client collects performance values for requests from other instances to this service. The Enqueue
server provides the enqueue service for the system.
This test monitors the performance of the enqueue service and reports how well the owner IDs in the loack table
were utilized. In addition, this test reports how well the elementary lock IDs were utilized and how many errors were
encountered in the enqueue work process.

Purpose

Monitors the performance of the enqueue service and reports how well the owner IDs in the
loack table were utilized. In addition, this test reports how well the elementary lock IDs were
utilized and how many errors were encountered in the enqueue work process

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Client enqueue frequency:

Locks/Min

This is a relative measure of activity in the
system, useful only for analyzing unusual
events or patterns of activity in an application
server. The R/3 enqueue service is capable of
handling very high rates of operation. Should
an alert occur, it indicates that the wait times
for lock operations are having an adverse
effect on the overall dialog response time.
These situations are of a temporary nature
and should correct themselves. They are
likely to occur only under unusual
circumstances, such as massively parallel
execution of RFC calls to a particular server.

Percent

If an error occurs in this MTE, analyze the
problem by executing the following diagnosis
function in the lock management:

The
rate
of
Enqueue
operations (logical data locks)
coming from another instance
to the central instance.

Server queue length:
The percentage length of the
wait queue for the enqueue
service

Owner names utilization:

Call Transaction SM12 and choose Extras ->
Diagnosis or -> Diagnosis in update. With
SAP'S agreement, you can use the extended
diagnosis functions that are displayed by
entering the OK codes "TEST".
Percent

Indicates the percentage of
owner IDs in the lock table
that are currently utilized.

Every time the enqueue server receives a
lock request, the system checks the lock
table to determine whether the request
collides with an existing lock . If this is the
case, the request is rejected. Otherwise, the
new lock is written to the lock table. This lock
table available in the main memory of the
enqueue server records the current locks in
the system.
For each elementary lock, the table specifies
the owner, lock mode, name, and the fields
in the locked table.
If the value of this measure is close to 100%,
it indicates that all the owner IDs in the lock
table are exhausted and hence, new locks
cannot be created unless the existing locks
assigned to the owner IDs are released.

Granule
utilization:

arguments

Percent

Indicates the percentage of
lock arguments in the lock
table that are currently
utilized.

The locks of different owners or with different
lock modes containing the same lock
argument occupy one entry in the lock table.
If the value of this measure is close to 100%,
it indicates that all the lock argument s in the
lock table are exhausted and new locks
cannot be created unless the existing locks
are released.

MONITORING THE SAP A BAP INSTANCE

Granule
utilization:

entries

Percent

Indicates the percentage of
elementary locks in the lock
table that are currently
utilized.

Enqueue
errors:

work

process

An elementary lock corresponds to a data
record in the lock table. For each elementary
lock, the table specifies the owner, lock
mode, name, and the fields in the locked
table.
If the value of this measure is close to 100%.
It indicates that all the elementary locks in
the lock table are utilized and hence, new
locks cannot be created unless the existing
elementary locks are released from the lock
table.

Number

Ideally, the value of this measure should be
zero.

Indicates the number of
errors encountered by the
enqueue work process.
Enqueue work
error rate:

process

Errors/Min

Indicates the rate of enqueue
work
process
errors
encountered.

2.4.16

Database consistency Test

A database consistency check performs a thorough check of the entire database. It examines all tables in the
database to find out whether index and data pages are correctly linked and indexes are in proper-sorted order. It
also checks that all pointers are consistent and that the data information on each page, and page offsets are
reasonable. It enables the early recognition of problems and thus prevents problem escalation and possible loss of
data.
Using this test, administrators can figure out how many primary and secondary indices were affected i.e.,
inconsistent while each type of database consistency check is performed. In addition, you can also figure out the
number of tables and views that were affected when the database consistency check is performed.

Purpose

Using this test, administrators can figure out how many primary and secondary indices were
affected i.e., inconsistent while each type of database consistency check is performed. In
addition, you can also figure out the number of tables and views that were affected when the
database consistency check is performed.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
13. JCOVERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Interpretation

MONITORING THE SAP A BAP INSTANCE

Primary indexes:

Number

A low value is desired for this measure.

Number

A low value is desired for this measure.

Number

A high value indicates that the tables in the
database are inconsistent. Early detection of
such tables will help administrators prevent
possible loss of data.

Indicates the number of
primary indices that were
affected while performing this
type of database consisteny
check.
Secondary indexes:
Indicates the number of
secondary indices that were
affected while performing this
type of database consisteny
check.
Tables:
Indicates the number of
tables that were affected
while performing this type of
database consisteny check.
Views:

Number

Indicates the number of
views that were affected
while performing this type of
database consisteny check.

2.4.17

Update requests Test

An update request, or update record, describes the data changes determined in an SAP LUW. These changes should
be made completely, or not all (this means, in a database LUW). This refers only to V1 updates. V2 updates are
triggered once the V1 update is complete, and are processed in a separate database LUW.
An update request is identified by its update key.
When the dialog transaction ends (COMMIT WORK), and the update process is called, an update header is created.
Then the update record is created. The update data is contained in the update modules that was created using the
ABAP command CALL FUNCTION '…' IN UPDATE TASK. The function module type is defined in the
transaction for maintaining function modules (transaction SE37). Whenever there are too many data changes in the
target environment, then it indicates that so many update requests will be created to effect those changes. With an
increase in the volume of data changes, administrators may need to check the volume of the update requests too.
The time taken for an update request to complete processing depends on the changes that were made to the target
environment. Therefore, when too many update requests are created in the environment, administrators need to
identify the update requests that are taking too long to process, update requests that are stopped and are stuck for a
longer duration. This is exactly where the Update requests Test helps! Using this test, you can figure out how many
update requests were created and how many were actually stopped/stuck in the target environment. In addition,
administrators can figure out the update requests that encountered errors.

Purpose

Helps you figure out how many update requests were created and how many were actually
stopped/stuck in the target environment. In addition, administrators can figure out the update
requests that encountered errors.

MONITORING THE SAP A BAP INSTANCE

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
13. JCOVERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.

MONITORING THE SAP A BAP INSTANCE

14. STUCKUPDATECUTOFF – Specify the time duration (in minutes) beyond which the
update requests in the following states are classified as stuck:


VB_RUN_V1,



VB_RUN_V2,



VB_RESTART_V1,



VB_RESTART_V2,



initial,



auto(sys) and



auto(dia)

15. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every SAP R/3 server being monitored

Measurement
Unit

Measurement

Number
of
requests created:

update

Requests

Indicates the number of
update requests that were
created during the last
measurement period.

Interpretation

MONITORING THE SAP A BAP INSTANCE

Rate of update requests
created:

Requests/sec

This measure is a good indicator of the load
on the system.

Requests

The update requests may be stopped due to
various reasons such as database issues,
longer wait period to connect to the server,
the update server being inactive for a longer
time etc.

Indicates the rate at which
update requests were created
during the last measurement
period.
Total number of stopped
updates:
Indicates the total number of
update requests that were
stopped since the start of the
server.
Rate of stopped update
requests:

Percent

Indicates the rate at which
update
requests
were
stopped during the last
measurement period.
Total number
updates:

error

Number

Ideally, the value of this measure should be
zero.

Requests/sec

An increasing trend for this measure indicates
an error with the update system. If so,
update system can be deactivated to prevent
issues relating to the abnormally terminated
updates and reactivated once the issue has
been resolved.

Requests

Stuck updates are hanging updates that have
not been marked as error updates. Stuck
updates may need to be manually processed
depending upon their actual status.

Indicates the total number of
errors encountered in the
update request since the start
of the server.
Rate of update requests
with errors:
Indicates the rate at which
errors were encountered in
the update requests during
the last measurement period.
Total number of updates
stuck:
Indicates the total number of
update requests that were
stuck while processing since
the start of the server.
Rate of update requests
stuck:

Requests/sec

Indicates the rate at which
update requests were stuck
while processing during the
last measurement period.

MONITORING THE SAP A BAP INSTANCE

New updates stopped:

Number

Indicates the number of
update requests that were
stopped during the last
measurement period.
New updates with errors:

Number

Indicates the number of
errors encountered in the
update requests during the
last measurement period.
New updates stuck:

Ideally, the value of this measure should be
zero.

Number

Indicates the number of
updates that were stuck while
processing during the last
measurement period.

2.4.18

Idoc wait monitor Test

Idocs are structured ASCII files (or a virtual equivalent). They are the file format used by SAP ABAP to exchange data
with foreign systems. Idocs is the acronym for Interchange Document. This indicates a set of (electronic) information
which builds a logical entity. An IDoc is e.g. all the data of a single customer in your customer master data file, or the
IDoc is all the data of a single invoice.
An SAP ABAP application creates data and updates the database appropriately. An application can be a transaction, a
stand-alone ABAP Report or any tool that can update a database within SAP ABAP. If the application thinks that data
needs to be distributed to a foreign system, it triggers the IDoc outbound routine, usually by leaving a descriptive
message record in the message table NAST. The application then either directly calls the IDoc engine or a collector
job eventually picks up all due IDoc messages and determines what to do with them. If the engine believes that data
is ready to be sent to a partner system, then it determines the function module which can collect and wrap the
required IDoc data into an IDoc. In IDoc customising, you specify the name of the function module to use. This can
either be one which is predefined by ABAP standard or a user-written one. When the IDoc is created it is stored in an
R/3 table and from there it is sent to the foreign system.

IDoc inbound routines, on the other hand, are function modules with a standard interface, which will interpret the
received IDoc data and prepare it for processing. The received IDoc data is processed record by record and
interpreted according to the segment information provided with each record. The prepared data can then be
processed by an application, a function module, or a self-written program.
Any slowdown noticed in electronic data exchange between the SAP ABAP system and foreign systems therefore, can
be attributed to bottlenecks or errors in the transmission/reception of Idocs. Administrators should hence closely
monitor inbound and outbound IDoc traffic to proactively detect probable slowdowns in inter-system
communications, and accurately tell where the slowdown occurred and why, so that the communication bottlenecks
can be promptly cleared. This is where the IDoc wait monitor test helps.
This test monitors the inbound and outbound Idocs generated during the past hour and reports the rate at which
these Idocs were processed at various stages of transmission/reception, thus accurately pointing to processing
slowdowns and where exactly the processing was bottlenecked. In addition, the test also reports the number of
Idocs that were found to be erroneous every second and the exact stage of transmission/reception at which the rate
of errors peaked!

Purpose

Monitors the inbound and outbound Idocs generated during the past hour and reports the rate
at which these Idocs were processed at various stages of transmission/reception, thus
72

MONITORING THE SAP A BAP INSTANCE

accurately pointing to processing slowdowns and where exactly the processing was
bottlenecked. In addition, the test also reports the number of Idocs that were found to be
erroneous every second and the exact stage of transmission/reception at which the rate of
errors peaked!

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
13. JCOVERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
14. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.

Outputs of the
test

One set of results for every SAP R/3 server being monitored

MONITORING THE SAP A BAP INSTANCE

Measurements
made by the
test

Measurement
Unit

Measurement
Open change pointers:

Number

Indicates the number of
Idocs generated for the
change pointers that are still
in the Waiting state for the
last 1 hour.
Outbound
dispatch:

ready

for

Interpretation

Change Pointers are log entries to
remember all modified records relevant
for ALE. Change pointers are log entries
to table BDCP, which are written every
time a transaction modifies certain fields.

Number

Indicates the number of
outbound Idocs that were
ready for dispatch during the
last 1 hour.
Outbound
system:

external

Number

Indicates the number of
outbound Idocs that were
waiting in the external system
during the last 1 hour.
Outbound errors in Idoc
interface:

Number

Ideally, the value of this measure should be
zero.

Number

Ideally, the value of this measure should be
zero.

Indicates the number of
outbound
Idocs
that
encountered errors in the
interface during the last 1
hour.
Outbound
errors
external system:

Indicates the number of
outbound Idocs that were
error prone in the external
system during the last 1 hour.
Inbound generated:

Number

Indicates the number of
Idocs that were in the
Waiting state during the last
1 hour.

MONITORING THE SAP A BAP INSTANCE

Inbound errors in Idoc
interface:

Number

Indicates the number of
inbound
Idocs
that
encountered errors in the
interface during the last 1
hour.
Inbound
errors
application:

Number

Indicates the number of
inbound
Idocs
with
application errors during the
last 1 hour.

MONITORING THE SAP A BAP INSTANCE

2.5 The SAP Workload Layer

Figure 2.19: The tests mapped to the SAP Workload Layer
77

MONITORING THE SAP A BAP INSTANCE

2.5.1

Background jobs Test

SAP background processing automates routine tasks and helps you optimize your organization’s SAP computing
resources. Using background processing, you tell the SAP System to run programs for you. Background processing
lets you move long-running or resource-intensive program runs to times when the system load is low. It also lets you
delegate to the system the task of running reports or programs. Your dialog sessions are not tied up, and reports
that run in the background are not subject to the dialog-step run-time limit that applies to interactive sessions.
The SAP System offers sophisticated support for background processing. You can choose from a variety of methods
for scheduling and managing jobs. You can run both SAP-internal and external programs. And, for easier scheduling
and management, you can run related programs as " job steps" within a single background processing job, allowing
a single background job to accomplish a complex task that consists of multiple processing steps.
Often job execution takes too long when the job consists of too many complex tasks. This prolonged execution of a
job may consume a considerable amount of resources and therefore hamper the execution of other background jobs.
In order to figure out the background jobs that are executing for a longer time and the status of the job,
administrators may use the Background jobs test! This test monitors the current status and the previous status of
each background job that is executing, the time taken for job execution and the time delay encountered by the jobs
during execution. This way, administrators can figure out the background job that is executing for a longer duration
and blocking valuable resources.

Purpose

Monitors the current status and the previous status of each background job that is executing,
the time taken for job execution and the time delay encountered by the jobs during execution.
This way, administrators can figure out the background job that is executing for a longer
duration and blocking valuable resources.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

MONITORING THE SAP A BAP INSTANCE

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
13. MAXLOGLINES - In order to troubleshoot the jobs that were aborted, the eG agent
facilitates collecting the last n lines of the jobs that were aborted. To achieve this, specify
the number of lines of an aborted job that needs to be retreived for troubleshooting in the
MAXLOGLINES parameter. By default, the value of this parameter is 3.
14. USERJOBS - Sometimes, adminsitrators may wish to periodically monitor certain
background jobs. To monitor such jobs, specify a comma-separated list of jobs in the
format: Job:Time period (in hours) in the USERJOBS text box. Say for example, you wish
to monitor a job named Print with a time period of 2 hours, then specify Print:2 in the
USERJOBS text box. By default, none is specified against this text box.
15. STANDARDJOBMOITOR – If you wish to monitor the standard jobs in the target SAP R/3
instance, then set the STANDARDJOBMONITOR flag to Yes. If you set this flag to No,
then standard jobs will not be monitored. By default, the value of this flag is Yes.
16. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.
17. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
o

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

Current status:

Interpretation

The values that this measure reports and
their numeric equivalents are provided in the
table below:

Indicates the current status
of this job execution.

Measure
value

Numeric
value

N/A

Planned or
Scheduled

Released

Ready

Active

Finished

Cancelled or
Aborted

Note:
By default, this measure reports one of the
values listed under Measure Values to
indicate the current status of this job
execution. In the graph of this measure
however, the same is represented using the
numeric equivalents i.e., 0 to 6 only.

MONITORING THE SAP A BAP INSTANCE

Previous status:

The values that this measure reports and
their numeric equivalents are provided in the
table below:

Indicates the status of this
job that was executed before
the last known execution of
this job.

Measure
value

Numeric
value

N/A

Planned or
Scheduled

Released

Ready

Active

Finished

Cancelled or
Aborted

Note:
By default, this measure reports one of the
values listed under Measure Values to
indicate the status of the job execution
before the last known execution. In the graph
of this measure however, the same is
represented using the numeric equivalents
i.e., 0 to 6 only.
Duration:

Minutes

Compare the value of this measure across the
jobs to figure out the job that took too long
to execute.

Minutes

A low value is desired for this measure.

Indicates the total time taken
to execute this job.

Delay:
Indicates the time delay
encountered by this job
during execution.

If there is an alarming increase in the value
of this measure, it indicates that adequate
background processes are not available for
executing this job. The background processes
may not be available when there are too
many job executions and when a job is
executing
endlessly.
In
such
cases,
administrators need to overlook the issue and
rectify the same before any serious
performance degradation of the server
occurs.
Comapring the value of this measure across
the jobs will help you identify the job that
encountered the maximum time delay.

MONITORING THE SAP A BAP INSTANCE

2.5.2

Job statistics Test

This test monitors the distribution of background jobs according to the job status. Apart from montoring the overall
job execution, this test helps to debug issues that occurred due to long running jobs, aborted jobs and jobs with high
start delays.

Purpose

Monitors the distribution of background jobs according to the job status. Apart from montoring the
overall job execution, this test helps to debug issues that occurred due to long running jobs,
aborted jobs and jobs with high start delays.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to enable
the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with either of the
following profiles need to be specified: S_A.SYSTEM (super administrator) or SAP_ALL (all
authorizations for SAP).

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box specify
the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In such a
case, specify the IP of the router in the ROUTER text box. If both the client and the server
exist in the same network, then specify 'none' against the ROUTER text box.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17 of
this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the metrics,
you need to specify the version of the SAP JCO library that the agent needs to use. For
instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the ‘major
version number’ alone against JCO VERSION – in the case of this example, this will be 2.x.
13. MAXLOGLINES - In order to troubleshoot the jobs that were aborted, the eG agent facilitates
collecting the last n lines of the jobs that were aborted. To achieve this, specify the number of
lines of an aborted job that needs to be retreived for troubleshooting in the MAXLOGLINES
parameter. By default, the value of this parameter is 3.
14. LONGRUNNINGCUTOFF - Specify the time duration in hours beyond which a job is classified
as a long running job in the LONGRUNNINGCUTOFF text box.
15. HIGHDELAYCUTOFF - Generally, there may be a permissible time delay while a job is
started. Specify the duration of such time delay in seconds beyond which the job is classifed as
a job with a higher start delay in the HIGHDELAYCUTOFF text box

MONITORING THE SAP A BAP INSTANCE

16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG Enterprise
suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can
be configured to run detailed, more elaborate tests as and when specific problems are
detected. To enable the detailed diagnosis capability of this test for a particular server, choose
the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available only if
the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis measures
should not be 0.

One set of results for every SAP R/3 server being monitored

Measurement

Active jobs:

Measurement
Unit

Interpretation

Number

Indicates the number of jobs of
this priority class that are
currently active.
Ready jobs:

Number

A low value is desired for this measure. If
there is a sudden/gradual increase in the
value of this measure, then it indicates that
the background work processes are
insufficient to execute the jobs. Therefore,
administrators may need to check the
number of background work processes and
provision them accordingly.

Number

Generally, the jobs may be classified as a
long running job when the job is stuck during
execution and loops the execution several
times without completion. A high value for
this measure is a cause of concern as long
running jobs consume too much of resources
thus leading to the performance degradation
of the SAP instance.

Indicates the number of jobs of
this priority class that are
waiting for execution by the
background work processes.

Long running jobs:
Indicates the number of jobs of
this priority class that have been
running for a duration longer
than than the cutoff time
specified
in
the
LONGRUNNINGCUTOFF
parameter.

The detailed diagnosis of this measure if
enabled, lists the name of the job, job count,
report name, user details, timestamps,
duration etc.,

MONITORING THE SAP A BAP INSTANCE

New jobs:

Number

A gradual decrease in the value of this
measure
is
a
cause
of
concecrn.
Administrators may need to check the
number of backgroung processes that are
free and provision them according so that the
background processes can execute the jobs
continuously.

Number

A low value is desired for this measure.

Indicates the number of jobs of
this priority class that were
started
during
the
last
measurement period.

New jobs with start delays:
Indicates the number of jobs of
this priority class that started
with a delay time greater than
the time specified against the
HIGHDELAYCUTOFF
parameter while configuring the
test.
Aborted or cancelled jobs:

The jobs may be started with a delay due to
various reasons such as unavailable
background work processes, scheduling
issues between the originating server and
target server, other dependencies etc., This
measure helps detect such issues by
providing the details of these jobs including
the exact start delay in milliseconds.
Number

Indicates the number of jobs of
this priority class that were
cancelled/aborted during the last
measurement period.

Jobs may be abruptly terminated either
manually or due to underlying program errors.
Program errors could in turn be due to
various issues such as authentication, file
access, dead locks, updates, tablespace,
memory, programming errors, dependencies
etc., Therefore, a sudden/gradual increase in
the value is a cause of concern which
indicates severe performance degradation fo
the target server.
The detailed diagnosis of this measure if
enabled, provides details and logs for the
aborted/cancelled jobs in order to facilitate
troubleshooting.

Average job start delay:

Milliseconds

Comparing the value of this measure across
the priority classes helps you identify the
class in which the jobs experienced the
maximum start delay.

Number

A high value is desired for this measure.

Indicates the average time delay
experienced in starting the jobs
of this priority class.
Finished jobs:
Indicates the number of jobs of
this priority class that completed
execution
during
the
last
measurement period.

2.5.3

This measure is a good indicator of the
performance of the background processing
system. The higher the value of this measure
the greater is the performace of the targe
server.

Task Types Load Test

Typically, every work process in the SAP AS ABAP system specializes in a particular task type. These task types are
as follows:

MONITORING THE SAP A BAP INSTANCE

Task Type

Explanation

B.INPUT

Transaction step in batch input mode; it is processed by the dialog work process (update
dialogs generated in batch input are always processed synchronously, they belong to
the UPDATE task type).

BACKGROUND

Transaction step that was started by a background processing work process.

DIALOG

Usually a transaction step started online by a user (for example, editor dialogs or manual
postings).

SPOOL

Transaction step of a spool work process

UPDATE

Transaction step of the SAP update task; it is automatically started by the dispatcher on a host
with an active update process (update processes are usually installed on the database host)

UPDATE2

V2 update

LCOM

The Fast RFC (fRFC or LCOM-RFC) is a very fast form of data transfer that uses a shared
memory pipeline. It is only used in internal communication between ABAP and Java in the SAP
Web AS.

HTTP, HTTPS, NNTP, SMTP, Requests from the ICM that are based on the corresponding Internet protocols
FTP
ENQUEUE

Enqueue handler

DIALOG(-)GUI

Dialog without GUI

EXT.PLUGIN
The statistical evaluations of these task types are only relevant for internal SAP purposes.
AUTOTH (Auto task handler)
RPCTH (Task handler remote
procedure call)
RFCVMC (RFC inside VMC)
DDLOG CLEANUP
DEL. THCALL (Delayed task
handler call)
AUTOJAVA
HTTP/JSP, HTTPS/JSP

In addition to the above, there are some task types that do not correspond to any work process; these tasks
represent specific applications in the dialog work process. Such task types are as follows:

MONITORING THE SAP A BAP INSTANCE

Task Type
AUTOABAP

Explanation
Automatically-processed report (for example, for monitoring tools)

BUFFERSYNC A synchronization of the local table buffers regularly requested by the SAP system (the time interval is
controlled by the profile parameter rdisp/bufreftime).
RFC

Remote Function Call in the ABAP system; it is processed by the dialog work process

CPIC

Other communication using the CPIC interface; it is processed by the dialog work process

ALE

iDoc processing; it is processed by the dialog work process

Tasks, regardless of their type, add to the workload of a SAP AS ABAP system. In the event of a slowdown therefore,
administrators should check the workload generated by each task type, analyze whether/not the ABAP system has
the processing power to handle the load, isolate the task types where processing is bottlenecked, and understand
where the bottleneck occurred – at the dispatcher? When rolling in user contexts? When loading objects? When
waiting for RFC calls? When interacting with the database? when performing enqueue operations? The Task Types
Load test provides administrators with answers to these questions!
This test auto-discovers the task types handled by the SAP ABAP system, and for each task type, reports the
resource usage of the transactions of that type, measures the processing time of the transactions at various stages,
and accurately pinpoints the following:
The task type(s) that is consuming more resources than normal;
The task type(s) that is taking too long to be processed and why;

Purpose

Monitors the performance of the enqueue service

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. MAXIMUM STEPS – To report workload metrics, the eG agent will have to typically analyze
numerous dialog steps of activity on the SAP ABAP system. To reduce the stress on the eG
agent, you can limit the number of dialog steps the eG agent needs to process in order to
make a fair assessment of the workload and the processing ability of the ABAP system. This
limit can be specified against MAXIMUM STEPS. By default, this limit is set to 5000.

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every task type handled by the SAP AS ABAP instance being monitored

Measurement
Activity:

Measurement
Unit
Steps/Sec

This is a good indicator of the workload
imposed by a task type on the SAP ABAP
instance. You can compare the value of this
measure across task types to know which
task type is generating the maximum load.

Percent

Compare the value of this measure across
task types to know which task type is using
the maximum CPU and is probably causing a
CPU contention on the system. You may then
want to observe how this task type has been
using CPU over time and figure out whether
the CPU usage of that task type remains
consistently high; if so, it could mean that
that task type requires more processing
power to execute. You may then want to
consider resizing the SAP ABAP system with
more CPU resources.

Indicates the rate of steps
executed for transactions of
this task type in the last
measurement period.
CPU utilization:

Interpretation

Indicates the percentage of
CPU resources utilized by the
transactions of this task type.

MONITORING THE SAP A BAP INSTANCE

Total memory:

This measure is the sum total of the roll
memory, extended memory, and heap
memory used by a process.

Indicates the total memory
used by the transactions of
this task type during the last
measurement period.

By comparing the value of this measure
across task types, you can accurately identify
that task type which is consuming the
maximum memory. If the memory usage of
this task type has been abnormally high
consistently, it could indicate that the task
type is basically memory-intensive and
requires more memory resources for proper
execution. You should then figure out how
much memory and of what type should be
allocated to the task. For this, you may want
to determine which memory type was being
used the highest over time – is it heap
memory? Roll memory? Or extended
memory. The values of the PRIV mode heap
memory and the Extended memory metrics
will help administrators figure this out.
You can also use the detailed diagnosis of
this measure to identify the top 3 memoryconsuming transactions of a particular task
type.

MONITORING THE SAP A BAP INSTANCE

PRIV mode heap memory:

SAP’s memory management system assigns
memory to a work process. The order in
which a work process is assigned the memory
type depends on the work process type,
either dialog or non-dialog), and the
underlying operating system. Some of the
memory types are as follows:

Indicates the maximum
PRIV mode heap memory
consumed by transactions
of this task type in the
last measure period.

Roll area: The roll area memory is
used for the initial memory assigned
to a user context, and (if available)
for additional memory if the
expanded memory is full. The roll
area consists of 2 segments. The
first segment is assigned to the work
process first as memory. If this is
used up, the work process has more
memory assigned to it.
Extended memory: Each ABAP work
process has a part reserved in its
virtual address space for extended
memory. The majority of the user
context is stored in the extended
memory. You can map the extended
memory from the common resource
onto any work process, and after
onto another process on the same
address in the virtual address space.
This is important if you work with
pointers in the ABAP program. The
value of the Extended memory
measure indicates how each task
type is using this memory type.
Private memory: If a dialog work
process has used up the roll area
assigned to it and the extended
memory,
private
memory
is
assigned to the work process. The
work process goes into PRIV mode
(private). Other processes cannot

MONITORING THE SAP A BAP INSTANCE

use private (heap) memory. After
releasing the assigned memory, the
operating system still considers the
(virtual) memory as being occupied
by the allocating process.

Extended memory:

A consistent increase in the value of
the PRIV mode heap memory
measure for a task type therefore
indicates that transactions of that
type are continuously using up all
the roll area and extended memory,
and are being forced to reach out to
the private memory. This could
mean that the task type is memoryintensive. If too many task types are
found to be using PRIV heap
memory, it could mean that the
work processes are sized with
insufficient roll area and extended
memory. You may want hence want
to allocate more roll area and
extended memory to make sure that
private memory usage is minimal.

Indicates the maximum
extended memory used
by transactions of this
task type in the last
measure period.

Work process restarts:

Number

Indicates the number of
work
process
restarts
caused by transactions of
this task type in the last
measure period.

One of the common reasons for work process
restarts is excessive usage of private
memory. The work process, if it has used a
lot of private memory, is restarted when the
user context is terminated and the local
memory is returned. The restart makes the
local memory available again for other
processes.
Regardless of what caused it, work process
restarts are performance-impacting and need
to be kept at a minimum.

MONITORING THE SAP A BAP INSTANCE

Maximum response time
of a step:
Indicates
response
transaction
type in the
period.

Secs

the
maximum
time
of
the
steps of this task
last measurement

This measure compares the response time of
all the transaction steps executed by a task
type in the last measurement period and
reports the highest response time.
Use the detailed diagnosis of this measure to
identify the top 3 steps executed for this task
type with highest response times. This leads
you to the probable cause for delay in the
execution of this task type in the last five
minutes. Apart from the response time break
up, the report and CUA programs that were
running are also shown as part of detailed
diagnosis.

Total response time:
Indicates
the
total
response
time
per
transaction of this task
type
within the last
measure period.

Seconds/transa
ction

This measure includes the response time
taken at the server and the round trip times.
Ideally, the value of this measure should be
low. High values are indicative of poor
responsiveness.
Compare the value of this measure across
task types to identify the task type that is
least responsive. To know the reason for the
delay, you can compare the value of the GUI

time, GUI Net time, Server response time,
Processing time, Dispatcher wait time, Load
and generation time, Roll time, Database
request time, Lock time, and RFC time
measures for that task type. This will
accurately pinpoint where the task spent
maximum time – in the dispatcher queue? at
the server end? in processing? when loading
objects? when rolling in user contexts? when
performing database operations? when
performing enqueue operations? Or in
waiting for RFC calls?
You can also use the detailed diagnosis of
this measure to view the details of the top 3
transaction invocations that were least
responsive.

MONITORING THE SAP A BAP INSTANCE

GUI time:
Indicates the average time
taken
for
round
trip
communication
steps
between client and server in
between a transaction of
this task type.
GUI Net time:
Indicates the average front
end net time taken for the
first and last steps of
transactions of this task
type.
Server response time:
Indicates
the
average
response
time
of
a
transaction of this task
type at the server end.
Processing time:
Indicates the average time
taken
to
process
a
transaction of this task
type.

Secons/transac
tion

If the values of these measures are
excessive, check that the hardware
requirements for the presentation server are
met and that the network between the
application servers and the presentation
servers is not experiencing shortages or slow
traffic.

Seconds/transa
ction

In the event of a processing slowdown, you
can compare the value of this measure with
other response time measures reported by
this test to understand where the processing
bottleneck lies.

Secons/transac
tion

A high value for this measure may indicate
that ABAP programs are very complex and
the work processes spend a large amount of
time interpreting what is to be done.
The processing time of the DIALOG task type
for instance should be below twice the CPU
time. The same for the UPDATE task type
should be about 50% higher than that of the
DIALOG task type.

MONITORING THE SAP A BAP INSTANCE

Dispatcher wait time:
Indicates the average time
that the transactions of
this task type spent waiting
for a free work process at the
dispatcher.

Seconds/transa
ction

When the dispatcher receives a processing
request, it looks for a free SAP work process
of the required type and then sends the
request to this work process, which begins
the work. If all SAP work processes of the
required type are busy when the request
initially reaches the dispatcher, the request is
placed in the dispatcher queue. In the
dispatcher queue, the request waits until a
work process of the required type is free. As
soon as a work process is free, the
dispatcher sends the request to it. This time
the request spends in the dispatcher queue is
indicated as the dispatcher wait time.
For the DIALOG task type for instance, the
value of this measure should be less than
10% of the value of the Total response time
measure. Higher values are indicative of
performance problems. One common cause
of such performance problems may be
insufficient work processes.

Load and generation time:
Indicates the average time
spent for a transaction of
this task type for loading
and generation.

Seconds/transa
ction

All ABAP programs and screens that are
required but not yet available in the
application server buffers must be loaded or
generated. The time it takes to do this is
indicated as load and generation time.
Loading a program also entails accessing
database tables that store the ABAP
programs.
Typically, for a DIALOG task type, the load
time per step should not be greater than 50
ms.
High values could indicate problems with
memory configuration, small buffer sizes,
wrong parameter settings or a CPU
bottleneck.

MONITORING THE SAP A BAP INSTANCE

Roll time:

Secs

AN SAP transaction normally extends over
several transaction steps. During these steps,
data such as variables, internal tables, and
screen lists are built up and stored in the
main memory of the application server. This
data is known as user context. Different
transaction steps are normally processed by
different dialog work processes. At the
beginning of a transaction step, the user
context is made available to the appropriate
work process.This procedure is called roll-in.
Roll-out on the other hand saves the current
user-context data to virtual memory at the
conclusion of a transaction step. The time a
transaction step waited in the roll-area is
called roll wait time.

Indicates the average time
spent by a transaction of
this task type for rolling in
user contexts or when waiting
for roll out.

The value of this measure is the sum total of
roll-in time and roll wait time.
A high value for this measure indicates that a
particular task type is either taking too long
to roll in user contexts or is waiting too long
in the roll-area for a roll-out to occur. Since a
user context is moved out of the local
memory of a work process and moved into
the roll buffer during the roll-in process,
improperly sized roll buffers can cause
slowdowns in this process. Lack of adequate
space in the extended memory can also
contribute to a slowdown when rolling in user
contexts.
Possible causes for high roll wait times may
be due to having all work processes in the
target system occupied. It is very important
to configure the instances properly, especially
when they are designed to handle RFC
communication.

MONITORING THE SAP A BAP INSTANCE

Database request time:
Indicates the average time
spent by transactions of this
task type for performing
database operations such as
selects, inserts,
updates,
deletes and commits.

Lock time:
Indicates the average time
spent performing enqueue
operations for a transaction
of this task type.

Secons/transac
tion

When data is read or changed in the dataase,
the time required is known as Database
request time. This time is measured from the
moment the database request is sent to the
database server and runs until the moment
the data is returned to the application server.
Ideally, for the DIALOG task type, the value
of this measure should be 40% of the total
response time. Many factors can can cause
worrysome spikes in this value. This could be
problems in the database such as expensive
SQL statement or wrong parameter settings
in the database level. In addition, issues in
network connectivity between the application
server and the database can also adversely
impact this value. This is because, the
Database request time not only includes the
time required by the database to produce the
requested data, but also the time required for
network transfer of that data. In addition, I/O
contention experienced by the physical disks
can also affect this time.

Seconds/Trans
action

The enqueue service allows SAP ABAP
applications to lock data so that only they can
use it. Locking the data prevents parallel
changes to the same data, which would lead
to data inconsistency.
The Lock time measure reports the time from
sending an enqueue request to the SAP
enqueue server to the receipt of the results.
For a DIALOG task type typically, the Lock
time should be less than 5 ms. Any value
higher than that would represent a problem
that migh affect system stability. Network
problems can also increase the value of this
measure.

MONITORING THE SAP A BAP INSTANCE

RFC time:
Indicates the average time
spent waiting for RFC calls to
get
executed
in
a
transaction of this task
type.

Secons/Transa
ction

The value of this measure includes CPIC

(Common
Programming
Interface
Communication) time as well. CPIC is
typically used by the SAP system
program-to-program communication.

for

An increase in RFC time can increase roll wait
time considerably. When synchronous RFCs
are called, the work process executes a roll
out and may have to wait for the
end of the RFC in the roll area, even if the
dialog step is not yet completed. In the roll
area, RFC server programs can also wait for
other RFCs sent to them. The time a
transaction step waited in the roll-area is
called roll wait time.
The absence of adequate work processes can
cause the RFC time and consequently, the
roll wait time to increase. Besides ensuring
that the SAP ABAP system is sized with
sufficient work processes, you can also set
the following parameters properly to better
balance RFC load:

rdisp/rfc_max_comm_entries:

This
specifies the maximum number of
communications in an instance. No
more dialog work processes will be
given to the program calling the
target system after this number is
reached.

rdisp/rfc_min_wait_dia_wp:

This
specifies the number of work
processes to be always available for
online users.

2.5.4

Transaction Load Test

SAP transactions are units of work that define the workload of a SAP ABAP system. When users to a SAP ABAP
program complain of a slowdown, administrators should be able to instantly locate the exact transaction at which the
slowdown occurred and what is causing the delay – is it because the transaction is resource-intensive? Is it because
the transaction spent too much time in the dispatcher queue? is it owing to the time spent loading objects? Is it
because database operations consumed too much time? Is it due to complex enqueue operations? or did waiting for
RFC calls to complete contribute to the transaction slowdown? The Transaction Load test helps answer these
questions!
For every transaction invocation, this test reports the resource usage of and load imposed by that transaction on the
SAP ABAP system, indicates how well the system is processing the load, proactively detects overload conditions and
processing bottlenecks (if any), and accurately points administrators to the source of the bottlneck – i.e., it precisely
pinpoints which transaction is being processed slowly, which exact transaction step caused the delay, and why.

MONITORING THE SAP A BAP INSTANCE

Purpose

For every transaction invocation, this test reports the resource usage of and load imposed by
that transaction on the SAP ABAP system, indicates how well the system is processing the load,
proactively detects overload conditions and processing bottlenecks (if any), and accurately
points administrators to the source of the bottlneck – i.e., it precisely pinpoints which
transaction is being processed slowly and why.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. MAXIMUM STEPS – To report workload metrics, the eG agent will have to typically analyze
numerous dialog steps of activity on the SAP ABAP system. To reduce the stress on the eG
agent, you can limit the number of dialog steps the eG agent needs to process in order to
make a fair assessment of the workload and the processing ability of the ABAP system. This
limit can be specified against MAXIMUM STEPS. By default, this limit is set to 5000.
14. INCLUDE TCODES – By default, this test monitors only those transactions that were
invoked in the last measurement period. However, if you want a few critical transactions to
be monitored all the time – i.e., regardless of their status (whether they were invoked or
not) in the last measurement period – then, you can provide a comma-separated list of the
transaction codes of such transactions against INCLUDE TCODES.

100

MONITORING THE SAP A BAP INSTANCE

15. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every transaction handled by the SAP AS ABAP instance being monitored

Measurement

Activity:

Measurement
Unit
Steps/Sec

This is a good indicator of the workload
imposed by a transaction on the SAP ABAP
instance. You can compare the value of this
measure across transactions to know which
transaction is generating the maximum load.

Percent

Compare the value of this measure across
transactions to know which transaction is
using the maximum CPU and is probably
causing a CPU contention on the system. You
may then want to observe how this
transaction has been using CPU over time
and figure out whether the CPU usage of that
transaction remains consistently high; if so, it
could mean that that transaction requires
more processing power to execute. You may
then want to consider resizing the SAP ABAP
system with more CPU resources.

Indicates the rate of steps
executed for this transaction
in the last measurement
period.
CPU utilization:

Interpretation

Indicates the percentage of
CPU resources utilized by this
transaction.

101

MONITORING THE SAP A BAP INSTANCE

Total memory:

This measure is the sum total of the roll
memory, extended memory, and heap
memory used by a process.

Indicates the total memory
used by this transaction
during the last measurement
period.

By comparing the value of this measure
across transactions, you can accurately
identify that transaction which is consuming
the maximum memory. If the memory usage
of this transaction has been abnormally high
consistently, it could indicate that the
transaction is basically memory-intensive and
requires more memory resources for proper
execution. You should then figure out how
much memory and of what type should be
allocated to the task. For this, you may want
to determine which memory type was being
used the highest over time – is it heap
memory? Roll memory? Or extended
memory. The values of the PRIV mode heap
memory and the Extended memory metrics
will help administrators figure this out.
You can also use the detailed diagnosis of
this measure to identify the top 3 memoryconsuming steps of a particular transaction.

102

MONITORING THE SAP A BAP INSTANCE

PRIV mode heap memory:

Indicates the maximum
PRIV mode heap memory
consumed
by
this
transaction in the last
measure period.

Roll area: The roll area memory is
used for the initial memory assigned
to a user context, and (if available)
for additional memory if the
expanded memory is full. The roll
area consists of 2 segments. The
first segment is assigned to the work
process first as memory. If this is
used up, the work process has more
memory assigned to it.
Extended memory: Each ABAP work
process has a part reserved in its
virtual address space for extended
memory. The majority of the user
context is stored in the extended
memory. You can map the extended
memory from the common resource
onto any work process, and after
onto another process on the same
address in the virtual address space.
This is important if you work with
pointers in the ABAP program. The
value of the Extended memory
measure
indicates
how
each
transaction is using this memory
type.
Private memory: If a dialog work
process has used up the roll area
assigned to it and the extended
memory,
private
memory
is
assigned to the work process. The
work process goes into PRIV mode
(private). Other processes cannot

103

MONITORING THE SAP A BAP INSTANCE

use private (heap) memory. After
releasing the assigned memory, the
operating system still considers the
(virtual) memory as being occupied
by the allocating process.

Extended memory:

A consistent increase in the value of
the PRIV mode heap memory
measure for a transaction therefore
indicates that transactions of that
type are continuously using up all
the roll area and extended memory,
and are being forced to reach out to
the private memory. This could
mean that the transaction is
memory-intensive. If too many
transactions are found to be using
PRIV heap memory, it could mean
that the work processes are sized
with insufficient roll area and
extended memory. You may hence
want to allocate more roll area and
extended memory to make sure that
private memory usage is minimal.

Indicates the maximum
extended memory used
by this transaction in the
last measure period.

Work process restarts:

Number

Indicates the number of
work
process
restarts
caused by this transaction
in
the
last
measure
period.

104

MONITORING THE SAP A BAP INSTANCE

Maximum response time
of a step:

Secs

Indicates
the
maximum
response
time
of
the
transaction steps of this
transaction
in
the
last
measurement period.

This measure compares the response time of
all the transaction steps executed by a
transaction in the last measurement period
and reports the highest response time.
Use the detailed diagnosis of this measure to
identify the top 3 steps executed by this
transaction with highest response times. This
leads you to the probable cause for delay in
the execution of a transaction in the last five
minutes. Apart from the response time break
up, the report and CUA programs that were
running are also shown as part of detailed
diagnosis.

Total response time:
Indicates the total response
time per invocation of this
transaction within the last
measure period.

Seconds/transa
ction

This measure includes the response time
taken at the server and the round trip times.
Ideally, the value of this measure should be
low. High values are indicative of poor
responsiveness.
Compare the value of this measure across
transactions to identify which transaction is
least responsive. To know the reason for the
delay, you can compare the value of the GUI

time, GUI Net time, Server response time,
Processing time, Dispatcher wait time, Load
and generation time, Roll time, Database
request time, Lock time, and RFC time
measures for that transaction. This will
accurately pinpoint where a transaction spent
maximum time – in the dispatcher queue? at
the server end? in processing? when loading
objects? when rolling in user contexts? when
performing database operations? when
performing enqueue operations? Or in
waiting for RFC calls?
You can also use the detailed diagnosis of
this measure to view the details of the top 3
transaction invocations that were least
responsive.

105

MONITORING THE SAP A BAP INSTANCE

GUI time:
Indicates the average time
taken
for
round
trip
communication
steps
between client and server in
between an invocation of
this transaction.
GUI Net time:
Indicates the average front
end net time taken for the
first and last steps of this
transaction.
Server response time:
Indicates
the
average
response
time
of
an
invocation
of
this
transaction at the server
end.
Processing time:
Indicates the average time
taken
to
process
an
invocation
of
this
transaction.

Dispatcher wait time:
Indicates the average time
that an invocation of this
transaction spent waiting
for a free work process at the
dispatcher.

Secons/transac
tion

Seconds/transa
ction

In the event of a processing slowdown, you
can compare the value of this measure with
other response time measures reported by
this test to understand where the processing
bottleneck lies.

Secons/transac
tion

A high value for this measure may indicate
that ABAP programs are very complex and
the work processes spend a large amount of
time interpreting what is to be done.
The processing time of transactions executed
by the dialog work process for instance
should be below twice the CPU time.

Seconds/transa
ction

When the dispatcher receives a processing
request, it looks for a free SAP work process
of the required type and then sends the
request to this work process, which begins
the work. If all SAP work processes of the
required type are busy when the request
initially reaches the dispatcher, the request is
placed in the dispatcher queue. In the
dispatcher queue, the request waits until a
work process of the required type is free. As
soon as a work process is free, the
dispatcher sends the request to it. This time
the request spends in the dispatcher queue is
indicated as the dispatcher wait time.
For the transactions of the dialog work
process for instance, the value of this
measure should be less than 10% of the
value of the Total response time measure.
Higher values are indicative of performance
problems. One common cause of such
performance problems may be insufficient
work processes.

106

MONITORING THE SAP A BAP INSTANCE

Load and generation time:
Indicates the average time
spent by an invocation of
this transaction for loading
and generation.

Seconds/transa
ction

All ABAP programs and screens that are
required but not yet available in the
application server buffers must be loaded or
generated. The time it takes to do this is
indicated as load and generation time.
Loading a program also entails accessing
database tables that store the ABAP
programs.
Typically, for the transactions of the dialog
work process, the load time per step should
not be greater than 50 ms.
High values could indicate problems with
memory configuration, small buffer sizes,
wrong parameter settings or a CPU
bottleneck.

107

MONITORING THE SAP A BAP INSTANCE

Roll time:

Secs

An SAP transaction normally extends over
several transaction steps. During these steps,
data such as variables, internal tables, and
screen lists are built up and stored in the
main memory of the application server. This
data is known as user context. Different
transaction steps are normally processed by
different dialog work processes. At the
beginning of a transaction step, the user
context is made available to the appropriate
work process.This procedure is called roll-in.
Roll-out on the other hand saves the current
user-context data to virtual memory at the
conclusion of a transaction step. The time a
transaction step waited in the roll-area is
called roll wait time.

Indicates the average time
spent by an invocation of
this transaction for rolling
in user contexts and when
waiting for roll out.

The value of this measure is the sum total of
roll-in time and roll wait time.
A high value for this measure indicates that
this transaction is either taking too long to
roll in user contexts or is waiting too long in
the roll-area for a roll-out to occur. Since a
user context is moved out of the local
memory of a work process and moved into
the roll buffer during the roll-in process,
improperly sized roll buffers can cause
slowdowns in this process. Lack of adequate
space in the extended memory can also
contribute to a slowdown when rolling in user
contexts.
Possible causes for high roll wait times may
be due to having all work processes in the
target system occupied. It is very important
to configure the instances properly, especially
when they are designed to handle RFC
communication.

108

MONITORING THE SAP A BAP INSTANCE

Database request time:
Indicates the average time
spent by an invocation this
transaction for performing
database operations such as
selects, inserts,
updates,
deletes and commits.

Secons/transac
tion

When data is read or changed in the
database, the time required is known as
Database request time. This time is
measured from the moment the database
request is sent to the database server and
runs until the moment the data is returned to
the application server.
Ideally, for the transactions of the dialog
work process, the value of this measure
should be 40% of the total response time.
Many factors can can cause worrysome
spikes in this value. This could be problems in
the database such as expensive SQL
statement or wrong parameter settings in the
database level. In addition, issues in network
connectivity between the application server
and the database can also adversely impact
this value. This is because, the Database
request time not only includes the time
required by the database to produce the
requested data, but also the time required for
network transfer of that data. In addition, I/O
contention experienced by the physical disks
can also affect this time.

Lock time:
Indicates the average time
that an invocation of this
transaction spent performing
enqueue operations.

Seconds/Trans
action

The enqueue service allows SAP ABAP
applications to lock data so that only they can
use it. Locking the data prevents parallel
changes to the same data, which would lead
to data inconsistency.
The Lock time measure reports the time from
sending an enqueue request to the SAP
enqueue server to the receipt of the results.
For the transactions of the dialog work
process for example, the Lock time should be
less than 5 ms. Any value higher than that
would represent a problem that might affect
system stability. Network problems can also
increase the value of this measure.

109

MONITORING THE SAP A BAP INSTANCE

RFC time:
Indicates the average time an
invocation of this transaction
spent waiting for RFC calls to
get executed.

Secons/Transa
ction

The value of this measure includes CPIC

(Common
Programming
Interface
Communication) time as well. CPIC is
typically used by the SAP system
program-to-program communication.

for

rdisp/rfc_max_comm_entries:

This
specifies the maximum number of
communications in an instance. No
more dialog work processes will be
given to the program calling the
target system after this number is
reached.

rdisp/rfc_min_wait_dia_wp:

This
specifies the number of work
processes to be always available for
online users.

110

MONITORING THE SAP A BAP INSTANCE

2.6 The SAP Gateway Layer
Using the tests associated with the R3 Gateway layer (see Figure 2.20), administrators can determine the health of
communications between the SAP systems and external programs.

Figure 2.20: The tests associated with the SAP Gateway layer

2.6.1

IDoc Statistics Test

111

MONITORING THE SAP A BAP INSTANCE

This test monitors the Idocs generated and reports the rate at which these Idocs were processed at various stages of
transmission/reception, thus accurately pointing to processing slowdowns and where exactly the processing was
bottlenecked. In addition, the test also reports the number of Idocs that were found to be erroneous every second
and the exact stage of transmission/reception at which the rate of errors peaked! This way, the test leads
administrators to errors in electronic data exchange that may have delayed communication significantly, and where
such delays were frequent!

Purpose

Monitors the Idocs generated and reports the rate at which these Idocs were processed at
various stages of transmission/reception, thus accurately pointing to processing slowdowns and
where exactly the processing was bottlenecked. In addition, the test also reports the number of
Idocs that were found to be erroneous every second and the exact stage of
transmission/reception at which the rate of errors peaked! This way, the test leads
administrators to errors in electronic data exchange that may have delayed communication
significantly, and where such delays were frequent!

Target of the
test

A SAP ABAP instance

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

112

MONITORING THE SAP A BAP INSTANCE

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.
14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

113

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP ABAP instance being monitored

Measurement
Unit

Measurement

Number of new Idocs:

Interpretation

Idocs

A high value is desired for this measure.

Idocs/sec

This measure gives an overview of
outbound/inbound data transfer rate using the
Idocs.

Idocs

Ideally, the value of this measure should be
zero.

Indicates the number of
Idcos of this type that were
created during the last
measurement period.
Rate of new Idocs:
Indicates the rate at which
the Idocs of this type were
generated during the last
measurement period.
Total number
Idocs:

error

Indicates the total number of
Idocs of this type with errors.

A non-zero value is desired for this measure.
If this measure reports a non-zero value, then
use the detailed diagnosis of the Total

number

Idocs

with interface

errors

measure and the Total number of Idocs with
external system or application errors measure
to know which Idocs have errors and where
in the processing cycle these errors occurred.
Rate of error Idocs:

Idocs/sec

A low value is desired for this measure.

Idocs

Using the detailed diagnosis of this measure,
you can accurately identify the Idocs that are
experiencing interface errors and at which
exact state these errors have occurred. This
way, you can quickly get to the source of the
errors, eliminate them, and ensure that the
electronic data exchange is not disrupted for
long hours.

Indicates the rate of Idocs
errors of this type during the
last measurement period.
Total number of Idocs
with interface errors:
Indicates the total number of
Idocs of this type with
interface errors.

Rate
of
Idocs
interface errors:

with

Idocs/sec

Indicates the rate of Idocs of
this type with interface
errors.

114

MONITORING THE SAP A BAP INSTANCE

Total number of Idocs
with external system or
application errors:

Idocs

Ideally, the value of this measure should be
zero.

Indicates the total number of
Idocs of this type with
external system errors or
application errors.
Rate
of
Idocs
external
system
application errors:

with
or

Idocs/sec

Indicates the rate of Idocs of
this type with external errors
or application errors.
Idocs
with
unprocessed
errors:

recent
interface

Number

The detailed diagnosis of this measure if
enabled, lists the details of these Idocs such
as the Idoc number, type, error message,
recipient and sender details, creation and
modified timestamps and number of data
records.

Indicates the number of
Idocs of this type with
unprocessed interface errors
during the last measurement
period.
Idocs
with
recent
unprocessed
external
system
or
application
errors:

Number

Ideally, the value of this measure should be
zero.
The detailed diagnosis of this measure if
enabled, lists the details of these Idocs such
as the Idoc number, type, error message,
recipient and sender details, creation and
modified timestamps and number of data
records.

Indicates the number of
Idocs of this type with
external system errors or
application errors during the
last measurement period.

2.6.2

Ideally, the value of this measure should be
zero.

qRFC Queues Test

All types of applications are instructed to communicate with other applications. This communication may take place
within an SAP system, with another SAP system, or with an application from a remote external system. An interface
that can be used for dealing with this task is the RemoteFunction Call (RFC). RFCs can be used to start applications
in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in
order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features
at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not
have to be available). These features were further enhanced through the queued RFC with inbound/outbound
queue.
qRFC performs a serialization of tRFC (Transactional RFC) using wait queues. While the actual sending process is
done by the tRFC, inbound and outbound queues are added to the tRFC, thus resulting in a qRFC (queued Remote
Function Call). The sender system is called the client system, while the target system corresponds to the server
system.
In qRFC, the following communication scenarios are possible:
115

MONITORING THE SAP A BAP INSTANCE

qRFC with outbound queue
qRFC with inbound queue (and outbound queue)
Figure 2.21 depicts both these communication scenarios:

As you can see, in a qRFC with an outbound queue, the sender system uses an outbound queue to serialize the
data that is being sent. This means that function modules which depend on each other (such as update and then
change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target
system one after each other and one time only. The called system (server) has no knowledge of the outbound queue
in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP
system. (Note: the programming code of the server system must not be changed. However, it must be tRFCcapable.)
In the qRFC with inbound queue scenario on the other hand, for an outbound queue in the sender system
(client), there is also an inbound queue in the target system (server). In other words, if a qRFC with inbound queue
exists, it means that an outbound queue also exists in the sender system. This guarantees the sequence and
efficiently controls the resources in the client system and server system. The inbound queue only processes as many
function modules as the system resources in the target system (server) at that time allow. This prevents a server
from being blocked by a client.
Two systems can engage in smooth, uninterrupted communication using qRFC only if the outbound and inbound
queues operate in an error-free manner. To be able to promptly capture deficiencies in queue execution and rapidly
isolate the reasons for the same, administrators should closely monitor the inbound and outbound qRFC queues. This
can be achieved using the qRFC queues test. For each type (inbound and outbound) of queue, this test reports the
number of queues that are experiencing errors currently and the count of queues that took too long to complete. In
the process, the test turns the spotlight on those queues that may be responsible for unexpected breaks or
prolonged delays (if any) in inter-system communication, and also reveals what could be causing such queues to
perform poorly.

Purpose

For each type (inbound and outbound) of queue, this test reports the number of queues that are
experiencing errors currently and the count of queues that took too long to complete. In the
process, the test turns the spotlight on those queues that may be responsible for unexpected
breaks or prolonged delays (if any) in inter-system communication, and also reveals what could
be causing such queues to perform poorly

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

116

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. LONGREADYCUTOFF (HRS) – This test reports the Long ready state queues measure,
which is the number of queues stuck in the Ready state for a long time. To report this
measure, this test counts all queues that have been in the Ready state in excess of the
duration (in hours) specified against LONGREADYCUTOFF (HRS).
13. LONGRUNNINGCUTOFF (HRS) – This test reports the Long running queues measure,
which is the number of queues that have been running for a long time. To report this
measure, this test counts all queues that have been running for over a period of time (in
hours) specified against LONGRUNNINGCUTOFF (HRS).
14. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.

117

MONITORING THE SAP A BAP INSTANCE

15. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every qRFC queue type on the server being monitored; an additional All
descriptor is also supported, which aggregates metrics across queue types.

Measurement

Number of queue entries:

Measurement
Unit
Number

Indicates the number of
queue entries for this queue
type.

Interpretation

Queue entries refer to the function modules
that are sequentially arranged and placed in
an inbound/outbound queue (as the case
may be), for consumption by a target system.
A high value or a consistently increasing
value for this measure therefore indicates
that the inbound/outbound queue is long or
is growing. This could imply an overload or a
processing bottleneck at the sender/receiver
system (as the case may be). You can
compare the value of this measure between
inbound and outbound queues to understand
where the bottleneck is – at the sender
system or the target system? .

Number of queues:

Number

Indicates the current number
of queues of this queue type.

118

The inbound queue scheduler and the
outbound queue scheduler ensure that the
corresponding
queues
(inbound
and
outbound) are processed in parallel. An
increase in the number of queues impairs the
performance of the scheduler, as it can no
longer process the queues in parallel. Its
hence best to limit the number of
inbound/outbound queues.

MONITORING THE SAP A BAP INSTANCE

Blocked queues:

Number

Ideally, the value of this measure should be
0. A non-zero value indicates that one/more
inbound/outbound queues are blocked. qRFC
queues can be blocked due to various
reasons such as no free work processes
(SYSLOAD), target system error (SYSFAIL),
transmission error(CPICERR), explicit lock,
dependent lock, debugging, waiting for
update, LUW execution error, LUW data
modification.

Number

Ideally, the value of this measure should be
0. If this measure reports a non-zero value
instead, it indicates that a serious error
occurred when the first logical unit of work
(LUW) of one/more queues was being
executed. SYSFAIL errors interrupt execution
of the LUW and generates short dumps on
the target system.

Indicates the current number
of queues in blocked state.

SYSFAIL queues:
Indicates the current number
of queues of this type in the
SYSFAIL error status.

To know which queues encountered SYSFAIL
errors, use the detailed diagnosis of this
measure.

SYSLOAD queues:

Number

Indicates the current number
of queues of this type in the
SYSLOAD error state.

Ideally, the value of this measure should be
0. If this measure reports a non-zero value
instead, it indicates that at the time of the
qRFC call, no DIALOG work processes were
free in the sending system. If these errors
persist, the number of dialog work processes
can be increased accordingly.
To know which queues encountered
SYSLOAD errors, use the detailed diagnosis
of this measure.

119

MONITORING THE SAP A BAP INSTANCE

CPICERR queues:

Number

Indicates the current number
of queues of this type in the
CPICERR error state.

Ideally, the value of this measure should be
0. If this measure reports a non-zero value
instead, it indicates that during transmission
or processing of the first LUW of one/more
queues, a network or communication error
occurred. Status CPICERR may also exist in
the
following
cases
although
no
communication error occurred: A qRFC
application finds out that a LUW cannot be
processed any further due to a temporary
error in the application and therefore calls the
RESTART_OF_BACKGROUNDTASK
function
module to prompt the qRFC Manager to
cancel the execution of this LUW and to
repeat this LUW later. In this case, qRFC
simulates a communication error with the
text "Command to tRFC/qRFC: Execute LUW
once again." If this error occurs very often,
you must contact the corresponding
application.
To know which queues encountered the
CPICERR errors, use the detailed diagnosis of
this measure.

Waiting queues:

Number

Indicates the current number
of queues of this type in the
WAITING state.

Ideally, the value of this measure should be
0. If this measure reports a non-zero value
instead, it indicates that the first LUW of
some queues has dependencies to other
queues, and at least one of these queues
currently still contains other LUWs with
higher priorities. Queues can also go into
waiting, if there are updates in the

transaction and and the queues have to
wait until the update ends.
To know which queues are in the WAITING
state currently, use the detailed diagnosis of
this measure.

120

MONITORING THE SAP A BAP INSTANCE

NoSend queues:

Number

Indicates the current number
of queues of this type in the
NOSEND state.

If this measure reports a non-zero value, it
indicates that the LUWs of some queues were
never sent but retrieved by a special
application. These queues are only used
internally at SAP. Even if a LUW has been
read by the corresponding application (BW,
CRM), this status does not change. This LUW
is only deleted from the queue if this
application confirms collection (collective
confirmation
possible).
Under
no
circumstances should this status be reset and
the queue activated.
Use the detailed diagnosis of this measure to
know which queues are NOSEND queues.

Long ready state queues:

Number

Indicates the number of
queues that have been in the
READY state for a long time.

This measure reports the count of all queues
that have been in the READY state for a
period
of
time
greater
than
the
LONGREADYCUTOFF (HRS) specification.
Typically, the READY state is a temporary
state. If this state becomes permanent for a
queue or is prolonged, it could be because
that queue has been locked manually via a
transaction/program and then unlocked
without being activated at the same time.
Under such circumstances, the queue must
be activated explicitly.

Long running queues:

Number

Indicates the number of
queues that have been
running for a long time.

This measure reports the count of all queues
that have been in the RUNNING state for a
period
of
time
greater
than
the
LONGRUNNINGCUTOFF
(HRS)
specification.
If a queue hangs in the RUNNING state for
more than 30 minutes, this may mean that
the work process responsible for sending this
LUW has been terminated. In this case, you
can activate this queue again.
Note that activating a queue in status
RUNNING may cause a LUW to be executed
several times if this LUW is still being
processed in the target system at that time.
SAP therefore recommends a waiting time of
at least 30 minutes before you reactivate the
queue.

121

MONITORING THE SAP A BAP INSTANCE

2.6.3

Gateways Test

The SAP Gateway carries out CPI-C services within the SAP world, which are based on TCP/IP. These services enable
SAP systems and external programs to communicate with one another. As RFC is based on CPI-C, all RFC
connections also pass through the SAP Gateway. This test reports statistics pertaining to this SAP gateway.

Purpose

Reports statistics pertaining to the SAP gateway

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

122

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server.
To view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for
a server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port
is 3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

10.

INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view
the complete list of instances to choose from, do the follow the procedure discussed in
Page 17 of this document.

11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a
response from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query
the metrics, you need to specify the version of the SAP JCO library that the agent needs to
use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you
specify the ‘major version number’ alone against JCO VERSION – in the case of this
example, this will be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP R/3 server being monitored

Measurement

Measurement
Unit

123

Interpretation

MONITORING THE SAP A BAP INSTANCE

Gateway clients:

Percent

The number of gateway
clients who are currently
connected to the SAP server,
expressed as a percentage of
the maximum number of
gateway clients allowed.
Gateway
utilized:

connections

For example, if the gateway can administrate
300 clients, and there are currently 30 clients
logged on to the gateway, the value is 10%.
If the value is near 100%, the maximum
number of clients can be changed using the
profile parameter gw/max_sys.

Percent

The number of gateway
connections currently utilized,
expressed as a percentage of
the maximum number of
gateway connections allowed.
Remote gateways:

Percent

Of the total number of
gateways, what percentage is
consumed
by
remote
gateways.
Gateway admin entries:

To administrate gateway connections, call
transaction SMGW on the server in question.
Percent

If the value is near 100%, the maximum
number of entries can be changed using the
profile parameter rdisp/max_comm_entries.

Percent

If a value is near 100%, the maximum
number of work processes can be changed
using the profile parameter gw/max_wp.

Percent

If a value is near 100%, the maximum
overflow size can be changed using the
profile parameter gw/max_overflow_size.

Of the maximum number of
gateway admin entries that
are allowed, what percentage
is being currently utilized.
Gateway work processes:
Of the maximum number of
gateway
work
processes
allowed, what percentage is
being used currently.
Gateway overflow usage:
Of the total gateway size,
what percentage of gateway
overflow has been used.

2.6.4

If the value is near 100%, the maximum
number of gateways can be changed using
the profile parameter rdisp/max_gateways.

RFC Calls Test

This test monitors the RFC connections that pass through the SAP gateway.

Purpose

Monitors the RFC connections that pass through the SAP gateway

Target of the
test

A SAP R/3 server

Agent
deploying the

An internal/remote agent

124

MONITORING THE SAP A BAP INSTANCE

test
Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP R/3 server being monitored

Measurement

Measurement
Unit

125

Interpretation

MONITORING THE SAP A BAP INSTANCE

Communication errors in
outbound RFC calls:
The
number
communication
errors
outbound RFC calls.

of
in

Execution
errors
outbound RFC calls:

Number

The number of execution
errors in outbound RFC calls.
Outbound calls
RFC resources:

without

Number

The number of errors with no
server
resources
for
outbound calls.
Inbound RFC calls:

Number

The number of inbound RFC
calls.

2.6.5

tRFC calls Test

Transactional RFC (tRFC) and qRFC are variants of the Remote Function Call that make the data transfer between
different systems more reliable and more secure. For each type of tRFC call, this test reports the number of calls that
were receorded , the number of calls that were executed. Using this test, administrators may figure out how many
calls were in states such as CPICERR, SYSFAIL, other states etc.

urpose

For each type of tRFC call, this test reports the number of calls that were receorded , the
number of calls that were executed. Using this test, administrators may figure out how many
calls were in states such as CPICERR, SYSFAIL, other states etc.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

126

MONITORING THE SAP A BAP INSTANCE

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. LONGWAITINGCUTOFF - Specify the time duration in hours beyond which the tRFC calls
are classified as stuck in the LONGWAITINGCUTOFF text box.
13. STUCKSTATES – By default, tRFC calls are prone to get stuck when in MAILED or
RECORDED states. In order to monitor those tRFC call that are stuck in these states, specify
these states as a comma-separated list in the STUCK STATES text box. The default is
MAILED,RECORDED. If you wish to monitor the tRFC calls that are stuck in HOLD state,
then you can specify MAILED,RECORDED,HOLD in this text box.
14. NEEDDDFOR OTHERSTATES - If you wish to disable the detailed diagnosis capability for
the Calls in other states measure of this test, then set the NEED DD FOR OTHER STATES
parameter to No. By default, this is set to Yes.
15. JCOVERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
16. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.

127

MONITORING THE SAP A BAP INSTANCE

17. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every SAP R/3 server being monitored

Measurement

Calls recorded:

Measurement
Unit
Number

Indicates the number of tRFC
calls of this type that were
recorded during the last
measurement period.
Calls executed:

Interpretation

A sudden/gradual increase in the value of this
measure could indicate issues such as
insufficient configuration of connection
resources for transactions.

Number

Indicates the number of tRFC
calls of this type that were
executed during the last
measurement period.
CPICERR calls:

Number

Indicates the number of tRFC
calls of this type with
communication errors i.e., the
number of tRFC calls in
CPICERR state during the last
measurement period.

SYSFAIL calls:

CPICERR error arises due to connection of
communication issues with the target system
or external component. CPICERR calls may
be retried.
The detailed diagnosis of this measure if
enabled, lists the details about these calls
such as the host, process ID, timestamp,
destination, function, user, retries, Tcode and
error message.

Number

Indicates the number of tRFC
calls of this type that were in
SYSFAIL state during the last
measurement period.

SYSFAIL error arises due to error in execution
of tRFC call in target system or external
component.
The detailed diagnosis of this measure if
enabled lists the details about these calls
such as the host, process ID, timestamp,
destination, function, user, retries, Tcode and
error message.

128

MONITORING THE SAP A BAP INSTANCE

Number of calls mailed:

Number

Indicates the number of tRFC
calls of this type for which
CMC
(protocol
X400)
connection
was
initiated
during the last measurement
period.
Calls executed in target:

Number

Indicates the total number of
tRFC calls of this type that
were executed in the target
SAP system during the last
measurement period.
Calls in other states:

Number

Indicates the number of tRFC
calls of this type that were in
intermediary states such as
HOLD, WCONFIRM, SYSLOAD
etc
during
the
last
measurement period.
Long waiting calls:

The detailed diagnosis of this emasure if
enabled lists the details for these calls using
which you can figure out any abnormal/error
states.
Number

Indicates the number of tRFC
calls of this type that were
stuck in any state beyond the
time specified against the
longwaitingCutOff parameter
while configuring this test.

2.6.6

Tracking these calls become important when
typical tRFC issues are encountered.

tRFC calls can get stuck in certain states due
to various reasons such as insufficient errors
or intermediate errors, communication issues
etc. Such calls need to be either manually
processed or an appropriate report can be
configured to process any known issues.
Use the detailed diagnosis of this measure for
further analysis of such calls.

Internet Communication Manager Test

The Internet Communication Manager (ICM) facilitates communication between SAP system(s) and the internet using
the HTTP, HTTPS, and SMTP protocols. Requests received from the internet are forwarded to SAP system for
processing via the ICM. Likewise, the ICM also sends SAP requests to the internet, gets the feedback and transfers it
to the SAP system.
The ICM is implemented as an independent process and is started and monitored by the dispatcher. The ICM process
uses a pool of worker threads to parallel process the load. This is why, if a sudden/consistent slow down is noticed in
a SAP system’s interactons with the internet, the first place administrators need to check for inconsistencies is this
thread pool. The absence of adequate threads in the pool can significantly impair the ICM’s ability to uniformly
distribute the request load across threads, thereby causing one/more threads be ove-utilized; ultimately, this will
result in a slowdown! Besides erratic thread pool usage, the sudden unavailability of the ICM and over-utilization of
ICM connections can also cause disturbances in a SAP system’s internet communications. To ensure that such
anomalies are promptly captured and corrected, administrators should keep an eye on the accessibility of the ICM, its
thread pool usage, and availability of ICM connections. This is where the Internet Communication Manager test helps!
This test periodically checks the availability, thread pool usage, and connection utilization of the ICM, and promptly
reports the non-availability of the ICM, abnormal usage of worker threads by the ICM, and the over-utilization of ICM
connections. This way, the test leads administrators to the probable causes for the breaks / slowness in the
communication between the SAP system and the internet.
129

MONITORING THE SAP A BAP INSTANCE

Purpose

Periodically checks the availability, thread pool usage, and connection utilization of the ICM, and
promptly reports the non-availability of the ICM, abnormal usage of worker threads by the ICM,
and the over-utilization of ICM connections

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

130

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.

131

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP ABAP instance being monitored

Measurement
Unit

Measurement

This measure reports the value Yes if the ICM
is running, and No if the ICM is not running.

Is available ?:
Indicates whether/not
ICM is running.

Interpretation

the

The numeric values that correspond to the
above-mentioned measure values are as
follows:
Measure Value

Numeric Value

Yes

100

Note:
By default, the test reports the abovementioned Measure Values to indicate
whether/not the ICM is available. However, in
the graph of this measure, the same is
represented using the numeric equivalents
only.
If the value of this measure is No, then it
indicates
that
the
HTTP/HTTPS/SMTP
communication to the SAP ABAP insitance is
disrupted.
Current threads:

Number

Indicates the number of
threads that were currently
created from the pool for
processing requests.
132

A high value denotes a high level of activity
on the ICM.

MONITORING THE SAP A BAP INSTANCE

Free threads:

Number

Indicates the number of
threads that can be created
from the pool for processing
requests.
Thread utilization:

Percent

A value close to 100% denotes over-usage of
threads. You may then have to increase the
maximum threads in pool configuration to
allow more threads to be created for
processing requests, so that processing
bottlenecks can be eliminated.

Percent

Threads waiting for data from network or
application server / server response / client
response are classified as waiting threads.
Threads waiting for a long time result in
sustained increase in waiting threads and are
indicative of a generic network / application
server issue.

Number

A consistent rise in this value could indicate a
potential overload condition, typically caused
by insufficient threads in pool. You may
hence have to resize the pool to prevent
requests from queuing up.

Percent

A value close to 100% is a cause for concern,
as it indicates that almost all requests are
being queued. This again points to a loadbalancing irregularity, probably caused by the
lack of adequate threads in the pool.

Number

The number of simulatenously open
connections and their sockets can be
deduced from this measure.

Percent

Each request can create multiple connections.
This measure therefore helps to gauge the
level activity at the ICM (web dispatcher), so
that the system load can be observed and the
relevant profile parameters can be tuned
accordingly. For instance, a value close to
100% for this measure, may mandate that
the icm/max_conn parameter be increased,
so that enough connections are always
available.

Indicates the percentage of
maximum threads (in pool)
that have been created
currently
for
processing
requests.
Percentage
threads:

waiting

Indicates the percentage of
maximum threads (in pool) to
that are currently waiting for
data to be processed..
Number
queue:

requests in

Indicates the number of
requests waiting for free ICM
threads.
Request queue utilization:
Indicates the percentage of
total requests that are in
queue currently.
Connections used:
Indicates the number of
currently open connections.
Connection utilization:
Indicates the percentage of
currently open connections.

133

MONITORING THE SAP A BAP INSTANCE

Inactive services:
Indicates the number
inactive ICM services.

Number
of

The detailed diagnosis of this measure
provides details of the inactive services.
These details include the service name, keep
alive connection status, backend processing
timeout, port, hostname and whether/not
external bindings are used.

2.7 The SAP Service Layer
The tests depicted by Figure 2.21 help administrators to find quick and accurate answers to the following questions:

 Are all R/3 sub-systems functioning smoothly, or has any sub-system reported errors? If
so, how many errors were reported?

 Is the Dialog service taking too long a time to respond to requests? If so, where does the
maximum delay take place - during network transfer or in the queue or during GUI callback or at the database end?

 Is the SAP R/3 server available? What is the connection time?
 Are too many users logged on to the SAP R/3 system? If so, who are they and what are
the client activities they are logged into?

134

MONITORING THE SAP A BAP INSTANCE

Figure 2.21: The tests associated with the SAP Service layer

2.7.1

Batch Inputs Test

Batch input is one of the primary ways in which data can be transferred into the SAP ABAP System. Batch input is
used for bulk data transfers and not for near real-time data transfers.
Typical uses of batch input include the one-time import of data from a legacy system into a newly installed SAP ABAP
System. Another typical use is for periodic (hourly, daily...) transfers of data from external systems or legacy systems
that are still in use into SAP ABAP, where all enterprise data is consolidated.
A batch input session is a set of one or more calls to transactions along with the data to be processed by the
transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of
bulk data into an SAP ABAP System.
Administrators should periodically check whether/not the batch input sessions have completed successfully. If bulk
transfers into the SAP ABAP system via these sessions is interrupted, then administrators should be able to promptly
capture the errors in sessions, instantly initiate error analysis, and rapidly correct the problem. The Batch Inputs test
enables administrators to perform all this and more! This test monitors the batch input sessions, promptly detects
errors in sessions, and accurately points administrators to those sessions where errors have occurred. In addition,

135

MONITORING THE SAP A BAP INSTANCE

the test periodically measures the load on the SAP ABAP system by reporting the number of created and running
sessions, and in the process, warns administrators of probable overload conditions.

Purpose

Monitors the batch input sessions, promptly detects errors in sessions, and accurately points
administrators to those sessions where errors have occurred; also, periodically measures the
load on the SAP ABAP system by reporting the number of created and running sessions, and in
the process, warns administrators of probable overload conditions

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

136

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.

137

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP ABAP instance being monitored

Measurement

Measurement
Unit

138

Interpretation

MONITORING THE SAP A BAP INSTANCE

Error sessions:

Number

Indicates the current number
of batch input sessions with
errors.

Ideally, the value of this measure should be
0. A non-zero value indicates that
transactions in one/more sessions ended in
errors. A transaction contains an error if it
issues a message of type E (error) or type A
(abnormal
termination).
In
such

situations, the system administrator must
analyze the error.
Most errors fall into one of two categories:
Required data is missing from the
batch-input session or invalid data
has been included in the session.
Possible external causes of this type
of problem include errors in the data
conversion program or the presence
of unexpected types of data or
incorrect data in the legacy
database. Causes for this type of
problem within R/3 include incorrect
or incomplete customizing in an
application. For example, a legacy
data type may not have been
foreseen in the check table entries
made in application customizing.
Technical/programming problems. A
batch input session enters data by
running R/3 transactions noninteractively. A typical technical or
programming problem is therefore
incorrect identification of one of the
data fields in a transaction. Or the
conversion program may not fill a
required data field or may have
provided invalid values.

You can use the detailed diagnosis of
this measure to know which batch input
sessions encountered what type of
errors.
To correct transactions with errors, the
system administrator or the responsible
department can interactively correct and
reprocess the transactions.

139

MONITORING THE SAP A BAP INSTANCE

Background sessions:

Number

Indicates
the
current
number of batch input
sessions running in the
background.

The data in a batch input session can be
processed in one of the three modes:
Process/foreground: Runs the
session
in
the
foreground,
displaying every screen and field.
If you change a screen in this
option, the process halts.
Display errors only: Runs the
session
in
the
foreground,
displaying only errors.
Background: Runs the session in
the background.
The Background sessions measure reports
the number of sessions currently running in
the background mode. Since sessions are
typically run in this mode to execute the data
transfer or test its performance, you can use
the Background sessions measure as an
indicator of the number of data transfer
sessions the SAP ABAP system can handle at
a given point in time.

Inprocess sessions:

Number

Indicates the number of
batch input sessions that are
currently running.
Sessions being created:

Number

Indicates the number of
batch
input
sessions
being created.

140

This is a good indicator of the current batch
input session load on the SAP ABAP system.

MONITORING THE SAP A BAP INSTANCE

2.7.2

Event linkages Test

The type linkage describes the assignment of a receiver function module and a receiver type to a particular
combination of object type and event.
A type linkage must be created if the system is always to react to an event of a particular object type. The type
linkages are evaluated at runtime by the event manager.
The event receiver should define a type linkage using a function module provided.
Type linkages are client-dependent and are written automatically into a Customizing transport request if the client is
configured (in table T000 ) for changes to be recorded automatically. All entries are then transported including
activation indicators.
In the case of client copy, you should ensure that the type linkages are copied into the target client, but are always
deactivated in the target client. The activation indicator of each individual type linkage is only copied with client copy
if explicitly requested (parameter option for copying tables of class A).
The event manager begins the evaluation of the active type linkages when it is notified of the ID of a created event.
For event handling to take place, either the event created and its triggering object type or the event created and a
supertype of the triggering object type must be entered for the type linkage.
An appropriate workflow is always started as a reaction to an event of a particular object type. Whenever workflow
start is delayed or there is a sudden decrease in the number of workflows that are started, then the administrators
may need to analyze the real cause behind such delays! Ususally such delays are caused when the event linkages are
inactive and when errors are detected in the event linkages. Therefore it becomes essential to monitor the event
linkages and keep a constant vigil on the number of inactive linkages and the number of linkages with errors. The
Event linkages test helps you in this regard.
This test monitors the event linkges and helps you figure out how many linkages are available on the server and how
many are currently active/inactive on the server. In addition, this test helps the administrators identify the number of
event linkages with errors and figure out the real reason behind such errors.

Purpose

Monitors the event linkges and helps you figure out how many linkages are available
on the server and how many are currently active and inactive on the server. In
addition, this test helps the administrators identify the number of event linkages with
errors and figure out the real reason behind such errors.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

141

MONITORING THE SAP A BAP INSTANCE

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, follow the procedure discussed in Page 17 of this
document.
11. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
12. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.
14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
o

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

142

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Total linkages:

Measurement
Unit

Interpretation

Number

Indicates the number of type
linkages defined on the
server.
Active linkages:

Number

Indicates the type linkages
that are currently activated
on the server.
Inactive linkages:

Number

Indicates the number of type
linkages that are currently
inactive on the server.

Percentage of linkages
that are inactive:

The event rerceivers will respond to events
only when the type linkages are active.
The detailed diagnosis of this measure if
enabled, lists the linkage details such as the
Client, Business object, event description,
receiver type, receiver function modules,
error linkage etc.

Percent

A low value is desired for this measure.

Number

Receivers will immediately respond to events
only if the event linkage is active is without
any errors. Active linkages with errors result
in the event being queued with error status
and these linkages have to be reprocessed
manually, if needed.

Indicates the percentage of
type linkages that were
inactive.
Error linkages:
Indicates the number of type
linkages with errors.

Ideally, the value of this measure should be
zero. If the value of this measure is
abnormally high, then it indicates that there
are too many errors in the linkages which
eventually results in the delay in processing
and lead to a delayed response to the events
by the receivers.
The detailed diagnosis of this measure if
enabled, lists the corresponding type linkage
details such as Client, Business object type,
event description, receiver type, receiver
function modules, error linkage etc.
143

MONITORING THE SAP A BAP INSTANCE

Percentage of
with errors:

linkages

Number

Indicates the percentage of
type linkages with errors.

2.7.3

R3 Dumps Test

This test reports the occurrence of ABAP short dumps.

Purpose

Reports the occurrence of ABAP short dumps

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

144

A high value for this measure is a cause of
concern.

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
o

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

145

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for the SAP R/3 server being monitored

Measurement

Total short dumps:

Measurement
Unit

Interpretation

Number

The total number of ABAP
short dumps that have
occurred.
New short dumps:

Number

The number of ABAP short
dumps that have occurred
during the last measurement
period

2.7.4

R3 Status Messages Test

The different SAP R/3 sub-systems report the status of different activities carried out. This test indicates whether
each sub-system's activities are successfully carried out or not.

Purpose

Indicates whether each sub-system's activities are successfully carried out or not

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

146

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and
the server exist in the same network, then specify 'none' against the ROUTER text box.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to
use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you
specify the ‘major version number’ alone against JCO VERSION – in the case of this
example, this will be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
o

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

147

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 sub-system being monitored

Measurement

Total messages:

Measurement
Unit

Interpretation

Number

The total number of error
messages present in R/3's
sub-system.
New messages:

Number

The
number
of
error
messages that were newly
generated in the R/3's subsystems.

2.7.5

Dialog Response Test

This test monitors the responses sent by the Dialog service, and returns key performance metrics pertaining to the
responses.

Purpose

Monitors the responses sent by the Dialog service, and returns key performance metrics
pertaining to the responses

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

148

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP). \
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement

Measurement
Unit

149

Interpretation

MONITORING THE SAP A BAP INSTANCE

Total response time for a
dialog step:

Secs

If the user response time increases, while the
standard response time remains stable, it
means that the problem must be at the front
end or in the connection to the application
server.

Secs

The value of this measure does not include
round trips.

Secs

With a normal workload, there should always
be free dialog work processes available. In
such a case, the wait time will only be a few
milliseconds.

The average time that the
user waits at the front end for
his or her request to be
processed. It is the sum of
the Dialog process time,
Network transfer time, Queue
time and GUI Callback time.
Network transfer time for
a dialog step:
The time taken by the
network for the first data
transfer between the front
end and the application
server and during the last
data transfer from the
application server to the front
end.
Queue time
process:

for

dialog

The average wait time in the
dispatcher wait queue.
GUI callback time:

Secs

The average length of time
that a work process waits for
the front end during the
communication between the
application server and the
front end.
Dialog process time:

Secs

Check the CPU performance, system paging,
dialog work processes, and database
performance for any performance lag in the
dialog process time.

The total time that is required
for processing a SAP R/3
dialog step, including the
database processing time.
Load generation time:

Secs

The average load generation
time
for
source
texts,
graphical user interfaces and
screen information from the
database.

150

MONITORING THE SAP A BAP INSTANCE

Database response time
for the dialog step:

Secs

Read requests can either be sent to the
database buffers or to the fast local SAP
buffers. The efficiency of the buffers, the
required number of requests as well as a
large number of database change requests
affect the total access time. The database
access time also takes into account the db
server, CPU performance as well as network
transfer times.

Secs

If the dialog response time is deteriorating
consistently, while the standard response
time remains stable, check the number of
users logged on. If there are only a small
number of users, the use of very resourceintensive transactions by one user can, in
extreme cases, significantly increase the
response time. If this is the case, there is
often no serious performance problem.

The
average
time
for
processing logical database
requests.

Dialog std response time:
The time taken for a standard
transaction that simulates the
normal
workload
of
a
transaction by accessing data
on
the
database
and
executing a series of ABAP
function modules.

2.7.6

R3 Connection Test

This test emulates a client access to the SAP R/3 server, and reports the server availability and connect time.

Purpose

Emulates a client access to the SAP R/3 server, and reports the server availability and connect
time.

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

151

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 server being monitored

Measurement
Unit

Measurement
SAP
R/3
availability:

server

Percent

Whether the SAP server is
available or not.

152

Interpretation
The value 0 for this measure indicates that
the server is not available. The value 100
indicates server availability.

MONITORING THE SAP A BAP INSTANCE

Connect time:

Secs

Time taken for the SAP client
to connect to the SAP server.
Command execution time:

Secs

Time taken by the server to
execute a command.

2.7.7

R3 Users Test

This test displays the number of users logged on to various client activities of the R/3 server.

Purpose

Displays the number of users logged on to various client activities of the R/3 server

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

153

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORTNO - Enter the port to which the specified HOST listens
4. CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.
5. SAPUSER - Provide a valid user name for logging into the SAP R/3 server. In order to
enable the eG Enterprise suite to effectively monitor SAP, the name of a SAPUSER with
either of the following profiles need to be specified: S_A.SYSTEM (super administrator) or
SAP_ALL (all authorizations for SAP).
6. PASSWORD - The password of the specified SAPUSER.
7. CONFIRMPASSWORD - Confirm the password by retyping it here.
8. SYSNO - An indicator of the TCP/IP port at which the SAP server listens. For example, for a
server that listens at port 3200, the SYSNO will be '00'. Similarly, if the SAP server port is
3201, the SYSNO will have to be specified as '01'. Therefore, in the SYSNO text box
specify the system number of the SAP server with which the specified client communicates.
9. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external
to the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCOVERSION - The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
14. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
o

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

154

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

One set of results for every SAP R/3 sub-system being monitored

Measurement

Current users:

Measurement
Unit
Number

The number of users logged
on to various client activities
of the R/3 server.

2.7.8

Interpretation

The detailed diagnosis of this measure, if
enabled, provides the details of the currently
logged in users.

R3 Log Test

The R3 Log test monitors the SAP R/3 server's log files for specific error patterns. This test is disabled by default.
This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page using the menu sequence
: Agents -> Tests -> Enable/Disable, pick SAP R/3 as the Component type, set Performance as the Test type, choose
this test from the DISABLED TESTS list, and click on the >> button to move the test to the ENABLED TESTS list. Finally,
click the Update button.

Purpose

Monitors the SAP R/3 server's log files for specific error patterns

Target of the
test

Log files of the SAP R/3 server

Agent
deploying the
test

An internal agent

155

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured.
3. PORT – The port at which the server listens
4. ALERTFILE - Specify the path to the SAP R/3 server log file to be monitored. For eg.,
/usr/saplog/slog.log. Multiple log file paths can be provided as a comma-separated list - eg.,
/user/john/sapalerts.log,/tmp/log/slog01.log .
Also, instead of a specific log file path, the path to the directory containing log files can be
provided - eg., /user/logs. This ensures that eG monitors the most recent log files in the
specified directory. Specific log file name patterns can also be specified. For example, to
monitor the latest log files with names containing the string 'slogs', the parameter
specification can be, /tmp/usr/*slogs*. Here, '*' indicates leading/trailing spaces (as the
case may be). In this case, the eG agent first enumerates all the log files in the specified
path that match the given pattern, and then picks only the latest log file from the result set
for monitoring.
The eG monitor interface will report one set of measurements for every configured path.
You can also configure the path in the following format: Name@logfilepath. Here, Name
represents the display name of the path being configured. Accordingly, the parameter
specification for the 'slogs' example discussed above can be: slogs@/tmp/usr/*slogs* . In
this case, the display name 'slogs' will alone be displayed as descriptors of the test.
Every time this test is executed, the eG agent verifies the following:
c.

Whether any changes have occurred in the size and/or timestamp of the log
files that were monitoring during the last measurement period;

Whether any new log files (that match the ALERTFILE specification) have been
newly added since the last measurement period;

5. SEARCHPATTERN - Enter the specific patterns of alerts to be monitored. The pattern
should be in the following format: :, where is
the pattern name that will be displayed in the monitor interface and is an
expression of the form - *expr* or expr or *expr or expr*, etc. A leading '*' signifies any
number of leading characters, while a trailing '*' signifies any number of trailing characters.
For example, say you specify SAP:*SAPSYS* in the SEARCHPATTERN text box. This
indicates that "SAP" is the pattern name to be displayed in the monitor interface.
"*SAPSYS*" indicates that the test will monitor only those lines in the R/3 server log which
embed the term "SAPSYS". A single pattern may also be of the form e1+e2, where +
signifies an OR condition. That is, the PatternName is matched if either e1 is true or e2 is
true.

156

MONITORING THE SAP A BAP INSTANCE

Multiple search patterns can be specified as a comma-separated list. For example:
SAP:*SAPSYS*,SAPAL:*DDIC*.
If the ALERTFILE specification is of the format Name@logfilepath, then the descriptor for
this test in the eG monitor interface will be of the format: Name:PatternName. On the other
hand, if the ALERTFILE specification consists only of a comma-separated list of log file
paths, then the descriptors will be of the format: LogFilePath:PatternName.
If you want all the messages in a log file to be monitored, then your specification would be:
:*.

6. LINES - Specify two numbers in the format x:y. This means that when a line in the alert
file matches a particular pattern, then x lines before the matched line and y lines after the
matched line will be reported in the detail diagnosis output (in addition to the matched
line). The default value here is 0:0. Multiple entries can be provided as a comma-separated
list.
If you give 1:1 as the value for LINES, then this value will be applied to all the patterns
specified in the SEARCHPATTERN field. If you give 0:0,1:1 as the value for LINES and if
the
corresponding
value
in
the
SEARCHPATTERN
filed
is
like
SAP:*SAPSYS*,SAPAL:*DDIC* then:

 0:0 will be applied to SAP:*SAPSYS* pattern
 1:1 will be applied to SAPAL:*DDIC* pattern
7. EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded from
monitoring in the EXCLUDEPATTERN text box. For example *critical*,*exception* . By
default, this parameter is set to 'none'.

157

MONITORING THE SAP A BAP INSTANCE

9. ROTATINGFILE - This flag governs the display of descriptors for this test in the eG
monitoring console.
If this flag is set to true and the ALERTFILE text box contains the full path to a specific
(log/text) file, then, the descriptors of this test will be displayed in the following format:
Directory_containing_monitored_file:. For instance, if the ALERTFILE
parameter is set to c:\eGurkha\logs\syslog.txt, and ROTATINGFILE is set to true, then,
your descriptor will be of the following format: c:\eGurkha\logs:. On the
other hand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of
the following format: : - i.e., syslog.txt: in
the case of the example above.
If this flag is set to true and the ALERTFILE parameter is set to the directory containing log
files, then, the descriptors of this test will be displayed in the format:
Configured_directory_path:. For instance, if the ALERTFILE parameter is
set to c:\eGurkha\logs, and ROTATINGFILE is set to true, then, your descriptor will be:
c:\eGurkha\logs:. On the other hand, if the ROTATINGFILE parameter
had been set to false, then the descriptors will be of the following format:
Configured_directory: - i.e., logs: in the case of the
example above.
If this flag is set to true and the ALERTFILE parameter is set to a specific file pattern,
then, the descriptors of this test will be of the following format:
:. For instance, if the ALERTFILE parameter is set to
c:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor will be:
*sys*:. In this case, the descriptor format will not change even if the
ROTATINGFILE flag status is changed.

10. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.

11. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

12. DETAILED DIAGNOSIS

- To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:



The eG manager license should allow the detailed diagnosis capability

 Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test

One set of results for every SEARCHPATTERN

158

MONITORING THE SAP A BAP INSTANCE

Measurements
made by the
test

Measurement
Number of messages:

Measurement
Unit
Number

Indicates the number of
messages of the configured
patterns that were added
to the SAP R/3 server logs
when the test was last
executed.

2.7.9

Interpretation
The value of this measure is a clear indicator
of the number of “new” alerts that have
come into the monitored logs.

Syslog errors Test

The SysLog aka “System Logging” is a text file where selected events and problems within a SAP ABAP instance are
generally logged.
This test monitors the syslog file and for each event type logged into the file, this test reports the numerical statistics
of the total number of messages logged, the messages that were entered due to transaction problems, application
server and memory related isssues. In addition, this test reports the error messages and the warings that were
entered. This way, administrators may identify the event type that is more error prone and take remedial measures
to rectify the same before any severe issue crop up!.

Purpose

Monitors the syslog file and for each event type logged into the file, this test reports the
numerical statistics of the total number of messages logged, the messages that were entered
due to transaction problems, application server and memory related isssues. In addition, this
test reports the error messages and the warings that were entered

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

159

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
13. JCO VERSION – Here, specify the major version of the JCO library that has been deployed
on the eG agent that is communicating with the SAP server. The value of this version is
either 2.x or 3.x where x relates to any of the minor releases.
14. CUSTOMPATTERNS – Specify a comma separated list of custom patterns for which this
test should report metrics for. You can specify the patterns in the
PatternName:Patternstring format. However, the PatternName is optional. If the
PatternName is specified, then this PatternName is displayed as the descriptor of this test in
the eG monitor interface. If the PatternName is not specified, then the PatternString alone is
specified as the descriptor of this test. By default, none will be displayed against this
parameter.
15. SHOWALERTSONLY – By default, this test monitors all the syslog messages logged in the
syslog file. If you wish to monitor only those syslog messages for which alerts were
generated in the SAP ABAP server instance, then set this flag to Yes.

160

MONITORING THE SAP A BAP INSTANCE

16. SEVERITYCUTOFF – By default, each syslog message is mapped to a severity value.
Specify a severity value against this text box beyond which all syslog messages are included
in the scope of montoiring. By default, the value of this parameter is 49.
17. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every SAP R/3 server being monitored

Measurement

Transaction problems:

Measurement
Unit
Number

Indicates the number of
messages of this type entered
in the syslog file with
transaction problems during
the last measurement period.

Warnings:

Transaction problems indicate problems while
invoking transaction codes.
The detailed diagnosis of this measure if
enabled, lists the details such as the user
executing the Tcode, the client, the terminal
logged in by the user, program that is
currently executing, timestamp of the problem
message, severity and alert message and the
actual problem message.

Number

The detailed diagnosis of this measure if
enabled, lists the details such as the user
executing the Tcode, the client, the terminal
logged in by the user, program that is
currently executing, timestamp of the problem
message, severity and alert message and the
actual problem message.

Number

Indicates the number of
warning messages of this
type that were entered in the
syslog file during the last
measurement period.
Dumps messages:

Interpretation

Indicates the number of
dump messages of this type
that were entered in the
syslog file during the last
measurement period.

161

MONITORING THE SAP A BAP INSTANCE

AS problems:

Number

Indicates the number of
application server problem
messages of this type that
were entered in the syslog
file
during
the
last
measurement period.

Memory messages:

Indicates the total number of
memory related messages of
this type that were entered in
the syslog file during the last
measurement period.

Error messages:

Number

The detailed diagnosis of this measure if
enabled, lists the name of the user executing
the Tcode, the client, the terminal logged in
by the user, Program that is currently
executing, Timestamp, severity and alert
message and the actual problem message.

Number

This measure is a good indicator of the issues
occurring on the SAP instance.

Indicates the total number of
messages
of
this
type
available in the syslog file
during the last measurement
period.

2.7.10

Use these messages to identify memory
related issues with the SAP ABAP instance.
The detailed diagnosis of this measure if
enabled, lists the details such as the user
executing the Tcode, the client, the terminal
logged in by the user, program that is
currently executing, timestamp of the problem
message, severity and alert message and the
actual problem message.

Indicates the error messages
of this type that were entered
ni the syslog file during the
last measurement period.
Total issues:

Use these messages to trace problems that
occurred when the application server was
operated.

The value of this measure is cumulative of
the Transaction problems, Warnings, Dumps
messages, AS problems, Memory messages
and Error messages measures.

TemSe Test

TemSe is the SAP store location for temporary sequential data. When the Temse are grows rapidly, it becomes
tedious for the adminsitrators to locate what exactly caused the growth of the Temse area and which Temse object
contributed to this abnormal growth? Use the Temse test to figure out the answers to such questions.
This test reports the rate at which each Temse object was created due to spool requests, background jobs and
activity in the HR module. In addition, this test reports how well the data is copied to the Temse object. This way,
administrators may figure out the Temse object that occupied more space and the Temse object that was created
the most.

Purpose

Monitors the functioning of the spool system, and reports the extent of its utilization, the length
of the wait queues, etc.

Target of the
test

A SAP R/3 server

Agent
deploying the

An internal/remote agent

162

MONITORING THE SAP A BAP INSTANCE

test
Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.
13. JCOVERSION –The eG agent uses the SAP JCO library to connect to the SAP ABAP system
and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.

Outputs of the
test
Measurements
made by the
test

One set of results for each Temse object of the SAP R/3 server being monitored

Measurement

Measurement
Unit

163

Interpretation

MONITORING THE SAP A BAP INSTANCE

Total
rate:

TemSe

creation

Parts/sec

This measure is a good indicator of the rate
at which the Temse data has grown. If the
value of this measure is high, administrators
can consider reorganizing/provisioning the
TemSe data accordingly.

Parts/sec

This measure is a good indicator of the
growth in the Temse area due to
spool/printing requests.

Indicates the rate at which
this Temse object was
created during the last
measurement period.
TemSe creation rate for
spool requests:
Indicates the rate at which
this Temse object was
created due to spool requests
during the last measurement
period.
TemSe creation rate for
jobs:

Parts/sec

Indicates the rate at which
this Temse object was
created due to background
jobs
during
the
last
measurement period.
HR TemSe creation rate:

Parts/sec

Indicates the rate at which
this Temse object was
created during the last
measurement period due to
the activity in the HR module
of the SAP ABAP instance.
TemSe data rate:

MB/sec

Indicates the rate at which
data was copied to the Temse
area of this Temse object
during the last measurement
period.

2.7.11

This measure can also be used for
provisioning/reorganization of the TemSe
space and also helps in detecting TemSe
issues created due to causes like huge spool
requests, overutilization by background jobs
etc.,

CTS Monitor Test

Change and Transport System (CTS) is the tool provided by SAP for the creation, documentation and distribution of
changes within a system landscape.
Using this test, administrators may figure out the number of requests that were created, how many of those requests
were successful and how many succeeded with errors. In addition, you may figure out how many transport requests
were partially successful and how many requests encountered critical errors. This way, administrators may figure out
how well the transport requests were processed and the exact cause behind the error prone requests.

Purpose

Helps you figure out the number of requests that were created, how many of those requests
were successful and how many succeeded with errors. In addition, you may figure out how
many transport requests were partially successful and how many requests encountered critical
errors
164

MONITORING THE SAP A BAP INSTANCE

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against dd
frequency.

165

MONITORING THE SAP A BAP INSTANCE

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every SAP R/3 server being monitored

Measurement

Total exports:

Measurement
Unit

Interpretation

Number

Indicates the total number of
requests that were created
during the last measurement
period.
Successful exports:

Number

The TPALOG return code for these requests
is 0000.

Number

The TPALOG return code for these requests
is 0004. Warnings could be innocuous as in
regular warnings issued when the transport
request
involves
object
deletion.
Nevertheless, these warnings need to be
checked.

Parts/sec

The TPALOG return code for these requests
is 0008. These errors need to be analyzed
and corrected. Examples of such errors
include original/repaired objects not being
overwritten. Detailed diagnosis for this
measure provides details of these requests
such as : Request timestamp, Request
number, target system, source client,
transport step, project number, transport user
and transport admin.

Indicates the number of
transport requests that were
successful during the last
measurement period.
Succeeded with warnings:
Indicates the number of
transport
requests
that
succeeded with warnings
during the last measurement
period.
Partial successes:
Indicates the number of
transport requests that were
partially successful during the
last measurement period.

166

MONITORING THE SAP A BAP INSTANCE

Percentage
successes:

partial

Percent

The TPALOG return code for these requests
is 0008. Typically these errors arise due to
transport request configuration as opposed to
a transport system error.

Number

The TPALOG return code for these requests
is 0012 or higher. These errors usually arise
due to some serious error in the transport
system and hence tend to impact a majority
of the transport requests.

Indicates the percentage of
transport requests that were
partially successful during the
last measurement period.
Critical errors:
Indicates the number of
transport
requests
with
critical errors during the last
measurement period.

The detailed diagnosis of this emsaure if
enabled lists the details of these requests
such as Request timestamp, Request
number, target system, source client,
transport step, project number, transport user
and transport admin.
Percentage
errors:

critical

Percent

Indicates the percentage of
transport
requests
with
critical errors during the last
measurement period.

2.7.12

The TPALOG return code for these requests
is 0012 or higher. These errors tend to
correspond to the overall availability of the
transport system.

New alerts in the last measure period

Every SAP solution is bundled with a monitoring architecture, and alerts form a central element of this architecture.
They quickly and reliably report errors – such as values exceeding or falling below a particular threshold value or that
a SAP component has been inactive for a defined period of time. These alerts are displayed in the Alert Monitor - this
is a central tool that facilitates efficient administration and monitoring of distributed SAP solutions.
An alert is uniquely assigned to one monitoring tree element (MTE) in the Alert Monitor. A set of monitoring tree
elements (MTEs) that are arranged in a hierarchical structure becomes a Monitor. These Monitors can be grouped to
form a Monitor Set.
The alerts contain a status indicator with a color and a numerical value. Yellow means a warning, red means a
problem, green means normal, and the numerical value shows the severity of the reported error.
Using APIs provided by SAP, this test pulls out useful statistics related to SAP R/3 alerts from the AlertMonitor.
Besides reporting the total number of alerts generated on every Monitor that is configured, the test also reveals the
number of alerts in various states (red, yellow, green, etc.). You can even optionally generate detailed measures to
view additional alert information such as the alert description and its severity. This way, the eG monitoring console
serves as a single, central platform that displays the details of the open and completed alerts related to a monitored
SAP R/3 server.

Purpose

Reports useful statistics related to SAP R/3 alerts

Target of the
test

A SAP R/3 server

167

MONITORING THE SAP A BAP INSTANCE

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.

10. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
11. ROUTER - If the SAP client with the specified CLIENTNAME exists in a network external to
the SAP server, then a router will be used to enable the server-client communication. In
such a case, specify the IP of the router in the ROUTER text box. If both the client and the
server exist in the same network, then specify 'none' against the ROUTER text box.
12. SETS - Provide a comma-separated list of monitor sets for which performance attributes
are to be monitored. For example: SAP CCMS Monitor Templates,Monitor Collection for

Certification
13. MONITORS - Provide a comma-separated list of monitors under the configured monitor
SETS for which performance attributes are to be monitored. While specifying the list of
MONITORS, make sure that you specify them in the same order as that of your monitor
SETS specification. For instance, the first monitor in your MONITORS list should belong to
the first monitor set in your SETS specification, and so on. This implies that if your SETS
specification reads as follows - SAP CCMS Monitor Templates,Monitor Collection for
Certification - then the first monitor in your MONITORS specification should belong to the
SAP CCMS Monitor Templates set and the second monitor should belong to the Monitor
Collection for Certification set. In this case, your MONITORS specification may read as
follows: Dialog Overview,Test Monitor Syslog .

168

MONITORING THE SAP A BAP INSTANCE

If you want to include more than one monitor from a particular monitor set in your
MONITORS specification, then make sure that you repeat that monitor set’s name as many
times in your SETS specification.
While configuring the SETS and MONITORS , you may want to know the exact names
of the monitors and monitor sets that form part of your specification. To determine this,
follow the procedure discussed in Page 176 of this document.
14. XMI AUDIT LEVEL - The XMI interface is a general framework for the CCMS external
system management interfaces. This interface contains essential function modules and
structures that coordinate connections between external system management tools and
individual CCMS interfaces, and writes messages in the R/3 XMI log on behalf of the
external tool. The XMI log is a table containing English message texts. The messages can
have various degrees of detail. The audit level determines the degree of detail to which
messages in the XMI log are written - i.e., whether the message should always be logged,
or is simply a message which supplies further detail (higher detail degree). The XMI log
contains messages from external tools and also messages which arise in SMAPI functions.
To indicate to the test the degree of detail to which messages from the eG agent are to be
written in the XMI log, you need to specify the XMI AUDIT LEVEL. By default, this
parameter is set to 0, which indicates that all calls that modify the database are to be
logged. The other values this parameter can take and their implications are discussed
below:
o

1: Logs all calls that modify the database and error
messages

2: Logs all calls that read from the database, modify the
database, and error messages

3: Logs all calls and all messages (full trace)

15. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every configured Monitor

Measurement

Measurement
Unit

169

Interpretation

MONITORING THE SAP A BAP INSTANCE

Total number of alerts:

Number

Indicates the total number of
alerts that have occurred for
this monitor since the last
measurement period.

The detailed diagnosis of this measure,
if enabled, provides the complete
details of all the alerts associated with
the corresponding monitor. The details
include: Date, Time, System, Context,
Object Name, Short Name, Status,
Importance and Alert Text.
Alternatively, you can navigate to the
Components -> SAP -> Alerts to selectively
view the alerts related to specific monitor
sets or monitors, alerts of a specific status, or
alerts generated during a given period.

Number of red alerts:

Number

To view the alerts and rectify them
instantly, you can navigate to the
Components -> SAP -> Alerts page in the eG
monitoring console.

Number

To view the alerts and rectify them instantly,
you can navigate to the Components -> SAP
-> Alerts page in the eG monitoring console.

Number

It is also possible to generate messages
for green “alerts” and react to them
correspondingly. Green alerts of this
type do not indicate error situations,
but are intended as all-clears or explicit
messages
that
an
action
was
successful.

Indicates the number of
errors or critical status
messages that have occurred
for this monitor since the last
measurement period.
Number of yellow alerts:
Indicates
warning
occurred
since the
period.

the number of
alerts that have
for this monitor
last measurement

Number of green alerts:
Indicates the number of
events or components that
were running normally since
the last measurement period.

You can activate green alerts in the
Alert Monitor for performance attributes
and status attributes. Behavior in the
case of performance attributes is as
follows:

170

A green alert is generated
if the current status is yellow or
red and the next report sets the
current status to green.

No green alert is generated
if the current status is already
green.

MONITORING THE SAP A BAP INSTANCE

Number of active alerts:

Number

An abnormally high value could indicate that
the SAP R/3 component is problem-prone.
You may want to navigate to the
Components -> SAP -> Alerts page in the eG
monitoring console to take a closer look at
the active alerts, and decide on a course of
action.

Number

To zoom into the completed alerts, you can
navigate to the Components -> SAP -> Alerts
page in the eG monitoring console.

Number

To zoom into the auto-completed alerts, you
can navigate to the Components -> SAP ->
Alerts page in the eG monitoring console.

Indicates the number of
alerts that are active since
the last measurement period.

Number
alerts:

completed

Indicates the number of
alerts that were rectified
manually since the last
measurement period.
Number of autocompleted
alerts:
Indicates the number of
alerts that were rectified
automatically by this SAP R/3
system
since
the
last
measurement period.

The detailed diagnosis of the Total number of alerts measure provides the complete details of the alerts generated
on a configured monitor. The details include: Date, Time, System, Context, Object Name, Short Name, Status,
Importance and Alert Text.

Figure 5.1: The detailed diagnosis of the Total number of alerts measure

171

MONITORING THE SAP A BAP INSTANCE

2.7.13

Performance Attributes for Monitors

A monitoring object represents a component of the IT environment that is to be monitored, such as the CPU of a
server, the dialog system, or background processing. Monitoring attributes are values, statuses, or texts that are
reported to this object, such as the CPU utilization, or the average response time in the dialog system. A monitoring
attribute can be assigned an alert. The selection of the monitoring objects is performed using the data suppliers that
exist for all areas of system management.
Monitoring objects and their attributes are displayed in the alert monitoring tree as individual nodes in a hierarchical
tree. If the data reported to the monitoring architecture exceeds or falls below the defined alert threshold values, an
alert is triggered in the corresponding monitoring tree element.
There are five different types of monitoring attributes:


Performance attribute



Status attribute



Heartbeat attribute



Log attribute



Text attribute

The Performance attribute collects and averages performance values that have been reported to the monitoring
architecture. If these values violate the set threshold values, an alert is generated.
To know the count of performance attributes associated with specific monitors, and to instantly isolate attributes on
which alerts were generated, use the Performance Attributes in Monitors test.
This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page using the menu sequence
: Agents -> Tests -> Enable/Disable, pick SAP R/3 as the Component type, set Performance as the Test type, choose
this test from the DISABLED TESTS list, and click on the >> button to move the test to the ENABLED TESTS list. Finally,
click the Update button.

Purpose

Reports the count of performance attributes associated with specific monitors, and helps isolate
attributes on which alerts were generated

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

172

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

MONITORING THE SAP A BAP INSTANCE

14. XMI AUDIT LEVEL - The XMI interface is a general framework for the CCMS external
system management interfaces. This interface contains essential function modules and
structures that coordinate connections between external system management tools and
individual CCMS interfaces, and writes messages in the R/3 XMI log on behalf of the
external tool. The XMI log is a table containing English message texts. The messages can
have various degrees of detail. The audit level determines the degree of detail to which
messages in the XMI log are written - i.e., whether the message should always be logged,
or is simply a message which supplies further detail (higher detail degree). The XMI log
contains messages from external tools and also messages which arise in SMAPI functions.
To indicate to the test the degree of detail to which messages from the eG agent are to be
written in the XMI log, you need to specify the XMI AUDIT LEVEL. By default, this
parameter is set to 0, which indicates that all calls that modify the database are to be
logged. The other values this parameter can take and their implications are discussed
below:
o

1: Logs all calls that modify the database and error
messages

2: Logs all calls that read from the database, modify the
database, and error messages

3: Logs all calls and all messages (full trace)

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every configured Monitor

Measurement

Measurement
Unit

174

Interpretation

MONITORING THE SAP A BAP INSTANCE

Total
number
of
performance attributes:

Number

Indicates the total number of
Performance
attributes
available for this monitor.

A monitoring tree depicts the hierarchy
of monitoring objects within a monitor
and the various attributes exposed by
the monitoring objects. The monitoring
tree depicted by the detailed diagnosis
page of this measure shows only the
Performance attributes within the
monitoring objects. Within the tree, the
Performance attributes are indicated in
a tabular format. The table contains an
entry for each Performance attribute
exposed by the monitoring object with
details such as the Attribute Name,
Current Value of the attribute (with
units), Importance and the actual
Timestamp of the Current Value shown.
The Importance value is a combination
of the status and severity of the most
significant active alert associated with
this Performance attribute. The Status
of
this
performance attribute
is
represented using the unique color code
as mentioned above. The severity of a
given status is indicated by a number
between 0 and 255, with higher
severity values being more important
than the lower ones.
The monitoring tree is identical to the
alert monitoring tree in SAP CCMS Alert
Monitor and its individual nodes can be
expanded and contracted.

Number
of
red
performance attributes:

Number

A high value for this measure indicates
that too many performance attributes
of a given monitor have encountered
critical
errors.
To
view
these
performance attributes, use the Alerts
page that appears when the Components ->
SAP -> Alerts menu sequence is followed in
the eG monitoring console.

Number

A high value for this measure indicates that
too many performance attributes of a given
monitor have encountered warnings. To view
these performance attributes, use the Alerts
page that appears when the Components ->
SAP -> Alerts menu sequence is followed in
the eG monitoring console.

Indicates the number of
errors or critical status
messages that have been
issued for this monitor.

Number
of
yellow
performance attributes:
Indicates the number of
warning messages that have
been issued for this monitor.

175

MONITORING THE SAP A BAP INSTANCE

Number
of
green
performance attributes:

Number

Indicates the number of
successful events for this
monitor.
Number
of
inactive
peformance attributes:

Number

Indicates the number of
Performance attributes for
this monitor that currently do
not have any data.

The monitoring tree depicted by the detailed diagnosis page of the Total number of performance attributes measure
shows only the Performance attributes within the monitoring objects. Within the tree, the Performance attributes are
indicated in a tabular format. The table contains an entry for each Performance attribute exposed by the monitoring
object with details such as the Attribute Name, Current Value of the attribute (with units), Importance and the actual
Timestamp of the Current Value shown. The Importance value is a combination of the status and severity of the
most significant active alert associated with this Performance attribute. The Status of this performance attribute is
represented using the unique color code as mentioned above. The severity of a given status is indicated by a number
between 0 and 255, with higher severity values being more important than the lower ones.

Figure 2.22: The detailed diagnosis of the Total number of performance attributes measure
While configuring the MONITOR DETAILS , you may want to know the exact names of the monitors and monitor
sets that form part of your specification. To determine this, do the following:
1.

Open the SAP Logon tool using the Start -> Programs -> SAP Front End -> SAP Logon menu sequence.

Pick a system from Figure 2.23 that appears, and click on the Logon button therein to connect to the chosen
sysem.

176

MONITORING THE SAP A BAP INSTANCE

Figure 2.23: Selecting a system to login to
3.

Then, login to the chosen system by providing the required Client, User, and Password credentials. Once the
Password is provided, press the Enter key on your keyboard to login (see Figure 2.24).

Figure 2.24: Logging into the chosen system
4.

Upon logging in successfully, the SAP Easy Access interface will appear (see Figure 2.25). In the tree-structure
in the left panel of the interface, follow the node sequence, SAP Menu -> Tools -> CCMS -> Control/Monitoring.
Then, double-click on the RZ20-CCMS Monitor Sets sub-node under the Control/Monitoring node.

177

MONITORING THE SAP A BAP INSTANCE

Figure 2.25: Double-clicking on the CCMS Monitor Sets sub-node
5.

This will invoke Figure 2.26, where the complete list of monitor sets will be displayed. Expand a monitor set to
view the monitors within. Use these details to configure the monitor set:monitors in the MONITOR DETAILS
text box.

178

MONITORING THE SAP A BAP INSTANCE

Figure 2.26: Viewing the monitor sets and monitors

179

MONITORING THE SAP A BAP INSTANCE

2.8 The SAP Users Layer

Figure 2.27: The tests mapped to the SAP Users layer

2.8.1

User Load Test

When a user complains that the SAP ABAP system is taking too long to process his/her requests, administrators may
want to closely observe the interactions between that user and the SAP system, identify processing bottlenecks (if
any), and accurately determine where the bottleneck has occurred. The User Load test enables administrators
effectively and efficiently perform this user experience analysis! This test monitors the transactions of every user to
the SAP ABAP system and reports the following:
Which user is executing resource-intensive transactions on the ABAP system?
Which user is overloading the system?
Which user is experiencing slowness when running transactions on the system? Where did this delay
occur? – in the dispatcher queue? when loading/generating objects? when rolling-in/rolling out user
contexts? in the database? when performing enqueue operations? or when waiting for RFC calls to
complete?

Purpose

Monitors the transactions of every user to the SAP ABAP system and reports the following:

180

MONITORING THE SAP A BAP INSTANCE

Which user is executing resource-intensive transactions on the ABAP system?
Which user is overloading the system?
Which user is experiencing slowness when running transactions on the system?
Where did this delay occur? – in the dispatcher queue? when loading/generating
objects? when rolling-in/rolling out user contexts? in the database? when
performing enqueue operations? or when waiting for RFC calls to complete?

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

181

MONITORING THE SAP A BAP INSTANCE

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. MAXIMUM STEPS – To report workload metrics, the eG agent will have to typically analyze
numerous dialog steps of activity on the SAP ABAP system. To reduce the stress on the eG
agent, you can limit the number of dialog steps the eG agent needs to process in order to
make a fair assessment of the workload and the processing ability of the ABAP system. This
limit can be specified against MAXIMUM STEPS. By default, this limit is set to 5000.
14. INCLUDE TCODES – By default, this test monitors only those transactions that were
invoked in the last measurement period. However, if you want a few critical transactions to
be monitored all the time – i.e., regardless of their status (whether they were invoked or
not) in the last measurement period – then, you can provide a comma-separated list of the
transaction codes of such transactions against INCLUDE TCODES.
15. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

182

MONITORING THE SAP A BAP INSTANCE

16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every transaction handled by the SAP AS ABAP instance being monitored

Measurement

Activity:

Measurement
Unit
Steps/Sec

This is a good indicator of the workload
imposed by a user on the SAP ABAP instance.
You can compare the value of this measure
across users to know which transaction is
generating the maximum load.

Percent

Compare the value of this measure across
users to know which user is using the
maximum CPU and is probably causing a CPU
contention on the system. You may then
want to observe how this user has been
using CPU over time and figure out whether
the CPU usage of that user remains
consistently high; if so, it could mean that
that transactions executed by that user
require more processing power to execute.
You may then want to consider resizing the
SAP ABAP system with more CPU resources.

Indicates the rate of steps
executed for this user’s
transactions in the last
measurement period.
CPU utilization:

Interpretation

Indicates the percentage of
CPU resources utilized by this
user’s transactions.

183

MONITORING THE SAP A BAP INSTANCE

Total memory:

This measure is the sum total of the roll
memory, extended memory, and heap
memory used by a process.

Indicates the total memory
used by the transactions of
this user during the last
measurement period.

By comparing the value of this measure
across users, you can accurately identify that
user who is consuming the maximum
memory. If the memory usage of this user
has been abnormally high consistently, it
could indicate that the user is typically
running memory-intensive transactions and
requires more memory resources for proper
execution. You should then figure out how
much memory and of what type should be
allocated to the task. For this, you may want
to determine which memory type was being
used the highest over time – is it heap
memory? Roll memory? Or extended
memory. The values of the PRIV mode heap
memory and the Extended memory metrics
will help administrators figure this out.
You can also use the detailed diagnosis of
this measure to identify the top 3 memoryconsuming steps of a particular transaction.

184

MONITORING THE SAP A BAP INSTANCE

PRIV mode heap memory:

Indicates the maximum
PRIV mode heap memory
consumed by transactions
of this user in the last
measure period.

Roll area: The roll area memory is
used for the initial memory assigned
to a user context, and (if available)
for additional memory if the
expanded memory is full. The roll
area consists of 2 segments. The
first segment is assigned to the work
process first as memory. If this is
used up, the work process has more
memory assigned to it.
Extended memory: Each ABAP work
process has a part reserved in its
virtual address space for extended
memory. The majority of the user
context is stored in the extended
memory. You can map the extended
memory from the common resource
onto any work process, and after
onto another process on the same
address in the virtual address space.
This is important if you work with
pointers in the ABAP program. The
value of the Extended memory
measure indicates how each user is
using this memory type.
Private memory: If a dialog work
process has used up the roll area
assigned to it and the extended
memory,
private
memory
is
assigned to the work process. The
work process goes into PRIV mode
(private). Other processes cannot

185

MONITORING THE SAP A BAP INSTANCE

use private (heap) memory. After
releasing the assigned memory, the
operating system still considers the
(virtual) memory as being occupied
by the allocating process.

Extended memory:

A consistent increase in the value of
the PRIV mode heap memory
measure for a user therefore
indicates that transactions of that
user are continuously using up all
the roll area and extended memory,
and are being forced to reach out to
the private memory. This could
mean that the user transactions are
memory-intensive. If too many
transactions are found to be using
PRIV heap memory, it could mean
that the work processes are sized
with insufficient roll area and
extended memory. You may hence
want to allocate more roll area and
extended memory to make sure that
private memory usage is minimal.

Indicates the maximum
extended memory used
by transactions of this
user in the last measure
period.

Work process restarts:

Number

Indicates the number of
work
process
restarts
caused by transactions of
this user
in the last
measure period.

186

MONITORING THE SAP A BAP INSTANCE

Maximum response time
of a step:

Secs

Indicates
the
maximum
response
time
of
the
transaction steps of this user
in the last measurement
period.

This measure compares the response time of
all the transactions executed by a user in the
last measurement period and reports the
highest response time.
Use the detailed diagnosis of this measure to
identify the top 3 transactions executed by
this user with highest response times. This
leads you to the probable cause for delay in
the execution of this transaction in the last
five minutes. Apart from the response time
break up, the report and CUA programs that
were running are also shown as part of
detailed diagnosis.

Total response time:
Indicates the total response
time per transaction of this
user within the last measure
period.

Seconds/transa
ction

This measure includes the response time
taken at the server and the round trip times.
Ideally, the value of this measure should be
low. High values are indicative of poor
responsiveness.
Compare the value of this measure across
users to identify the user who is experiencing
the maximum slowness. To know the reason
for the delay, you can compare the value of
the GUI time, GUI Net time, Server response

time, Processing time, Dispatcher wait time,
Load and generation time, Roll time,
Database request time, Lock time, and RFC
time measures for that transaction. This will
accurately
pinpoint
where
the
user
transactions spent maximum time – in the
dispatcher queue? at the server end? in
processing? when loading objects? when
rolling in user contexts? when performing
database operations? when performing
enqueue operations? Or in waiting for RFC
calls?
You can also use the detailed diagnosis of
this measure to view the details of the top 3
transaction invocations that were least
responsive.

187

MONITORING THE SAP A BAP INSTANCE

GUI time:
Indicates the average time
taken
for
round
trip
communication
steps
between client and server in
between a transaction of
this user.
GUI Net time:
Indicates the average front
end net time taken for the
first and last steps of
transactions of this user.
Server response time:
Indicates
the
average
response
time
of
a
transaction of this user at
the server end.
Processing time:
Indicates the average time
taken
to
process
a
transaction of this user.

Secons/transac
tion

Seconds/transa
ction

In the event of a processing slowdown, you
can compare the value of this measure with
other response time measures reported by
this test to understand where the processing
bottleneck lies.

Secons/transac
tion

A high value for this measure may indicate
that ABAP programs are very complex and
the work processes spend a large amount of
time interpreting what is to be done.
The processing time of transactions executed
by the dialog work process for instance
should be below twice the CPU time.

Dispatcher wait time:
Indicates the average time
that the transactions of
this user spent waiting for a
free work process at the
dispatcher.

Seconds/transa
ction

When the dispatcher receives a processing
request, it looks for a free SAP work process
of the required type and then sends the
request to this work process, which begins
the work. If all SAP work processes of the
required type are busy when the request
initially reaches the dispatcher, the request is
placed in the dispatcher queue. In the
dispatcher queue, the request waits until a
work process of the required type is free. As
soon as a work process is free, the
dispatcher sends the request to it. This time
the request spends in the dispatcher queue is
indicated as the dispatcher wait time.
For the transactions of the dialog work
process for instance, the value of this
measure should be less than 10% of the
value of the Total response time measure.
Higher values are indicative of performance
problems. One common cause of such
performance problems may be insufficient
work processes.

188

MONITORING THE SAP A BAP INSTANCE

Load and generation time:
Indicates the average time
spent for a transaction of
this user for loading and
generation.

Seconds/transa
ction

All ABAP programs and screens that are
required but not yet available in the
application server buffers must be loaded or
generated. The time it takes to do this is
indicated as load and generation time.
Loading a program also entails accessing
database tables that store the ABAP
programs.
Typically, for the transactions of the dialog
work process, the load time per step should
not be greater than 50 ms.
High values could indicate problems with
memory configuration, small buffer sizes,
wrong parameter settings or a CPU
bottleneck.

189

MONITORING THE SAP A BAP INSTANCE

Roll time:

Secs

Indicates the average time
spent by a transaction of
this user for rolling in user
contexts and when waiting
for roll out.

The value of this measure is the sum total of
roll-in time and roll wait time.
A high value for this measure indicates that
the user transaction is either taking too long
to roll in user contexts or is waiting too long
in the roll-area for a roll-out to occur. Since a
user context is moved out of the local
memory of a work process and moved into
the roll buffer during the roll-in process,
improperly sized roll buffers can cause
slowdowns in this process. Lack of adequate
space in the extended memory can also
contribute to a slowdown when rolling in user
contexts.
Possible causes for high roll wait times may
be due to having all work processes in the
target system occupied. It is very important
to configure the instances properly, especially
when they are designed to handle RFC
communication.

190

MONITORING THE SAP A BAP INSTANCE

Database request time:
Indicates the average time
spent by transactions of this
user for performing database
operations such as selects,
inserts, updates, deletes and
commits.

Lock time:
Indicates the average time
spent performing enqueue
operations for a transaction
of this user.

Secons/transac
tion

When data is read or changed in the dataase,
the time required is known as Database
request time. This time is measured from the
moment the database request is sent to the
database server and runs until the moment
the data is returned to the application server.
Ideally, for the transactions of the dialog
work process, the value of this measure
should be 40% of the total response time.
Many factors can cause worrysome spikes in
this value. This could be problems in the
database such as expensive SQL statement
or wrong parameter settings in the database
level. In addition, issues in network
connectivity between the application server
and the database can also adversely impact
this value. This is because, the Database
request time not only includes the time
required by the database to produce the
requested data, but also the time required for
network transfer of that data. In addition, I/O
contentions experienced by the physical disks
can also affect this time.

Seconds/Trans
action

The enqueue service allows SAP ABAP
applications to lock data so that only they can
use it. Locking the data prevents parallel
changes to the same data, which would lead
to data inconsistency.
The Lock time measure reports the time from
sending an enqueue request to the SAP
enqueue server to the receipt of the results.
For the transactions of the dialog work
process for example, the Lock time should be
less than 5 ms. Any value higher than that
would represent a problem that might affect
system stability. Network problems can also
increase the value of this measure.

191

MONITORING THE SAP A BAP INSTANCE

RFC time:
Indicates the average time
spent waiting for RFC calls to
get
executed
in
a
transaction of this user.

Secons/Transa
ction

The value of this measure includes CPIC

(Common
Programming
Interface
Communication) time as well. CPIC is
typically used by the SAP system
program-to-program communication.

for

rdisp/rfc_max_comm_entries:

This
specifies the maximum number of
communications in an instance. No
more dialog work processes will be
given to the program calling the
target system after this number is
reached.

rdisp/rfc_min_wait_dia_wp:

This
specifies the number of work
processes to be always available for
online users.

2.8.2

User logons Test

By tracking the user logins to the SAP ABAP system, administrators can understand how actively the system is being
used and accordingly plan the capacity of the system. In addition, failed login attempts can also be isolated, thus
turning the spotlight on unauthorized accesses and malicious attacks. This is why, eG Enterprise periodically executes
the User Logons test. For every type of login, this test reports the number of users who are logged in, measures the
activity levels of the users, and reports login failures. This way, the test indicates how well the ABAP system is being
utilized, proactively reveals a consistent rise in user activity on the system, and pre-emptively points to dubious login
attempts.

192

MONITORING THE SAP A BAP INSTANCE

Purpose

For every type of login, this test reports the number of users who are logged in, measures the
activity levels of the users, and reports login failures

Target of the
test

A SAP R/3 server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORTNO - Enter the port to which the specified HOST listens

CLIENTNAME – Specify the ID of the client system that is connecting to the R/3 server. To
view a list of client IDs to choose from, follow the procedure discussed in Page 14.

PASSWORD - The password of the specified SAPUSER.

CONFIRMPASSWORD - Confirm the password by retyping it here.

10. INSTANCENAME - Specify the name of the SAP R/3 instance to be monitored. To view the
complete list of instances to choose from, do the follow the procedure discussed in Page 17
of this document.
11. TIMEOUT - Indicate the duration (in seconds) for which this test should wait for a response
from the SAP R/3 server. By default, this is set to 120 seconds.
12. JCO VERSION – The eG agent uses the SAP JCO library to connect to the SAP ABAP
system and pull out metrics. To enable the eG agent to make this connection and query the
metrics, you need to specify the version of the SAP JCO library that the agent needs to use.
For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the
‘major version number’ alone against JCO VERSION – in the case of this example, this will
be 2.x.
13. CUTOFFMINS – Specify the duration of inactivity of a user, beyond which that user will be
considered as inactive. Such users will be automatically excluded from the Active users
count and the value of the Percentage active users measure.
14. ISPASSIVE – If the value chosen is YES, then the server under consideration is a passive
server in a SAP R/3 cluster. No alerts will be generated if the server is not running.
Measures will be reported as “Not applicable” by the agent if the server is not up.

193

MONITORING THE SAP A BAP INSTANCE

15. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to
be generated for this test. The default is 1:1. This indicates that, by default, detailed
measures will be generated every time this test runs, and also every time the test detects a
problem. You can modify this frequency, if you so desire. Also, if you intend to disable the
detailed diagnosis capability for this test, you can do so by specifying none against DD
FREQUENCY.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every user login type - GUI, PLUGIN, SYSTEM and various RFC subtypes
such as RFC client, RFC Internal, RFC Server, RFC to App Server, RFC to R/2. One set of
summary measures for all types

Measurement

Logged in users:

Measurement
Unit
Number

This is a good indicator of the current
workload imposed on the SAP ABAP instance.
You can compare the value of this measure
across login types to know which type of
login contributed to the maximum load.

Number

A high value of this measure is indicative of
high level of user activity on the ABAP
instance. In the event of an overload, you cn
compare the value of this measure across
login types to know which type of login is
generating the maximum activity on the
instance.

Indicates the number of users
of this type who are currently
logged in.
Active users:
Indicates the number of
users of this login type
who created some activity
in the instance during the
last measure period.
Percentage active users:

Interpretation

Percent

Indicates the percentage of
logged in users of this type
who are currently active.
Number of failed logins:

Number

Indicates the number of
logins of this type that failed.

Ideally, the value of this measure should be
low. If this value is abnormally high, you can
use the detailed diagnosis of this measure to
know which logins failed and investigate why.

Note that the value of this measure does not
include the number of logins that failed due to
incorrect password.
194

MONITORING THE SAP A BAP INSTANCE

New users:

Number

Indicates the number of users
of this login type who logged
in
during
the
last
measurement period.
Logouts:

Number

The detailed diagnosis of this measure shows
the activity summary of the logged out user
such as name, hostname, login time, duration
in minutes etc.

Number

When user logs on to SAP ABAP system, the
system creates a new terminal session called
external session. In general, each user can
open up to six windows in a single SAP GUI
session. Each of these windows corresponds
to an external session on the application
server with its own area of shared memory.

Number

Internal sessions are automatically created by
the ABAP system when navigating through
transactions. Internal sessions are like
navigation levels when performing system
functions.. A maximum of 9 internal sessions
can be created.

Indicates the number of users
of this login type who have
successfully logged out in the
last measure period.
External sessions:
Indicates the total number of
external sessions created for
this login type.

Internal sessions:
Indicates the total number of
internal sessions created for
this login type.

The internal session has a memory area that
contains the ABAP program and its associated
data. Internal sessions proportionately
increase the memory consumption of its
parent external session. High average
number of internal sessions results in higher
memory consumption for the same number
of external sessions.

2.9 Viewing the SAP Alerts
The eG monitoring console provides a dedicated interface for selectively viewing the history of alerts related to
managed SAP R/3 components. With the help of this interface, administrators can at-a-glance infer the number,
nature, status, and severity of issues encountered by the SAP R/3 environment, currently and in the past. This
information will enable administrators to understand how problem-prone their SAP environment has been over time,
study problem patterns, isolate recurring problems (if any), and arrive at effective solutions.
Moreover, active alerts awaiting manual completion can be effortlessly identified using this interface, and such alerts
can also be closed by employing a simple sequence of mouse-clicks on this interface.
To access this interface, follow the menu sequence, Components -> SAP -> Alerts in the eG monitoring console.
Figure 2.28 will then appear.

195

MONITORING THE SAP A BAP INSTANCE

Figure 2.28: The SAP Alerts page with the filter criteria
In this page, do the following:
1. To view the SAP alerts related to a particular SAP R/3 component, select a Component.
2. Once a Component is selected, the Monitor Sets list will be populated with the monitor sets that currently exist
for the selected component. To view the alerts for specific monitor sets, pick them from the Monitor Sets list.
3. The monitors that are available within the chosen monitor sets will be populated automatically in the Monitors
list. Select the monitors of your choice from this list.
4. Use the Filter By list to filter your alerts based on their current status. The options available here are as follows:
g.

Active: Pick this criterion to view the currently active alerts pertaining to the selected monitor
sets and the monitors.

Done: This criterion is selected to view the list of alerts that were completed by the
administrator.

Auto Completed: You can select this option to view the list of alerts that were completed
automatically by the SAP system.

All: Select this option to view all alerts related to the chosen monitors, regardless of their
status.

5. Then, from the Timeline list box, select the time period for which you wish to view the alerts. The timeline
options available are as follows:
k.

To view all the alerts that were generated by the SAP R/3 system since startup, select the All
option from the Timeline list box.

If you wish to view the alerts that were prevalent for a short period during the last 24 hours,
pick the Last X Minutes option. This will invoke the Hr and Min list boxes using which you can
specify a particular time period for which you wish to view the alerts.

By picking the Any option, you will be allowed to select the date/time range from the list boxes
that appear next to the Timeline option.

196

MONITORING THE SAP A BAP INSTANCE

Note:
The date/time range provided as part of the Any Timeline specification will pertain to the time zone of
the SAP USER configured for the New alerts in the last measurement period test.

6. Finally, click the Submit button to view the list of alerts that fulfill the selected criteria.
7. If the Filter by option was set to All, then all alerts related to chosen monitor sets and monitors will appear,
regardless of status (see Figure 2.29).

Figure 2.29: The SAP Alerts page displaying all alerts, regardless of status
8. On the other hand, if you had chosen the Active alerts from the Filter by list, then only the currently active alerts
will appear.

197

MONITORING THE SAP A BAP INSTANCE

Figure 2.30: The SAP Alerts page displaying only the active alerts
9. Regardless of the Filter by option chosen, the details displayed for each alert include the Date, Time, System (the
name of the SAP R/3 system), Context (the instance on which this alert has occurred), Object Name and Short
Name (the name of the monitoring object and its corresponding attribute that is responsible for this alert). Also,
in the Status column, the status of each alert will be indicated using symbols. In other words, the
symbol will
be displayed to represent an Active alert. Likewise, the
symbol represents the alerts that were Auto
Completed by the SAP R/3 system and the
symbol represents that the alerts were completed i.e., Done by the
administrator. Besides status, an alert is also accompanied by 'importance' indicators. The importance of an alert
is represented by a color coding and a severity value ranging from 0 to 255, encrypted on the color. A red color
in the Importance column indicates that the alert is critical and a yellow color in the Importance column indicates
that this is a warning alert. An elaborate description of alert will be available in the Alert text column. The alerts
displayed in this page are sorted in the order and sequence specified below:
n.

ascending order of the monitors chosen from the Monitors list box in Figure 2.30

ascending order of status code (active/done/auto-completed),

descending order of severity values (most severe alerts appear first)

ascending order of alert time stamps

ascending order of the ID of the alert (note that the alarm ID will not be displayed in the
Figure 2.30, and is maintained internally by the eG Enterprise system; this will be however
used for the sorting purposes).

Note:
The DATE and TIME displayed for every alert in this page will pertain to the time zone of the SAP USER
configured for the New alerts in the last measure period test.

10. Active alerts can also be completed on-the-fly, using this page. For this purpose, simply select the check box
corresponding to an active alert, and click the Complete button below (see Figure 2.30)
198

MONITORING THE SAP A BAP INSTANCE

2.10 Viewing the Performance Attribute Tree
The Performance Attribute tree (see Figure 2.22) discussed earlier in this chapter allowed you to view all
the performance attributes that are associated with a specific monitor only. However, if you are
looking for a more flexible interface, which allows you to choose from all monitor sets configured for a
SAP R/3 server, pick one/more monitors of interest to you, and view all the attributes associated with
all chosen monitors, then, you will have to use the METRICS page (see Figure 2.31) offered by the eG
monitoring console. To access this page, follow the Components -> SAP -> Metrics menu sequence.

Figure 2.31: The Metrics page
To use this page, do the following:
1.

Select the SAP R/3 Component of interest to you.

All the Monitor Sets configured for the chosen server will then populate the Monitor Sets list. Pick a monitor set
from this list.

The Monitors list will then display all the monitors associated with the chosen Monitor Set. Select one/more
monitors from this list, and click the Get Tree button.

An attribute tree providing the details of all the attributes of the chosen monitors will then appear, as depicted
by Figure 2.31 above. Within the tree, the Performance attributes will be displayed in a tabular format. The
table contains an entry for each Performance attribute exposed by the monitoring object with details such as
the Attribute Name, Current Value of the attribute (with units), Importance and the actual Timestamp of the
Current Value shown. The Importance value is a combination of the status and severity of the most significant
active alert associated with this Performance attribute. The Status of this performance attribute is represented
using a unique color code. The severity of a given status is indicated by a number between 0 and 255, with
higher severity values being more important than the lower ones.

199

MONITORING THE INTERNET TRANSACTION SERVER (ITS)

Monitoring the Internet
Transaction Server (ITS)
The Internet Transaction Server is the platform-independent, browser-based SAP client that typically comprises of
two components: a WGate component, and an AGate component. The WGate component is a CGI program that runs
within a web server (Apache). This component interfaces between the web server and the AGate component, and
facilitates the transmission of requests from the web server and HTML responses from the AGate component.
The AGate component, on the other hand, performs the following functions:

 Sends the requests received from the WGate component to the SAP application server
 Receives ‘Screen’ from the application server
 Formats ‘Screen’ into HTML using an HTML Template file and style sheets
 Sends the formatted page to WGate
As the SAP ITS serves as an interface between the users and the SAP application server, any
performance slowdown or non-availability that the SAP ITS experiences can negatively impact the user
interaction with the SAP environment. If such an outcome is to be prevented, then both the AGate and
WGate components of SAP ITS need to be kept under constant observation.
To monitor the WGate component, eG Enterprise recommends the following steps:

 Configure a web site on the web server hosting the WGate component
 While configuring the transactions to be monitored, ensure that the URL */wgate/* is
included in the PAGES TO BE INCLUDED list.
As for the AGate component, eG Enterprise prescribes a unique AGate monitoring model to monitor the load
on the component and the user accesses to it (see Figure 3.1).

200

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

Figure 3.1: The layer model of the AGate component of ITS
The sections to come discuss each of top 2 layers of Figure 3.1. For details on the remaining layers, please refer to
the Monitoring Unix and Windows Servers document.

3.1 The AGate Server layer
The AgateServer test associated with the AGate Server layer measures the session load on the AGate component,
and reveals whether/not the component has adequate threads to handle the load.

Figure 3.2: The tests associated with the AGate Server layer

3.1.1

AGate Server Test

The AGateServerTest reports performance statistics pertaining to the AGate component of the Internet Transaction
Server (ITS).

Purpose

Reports performance statistics pertaining to the AGate component of the Internet Transaction
Server (ITS)

Target of the
test

The AGate Component of ITS

Agent
deploying the

An internal agent
201

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

test
Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. LOGFILEPATH - This test extracts the performance metrics from the performance.log file
present in the {ITS_INSTALL_DIR}\6.20\{Directory corresponding to the ITS instance}\logs
directory. Therefore, in the LOGFILEPATH text box, provide the full path to the
performance.log file in the following format: {Instance Name}={Path to the log file}. For
example, if the log file for an instance named 'ADM' is to be monitored, and ITS is installed
in the C:\Program Files\SAP\ITS directory, then the LOGFILEPATH specification should be
as follows: ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\performance.log. To monitor the
performance.log files associated with multiple instances, provide the LOGFILEPATH as a
comma-separated
list.
For
example,

ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\performance.log,ITS1=c:\Progra~1\SAP\ITS\6.
20\ITS1\logs\performance.log.

Outputs of the
test
Measurements
made by the
test

One set of results for every ITS instance being monitored

Measurement

Current sessions:

Measurement
Unit
Number

Indicates the number of
sessions that are currently
active.
Free sessions:

Number

Indicates the number of free
sessions.
Sessions usage:

Percent

Indicates the percentage
utilization of sessions.
Active worker threads:

Number

Indicates the worker threads
that are currently active.
Free worker threads:

Number

Indicates the number of free
worker threads.

202

Interpretation

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

Worker threads usage:

Percent

Indicates the percentage
usage of worker threads.
Hit rate:

Hits/Sec

Indicates the rate at which
the AGate component was
hit.
Turnaround time:

Secs

Indicates the total time taken
by a client request to reach
the AGate component and a
response received from it.
Hits:

Number

Indicates the number of hits
at an AGate component.

3.2 The AGate Service Layer
The tests associated with the AGate Service layer extract critical access statistics from the AGate component.

Figure 3.3: The tests associated with the AGate Service layer

3.2.1

AGate Access Test

The AgateAccess test reports the number of successful logins to the AGate component of the Internet Transaction
Server (ITS).

Purpose

Reports the number of successful logins to the AGate component of the Internet Transaction
203

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

Server (ITS).

Target of the
test

The AGate Component of ITS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. LOGFILEPATH - This test extracts the performance metrics from the access.log file
present in the {ITS_INSTALL_DIR}\6.20\{Directory corresponding to the ITS instance}\logs
directory. Therefore, in the LOGFILEPATH text box, provide the full path to the access.log
file in the following format: {Instance Name}={Path to the log file}. For example, if the log
file for an instance named 'ADM' is to be monitored, and ITS is installed in the C:\Program
Files\SAP\ITS directory, then the LOGFILEPATH specification should be as follows:
ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\access.log. To monitor the access.log files
associated with multiple instances, provide the LOGFILEPATH as a comma-separated list.
For
example,

ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\access.log,ITS1=c:\Progra~1\SAP\ITS\6.20\ITS
1\logs\access.log.

Outputs of the
test
Measurements
made by the
test

One set of results for every ITS instance being monitored

Measurement
Access count:

Measurement
Unit

Interpretation

Number

Indicates the number of
times the AGate component
was successfully accessed.

3.2.2

AGate Status Test

The AgateStatus test reports whether any errors occurred in the AGate component during the last measurement
period.

Purpose

Reports whether any errors occurred in the AGate component during the last measurement
period

Target of the
test

The AGate Component of ITS

Agent
deploying the
test

An internal agent

204

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. LOGFILEPATH - This test extracts the performance metrics from the diagnostics.log file
present in the {ITS_INSTALL_DIR}\6.20\{Directory corresponding to the ITS instance}\logs
directory. Therefore, in the LOGFILEPATH text box, provide the full path to the
diagnostics.log file in the following format: {Instance Name}={Path to the log file}. For
example, if the log file for an instance named 'ADM' is to be monitored, and ITS is installed
in the C:\Program Files\SAP\ITS directory, then the LOGFILEPATH specification should be
as follows: ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\diagnostics.log. To monitor the
diagnostics.log files associated with multiple instances, provide the LOGFILEPATH as a
comma-separated
list.
For
example,

ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\diagnostics.log,ITS1=c:\Progra~1\SAP\ITS\6.20
\ITS1\logs\diagnostics.log.

Outputs of the
test
Measurements
made by the
test

One set of results for every ITS instance being monitored

Measurement
Unit

Measurement

Message count:
Indicates the number
diagnostic messages.

3.2.3

Number

Interpretation

These are always failure messages.

AGate Transactions Test

The AgateTrans test monitors the access requests serviced by the ITS instance.

Purpose

Monitors the access requests serviced by the ITS instance

Target of the
test

The AGate Component of ITS

Agent
deploying the
test

An internal agent

205

MONITORING THE INTER NET TRANSACTION SERV ER (ITS)

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. LOGFILEPATH - This test extracts the performance metrics from the loadstat.log file
present in the {ITS_INSTALL_DIR}\6.20\{Directory corresponding to the ITS instance}\logs
directory. Therefore, in the LOGFILEPATH text box, provide the full path to the
loadstat.log file in the following format: {Instance Name}={Path to the log file}. For
example, if the log file for an instance named 'ADM' is to be monitored, and ITS is installed
in the C:\Program Files\SAP\ITS directory, then the LOGFILEPATH specification should be
as follows: ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\loadstat.log. To monitor the
loadstat.log files associated with multiple instances, provide the LOGFILEPATH as a
comma-separated
list.
For
example,

ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\loadstat.log,ITS1=c:\Progra~1\SAP\ITS\6.20\IT
S1\logs\loadstat.log.

Outputs of the
test
Measurements
made by the
test

One set of results for every ITS instance being monitored

Measurement

AGate instances:

Measurement
Unit
Number

Every ITS instance could
consist of multiple AGate
instances.
This
measure
returns the number of AGate
instances in every monitored
ITS instance.
Web transactions:

Number

The number of web accesses
(including incorrect accesses)
that were serviced by the
AGate instances

206

Interpretation

MONITORING THE SAP W EB APPLICATION SERVE R

Monitoring the SAP Web
Application Server
The SAP Web Application Server (Web AS) is the web services infrastructure for all current versions of SAP R/3
Enterprise, and SAP xApps, mySAP solutions and any SAP J2EE-based application. It is also the underlying technology
for SAP Enterprise Portal, SAP Business Information Warehouse, and SAP Exchange Infrastructure, and a key
component in the SAP Enterprise Services Architecture and SAP NetWeaver. Therefore, managing the SAP Web AS is
crucial for ensuring business continuity in the SAP environment.
The graphic below shows the components of the Web Application Server (see Figure 4.1).

Figure 4.1: The SAP Web AS Architecture

207

MONITORING THE SAP W EB APPLICATION SERVE R

The components and their tasks are described below:

 The Internet Communication Manager (ICM) sets up the connection to the Internet. It can
process both server and client Web requests. It supports the protocols HTTP, HTTPS, and
SMTP. The SAP Web AS can behave as a Web server or as a Web client .

 The dispatcher distributes the requests to the work processes. If all the processes are
occupied the requests are stored in the dispatcher queue.



The ABAP work process executes the ABAP code.



The SAP Gateway makes the RFC interface between the SAP instances available (within an
SAP System and beyond system boundaries).

 The message server exchanges messages and balances the load in the SAP System.


In the Java component of the SAP Web AS there are the components Java Dispatcher,
Server Process, and Software Deployment Manager. The Java dispatcher receives the
client request and forwards it to the server process with the lowest capacity usage. If
there is already a connection to the client, the request goes to the server process that
processes this client. The server processes actually execute the J2EE application. The
Software Deployment Manager (SDM) is a tool with which you can manage and deploy
software packages (Software Deployment Archives (SDAs) and Software Component
Archives (SCAs)) that you receive from SAP.

The eG Enterprise suite embeds a specialized monitoring model for the SAP Web AS (see Figure 4.2), using which the
performance of the critical services and components of the server can be tracked, issues affecting serverperformance captured at their infancy, and the root-cause of the issues promptly traced and treated before it
adversely impacts the transaction of business in the SAP environment.

Figure 4.2: The layer model of the SAP Web AS
Every layer depicted by Figure 4.2 is associated with a series of tests, each of which seeks to answer the following
questions related to the performance of the SAP Web AS:

 Are the thread managers of the SAP Web AS making optimum use of the threads in the
pool?

 Are direct database accesses kept at a minimum?
 What type of connection requests are received by the SAP Web AS? How well does the
server handle these requests?

 How is the memory usage of the Java objects managed by the SAP Web AS?
208

MONITORING THE SAP W EB APPLICATION SERVE R

 Is the server cache been utilized effectively?
 Were any HTTP connections terminated abnormally by the SAP Web AS?
 Has the SAP Web AS been sized adequately to handle both the present and future logs?
 Has sufficient memory been allocated to the JVM?
 Have any new bean instances been added/removed from a bean pool? What are they?
 Are there any invalid user sessions on the SAP Web AS?
 How often do transaction rollbacks occur on the SAP Web AS?
 Are too many transactions/sessions getting timed out?
 Is the P4 connection to the server available? How quickly was the connection established?
 Is the web server component on the SAP Web AS accessible? What is its response time?
Since the last 4 layers of Figure 4.2 have been dealt with to a great extent in the Monitoring Unix and Windows
Servers document, the sections to come will discuss the first 3 layers only.

4.1 The SAP WAS Kernel Layer
The eG agents use JMX to obtain critical performance metrics from the SAP Web AS. At the SAP WAS Kernel layer, the
agents execute a wide range of Kernel tests (see Figure 4.3) that extract performance statistics pertaining to the
J2EE Engine managers such as:

 the Application Thread manager
 the Configuration manager
 the Connections Manipulator Manager
 the Pool manager
 the Threads manager

209

MONITORING THE SAP W EB APPLICATION SERVE R

Figure 4.3: The tests associated with the SAP WAS Kernel layer

4.1.1

Kernel Config Test

The Kernel Config test monitors the Configuration Manager's interactions with the database. The Configuration
Manager enables J2EE Engine modules to store and access data from a relational database management system
(RDBMS). It provides properties for configuring a database connection.

Purpose

Monitors the Configuration Manager's interactions with the database

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

210

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid
j2ee admin user name which the test should use for connecting to the server instance.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.

CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be
specified as the CONNECTORPORT. The default port number of the P4 protocol is 50004.
However, if the P4 protocol listens at a different port in your environment, then specify the
exact port number here. To know the P4 protocol port, first open the adminCFG.properties
file in the {SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory.
The value specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.

211

MONITORING THE SAP W EB APPLICATION SERVE R

DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps
discussed in Section 4.1.1.1 of this document.

10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to
the server processes executing on the Java component of the SAP Web AS for processing.
To monitor specific server processes, specify a comma-separated list of the cluster IDs of
these server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that
these cluster IDs alone appear as the descriptors of the test. If need be, you
can have server process name-cluster ID pairs appear as the test descriptors.
To achieve this, the specification in the SERVERIDS text box should be of the
following format: Server process name:Cluster ID of the server process. For
example, if the cluster ID of a server process named Server0 is 12621850,
then you can specify the SERVERID in the format: Server0:12621850.

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Commit duration:

Measurement
Unit

Interpretation

Secs

Indicates the time taken for a
commit to take place for data
storage
in
the
last
measurement period.
Locked exception ratio:
Indicates the number of
database lock exceptions that
occurred for every database
access
in
the
last
measurement period.
Cache hit rate:

Exceptions/Db
_tries

Percent

Indicates the percentage of
time data was retrieved from
the database cache in the last
measurement period.
Db read ratio:

Reads/Db_tries

Indicates the number of
database reads that occurred
for every database access in
the last measurement period.
212

Ideally, the ratio of cache hits to database
accesses should be high, as direct database
accesses are expensive operations.

MONITORING THE SAP W EB APPLICATION SERVE R

Db write ratio:
Indicates the number of
database writes that occurred
for every database access in
the last measurement period.

4.1.1.1

Writes/Db_trie
s

Configuring the DISPATCHERID and SERVERID ParameterS

This test reports a set of metrics for the Java dispatcher that receives client requests. To enable this reporting, you
need to specify the cluster ID of the Java dispatcher that needs to be monitored in the DISPATCHERID text box of
the test configuration page.
Typically, the Java dispatcher distributes the client requests it receives to the server processes executing on the Java
component of the SAP Web AS for processing. To monitor specific server processes, you need to specify a commaseparated list of the cluster IDs of these server processes in the SERVERIDS text box.
To know the cluster ID of the dispatcher and the server process, you can use any of the following broad
methodologies:
s.

Using the J2EE Engine Visual Administrator tool

Using SAP's Web Application through the browser

Using the Properties file for instances in the SAP installation

The sections that come will discuss each of these methodologies in detail.

4.1.1.1.1 Determining the DISPATCHERID and SERVERID using the Visual
Administrator Tool
If the Visual Administrator Tool is available in your environment, then follow the steps below to figure out the cluster
ID of the dispatcher:
1. Start

the

J2EE

Engine

Visual

Administrator

tool

executing

the

command

{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\go.bat at the command prompt, if you use a
Windows
platform.
If
you
use
a
Unix
platform,
execute
the
command
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\go at the command prompt.
2. Login to the J2EE Engine Visual Administrator using a valid user name and password.
3. Proceed to the Global Configuration tab that appears in the left panel of the Visual Administrator.
4. Upon clicking on the Dispatcher node, the information pertaining to that dispatcher will appear in the right
panel.
5. Pick the cluster ID that is displayed in that panel and specify in the DISPATCHERID text box.
Likewise, if the Visual Administrator Tool is available in your environment, then follow the steps below to figure out
the cluster ID of the server process:
1. Start

the

J2EE

Engine

Visual

Administrator

tool

executing

the

command

213

MONITORING THE SAP W EB APPLICATION SERVE R

2. Login to the J2EE Engine Visual Administrator using a valid user name and password.
3. Proceed to the Global Configuration tab that appears in the left panel of the Visual Administrator.
4. A list of servers will appear in the left panel of the Visual Administrator. Upon clicking on a particular Server
node, the information pertaining to that server process, including its name and cluster ID, will appear in the right
panel.

Figure 4.4: Determining the name and cluster ID of a server process

This way, you can determine the Name and cluster ID of each of the servers to be monitored. To configure the
tests to report metrics for each cluster ID alone, specify these cluster IDs as a comma-separated list in the
SERVERIDS text box. To configure the tests to report metrics for each server process name - cluster ID pair,
then provide a comma-separated list of server process Names and cluster IDs in the format: Server process

name:Cluster ID

214

MONITORING THE SAP W EB APPLICATION SERVE R

4.1.1.1.2 Determining the DISPATCHERID and SERVERID using the SAP's Web
Application
To determine the cluster ID of a dispatcher and server through SAP's Web Application, do the following:
1.

Connect to SAP's Web Application using the URL: http://:/
For instance, your URL can be: http://192.168.10.127:50100l

Figure 4.5 will then appear. Click on the System Information link indicated by Figure 4.5.

Figure 4.5: The SAP Web Application Server
3.

In the login pop-up that then appears, provide the credentials for accessing the system information, and click the
OK button therein.

Upon providing valid login credentials, Figure 4.6 will appear, displaying the necessary system information. The
Dispatcher ID and Server ID indicated by Figure 4.6 can be used to configure the DISPATCHERID and
SERVERID test parameters respectively.

215

MONITORING THE SAP W EB APPLICATION SERVE R

Dispatcher ID

Server ID

Figure 4.6: The page showing a dispatcher ID and server ID

4.1.1.1.3 Determining the DISPATCHERID and SERVERID using the Properties file
You can use the instance.properties file in the SAP system to determine the dispatcher ID and server process ID to
be used for configuring the SAP Netweaver tests. For this, follow the steps given below:
1.

The instance.properties file can be found in the following directory in a SAP system installed on Windows:

\usr\sap\\DVEBMGS[NN]\j2ee\cluster

Here, refers to the 3-letter system name, and DVEBMGS[NN] indicates the corresponding number
(example: DVEBMGS01)

The instance.properties file contains the properties for the various instances (cluster elements) in the WAS server
(see Figure 4.7).

216

MONITORING THE SAP W EB APPLICATION SERVE R

Figure 4.7: The instance.properties file
3.

As you can see, in Figure 4.7, each property of each instance is identified by the cluster element ID and the
property name in the following format :
4.

ID[cluster element ID].=

5.
For example, take the case of the following (non-contiguous) entries in the instance.properties file:
ID12621800.Name=dispatcher
....
....
....
ID12621850.Name=server0
In the first entry, Name is the , dispatcher is the , and 12621800 is the .
Likewise, in the second entry, Name is the , server0 is the , and 12621850 is the
.
While the Name property and its corresponding tells us whether a cluster element is a
dispatcher or server, the indicates the ID of the dispatcher or server (as the case may be).
217

MONITORING THE SAP W EB APPLICATION SERVE R

In the case of the entries above, 12621800 is the dispatcher ID and 12621850 is the ID of the server, server0.
During test configuration, you will have to provide these two IDs against the DISPATCHERID and SERVERID
parameters respectively.

4.1.2

Application Threads Test

The J2EE Engine thread system is responsible for handling system and client threads. It comprises of two managers
– Thread Manager and Application Thread Manager. The Application Threads test monitors the Application Thread
Manager of the SAP Web Application server, which supplies the threads in which the client applications' source code
is executed. This manager provides a set of properties for starting and managing client threads in the Java Virtual
Machine. When a client request comes, the system tries to find a free thread in the Application Thread Manager and
to start the execution of the request. If no free thread is available, the thread system buffers the request in a request
queue. By buffering the threads and using them again, the system achieves better performance than using normal
Java thread system without buffering. The Application Thread Manager runs only on server processes.

Purpose

Monitors the Application Thread Manager of the SAP Web Application server, which supplies the
threads in which the client applications' source code is executed

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

218

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

219

MONITORING THE SAP W EB APPLICATION SERVE R

9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that
these cluster IDs alone appear as the descriptors of the test. If need be, you can
have server process name-cluster ID pairs appear as the test descriptors. To
achieve this, the specification in the SERVERIDS text box should be of the
following format: Server process name:Cluster ID of the server process. For
example, if the cluster ID of a server process named Server0 is 12621850, then
you can specify the SERVERID in the format: Server0:12621850.

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Active threads:

Measurement
Unit
Number

Indicates the number of
threads from the thread pool
which are currently executing
a runnable task.
Current pool size:

Interpretation

This measure serves as a good indicator of
the server workload.

Number

Indicates the number of
threads that are currently in
the thread pool.
Threadpool usage:

Percent

Indicates the percentage of
threads in the thread pool
that are being currently
utilized.
Waiting tasks:

Number

Indicates the number of tasks
waiting for threads, so as to
begin execution.

220

If the value of this measure is high, it could
indicate a heavy server workload.

MONITORING THE SAP W EB APPLICATION SERVE R

Tasks queue size:

Number

Indicates the capacity of the
request queue where the
tasks waiting for execution
are stored.
Task queue overflow:

Number

Indicates the number of tasks
waiting to be placed in the
request queue, in the event
that the request queue is full.

4.1.3

If the value of this measure increases
consistently, it could indicate a processing
bottleneck.

Cluster Connections Test

The Cluster Connections test monitors the SAP J2EE engine's Connections Manipulator Manager, which manages the
client connections to the cluster by providing a set of properties for managing the pools where the TCP connection
objects are stored. The Connections Manipulator Manager runs on dispatchers only.

Purpose

Monitors the SAP J2EE engine's Connections Manipulator Manager, which manages the client
connections to the cluster by providing a set of properties for managing the pools where the
TCP connection objects are stored

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

221

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

222

MONITORING THE SAP W EB APPLICATION SERVE R

9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that these
cluster IDs alone appear as the descriptors of the test. If need be, you can have server
process name-cluster ID pairs appear as the test descriptors. To achieve this, the
specification in the SERVERIDS text box should be of the following format: Server process
name:Cluster ID of the server process. For example, if the cluster ID of a server process
named Server0 is 12621850, then you can specify the SERVERID in the format:
Server0:12621850.

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Current pool size:

Measurement
Unit
Percent

Indicates the current size of
the TCP connections pool.
HTTP connections:

Number

Indicates the number of TCP
connections in the pool that
are currently been utilized for
servicing HTTP requests.
P4 connections:

Number

Indicates the number of TCP
connections in the pool that
are currently been utilized for
servicing P4 requests.
IIOP connections:

Number

Indicates the number of TCP
connections in the pool that
are currently been utilized for
servicing IIOP requests.

223

Interpretation

MONITORING THE SAP W EB APPLICATION SERVE R

Unrecognized
connections:

Number

Indicates the number of TCP
connections in the pool that
are currently being utilized for
servicing requests of an
unknown kind.

4.1.4

Pool Data Aggregate Test

The Pool Data Aggregate test reports metrics pertaining to the J2EE Engine Pool Manager, which facilitates the
centralized creation and reuse of byte arrays.

Purpose

Reports metrics pertaining to the J2EE Engine Pool Manager, which facilitates the centralized
creation and reuse of byte arrays

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

224

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

225

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Pool memory allocated:

Measurement
Unit

Interpretation

Indicates the total memory
that is allocated by the Pool
Manager to the Java objects
that it manages.
Pool memory used:

Indicates the total memory
that is used by the Java
objects managed by the Pool
Manager.

4.1.5

System Threads Test

The J2EE Engine thread system is responsible for handling system and client threads. It comprises two managers –
Thread Manager and Application Thread Manager. The System Threads test monitors the health of the Thread
Manager, which supplies the threads in which SAP J2EE Engine system operations are executed. This manager
provides a set of properties for starting and managing system threads. This thread pool is for system activities such
as making backup, background optimizations for load/store data, and so on. The logic in the system thread manager
is similar to the application logic – the system uses a queue for system requests if a free thread is not available.

Purpose

Monitors the health of the Thread Manager, which supplies the threads in which SAP J2EE
Engine system operations are executed

226

MONITORING THE SAP W EB APPLICATION SERVE R

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

227

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Active threads:

Measurement
Unit
Number

Indicates the number of
threads from the thread pool
which are currently executing
a runnable task.
Current pool size:

Interpretation

This measure serves as a good indicator of
the server workload.

Number

Indicates the number of
threads that are currently in
the thread pool.
Threadpool usage:

Percent

Indicates the percentage of
threads in the thread pool
that are being currently
utilized.
Tasks waiting:

Number

Indicates the number of tasks
waiting for threads, so as to
begin execution.

228

If the value of this measure is high, it could
indicate a heavy server workload.

MONITORING THE SAP W EB APPLICATION SERVE R

Tasks queue size:

Number

Indicates the capacity of the
request queue where the
tasks waiting for execution
are stored.
Tasks queue overflow:

Number

Indicates the number of tasks
waiting to be placed in the
request queue, in the event
that the request queue is full.

If the value of this measure increases
consistently, it could indicate a processing
bottleneck.

4.2 The Web Server Layer
An external Http test executes on this layer (see Figure 4.8), which emulates a user access to the web server
component of the SAP Web AS, and reports the web server's availability and responsiveness.

Figure 4.8: The test executing on the Web Server layer
Since the Http test has already been dealt with in Monitoring Web Servers document, let us focus on the SAP WAS
Service layer.

4.3 The SAP WAS Service Layer
The tests mapped to the SAP WAS Service (see Figure 4.9) layer extract critical performance metrics relating to the
services running on a SAP Web AS, where each service performs an application function.

229

MONITORING THE SAP W EB APPLICATION SERVE R

Figure 4.9: The tests associated with the SAP WAS Service layer

4.3.1

MBeans Cache Test

The MBeansCache test monitors the accesses to the MBeans cache, where the MBeans are created and administered
by the JMX Adapter Service. The JMX Adapter Service manages the configuration and lifecycle of the MBeanServer
and provides access to it for applications, services, and libraries.
230

MONITORING THE SAP W EB APPLICATION SERVE R

Purpose

Monitors the accesses to the MBeans cache, where the MBeans are created and administered by
the JMX Adapter Service

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

231

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Cache hit rate:

Measurement
Unit
Hits/tries

Indicates the ratio of the
number of cache hits to the
total number of accesses to
the MBeanServer.

4.3.2

Interpretation

Ideally, this ratio should be high. Direct
server accesses are expensive operations,
and hence need to be kept at the minimum.

HTTP Connections Test

The HTTP Provider Service represents a server socket that listens for client HTTP connections on the J2EE Engine. It
takes care of parsing the URL of the incoming HTTP requests, dispatching them to the correct J2EE Engine’s module
for processing, and returning the generated responses back to the client. The HTTP Connections test monitors the
HTTP Provider Service and reports key statistics pertaining to client HTTP connections on the J2EE engine.

Purpose

Monitors the HTTP Provider Service and reports key statistics pertaining to client HTTP
connections on the J2EE engine

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

232

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

233

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

New requests:

Measurement
Unit

Interpretation

Number

Indicates the number of
HTTP
requests
newly
received from client since the
last measurement period.
Connections keep alive:

Number

Indicates the number of TCP
connections that are currently
open.

234

Under HTTP 1.0, if the browser supports
keep-alive, it adds an additional header to
the request: "Connection: Keep-Alive". Then,
when the server receives this request and
generates a response, it also adds a header
to the response: "Connection: Keep-Alive".
Following this, the connection is NOT
dropped, but is instead kept open. When the
client sends another request, it uses the
same connection. This will continue until
either the client or the server decides that the
conversation is over, and one of them drops
the connection. Under HTTP 1.1, all
connections are kept alive by default, unless
stated otherwise with the following header:
"Connection: close". The "Connection: KeepAlive" header no longer has any meaning
because of this.

MONITORING THE SAP W EB APPLICATION SERVE R

Connections
client:

closed

Number

Indicates the number of TCP
connections that have been
closed by the client since the
last measurement period.
Connections
server:

closed

Number

Indicates the number of TCP
connections closed by the
server
since
the
last
measurement period.

4.3.3

When the server closes a TCP connection, it
could be a normal connection timeout or an
abnormal termination. In case of the latter,
the reasons for the abnormal connection loss
will have to be investigated.

HTTP Requests Test

The HTTP Provider Service represents a server socket that listens for client HTTP connections on the J2EE Engine. It
takes care of parsing the URL of the incoming HTTP requests, dispatching them to the correct J2EE Engine’s module
for processing, and returning the generated responses back to the client. The HTTP Requests test monitors how well
the HTTP Provider Service responds to the HTTP connection requests received from clients.

Purpose

Monitors how well the HTTP Provider Service responds to the HTTP connection requests
received from clients

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

235

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

236

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

New HTTP requests:

Measurement
Unit

Interpretation

Number

Indicates the number of
HTTP requests received by
the server since the last
measurement period.
Responses from cache:

Number

Ideally, this value should be high.

Indicates the number of
times the server has retrieved
information from the cache to
respond to HTTP requests
from clients, since the last
measurement period.

4.3.4

JMX Notify Queue Test

The JMX Notification Service is responsible for the distribution of the MBeanServer notifications throughout the
cluster. MBeanServer notifications inform all the clients within the cluster about recently registered MBeans and the
removal of MBeans from the MBeanServer. The JmxNotifyQueue test reports metrics that indicate how well the JMX
Notification Service performs.

Purpose

Reports metrics that indicate how well the JMX Notification Service performs

Target of the

The SAP Web AS
237

MONITORING THE SAP W EB APPLICATION SERVE R

test
Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

238

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Active threads:

Measurement
Unit

Interpretation

Number

Indicates the number of
threads that are currently
processing JMX notifications.
Queue size:

Number

Indicates the number of
notifications
currently
in
queue, waiting to be sent to
clients.

4.3.5

If the value of this measure increases
consistently,
it
could
indicate
a
processing/delivery bottleneck.

Log Config Test

Using the Log Configurator service runtime available in the Visual Administrator, one can manage the logging and
tracing configurations of the J2EE Engine components and of the deployed applications. The LogConfig test monitors
this service to indicate whether the SAP web application server has been adequately configured to handle both its
present and future logs.

Purpose

Monitors this service to indicate whether the SAP web application server has been adequately
configured to handle both its present and future logs

Target of the
test

The SAP Web AS

Agent
deploying the

An internal agent

239

MONITORING THE SAP W EB APPLICATION SERVE R

test
Configurable
parameters for
the test

240

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Archives size:

Measurement
Unit

Interpretation

Indicates the total size of all
log and trace archives.
Log files size:

Indicates the total size of all
log and trace files excluding
archives.

4.3.6

MBeans Register Test

The MBeansRegisterTest monitors the process of the registration of MBeans with the MBeanServer.

Purpose

Monitors the process of the registration of MBeans with the MBeanServer

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

241

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORT - The port number to which the server is listening
4. USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid j2ee
admin user name which the test should use for connecting to the server instance.
5. PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.
6. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.
7. INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.
8. CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be specified
as the CONNECTORPORT. The default port number of the P4 protocol is 50004. However,
if the P4 protocol listens at a different port in your environment, then specify the exact port
number here. To know the P4 protocol port, first open the adminCFG.properties file in the
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory. The value
specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.
9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Page 213 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Page 218 of this document.
11. Providing a comma-separated list of server process cluster IDs will ensure that these cluster
IDs alone appear as the descriptors of the test. If need be, you can have server process
name-cluster ID pairs appear as the test descriptors. To achieve this, the specification in
the SERVERIDS text box should be of the following format: Server process name:Cluster
ID of the server process. For example, if the cluster ID of a server process named Server0
is 12621850, then you can specify the SERVERID in the format: Server0:12621850.

242

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Notify listeners:

Measurement
Unit
Number

Adding

listener
for
causes
the
MBeanServer to send a broadcast message
for each MBean that is (un)registered.
Therefore, avoid it whenever possible and do
not forget to unregister the listener if you no
longer require notification.

MBeanServerNotifications

Indicates the number of
notification
listeners
registered
with
the
MBeanServer since the last
measurement period.
Mbeans registered:

Interpretation

Number

Indicates the number of
Mbeans registered with the
MBeanServer since the last
measurement period.

4.3.7

P4 Connections Test

The P4Connections test reveals the availability and responsiveness of the P4 connection to the SAP Web AS.

Purpose

Reports the availability and responsiveness of the P4 connection to the SAP Web AS

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

243

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results each for every SAP Web AS monitored

Measurement

Availability:

Measurement
Unit
Percent

Indicates whether the P4
connection is available or not.

Response time:

Secs

Indicates the responsiveness
(in seconds) of the P4
protocol.

244

Interpretation

If the value of this measure is 100, it
indicates that the P4 connection is available.
The value 0, on the other hand, is indicative
of the non-availability of the P4 connection to
the server.

MONITORING THE SAP W EB APPLICATION SERVE R

4.3.8

P4 Usage Test

The P4Usage test measures the capability of the P4 Provider Service in handling P4 requests. The P4 Provider Service
provides functions for the communication of remote objects over the P4 protocol on the J2EE Engine. It also provides
functions for communication support generation. The P4 Provider Service consists of two parts. One of the parts runs
on the Java dispatcher. It accepts requests from the remote clients and has the responsibility to dispatch them to the
appropriate cluster element, where the implementation of the remote object resides. For the purpose, the P4
Provider Service uses the J2EE Engine Load Balancing System. The second part of the P4 Provider Service runs on
the server processes. This part contains the implementation of the P4RemoteObject broker and is responsible for
executing methods on the implementation of the remote object and returning the results.

Purpose

Measures the capability of the P4 Provider Service in handling P4 requests

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

245

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORT - The port number to which the server is listening
4. USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid j2ee
admin user name which the test should use for connecting to the server instance.
5. PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.
6. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.
7. INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.
8. CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be specified
as the CONNECTORPORT. The default port number of the P4 protocol is 50004. However,
if the P4 protocol listens at a different port in your environment, then specify the exact port
number here. To know the P4 protocol port, first open the adminCFG.properties file in the
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory. The value
specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.
9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
11. Providing a comma-separated list of server process cluster IDs will ensure that these cluster
IDs alone appear as the descriptors of the test. If need be, you can have server process
name-cluster ID pairs appear as the test descriptors. To achieve this, the specification in
the SERVERIDS text box should be of the following format: Server process name:Cluster
ID of the server process. For example, if the cluster ID of a server process named Server0
is 12621850, then you can specify the SERVERID in the format: Server0:12621850.

Outputs of the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

246

MONITORING THE SAP W EB APPLICATION SERVE R

Measurements
made by the
test

Measurement
Remote objects:

Measurement
Unit

Interpretation

Number

Indicates the number of
remote objects handled by
the P4 Provider Service.
P4 requests:

Number

Indicates the number of P4
requests
received
from
remote clients since the last
measurement period.
Failed requests:

Number

Indicates the number of P4
requests which have failed
since the last measurement
period.

4.3.9

Sap WAS Beans Test

The SapWasBeans test measures the efficiency with which the EJB Container Service manages the enterprise bean
instances deployed on the server. The EJB Container provides all the services that are required by an EJB application,
such as transaction and security management, clustering, persistence, network distribution of remote clients, scalable
management of resources, and so on.
If too many EJBs have been deployed on the server, then managing the individual EJBs could become a cumbersome
task. In such a case, you can use the eG administrative interface to group EJBs and manage the groups, instead. To
create an EJB group, you will need to click on the Click here hyperlink displayed above the parameters of the
SapWasBeans test. By default, eG Enterprise system monitors only those beans that are part of a group.

Purpose

Measures the efficiency with which the EJB Container Service manages the enterprise bean
instances deployed on the server

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

247

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORT - The port number to which the server is listening
4. USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid j2ee
admin user name which the test should use for connecting to the server instance.
5. PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.
6. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.
7. INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.
8. CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be specified
as the CONNECTORPORT. The default port number of the P4 protocol is 50004. However,
if the P4 protocol listens at a different port in your environment, then specify the exact port
number here. To know the P4 protocol port, first open the adminCFG.properties file in the
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory. The value
specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.
9. AUTODISCOVERY – By default, the eG Enterprise suite allows administrators to configure
bean groups using the eG administrative interface, and reports metrics pertaining to every
group so created. Accordingly, by default, AUTODISCOVERY is set to NO. If you want
beans to be discovered and monitored automatically, then select the YES option against
AUTODISCOVERY. When this is done, the eG agent automatically discovers all the beans
on the SAP web application server, and reports one set of measures for every bean hosted
on the server.

248

MONITORING THE SAP W EB APPLICATION SERVE R

10. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
11. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that
these cluster IDs alone appear as the descriptors of the test. If need be, you can
have server process name-cluster ID pairs appear as the test descriptors. To
achieve this, the specification in the SERVERIDS text box should be of the
following format: Server process name:Cluster ID of the server process. For
example, if the cluster ID of a server process named Server0 is 12621850, then
you can specify the SERVERID in the format: Server0:12621850.
12. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test

The eG manager license should allow the detailed diagnosis capability

Both the normal and abnormal frequencies configured for the detailed diagnosis
measures should not be 0.

One set of results for every configured EJB group

Measurement

Bean creations:
Indicates
times a
created.

Measurement
Unit
Number

the number of
bean has been

Bean removals:

Number

Indicates the number of
times a bean has been
removed.

249

Interpretation

The detailed diagnosis of this measure, if
enabled, provides an individual bean-wise
breakup of the current pool size, and the
number of additions and removals.

MONITORING THE SAP W EB APPLICATION SERVE R

Current pool size:

Number

Indicates the number of bean
instances provided by this
pool, which are currently
used by the application or are
stored in the pool.
Bean activations:

Number

Indicates the number of
times a bean instance has
been activated since the last
measurement period.
Bean passivations:

Number

Indicates the number of
times a bean instance has
been
passivated
or
deactivated since the last
measurement period.
Active sessions:

Number

Indicates the number of bean
sessions that are currently
active.
Passive sessions:

Number

Indicates the number of bean
sessions that are currently
passive.
Completed sessions:

Number

Indicates the number of bean
sessions that have been
completed since the last
measurement period.
Bean stores:

Number

Indicates the number of
entity bean instances that
were stored in the database
since the last measurement
period.
Bean loads:

Number

Indicates the number of
entity bean instances that
were loaded to the EJB
container from the database
since the last measurement
period.

250

MONITORING THE SAP W EB APPLICATION SERVE R

4.3.10

Sap WAS Memory Test

The SapWasMemoryTest reports the memory usage metrics revealed by the Memory Info Service. This service is
responsible for keeping track of the memory that is used internally by the JVM of the owner cluster element. The
service provides a set of properties for managing memory usage levels.

Purpose

Reports the memory usage metrics revealed by the Memory Info Service

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

251

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Memory used:

Measurement
Unit

Interpretation

Indicates the memory that
has been currently utilized by
the JVM.
Memory allocated:

Indicates the amount of
memory that has been
allocated to the JVM.
Memory available:

If this value is very low or is decreasing
consistently, it could be a cause for concern.
You might then consider allocating more
memory to the JVM of the owner cluster
element.

Indicates the amount of
memory that is currently
available.

4.3.11

Sap WAS Sessions Test

The SapWasSessions test reports metrics pertaining to user sessions on the SAP web application server as revealed
by the Security Provider service. This service enables the management of the security policy and the authentication
and authorization mechanisms on the system, monitors user sessions, and restricts access to the resources or the
applications deployed on the J2EE Engine.

252

MONITORING THE SAP W EB APPLICATION SERVE R

Purpose

Reports metrics pertaining to user sessions on the SAP web application server as revealed by the
Security Provider service

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

253

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement
Unit

Measurement

Failed logon attempts:

Number

Indicates the number of
unsuccessful logon attempts
since the last measurement
period.
New sessions:

Number

Indicates the number of
sessions that have newly
opened
since
the
last
measurement period.
Active sessions:
Indicates the number
currently active sessions.

Number
of

Invalid sessions:

Number

Indicates the number of
invalid sessions since the last
measurement period.

254

Interpretation

MONITORING THE SAP W EB APPLICATION SERVE R

Logged off sessions:

Number

Indicates the number of
sessions users logged out of
since the last measurement
period.
Timed out sessions:
Indicates the number
sessions that timed out.

4.3.12

Number
of

If the value of this measure is very high, then
consider resetting the TIMEOUT period for
user sessions.

Sap WAS Transactions Test

The Sap WAS Transactions test monitors the transactions to the SAP web application server, and reports key
statistics pertaining to the transactions.

Purpose

Monitors the transactions to the SAP web application server, and reports key statistics pertaining
to the transactions

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

255

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORT - The port number to which the server is listening
4. USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid j2ee
admin user name which the test should use for connecting to the server instance.
5. PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.
6. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.
7. INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.
8. CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be specified
as the CONNECTORPORT. The default port number of the P4 protocol is 50004. However,
if the P4 protocol listens at a different port in your environment, then specify the exact port
number here. To know the P4 protocol port, first open the adminCFG.properties file in the
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory. The value
specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.
9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that
these cluster IDs alone appear as the descriptors of the test. If need be, you can
have server process name-cluster ID pairs appear as the test descriptors. To
achieve this, the specification in the SERVERIDS text box should be of the
following format: Server process name:Cluster ID of the server process. For
example, if the cluster ID of a server process named Server0 is 12621850, then
you can specify the SERVERID in the format: Server0:12621850.

Outputs of the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

256

MONITORING THE SAP W EB APPLICATION SERVE R

Measurements
made by the
test

Measurement
Active transactions:

Measurement
Unit

Interpretation

Number

Indicates the number of
transactions
that
are
currently active.
Commit transactions:

Number

Indicates the number of
transactions that have been
committed since the last
measurement period.
Rollback transactions:

Number

Indicates the number of
transactions that have been
rolled back since the last
measurement period.
Suspend transactions:

Ideally, there should be fewer rollbacks
happening, as rollbacks are costly operations
on the database.

Number

Indicates the number of
suspended transactions since
the last measurement period.
Timedout transactions:

Number

Indicates the number of
transactions that have timed
out
since
the
last
measurement period.

4.3.13

If the value of this measure is very high, then
consider resetting the TIMEOUT period for
transactions.

Timeouts Test

The Timeouts test monitors the Timeout service, which provides an open structure for registering numerous listeners
willing to perform time-base actions. This service is a non-distributed system for scheduling tasks for future execution
in a background thread. A special Timeout object represents each task. If you want to reuse a particular thread, you
can specify a timeout after which the same thread can be reused. The Timeout Service is used by other J2EE Engine
services that need to receive events at particular intervals. The service can be used for accomplishing regular
operations – checking the module status, logging information about the current load, and so on.

Purpose

Monitors the Timeout service, which provides an open structure for registering numerous
listeners willing to perform time-base actions

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

257

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

258

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

Timeout rate:

Measurement
Unit
Timeouts/min

Indicates
the
count
of
timeout events received by a
J2EE Engine service per
minute.

4.3.14

Interpretation

If the timeout value set for the Timeout
objects is high, then the value of this
measure will be low. Since the Timeout
Service optimizes thread utilization by
running
multiple
application
tasks
simultaneously, it would be good practice to
create more Timeout objects and set a low
timeout value for the objects.

WasJndiRegistry Test

The WasJndiRegistryTest monitors the JNDI Registry Service, which provides a way by which names are associated
with objects, and objects are found based on their names. It provides a set of properties for specifying the number of
trials for locking an object in a database, for assigning communication protocols to be used by this service, and for
specifying the method of the lookup process. The JNDI Registry runs on server processes only.

Purpose

Monitors the JNDI Registry Service

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

259

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - Host name of the server for which the test is to be configured
3. PORT - The port number to which the server is listening
4. USERNAME - This test connects to a specific SAP web application server instance, and
extracts critical metrics from it. Therefore, in the USERNAME text box, provide a valid j2ee
admin user name which the test should use for connecting to the server instance.
5. PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.
6. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.
7. INSTANCENAME - Provide the application server instance to which the test should
connect. For example, if you specify tpp here, then the test will use the login credentials
(USERNAME and PASSWORD) provided here to connect to an instance named TPP,
which is incidentally the central instance of the SAP web application server. To know the
available server instances, use the Programs -> SAP Management Console menu sequence
on the application server host, and open the SAP Management Console. In the treestructure in the left pane of the console, you will find a SAP Systems node. When you
expand the SAP Systems node, the available server instances will appear as its sub-nodes.
Any one of the displayed instance names can be specified in the INSTANCENAME text
box.
8. CONNECTORPORT - This test uses the P4 protocol for connecting to the SAP web
application server. Therefore, the port at which the P4 protocol listens needs to be specified
as the CONNECTORPORT. The default port number of the P4 protocol is 50004. However,
if the P4 protocol listens at a different port in your environment, then specify the exact port
number here. To know the P4 protocol port, first open the adminCFG.properties file in the
{SAP_WAS_HOME_DIR}\usr\sap\TPP\DVEBMGS00\j2ee\admin\classes directory. The value
specified against the LOGIN_PORT parameter in that file, is the P4 protocol port.
9. DISPATCHERID - This test reports a set of metrics for the Java dispatcher that receives
client requests. To enable this reporting, specify the cluster ID of the Java dispatcher that
needs to be monitored. To know the cluster ID of the dispatcher, follow the steps discussed
in Section 4.1.1.1 of this document.
10. SERVERIDS - Typically, the Java dispatcher distributes the client requests it receives to the
server processes executing on the Java component of the SAP Web AS for processing. To
monitor specific server processes, specify a comma-separated list of the cluster IDs of these
server processes in the SERVERIDS text box. To know the cluster IDs of the server
processes, follow the procedure detailed in Section 4.1.1.1 of this document.
Providing a comma-separated list of server process cluster IDs will ensure that
these cluster IDs alone appear as the descriptors of the test. If need be, you can
have server process name-cluster ID pairs appear as the test descriptors. To
achieve this, the specification in the SERVERIDS text box should be of the
following format: Server process name:Cluster ID of the server process. For
example, if the cluster ID of a server process named Server0 is 12621850, then
you can specify the SERVERID in the format: Server0:12621850.

Outputs of the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

260

MONITORING THE SAP W EB APPLICATION SERVE R

Measurements
made by the
test

Measurement
Bound objects:

Measurement
Unit
Number

Indicates the total number of
objects that are bound in the
naming tree, including the
serializable
and
nonserializable objects.
Byte array cache size:

Interpretation
This measure gives an idea about the
application runtime.

Indicates the size of the byte
array cache.

4.3.15

WebContainer Test

The WebContainer test monitors the functions of the Web Container Service, which manages J2EE Web components
across a cluster environment, generates dynamic responses, and so on. This service enables the life cycle of Web
applications to be managed. It also helps developing and running session- and security-aware Web applications.

Purpose

Monitors the functions of the Web Container Service, which manages J2EE Web components
across a cluster environment, generates dynamic responses, and so on.

Target of the
test

The SAP Web AS

Agent
deploying the
test

An internal agent

261

MONITORING THE SAP W EB APPLICATION SERVE R

Configurable
parameters for
the test

262

MONITORING THE SAP W EB APPLICATION SERVE R

Outputs of the
test
Measurements
made by the
test

One set of results each for the Dispatcher and each of the configured server processes of the
SAP Web AS

Measurement

New requests:

Measurement
Unit
Number

Indicates the number of
requests newly received by
the Web Container Service
since the last measurement
period.
Current http sessions:

Number

Indicates the number of
HTTP sessions that are
currently valid.
Current secure sessions:

Number

Indicates the number of valid
security sessions currently
created for HTTP clients.
Invalid http sessions:

Number

Indicates the number of
HTTP sessions invalidated by
application since the last
measurement period.

263

Interpretation

MONITORING THE SAP W EB APPLICATION SERVE R

Invalid secure sessions:

Number

Indicates the number of
security sessions which have
been
invalidated
by
application since the last
measurement period.
Timeout http sessions:

Number

Indicates the number of
HTTP sessions which have
timed out since the last
measurement period.
Timeout secure sessions:

Number

Indicates the number of
secure sessions which have
timed out since the last
measurement period.

264

MONITORING MAXDB

Monitoring MaxDB
MySQL MaxDB is a mature and reliable database system that effortlessly handles heavy-duty transactions related to
OLTP. As MaxDB embeds special capabilities to handle all SAP applications, in-depth monitoring of MaxDB is
necessary to ensure the continuous availability and good health of the SAP environment.
The eG Enterprise suite offers a specialized monitoring model (see Figure 5.2) for the MaxDB server using which the
following queries can be effectively answered:

 Is a connection to the database available?
 Is the OMS heap been excessively utilized?
 Is there enough free space in the data area for permanent data, or is the temporary data
occupying a large portion of it?

 Have locks been held for too long a time? Are deadlocks and lock collisions kept at a
minimum?

 Is the log area been used excessively, or are log backups carried out frequently?
 What type of QUERY statements are most often executed on the database? How long does
the database server take to execute a simple load query?

 Are many transaction rollbacks happening?
 Does the server handle all I/O requests to it promptly, or are there too many requests
pending processing?

 Are all caches adequately sized? Are there excessive cache misses?

265

MONITORING MAXDB

Figure 5.2: Layer model of a MaxDB server
The eG agent on MaxDB executes a wide variety of tests on the server to assess its health. Typically, these tests
connect to a database on the MaxDB server as a SYSDBA, access certain key system tables on the database, and pull
out critical performance statistics pertaining to the MaxDB server from the system tables. Every layer of Figure 5.2
above is associated with one/more of these tests.

Note:

Before monitoring the MaxDB server, do the following:

 Connect to the URL: http://dev.mysql.com/downloads/
 Scroll down the page that appears next to view a section titled, MaxDB by MySQL - - SAP R/3
Cerfified.
 In that section, click on the hyperlink representing the latest version of MaxDB.
 Scroll down the page that appears next to view the list of downloads available for the latest
version. From the list, download the JDBC Driver Binary to the local host.
 A file named sapdbc-.jar gets downloaded.
 Next, copy the sapdbc-.jar file to the /opt/egurkha/lib directory.
 Once copied, rename the sapdbc-.jar file to sapdbc.jar.
 Restart the eG agent.
The sections to come will discuss each of the top 4 layers of Figure 5.2 in more detail. The other layers have been
dealt with extensively in the Monitoring Unix and Windows Servers document.

5.1 The MAXDB Net Layer
Using the Db Connection test associated with it (see Figure 5.3), the MAXDB Net layer measures the availability and
responsiveness of the MaxDB server.

266

MONITORING MAXDB

Figure 5.3: The test associated with the MAXDB Net layer

5.1.1

Db Connection Test

The Db Connection test measures the availability and responsiveness of the MaxDB server.

Purpose

Measures the availability and responsiveness of the MaxDB server

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

DATABASENAME - The test connects to a database on MaxDB and extracts performance
statistics from the system tables in the database. Therefore, provide the name of a
database in the DATABASENAME text box.

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement

Measurement
Unit

267

Interpretation

MONITORING MAXDB

Database availability:
Indicates
whether
database
connection
available or not.

Percent

The value 100 indicates availability, the value
0 indicates non-availability.

Secs

A sudden increase in response time is
indicative of a bottleneck at the database
server.

the
is

Response time:
Indicates the time taken to
execute
a
simple
load
database query.

5.2 The MAXDB Memory Layer
The tests associated with the MAXDB Memory layer help determine the following:

 Whether the data area has been adequately sized or not
 Whether the locking mechanism is functioning smootly on the database server
 Whether log queues are overloaded with log entries
 Whether adequate memory is available in the log area
 How well the SAP liveCache manages objects

Figure 5.4: The tests associated with the MAXDB Memory layer

5.2.1

Db Data Area Stats Test

All data volumes in a database instance are known collectively as the data area. The data area contains, amongst
other things, the application data, the database catalog and the undo log entries of the database instance. This test
monitors the usage of the data area.

Purpose

Monitors the usage of the data area

Target of the

The MaxDB server

268

MONITORING MAXDB

test
Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement
Usable size:

Measurement
Unit
MB

There must also always be sufficient space in
the data area to hold all the data that is
created
during
database
operations.
Therefore, ideally, this value should be high.

Indicates the data area that is
currently available for data.
Used size:

Interpretation

Indicates the memory in data
area that is currently used for
data.
Data area usage:

Percent

Indicates the percentage of
memory in the data area that
is actually used for data.
Data on volume:

Indicates the amount of data
that has been written to the
data area, currently.

269

Ideally, this value should not be very high.

MONITORING MAXDB

Data not on volume:

Pagers (which are tasks in the user kernel
thread) write the data from the data cache to
the data area for each savepoint. If a lot of
data was changed and the pagers would
have to write many pages at the next
savepoint, then the pagers write data from
the data cache to the data area before the
next savepoint.

Indicates the amount of
permanent data that has to
be written to the data area at
the next savepoint.

Permanent size used:

Indicates the data area that is
currently used for permanent
data.
Temporary size used:

A large proportion of temporary data
indicates large amounts of (buffer) result
sets. If the value of this measure is high,
then find the statement that is causing large
amounts of (buffer) result sets to be created,
and check the access strategies for this
statement.

Indicates the data area that is
currently used for temporary
data.

5.2.2

Db Locks Test

Multiple transactions can access the same database object, such as a table, at the same time. To isolate the
transactions from one another, the database system sets locks for database objects. The Db Locks test monitors the
locking activity on MaxDB.

Purpose

Monitors the locking activity on MaxDB

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

270

MONITORING MAXDB

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement
Unit

Measurement

Num locks:

Number

Indicates the number of locks
currently in the database.
Transaction holding locks:

Interpretation

A consistent increase in the value of this
measure indicates a contention for locks.

Number

Indicates the number of
transactions to which locks
have
been
assigned,
currently.
Transaction request locks:

Number

Indicates the number of
transactions requesting locks
in the last measurement
period.
Num oms locks:

Number

Indicates the number of OMS
locks
currently
in
the
database.
Deadlock rate:
Indicates
deadlocks

the

Deadlocks/Sec
rate

271

A deadlock may arise due to various
situations including bad design of queries and
deficient coding practices. A deadlock is a
situation where both/all the lock requestors
are in a mutual or a multi-way tie. Any
deadlocks are detrimental to database
application performance.

MONITORING MAXDB

Collision rate:

Collisions/Sec

Indicates the rate of lock
collisions.

A lock collision occurs when tasks running in
different threads attempt to access a global
storage area in parallel. The synchronization
required for this often leads to an increased
collision rate. Generally, the risk of collision
rises with the number of processors used
(MAXCPU general database parameter). In
multiprocessor systems, you should therefore
check whether the database system can fulfill
the needs of the applications with fewer
CPUs. If high collision rates occur in
multiprocessor central systems (database
system and application running on the same
computer), check whether the computer’s
CPU is overloaded, and whether the database
threads are blocked by other applications. In
this case, the database threads that contain
user tasks should receive REAL TIME
PRIORITY from the operating system. To
avoid operating system blocks however, the
value of MAXCPU must be at least one lower
than the number of actual CPUs. If the high
collision rates occur in the DATAn, SPLITn or
TREEn regions, increase the values of both
the general database parameter CACHE_SIZE
and the special database parameters
_DATA_CACHE_RGNS and _TREE_RGNS. If
the high collision rates occur in the TRACE or
BUFWRTR regions, then activate the
database
trace
temporarily
for
troubleshooting only.
Note:
One exception to this in liveCache instances
is high collision rates in the OMSVDIR and
CNSTVIEW regions. This is normal for certain
actions, such as a simultaneous CIF queue
transfer.

272

MONITORING MAXDB

Escalation rate:
Indicates
the
escalations.

rate

Escalations/Sec

Escalations show the total number of rows
locked by a single user session. If more than
a certain percentage of the rows of a table
are locked by a single user session, then the
database system locks the entire table. You
can specify the maximum number of possible
row locks in the lock list in the general
database
parameter
MAXLOCKS.
The
database system attempts to convert the row
lock to a table lock if a task holds more than
0.1*MAXLOCKS row locks in a table. If too
many escalations occur, increase the
parameter value. Whether escalations lead to
problems depends strongly on the application
in question. If escalations occur, check the
application to see whether you can split any
change transactions that lock a lot of rows
into several individual transactions.

Locks/Sec

A consistent increase in the value of this
measure could indicate a probable escalation.

Row locks:
Indicates the rate of row
locks.
Table locks:

Locks/Sec

Indicates the rate of table
locks.
Request timeouts:

Timeouts/Sec

Indicates the rate at which
lock requests exceeded the
timeout value.

5.2.3

If the value of this measure is high, you
might want to reset the REQUEST_TIMEOUT
value.

Db Lock Waits Test

The Db Lock Waits test reports the number of requests that are awaiting locks.

Purpose

Reports the number of requests that are awaiting locks

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

273

MONITORING MAXDB

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

One set of results for every lock type operational on the MaxDB server being monitored

Measurement

Lock waits:

Measurement
Unit
Number

Indicates the number of lock
waits
currently
in
the
database.

5.2.4

Interpretation

Lock waits can be caused by transactions that
take too long to execute. Long wait times can
also occur when various applications want to
lock the same object.

Db Log Queue Test

The log queue is the main memory area, in which redo log entries from the transactions are stored. The Db Log
Queue test monitors the usage of the log queue.

Purpose

Monitors the usage of the log queue

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

274

MONITORING MAXDB

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

One set of results for every log queue on the MaxDB server being monitored

Measurement

Queue max used:

Measurement
Unit

Interpretation

Number

Indicates
the
maximum
number
of
transactions
written to the log queue.
Log entries inserted:

Number

Indicates the number of log
entries inserted into the
queue
in
the
last
measurement period.
Queue overflow:

Number

Indicates the number of wait
situations that arose due to
log queue overflows in the
last measurement period.
Group commits:

Number

Indicates the number of log
pages whose writing was
waited for by more than one
transaction, in the last
measurement period.
Log queue transactions:

Number

Indicates the number of
transactions waiting to write
in the log queue in the last
measurement period.
275

If the log queue becomes full before log
pages are written to the log area, then a log
queue overflow occurs. If the value of this
measure keeps increasing, you might want to
consider altering the log queue size by
resetting the LOG_IO_QUEUE parameter.

MONITORING MAXDB

Max waits per page:

Number

Indicates
the
maximum
number of transactions that
simultaneously waited for the
same page to be written.
Physical write rate:

A high value of this measure could cause
undue delays in transaction execution.

Writes/Sec

Indicates the rate at which
log pages were written to the
log area.

5.2.5

Db Log Test

All log volumes in a database instance are known collectively as the log area. The database system writes the redo
log entries of transactions in the log segments of the log area. Redo log entries are needed, amongst other things,
for restoring a consistent database instance state after a restart or a system breakdown. The Db Log test monitors
the usage of the log area.

Purpose

Monitors the usage of the log area

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement

Measurement
Unit

276

Interpretation

MONITORING MAXDB

Total log memory:

Indicates the current size of
the log area.
Log memory used:

If the value of this measure grows
dangerously close to the value of the
Total_log_memory measure, it indicates that
the log area is fast becoming full. This
indicates a probable problem condition, as a
full log area causes the database to shut
down. To avoid this, it is recommended that
you carry out log backups at regular
intervals, because the database system
cannot overwrite the segments in the log
area until after a successful log backup.

Percent

If the value of this measure grows
dangerously close to 100%, it indicates that
the log area is fast becoming full. This
indicates a probable problem condition, as a
full log area causes the database to shut
down. To avoid this, it is recommended that
you carry out log backups at regular
intervals, because the database system
cannot overwrite the segments in the log
area until after a successful log backup.

Indicates the size of the log
area currently utilized.

Percentage of log area
used:
Indicates the percentage of
the log area utilized.

Transaction rate:

Trans/Sec

Indicates
the
rate
of
transactions to the log area.
Write transaction rate:

Trans/Sec

Indicates the rate of write
transactions to the log area.
Percentage
transactions:

write

Percent

Indicates the percentage of
write transactions to the log
area.
Log queues:

Number

Indicates the current number
of log queues.
Queue size:

Indicates the size of the log
queue.

277

This measure is a good indicator of the level
of activity on the log area.

MONITORING MAXDB

5.2.6

Db Oms Stats Test

Object management system (OMS) is a type of data management. Only SAP liveCache database instances use OMS.
SAP liveCache is an enhancement of the MaxDB relational database system. In SAP liveCache, the actual data
structures and data streams (such as networks and relationships) can be mapped more easily and effectively. A large
part of the data in a SAP liveCache database instance is managed in objects. This object data is called OMS data.
OMS data is managed in containers that are assigned to precisely one persistent C++ class of the object type, and is
edited in the OMS intermediate layer. The OMS data pages are in the data cache. The Db Oms Stats test measures
how well the SAP liveCache manages objects using OMS.

Purpose

Measures how well the SAP liveCache manages objects using OMS

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for every liveCache object on the MaxDB server being monitored

Measurement

Measurement
Unit

278

Interpretation

MONITORING MAXDB

Heap used:

The memory requirements in the OMS heap
are very high for the running DB procedures.
If the memory utilization in the OMS heap
reaches 100% of its limit, there is the risk of
errors in the DB procedures (Out of Memory
Exceptions), or that OMS version data is
swapped from the OMS heap to the global
data cache (OMS version is unloaded). It is
recommended that you configure the general
database parameter CACHE_SIZE and the
liveCache parameter OMS_HEAP_LIMIT in
such a way that it prevents swapping at the
operating system level and errors in DB
procedures.

Indicates
the
liveCache
memory that is been used
currently.

Reserved size:

Indicates
the
memory
managed by the allocator.
Memory allocation rate:
Indicates
memory
second.

Allocations/Sec

the number of
allocations
per

Memory release rate:

A higher rate indicates higher and faster
memory utilization.

Releases/Sec

Indicates the number of
memory releases per second.
Spinlock rate:

Attempts/Sec

When a requested lock is not
available, then the process
will spin and try again to
acquire the lock. This is
known as a Spinlock. This
measure
indicates
the
number of attempts that
were made per second to
acquire a spinlock.
Collision rate:

Collisions/Sec

Indicates the rate at which
attempts to get a spinlock
failed.

279

A consistent increase in this rate indicates
that some locks have been held for too long a
time.

MONITORING MAXDB

Spinloop rate:

Attempts/Sec

Indicates the rate at which
attempts were made to
acquire a spinlock without
prior release of the CPU.
Yieldloop rate:
Indicates
attempts
acquire a
release of

Attempts/Sec

the rate at which
were made to
spinlock after prior
the CPU.

Errors rate:

Errors/Sec

Indicates the rate at which
errors were detected and
automatically corrected.

5.3 The MAXDB Cache Layer
The utilization of the data cache and the I/O buffer cache is monitored using the tests mapped to the MAXDB Cache
layer (see Figure 5.5).

Figure 5.5: The tests associated with the MAXDB Cache layer

5.3.1

Db Data Cache Test

The Db Data Cache test monitors the usage of the data cache on MaxDB. The data cache contains the last read- or
write-accessed pages of the data volumes. It is shared by all simultaneously active users.

Purpose

Monitors the usage of the data cache on MaxDB

Target of the
test

The MaxDB server

Agent
deploying the

An internal agent

280

MONITORING MAXDB

test
Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

One set of results for the MaxDB server being monitored

Measurement

Data cache hit ratio:

Measurement
Unit
Percent

A high hit rate of at least 98% is
recommended for the data cache. If the hit
rate is low, consider changing the size of the
data cache.

The size of the data cache has the following
effect on the performance of the database
system:

Indicates the percentage of
successful accesses to the
data cache.
Cache usable size:

Interpretation

Indicates the current size of
the data cache.

A large data cache makes a
high hit rate possible.
If the data cache is too large for
a small main memory, this can
lead
to
operating
system
swapping with a very high level
of I/O activity.
However, since the data cache is dynamically
dimensioned by the database system, you
cannot configure the size of the data cache
directly, but can only influence it implicitly by
configuring the I/O buffer cache. The
database system takes the pages required for
the data cache from the I/O buffer cache. If
the other I/O buffer cache user, the
converter, grows in size, the database system
decreases the size of the data cache, if
necessary.
281

MONITORING MAXDB

Cache used size:

If converter cache or catalog cache run out of
space, the data cache is used; so, it is
recommended that you increase the overall
cache size.

Percent

If converter cache or catalog cache run out of
space, the data cache is used; so, it is
recommended that you increase the overall
cache size.

Since the data in an SAP liveCache database
instance consists mainly of OMS data, you
should configure the data cache for SAP
liveCache database instances to be large
enough to store all the OMS data, if possible.

Indicates
the
currently
utilized portion of the data
cache.
Percent
used:

data

cache

Indicates the percentage of
the cache that is utilized.
Oms data size:
Indicates the size of the data
cache that is currently used
for storing OMS data.
History data size:

Indicates the size of the data
cache required for consistent
reads
and
transactions
management.
SQL data size:

Indicates the size of the data
cache not required either for
OMS data or consistent reads
and transaction management.

5.3.2

Db I/O Cache Test

The Db I/O Cache test monitors the I/O Buffer Cache on the MaxDB server. The database system uses the I/O buffer
cache to manage all of the main memory that is available for I/O operations. The converter and the data cache are
the most important main memory consumers that the database system manages in the I/O buffer cache. The
converter is where the database system keeps information about which logical page number is saved at what
physical position (MaxDB block address). When the database system fails to find a page number in the data cache, it
searches for the page number in the converter and uses this to calculate the physical position of the data page in the
data volumes. If the converter grows while the database is running, and requires more pages, the database system
gives it more pages from the I/O buffer cache. If no more pages are available there, data is displaced from the data
cache and made available to the converter.

Purpose

Monitors the I/O Buffer Cache on the MaxDB server

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

282

MONITORING MAXDB

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

One set of results for the MaxDB server being monitored

Measurement

Total I/O cache size:

Measurement
Unit

Interpretation

Indicates the current size of
the I/O buffer cache.
Data cache size:

A high value of this measure is imperative to
ensure a high data cache hit rate. If the value
of this measure is very low, it is
recommended
that
you
reset
the
CACHE_SIZE parameter.

Percent

A high value of this measure is imperative to
ensure a high data cache hit rate. If the value
of this measure is very low, it is
recommended
that
you
reset
the
CACHE_SIZE parameter.

Indicates the portion of the
I/O buffer cache that is
currently utilized by the data
cache.
Percent data cache:
Indicates the percentage of
the I/O buffer cache used by
the data cache.
Converter size:

Indicates the space in the I/O
buffer cache currently used
by the converter.
Percent coverter size:

Percent

Indicates the percentage of
the I/O buffer cache used by
the converter.

283

If the value of this measure falls, data is
displaced from the data cache and made
available to the converter.

MONITORING MAXDB

IO mgmt size:

Indicates the current size of
the I/O management.
File directory size:

Indicates the space currently
used by the file directories.
Restart record size:

Indicates the space currently
used by restart records that
store all information that the
database system requires to
restart the database instance.
Block allocator size:

Indicates the amount of
memory currently used by
block allocators.
Unused size:

Ideally, this value should be high. A very low
value of this measure indicates the need to
reset the CACHE_SIZE.

Indicates the free space in
the I/O buffer cache.

5.4 The MAXDB Service Layer
Using the tests associated with the MAXDB Service layer (see Figure 5.6), you can monitor the following:

 How well the database session caches are utilized
 The SQL statements and transactions executing on the MaxDB server
 The request processing capability of the MaxDB server
 The different types of queries that are executed on the server
 The active sessions on the database server

284

MONITORING MAXDB

Figure 5.6: The tests associated with the MAXDB Service

5.4.1

Db Session Cache Test

The Db Session Cache test reveals whether the database session cache has been effectively utilized or not.

Purpose

Reveals whether the database session cache has been effectively utilized or not

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

285

MONITORING MAXDB

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise system embeds an optional detailed diagnostic capability. With this capability,
the eG agents can be configured to run detailed, more elaborate tests as and when specific
problems are detected. To enable the detailed diagnosis capability of this test for a
particular server, choose the On option against DETAILED DIAGNOSIS. To disable the
capability, click on the Off option.
The option to selectively enabled/disable the detailed diagnosis capability will be available
only if the following conditions are fulfilled:
The eG manager license should allow the detailed diagnosis capability
Both the bad and normal frequencies configured for the detailed diagnosis
measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement

Cache hits:

Measurement
Unit
Percent

Indicates the percentage of
total database sessions that
were accessed from the
cache.

Interpretation

If the value of this measure is over 85%, it is
a sign of good health. Values lesser than
85% might warrant a change in the cache
size
using
the
CAT_CACHE_SUPPLY
parameter.
The detailed diagnosis of this measure, if
enabled, provides a list of session IDs, the
number of attempts made to access each
session, the number of times every listed
session was successfully accessed from the
cache, and the hit rate.

286

MONITORING MAXDB

5.4.2

Db Activity Test

A transaction is a sequence of SQL statements that are handled by the database system as a unit, in the sense that
any modifications made to the database by the SQL statements are either all reflected in the state of the database,
or else none of the database modifications are retained. Among other things, the transaction management functions
of a database system make sure that parallel transactions from multiple database sessions are processed correctly,
and that they deliver the same results as if the transactions were processed sequentially. The Db Activity test reports
statistics pertaining to the transactions executing on MaxDB.

Purpose

Reports statistics pertaining to the transactions executing on MaxDB

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement

Sql command rate:
Indicates the rate at which
SQL
statements
were
executed.
Sql parsing rate:

Measurement
Unit
Commands/Se
c

Parses/Sec

Indicates the rate at which
SQL statements were parsed.

287

Interpretation

MONITORING MAXDB

Parsed
rate:

sql

execurtion

Executions/Sec

Indicates the rate at which
parsed SQL statements were
executed.

Transaction commits:

A high level of parse activity when the
database is running can indicate a missing
statement cache implementation in your
application, or a deactivated parse info cache
in the JDBC interface. A high level of parse
activity is normal when programs or program
components are started for the first time.

Commits/Sec

Indicates the rate at which
transactions were committed.
Transaction rollbacks:

Rollbacks/Sec

Ideally, there should be few user rollbacks
happening, since rollbacks are costly
operations on the database.

Percent

Ideally, there should be few user rollbacks
happening, since rollbacks are costly
operations on the database.

Indicates the rate at which
transactions were rolled back.
Rollbacks:
Indicates the percentage of
rollbacks.
Memory sort rate:

Sorts/Sec

Indicates the rate at which
sorting
operations
were
performed on the main
memory to build indexes.
Table scans:

Scans/Sec

Indicates the rate of table
scans.
Index scan rate:

A high value of table scans is an indicator
that the queries do not use indexes at all or
use indexes with low selectivity.

Scans/Sec

Indicates the rate of index
scans.

5.4.3

Db I/O Stats Test

The Db I/O Stats test indicates how efficiently MaxDB handles read/write requests to the database.

Purpose

Indicates how efficiently MaxDB handles read/write requests to the database

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

288

MONITORING MAXDB

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

One set of results for every data volume and log volume on the MaxDB server being monitored

Measurement

Database read rate:

Measurement
Unit

Interpretation

Reads/Sec

Indicates the rate at which
database
reads
were
performed.
Page read operations:

Pages/Sec

Indicates the rate at which
page reads were performed.
Database read time:

Secs

A high value of this measure indicates a
reading bottleneck.

Indicates the time taken by
the database to perform read
operations
in
the
last
measurement period.
Database write rate:

Writes/Sec

Indicates the rate at which
data is written to the
database.
Page write operations:

Pages/Sec

Indicates the rate at which
page writes were performed.

289

MONITORING MAXDB

Database write time:

Secs

A high value of this measure indicates a
writing bottleneck.

Number

If the value of this measure keeps increasing,
it is indicative of a processing bottleneck.

Indicates the time taken by
the database to perform write
operations
in
the
last
measurement period.
Pending I/O operations:
Indicates the number of IO
operations
still
to
be
completed.

5.4.4

Db Query Test

A QUERY statement specifies a result table that can be ordered. The Db Query test monitors the different types of
QUERY statements that are executed on the MaxDB database.

Purpose

Monitors the different types of QUERY statements that are executed on the MaxDB database

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test
Measurements
made by the
test

One set of results for the MaxDB server being monitored

Measurement

Measurement
Unit

290

Interpretation

MONITORING MAXDB

Create statements:

Number

Indicates the number of
CREATE statements that were
executed
in
the
last
measurement period.
Alter statements:

Number

Indicates the number of
ALTER statements that were
executed
in
the
last
measurement period.
Drop statements:

Number

Indicates the number of
DROP statements that were
executed
in
the
last
measurement period.
Insert statements:

Number

Indicates the number of
INSERT statements that were
executed
in
the
last
measurement period.
Insert row statements:

Number

Indicates the number of rows
inserted
in
the
last
measurement period.
Update statements:

Number

Indicates the number of
UPDATE
statements
that
were executed in the last
measurement period.
Update row statements:

Number

Indicates the number of rows
that were updated in the last
measurement period.
Delete statements:

Number

Indicates the number of
DELETE statements that were
executed
in
the
last
measurement period.
Delete row statements:

Number

Indicates the number of rows
that were deleted in the last
measurement period.

291

MONITORING MAXDB

5.4.5

Db Sessions Test

To work with a database instance, to make data queries or to manage the database instance, you have to open a
database session. This can happen as follows:
The user logs on to the database instance with a user name and password, thus opening a
database session. Later, the database session is terminated explicitly by the user or closed
implicitly when the timeout value is exceeded.
A database tool implicitly opens a database session and then closes it again later.
The Db Sessions test reveals the level of activity on the MaxDB server by reporting the number of active database
sessions.

Purpose

Reveals the level of activity on the MaxDB server by reporting the number of active database
sessions

Target of the
test

The MaxDB server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

TEST PERIOD - How often should the test be executed

HOST - Host name of the server for which the test is to be configured

PORT - The port number to which the server is listening

USERNAME - Since users with the SYSDBA privilege alone are allowed access to system
tables, specify the name of such a user against USERNAME.

PASSWORD - Provide the PASSWORD that corresponds to the specified USERNAME.

CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM
PASSWORD box.

Outputs of the
test

One set of results for the MaxDB server being monitored

292

MONITORING MAXDB

Measurements
made by the
test

Measurement
Number of sessions:
Indicates
currently
sessions.

Measurement
Unit
Number

the number of
active database

293

Interpretation
This measure is a good indicator of the
workload on the database server.

CONCLUSION

Conclusion
This document has described in detail the monitoring paradigm used and the measurement capabilities of the eG
Enterprise suite of products with respect to SAP Environments. For details of how to administer and use the eG
Enterprise suite of products, refer to the user manuals.
We will be adding new measurement capabilities into the future versions of the eG Enterprise suite. If you can
identify new capabilities that you would like us to incorporate in the eG Enterprise suite of products, please contact
support@eginnovations.com. We look forward to your support and cooperation. Any feedback regarding this manual
or any other aspects of the eG Enterprise suite can be forwarded to feedback@eginnovations.com.

294

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 302
Language                        : en-US
Title                           : Manual
Author                          : Geetha
Creator                         : Microsoft® Word 2010
Create Date                     : 2015:02:10 21:30:37+05:30
Modify Date                     : 2015:02:10 21:30:37+05:30
Producer                        : Microsoft® Word 2010

EXIF Metadata provided by EXIF.tools

Manual Monitoring SAP Environments

Navigation menu

Versions of this User Manual:

Views

Navigation