Manual Monitoring SAP Business Objects

User Manual: Monitoring SAP Business Objects

Open the PDF directly: View PDF .
Page Count: 125 [warning: Documents this large are best viewed by clicking the View PDF Link!]

1. Monitoring SAP Business Objects
2. Conclusion

Monitoring SAP Business Objects

eG Enterprise v6.0

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 2003, 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.

Table of Contents

MONITORING SAP BUSINESS OBJECTS ............................................................................................................................... 1

1.1 How does eG Enterprise Monitor the SAP BOBI Platform?............................................................................................. 4

1.1.1 Enabling the Monitoring Application of the SAP BOBI Platform ............................................................................ 5

1.2 The BOBI Storage Layer .................................................................................................................................................. 8

1.2.1 Dashboards Cache Server Status Test ....................................................................................................................... 9

1.2.2 Dashboards Cache Server Performance Test........................................................................................................... 12

1.2.3 File Repository Server Status Test .......................................................................................................................... 14

1.2.4 File Repository Server Performance Test ................................................................................................................ 17

1.3 The BOBI Processing Layer ........................................................................................................................................... 18

1.3.1 Adaptive Job Server Status Test .............................................................................................................................. 19

1.3.2 Adaptive Job Server Destinations Test.................................................................................................................... 22

1.3.3 Adaptive Job Server Performance Test ................................................................................................................... 26

1.3.4 Adaptive Processing Server Status Test .................................................................................................................. 28

1.3.5 Adaptive Processing Server Performance Test ....................................................................................................... 31

1.3.6 Connection Server Status Test ................................................................................................................................ 34

1.3.7 Crystal Reports Server Status Test .......................................................................................................................... 37

1.3.8 Crystal Reports Server Performance Test ............................................................................................................... 40

1.3.9 Dashboards Server Status Test ................................................................................................................................ 42

1.3.10 Dashboards Server Performance Test ..................................................................................................................... 45

1.3.11 Report Application Server Test ............................................................................................................................... 47

1.3.12 Web Intelligence Server Status Test ....................................................................................................................... 50

1.3.13 Web Intelligence Server Cache Test ....................................................................................................................... 53

1.3.14 Web Intelligence Server Performance Test ............................................................................................................. 55

1.3.15 Web Intelligence Server Activity Test .................................................................................................................... 57

1.3.16 Process Logs Test.................................................................................................................................................... 59

1.3.17 Dimensional Semantic Layer Bridge Service Test .................................................................................................. 63

1.4 The BOBI Management Layer ........................................................................................................................................ 64

1.4.1 Central Management Server Status Test ................................................................................................................. 65

1.4.2 Central Management Server Audit Test .................................................................................................................. 68

1.4.3 Central Management Server Jobs Test .................................................................................................................... 72

1.4.4 Central Management Server System DB Test ......................................................................................................... 73

1.4.5 Central Management Server Workload Test ........................................................................................................... 76

1.4.6 Event Server Test .................................................................................................................................................... 78

1.5 The BOBI Web Access Layer ......................................................................................................................................... 82

1.5.1 Web Application Container Server Test.................................................................................................................. 82

1.5.2 Communication Logs Test ...................................................................................................................................... 85

1.6 The BOBI Services Layer ............................................................................................................................................... 89

1.6.1 Multi Dimensional Analysis Service Test ............................................................................................................... 90

1.6.2 Platform Search Service Test .................................................................................................................................. 92

1.6.3 Data Federation Service Test .................................................................................................................................. 94

1.6.4 Dashboard Logs Test .............................................................................................................................................. 96

1.6.5 Report Logs Test ................................................................................................................................................... 101

1.6.6 Data Federation Service Queries Test ................................................................................................................... 105

1.6.7 Node Health Test .................................................................................................................................................. 108

1.6.8 Probes Test ............................................................................................................................................................ 109

1.6.9 Service Category Status Test................................................................................................................................. 111

1.6.10 Services Usage Test .............................................................................................................................................. 116

CONCLUSION ........................................................................................................................................................................... 119

Table of Figures

Figure 1. 1: Architecture of SAP BusinessObjects BusinessIntelligence Platform .................................................................................................... 2

Figure 1. 2: The layer model of the SAP BOBI platform .......................................................................................................................................... 3

Figure 1. 3: Logging into the Central Management Console ..................................................................................................................................... 6

