SAP Business Objects XI

4.0

version 1.0, 29.05.2012

Lukas Hatala

HPS Global Delivery IT Operations

Enterprise Application Operations (EAO) / SAP
© 2004 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
Table of Content

• Overview
• Architecture
• Managment and Configuration
• Backup/Restore
• Monitoring
• Q&A

04/23/24 2
Introduction

© 2004 Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without notice
Overview

BusinessObjects Enterprise XI 4.0 is a flexible, scalable,

and reliable solution for delivering powerful, interactive
reports to end users via any web application—intranet,
extranet, Internet or corporate portal. SAP BusinessObjects
consist from many components, for component overview
check:
http://eaowiki.gre.omc.hp.com/doku.php?id=sap:bo:bo

04/23/24 4
Architecture
SAP BO consists of 4 tiers:
Client tier (client applications on end user desktop) not supported by HP basis team
Web tier (Web server) supported by HP basis team
Application tier (BO Services and processes) supported by HP basis team
Database tier (CMS Database) supported by HP basis team

System
anageent XI

04/23/24 5
Web tier
Web tier is represented by web server with deployed BO web applications and web services such session
authentication, user privilege management, scheduling, search... There are many of supported web servers but
we are mainly using bundled Tomcat webserver. It is represented on OS like separate service:

Tomcat is independent on running BO system. Restart of Tomcat is not affecting BO processes but all
users connected via Tomcat will be disconnected. Logs for Tomcat can be found in I:\Program Files
(x86)\SAP BusinessObjects\Tomcat6\logs

04/23/24 6
Application tier

Application tier representing core of SAP BO Technology and it consist of:

BO nodes: A BO node is one BO installation on server. There can be multiple BO nodes

on the same server or more nodes on more servers.

BO servers:This are the main processes running WITHIN the BO installation.

(sometimes called daemons). They are
processing all BO calls.
They are communicating with CMS and with each other.

BO service: Are applications assigned to BO server. BO services are providing

final application functionality and they are usually distributed
across more BO servers.

BO cluster: It is logical CMS cluster configured between BO nodes on one or

more servers. BO cluster is ballancing load automatically between
BO nodes inside of cluster. One distributed BO deployment can
consist of more BO clusters.

Logical structure is that an physical server hosting one or more BO nodes. BO node consist of
CMS server and other servers which are processing user requests. The BO nodes are bulding a
logical BO cluster.

04/23/24 7
Database tier

Database tier consist of database which is keeping track of all BO servers and statuses of
running/finished tasks, informations about users and permisions... In BO database are not stored
physical data (Data are stored in datasources defined in universes, FRS or BW database). Once
CMS (system database) database is not available for one of CMS servers the CMS server will be
switched into “Waiting for resources“ state and all operations which needs database access will
be forwarded into another CMS server inside of BO cluster. CMS server in “Waiting for
resources“ state is still able to serve users for operations where DB access is not required. Once
CMS Database is down BO is unable to start because of informantions about BO nodes, BO
servers and BO services distribution are stored in CMS database (so in general no DB no FUN).

From SAP BO perspective there “should“ be one or more databases. We have to decide durring
planning phase if CMS and Auditing tables will remain in one database, but there is strongly
recommended to split CMS and ADS database into two separate databases.

ADS databse is auditing database what is used for recording of auditing events (recording
defined user activity on system) and can grow to many hundreds GB sizes.

04/23/24 8
Administration and management

We are using to main tools for BO administration CMC and CCM.

CCM (central configuration manager) is used for service starting and stopping and for Deep
technical support tasks.

CMC (central management console) is web tool used for daily administration and application
setup.

04/23/24 9
Stop/Start/Check introduction

In order to understand start/stop/check process we need to understand first what is managing

what.
Server Inteligence Agent is managing BO node OS processes from OS point of view (In case
of any unpredicted issue or unresponsivity will restart them on OS level).
CMS server is managing BO servers inside of BO node in application logic way it monitoring
BO servers and BO services statuses and taking care about their startup.

04/23/24 10
Start/Stop/Check whole BO instance

I case of restart whole BO instance I would like to recommend following sequence :

Stopping order:
Apache Tomcat service
Server Intelligence Agent service
Database

Starting order:
Database
Server Intelligence Agent service
Apache Tomcat service

Check: After restart agent have to logon into http://<server>:8080/BOE/CMC than navigate into
Servers -> Server List and check if all servers are running and enabled.

04/23/24 11
Start/Stop/Check BO server/service