Figure 1. 4: Clicking the Applications link in the CMC Home Page ......................................................................................................................... 6

Figure 1. 5: Accessing the properties of the Monitoring Application ........................................................................................................................ 7

Figure 1. 6: The Properties of the Monitoring Application ........................................................................................................................................ 7

Figure 1. 7: Determining the JNDI name from the RMI JMX agent end point URL ................................................................................................. 8

Figure 1. 8: The tests mapped to the BOBI Storage layer .......................................................................................................................................... 8

Figure 1. 9: The tests mapped to the BOBI Processing layer ................................................................................................................................... 19

Figure 1. 10: The tests mapped to the BOBI Management layer ............................................................................................................................. 65

Figure 1. 11: The tests mapped to the BOBI Web Access layer .............................................................................................................................. 82

Figure 1. 12: The tests mapped to the BOBI Services Layer ................................................................................................................................... 90

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Monitoring SAP Business Objects

SAP BusinessObjects BI (also known as BO or BOBJ) is a suite of front-end applications that allow business users to

view, sort and analyze business intelligence data.

The suite includes the following key applications:

 Crystal Reports -- Enables users to design and generate reports

 Xcelsius/Dashboards -- Allows users to create interactive dashboards that contain charts and graphs

for visualizing data

 Web Intelligence -- Provides a self-service environment for creating ad hoc queries and analysis of

data both online and offline

 Explorer -- Allows users to search through BI data sources using an iTunes-like interface. Users do not

have to create queries to search the data and results are shown with a chart that indicates the best

information match.

SAP BusinessObjects Business Intelligence platform can be thought of as a series of conceptual tiers:

 Client tier: The client tier contains all desktop client applications that interact with the SAP BusinessObjects

Business Intelligence platform to provide a variety of reporting, analytic, and administrative capabilities.

Examples include the Central Configuration Manager (BI platform installation program), Information design

tool (BI platform Client Tools installation program), and SAP Crystal Reports 2011 (available and installed

separately).

 Web tier: The web tier contains web applications deployed to a Java web application server. Web

applications provide SAP BusinessObjects Business Intelligence platform functionality to end users through a

web browser. Examples of web applications include the Central Management Console (CMC) administrative

web interface and BI launch pad. The web tier also contains Web Services. Web Services provides SAP

BusinessObjects Business Intelligence platform functionality to software tools via the web application server,

such as session authentication, user privilege management, scheduling, search, administration, reporting,

and query management. For example, Live Office is a product that uses Web Services to integrate SAP

BusinessObjects Business Intelligence platform reporting into Microsoft Office products.

 Management tier: The management tier (also known as intelligence tier) coordinates and controls all of the

components that make up SAP BusinessObjects Business Intelligence platform. It is comprised of the

Central Management Server (CMS) and the Event Server and associated services. The CMS provides

maintains security and configuration information, sends service requests to servers, manages auditing, and

maintains the CMS system database. The Event Server manages file based events, which occur in the

storage tier.

 Storage tier: The storage tier is responsible to handling files, such as documents and reports. The Input File

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Repository Server manages files that contain information to be used in reports, such as the following file

types: .rpt, .car, .exe, .bat, .js, .xls, .doc, .ppt, .rtf, .txt, .pdf, .wid, .rep, .unv. The Output File Repository Server

manages reports created by the system, such as the following file types: .rpt, .csv, .xls, .doc, .rtf, .txt, .pdf,

.wid, .rep. The storage tier also handles report caching to save system resources when users access reports.

 Processing tier: The processing tier analyzes data and produces reports. This is the only tier that accesses

the databases that contain report data. This tier is comprised of the Adaptive Job Server, Connection Server

(32- and 64-bit), and processing servers such as the Adaptive Processing Server or Crystal Reports

Processing Server.

 Data tier: The data tier consists of the database servers hosting the CMS system database and Auditing Data

tore. It also consists of any database servers containing relational, OLAP, or other data types for reporting

and analytic applications.

SAP BusinessObjects Business Intelligence platform consists of collections of servers running on one or more hosts.

Small installations (such as test or development systems) can use a single host for a web application server,

database server, and all BI platform servers. Medium and large installations can have servers running on multiple

hosts. Large installations can have several BI platform server hosts working together in a cluster. The term server is

used to describe an operating system level process (on some systems, this is referred to as a daemon) hosting one

or more services. For example, the Central Management Server (CMS) and Adaptive Processing Server are servers. A

server runs under a specific operating system account and has its own PID. A service is a server subsystem that

performs a specific function. The service runs within the memory space of its server under the process ID of the

parent container (server). For example, the Web Intelligence Scheduling Service is a subsystem that runs on the

Adaptive Job Server. A node is a collection of BI platform servers running on the same host and managed by the

same Server Intelligence Agent (SIA). One or more nodes can be on a single host.

Figure 1. 1: Architecture of SAP BusinessObjects BusinessIntelligence Platform

If a single server/service on a node fails or processes requests slowly, then the user experience with the

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

corresponding front-end application will suffer, making analysis of business intelligence data difficult and delaying

crucial business decisions. If this is to be avoided, then every server/service running in a node should be closely

monitored and administrators should be proactively notified of performance setbacks that the servers/services

experience. eG Enterprise provides a specialized, web-based

SAP BOBI

monitoring model for this purpose.

Figure 1. 2: The layer model of the SAP BOBI platform

Each layer of Figure 1.2 above is mapped to tests that monitor the overall health, availability, and performance of

each of the servers running in a configured node. Using the metrics so reported, administrators can find quick and

accurate answers for the following performance queries:

 Are the various BOBI services in healthy state? Is the node healthy ?

 What is the system load in terms of publications, instances running, reports scheduled etc.,?

 What are the errors occurring in the various Crystal Reports servers defined?

 What is the load generated by the Multi Dimensional Analysis service in terms of queries running,

sessions and cubes created?

 How many resource intensive queries are running for the Data Federation service? What is the disk

and memory utilization of queries run by this service? How many queries have failed? What is the

current number of connections created?

 Are there any Dashboards server errors?

 How is the Platform Search Service performing?

 Are there any errors from connection servers, web intelligence servers etc.,?

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

 Is the BI launchpad available? What is the response time like?

 Is the Central Management Server auditing properly? How many users are currently using the server?

What is their average response time?

 Have any Central management server jobs failed? How many jobs are pending?

 Are the Job Server destinations available? Are there are errors in the server?

 What is the performance of the Adaptive Processing Server JVM? Are there any errors in this server?

 What is the utilization and response time of the Dashboards processing server?

 How many connections are used by the Data Semantic Layer Bridge? How many queries are being run

for this service?

 How many documents is the Report Application Server processing? What is its thread utilization?

 How many CORBA requests is the web intelligence server processing? How many users are using the

web intelligence server? Are too many sessions getting timed-out?

 How is the web intelligence server cache utilization? What is the cache swap rate?

 Is the web intelligence server using too much memory ? What is its CPU utilization ?

 How is the Dashboards cache server performing? Is it slow?

 How many files are accessed through the file repository server? How many connections? What are the

data transfer rates?

 How is the health of each configured server? Which servers are enabled and are they running

properly?

 What is the rate of error messages occurring in the various servers running in this node? What are

those error messages?

 Is the root directory of the file repository server's partition running out of free space?

 Are the Bobi server processes running? How much CPU and memory are they using the node's

computer?

 What is the performance of the host computer on which the node has been installed? How is its

connectivity?

1.1 How does eG Enterprise Monitor the SAP BOBI Platform?

To collect all the metrics summarized above, it is recommended that you use eG’s Agent-based Monitor. This Monitor

should then be configured to connect to the SAP BOBI platform via JMX and obtain the status and performance

information of the node configured for monitoring, using the attributes exposed by BOBI's Managed beans.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

To enable the Monitor to establish this connection and collect metrics, the following pre-requisites should be fulfilled:

 The Monitoring Application of SAP BOBI should be up and running for the eG Monitor to perform

metrics collection. The Monitoring application allows you to capture the runtime and historical metrics

of BI platform servers, for reporting and notification. To know how to enable the Monitoring

Application, refer to Section 1.1.1 below.

 When managing the

SAP BOBI

component in the eG administrative interface, make sure you manage

it using the port number of the web application server on which SAP BOBI runs. For instance, if the

default tomcat application server is used for the SAP BOBI installation and its default port number has

not been changed, then specify 8080 as the Port number of the

SAP BOBI

component when managing

it.

 Each test run by the eG Monitor on the

SAP BOBI