In case of incomplete restart requested. There is possible to restart Apache Tomcat service
without restarting of SIA service (especially after configuration on web server). In case of restart
SIA I would like recommend to restart Apache Tomcat service too.

In case of ticket from monitoring or customer call complaining about unavailable services.
Please restart BO server where are issues reported via CMC by using “Stop Server“ and “Start
Server“ available after right click or in action bar on CMC servers screen. In case of server can
not be stopped or remain in stopping status for longer than 5 minutes you can exceptionaly use
“Force Termination“. Please do not use “Restart Server“.

Check: for this “Small“ or “Incomplete“ restarts is enough to see restarted server running in
CMC servers screen.

04/23/24 12
Check & Troubleshooting

In case of logon page for CMC page can not be displayed check Apache Tomcat service and
Apache logs in: I:\Program Files (x86)\SAP BusinessObjects\Tomcat6\logs
In case that logon into CMC is not working check if SIA service is running and logs in:
I:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\logging
and Windows Event Viewer.
Additionally you have to check statuses of BO servers via CCM: By clicking on and
providing logon details. You will be able to see and manage BO servers.

If connection into BO is not working via CCM check database state, connection, logs and you
can proceed with complete restart of system (alternatively complete server restart).

04/23/24 13
Check & Troubleshooting

BO servers can have following statuses:

Stopped: server were stoped and is not running (not running as OS process)
Starting: server receieved startup command is initializated and now is starting services.
Initializing: server received start command as is loading Java programs into RAM.
Running: server is started and running .
Stopping: sever receieved stop command and perfoming stop operation.
Started with Errors: server started but it has errors in configuration.
Failed: Server were stopped due to unpredicted conditions.
Waiting for resources: Mostly happens on CMS when connection into DB were interupted and
CMS server is waiting for DB resource.
--------------------------------------------------------------------------------------------------
Enabled: Server is accepting user requests.
Disabled: Server is not accepting user requests.

If Server have to be fully operational it must be in Running and Enabled state.

04/23/24 14
Backup/Restore data overview

We have to backup 3 main locations:

CMS Database – The database containing information's about inside BO configuration
(Reports, Server distribution, permissions, users,…)
File store (FRS) – Files tore location should be placed on shared drive accessible by all BO
nodes it is depot where are physical files located and indexed.
BO binaries – The file system where were BO installed. It contains BO binaries, BO
configuration files, Web server configuration files…

In deployments were ADS tables are stored in different database backup of ADS database is
recommended. Because of SAP BO Technology consist from many components there is always
good idea to refer administration guide for specific product.

04/23/24 15
Backup/Restore introduction

In order to be able provide backup restore supportability we need to backup all BO filesystems
and Database in very small time differences. The source what have to backed up are:
CMS Database – standard DB online backup and redolog backup.
FRS (filestore input/output) – standard FS backup
BO binaries – standard FS backup
The goal is to have all resources synchronized. To be able achive that we have to run RDT after
restore (Report Diagnostinc tool). RDT scaning CMS database InfoObjects and repairing
inconsistencies between CMS <-> FRS and between InfoObjects <-> infoObjects metedata
inside of CMS as well. I would like to recommend to run RDT after restore with stopped BO,
otherwise inconsistencies caused by running system after restore remains undetected. For more
informations about RDT please refer to:
http://help.sap.com/businessobject/product_guides/boexir4/en/
xi4_bip_repository_diagnostic_tool_en.pdf

Due to necessary synchronization of CMS DB and FRS schedule backup in as same time as
possible.

04/23/24 16
Monitoring

We have this monitoring solutions in place nowdays:

•Service monitoring via srv_mon

•Process monitoring via ps_mon
•Disk space monitoring via df_mon
•Availability monitoring via R3status

Services expected to be running are usually set like automatic and monitored by srv_mon.

04/23/24 17
BO R3status monitoring

Availability monitoring via R3status is performed with URL extension with cooperation of
deployed monitoring application in Apache Tomcat. For more informations about configuration
please refer to:
http://teams2.sharepoint.hp.com/teams/sapstandards/Technical_Documentation/Monitoring/SAP
_R3Status/BO_monitoring_with_r3status/
R3status URL monitoring solution is based on checking monitoring application generated web
page. If everything is ok ##Result: Check OK appears and UP entry is written into R3status log.
If check failed name of failed service appears in ## Result: row.
Page example:

04/23/24 18
Summary and Questions

Q&A