should be configured with the following:

o The RMI PORT number of SAP BOBI’s Monitoring Application. To know how to determine the

RMI port of the Monitoring Application, refer to Section 1.1.1 below.

o The JNDI NAME of SAP BOBI’s Monitoring Application. To know how to determine the JNDI

name of the Monitoring Application, refer to Section 1.1.1 below.

o A JMX USER and JMX PASSWORD. Here, provide the credentials of a JMX user who fulfills

the following conditions:

 The Authentication Type of the user should be Enterprise.

 The user should have access rights to the BOBI Monitoring Application.

 The user should belong to the default

Monitoring users

group on SAP BOBI.

1.1.1 Enabling the Monitoring Application of the SAP BOBI Platform

To check the status of the Monitoring Application, enable it (if required, and determine its JNDI Name and RMI Port,

do the following:

1. Access the BOBI Central Management Console using a browser. When Figure 1.3 appears, login as a user who

belongs to the

administrators

group.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Figure 1. 3: Logging into the Central Management Console

2. The CMC Home Page then appears (see Figure 1.4). Click the Applications link indicated in Figure 1.4.

Figure 1. 4: Clicking the Applications link in the CMC Home Page

3. Then, select the Monitoring Application from the Applications list of Figure 1.5. To access the properties of the

chosen application, select the Properties option from the Manage menu, as shown by Figure 1.5.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Figure 1. 5: Accessing the properties of the Monitoring Application

4. The Monitoring Application Properties page (see Figure 1.6) will then appear. Here, select the Enable

Monitoring Application check box to enable the Monitoring Application.

Figure 1. 6: The Properties of the Monitoring Application

5. Also, select the Enable RMI protocol for JMX check box in Figure 1.6 to activate the RMI Port. Use the RMI port

number displayed in Figure 1.6 to configure the JMX REMOTE PORT parameter of the eG tests.

6. Likewise, you can also obtain the value for the JNDI NAME parameter from Figure 1.6. For this, first focus on

the RMI JMX agent end point URL specification in Figure 1.6. The JNDI Name is part of this URL. Figure 1.7 below

displays a sample URL and indicates which part of it forms the JNDI name.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Figure 1. 7: Determining the JNDI name from the RMI JMX agent end point URL

7. Finally, click the Save & Close button in Figure 1.6 to register the changes made to the properties of the

Monitoring Application.

The sections that follow discuss each of the top 5 layers of of Figure 1.2 in detail. The remaining layers have already

been discussed in the

Monitoring Unix and Windows Servers

document.

1.2 The BOBI Storage Layer

This layer reports the status and performance of the Dashboards Cache and File Repository servers.

Figure 1. 8: The tests mapped to the BOBI Storage layer

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

1.2.1 Dashboards Cache Server Status Test

The Dashboards Cache Server intercepts report requests sent from clients to the Dashboard server. If the cache

server cannot fulfill the request with a cached report page, it passes the request on to the Dashboard server, which

runs the report and returns the results. The cache server then caches the report page for potential future use.

If the cache server is down, then all report requests will be sent directly to the Dashboard server for servicing,

resulting in additional processing overheads. If the cache server is slow, report requests will be processed slowly,

increasing user dissatisfaction with the service. By promptly capturing the failure/slowness of a Dashboards Cache

server and rapidly taking action against such anomalies, administrators can ensure the continuous availability and

peak performance of the cache server. The Dashboards Cache Server Status test aids administrators in this

endeavor! This test tracks the health, status, and thread pool usage of the Dashboards cache server and alerts

administrators to probable deviations in the availability and performance of the server. This way, the test allows

administrators adequate time to take pre-emptive action against the issues noticed, so that guaranteed cache server

performance levels are maintained at all times.

Purpose

Tracks the health, status, and thread pool usage of the Dashboards cache server and alerts

administrators to probable deviations in the availability and performance of the server

Target of the

test

A SAP BOBI node

Agent

deploying the

test

An internal/remote agent

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

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 - Enter the port to which the specified HOST listens. This should be the port at

which the web application server hosting SAP BOBI listens.

4. JMX REMOTE PORT - Specify the RMI port number of the BOBI monitoring application.

To know the RMI port number of the monitoring application, refer to Section 1.1.1 of this

document.

5. JNDI NAME - Specify the lookup name for connecting to the JMX connector of the BOBI

monitoring application. To know the JNDI name, refer to Section 1.1.1 of this document.

6. JMX USER and JMX PASSWORD – Enter the credentials of an enterprise authenticated

BOBI user belonging to the default

monitoring users

group.

7. CONFIRM PASSWORD - Confirm the password by retyping it here.

8. NODE NAME – Specify the name of the BOBI node being monitored.

9. 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 the Dashboards cache server running in the node monitored

Measurements

made by the

Measurement

Unit

Interpretation

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

test

Health state:

Indicates the current health

state of the Dashboards

Cache server in the

monitored node.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

Danger

Caution

Healthy

If the server is not healthy, then the detailed

diagnosis of this measure, if enabled,

provides the process ID and processing

plugin name of the server.

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

the health state of the server. In the graph of

this measure however, the same is

represented using the numeric values only.

Server running state:

Indicates the current running

state of the Dashboards

Cache server.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

STOPPED

STARTING

INITIALIZING

RUNNING

STOPPING

FAILED

RUNNING_WITH_E

RRORS

RUNNING_WITH_W

ARNINGS

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

the running state of the server. In the graph

of this measure however, the same is

represented using the numeric values only.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Server enabled state:

Indicates whether/not the

Dashboards Cache server is

enabled.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

Disabled

Enabled

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

whether/not the server is enabled. In the

graph of this measure however, the same is

represented using the numeric values only.

Busy server threads:

Indicates the number of

server threads that are

currently servicing requests.

Number

If this measure reaches the configured

maximum thread pool size for the server,

new requests to the server would have to

wait until a server thread becomes free. If

this happens often, it may significantly

slowdown request processing by the server.

In such a situation, you may want to consider

resizing the thread pool.

1.2.2 Dashboards Cache Server Performance Test

Ideally, the cache server should be able to serve maximum report requests. If it cannot, then client queries will be

routed to the Dashboard Processing Server, which will fulfill the requests by running the queries on the database.

This will considerably increase databases accesses and related processing overheads. To minimize these overheads,

administrators should continuously monitor report requests, measure how quickly and efficiently the cache server

services these requests, and detect deficiencies in cache usage/performance (if any). This is exactly what the

Dashboards Cache Server Performance test does. This test reports how well the Database Cache Server is utilized

and how quickly it processes requests. In the process, the test points to poor cache usage and processing

bottlenecks, and also reveals if it is because the server is badly sized.

Purpose

Reports how well the Database Cache Server is utilized and how quickly it processes requests.

In the process, the test points to poor cache usage and processing bottlenecks, and also reveals

if it is because the server is badly sized.

Target of the

test

A SAP BOBI node

Agent

deploying the

test

An internal/remote agent

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

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 - Enter the port to which the specified HOST listens. This should be the port at

which the web application server hosting SAP BOBI listens.

4. JMX REMOTE PORT - Specify the RMI port number of the BOBI monitoring application.

To know the RMI port number of the monitoring application, refer to Section 1.1.1 of this

document.

5. JNDI NAME - Specify the lookup name for connecting to the JMX connector of the BOBI

monitoring application. To know the JNDI name, refer to Section 1.1.1 of this document.

6. JMX USER and JMX PASSWORD – Enter the credentials of an enterprise authenticated

BOBI user belonging to the default

monitoring users

group.

7. CONFIRM PASSWORD - Confirm the password by retyping it here.

8. NODE NAME – Specify the name of the BOBI node being monitored.

Outputs of the

test

One set of results for the Database Cache Server in the node monitored

Measurements

made by the

test

Measurement

Unit

Interpretation

Cache hit rate:

Indicates the percentage of

requests, over the last 500

requests, that have been

served with cached data.

Percent

A value over 80% is ideal. A value less than

50% is a cause for concern, as it indicates

that a vast majority of requests for reports is

not served by the cache server. This

increases database accesses and related

overheads, and hence, should be avoided.

Requests served rate:

Indicates the rate at which

the server serviced requests.

Requests/Sec

A low value or a steady drop in the value of

this measure is indicative of a processing

bottleneck.

Average processing time:

Indicates the average time

taken by the server to

process a request.

Millisecs

A low value is desired for this measure. A

high value indicates that the server is taking

too much time to process requests. This

could be owing to a processing bottleneck

and warrants closer scrutiny.

Queued requests:

Indicates the number of

requests that are either

waiting for processing or are

being processed.

Number

A steady rise in the value of this measure is a

sign of a request queue that is growing. This

means that the server is unable to process

page requests as quickly as it receives them.

Current cache size:

Indicates the current size of

the cache.

A large cache size may be necessary if the

server needs to handle large numbers of

queries, or highly complex queries. You may

want to increase the cache size if the

Cache

hit rate, Requests served rate

, and

Average

processing time

measures exhibit disturbing

trends.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Open connections:

Indicates the number of

connections open between

the server and its clients.

Number

Data transfer rate:

Indicates the rate at which

data is transferred from the

server to its clients.

KB/Sec

Current number of

auditing events queued:

Indicates the number of

auditing events that this

server has recorded, but

which have not yet been

retrieved by the CMS Auditor.

Number

If this number increases without bound, it

could mean indicate that auditing has not

been configured properly or that the system

is heavily loaded and generating auditing

events faster than the auditor can retrieve

them. When stopping servers, it is advisable

to disable them first and wait for auditing

events to be fully retrieved and this queue

becomes empty. Otherwise, they may be

retrieved only when this server has been

restarted and the CMS polls for them.

1.2.3 File Repository Server Status Test

The File Repository server is responsible for the creation of file system objects, such as exported reports, and

imported files in non-native formats. An Input FRS stores report and program objects that have been published to

the system by administrators or end users. An Output FRS stores all of the report instances generated by the Job

Server. In the absence of the File Repository server, these file system objects cannot be stored, resulting in

significant loss of reports and program objects. If this loss is to be prevented, then administrators will have to make

sure that the File Repository server is always available and is processing requests speedily. To ascertain this,

administrators can use the File Repository Server Status test. At configured intervals, this test verifies the overall

health, current state, and thread pool usage of the File Repository server, and captures potential performance

aberrations well before they occur. This way, the test red flags future anomalies and enables administrators to

prevent them from occurring.

Purpose

Verifies the overall health, current state, and thread pool usage of the File Repository server,

and captures potential performance aberrations well before they occur. This way, the test red

flags future anomalies and enables administrators to prevent them from occurring.

Target of the

test

A SAP BOBI node

Agent

deploying the

test

An internal/remote agent

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

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 - Enter the port to which the specified HOST listens. This should be the port at

which the web application server hosting SAP BOBI listens.

4. JMX REMOTE PORT - Specify the RMI port number of the BOBI monitoring application.

To know the RMI port number of the monitoring application, refer to Section 1.1.1 of this

document.

5. JNDI NAME - Specify the lookup name for connecting to the JMX connector of the BOBI

monitoring application. To know the JNDI name, refer to Section 1.1.1 of this document.

6. JMX USER and JMX PASSWORD – Enter the credentials of an enterprise authenticated

BOBI user belonging to the default

monitoring users

group.

7. CONFIRM PASSWORD - Confirm the password by retyping it here.

8. NODE NAME – Specify the name of the BOBI node being monitored.

Outputs of the

test

One set of results for the File Repository server running in the node monitored

Measurements

made by the

test

Measurement

Unit

Interpretation

Health state:

Indicates the current health

state of the File Repository

server in the monitored node.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

Danger

Caution

Healthy

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

the health state of the server. In the graph of

this measure however, the same is

represented using the numeric values only.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Server running state:

Indicates the current running

state of the File Repository

server.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

STOPPED

STARTING

INITIALIZING

RUNNING

STOPPING

FAILED

RUNNING_WITH_E

RRORS

RUNNING_WITH_W

ARNINGS

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

the running state of the server. In the graph

of this measure however, the same is

represented using the numeric values only.

Server enabled state:

Indicates whether/not the File

Repository server is enabled.

The values that this measure can report and

their corresponding numeric values are

discussed in the table below:

Measure Value

Numeric Value

Disabled

Enabled

Note:

By default, this measure reports the Measure

Values listed in the table above to indicate

whether/not the server is enabled. In the

graph of this measure however, the same is

represented using the numeric values only.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Busy server threads:

Indicates the number of

server threads that are

currently servicing requests.

Number

If this measure reaches the configured

maximum thread pool size for the server,

new requests to the server would have to

wait until a server thread becomes free. If

this happens often, it may significantly

slowdown request processing by the server.

In such a situation, you may want to consider

resizing the thread pool.

1.2.4 File Repository Server Performance Test

An Input File Repository server that is sized right and is capable of processing I/O requests quickly can alone enable

users to rapidly generate new reports using the published report and program objects stored in the server. Likewise,

if the Output File Repository server does not have enough space or is incapable of processing I/O requests rapidly, it

cannot hold or serve completed documents for users. This is why, it would be good practice to keep an eye on the

disk space usage and I/O activity on the Input and Output File Repository servers. The File Repository Server

Performance test helps administrators do just that. This test monitors I/O requests to Input and Output File

Repository servers and measures how well these servers handle these requests. In the process, the test indicates

whether/not the servers are experiencing any processing bottlenecks. Additionally, the test monitors the disk space

usage of the servers and proactively alerts administrators to a potential space crunch (if any) on the servers.

Purpose

Monitors I/O requests to Input and Output File Repository servers and measures how well these

servers handle these requests. In the process, the test indicates whether/not the servers are

experiencing any processing bottlenecks. Additionally, the test monitors the disk space usage of

the servers and proactively alerts administrators to a potential space crunch (if any) on the

servers.

Target of the

test

A SAP BOBI node

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. PORT - Enter the port to which the specified HOST listens. This should be the port at

which the web application server hosting SAP BOBI listens.

4. JMX REMOTE PORT - Specify the RMI port number of the BOBI monitoring application.

To know the RMI port number of the monitoring application, refer to Section 1.1.1 of this

document.

5. JNDI NAME - Specify the lookup name for connecting to the JMX connector of the BOBI

monitoring application. To know the JNDI name, refer to Section 1.1.1 of this document.

6. JMX USER and JMX PASSWORD – Enter the credentials of an enterprise authenticated

BOBI user belonging to the default

monitoring users

group.

7. CONFIRM PASSWORD - Confirm the password by retyping it here.

8. NODE NAME – Specify the name of the BOBI node being monitored.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Outputs of the

test

One set of results for the Input and Output File Repository servers in the node monitored

Measurements

made by the

test

Measurement

Unit

Interpretation

Active connections :

Indicates the number of

active connections from

clients to this server.

Number

This is a good indicator of the load on the

server.

Open files:

Indicates the number of files

that are currently being

accessed in this server.

Number

Data write rate:

Indicates the rate at which

data is written to this server.

MB/Sec

A consistent drop in the value of this measure

could indicate a drop in load or a processing

bottleneck.

Data read rate:

Indicates the rate at which

data is read from this server.

MB/Sec

A consistent drop in the value of this measure

could indicate a drop in load or a processing

bottleneck.

Free disk size:

Indicates the free space on

the disk containing the

server’s executable file.

A high value is desired for this measure.

Free disk:

Indicates the percentage of

free space on the disk

containing the server’s

executable file.

Percent

A steady decrease in the value of this

measure indicates that disk space on the

server is getting depleted. This is a cause for

concern.

1.3 The BOBI Processing Layer

Using the tests mapped to this layer, administrators can receive real-time updates on the current status of critical

servers running in the monitored node, receive an overview of the load and performance of these servers, and

proactively detect bottlenecks in processing in a server.

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

Figure 1. 9: The tests mapped to the BOBI Processing layer

1.3.1 Adaptive Job Server Status Test

The Adaptive Job Server is a “generic” server that processes Scheduled requests for different Object types. If this

server stops suddenly, encounters critical errors, or slows down unexpectedly, scheduled requests will no longer be

processed promptly, affecting the operations of the different object types. To avert such unpleasant eventualities,

administrators must detect problems with the availability, overall health, running state, and server size of the

Adaptive Job server well before end-users notice and complain. For this purpose, administrators can periodically run

the Adaptive Job Server Status test. This test keeps an eye on the current health and status of the Adaptive Job

server and alerts administrators at the first sign of an abnormality. In addition, the test also reports the count of

M O N I T O RI N G S A P B U S I N E S S O BJ E C T S

threads currently in use, thus providing administrators with early pointers to a potential processing bottleneck on the

server.

Purpose

Keeps an eye on the current health and status of the Adaptive Job server and alerts

administrators at the first sign of an abnormality. In addition, the test also reports the count of

threads currently in use, thus providing administrators with early pointers to a potential

processing bottleneck on the server.