Boe330 en Col17

BOE330
SAP BusinessObjects Business

Intelligence Platform: Designing
and Deploying a Solution
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 17
Course Duration: 5 Day(s)
Material Number: 50157327
SAP Copyrights, Trademarks and
Disclaimers
© 2022 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any
purpose without the express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an SAP
affiliate company) in Germany and other countries. Please see https://
www.sap.com/corporate/en/legal/copyright.html for additional trademark
information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary
software components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical
errors or inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind, and SAP
SE or its affiliated companies shall not be liable for errors or omissions with respect
to the materials. The only warranties for SAP SE or SAP affiliate company products
and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be
construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any
course of business outlined in this document or any related presentation, or to
develop or release any functionality mentioned therein. This document, or any related
presentation, and SAP SE’s or its affiliated companies’ strategy and possible future
developments, products, and/or platform directions and functionality are all subject
to change and may be changed by SAP SE or its affiliated companies at any time for
any reason without notice. The information in this document is not a commitment,
promise, or legal obligation to deliver any material, code, or functionality. All forward-
looking statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned not to
place undue reliance on these forward-looking statements, which speak only as of
their dates, and they should not be relied upon in making purchasing decisions.
Typographic Conventions
American English is the standard used in this handbook.

The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
© Copyright. All rights reserved. iii

iv © Copyright. All rights reserved.
Contents
vii Course Overview
1 Unit 1: Reviewing Architecture, Administration, and Security in SAP

BusinessObjects BI Platform
3 Lesson: Describing the BI Platform Architecture, System, and

System Elements
29 Lesson: Identifying Key Architecture Flows
37 Lesson: Reviewing SAP BusinessObjects BI Platform Security
47 Lesson: SAP BusinessObjects 4.3 and SAP Analytics Cloud Hybrid
Solution
51 Lesson: SAP BusinessObjects BI Platform Support Tool
61 Unit 2: Identifying Requirements
63 Lesson: Assessing your Organization's Environment
67 Unit 3: Planning a Deployment
69 Lesson: Identifying Factors to Consider when Deploying a BI

Platform 4.3 System
73 Lesson: Identifying Factors that Influence the Deployment Process
77 Lesson: Identifying Factors to Consider when Installing SAP
BusinessObjects Platform 4.3
81 Lesson: Identifying Factors to Consider when Integrating SAP
Analytics Cloud
87 Lesson: Identifying Factors to Consider when Configuring a
Deployment
97 Unit 4: Deployment Design and Sizing
99 Lesson: Designing an SAP Business Intelligence Deployment

103 Lesson: Designing a Scalable System
109 Lesson: Preparing a Sizing of a BI Platform Deployment
159 Unit 5: Deployment and Configuration of an SAP Business Intelligence

Platform 4.3
161 Lesson: Planning a Deployment Solution

179 Lesson: Configuring the Web Tier for High Availability
187 Lesson: Configuring the Management Tier for High Availability
191 Lesson: Configuring the Storage Tier for High Availability
195 Lesson: Configuring the Processing Tier for High Availability
201 Lesson: BI Platform Pattern Books and Best Practices for
Deployment
207 Lesson: Administering Server Groups
© Copyright. All rights reserved. v

217 Unit 6: Content Management Planning
219 Lesson: Preparing to Manage Content

223 Lesson: Upgrading to SAP BusinessObjects 4.3
227 Lesson: Managing the Life Cycle of a Deployment
243 Lesson: Moving Objects from One Deployment to Another
251 Unit 7: Publications and Single Pass Report Bursting
253 Lesson: Designing Publications
265 Unit 8: Deployment Administration
267 Lesson: Performing Advanced Troubleshooting of a BI Platform

Deployment
285 Unit 9: Deployment Replication (Optional)
287 Lesson: Replicating a BI Platform Deployment
299 Unit 10: Disaster Recovery in the SAP Business Intelligence Platform 4.3
301 Lesson: Planning for Disaster Recovery
vi © Copyright. All rights reserved.

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● Systems Architect
© Copyright. All rights reserved. vii

viii © Copyright. All rights reserved.
UNIT 1 Reviewing Architecture,
Administration, and Security in
SAP BusinessObjects BI
Platform
Lesson 1
Describing the BI Platform Architecture, System, and System Elements 3
Lesson 2
Identifying Key Architecture Flows 29
Lesson 3
Reviewing SAP BusinessObjects BI Platform Security 37
Lesson 4
SAP BusinessObjects 4.3 and SAP Analytics Cloud Hybrid Solution 47
Lesson 5
SAP BusinessObjects BI Platform Support Tool 51
UNIT OBJECTIVES
● Describe the SAP strategic focus on BI

● Describe the BI suites
● Describe the BI platform system
● Describe the integration of the BI platform suite
● Describe key architecture flows
● Administer security
● Understand SAP BusinessObject 4.3 strategy and direction
● Understand how the SAP BusinessObject and SAC can be configured as a blended hybrid
(on-prem/cloud) solution
● Describe SAP BusinessObjects BI Platform Support Tool
© Copyright. All rights reserved. 1

Unit 1: Reviewing Architecture, Administration, and Security in SAP BusinessObjects BI Platform
2 © Copyright. All rights reserved.

Unit 1
Lesson 1
Describing the BI Platform Architecture,
System, and System Elements
LESSON OVERVIEW
This lesson describes the SAP BusinessObjects Business Intelligence (BI) platform
architecture, BI systems, and the elements contained within BI systems. It aslo describes key
benefits and features of the BI Suite.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP BusinessObjects Analytics Editions

The Challenges for Business Intelligence (BI)
Collecting data is no longer enough. For an organization to thrive, it needs to use data from
multiple sources to identify actions that will improve strategic, operational, and tactical
performance. Most businesses can benefit from access to real-time business insights and
predictive capabilities.

Figure 1: BI Challenges
Strategic Focus on BI
A solid BI strategy is critical to the consolidation of BI assets and effort across any company.
Major barriers to building a successful BI strategy include the following problems:
● IT is not aligned with the business strategy.
● The organization makes decisions about technology or architecture structures without
considering the business problems that the organization is trying to solve.
Figure 2: BI Suite

Lesson: Describing the BI Platform Architecture, System, and System Elements
Functions of the SAP BusinessObjects BI Suite Client Tools

The analytics editions of the SAP BusinessObjects BI suite include the BI suite client tools,
which provide the following functions:
● Data discovery
● Analysis
● Dashboards
● Reporting
● Visualization
● Predictive capabilities
● Delivery to mobile devices
The Evolution of BI
Figure 3: The Maturity of BI from Raw Data to Optimization
The use of business data has evolved significantly from simply gathering raw data, to more
complex efforts to use data for analysis and gaining business insights. Initially, business data
could only inform companies about what was happening with their businesses. As reporting
and user tools matured, organizations began to learn why certain activities occurred within
their businesses. More sophisticated analysis tools allowed organizations to determine what
would happen with the future of their businesses. As analytic capabilities in the tools became
more mature, organizations could predict what paths would be best for their business and
optimize reporting, analysis, and prediction to gain valuable insights into the operation of their
companies.

Advantages of the SAP Strategic Focus on BI

Above and beyond the traditional BI solutions for reporting, analysis, and dashboarding, SAP
also delivers instant mobile business intelligence, self-service data discovery, and predictive
analysis. Your organization can act on relevant insights, regardless of whether decision-
makers are at their desks or on the road. Your organization can react quickly to market
changes with immediate insights, and without depending on IT. This enables decision-makers
to pro-actively manage business opportunities and threats.
Benefits of a BI Strategy to the Organization

SAP BI solutions facilitate instant insight by using the following functions:
● Instant mobile BI
● Self-service data discovery
● Predictive analysis
Benefits of a BI Strategy to IT
Successful implementation of SAP BI solutions positively impact business users in the
following ways:
● IT can align itself with business partners and formal business needs.
● The IT organization can create prioritized roadmaps:
- Plan for short, medium, and long term projects
- Align with strategic business goals
- Deliver measurable results
● The IT organization can create business justifications for an enterprise-wide scope and an
end-to-end BI approach, including data management.
Benefits of a BI Strategy to the Line of Business

SAP BI solutions help improve inter-departmental collaboration in the following ways:
● Departmental spending achieves more and contributes to the investments of the

organization.
● Departments can share business intelligence data and work towards achieving an
enterprise-wide strategy.
● Using enterprise-wide BI, departments use a unified approach and communicate with each
other using the same terms and concepts.
Facilitated Discussion: Advantages of the SAP Strategic Focus on BI

Describe the advantages of the SAP strategic focus on BI. How does the BI strategy benefit an
organization? How does it specifically benefit the IT department? How can lines of business
benefit from a BI strategy? Can you identify specific, tangible benefits that your organization
has realized by implementing a BI strategy?

BI Suites on the BI Platform

SAP BusinessObjects BI solutions support all the information access, interaction, and
analysis needs of the different business users across the organization. By meeting the needs
of nearly every role and every individual, businesses can gain smarter and better aligned
individuals, teams, and ecosystems.
SAP BusinessObjects BI solutions enable organizations to take advantage of decades of
know-how, industry-leading expertise, and BI best practices developed through close
collaboration and development with industry leaders and partners.
Figure 4: BI Platform
Leveraging the Cloud for SAP BusinessObjects Business Intelligence Platform

SAP Cloud Strategy: Business Intelligence Solutions
Enterprise BI with SAP BI 4

Your organization gains agility, efficiency, and cost savings by using enterprise-grade BI
in the cloud or in hybrid on-premise environments. Users can work at their own pace
without sacrificing functionality, agility, or support.
Analytic Applications on SAP HANA
The analytic applications on SAP HANA allow your organization to choose any cloud
model to create innovative applications, or to extend SAP solutions with the existing
standard analytics platform for partners and customers.

Figure 5: SAP BusinessObjects BI 4 for Cloud Deployments
SAP BusinessObjects BI 4 for Cloud Deployment Options

SAP BusinessObjects BI 4 for cloud deployments provide a variety of options to suit every
hosting need:
● SAP HANA Enterprise Cloud

SAP HANA Enterprise Cloud is a managed cloud environment for SAP HANA, BW on
HANA, Suite-on-HANA, and SAP BI 4.
● SAP Hosting Partners
Third-party managed hosting partners have SAP BI 4 experience, so you can run faster,
simpler, and smarter than ever before.
● Amazon Web Services
Your organization can deploy SAP BI 4 on Amazon’s public cloud infrastructure for
productive and non-productive purposes without the up-front infrastructure costs.
● Microsoft Azure
Microsoft Azure offers a wide range of services including compute, storage, networking,
and many others for businesses to build their applications without lengthy procurement
cycles. Azure virtual machines (VM) help companies to deploy on-demand and scalable
computing resources for SAP BusinessObjects BI Platform.
● Google Cloud
The SAP BusinessObjects product team performed a standard certification activity to
ensure that the Business Intelligence platform and its key clients/add-ons are successfully
deployed and work as expected on Google’s Compute Engine.

BI Platform System Overview
Figure 6: One Suite for All Insight
The SAP customer base has three core sets of BI client requirements: Agile Visualization,
Dashboards and Applications, and Reporting.
Within each of these requirement areas, SAP has products designed to meet the specific
needs of its large and diverse customer base.
Discovery, Prediction, and Creation

The following are possible with SAP products:
● Discover areas to optimize your business.

● Adapt data to business needs.
● Tell your story with visualizations.
Engaging Experiences
● Deliver engaging information to users where they need it.

● Track key performance indicators and summary data.
● Build customer experiences so users get what they need quickly.
Information Distribution
● Securely distribute information across your organization.

● Answer related questions by interacting with predefined reports.
● Build printable reports for operational efficiency.

Solution Areas
The following solution areas are covered:
Discovery
This area is focused on analysts and users within lines of business and departments. This
category allows users to acquire, cleanse, and visualize data with minimal end user
training. The interfaces have limited layout capabilities, but include powerful faceted
exploration and navigation. Solutions in this category are a great fit for in-memory data
source, such as SAP HANA, allowing users to go anywhere in the data.
Analysis
Workflows are the main focus of solutions in this category, but some layout is available.
They are designed to take advantage of modeled multi-dimensional sources (SAP HANA
and SAP BW) and data in Microsoft SQL Server Analysis Services. Solutions in this
category are designed from the ground up as OLAP clients, and are the best solution for
projects with demanding hierarchical navigation requirements.
Dashboards
The dashboards category focuses on the needs of IT and developers to create and deploy
interactive, visual dashboards. Unlike discovery and analysis, the dashboards are
typically built for others to consume using highly visual layout tools.
Reporting
Both SAP Crystal Report and Web Intelligence are focused on the mass distribution of
formatted data, with the primary difference being the report design experience. SAP
Crystal Reports use a desktop-based report designer, while the primary Webi design
experience is over the web. Both solutions allow for scheduled reports or on-demand
reporting.
Predictive
The solutions in this category include SAP Analytics Cloud (SAC).
BI Platform Terms
The following terms refer to the types of software running on a BI platform:
Server
This operating system level process (other systems use a daemon) hosts one or more
services. A server runs under a specific operating system account and has its own
process ID (PID).
Examples of a server include Central Management Server (CMS) and Adaptive
Processing Server.
Service
This server subsystem performs a specific function. The service runs within the memory
space of its server under the PID of the parent server.
Examples of a service include the Web Intelligence Scheduling Service, which is a
subsystem that runs within the Adaptive Job Server.
Node
This 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.
Installation Approaches
The BI platform can be installed in various ways:

● On a single computer
● Spread across different computers on an intranet
● Separated over a wide-area network (WAN)
BI Platform Tiers
The BI platform is composed of the following tiers, which are optimized for specific tasks and
operations:
● Client Tier: Web browser and rich clients

● Application Tier: Web application servers and tools
● Intelligence Tier: System server processes
● Processing Tier: Data analysis and report generation
● Data Tier: Reporting databases
Deployment Approaches
The BI platform can be deployed in various ways:
● Single-server deployment
● Multi-server distribution deployment
● Scaling up and/or scaling out
● High-availability deployment
Figure 7: Multi-Server Distribution Deployment

This figure illustrates a highly available SAP BusinessObjects 4.3 deployment with system/
auditing databases and the storage tier as a network share.
Network Considerations for SAP BusinessObjects BI Platform

Key Networking Metrics Relevant to SAP BusinessObjects BI Platform
Network latency
This is the time a packet takes to make a round-trip between two networked hosts.
Network bandwidth
This measures the amount of data that can be sent from point A to point B in a certain
amount of seconds.
Network latency is the time a packet takes to make a round-trip between two networked
hosts. The packet must arrive at its destination and return back to the originating client.
Network bandwidth measures the amount of data that can be sent from point A to point B in a
certain amount of seconds. Effectively, bandwidth is the real amount of data from point to
point, not the theoretical speed listed “on the box.” Real measurements are taken by sending
a known size of data across and measuring the time it takes for all of it to arrive. Relying only
on NIC card and router specifications is likely to result in imprecise and higher than effective
measurements of bandwidth. Those specifications indicate the maximum bandwidth that
appliance might achieve. Measuring bandwidth across shared connections and network
infrastructure will generally result in a substantially smaller number.
Network Latency Measurement

A ping command sends one of the following ICMP echo requests to a destination and waits for
the echo response:
● 32–byte echo request (Windows)

● 64–byte echo request (*nix)
Figure 8: Network Latency Echo Request Using Ping
Alternative Network Latency Measurements

● A traceroute/tracert command pings each router and/or hop on the way to the
destination, and helps with mapping networks.

Figure 9: Network Latency Echo Request Using Traceroute/Tracert
Network Bandwidth Measurement Tools

The following tools can be used to measure network bandwidth:
● Ttcp
● Iperf
● Bwping
● Netperf
Note:
While ping is generally available, network engineer support is typically required to
test bandwidth. Running tools like netperf without permission is likely to raise
alarms.
Types of Network Connections

The following types of network connections are possible:
● HTTP(S) requests
● Reporting Database requests
● CMS database requests, and system and API calls

Note:
Each network connection type is impacted differently by network latency and
bandwidth limitations. The nature of network request types will determine the
deployment options. By understanding the request types, you will be better
prepared to choose among deployment options.
HTTP(S) Requests
These requests are usually long, cover a large distance, and are few per user:
● Browser request to BI Launchpad

● HTML, SML, image files, JavaScript files, CSS files
● Query panel communication
● SAP BusinessObjects Dashboards with QaaWS or other Web services
● SAP BusinessObjects Mobile
The Nature of HTTP(S) Requests

The following are considerations when discussing the nature of HTTP(S) requests:
● A single request results in a number of processes in the back end, such as logon, report
open, or refresh requests.
● An HTML response can be a frameset, which pulls in additional HTML pages.
● The HTML pages themselves can pull in images, JavaScript files, Query Panel, and other
objects.
● Images, JavaScript files, and others objects that have been cached will not download
again, but a timestamp check is performed to determine if the files are unchanged.
Clearing the browser cache forces a download.
Considerations When Using Simultaneous Connections

The following are considerations when using simultaneous connections:
● Using many simultaneous connections reduces latency but increases bandwidth concerns.
● Each browser allows a different number of simultaneous connections:
Report Database Requests

These requests are usually long, cover a short to medium distance, only occur on a report
refresh, and typically come form the BI servers:
● Relational data sources (Oracle, DB2, SQL Server, and others)

● SAP BW MDX connections
The Nature of Report Database Requests

The following are considerations when discussing the nature of report database requests:

● A single request for a dataset retrieves multiple rows of data.

● The query response is expected to be received in seconds or within a few minutes.
● It is likely to be the largest volume of data, and it is received as a large single data stream.
● Longer queries are sensitive to time-outs, inappropriate disconnects, and retransmissions
of data packets.
● You should consider the legal ramifications of retrieving datasets across continents.
Legal Considerations for Retrieving Datasets Across Continents

The following are legal considerations when retrieving datasets across continents:
● EU Data Protection Act prohibits the exportation of data outside recognized safe data
havens.
● The US is not considered a safe data haven.
● Similar legal issues might be relevant in other parts of the world.
● Nevertheless, these issues are widely ignored.
CMS Database Requests and System and API Calls

These requests are very short, frequent, and continuous. They cover a short distance and
come from the following sources:
● CMS database requests

● BI system calls
● API calls from BI Launchpad or Java or .Net APIs to BI platform (CMS)
The Nature of CMS Database Requests and System and API Calls
The following are considerations when discussing the nature of CMS database requests and
system and API calls:
● Many of these requests and calls occur, and they occur frequently.
● They are short in duration—usually counted in milliseconds and less than one second.
● One HTTP request, such as logon, open report, refresh report, and others, can generate
multiple system and API calls.
● However, the exception is a request to retrieve documents from FRS, which is more
bandwidth-bound than latency-bound.
Centralization versus Decentralization

It is recommended that you not decentralize CMS services or Application Servers.
● The network would be impacted more by multiple and frequent requests than an HTTP(S)
request over distance.
● You might obtain a slight, barely noticeable gain on web requests, but it would be
insignificant compared to the costs incurred.
● CMS services ping other CMSs and BI platform services continuously.

● Decentralizing will slow the entire system down for everybody.

● Decentralization of Processing Servers could make sense in certain deployment scenarios.
Agile Visualization
Agile Visualization Functions and Components
The following are functions and components of agile visualization:
● Agile visualization helps the user discover, predict, and create:

- Discover trends, outliers, and areas of interest in your organization.
- Adapt to business scenarios by combining, manipulating, and enriching data.
- Communicate with self-service visualizations and analytics.
- Forecast and predict future outcomes.
● The agile visualization portfolio comprises the following products:
- SAP BusinessObjects Lumira Designer
- SAP BusinessObjects Analysis
- SAP Analytics Cloud (SAC)
Benefits of Agile Visualization

Business analysts and business users benefit in the following ways:
● Using SAP BusinessObjects Lumira Designer, they can quickly massage, transform, and
personalize data without scripting.
● They can access the tools everywhere using mobile, web-based, and desktop access, both
online and offline.
● They receive the best SAP BW support with Analysis.
SAP BusinessObjects Lumira Discovery
Note:
SAP BusinessObjects Lumira Discovery will be deprecated in 2024. Its
replacement will be SAC Analytics Cloud. Please plan accordingly.
SAP BusinessObjects Lumira Discovery helps you understand your organization’s data,
personalize it, and create beautiful content:
● Quick download and installation on desktop (less than 5 minutes).

● Insight provided from many data sources.
● Business scenarios supported by combined, manipulated, and enriched data.
● Self-service visualizations and analytics.
● Optimization for SAP HANA for real-time use of detailed data.

SAP BusinessObjects Lumira Discovery provides agile visualizations that support real-time
understanding of data, both big and small. Users can combine their own desktop data with
other information, then share the outcomes with colleagues. Flexible, self-service cloud
solutions like SAP BusinessObjbects Lumira help your organization leave rigid spreadsheets
behind, generate insights on the go, and visually present a data-driven story.
SAP BusinessObjects Lumira Discovery fully integrates with the SAP core enterprise BI
platform, the SAP BusinessObjects Business Intelligence suite, to ensure true data
governance and facilitate collective insight.
SAP BusinessObjects Analysis for OLAP

SAP BusinessObjects Analysis allows business analysts to analyze OLAP data in Microsoft
Excel and over the web.
● Recommended solution for OLAP analysis scenarios (multi-dimensional analysis).

● Quick leveraging of existing SAP investments with support for SAP BW and SAP HANA.
● High productivity for analysts using web-based and Microsoft Excel-based interfaces.
● Premium alternative for SAP Business Explorer (BEx) customers.
Dashboards and Applications

Functions and Components of Dashboards and Applications
The following are functions and components of dashboards and applications:
● Dashboards and applications build engaging experiences:

- Use a powerful environment to build interactive and visually appealing analytics.
- Navigate and innovate with a rich set of controls, such as buttons, list boxes, menus,
tabs, and charts.
- Use custom code to extend and build workflows.
● Portfolio comprises the following:
- SAP Lumira Designer NOTE: SAP SAP Lumira Designer will only be supported until
2024. The Dashboarding solution going forward will be SAP Analytics Cloud (SAC).
Please plan accordingly

Figure 10: SAP BusinessObjects Dashboards User Alignment
SAP Lumira Designer

SAP Lumira Designer provides a development environment that contains a broad library of
controls and visualization to build analytic applications on SAP BW and SAP HANA:
● Modern development environment and HTML5 runtime

● Native SAP BW and SAP HANA support
● Growing library of controls
● Recommended solution for SAP BW customers (especially those with SAP BEx WAD
investments)
Reporting in the BI Platform

Functions and Components of Reporting
● Reporting features allow users to design, distribute, and share information:

- High productivity for report designer to create custom applications, enhanced with
embedded reports.
- Quick construction of formatted reports on any data source.
- Secure distribution of reports, both internally and externally.
- Lower IT support costs because empowered end users can easily create and modify
their own reports.
● Portfolio comprises the following:
- SAP BusinessObjects Web Intelligence
- SAP Crystal Reports
Reporting features include the following:

● Self-service ad-hoc reporting with SAP BusinessObjects Web Intelligence.

● Depth of SAP Crystal Reports SDK and ability to embed SAP Crystal Reports.
● Ability to access the tools everywhere using mobile, web-based, and desktop access, both
online and offline.
SAP BusinessObject Web Intelligence

SAP BusinessObject Web Intelligence lets users perform self-service queries and reporting:
● Quick construction of ad-hoc queries and reports, without knowledge of SQL or underlying
data structures.
● Market-leading self-service reporting solution for rapid report creation.
● Support for a multi-source, semantic layer to bring together different source of
information.
● Ability to access the tools everywhere using mobile, web-based, and desktop access, both
online and offline.
SAP Crystal Reports

SAP Crystal Reports allows users to build pixel-perfect formatted reports for printing and
operational reporting:
● Direct access to nearly any data source.

● Construction of reports that look professional, using pixel-perfect positioning, layout, and
templates.
● Powerful API used to embed reports into applications.
● Optimization for high-volume reporting and publishing.
Universe Semantic Layer

Semantic Layer Elements
The semantic layer is an abstraction layer between the database and the business user. It
encompasses the following elements:
● Universes
● Query generation
● Calculator
● Local cache (a microcube)
● Query panel
● Database connectivity parameters
The semantic layer frees the business user from the complexity of the data structures and
technical names. It enables business users to access, interact, and analyze their data
regardless of the underlying data sources and schemas.

Metadata Objects Within a Universe
● A universe allows business users to analyze and report on corporate data in a non-
technical language. It is a collection of the following metadata objects:
- Dimensions
- Measures
- Hierarchies
- Attributes
- Pre-defined calculations
- Functions
- Queries
● There are two types of universes: multi-source-enabled relational universes and
dimensional universes.
The information design tool is an SAP BusinessObjects metadata design environment that
enables a designer to extract, define, and manipulate metadata from relational and OLAP
sources to create and deploy SAP BusinessObjects universes. The objects in the universe
form the metadata object layer (the business layer), which is built on a relational database
schema or an OLAP cube. The objects map directly to the database structures via SQL or
MDX expressions. A universe includes connections identifying the data sources so queries
can be run on the data. The role of the universe is to provide the business user with
semantically understandable business objects, such as, Customer, Country, Quarter,
Revenue, or Margin. The user is then free to analyze data and create reports using the
business objects that are relevant to their needs, without requiring knowledge of the
underlying data sources and structures.
Feature of Universes
● Access to all the major relational sources with multi-source enabled relational universes.
● Support for SAP NetWeaver Business Warehouse 7.0.1 and 7.3.
- With multi-source enabled relational universes.
- With direct access to BEx Queries (no universe).
● Support of OLAP sources: Microsoft Analysis Services 2005 and 2008 with dimensional
universes.
● General access capabilities via open database connectivity (ODBC).
Benefits of Universes
● Facilitated access to information that makes it easier to answer business questions.

● Increased range of information that business users can access.
● Reduced maintenance due to the use of one optimized source of data and metadata for
multiple reports.
● IT control of who can access the data, which fosters trust in the information.

Other BI Platform System Components

Benefits of Business Views
Business Views simplify report creation and interaction in the following ways:
● Business Views can only be used by SAP Crystal Reports.

● They are designed to simplify the data access and view-time security for SAP Crystal
Report creation.
● Complex data is abstracted for report developers.
● Data connection, data access, business elements, and access control are separated.
● Multiple data sources are combined into a single view.
● Business Views are fully supported in the BI platform.
Differences Among the Tools

Within the suite of tools, various differences occur as follows:
● How tools access data

● Where data resides
● Where the content is used
● Where the content is created
● Who uses the content
Overview of the BI Platform Suite

Features of the BI Platform Suite
The BI platform is a flexible, scalable, and reliable solution for delivering powerful, interactive
reports to end users via any web applications, whether they run from the intranet, extranet,
Internet, or corporate portal. The BI platform can be installed on a single machine, spread
across different machines on an intranet, or separated over a wide-area network (WAN).
Installation and Installables
● The BI 4.3 platform requires a 64–bit operating system.

● SAP BW reporting performance has been significantly improved with native BI Consumer
Services (BICS) drivers for SAP BW.
● Data Federator, Integration Kit, Life Cycle Management, and Upgrade Management tools
are installed as part of the platform services server component installation. No separate
installations are necessary.
● SAP BusinessObjects platform is installed with two distinct installers: (1) for the SAP
BusinessObjects platform server components and (2) for SAP BusinessObjects platform
client tool components.
● The SAP BusinessObjects BI platform web tier components and integration kits for third-
party systems are also part of the Server Installer.

● The SAP BusinessObjects BI 4.3 Client Installer can be used to deploy all of the client-side
components for the BI platform. This does not include SAP Crystal Reports or SAP Crystal
Reports Dashboard Design.
Server Components Installation

The following server components are installed:
● Platform Services
● Connection Services
● Data Federator Services
● SAP Crystal Report Services
● Web Intelligence Services
● Mobile Services
● Lifecycle Management
Third-Party Components Installation

The following third-party components can be installed:
● Subversion
● Tomcat 8.0/9.0
Client Tool Components Installation

The following client tool components can be installed:
● Web Intelligence Rich Client (WRC)

● Business View Manager (BVM)
● Universe Design Tool
● Information Design Tool
● Translation Manager
● Data Federation Administration Tool
● Developer components
● Database access and security

Figure 11: Integration of BI Platform with Existing Infrastructure
Client Tier Components for Integration
Figure 12: SAP BusinessObjects BI Platform 4.3 Architecture
SAP BusinessObjects Analysis for Microsoft Office

This plug-in integrates into Microsoft Excel and Microsoft PowerPoint to be used as an
OLAP tool. With access to OLAP data sources, users can combine information from
different systems within a single workspace.
SAP BusinessObjects Analysis for online analytical processing (OLAP)
This OLAP tool (formerly called Voyager) works with multidimensional data. With access
to OLAP data sources, users can combine information from different systems within a
single workspace.
SAP Crystal Reports for Enterprise
This Java-based report design tool is used to create and integrate powerful reports in the
BI platform.
Data Federation Administration Tool
This tool (formerly known as Data Federator) enables multi-source universes by
distributing queries across data sources and lets you federate data through a single data
foundation. Administrators use this tool to optimize data federation queries and fine-tune
the data federation query engine for the best possible performance.
Information Design Tool
This SAP BusinessObjects metadata design environment lets a designer extract, define,
and manipulate metadata from relational and OLAP sources to create and deploy UNX
universes.
Promotion Management Tool (PMT)
The Promotion Management Tool (PMT) provides centralized views to monitor the
progress of the entire lifecycle process. The PMT is used to move content from one BI
platform to another of the same version.
Repository Diagnostic Tool
This tool scans, diagnoses, and repairs inconsistencies that might occur between a CMS
system database and an FRS file store. It can also report the status of repairs and what
actions have been completed.
Translation Management Tool
This tool defines multilingual universes and manages translations of universes and their
Web Intelligence documents and prompts.
Data Tier Components for Integration
Monitoring Database
This embedded Java Derby database stores system configuration and component
information for SAP Supportability in the SAP BusinessObjects BI platform.
Universes (UNX)
UNX universes are identified by the .unx file extension. These universes are based on the
new semantic layer in the SAP BusinessObjects BI platform and are built using the new
Information Design Tool.
Processing Tier Components for Integration
Adaptive Job Server

This generic server processes scheduled jobs for a variety of object types. All the
scheduling services are hosted on this server.
Adaptive Processing Server

This generic server hosts services responsible for processing requests for a variety of
sources.
SAP Crystal Reports Processing Server
The server responds to page requests from SAP Crystal Reports for Enterprise by
processing reports and generating encapsulated page format (EPF) files. The server
retrieves data for the report from the latest instance or directly from the data source.
After it generates the report, it converts the data to one or more EPF files, which are then
sent to the SAP Crystal Reports Cache Server. The EPF format supports page-on-
demand access, so only the requested page is returned, not the entire report. System
performance is improved and unnecessary network traffic is reduced for large reports.
Dashboard Analytics Server
This server is used by BI workspaces to create and manage corporate and personal BI
workspace module content.
Storage, Management, and Web Tiers Components for Integration
Central Management Server

The Central Management Server (CMS) maintains a database of information about your
SAP BusinessObjects BI platform (in the CMS System Database) and audited user
actions. All platform services are managed by the CMS, which also controls access to
system files where documents are stored, including information on users, user groups,
security levels (including authentication and authorization), and content.
Web Applications
Web applications run in the Web Application Server to process requests for the Web
client. BI Suite Web applications include the following:
● Central Management Console (CMC)
● Lifecycle Management Console (LMC)
● BI Launch Pad
● BI Workspaces
● Web Intelligence
● SAP BusinessObjects Analysis for OLAP
Platform Tools and Features for Integration
Web interfaces
● Central Management Console (CMC)
● BI Launch Pad
Semantic Layer
● UNX
● Multi-source universes
Report Content Types

● SAP Crystal Reports
● Web Intelligence

Dashboards
Advanced Analysis – Web
Central Management Console for Integration
Figure 13: Central Management Console Home Page
The Central Management Console (CMC) is a Web-based tool, which offers a single interface
through which you can perform almost every day-to-day administrative task, including user
management, content management, and server management.

Figure 14: Central Management Console Servers Page
LESSON SUMMARY
You should now be able to:


Unit 1
Lesson 2
Identifying Key Architecture Flows
LESSON OVERVIEW
This lesson describes the architecutural tiers of the the BI platform and identifies key process
flows through the tiers; for example, validating users, scheduling jobs, and on-demand
viewing of Web Intelligence documents.
LESSON OBJECTIVES
Overview of Key Architecture Flows

Conceptual Tiers
SAP BusinessObjects Business Intelligence platform can be thought of as a series of
conceptual tiers:
● Client
● Web
● Intelligence (Management)
● Storage
● Processing
● Data
The figure illustrates the location of components among the conceptual tiers.

Figure 15: Location of Components Among the Tiers
CMS Validation Process During User Logon

The figure illustrates the CMS validation process during user logon.
Figure 16: CMS Validation Process During User Logon

Lesson: Identifying Key Architecture Flows
Process When A User Logs on to BI Launch Pad

1. The user sends the logon request from the BI launch pad Web Client through the Web
server to the Web application server, where the BI launch pad Web application is running.
This logon process also applies to other Web clients, such as the Central Management
Console (CMC).
2. The Web application server determines that the request is a logon request. The Web
application server sends the user name, password, and authentication type to the Central
Management Server (CMS) for authentication.
3. The CMS validates the user name and password against the appropriate database. In this
case, Enterprise authentication is used, so user credentials are authenticated against the
CMS system database.
4. Upon successful validation, the CMS creates a session in memory for the user.
5. The CMS sends a response to the Web application server to let it know that the validation
was successful.
6. The Web application server generates a logon token in memory for the user session. For
the rest of this session, the Web application server uses the logon token to validate the
user against the CMS. The Web application server also generates the next Web page to
send to the Web client.
7. The Web application server sends the next Web page to the Web server.
8. The Web server sends the Web page to the Web client.
Schedule Setting Process for a Web Intelligence Document

The figure illustrates the schedule setting process for a Web Intelligence document.

Figure 17: Schedule Setting Process for a Web Intelligence Document
Process for Setting a Schedule for a Web Intelligence Document

1. The user sends the schedule request from the Web client of the BI launch pad through the
Web server to the Web application server, where the BI launch pad Web application is
running.
2. The Web application server interprets the request and determines that the request is a
schedule request. The Web application server sends the schedule information, including
time and destination, to the specified CMS.
3. The CMS checks the CMS system database to ensure that the user has the rights required
to schedule the object. If the user has sufficient rights, the CMS adds a new record to the
CMS system database. The CMS also adds the instance to its list of pending schedules.
4. The CMS sends a response to the Web application server to let it know that the schedule
operation was successful.
5. The Web application server generates the next HTML page and sends it through the Web
server to the Web client.
Start-Up Process for the Server Intelligence Agent

The figure illustrates the start-up process for the Server Intelligence Agent.

Figure 18: Start-Up Process for the Server Intelligence Agent
Process for Starting the Server Intelligence Agent

1. The user starts the Server Intelligence Agent (SIA) manually in the Central Configuration
Manager (CCM). An SIA can be configured to start automatically with the operating
system, or it can be started manually with the CCM.
2. The SIA looks in its cache to locate a CMS. If the SIA is configured to start a local CMS, and
the CMS is not running, the SIA starts the CMS and connects. If the SIA is configured to
use a running CMS (local or remote), it attempts to connect to the first CMS in its cache. If
the CMS is not currently available, it attempts to connect to the next CMS in its cache. If
no cached CMS is available, the SIA waits for one to become available. The CMS then
confirms the SIA’s identity to ensure that it is valid.
3. After the SIA has successfully connected to a CMS, it requests a list of servers to manage.
A SIA does not store information about the servers it manages. The configuration
information that dictates which server is managed by an SIA is stored in the CMS system
database and is retrieved from the CMS by the SIA when it starts.
4. The CMS queries the CMS system database for a list of servers managed by the SIA. The
configuration for each server is also retrieved.
5. The CMS returns the list of servers to manage, and their configuration, to the SIA.
6. For each server configured to start automatically, the SIA starts it with the appropriate
configuration and monitors its state. Each server started by the SIA is configured to use
the same CMS used by the SIA. Any servers that are not configured to start automatically
with the SIA will not start.

Run Process for a Scheduled Web Intelligence Document

The figure illustrates the run process for a scheduled Web Intelligence document.
Figure 19: Run Process for a Scheduled Web Intelligence Document
Process for Running a Scheduled Web Intelligence Document

1. The CMS checks the CMS system database to determine if there is any Web Intelligence
document scheduled to run at that time.
2. When the scheduled job time arrives, the CMS locates an available Web Intelligence
Scheduling Service running on an Adaptive Job Server. The CMS sends the schedule
request and all information about the request to the Web Intelligence Scheduling Service.
3. The Web Intelligence Scheduling Service locates an available Web Intelligence Processing
Server, based on the Maximum Jobs Allowed value configured on each Web Intelligence
Processing Server.
4. The Web Intelligence Processing Server determines the location of the Input File
Repository Server (FRS) that houses the document and the universe metalayer file on
which the document is based. The Web Intelligence Processing Server then requests the
document from the Input FRS. The Input FRS locates the Web Intelligence document as
well as the universe file on which the document is based, and then streams them to the
Web Intelligence Processing Server. (This step also requires communication with the CMS
and the CMS system database to locate the required server and objects).
5. The Web Intelligence document is placed in a temporary directory on the Web Intelligence
Processing Server. The Web Intelligence Processing Server opens the document in
memory. The QT.dll generates the SQL from the universe on which the document is

based. The Connection Server libraries included in the Web Intelligence Processing Server
are used to connect to the data source, which is a relational database in this example. The
required data passes through QT.dll back to the Report Engine in the Web Intelligence
Processing Server, where the document is processed. A new successful instance is
created.
6. The Web Intelligence Processing Server uploads the document instance to the Output File
Repository Server. This step also requires communication with the CMS and the CMS
system database to locate the required server and objects.
7. The Web Intelligence Processing Server notifies the Web Intelligence Scheduling Service
(on the Adaptive Job Server) that document creation is completed. If the document is
scheduled to go to a destination, such as file system, FTP, SMTP, or Inbox, the Adaptive
Job Server retrieves the processed document from the Output File Repository Server and
delivers it to the specified destinations. That is not the case in this example.
8. The Web Intelligence Scheduling Service updates the Central Management Server with
the job status.
9. The CMS updates the job status in its memory, and then writes the instance information
to the CMS system database.
On-Demand Viewing Process for a Web Intelligence Document

The figure illustrates the on-demand viewing process for a Web Intelligence document.
Figure 20: On-Demand Viewing Process for a Web Intelligence Document

Processing for On-Demand Viewing of a Web Intelligence Document
1. The user sends the view request from the BI launch pad Web client through the Web
server to the Web application server, where the BI launch pad Web application is running.
2. The Web application server recognizes the request as a request to view a Web Intelligence
document. The Web application server checks the CMS to ensure that the user has
sufficient rights to view the document.
3. The CMS checks the CMS system database to determine if the user has the appropriate
rights to view the document.
4. The CMS sends a response to the Web application server to confirm that the user has
sufficient rights to view the document.
5. The Web application server sends a request to the Web Intelligence Processing Server,
requesting the document.
6. The Web Intelligence Processing Server requests the document, and the universe file on
which the requested document is built, from the Input FRS. The universe file contains
metalayer information, including row-level and column-level security. The Input FRS sends
a copy of the document and universe to the Web Intelligence Processing Server. This step
also requires communication with the CMS and the CMS system database to locate the
required server and objects.
7. The Web Intelligence Report Engine runs on the Web Intelligence Processing Server. The
Report Engine opens the document in memory and launches QT.dll and a Connection
Server in process. QT.dll generates, validates, and regenerates the SQL and connects to
the database to run the query. The Connection Server uses the SQL to get the data from
the database to the Report Engine, where the document is processed.
8. The Web Intelligence Processing Server sends the viewable document page that was
requested to the Web application server.
9. The Web application server forwards the document page to the Web server.
10. The Web server sends the requested page to be rendered in the Web client.
Additional Information about Key Architecture Flows

Title Online Location
Official Product Tutorials — SAP Business In the SAP Community Network, search for
Objects Business Intelligence Platform 4.x the title.
LESSON SUMMARY

Unit 1
Lesson 3
Reviewing SAP BusinessObjects BI Platform
Security
LESSON OVERVIEW
In this lesson, we will review SAP BusinessObjects BI platform security concepts.
LESSON OBJECTIVES
User and Group Set Up

Default User Accounts
In the Users and Groups management area, you can specify everything required for a user to
access SAP BusinessObjects Business Intelligence platform. You can also view the three
default user accounts summarized by the following table.
Table 1: Default User Accounts

Account Name Description
Administrator This user account belongs to the Administrators and Every-

one groups. An administrator can perform all tasks in all BI
platform applications (for example, the CMC, CCM, Publish-
ing Wizard, and BI launch pad).
Guest This user account belongs to the Everyone group. This ac-
count is disabled by default and is not assigned a password
by the system. If you assign a password to this account, the
single sign-on to the BI launch pad will be broken.
SMAdmin This user account is a read-only account used by the SAP Sol-
ution Manager to access BI platform components.
The default user accounts are displayed in the figure.

Figure 21: Default User Accounts
Licensing
The BI platform supports four license types.
License Types
● Concurrent user
● Named user
Each license type grants and restricts access to particular tasks and applications. Depending
on which license you have, you may be unable to access some applications, create content, or
add documents to the repository.
Note:
Choose License Key in the CMC for more information on your licensing scheme.
License Type and Access

Concurrent User
Designed for users who need occasional access to the BI platform. This license specifies
how many users can be connected to the BI platform at any given time.
Named User
Designed for users who require access to BI platform regardless of the number of other
people who are currently connected.

Lesson: Reviewing SAP BusinessObjects BI Platform Security
Caution:
BI Viewer users cannot access the CMC.
User Settings
New users and groups are created in the CMC. When you create a new user account in the
CMC, you first must specify the user’s properties, before you configure group memberships
for the user. Groups are collections of users who share the same account privileges. For
instance, you might create groups that are based on department, role, or location. Groups
enable you to change the rights for users in one place (a group) instead of modifying the
rights for each user account individually. You can also assign object rights to a group or
groups.
User Rights and Permissions
After a user account has been created, you can modify the account properties. The properties
that can be modified include:
● Account Name
The account name is the unique identifier for a user account and is the user name entered
when logging into the SAP BusinessObjects Business Intelligence platform.
● Full Name
This optional field is used to capture the user’s full name. We recommend that you use this
field, particularly when managing many users.
● Email
This optional field is used to add the user’s email address and is used for reference only.
For example, if the user forgets their password sometime in the future, you can retrieve
their email address from this field to send them their password.
● Description
This optional field is used to add information about the user, such as their position,
department, or geographic location.
● Enterprise Password Settings
User password settings allow you to change the password and password settings for the
user.
Global password settings can be configured in the Authentication area of the Central
Management Console.
● Connection Type
This option specifies how the user connects to the SAP BusinessObjects Business
Intelligence platform based on the license agreement.
● Account is Disabled
This check box allows the Administrator to deactivate the user account, instead of
permanently deleting the account. This option is useful when administering users who will
be temporarily denied system access, such as employees taking parental leave.
Select the Account is disabled check box to disable the Guest account and make it
unavailable for use.

● Assign Alias
If a user has multiple accounts within SAP BusinessObjects Business Intelligence platform,
use this feature to link the accounts. This results in the user having multiple SAP
BusinessObjects Business Intelligence platform login credentials that map to one SAP
BusinessObjects Business Intelligence platform account.
You can also use the New Alias button to create a new alias.
Group Hierarchy
Groups are collections of users who share the same account privileges. Therefore, you may
create groups that are based on department, role, or location. Groups enable you to change
the rights for users in one place (a group) instead of modifying the rights for each user
account individually. You can also assign object rights to a group or groups.
In the Users and Groups area, you can create groups that give a number of people access to
the report or folder. These groups allow you to make changes in one place instead of
modifying each user account individually. You can also view the several default group
accounts summarized by the following table.
Note:
To view groups in the CMC, in the tree panel, choose Group List. Alternatively, to
display a hierarchical list of all available groups, choose Group Hierarchy.
Table 2: Group Hierarchy

Account name Description
Administrators Members of this group can perform all tasks in all of the SAP
BusinessObjects Business Intelligence platform applications
(CMC, CCM, Publishing Wizard, and BI launch pad). By de-
fault, the Administrators group contains only the Administra-
tor user.
Everyone Each user is a member of the Everyone group.
QaaWS Group Designer Members of this group have access to Query as a Web Serv-
ice.
Report Conversion Tool Members of this group have access to the Report Conversion
Users Tool application.
Translators Members of this group have access to the Translation Manag-
er application.
Universe Designer Users Users who belong to this group are granted access to the Uni-
verse Designer folder and the Connections folder. They can
control who has access rights to the Designer application.
Add users to this group as needed. By default, no user be-
longs to this group.
The group hierarchy is displayed in the figure.

Figure 22: Group Hierarchy
Groups and Subgroups

After creating a new group, you can add users, add subgroups, or specify group membership,
so that the new group is actually a subgroup. Subgroups provide additional levels of
organization, so they are useful when you set object rights to control users’ access to your BI
platform content.
It is useful to create subgroups when you must further classify groups of users. For example,
users can be grouped by location (such as London), and then further divided according to
their department (such as the London Finance Team).
Group Settings
After a group is created, you can modify its membership to include other groups. Groups can
include other groups as subgroups. Group names must be unique. After a group is created,
you can modify the properties.
User Group Properties
● Title
● Description
● Translations
● User Security
● Member of
● Profile Values
● Account Manager
Rights in the BI Platform

Rights are the base units for controlling user access to the objects, users, applications,
servers, and other features in the BI platform. They play an important role in securing the
system by specifying the individual actions that users can perform on objects. In addition to

enabling access control to your BI platform content, rights enable you to delegate user and
group management to different departments. Rights also provide your IT department with
administrative access to servers and server groups.
You can set rights on objects (for example, folders and documents) and principals (the users
and groups that access the objects). For example, to give a manager access to a particular
folder, add the manager to the access control list (the list of principals who have access to an
object) for the folder. You cannot give the manager access by configuring the manager's
rights settings in the Users and Groups area. The User Security settings for the manager in
the Users and Group area are used to grant other principals (such as delegated
administrators) access to the manager as an object in the system. In this way, principals are
themselves like objects for others with greater rights to manage.
Rights on objects can be Granted, Denied, or Not Specified. If a right is Not Specified, the right
is denied. In addition, if the access control settings result in a right being both Granted and
Denied to a User or Group, the right is denied.
An important exception to this rule occurs when a right is explicitly set on a child object that
contradicts the rights inherited from the parent object. In this case, the right set on the child
object overrides the inherited rights. This exception also applies to users who are members of
groups. If a user is explicitly granted a right that is denied to the user's group, the right set on
the user overrides the inherited right from the group.
Rights Terminology
Access levels
Access levels are groups of rights that users frequently need. They allow administrators
to set common security levels quickly and uniformly rather than requiring that individual
rights be set one by one. The BI platform comes with several predefined access levels.
These predefined access levels are based on a model of increasing rights: Beginning with
View and ending with Full Control, each access level builds on the rights granted by the
previous level.
Inheritance
The BI platform recognizes two types of inheritance: group inheritance and folder
inheritance. Group inheritance allows principals to inherit rights as the result of group
membership. Folder inheritance allows principals to inherit any rights that they have
been granted on an object's parent folder.
Top-level folder security
Top-level folder security is the default security set for each specific object type (for
example Universes, Web Intelligence Application, Groups, and Folders). Each object type
has its own top-level folder (root folder) from which all the subobjects inherit rights.
If there are any access levels common to certain object types that apply throughout the
whole system, set them at the top-level folder specific to each object type. For example, if
the Sales group requires the View access level to all folders, you can set this access at the
root level for Folders.
Folder-level security
Folder-level security enables you to set access-level rights for a folder and the objects
contained within that folder. While folders inherit security from the top-level folder (root
folder), subfolders inherit the security of their parent folder. Rights set explicitly at the
folder level override inherited rights.
Object-level security

Objects in BI platform inherit security from their parent folder. Rights set explicitly at the
object level override inherited rights.
Advanced Rights Settings

To provide you with full control over object security, the CMC allows you to set advanced
rights. These advanced rights provide increased flexibility as you define security levels for
objects at a granular level.
Use advanced rights settings, for instance, to customize a principal’s rights to a particular
object or set of objects. Most importantly, use advanced rights to deny a user or group any
right that must not be changed when, in the future, you change group memberships or folder
security levels.
The following table summarizes the options that you have when you set advanced rights.
Table 3: Advanced Rights

Rights Option Description
Granted The right is granted to a principal.

Denied The right is denied to a principal.
Not Specified The right is unspecified for a principal. By de-
fault, rights set to Not Specified are denied.
Apply to Object The right applies to the object. The option be-
comes available when you choose Granted or
Denied.
Apply to Sub Objects The right applies to the subobject. The option
becomes available when you choose Granted
or Denied.
Type-specific Rights
Type-specific rights are rights that affect specific object types only, such as SAP Crystal
reports, folders, or access levels. Type-specific rights consist of the following:
● General rights for the object type
These rights are identical to general global rights (for example, the right to add, delete, or
edit an object), but you set them on specific object types to override the general global
rights settings.
● Specific rights for the object type
These rights are available for specific object types only. For example, the right to export a
report's data appears for SAP Crystal reports but not for Microsoft Word documents.
The diagram Type-specific rights example illustrates how type-specific rights work. Right 3
represents the right to edit an object. Group A is denied Edit rights on the top-level folder and
granted Edit rights for SAP Crystal reports in the folder and subfolder. These Edit rights are
specific to SAP Crystal reports and override the rights settings on a general global level. As a
result, members of Group A have Edit rights for SAP Crystal reports but not the XLF file in the
subfolder.

Figure 23: Type-Specific Rights Example
Type-specific rights are useful because they let you limit the rights of principals based on
object type. Consider a situation in which an administrator wants employees to be able to add
objects to a folder but not create subfolders. The administrator grants Add rights at the
general global level for the folder, and then denies Add rights for the folder object type.
Rights are divided into collections based on the object types to which they apply.
Rights Collections
General
These rights affect all objects.
Content
These rights are divided according to particular object types. Examples of content object
types include SAP Crystal reports and Adobe Acrobat PDFs.
Application
These rights are divided according to which BI platform application they affect. Examples
of applications include the CMC and BI launch pad.
System
These rights are divided according to which core system component they affect.
Examples of core system components include Calendars, Events, and Users and Groups
Type-specific rights are in the Content, Application, and System collections. In each
collection, type-specifc rights are further divided into categories based on object type.

Object Security Settings

You can manage security settings for most objects in the CMC with the security options on
the Manage menu. These options let you assign principals to the access control list for an
object, view the rights that a principal has, and modify the rights that the principal has to an
object.
LESSON SUMMARY


Unit 1
Lesson 4
SAP BusinessObjects 4.3 and SAP Analytics
Cloud Hybrid Solution
LESSON OBJECTIVES
SAP Analytics Business Intelligence Strategy and Direction

SAP BusinessObjects 4.3 on-premise solution works with SAP Analytics Cloud (SAC) in a
Hybrid Analytics scenario. In the long-term, SAP has strategically positioned SAC as the
Augmented Analytics tool. Meanwhile, SAP continues to deliver innovations with SAP
BusinessObjects 4.3 as part of a hybrid Analytics configuration.
Figure 24: SAP Analytics Cloud and SAP BusinessObjects working together as part of an Analytics Hybrid
Solution
SAP will continue to provide maintenance and support for SAP BusinessObjects 4.3 on-
premise until at least 2027. At that point, SAP will re-evaluate continued support and
maintenance. Information about this will be disseminated publicly as this time-line
approaches.

Figure 25: SAP BusinessObjects 4.3 Statement of Direction
SAP BusinessObjects Platform and SAP Analytics Cloud Hybrid Solution

Setting up a Hybrid Analytics solution allows SAP Analytics Cloud (SAC) to access on-prem
Universes and Web Intelligence documents as a data source. An SAC user can create a story
based on an SAC Model derived from on-prem universes using the Live Universe Connector
configured in SAC to point to the SAP BusinessObjects 4.3 BI Platform.
Figure 26: Using Universes as a data source for SAP Analytics Cloud (SAC)
You can also utilize existing Web Intelligence documents in the BI Repository as a data source
for SAC. An SAP SAC user would have to create an SAC model derived from an existing Web
Intelligence document resident in the BI Repository.

Lesson: SAP BusinessObjects 4.3 and SAP Analytics Cloud Hybrid Solution
Figure 27: Consume a Web Intelligence document data model in SAP Analytics Cloud (SAC)
LESSON SUMMARY


Unit 1
Lesson 5
SAP BusinessObjects BI Platform Support Tool
LESSON OVERVIEW
LESSON OBJECTIVES
SAP BusinessObjects BI Platform Support Tool 2.1

The BI Platform Support Tool is a Java based utility used by support engineers, consultants,
and BI administrators. It is designed to support many aspects of the BI platform and simplifies
the process of reporting on the landscape configuration, performing root cause analysis
tasks, and delivering performance optimization and go-live services. This tool is free of charge
and will be maintained with enhancements and corrections for the foreseeable future.
This section helps you to prepare the BI platform landscape, where the BI servers run on MS
Windows. To get the most functionality, the following optional configurations are added:
What? Where? Why?
SAP Host Agent Each BI Platform node and Hardware metrics and config-
Tomcat node urations are collected using
the SAP Host Agent (Hard-
ware Analysis and Patch His-
tory Analysis).
E2E tracing has the option to
use the SAP Host Agent when
gathering log files once the
trace is complete.
Tomcat JMX Configuration Each Tomcat node in your Metrics are collected from
landscape Tomcat via JMX (Web Appli-
cation Server Analysis).
In the BI Platform Support Tool 2.1, some of the functionality now requires the SAP Host
Agent to collect the analysis data. For example, the SAP Host Agent is required for
the Hardware Analysis Summary report and the Patch History Analysis report. It is also used
to compress and gather the log files from each node during an E2E trace. The SAP Host Agent
is a service that has a very lightweight performance footprint and provides a secure
communication channel between the BI Platform Support Tool client, and your BI and Web
Application Server nodes.
● If you have never installed the SAP Host Agent in your environment, to get the most
functionality from the Landscape Analysis Report and E2E Trace Wizard, you must
complete this step.

● If you have already installed the SAP Host Agent to use with the BI Platform CMC
Monitoring application, then you do not need to install the SAP Host Agent again on the BI
nodes. However, if possible, install the SAP Host Agent on your Apache Tomcat server.
● If you already have the Solution Manager Diagnostic Agent 7.4 on your SAP BI platform
nodes and your Web Application Server nodes, it is not necessary to install the SAP Host
Agent. It is already included as part of the Diagnostic Agent.
● If you are running Diagnostic Agent 7.3 or lower, it is recommended that you update the
SAP Host Agent to the latest 7.2 version (older SAP Host Agents that ship with older
Diagnostic Agents may not be able to collect the required host metrics). The upgrade is a
safe and quick process, refer to the Manual Upgrade of SAP Host Agent page (https://
help.sap.com/saphelp_nw73ehp1/helpdata/en/ab/f882afa4984d818fa2f8d530ad0e83/
content.htm)
● The SAP Host Agent is not required on the client running the BI Platform Support Tool.
● The SAP HOST AGENT 7.21 Patch 45 or higher and SAPCAR 7.21 archives are required.
They can be downloaded from the SAP Software Download Center (https://
support.sap.com/swdc).
LESSON SUMMARY

Unit 1
Learning Assessment
1. What are some of the ways that implementing a BI strategy can help the IT department?
2. SAP BusinessObjects Cloud for business intelligence may be hosted with Amazon Web
Services.
Determine whether this statement is true or false.
X True
X False
3. SAP HANA-based Analytics are reported by schedule, and therefore not real-time.
X True
X False
4. Use SAP HANA Rapid Deployment Solutions when you want to do reporting analysis on an
ECC system.
X True
X False
5. SAP offers many BI tools. At first glance, an organization might think the varied choice of
tools would be too confusing for users or too complicated for IT to develop and support.
Why should an organization not pick just one SAP BI tool that fits most of its business
scenarios and use that tool for all of its scenarios?

Unit 1: Learning Assessment
6. Which of the following options are server components of the platform?

Choose the correct answers.
X A Client Tools
X B Data Federator Services
X C Lifecycle Management
X D Configuration Services
7. Which of the following is a third party component that can be installed on the platform?
Choose the correct answer.
X A Adobe Server Solutions
X B Linux Translator
X C Atlassian JIRA
X D Subversion
8. The Adaptive Job Server is a Processing Tier component for integration.

X True
X False
9. Web Intelligence data cannot be accessed offline.

X True
X False
10. Match the tiers with the components that function within the tiers.
Match the item in the first column to the corresponding item in the second column.
Web Tier Reporting data

Management Tier Information Design Tool
Processing Tier Tomcat server
Database Tier CMS server
Client Tier WEB Intelligence processing
server

11. During the process to set a schedule for a Web Intelligence document, the Web
Application Server directly communicates with the BI Launch Pad.
X True
X False
12. Web Intelligence documents can be viewed on-demand.

X True
X False
13. Default user accounts in the BI platform include:

X A Superuser
X B Guest
X C BI Viewer
X D Administrator
X E Named user
14. Select the options that can be the basis of a group.

X A Department
X B Login
X C Location
X D Role
X E Status
15. What is an access level?

16. What is a principal?
17.

Unit 1
Learning Assessment - Answers
1. What are some of the ways that implementing a BI strategy can help the IT department?
The IT organization can align itself with business partners and formal business needs. The
organization can plan for short, medium, and long term projects. IT can align its efforts
with strategic business goals and deliver measurable results. The company can create
business justifications for an enterprise-wide scope and an end-to-end BI approach,
including data management.
2. SAP BusinessObjects Cloud for business intelligence may be hosted with Amazon Web
Services.
X True
X False
3. SAP HANA-based Analytics are reported by schedule, and therefore not real-time.
X True
X False
4. Use SAP HANA Rapid Deployment Solutions when you want to do reporting analysis on an
ECC system.
X True
X False

Unit 1: Learning Assessment - Answers
5. SAP offers many BI tools. At first glance, an organization might think the varied choice of
tools would be too confusing for users or too complicated for IT to develop and support.
Why should an organization not pick just one SAP BI tool that fits most of its business
scenarios and use that tool for all of its scenarios?
SAP BI offerings meet four sets of client requirements: (1) Reporting, (2) Monitoring, (3)
Analyzing, and (4) Discovering. For each of these requirement areas, SAP has designed
products to meet the specific needs of its large and diverse customer base. When an
organization is deciding which SAP BusinessObjects BI solution to choose for each of
these requirement areas, it should determine who will create the information, who will use
the information, what the business requirements are, what the data sources are, and how
will the data sources connect to the tools.
6. Which of the following options are server components of the platform?

X A Client Tools
X B Data Federator Services
X C Lifecycle Management
X D Configuration Services
7. Which of the following is a third party component that can be installed on the platform?
X A Adobe Server Solutions
X B Linux Translator
X C Atlassian JIRA
X D Subversion
8. The Adaptive Job Server is a Processing Tier component for integration.

X True
X False

9. Web Intelligence data cannot be accessed offline.

X True
X False
10. Match the tiers with the components that function within the tiers.
Web Tier Tomcat server

Management Tier CMS server
Processing Tier WEB Intelligence processing
server
Database Tier
Reporting data
Client Tier
Information Design Tool
11. During the process to set a schedule for a Web Intelligence document, the Web
Application Server directly communicates with the BI Launch Pad.
X True
X False
12. Web Intelligence documents can be viewed on-demand.

X True
X False

13. Default user accounts in the BI platform include:

X A Superuser
X B Guest
X C BI Viewer
X D Administrator
X E Named user
14. Select the options that can be the basis of a group.

X A Department
X B Login
X C Location
X D Role
X E Status
15. What is an access level?
Access levels are groups of rights that users frequently need. They allow administrators to
set common security levels quickly and uniformly rather than requiring that individual
rights be set one by one.
16. What is a principal?
A principal is a user or a group.
17.

UNIT 2 Identifying Requirements
Lesson 1
Assessing your Organization's Environment 63
UNIT OBJECTIVES
● Assess your organization's environment

Unit 2: Identifying Requirements

Unit 2
Lesson 1
Assessing your Organization's Environment
LESSON OVERVIEW
In this lesson, we consider the importance of accurately assessing the needs of your
organization prior to deploying. We will discuss technical requirements such as hardware,
Operating Systems, Databases and Web Application Servers.
LESSON OBJECTIVES
Planning your Deployment

Planning your deployment involves the following steps:
1. Refer to the SAP BusinessObjects Business Intelligence Product Availability Matrix

documentation available in the SAP BusinessObjects Platform Support Tool 2.1.
2. Review the key concepts you need to consider for your deployment, including operating
system, database, application server considerations, security, performance and
scalability, and high availability.
3. Choose an initial deployment architecture. Consider which deployment architecture will

serve your needs within the limits of your resources.
Note:
It is important to note that each deployment is unique. The flexibility of the SAP
BusinessObjects Business Intelligence platform service-based architecture allows
you to tailor the deployment to serve your organization’s requirements as
precisely as possible.
Operating Systems
The resources and conventions used in your existing network environment affect how you
deploy the SAP BusinessObjects Business Intelligence platform.
Different deployment options are available to you, depending on the operating systems, web
application servers, database servers, and authentication method you plan to use. Other
conventions used in your current environment may also affect how you deploy the SAP
BusinessObjects Business Intelligence platform, such as security, performance monitoring,
and design for high availability.
The SAP BusinessObjects Business Intelligence platform runs on Microsoft Windows and Unix
(including Linux) operating systems.
An administrator account must be used to install the SAP BusinessObjects Business
Intelligence platform on Windows operating systems.

Note:
Review the latest SAP BusinessObjects Business Intelligence Platform Product
Availability Matrix (PAM) available at http://help.sap.com
Databases in the SAP Business Intelligence Platform

In the SAP BusinessObjects Business Intelligence platform, a database can be defined as a
data repository that organizes a collection of information into structures called tables for
rapid search and information retrieval. Databases allow tables to be grouped together into
collections of logically related tables called tablespaces. Tables are grouped into tablespaces
within a database system in the same way that files are grouped into a directory within a file
system.
Web Application Servers

The SAP BusinessObjects Business Intelligence platform requires a Java Web application
server to process the server-side scripts that make up Web applications. You can install the
Tomcat application server during the SAP BusinessObjects Business Intelligence platform
installation or use a supported third-party Web application server and Java Development Kit
(JDK).
Web Servers
Although Web application servers come with built-in Web server functionality, the SAP
BusinessObjects Business Intelligence platform also supports the separation of Web and Web
application servers into a de-paired configuration. In a de-paired configuration, the Web
server will serve static and cached content to offset a portion of the requests sent to the Web
application server.
Fail Over and Loadbalancing

The SAP BusinessObjects Business Intelligence platform supports clustered Web application
servers with load balancing. Hardware or software load balancers can be used as the entry-
point for the Web application servers, to ensure that the processing is evenly distributed
among the Web application servers.
Note:
● Load balancing a cluster of SAP BusinessObjects Business Intelligence

platform servers is not required, as the Central Management Server (CMS)
already distributes work between cluster nodes.
● The Central Management Console (CMC) Web application does not support
session fail-over. However, the BI launch pad is fault-tolerant, and does support
session fail-over, so users will not notice if a cluster node fails.
Multi-Homed Environment
The SAP BusinessObjects Business Intelligence platform supports multi-homed
environments, in which a server has two or more network addresses. This allows servers to be
configured to receive requests from one network and transmit requests to another.
Security
Your organization’s security policies affect how you deploy the SAP BusinessObjects
Business Intelligence platform on your network. Do you plan to use the system’s built-in

Lesson: Assessing your Organization's Environment
authentication, or do you need it to work with existing Lightweight Directory Authentication

Protocol (LDAP) or Windows Active Directory (AD) authentication? You also need to decide
how your firewalls are configured, and if you plan to use a reverse proxy.
Performance and Scalability

Before deciding how to deploy your system, consider whether the demand on the system may
change after it has been installed. This could be an increase in the number of concurrent
users, the volume of business data, report complexity, or any other factor that could cause
your SAP BusinessObjects Business Intelligence platform system requirements to change.
Anticipate these changes before you deploy to save time and money by making architectural
choices that will support a scalable solution. For example, if you are expecting an increase in
the number of concurrent users accessing your system, you may consider deploying a small
three-node cluster that can be expanded to five-nodes when demand increases.
By monitoring and regularly re-evaluating your system’s performance, you can schedule
tuning or configuration changes before potential issues become performance problems.
Designing for High Availability

High availability refers to a system that is almost always operational. When designing a
system for high availability, consider how much down-time is acceptable for the system. To
minimize time down, consider a combination of failover processing, server or server process
redundancy, and frequent back-ups.
Product Coexistence
Several SAP BusinessObjects Business Intelligence platform products can exist on the same
host.
Caution:
All SAP BusinessObjects Business Intelligence platform products installed at
your organization must have the same patch level. For example, if your
organization upgrades SAP BusinessObjects Business Intelligence platform
server products to a service pack or fix pack, all add-ons, Client Tools, and stand-
alone products must also be upgraded. Similarly, if one product is downgraded,
all other products should also be downgraded.
Creating Additional Adaptive Processing Servers

The installation program installs one Adaptive Processing Server (APS) per host system.
Depending on the features that you’ve installed, this APS may host a large number of
services, such as the Monitoring Service, Lifecycle Management Service, Multi-Dimensional
Analysis Service (MDAS), and Publishing Service.
Deployment Checklist
This section provides a checklist for the steps you need to perform when planning a
deployment of the SAP BusinessObjects Business Intelligence platform. The following
checklist outlines the major tasks to be completed for the planning phase of your SAP
BusinessObjects Business Intelligence platform deployment.
Checklist Item Complete (Y/N)
Understand the tiers that make up the SAP Y/N

BusinessObjects Business Intelligence plat-
form architecture.

Checklist Item Complete (Y/N)
Understand the components and how they Y/N

communicate with each other.
Understand the workflows (how information Y/N

travels through the architecture).
Identify the operating system on which the Y/N

system will be deployed.
Choose the database servers will you be ac- Y/N

cessing.
Choose a Web application server. Y/N
Are you using third-party authentication, se- Y/N

cure sockets layer, firewalls, and/or reverse
proxy?
Identify potential performance problems. Y/N
LESSON SUMMARY

UNIT 3 Planning a Deployment
Lesson 1
Identifying Factors to Consider when Deploying a BI Platform 4.3 System 69
Lesson 2
Identifying Factors that Influence the Deployment Process 73
Lesson 3
Identifying Factors to Consider when Installing SAP BusinessObjects Platform 4.3 77
Lesson 4
Identifying Factors to Consider when Integrating SAP Analytics Cloud 81
Lesson 5
Identifying Factors to Consider when Configuring a Deployment 87
UNIT OBJECTIVES
● Identify factors to consider when designing and sizing a deployment

● Identify factors that influence the deployment process
● Identify factors to consider when installing a deployment
● Identify factors to consider when integrating with SAP Analytics Cloud
● Identify factors to consider when configuring a deployment

Unit 3: Planning a Deployment

Unit 3
Lesson 1
Identifying Factors to Consider when
Deploying a BI Platform 4.3 System
LESSON OVERVIEW
In this lesson, we will review important factors to consider when planning a SAP
BusinessObjects Platform 4.3 deployment. We will consider virtualization strategies and
sizing considerations.
LESSON OBJECTIVES
Overview of Deployment Preparation

Considerations When Preparing for Deployment
Consider these topics when preparing for deployment:
● Virtualization
● Best practices for deployment architecture
● Sizing and configuration
Strategies for Safeguarding a Production System

The following strategies need to be in place to safeguard a production system:
● Fail-over methods
● Load balancing
● Clustering
● Backup strategy
● File storage
Everything must be planned up front, before beginning the implementation, so that you do not
encounter any problematic surprises.
Consideration for Infrastructure, Integration, and Plug-Ins

Infrastructure, integration, and plug-in concerns must be considered:
● SSO authentication protocols and identity management

● Portal integration

● Cross-domain policies, firewalls, and proxies

● Third-party compatibility
● Interoperability fixes for integration assets
Virtualization Concepts
Considerations for Virtualization
When planning a deployment, consider answering the following virtualization questions:
● Are you getting all of the central processing unit (CPU) power for the CPU licenses that you
paid for?
● Are other VMs on the same machine jamming the Input/Output (I/O) paths from the host?
● Is the memory being over committed without your knowledge?
It is recommend that you become familiar with VMWare concepts and terminology, so that
you can better negotiate with your IT infrastructure providers. See Additional Information
about Designing and Sizing a Deployment for more information.
Best Practices for Deployment

Best Practices When Planning Configuration Elements
The following configuration elements must be considered when planning a deployment:
● The installation directory should have sufficient drive space.

● Prerequisites, such as SAP GUI and SMD Agent, should already be installed.
● Forward-fit (fix) detection should be included, with no special characters in passwords.
● The solution cannot coexist with DS IPS. Ideally, there should be no 4.x systems installed
side by side.
● It must run with NET 3.5 or higher.
Best Practices When Planning Other Components

Other components must be considered when planning a deployment:
● The plan should include monitoring solutions, including Wily Introscope and Solution
Manager.
● It should accommodate database clients and middleware downloads, especially 32–bit
and 64–bit DSN administration.
● Other components should be included, such as Chrome Browser and Java 8.
● It should take into account database availability and location (CMS, Audit, Trending),
threads, and deadlocks.

Lesson: Identifying Factors to Consider when Deploying a BI Platform 4.3 System
Deployment Sizing Considerations

Considerations When Sizing a Deployment
● Ensure you have planned enough memory and number of machines from the start.
● Changes made after tuning and configuring your system create much work.
● To plan for correct sizing, use the sizing estimator.
After you tune up and configure your system, you might retrospectively realize that you need
more memory or additional machines in a cluster. These changes create massive amounts of
rework. You must make sure that you have the correct amount of memory and number of
machines from the beginning, by designing your deployment options and architecture tiers.
To ensure that you have correctly designed the architecture, read the sizing guide and use the
sizing estimator. See Additional Information about Designing and Sizing a Deployment.
You must conduct the sizing calculation before you begin the configuration. Design the
architecture of your deployment options (tiers) before you begin the installation.
Figure 28: Resource Usage Estimator
Additional Information about Designing and Sizing a Deployment

Performance Best Practices for VMware On the VMware website, search for Perform-
vSphere® 5.1 ance Best Practices.
vSphere Resource Management — ESXi 5.1, On the VMware website, search for vSphere
vCenter Server 5.1 Resource Management — ESXi 5.1.
Official Product Tutorials — SAP BI Suite On the SAP Community Network, search for
Tutorials — BI Suite.
Sizing and Deploying SAP BI 4 and SAP Lumi- On the SAP Community Network, search for
ra Primary Sizing and Deployment Resources
for SAP BI 4

LESSON SUMMARY

Unit 3
Lesson 2
Identifying Factors that Influence the
Deployment Process
LESSON OVERVIEW
In this lesson, we will review important factors that influence the deployment process. We will
consider hardware, network topology, and infrastructure design.
LESSON OBJECTIVES
Overview of the Deployment Process

SAP recommends the best practices for deploying BI and sharing valuable resources, such as
the BI Pattern Books.
However, before starting the sizing, architecture, installing, and configuring of the BI
environment, you must know the factors that influence the deployment process.
Factors that Influence the Deployment Process
● The BI platform is organized into conceptual tiers.

● The deployment process follows a recommended workflow.
● Configuration factors must be considered during planning:
- Hardware
- Landscape topology
- Infrastructure
BI Platform Conceptual Tiers

Conceptual Tiers Overview
BI architecture is complex and is organized into the following conceptual tiers:
● Web tier
● Management and Intelligence tier
● Processing tier
● File Storage area
● Database tier
There are a few critical pieces of this architecture to consider when planning a deployment:

1. Web tier servers, including static content (preferably hosted on a dedicated Web server)
and application servers, processing dynamic Java content.
2. Management servers, specifically the Central Management Server (CMS).
3. Adaptive Processing Servers (APS) that host approximately 22 individual services in the
BI landscape and that run in a Java architecture.
Deployment Workflow
Figure 29: Deployment Workflow
Planning is essential to a well designed system landscape. Do not begin running installers
before the entire landscape has been completely planned. If the planning phase is thorough,
the implementation and deployment phases are time consuming, but simple. The post-
installation configuration phase uses a large portion of the deployment time. This phase is
complex, but can be performed in a methodical, step-by-step process.
Hardware, Landscape Topology, and Infrastructure Considerations for Planning

Consideration for Configuration
While planning your configuration, consider the following:
● The proposed system should allow for future growth.

● Hardware should be scalable.
● Your solution should be fully functional before leaving the design phase.
● Important decisions must be made, such as whether to split tiers vertically or whether to
cluster nodes horizontally.
Your enterprise needs to make any proposed system future-proof. Be sure to size to allow for
growth. Work with your vendors to obtain the hardware you need that allows you to easily
scale up when necessary.
How you design the architecture of your solution is a pivotal decision. The solution design
cannot be changed after you have started building, so be sure that it is fully functional before
moving on from the design phase. When planning your design, begin by answering some
questions to help you select a design strategy:

Lesson: Identifying Factors that Influence the Deployment Process
● Are you going to split out the architecture tiers vertically? Answer this question with “yes”
because it improves the user experience.
● Are you going to cluster nodes horizontally? This form of node clustering improves balance
and fault tolerance, so it is a preferable method.
Keep in mind that your existing IT infrastructure (and its limitations) could negatively impact
the high ambitions you have for this system. Be sure to determine if you will be hampered by a
substandard network or storage system, and design your solution to avoid or overcome these
kinds of impediments.
Additional Information about the Deployment Process

SAP BusinessObjects Business Intelligence On the SAP Help Portal, select Analyt-
platform 4.1: Installation, Upgrade, Deploy- ics → Business Intelligence → Business Intel-
ment ligence Platform (Enterprise) → Platform
4.1 → Installation, Upgrade, Deployment
LESSON SUMMARY


Unit 3
Lesson 3
Identifying Factors to Consider when Installing
SAP BusinessObjects Platform 4.3
LESSON OVERVIEW
In this lesson, we will review important factors to consider when installing SAP
BusinessObjects Platform 4.3.
LESSON OBJECTIVES
Successful Installation Preparation

Preparation for a Successful Installation
The following actions are necessary to prepare for a successful installation:
● Check the Platform Availability Matrix (PAM) for a supported platform.

● Check the file system permissions.
● Use a short path for the installation location (such as E:\SAPBOBJ).
● Remember the credentials and parameters for the installer, including passwords and the
cluster key.
● Make sure Secure Socket Layer (SSL) is off, and disable antivirus software, SMD Agent,
and similar software.
● Back up the whole system before attempting an upgrade.
● In the event of problems, restore the system from the backup, rather than by uninstalling a
patch.
Deployment Installation Plan

Considerations When Planning the Installation of a Deployment
Consider the following strategies before implementing the Installation Plan and Architecture
Plan, including the dispersal of different BI services:
● Failover
● Load balancing
● Clustering
● Backup strategy

● File storage
BI server nodes are clustered horizontally to perform fail-over and load balancing.
Web Property Files Management and Customization Plan

Considerations When Planning the Management and Customization of Web Property Files
● Do not modify files in the default installation directory.
● Only modify files in the custom installation directory.
1. Copy the file in the default directory into the custom directory.
2. Add lines only for properties that differ from the default properties.
3. Use Wdeploy to roll out the change.
The default installation files are found in <install_directory>\SAP BusinessObjects

Enterprise XI 4.0\warfiles\webapps\BOE\WEB-INF\config\default\. These files
should not be modified.
When you want to modify an installation file, copy the file from the default directory to
<install_directory>\SAP BusinessObjects Enterprise XI 4.0\warfiles
\webapps\BOE\WEB-INF\config\custom. In the new file in the custom directory, do not
remove any lines. Instead, add lines at the bottom of the file for only those properties that are
different from the default properties. Save the file and use Wdeploy to roll out the change.
You can update the properties files in the Tomcat folder to speed up the process. Go to
<install_directory>\SAP BusinessObjects Enterprise XI\4.0\warfiles
\webapps\BOE\WEB-INF\config\custom\ to access the properties files. Make sure that
you also update the property files in <install_directory> to ensure that the changes are
preserved.
Portal Integration
Considerations When Planning the Integration with Portals
● BI 4.x can be integrated with MS SharePoint and SAP Enterprise Portal.

● The binaries for portal integration are available in the service market place (SMP).
● BI 4.x is enabled for connection to MS SharePoint or SAP Enterprise Portal.
BI 4.x can be integrated with MS SharePoint and SAP Enterprise Portal. Decide on the portal
integration and authentication mechanism that has to be in place to eliminate conflict.
The binaries for portal integration are available in the SAP Mobile Platform. They are installed
and configured with help from the respective portal administrators. When BI 4.x is installed, it
is already enabled for connection to MS SharePoint or SAP Enterprise Portal. Therefore, after
the iViews are installed and configured on SAP Enterprise Portal, BI content can be accessed
from there and similarly from MS SharePoint.
Additional Information about Installing a Deployment

Installation guides and preparation steps for On the SAP Web site, search for Business In-
different types of deployments telligence — SAP Help Portal Page.

Lesson: Identifying Factors to Consider when Installing SAP BusinessObjects Platform 4.3
LESSON SUMMARY


Unit 3
Lesson 4
Integrating SAP Analytics Cloud
LESSON OBJECTIVES
The Hybrid Architecture

The paradigm shift of SAP from on-premise systems to the Cloud-based SAP Analytics Cloud
(SAC) system brings several advantages but also some challenges for new Business
Intelligence systems and influences the architecture of a system landscape for a company in
many ways. However, it is important to understand that with SAP Analytics Cloud, SAP is not
following a "Cloud-only" strategy but rather a "Cloud-first" strategy. This means that the new
Business Intelligence system as part of a the Business platform technology will at last
integrate the SAP BusinessOjects BI Platform with SAP Analytics Cloud to create a powerful,
self-service analytic system within an organization.
Figure 30: The Basic Hybrid Scenario
Such a hybrid system architecture provides a number of benefits in the areas of:
● Data Preparation and Data Wrangling
● Data Modeling
● Data Discovery
● Report Design
● Scheduling and Broadcasting
● Predictive Scenarios,
just to name a few.

Specifically related to data analysis, the SAP strategy essentially offers SAP Analytics Cloud
as the central analytics platform for the creation of hybrid scenarios and thus the promotion
of interoperability. The future of SAP Analytics systems is to incorporate the best of both on-
premise and SAP Analytics Cloud systems.

Figure 31: Why a Hybrid Solution?
In contrast to classic on-premise systems, SAP Analytics Cloud offers all central business
intelligence tasks within a single software-as-a-service (SaaS) platorm. These tasks include:
● Business Intelligence/Analytics
● Planning
● Predictive Analytics
● Analytics Applications
This single platform eliminates the need to combine various front-end tools within an
additional platform.
All of the tools required to visualize, analyze, and create reports on data are possible on a
single platform—SAP Analytics Cloud. The data used by SAC can be from existing data
sources, such as SAP BusinessObjects universes and SAP BW queries, or even directly from a
data source. The interfaces required for this integration flow into the architecture of the
system and usually take the form of a pure data connection.
Figure 32: Possible Hybrid Scenarios
The implementation of such an integrated approach for your company allows your
organization to take advantage of the strengths of both systems, such as:
● The agility of a self-service strategy
● Optimized business performance

Lesson: Identifying Factors to Consider when Integrating SAP Analytics Cloud
● Accessibility across the company

● Reduction in IT overhead by delegating BI system infrastructure, management, and
maintenance to the Cloud provider
● Continual and automatic system and software updates
Figure 33: Benefits of a Hybrid Solution
Technical Considerations
In terms of planning for such an integration, an organization must not only invest in future
intelligence systems but also protect investments already made in existing, on-premise
business intelligence systems. Cooperation and communication between existing systems
with future-oriented systems requires consideration in the areas of data transformation and
the inevitable systems expansions, requiring innovations and technologies for a hybrid
business intelligence landscape. Integrating the new technologies and intelligent enterprise
systems, as part of a new business technology platform, must be included in the planning of
the architecture of new system landscapes.
The technical implementation, which includes the aspects of landscape architecture, extends
to the following areas:
● Data connection: Use of different data sources with different properties
● Data types: Live or import connections
● Re-usability of already created data structures such as SAP BusinessObjects universes or
SAP BW queries
● Single sign on: Compatibility of both systems
● System security
● Report requirements
● Presentation of content
● Platform services
● Collaboration
As data security and data storage are of great importance, considering the correct data
connection is a central point of the architecture. There are two types of connections in SAP
Analytics Cloud:
● Import connection: Enables a broader selection of data sources and in some cases also
requires a lower version of the source system than a live connection. Please check the

suitability of a data source in advance. In this situation, the selected data is extracted from
the data source once or at intervals and is stored on the cloud server.
● Live connection: Does not save any data permanently in the cloud but only uses data at the
time of execution/presentation of a report.
Figure 34: SAC Data Connection Options
In order to carry out an uncomplicated integration of both system security systems, it is

recommended to establish a SAML 2 (Security Assertion Markup Language)-based Single
Sign-on. The definition of the system as a so-called service provider is also necessary, which
must be verified against a separate IDP (Identity Provider). The IDP can be made available
through the SAP Analytics Cloud.
A takeover of the user structures for both systems is desired and supported for a hybrid
solution. In this scenario, the object security of reports, universes, applications, etc. is
maintained by SAP Analytics Cloud, while the SAP Business Objects Enterprise, as the data
supplier, ensures data security and can provide access security for the purpose of data
presentation.
Figure 35: Basic User Administration in the Hybrid Scenario

Lesson: Identifying Factors to Consider when Integrating SAP Analytics Cloud
The result of a successful architecture plan that takes into account all aspects of the SAP
Business Intelligence systems ideally leads to an architecture that allows you to benefit from
the entire SAP BI portfolio. A current evaluation, but also an evaluation optimized for future
changes, increases the business value of your data collection in the context of an optimized
data evaluation and presentation. However, keeping an eye on the entire development
process of the SAP BI process and keeping pace with the changes in technology does not
always make sense in all respects. So consider implementing the best of both worlds with the
hybrid scenario as an option. Your business functions and areas can be available both on-
premise and via Cloud systems. A sensible approach leads to a scalable architecture of an
SAP Business Intelligence portfolio, the scope and use of which can be adapted to your needs
at any time.
LESSON SUMMARY


Unit 3
Lesson 5
Configuring a Deployment
LESSON OVERVIEW
In this lesson, we will review factors to consider when configuring a SAP Business Objects
Platform 4.3 deployment. We will consider optimal configuration settings that will improve
system performance and system scalability.
LESSON OBJECTIVES
Deployment Configuration Plan

Considerations When Planning the Configuration of a Deployment
Based on the deployment requirement, the configuration for the deployment must be planned
in advance to avoid any surprises later. This includes the need for configuring the required
authentication for BI deployment security setup.
● Tune the BI server tiers for effective, optimal performance.

- Web tier
- Processing tier
- Intelligence tier
● Configure the required authentication for BI deployment security setup.
BI Server Tiers Optimization Overview

Due to added functionality, BI becomes more complicated with every release. It is really
important for BI Administrators to have a solid understanding of how the application works
and how to configure it so that we are not negatively impacted by this evolution.
It is equally important to tune all of the tiers: Web tier, Intelligence tier, Processing tier, and
Database tier for an effective, optimally performing BI deployment.
BI Server Tiers Optimization: Web Tier

Considerations When Optimizing the Web Tier
● BI 4.3 ships with a Tomcat Web application server component that processes static
content.
● A dedicated Web server component allows for optimization of JavaScript and images.

● Implementing a Web server provides benefits that out-weigh the costs.

● Apache 2.4 provides scalable, event-based threading for Linux systems.
● A configuration with an Apache Web server and Wdeploy in split mode improves navigation
by 25% or more.
BI 4.3 ships with a Tomcat Web application server component, whose built-in HTTP plug-in
also allows it to process static content. However, a dedicated Web server component, such as
Apache or IBM HTTP Server, allows significant benefits in the optimization of JavaScript and
images. Key points for Web tier optimization are:
● If you are not using a Web server, start planning to implement one. The benefits far out
weigh the costs and the process is documented extensively on SAP Community Network
(SCN).
● For Linux customers, Apache 2.4 offers an event-based threading model that dynamically
scales up and down to meet the user load. This performs well with robust applications like
BI.
● Adding an Apache Web server and using Wdeploy in split mode can improve navigation by
25% or more. This can even be added to the same machine that is running the Tomcat
server.
Figure 36: Web Tier Optimization
Capabilities of the Web Application Container Server (WACS) Application Server

WACS Application Server offers the following capabilities:
● 500 active connections can run concurrently.

● A maximum of 900 threads and a 5 gigabyte size limit is available for a single instance.
● If service usage is consistently at 80–100%, additional service can be added.
Web Tier Optimization

Key points about Web tier optimization include:
● BI 4.3 is leveraging an SAP JVM for the embedded application server for the first time.
However, it is currently using Java 8.

Lesson: Identifying Factors to Consider when Configuring a Deployment
● Java 8 delivers significant performance improvement, especially around startup time and
during garbage collection for a multi-core CPU, capabilities you will use anyway.
BI Server Tiers Optimization: Processing Tier

Considerations When Optimizing the Processing Tier
● Adaptive processing servers (APSs) can host over 20 services.

● The System Configuration wizard identifies the right system configuration template,
splitting APS processes into separate bundles, and stopping unnecessary processes.
● Allocating sufficient heap space to the APS is the single biggest performance factor in a
high performing BI environment.
Adaptive Processing Server Splitting
● APS is a plug-able service model that is Java based and hosts over 20 services.
● APS is certified only for use with SAP JVM. Therefore, currently you cannot use GC1 or a
tiered compilation.
● The System Configuration wizard simplifies the optimization process.
The APS can host over 20 different services. It is an SAP plug-able service container for
interactive processes, such as charting, connectivity to SAP Business Warehouse (SAP BW),
and promotion management.
The APS is a Java-based process like the Web Application Server (WAS), but unlike the WAS,
it is not certified for use with any JVM other than SAP JVM. Therefore, you cannot switch to
Java 7 and enable the GC1 collector. Instead, use the documented best practices from SAP to
adjust and configure these processes.
The BI 4.3 provides the System Configuration wizard as a great first step for identifying the
right system configuration template, splitting APS processes into separate bundles, and
stopping unnecessary processes.
● Monolithic APS uses significantly less resource allocation than required for complex
product workflows.
● Processes are labor intensive.
● It is recommended to use the Configuration Wizard in 4.3, if it is available.
APS Configuration Key Points
● Sufficient heap space to the APS is the single biggest performance factor.
● For response-time-critical applications, the older generation parallel garbage collector is
recommended.
● SAP JVM is new to SAP BusinessObjects customers.
● Performance tests help you to determine whether to switch to —XX:
+UseConcMarkSweepGC.
● Version 4.3 uses Parallel Old garbage collector.

Allocating sufficient heap space to the APS is the single biggest performance factor in a high
performing BI environment. Starving an APS for memory can cause out-of-memory errors or
significant performance degradation, due to the swapping of memory to disk.
If you have granted the APS memory up to maximum heap, you have made a significant
commitment. Take resizing out of the equation and right-size the JVM.
SAP JVM documentation states that concurrent mark sweep garbage collector is also
available for use with SAP JVM. For response-time-critical applications, the Parallel Old
garbage collector is recommended. For more information, refer to Additional Information
about Configuring a Deployment.
Starving the APS is the single worst performance problem in BI 4.x. Your system will either
crash with an out-of-memory error, or it will swap to disk, which causes performance to
suffer.
SAP JVM has been in use by SAP NetWeaver applications for many years, but it is relatively
new to SAP BusinessObjects customers.
Setting — Xms and —Xmx to the same value increases predictability by removing the most
important sizing decision from the virtual machine. On the other hand, the virtual machine
cannot compensate if you make a poor choice. By default, they are not set to the same value.
You can utilize performance tests to determine whether or not there are gains to be had from
switching to —XX:+UseConcMarkSweepGC. Key points of this switch are:
● The BI 4 Sizing Companion and System Configuration wizard give you a great starting
point for your deployment.
● Garbage Collection (GC) Logging, while extensive, does not cause a performance impact
because of buffering. However, it does create a lot of files on the file system.
● Version 4.3 uses the Parallel Old garbage collector, which is a big step up from the default
garbage collector that was used in 4.0. To enable this in 4.0, refer to Additional
Information about Configuring a Deployment.
There is a lot of documentation on sizing and configuring the SAP JVM. See Additional
Information about Configuring a Deployment.
BI Server Tiers Optimization: Intelligence Tier

Considerations when Optimizing the Intelligence Tier
● CMS is the “brains” of the entire BI system.
● CMS needs to be tuned.
● Bottlenecks at the CMS level impact every operation.
● Amounts of memory and the number of objects in the cache affect CMS performance.
CMS Tuning
● A bottleneck that occurs in the CMS will cascade throughout the system and cause
performance problems.
● The CMS communicates with the database to update metadata and verify security.
● The CMS saves object metadata in cache.
● Queuing at the CMS level should not occur and can be prevented by an administrator’s
actions.

Lesson: Identifying Factors to Consider when Configuring a Deployment
● CMS performance is affected by the size of its cache memory and by the number of
objects it holds in the cache.
The Central Management Server (CMS) is the brains of the entire BI system. A bottleneck at
the CMS level (or CMS database level) can impact every operation in the entire environment.
The CMS communicates with the database to update metadata and verify security. It uses a
pool of connections, which is configured in the CMC. The CMS must have enough database
connections to run queries in parallel. In older releases, this was set via the command line, but
now the setting can be configured in the CMC. The default setting is 14, but it can be set as
high as 50 per CMS.
Before changing this value, anyone who is using a system database such as Oracle or SQL
Server should speak with their database administrator to ensure that sufficient connections
are available for the CMS cluster.
Different Tuning Parameters for CMS

Consider the following points when preparing to configure the CMS:
● The CMS saves object metadata in cache, because reading from memory is significantly
faster than reading from a database.
● Between XI 3.1 and BI 4, the default was increased by a factor of ten, from 10,000 to
100,000.
● The sizing guide mentions that a CMS uses over 1 gigabyte of memory. This assumption
means that each object is around 10 kilobytes, but could be more or less. For example, a
universe with 3,000 Webi reports linked to it will take more memory than a user account.
● Check the CMC for the number of objects that are in your system database, and consider
increasing the CMS size if the number of objects is over 100,000. It is important to note
that increasing the CMS size will also increase the memory footprint of the CMS.
The other property that impacts CMS performance is the number of objects that are held in
memory (cache). In prior versions of the product, this value was configured at 10,000, which
quickly resulted in the CMS swapping objects in and out of cache. In newer releases, such as
BI 4.3, the value defaults to 100,000. A higher value means that there is higher memory
consumption in the CMS.
You can check the metrics view of the CMS to identify how many objects are in the CMS
cache at any given time. This view will also show how many objects there are in total in the
system database. Few objects make it unlikely that you would need to increase the value for
the CMS cache, but if you have a million (or more) objects in the CMS system database, it is
worth increasing the value. The setting can be configured on the command line, as such: -
maxobjectsincache 250000.
Supporting Information for Planning Deployments

The BI Pattern Book offers helpful suggestions for a successful deployment. A pattern book is
a step-by-step instructional guide to an actual deployment that was documented as precisely
as possible. The objective of a pattern book is to give a live example of a successful
deployment and how it was technically achieved.
Benefits of Referring to a Pattern Book
● You can study the system topology, network components, servers, and connections.

● You can follow the detailed, step-by-step setup and deployment instructions for each
software component.
● It details the multivariate considerations of the deployment, including hardware, operating
system, and software, all the way down to the smaller components of versions, patches,
user accounts, and network domains.
● It notes deployment failures and solutions to these failures.
For more information about the BI Pattern Books, refer to Additional Information about
Configuring a Deployment.
Additional Information about Configuring a Deployment

Best Practices for SAPBO BI 4.0 Adaptive On the SAP Community Network, search for
Processing Servers the title.
Configuration and Setup of SAP JVM On the SAP Help Portal, search for the title.
Improve BI 4.0 P&R by using Java’s Parallel On YouTube, search for the title.
Garbage Collector
LESSON SUMMARY

Unit 3
Learning Assessment
1. When planning the deployment, which factors are important?

X A Installing the product as quickly as possible.
X B Designing a backup and fail-over strategy.
X C Customizing the application to meet business requirements.
X D Considering server architecture, clusters, and tiers.
2. Web Servers for BI 4 are part of the Processing tier.

X True
X False
3. How does SAP recommend clustering nodes in your solution, and why?
X A Nodes should be clustered horizontally, because this form of node clustering helps
improve the user experience.
X B Nodes should be clustered horizontally, because this form of node clustering

improves balance and fault tolerance.
X C Nodes should be clustered vertically, because this form of node clustering helps
X D Nodes should be clustered vertically, because this form of node clustering


4. How does SAP recommend splitting the tiers in your solution, and why?
X A Tiers should be split horizontally, because this configuration helps improve the
user experience.
X B Tiers should be split horizontally, because this configuration improves balance and
fault tolerance.
X C Tiers should be split vertically, because this configuration helps improve the user
experience.
X D Tiers should be split vertically, because this configuration improves balance and
fault tolerance.
5. Which of the following statements are true?

X A To modify an installation file, the administrator makes changes directly in the file
located in the default installation directory.
X B When installed, BI 4.x is already enabled to connect to MS Sharepoint and SAP

Enterprise Portal.
X C The administrator should back up the entire system before attempting an upgrade.
X D In the event of a problem, the administrator should restore the system by

uninstalling a patch.
6. Why would you increase the CMS connection pool and maximum number of objects in
CMS cache?
X A To hold more object metadata in cache, rather than disk.
X B To reduce the memory footprint of the CMS.
X C To avoid queuing at the CMS level, thus avoiding bottlenecks.
X D To bypass security checking during metadata update.

Unit 3
1. When planning the deployment, which factors are important?

X A Installing the product as quickly as possible.
X B Designing a backup and fail-over strategy.
X C Customizing the application to meet business requirements.
X D Considering server architecture, clusters, and tiers.
2. Web Servers for BI 4 are part of the Processing tier.

X True
X False
3. How does SAP recommend clustering nodes in your solution, and why?
X A Nodes should be clustered horizontally, because this form of node clustering helps
X B Nodes should be clustered horizontally, because this form of node clustering

X C Nodes should be clustered vertically, because this form of node clustering helps
X D Nodes should be clustered vertically, because this form of node clustering


4. How does SAP recommend splitting the tiers in your solution, and why?
X A Tiers should be split horizontally, because this configuration helps improve the
user experience.
X B Tiers should be split horizontally, because this configuration improves balance and
fault tolerance.
X C Tiers should be split vertically, because this configuration helps improve the user
experience.
X D Tiers should be split vertically, because this configuration improves balance and
fault tolerance.

X A To modify an installation file, the administrator makes changes directly in the file
located in the default installation directory.
X B When installed, BI 4.x is already enabled to connect to MS Sharepoint and SAP

Enterprise Portal.
X C The administrator should back up the entire system before attempting an upgrade.
X D In the event of a problem, the administrator should restore the system by

uninstalling a patch.
6. Why would you increase the CMS connection pool and maximum number of objects in
CMS cache?
X A To hold more object metadata in cache, rather than disk.
X B To reduce the memory footprint of the CMS.
X C To avoid queuing at the CMS level, thus avoiding bottlenecks.
X D To bypass security checking during metadata update.

UNIT 4 Deployment Design and Sizing
Lesson 1
Designing an SAP Business Intelligence Deployment 99
Lesson 2
Designing a Scalable System 103
Lesson 3
Preparing a Sizing of a BI Platform Deployment 109
UNIT OBJECTIVES
● Describe factors that influence BI platform deployment design

● Identify factors that influence scalability and capacity
● Define the sizing process
● Analyze the sizing capacity of system servers
● Analyze the sizing requirements of system components
● Describe factors that influence scaling
● Identify the uses of Configuration Intelligence
● Identify the uses of the BI 4 Sizing Guide
● Identify the uses of BI Virtualization
● Identify backend BW systems sizing guidelines
● Perform an initial sizing of a deployment

Unit 4: Deployment Design and Sizing

Unit 4
Lesson 1
Designing an SAP Business Intelligence
Deployment
LESSON OVERVIEW
This lesson describes the role of system resources in the BI platform and the aspects of
system resources you should consider when you design a BI deployment.
LESSON OBJECTIVES
Intensive I/O in BI Platform

Reasons for I/O Intensity in the BI Platform
BI is Input/Output (I/O) intensive for the following reasons:
● Stresses to I/O are even more critical and harder to measure than the effects to CPU or
RAM.
● Aggregating millions of rows is very different from streaming transactions.
● Spiky loads make estimation even harder when considering a constant load versus peak
times.
● I/O concerns underscore the importance of understanding the workload before you start.
Use of All System Resources

System Resources in BI
BI is designed to use all system resources. Note the following information about system
resources:
● Real enterprise systems are “resource-greedy” for performance, like MS Exchange.

● No real reason exists to restrict resource usage for each system.
● Throttling outside the machine is done by vLANs, QoS, and storage tiering.
Evolution of SAP BI 4.x Architecture

SAP BusinessObjects Enterprise 3.1 Architecture
SAP BusinessObjects Enterprise 3.1 had the following characteristics:
● The entire BI Suite was squeezed into a 32–bit architecture.

● It was a collection of applications with their own connectivity stacks.
BI 4.x Architecture
BI 4.x is entirely different from 3.1. Note the following information:
● It is designed as 64-bit architecture.

● It takes advantage of modern hardware and RAM (64-bit addressing).
● It can “stretch out” and is no longer artificially limited for resources.
● The components share a new common Semantic Layer for data connectivity.
● BI 4.x is a first-class and highly integrated SAP client for BI.
● It is bigger because it includes new services and applications.
● It uses a modern infrastructure. Do not expect it to run on the same hardware.
Comparison of Homogeneous System with Heterogenous System

Considerations When Scaling Up
The following are considerations when scaling up:
● Scaling up has limits, but modern hardware is too powerful to host only single processes.
● Five instances of Web Intelligence on a machine might make sense, but watch out for
bottlenecks such as Disk I/O.
● If you schedule SAP Crystal Reports to run mostly at night, Crystal Reports job servers and
Processing servers might co-exist with Web Intelligence.
Considerations When Scaling Out

The following are considerations when scaling out:
● Virtualization enables easier scale-out, because there is little to no incremental hardware

cost.
● Design principles for scaling out are no different from other enterprise software.
● When scaling out, you might not need servers with vast system resources, because each
server will handle part of the overall load.
Role of External Systems

Invisible Effects of Poorly Provisioned Databases
The following are the invisible effects for poorly provisioned databases:
● CMS DB latencies have cascading effects.

● I/O bottlenecks have severe impacts:
- Starving a BI system for I/O will guarantee poor performance.
- A slow file server hosting the FRS can also impact performance.
● All SAP BW systems should be patched:

Lesson: Designing an SAP Business Intelligence Deployment
- Incremental performance gains can be significant.

- Poorly performing Webi documents can often be traced back to a lack of BW patches.
● Ensure virtualization hosts can handle aggregate requirements.
● Putting five processing server VMs on one host means the host must have at least five
times the I/O capability and five times the RAM.
Management and Intelligence Tiers

Considerations for Servers in the Management and Intelligence Tiers
The following are considerations for servers in the management and intelligence tiers:
● CMS:
- Each instance of a CMS can handle 400 to 500 heavy users.
- Add another CMS for every 500 active concurrent user.
- The best practice is to maintain only one CMS on a physical system, which enables fault
tolerance and effective load balancing.
● FRS:
- FRS performance is dependent on disk I/O.
- Input FRS should be kept close to processing servers as a best practice.
- Setting Instance Limits is essential for optimal output FRS performance.
Considerations for Databases in the Management and Intelligence Tiers

The following are considerations for repository databases in the management and intelligence
tiers:
● System and audit databases should be kept close to the CMSs.

● If monitoring is enabled, the trend database should also be kept close.
● The best practice is not to choose all servers for monitoring, because that approach can
negatively impact performance.
Key Points to Consider for the Management and Intelligence Tiers

The following points are the most important things to understand:
● File repository servers need to be hosted on an NFS that is physically near the BI Platform
(but not on it).
● Likewise, the CMS and audit databases should be physically close, but not on the BI
Platform.
● This configuration reduces the amount of parallel I/O on a single host by distributing the
handling of requests to other processors.

Additional Information about Factors that Influence BI Platform Deployment

Design
ra the title.
LESSON SUMMARY

Unit 4
Lesson 2
Designing a Scalable System
LESSON OVERVIEW
This lesson describes the factors that influence scalability and capacity in a BI system and
discusses the design tradeoffs to consider when you design a BI system.
LESSON OBJECTIVES
Scalability Definition
Scalability is the capacity of a system to address additional system load, by adding resources
without fundamentally altering the implementation architecture or implementation design.
Scalability Objectives
When building a scalable system, the main objective is to achieve a linear relationship
between the amount of resources added and the resulting increase in performance, while
maintaining the speed of the transactions after additional users are added and more requests
need to be processed.
Methods for Scaling

There are two methods of scaling the SAP BusinessObjects BI platform: vertical and
horizontal.
● Vertical Scaling
Vertical scaling, also referred to as scaling up, is the ability to improve system
performance by taking advantage of the hardware on a single server. Adding memory to
the machine on which the Web Intelligence Processing Server is running, to improve
performance, is an example of vertical scaling.
● Horizontal Scaling
Horizontal scaling, also referred to as scaling out, is the ability to improve system
performance by adding computers to the same enterprise solution. Adding a new machine
to the enterprise system and configuring additional Crystal Reports Processing Server
services on it, which improves performance, is an example of horizontal scaling.
Depending on your situation, you can run all services on one machine or you can run them on
separate machines. For example, you can run the Central Management Server and the Event
Server on one machine, while you run the Adaptive Processing Server on a separate machine.
The same service can also run in multiple instances on a single machine.

Scalability Goals for the BI Platform

Considerations When Scaling a System
When scaling your system, it is important to understand the general considerations for
system scalability and how each of the SAP BusinessObjects BI platform servers is
responsible for particular aspects of your system.
● You can scale a system to improve the following functions:

- Increase overall system capacity.
- Increase schedule reporting capacity.
- Increase on-demand report viewing capacity.
- Increase interactive report viewing capacity.
- Configure a Web farm for load balancing to improve Web response speeds.
- Optimize custom Web applications to improve Web response speeds.
This section focuses on the different aspects of your system’s capacity, discusses the
relevant components, and provides a number of ways in which you can modify your
configuration accordingly.
External Factors that Affect Scalability and Performance

The overall performance and scalability of SAP BusinessObjects BI platform can be affected
by external factors. When thinking about the overall performance and scalability of SAP
BusinessObjects BI platform, remember the following points:
● SAP BusinessObjects BI platform depends upon your existing IT infrastructure.
● SAP BusinessObjects BI platform uses your network for communication between servers
and for communication between SAP BusinessObjects BI platform and client machines on
your network. Make sure that your network has the bandwidth and speed necessary to
provide SAP BusinessObjects BI platform users with acceptable levels of performance.
● SAP BusinessObjects BI platform processes reports against your database servers. If your
databases are not optimized for the reports you need to run, the performance of SAP
BusinessObjects BI platform could suffer.
● The way in which your network is configured, and the third-party tools that are used in
correlation with SAP BusinessObjects BI platform, could affect the performance of SAP
BusinessObjects BI platform.
Overall System Capacity

Improvements to System Capacity By Using Clustering
As the number of report objects and users on your system increases, you can increase the
overall system capacity by clustering two or more Central Management Servers (CMSs). You
can install multiple CMS services on the same machine. However, to provide server
redundancy and fault tolerance, it is recommended that you install each cluster member on
its own machine.
CMS clusters can improve overall system performance because every SAP BusinessObjects
BI platform request results, at some point, in a server component querying the CMS for

Lesson: Designing a Scalable System
information stored in the CMS database. When you cluster two CMS machines, you instruct
the new CMS to share in the task of maintaining and querying the CMS database.
Clustering helps improve system capacity in the following ways:
Scheduled Reporting Capacity

Improved Capacity of Scheduled Reporting
All reports (Crystal reports and Web Intelligence reports) that are scheduled are processed
by a job server. You can expand the SAP BusinessObjects BI platform by running individual
job servers on multiple machines.
Note:
The Web Intelligence processing server is added because it is responsible for
scheduling the physical processing of a Web Intelligence document.
If the majority of your reports are scheduled to run on a regular basis, there are several
strategies you can adopt to maximize your system’s processing capacity:
● Install all Adaptive Job servers and Adaptive Processing servers in close proximity to (but
not on the same machine as) the database server against which the reports run. Ensure
that the File Repository servers are readily accessible to the installed services (so you can
send a read report objects request from the Input File Repository server, and send a
request to write report instances to the Output File Repository server, quickly). Depending
on your network configuration, these strategies may improve the processing speed of your
scheduled documents, as there is less distance for data to travel over your corporate
network.
● Verify the efficiency of your reports. When designing reports in Crystal Reports, there are a
number of ways in which you can improve the performance of the report itself. You can do
this by modifying record selection formulas, using the database server’s resources to
group data, incorporating parameter fields, and so on.
● Use event-based scheduling to create dependencies between large or complex reports.
For instance, if you run several very complex reports on a nightly basis, you can use
Schedule events to ensure that the reports are processed sequentially. This is a useful way
of minimizing the processing load that your database server is subject to at any time.
● If some reports are much larger or more complex than others, consider distributing the
processing load through the use of server groups. For instance, you might create two
server groups, each containing one or more Adaptive Job servers. When you schedule
recurrent reports, you can specify that it be processed by a particular server group to
ensure that especially large reports are executed by more powerful servers.
● Increase the hardware resources that are available to your scheduling services. If the
server is currently running on a machine along with other SAP BusinessObjects BI platform
components, consider moving the server to a dedicated machine. If the new machine has
multiple CPUs, you can install multiple Adaptive Job and Adaptive Processing servers on
the same machine (typically no more than one service per CPU).

Report Viewing Capacity

Improved Capacity of Report Viewing
When you provide many users with View On-Demand access to reports, you allow each user
to view live report data by refreshing reports against your database server. For most
requests, the Crystal Reports Processing server retrieves the data and performs the report
processing, and the Crystal Reports Cache Server stores recently viewed report pages for
possible reuse. If users use the Advanced DHTML viewer, the Report Application Server
(RAS) processes the request. If users use Web Intelligence, the Web Intelligence Processing
server processes the request. If your reporting requirements demand that users have
continual access to the latest data, you can increase capacity in the following ways:
● Increase the maximum allowed size of the cache for Crystal Reports.
● Verify the efficiency of your reports. When designing reports in Crystal Reports, there are a
number of ways in which you can improve the performance of the report itself by
modifying record selection formulas, using the database server’s resources to group data,
incorporating parameter fields, and so on. The efficiency of the design of your universes
impacts the processing speed of Crystal Reports.
● Increase the number of Crystal Reports Processing servers that serve requests on behalf
of any single Crystal Reports Cache server. You can install additional Crystal Reports
Processing servers on multiple machines.
● Increase the number of Crystal Reports Processing servers, Crystal Reports Cache
servers, Web Intelligence Processing servers, and Connection servers on the system, and
then distribute the processing load through the use of server groups. For instance, you
might create two server groups, each containing one or more Crystal Reports Processing
servers along with one or more RAS. You can then specify individual reports that should
always be processed by a particular server group.
Improved Capacity of Interactive Viewing

When you provide many users with interactive viewing capability, you allow each user to
interact with live data by refreshing reports against your relational database server or OLAP
data source. If your reporting requirements demand users to have continual access and
interactivity with live data, you can increase capacity:
● Verify the efficiency of your reports. When designing reports with Web Intelligence you will
gain the most improvement by carefully investigating the efficiency of the underlying
universe.
● Increase the number of Web Intelligence Processing servers that create, view, and edit
Web Intelligence portal requests.
Web Response Speeds

Considerations for Improving Web Response Speeds
As all user interactions with SAP BusinessObjects BI platform occurs over the web, you may
need to investigate a number of areas to determine exactly where you can improve web
response speeds:
● Assess your Web server’s ability to serve the number of users who connect regularly to the
SAP BusinessObjects BI platform. Use the administrative tools provided with your Web
server software (or with your operating system) to determine how well your Web server

Lesson: Designing a Scalable System
performs. If the Web server is limiting web response speeds, consider increasing the Web
server’s hardware, setting up a “Web farm” (multiple Web servers responding to Web
requests to a single IP address), or both.
● If Web response speeds are slowed only by report viewing activities, you can increase
scheduled reporting capacity and on-demand viewing capacity.
● Take into account the number of users who regularly access your system. If you are
running a large deployment, ensure that you have set up a CMS cluster.
If you find that a single application server (for example, the Tomcat Java Web Application
Server) inadequately serves the number of scripting requests made by users who access your
system on a regular basis, consider the following options:
● Increase the hardware resources that are available to the application server. If the
application server is currently running on the Web server or on a single machine with other
SAP BusinessObjects BI platform components, consider moving the application server to a
dedicated machine.
● Consider setting up two (or more) Java application servers. Consult the documentation for
your Java Web Application server for information on load-balancing, clustering, and
scalability.
● Before you expand your SAP BusinessObjects BI platform, consider some of the following
common aspects of your deployment:
- Assess the Web server’s ability to serve the number of users who regularly connect to
the platform.
- For a large deployment, ensure that you have set up a CMS cluster.
- Determine if an application server is not adequately serving user requests.
- Assess the ability of your system to overcome failure during outages.
Note:
If your deployment requires a higher level of failover and fault tolerance, exceeds
three or more servers, or serves a large number of users who would be severely
affected by any system outage, it is strongly advised that you distribute the load of
the application tier over multiple application servers balanced through a hardware
load balancer. Each application server will connect to any CMS service running in
the cluster, so the failure of one application server would only affect the
application tier, not the processing tier.
Load Balancing Using a Web Farm

A Web farm is a group of two or more Web servers working together to handle browser
requests. Web farms are not currently supported by SAP BusinessObjects BI platform.
However, that is not to say that Web servers will not work together. Some customers have
successfully deployed using Web farms, but it is not a scenario that is tested during the QA
cycle, because a Web server is not required as part of a SAP BusinessObjects BI platform
deployment. For Java environments specifically, there are no known issues with the use of
any Web server proxy components that are supported by the application server vendor or
provider.

Note:
For proxy load balancing, just as with hardware-based load balancing, the use of
sticky sessions is required.
Optimization of Custom Web Applications

The following are examples of information about developing custom desktops or
administrative tools, that can be found in the libraries and APIs of the SAP BusinessObjects BI
platform Software Development Kits (SDKs):
● How to incorporate security and scheduling options

● How to modify server settings in your code to integrate the platform with existing tools
● How to improve performance and implement scalability
● How to make efficient use of the query language
If you are developing your own custom desktops or administrative tools with the SAP
BusinessObjects BI platform SDKs, be sure to review the libraries and APIs. You can, for
instance, incorporate complete security and scheduling options into your own Web
applications. You can also modify server settings from within your own code to further
integrate SAP BusinessObjects BI platform with your existing intranet tools and overall
reporting environment. In addition, be sure to check the developer documentation available
on your SAP BusinessObjects BI platform product CD for performance tips and other
scalability considerations. The query optimization section in particular provides some
preliminary steps to ensure that custom applications make efficient use of the query
language.
Web farms are not supported by SAP BusinessObject BI platform.
Additional Information about Scalability and Capacity

Primary Sizing and Deployment Resources On the SAP Community Network, search for
for SAP BI 4 Sizing and Deploying SAP BI 4 and SAP Lumi-
ra
LESSON SUMMARY

Unit 4
Lesson 3
Preparing a Sizing of a BI Platform Deployment
LESSON OVERVIEW
This lesson describes the details of sizing a BI platform deployment. It discusses sizing
considerations for each type of server at each tier in the BI platform.
LESSON OBJECTIVES
The Sizing Process

Sizing Estimates Using SAPS
The following are considerations for sizing estimates using SAP Application Performance
Standard (SAPS):
● Sizings for versions 3.1 and earlier were conducted using CPU units. As of BI 4.0, CPU units
are deprecated and are no longer used for sizing BI 4.0 and later deployments.
● Using SAPS to provide sizing estimates includes the following benefits:
- Each hardware partner generates the SAPS rating for the systems that they sell. SAPS
ratings, therefore, are always current. There is built in anti-obsolescence.
- SAPS is the unit of measurement used in sizing and is independent of operating
systems.
- Using SAPS for sizing is now consistent with how SAP provides sizing information for
other products like SAP Business Suite.
The SAP SD Standard Application Benchmark Results provide more information about
correctly converting the SAPS into core CPU. Refer to Additional Information about the Sizing
Process to access the information online.

The conversion of SAPS to Core CPU is totally dependent on the hardware used. Your
hardware vendor can also provide the right conversion ratio for their hardware.
The Sizing Process

Because CPU units are deprecated for sizing and each deployment is reliant on SAP hardware
partners, the sizing process of determining the system load and determining the number of
services required are no longer applicable for BI 4.x implementation.
● The following steps are recommended for sizing a deployment:
1. Determine the Active Concurrent Users for each of the BI 4.x Client tools. Examples of
BI 4.x Client tools include Analysis, edition for OLAP, BI Workspace, Crystal Reports
2013, Crystal Reports Enterprise, Dashboards (Dashboard Design), and Web
Intelligence.
2. Work with SAP certified hardware partners using SAPS to secure the required
resources, following the detailed description and guidelines for BI 4.x Services.
SAP Application Performance Standard (SAPS) Definition

● SAP Application Performance Standard is defined as follows:
- SAPS is the unit of measurement used in sizing and is independent of operating
systems.
- Every hardware platform SAP supports has an SAPS value that is calculated by the
hardware partner using the SAP Standard Benchmark Kit.
- Each T-shirt sizing guide describes SAPS in more detail.
Note:
An Active Concurrent User is a user who is actively executing a workflow. In the
benchmarks used to create this standard, all users are active concurrent. No
user is idle, that is, sitting at the BI Launch Pad home page.
Deployment Mapping
Initial Sizing and Mapping
The following are considerations when carrying out the initial sizing and mapping:
● Use the BI 4 Sizing Estimator and Companion Guide to create an initial sizing calculation
using the Sizing Estimator.
● Map out the deployment, noting the following information:
- CMS database is the key to overall performance and scalability of BI Platform.
- Use a dedicated CMS database on its own hardware to ensure performance.
- Monitor individual server tiers to identify bottlenecks.
Scaling Approach
Considerations When Scaling
When scaling out your system, consider the following approach:

Lesson: Preparing a Sizing of a BI Platform Deployment
Methodically build the system out noting the following information:

● Start with a small landscape and increase load in increments of 50 to 200 users. Add
services as needed.
- Immediately jumping to 1,000 users will make root cause analysis impossible.
- Work to ensure CMS DB, all machines, and network capabilities are correctly sized,
configured, and monitored.
● Carefully monitor and analyze performance and resource usage across entire landscape.
- Use the CMS repository database, Web application tier, each SAP BusinessObjects
Enterprise service, and the machine to identify bottlenecks.
● You should always test, collect results, analyze, and then repeat.
● Modify your deployment architecture as necessary before adding users.
Additional Information about the Sizing Process

SAP Standard Application Benchmarks http://www.sap.com/benchmark
Service Capacity Definition

This section contains service capacity as measured against active concurrent users utilizing
each particular service.
Table 4: Service Capacities

Service Name Recommended Maximums
Central Management Serv- 500 active concurrent users per instance.

er
SAP Crystal Reports Cache 400 simultaneous requests per instance.
Server
SAP Crystal Reports Proc- If the maximum simultaneous report jobs metric is set to auto,
essing Server (CR 2020) 1 service per CPU will default to 25 simultaneous requests, ex-
cept single CPU machines, which default to 50. Only configure
1 CR Processing Server instance per machine (unless you are
using server groups).
Web Intelligence Process- 25 simultaneous connections per instance.
ing Server
Web Application Server 100 simultaneous requests per core for Java viewer. 50 simul-
taneous requests per core for HTML viewer.
Web Application Server

Below are the suggested settings for some of the Web servers.

Table 5: Web Application Server Applications

Web Application Server Java Heap Recommended Settings
Tomcat 9 Change the JVM Heap size in the 'Java Options' box. Add the
line '-XX:MaxPermSize=256m' Fill out the Maximum memory
pool field with the host machine's memory (such as, 1024).
Oracle WebLogic Server -Xms1024m -Xmx1024m -XX:MaxPermSize=512m
SAP Netweaver Java Appli- Use default settings for SAP NetWeaver
cation Server
IBM WebSphere Applica- Use default setting for WebSphere CE 2.0

tion Server
JBoss EAP -Xms128m -Xmx512m -XX:MaxPermSize=256m
Database Performance Criteria

Some terminology is necessary to understand how database access may be optimized:
● Lock
Locks are used to control concurrency in a database. When a process locks a row or table,
no other process can access it until the lock is released. Lock granularity is the level at
which a lock is requested (that is, row or table level).
● Deadlock
A deadlock occurs when two or more processes conflict in such a way that each must wait
for the other to release its lock to complete.
● Lock wait
A lock wait occurs when a process must wait for another process to release a lock on a row
or table.
● Lock escalation
A lock escalation occurs when the number of locks on rows or tables in the database
equals the maximum number of locks specified in the database configuration settings.
Criteria for Avoiding Common Performance Database Bottlenecks

Meeting the following five criteria helps to avoid the most common performance bottlenecks:
● The database system cache hit rates are over 90%.

● The optimizer statistics are not older than 24 hours.
● Lock granularity is row locking.
● There are no lock escalations.
● There is no wait time associated when the system writes to log files. The average queue
length from disk write to the disk drives that contain the database log files is smaller than
five.

Note:
For additional information, refer to Additional Information about Analyzing the
Sizing Capacity of Server.
Table 6: 90% or Higher Cache Hit Rates

90% or higher cache hit
rates
Offers: ● A relatively low number of physical disk reads and writes.

● A relatively low number of SQL compiler executions.
Are important to avoid: ● Disk access being unable to keep up with the level of I/O
that the database server requests.
● Long disk read or disk write queues.
● Unnecessary SQL statement compilations or long SQL
statement compilation times.
Are achieved by: ● Providing sufficient physical memory.

● Configuring sufficient cache sizes.
Table 7: Up-to-Date Optimizer Statistics

Up-to-date optimizer sta-
tistics
Offers: ● Good selectivity estimates of predicates in SQL expres-

sions, especially for expressions including columns with un-
equal or skewed dispersal of column values.
Are important to avoid: ● Long response times and low throughput.

● Long execution times for queries.
● Full table scans.
● Lock escalations.
● Lock waits or deadlocks.
● Significant differences between the estimated number of
rows for each operator in the query plan from the actual
number of rows.

Up-to-date optimizer sta-

tistics
Are achieved by: ● Implementing a procedure to periodically update the statis-

tics or to update the statistics after frequent changes to the
database.
● Creating statistics for tables, columns, and indexes that are
not stale.
● Setting the sample size (percentage of data that is analyzed
to gather statistical information) to a value that is sufficient
for the skewed data dispersal.
● Setting the number of histogram buckets to a value that is
sufficient for the skewed data dispersal.
Table 8: Lock Granularity Is Row Locking

Lock granularity is row
locking
Offers: ● Increased concurrent execution of transactions.

● Reduced transaction processing time due to fewer lock
waits.
Table 9: Lock Granularity is Row Locking

Lock granularity is row
locking
Are important to avoid: ● Lock waits

● Deadlocks
Are achieved by: ● Setting the lock granularity of your database to row level.
Table 10: No Lock Escalations

No lock escalations
Offers: ● Increased concurrent execution of transactions.

● Deadlocks

No lock escalations
Are achieved by: ● Configuring a sufficient size of the lock list.

● Setting the lock escalation threshold to an appropriate level.
● Keeping the optimizer statistics up to date.
Table 11: No Log Write Waits

No log write waits
Offers: ● Reduced transaction processing time due to no I/O waits.

● Deadlocks
Are achieved by: ● Providing an I/O subsystem with sufficient throughput.

● Providing a Disk Controller Cache and setting the Disk Con-
troller cache to 100% write cache.
Using Quick Sizer

Quick Sizer is the online sizing tool of SAP. The tool helps prospects, customers, and
hardware vendors to:
● Speed up hardware planning phase by asking structured questions relating to usage of
business processes that might affect sizing.
● Facilitate tendering procedure by including links to hardware vendors, so that they can
make an offer based on the information provided in the tool.
● Provide content for the going-live check to analyze if the hardware is sufficient to smoothly
run SAP software.
Hint:
Keep in mind that Quick Sizer is a tool for initial sizings only. Post going-live
sizings are out-of-scope, such as upgrade or resizing (except delta sizing of a
new SAP solution), configuration, landscaping, and customer coding.

Figure 37: Quick Sizer
Note:
For more information about the principles of sizing and the theoretical
background of SAP sizing initiative, see the background sizing document at:
service.sap.com/sizing Sizing Guidelines → General Sizing.
Figure 38: Quick Sizer Tool
Server Intelligence Agent

The following are functions of the Server Intelligence Agent (SIA):
● One SIA is required to run on each machine, regardless of CPU configuration.

● The SIA maintains server status according to the settings you specify in the CMC.

● It processes the CMC requests to start, stop, monitor, and manage all servers on the node.
● It also monitors potential problems and automatically restarts servers that have shut down
unexpectedly.
● The SIA ensures optimal performance by continually monitoring server status information,
which is stored in the CMS database.
● When you change server settings or add a new server in the CMC, the CMS notifies the
SIA, and the SIA performs the task.
● Only RAM memory consideration is required to maintain the execution of SIA. The
recommended RAM memory is 350 MB.
Central Management Server

The principle component of the SAP BusinessObjects BI suite 4.3 system is the Central
Management Server CMS).
Responsibilities of the CMS

The primary responsibilities of the CMS include (but are not limited) to the following:
● Management of users and user groups

● Management of object security
● Central system configuration
● Management of scheduled tasks
● Management of historical tasks (such as successful or failed instances)
● Management of system objects (such as Info Objects)
● License management
● System database management
● Name service
● Cluster management
General Considerations
The CMS manages many areas. The state of various activities persists in the CMS repository.
This is what enables multiple CMSs to run in a cluster, as well as providing for fault tolerance.
The CMS depends heavily on the repository for the proper functioning of BI 4.0. Therefore, it
is imperative that the DBMS, where the repository resides, is tuned and running on a machine
with sufficient capacity (memory, CPU, fast disk, and network bandwidth) and reliability.
Stated another way, if access to the repository database is slow or the reliability is in question,
then the BI 4.0 deployment will not deliver maximum performance and reliability. This also
means network throughput between any node running a CMS and the repository database
must not endure the effects of other heavy traffic (such as backups running during production
hours). This cannot be overstated.
Note:
The recommended maximum number of CMS services in a cluster is 4. The best
balance of CMS performance and network traffic occurs with this number.

CMS Clustering Considerations
● A cluster can have two or more CMS clusters on different subnets.

● It is important to eliminate excessive latency between CMS services and the CMS
database.
● All CMS members of a cluster must have uniform communication speeds to the system
database.
● The number of cores required to support CMS services is highly dependent on the type of
CMS activity.
● For best performance, run each CMS cluster member on a machine that has the same
amount of memory.
A cluster that has two or more CMS clusters on different subnets is technically possible and
has been QA tested. This configuration is supported by SAP, strictly providing that it does not
create significant additional network latency as a result of an additional subnet.
The most important factor to ensure efficient CMS clustering performance is to eliminate
excessive latency between CMS services and the CMS database. For example, CMS1 and the
CMS system database are located in the same data center in New York. CMS2 is a member of
the same cluster as CMS1, but it is located in China and must communicate with the CMS
database in New York. Excessive network latency of CMS2 in China to the CMS database in
New York would be problematic.
Make sure that all CMS cluster members have uniform communication speeds to the system
database.
Note:
For best performance, run each CMS cluster member on a machine that has the
same type of CPU, same operating system, same amount of memory and so on.
The machines should be as similar as possible to ensure uniform performance.
Processor Requirements
The number of cores (and, by association, SAPS) required to support CMS services is highly
dependent on the type of CMS activity. For example, large updates to the CMS system
database (that is, adding or deleting many users; viewing or querying many objects) will use
significant CPU time. For increased CMS throughput and response times, allocate additional
CPU resources.
Memory Requirements
For best performance, run each CMS cluster member on a machine that has the same
amount of memory. Memory usage is controlled (roughly) by the number of objects stored in
the object cache. You can accomplish this by using the –MaxObjectsInCache command in the
properties of the CMS. You can set the desired number of InfoObjects to be cached. It is
recommended you set it to 500000 to 1000000.
Note:
The official syntax would be –MaxObjectsInCache 500000.

This specifies the maximum number of objects that the CMS stores in its memory cache.
Increasing the number of objects reduces the number of database calls required and greatly
improves CMS performance. The memory restrictions that existed in earlier versions with
respect to the number of objects in cache has been removed.
SAP Crystal Reports Cache Server

The Cache server stores report pages generated by the Processing server. By storing report
pages in cache, it is no longer necessary to access the Processing server and database server
each time the report is requested. The Cache server is used for viewing of SAP Crystal
Reports only, and if viewer preference is set to any viewer other than Interactive DHTML.
When a report is requested for viewing, the system will first check the Cache server to see if
there are any current available cache pages generated for that report. If there are pages, the
Cache server will send available report pages to the Web Application server. If there are no
cached pages, the Cache server will request a Processing server to generate these pages.
The threshold that determines the number of Cache server services required is the maximum
simultaneous processing threads per Cache server service. The number of simultaneous
processing threads is equal to the number of simultaneous requests.
Parameters for the SAP Crystal Reports Cache Server

Set the parameters for the SAP Crystal Reports Cache Server in the CMC.
Note:
For parameters that affect the caching of user data, make sure that the interval
length is no longer than the shortest interval for refresh of any referenced data
source. The oldest on-demand data settings will ensure that data is kept in cache
no longer than the set interval, no matter how often the cached data is referenced.
Make sure that any properties that apply to both the SAP Crystal Reports Cache server and
SAP Crystal Reports Processing server are set to the same respective value.
Table 12: SAP Crystal Reports Cache Server Parameters

Option Values Behavior Recommended Set-
tings
Oldest On-Demand Seconds Specifies the amount Default value is 0 sec-

Data Given to Clients of time that the serv- onds – which means
er uses cached data that ODD is disabled.
to meet request from Recommended set-
on-demand reports ting is 300000.
Viewer Refresh Al- On or Off Control caching ef- ON

ways Yields Current fectiveness
Data
Share Report Data On or Off Control caching ef- ON

Between Client fectiveness
Disk Requirements
For the Cache server service, it is recommended that sufficient hard drive disk space be
available for the generation of cache files, as well as in the temp directory for the creation of

temp files (located in %DefaultDataDir%/CrystalReportsCachingServer/temp). The location

of Cache server cache files can be specified from the Central Management Console. The
highest volume of cache files will likely be the encapsulated page file or .epf. A single .epf file
represents one page of a Crystal Report. The size of the individual file is variable, depending
on the complexity of the report page. For example, a single .epf file from the sample
Statement of Account report is 88kb size. Make sure that there is enough disk space available
to support all potential cache pages generated at a given period.
File Repository Servers (FRS)

There is an Input and an Output File Repository Server (FRS) in every SAP BusinessObjects BI
suite 4.0 implementation.
The Input File Repository Server manages the underlying report files, agnostic documents,
and other file content that remains on disk.
File Repository Servers (FRSs): Examples of Content Files

The following are examples of content files managed by the FRS:
● SAP Crystal Reports 2020

● Enterprise reports
● Analysis edition for OLAP reports
● Web Intelligence reports
● Program objects
● Microsoft Excel, Word, and PowerPoint files
● Adobe Acrobat PDF files
● Rich text format files
● Text files
● Hyperlinks
● Object packages
These files are published to the system by administrators or end users. Publishing Wizard, the
Central Management Console, or a SAP BusinessObjects designer component, such as SAP
Crystal Reports or the Web Intelligence Java or HTML Report Panels, are used to facilitate
publishing.
The Output FRS maintains all the instances that have been produced from reports (SAP
Crystal Reports or Web Intelligence), programs, and object packages that have been
scheduled.
Considerations About FRSs

The following are considerations when using the FRS:
● Multiple FRSs can exist on different machines for high availability.

● One Input FRS and one Output FRS are required.
● Input and Output FRSs do not have to reside on the same machine.

● The FRSs require higher I/O resources (faster disks and network) and fewer CPU
resources.
● The first available FRS is active. All other FRSs are passive, unless the active FRS becomes
unavailable.
● FRSs have little impact on system memory.
● Enough disk space must be available to store files.
Repository Location
You could have multiple FRS (input) and FRS (output) services on one or several different
machines to support a high-availability environment. However, the FRS services will behave in
an active or passive fashion, where the first available FRS will be active and all other FRS
services will remain passive, unless the active FRS becomes unavailable. The Input and
Output repositories do not have to reside on the same machine. The location of the FRS
repositories is managed through the CMC in the Servers section under the Properties tab.
Table 13: Parameters for the FRS

Option Values Behavior Recommended Set-
tings
Maximum Idle Time Minutes This setting limits the Default value is 20.
length of time that Note: Setting a value
the server waits be- too low can cause a
fore it closes inactive user request to be
connection. closed prematurely.
Setting a value too
high can cause exces-
sive use of system re-
sources such as proc-
essing and disk
space.
Calculate Number of FRS Required

One of each Input and Output FRSs are required. In larger deployments, there may be
multiple Input and Output FRSs, to ensure server redundancy. In this case, all Input FRSs
must share the same directory. Likewise, all Output FRSs must share a directory.
The FRSs require higher I/O resources (faster disk, network) and fewer CPU resources. When
estimating resource requirements in the SAP BusinessObjects BI platform, the FRSs are not
considered.
Memory Requirements
The FRSs have little impact on system memory.
Disk Requirements
Enough disk space must be available to store files. We recommend a fast disk for both the
input and output FRS file systems, especially for high volume publications. Typically, the
Output FRS will require more disk space than the Input FRS. The Output FRS maintains all the
instances (with Saved Data) that have been produced from reports (Crystal or Web

Intelligence), programs, and object packages that have been scheduled, As a result, they
require proportionately more disk space. For both the Input and Output FRS, the amount of
space required varies from system to system, however, knowing the average file size and
multiplying this by the number of projected instances assists in estimating total disk needs.
Adaptive Job Servers

Processor and Disk Considerations for Adaptive Job Servers (AJSs)
The Web Intelligence Job Service has a comparable function to the SAP Crystal Reports Job
Service in that it is responsible for handling Scheduled Jobs. However, the Web Intelligence
Job Service does not actually process reports. It only acts as a scheduling manager or router,
sending jobs to be processed by the Web Intelligence Processing Server.
Disk Requirements
For the Web Intelligence Job Server service, sufficient hard drive disk space should be
available in the temp directory for the creation of temporary files during report processing.
The data from the database server is stored in these files until it can be saved and
compressed in the report.
Adaptive Job Server SAP Crystal Reports Job Service Requirements
● The following are requirements for the AJS SAP Crystal Reports job service:
- Memory Requirements
Depending on the design of a report, the number of records retrieved from the
database, memory requirements can vary. When a report is executing and loaded into
memory, the report is decompressed and expanded up to as much as 40 times the
original report file size (with saved data and retrieved records).
- Disk Requirements
For an SAP Crystal Reports job service, sufficient hard drive disk space should be
available in the temp directory for the creation of temporary files during report
processing. The data from the database server is stored in these files until it can be
saved and compressed in the report. Hard-drive access speed to the temp directory
could have an impact on the speed at which a report processes.
Overview of Adaptive Servers

Adaptive Processing Server (APS) and Adaptive Job Servers (AJS) are Java host containers
that run other services. The APS is for on-demand processing and the AJS is for delegating
the processing for scheduled jobs. The APS can host one or more of the following services:
Search Service, Client Auditing Proxy Service, MDAS, DSL Bridge Service, CVOM, Publishing
Post Processing Service, and Publishing Service.
Services Hosted by the Adaptive Job Servers (AJSs)
● An AJS can host one or more services. The following service are some that might be
included:
- Destination Delivery Scheduling Service
- Publication Scheduling Service

- Program Scheduling Service

- Program Scheduling Service
- Replication Service
- SAP Crystal Reports Job Service
- LOV Job Service
- Web Intelligence Job Service
- Destination Configuration Service
This is not an exhaustive list.
Note:
The DSL Bridge Service that runs in the APS is used by any BI 4.3 client tool that
accesses BW data via the transient universe. It is important to note that the APS
and AJS are not the same as the Java components of SAP Crystal Reports
Enterprise and the other products (such as the SAP Crystal Reports Processing
Server).
Parameters for the Adaptive Processing Server
Table 14: APS Parameters

Option Behavior Recommended Setting
Log level Default setting is “Unspeci- Recommended to leave as

fied”. Changing this to a high- “Unspecified”.
er logging level will increase
Other values are:
the amount of disk space
consumed, which can grow ● None
large (that is, setting this at a
higher level on a production
● Low
system that will also impact ● Medium
performance). Only increase
the log level when trouble- ● High
shooting.
Consult the Administrator
Guide for more information.
-Xmx1024M This command line flag will Enables the server to handle
increase the server heap size. more requests. Ensure that
A 1 GB heap size is recom- you have sufficient free mem-
mended unless otherwise ory at peak before increasing
noted – check the specific this value. Note that certain
sections below for excep- clients, like Analysis edition
tions. for OLAP, may recommend a
4GB heap size for an APS
running the MDAS service.

For APS instances running publication services, SAP recommends having 1 APS instance for
every 3 concurrent publications.
For small deployments (running a dozen or fewer users) like development systems, small
demo systems or sandbox systems where performance is not critical, you can run multiple
types of services in a single APS.
For medium to large deployments, it is a general recommendation that an APS instance hosts
only one service for those services that are critical to performance, and that you will need to
scale out as capacity is added. For example, you would not have one APS instance hosting the
CVOM and DSL Session Service — you would have at least one for each. The memory
requirements of some of the services hosted by the APS can be large. By separating services
across APS instances (and nodes), you gain better manageability for memory and scalability
considerations.
Web Intelligence Processing Server

The Web Intelligence Processing Server is used to create, edit, view, and analyze Web
Intelligence documents (stored in the Input and Output FRS). It also processes scheduled
Web Intelligence documents and generates new instances of the document, which it stores on
the Output File Repository Server (OFRS). Depending on the user access rights and the
refresh options of the document, the Web Intelligence Processing Server will use cached
information, or it will refresh the data in the document and then cache the new information.
Web Intelligence Processing Server Requirements
● The following are requirements for the Web Intelligence Processing Server:
- Processor Requirements
The Web Intelligence Processing Server will expand to as many CPUs as needed by
scaling-up the number of Web Intelligence Server services. It can also process several
documents in parallel, so only one Web Intelligence report server is required per
machine as a starting point.
- Memory Requirements
Depending on the design of a report, the types of actions being performed (view,
modify, refresh) and the memory requirements will vary. A refresh request demands
the greatest amount of memory for a Web Intelligence document, because the
database is queried and the entire data set will be transferred to the Web Intelligence
server.
When using several large documents, it is not necessary to increase the number of Web
Intelligence Processing Server instances to more than one per machine, because in BI
4.3 the platform and all services are native 64 bit. You can create more than one Web
Intelligence Processing Server instance per machine for tuning reasons not related to
memory.
Load balancing between the Web Intelligence Processing servers is handled by the CMS
services automatically.
SAP Crystal Reports Processing Servers

Types of Processing Servers
Note there are two different types of processing server in BI 4.3. The SAP Crystal Reports
2020 Processing Server utilizes the same architecture as previous versions. However, the
SAP Crystal Reports Enterprise Processing Server has a new architecture. Previously, the
child processes were single threaded. In SAP Crystal Reports Enterprise, they run as threads

in a Java component. This means additional tuning can be applied to the SAP Crystal Reports
Enterprise Processing Server.
Both processing servers are primarily responsible for responding to page requests, by
processing SAP Crystal Reports and generating Encapsulated Page Format (EPF) pages. A
single .epf file represents one page of an SAP Crystal report. The processing server retrieves
data for the report from the latest instance or directly from the database (depending on the
user request and user security level).
Specifically, both processing servers respond to page requests made by the cache server.
The processing server and cache server interact closely, so cached EPF pages are reused as
frequently as possible, and new pages are generated as soon as they are required. The BI
Launchpad portal takes advantage of this behavior by ensuring that most report-viewing
requests are made to the cache server and processing server. However, if a user default
viewer is the interactive DHTML viewer, the report application server processes the report.
The SAP Crystal Reports 2020 Processing Server creates processing server subprocesses.
Each subprocess loads CRPE and then initiates threads or print jobs as needed. With the SAP
Crystal Reports 2020 Processing Server, if an individual print job were to fail for any reason,
only those threads contained in the processing server sub-process would be affected. All
other subprocesses within the processing server service would be unaffected. Additionally,
individual subprocesses end after so many requests and a new subprocess starts, if required,
so as to maximize resource management.
SAP Crystal Reports Enterprise Processing Server

The table presents the recommended settings for the SAP Crystal Reports Enterprise
Processing Server.
Table 15: SAP Crystal Reports Enterprise Processing Server Options

Option Values Behavior Recommended Settings
Max. Concurrent 0 for automat- — —

Jobs ic
Max. Lifetime Jobs Number — Default value is 1000

per child
Max. No. of Prestart- Number — Default value is 1

ed Children
Idle Connection time- Minutes — Default value is 20

out
Idle Job Timeout Minutes — Default value is 1
Oldest On-Demand Seconds Specifies the amount of Default value is 0 (disa-

Data Given to Clients time that the server uses bled) Recommended set-
cached data to meet re- ting is 300000
quest from on-demand
reports.
SAP Crystal Reports 2020 Processing Server

The table presents the recommended settings for the SAP Crystal Reports 2020 Processing
Server.

Table 16: SAP Crystal Reports 2020 Processing Server Options

Option Values Behavior Recommended Settings
Database records — Specifies the maximum Default value is 20000.

read when previewing number of DB records to Recommendation is to
or refreshing (0 for read when the report is schedule large reports to
unlimited) being previewed or re- reduce the load on your
freshed. Allows you to DB from these large
limit the number of re- queries.
cords that the server re-
trieves from the DB when
a user runs a query re-
port.
Idle job timeout Minutes Specifies the length of Default value is 60 min.
time, the CR processing
server waits between re-
quests for a given job.
Allow report jobs to On or Off — On

stay connected to the
DB until the report
job closes
Oldest on-demand Seconds Specifies the amount of Default value is 0 (disa-

data seconds given to time that the server uses bled). Recommended
clients cached data to meet the setting is 300000.
request from on-demand
reports. Disabled is rec-
ommended.
Report Application Server

The Report Application Server (RAS) is similar to the processing server. It, too, is primarily
responsible for responding to page requests by processing reports and generating EPF pages.
Additionally, the report application server is used at the time of viewing or submitting
schedule requests for reports containing dynamic prompts and cascading lists of values.
Set the default maximum simultaneous report jobs to 75 for each RAS service. This value, as
with the SAP Crystal Reports Processing Server, can be adjusted according to anticipated
load and available hardware resources. The ideal setting for your reporting environment,
however, is highly dependent on your hardware configuration, your database software, and
your reporting requirements. Additionally, a recommended guideline is to run 1 report
application server per CPU.
Depending on the design of a report, and the number of records retrieved from the database,
memory requirements may vary. When a report is viewed and loaded into memory, the report
is decompressed and expanded up to as much as 40 times the original report file size (with
saved data and retrieved records).
Configure these parameters in the CMC.
The table presents the recommended settings for the RAS.

Table 17: Report Application Server Options

Option Argument Units Behavior Recommended Set-
tings
Browse Data Size Number Specifies the number Default value is 100
(records) of distinct records re- records.
turned from the data-
base when browsing
through a particular
field value.
Idle Connection Minutes Specifies the amount Default value is 30

Timeout of time, in minutes min.
that the RAS waits for
requests from an idle
client before timing
out.
Batch Size Records Specifies how many Default value is 100

rows from the result records.
set are returned by
the database during
each data transfer
Number of database Records Specifies the number Default value is

records to read when of database records 20000 records (-1 for
previewing or re- that will be read when unlimited)
freshing a report viewing or refreshing
a report.
Maximum Concur- Jobs Specifies the max. no Default value is 75

rent Report Jobs of independent jobs jobs (0 for unlimited)
allowed to run con-
currently on the RAS.
Oldest on-demand Minutes Specifies the amount Default value is 20

data given to a client of time, in minutes, minutes
that an on-demand
report will serve
cached report data.
SAP BusinessObjects Analysis for OLAP
● Performance factors that are not specific to Analysis edition for OLAP:
- Network bandwidth and quality
- Other enabled services that would have a small effect on performance (such as
monitoring or auditing)
● Performance factors that are specific to Analysis edition for OLAP:
- Hardware settings (HDD RAID settings, memory tuning)

- Optimum server deployment definition

- JVM memory and GC settings
- Number of MDAS services on the same server machine
Testing has shown a practical limit of 45 users per machine. This is due to a number of
factors, including the memory needed to support 45 users (for the MDAS instances alone this
is 12 GB). Supporting 45 users implies three MDAS instances (3 MDAS instances * 15 users
recommended max/MDAS instance). Keep in mind it is better to scale out than up for BI 4.3.
You have more flexibility in terms of allocating services with more nodes, not less.
So, if you wanted to have 3 MDAS instances running, that means you have 3 APS instances
that are only running the MDAS service.
An alternate way to configure for 45 users would be to run one APS running the MDAS service
supporting 45 sessions. Testing shows this performs better, which is likely due to the
elimination of load balancing. However, as we recommend 4 GB heap size per 15 users, that
scale would mean an APS with a heap size of 12 GB.
Connection Server
Connection Server Considerations
● Consider the following when analyzing the connection server:

- Its performance is dependent on the back-end database performance.
- Performance can be improved by adjusting the array fetch size.
- Different connection server modes can impact performance.
Connection server performance is highly dependent on the back-end database performance.

Most of query time will be spent in the database middleware. However, performance can be
improved by adjusting the array fetch size. This parameter determines the number of rows
that will be retrieved during a fetch cycle. Larger array fetch sizes reduce the number of
network calls, but increase memory footprint. Smaller values put more load on the network,
but reduce memory use. In addition, different connection server modes can also have an
impact on performance. By default, the extended SMART switchboard is used to maximize
available connections and performance. Different deployment scenarios can also improve
performance, for instance by making sure that a database middleware is available locally for a
Web Intelligence node.
Event Server
Event Server Considerations
The Event Server under normal enterprise usage is not a processing or memory intensive
server and as such will not be weighted in the sizing process. If event server functionality is
required, allocate this service into the system, but do not estimate any additional cores for
this service.
Additional Servers
Search Service
● The search service manages the delivery of search content.

- Memory: 500MB
- Disk space: same size as FRS
Client Auditing Proxy Service
● The client auditing proxy service manages the logging of events of all clients.
- Load: N/A Memory
- 500MB Disk space: N/A
Services for Publishing
● To make the publishing service available, host the publishing post processing service,
publishing service, and the destination delivery service.
Program Scheduling Service
● The program scheduling service manages schedule executable objects. Memory and disk
space consumption varies depending on individual executable runtime requirements.
BI Workspaces
The tables below assume that all BI 4.3 services are deployed on the same machine and the
only load on the machine are BI workspace scenarios. Note that the scenarios run at the suite
level differ slightly from the workflows that form the basis of these observations.
The table presents the BI workspace parameters.
Table 18: BI Workspace Parameters

Server Specific Comments
CPU Most of the BI workspace code is now Java code being run by
the Java Application Server (Tomcat). It is best to have one
Java AS instance per each SAP BusinessObject Enterprise in-
stance in a clustered installation.
Memory It is critical that there is enough RAM available to the server in-
stance so as not to require paging. If the Java AS is configured
with a heap size of 2 GB, the operating system requires 1 GB,
and other processes require 2 GB, then 6 GB of RAM is installed
on the server to preserve a buffer for memory usage. Our load
tests show that about 500 MB of memory is recycled per hour
during load. If possible, a heap size of 2 GB is allocated to the
Java AS, and another 2 GB is reserved for use by the C++ proc-
esses, such as the CMS.
Disk There is no critical requirement for disk space for BIW.
Process/Instance On our hardware, we brought the server to 100% CPU usage

with 250 users. However, plan for no more than 100 concurrent
users per instance to keep the load on the server low and re-
serve server resources for peak usage times.

Server Specific Comments
Optimal Configuration Pa- N/A

rameter
Sizing/Scale N/A
Additional Information about Analyzing the Sizing Capacity of Servers

Title Online location
Performance and Scalability: Sizing On the SAP Service Marketplace, choose

Products → Performance and Scalability →
Sizing.
Processing Architecture
Consideration When Analyzing the Processing Architecture
● When analyzing the processing architecture, you should ask the following questions:
- Do you have enough CPU power beyond SAPS?
- Are you set to properly scale your systems out?
- Are your processes distributed across nodes?
It is very important to distribute all the processes across the nodes.
Approaches for Analyzing the Processing Architecture

You should aim for 60% to 65% average CPU utilization. This setting enables peaks from
80% to 90% without having to set data center alerts for high utilization. Systems peaking at
100% utilization impact user sessions.
Analyzing processing architecture emphasizes how important it is to scale slowly, so that you
know which services in the APS need more resources and how those resources can be better
utilized, for example, determining whether to add another WEBI service or an additional
MDAS.
A processing architecture analysis can be CMS-specific. CMSs are usually on their own
machines. Add additional CMS hosts at 65% utilization. There is no CMS limit.
Requirements for I/O

Evaluation of I/O Requirements
● Evaluate your I/O for the following requirements:

- Reporting databases, internode communication, I/O links, and so forth.
- CMS database provisioning to ensure low latency and high throughput.
- Database is vendor specific and not part of SAP BI documentation.
Scheduling and publishing are I/O intensive. A machine with fast I/O for disk, and networking
to a SAN, is important for the location of the FRS folders.

WEBI processing server is an I/O intensive process. Carefully consider I/O while sizing for the
WEBI processing server.
Situations That Require Scaling

Considerations When Scaling
BI 4.3 works very well in virtualized environments. Testing has shown it performs equally well
on virtualized hardware as it does on dedicated hardware. However, in order to achieve equal
performance, the hardware it runs on must be dedicated to the virtual machines on which the
BI services run.
Note:
SAP strongly recommends that BI virtual machines have reservations for the
memory and CPUs assigned to them.
BI is a bursty application workload. It can be very I/O intensive when heavily loaded by users.
When experiencing maximum load as defined by your sizing, all parts of the system can go
from moderately loaded to very busy momentarily. If the BI hardware is being shared with
other workloads in a virtualized environment, the response to bursts in activity can result in
slow-downs between dependent BI services and ultimately end-user response time.
It is recommended that you build your system to target 65% utilization so that bursts in
activity can be handled. Performance of both physical and virtual systems degrades when
system utilization is greater than 80%.
If you are unable to secure memory and CPU reservations for your virtualized deployment, it
is recommended that additional scale-outs be done to provide adequate BI processing
resources for peak periods. The amount of additional scaling out will depend on your IT
infrastructure and performance policies.
The goal of sizing BI 4.3 is to have a deployment that can handle the workload needed and
provide a good response time for end-users. If you deploy to a shared virtualized
environment, extra care is needed to ensure your sizing exercise results in a system which
has a service level and responsiveness that can be maintained.
Best Practices for Sizing Virtual Environments in the Cloud

Sizing for Virtual Environments in the Cloud
If you choose not to analyze your cloud deployment, you could run into the following issues:
● Hardware could be completely abstracted with little or no SLAs.
- There is no ability to know what you are running on and if you are actually getting it.
- There is even less visibility and usually no IT counterpart to “see the other side.”
● Virtualization could be very highly utilized.
- Cloud computing is “cheap” because of very high VM density.
- It is in the provider’s best interest to overcommit and hope you do not notice.
● Cloud providers are external parties and outside of organizational control.
- If you thought you had no pull with IT – try a cloud provider.

- One of the only things you can control is your own architecture.
Issues with BI in the Cloud

● Network bandwidth is the most constrained resource.
- Bandwidth at both your site and the cloud provider is limited.
- Loading data to the cloud and keeping it updated is challenging.
- Splitting your nodes becomes important.
● I/O saturation happens long before storage saturation.
- Interconnects can be oversubscribed even with dedicated database servers.
- Most providers do not have “performance tiered” storage.
● Cloud providers do not provide visibility into performance.
- You can only see within your “box” or an abstracted “console.”
- It is difficult to assert SLAs (most providers do not even provide them).
- Performance variability is difficult to detect.
- Cloud deployments require that you have good BI system design, because you cannot
see the underlying infrastructure.
Gauging Performance in the Cloud

When evaluating system performance in the cloud, consider the following advise:
● You can only trust your own numbers
- Standard benchmarks and synthetic benchmarks are not useful.
- There is no “standard” infrastructure like in the on-premise world.
- “Full system” benchmarks are impossible even in the physical world.
● Do not trust your own numbers.
- BI workloads are highly variable. An interactive analysis can happen anytime.
- You have no visibility of events outside your instance.
● The provider cannot usually provide an SLA for I/O resources.
- Multi-tenancy at the I/O transaction level is not really possible.
- The provider must balance overprovisioning and oversubscription.
The best and only thing you can really do is benchmark a series of loads and continue to test
over time. The testing will not show root causes, but it will help determine if there is a problem
in the first place.
Lessons Learned by SAP from Cloud Deployments

SAP has learned the following information from its cloud deployments:
● The placement and number of nodes are important decisions.

- Poor system architecture can create invisible bottlenecks.

- Sizing directly impacts performance and cost (that is, the number of nodes).
● Know what your “normal” is so that you know when something is wrong.
- SAPS, CPU utilizations, and so forth are not proxies for good system performance.
- Establishing reproducible baselines helps to prove problems exist
● Do not ignore design because of lack of visibility
- Make as many choices about BI deployments as possible.
- Make smart, scalable designs from the beginning.
- Find ways to gain visibility.
Lessons Learned by Customer from Cloud Deployments

SAP customers have shared to following tips with us:
● Sizing estimates are hard – architecture is even harder.
- Estimator is based on tests under lab conditions, not real world.
- It’s impossible to estimate your workload. Always get more than you need.
- Expert advice helps create good architecture and better sizing estimates.
● Working with infrastructure teams can pay off.
- IT utilization needs do not need to sacrifice BI system performance.
- A two-way conversation in their language goes a long way.
- The results are always better when everybody gets along.
● I/O issues can be an invisible disaster.
- Not enough attention is paid to things other than CPU and RAM.
- Contention can happen within your system or within the server room.
- Knowing what’s going on in your BI system is important to help find the causes of
problems.
Best Practices for Sizing Virtual Environments using VM Ware
● Use the following best practices for sizing virtual environments using VM Ware:
- Use strict CPU reservations for each BI VM on every host (for example, vCPU to pCPU
relationship).
- Use strict “memory reservations,” for the full amount, for each BI VM on every host (for
example, RAM or heap pre-allocation). This is especially true for Java applications.
- Do not use shares, limits, affinity, or other artificial mechanisms to divide VM resources
on the host.
- To avoid excessive swapping, size VMs large enough (for example, CPU and RAM) in
anticipation of very I/O intensive BI workloads.

- Use more, smaller VMs rather than a few very large (greater than 16 CPU) nodes.
Overview of Configuration Intelligence

Conceptual Tiers
● SAP BusinessObjects Business Intelligence platform comprises a series of conceptual

tiers:
- Client tier
- Management tier
- Storage tier
- Processing tier
- Data tier
The Adaptive Processing Server (APS) is a generic server that hosts multiple services
responsible for processing various requests. The APS is part of the processing tier. By default,
the BI4.x platform contains one APS per host system.
Figure 39: Basic Architecture of the BI Platform
SAP BI 4.x: Not a technical upgrade from SAP BusinessObjects Enterprise 3.1 or XI R2
BI 4.3 is designed to take advantage of modern hardware and RAM. It uses 64–bit addressing,
unlike SAP BusinessObjects Enterprise 3.1, which was designed to squeeze the whole suite
within a 32–bit architecture.
BI 4.3 is architecturally different than 3.1. Whereas SAP BusinessObjects Enterprise 3.1 was a
collection of applications with their own connectivity stacks, BI 4 components share a new
common semantic layer for data connectivity.
BI 4.3 is bigger than SAP BusinessObjects Enterprise 3.1, because it includes new services
and applications. It is designed for modern infrastructure and does not run on the same
hardware. As a first-class system, it is a highly integrated SAP client for BI. New components

on the system include analysis functions, new monitoring capabilities, native SAP BW
connectivity, and others.
Note:
The BI Sizing Guide and BI Platform Installation Guide contain detailed technical
information about specific services critical to configure and size correctly. See
Additional Information about Using Configuration Intelligence.
XL Template Usage
The following are XL template usage considerations when upgrading:
● Adaptive Processing Server (APS) configuration

● Leverage BI 4.3 Configuration Intelligence XLBI Template APS definitions
- XL Template has the most granular APS definitions.
- 40 to 60 GB RAM required
- 48 to 64+ Host RAM
- 11 APSs
- Typically used in large production systems
● APSs are used to create, disable, remove, and group (for redundancy).
Deployment Templates
The following are deployment template considerations when sizing:
● Templates do not specify the number of supported users.

● Number of supported users is dependent on load.
● System sizing determines the number of supported users and other needed resources.
Note:
The DeploymentTemplates.pdf file describes the deployment templates in detail
(see Additional Information about Configuration Intelligence). The templates do
not specify the number of users that can be supported, because the number is
dependent on load. You should perform system sizing to determine the number of
users you will need to support and the system resources required for that support,
including RAM, CPU, and other resources.
Overview of the BI 4 Sizing Guide

BI 4.3 Sizing
The BI 4 suite is designed to serve customers from small business to large organizations. The
number of users, types of users, usage patterns, number of BI tools included in the suite, and
number of data sources and deployment options supported by the suite all factor into a series
of variables that affect the successful deployment of the BI suite. No single configuration fits
all customers.

Sizing BI is different compared to sizing of other types of enterprise software. BI is a very

resource intensive task. The act of extracting information from a potentially large amount of
data requires adequate amounts of processing power and uses all the important subsystems
of a computer: CPU, memory, disk space, and network capabilities. Having the right amount
of capacity of these four aspects of your system is key to success. BI can also be very bursty,
since the load can rely a lot on the schedule of its users.
A BI system is used to search for information interactively, like Google. If Google required a
number of seconds to respond, most users would believe there was a problem with the site.
Users have an expectation, and often a business need to have a responsive system available
to them. Users should be able to access BI decision-making information in a timely manner.
No tool or document can replace human judgment. Although the Sizing Guide attempts to
cover as many aspects of sizing as possible, sizing experts at SAP should always be
consulted.
Sizing Methodology
Factors Affecting Sizing
Sizing a BI 4.3 deployment requires a reasonable degree of planning, so that calculations and
predictions can be made about the needs of the system. The number of users and the needs
of those users can be used to predict system loads. The types of data sources used have an
effect on the load and needs of the system. The needs of the users include the BI services that
they need to use. Some users use a lot of services, some use just a few. Some reports are
scheduled to be processed at night and viewed during the day. Some reports need to be
refreshed when viewed, which causes more load as the number of users increases.
After the user requirements are defined, the system can be defined so that it will support the
amount of processing required. The final step in sizing is to apply it to the hardware
landscape. Deployment hardware can range from many small machines to one large machine.
The sizing exercise includes the allocation of BI services to the nodes in the system, taking
into account the CPU, memory, disk, and network capabilities of nodes to be used in the
construction of the system landscape.
Sizing Methodology Overview

Sizing Steps and Methodology
The basic approach to sizing is to assess the requirements of all tiers in the deployment, and
to account for the processing and memory requirements of each subsystem. Most
subsystems and services have special considerations that need to be taken into account.
After the processing and memory requirements are determined, the next major step is to fit
the services to the hardware landscape. This requires knowing the SAPS per core rating of the
computer to be used as well as the amount of memory available to the machine or machines.
Note:
You must determine the SAPS rating of the machines that will make up your
deployment. You cannot assume any SAPS rating from this or any other
document.
Prerequisite Sizing Information

The goal of the sizing effort is to calculate the peak load that will be placed on the system. In
order to proceed with the sizing steps, you need to know the following information. Gathering

this data accurately is the most important part of the sizing effort, because all of the sizing
calculations derive from this information.
Users: You need to determine how many information consumers, business users, and expert
users of each type of BI tool there are. An average user workflow is also important to know. If
you expect users to open five BI documents and refresh them all at the same time, that’s five
times the load of one user. The entire load needs to be accounted for because the system
needs to handle that load.
It is very important to know if the user workflow is going to include refreshing reports and how
frequently those reports will be refreshed. You will need to determine if the reports will be
scheduled to run at night, and you will need to know if users are only viewing reports or if they
are refreshing reports frequently. This information is an important part of load prediction and
the sizing estimation.
Data Sources: You need to determine which data sources will be used: direct-access SQL
databases, UNV Universes, UNX Universes, SAP BW, BW on SAP HANA, or HANA (Direct
Connectivity). It can be a mix of sources. It’s important to know which types of data sources
will be used for the majority of BI processing so that peak load can be predicted. It is also
important to consider that some customers expect their mix of data sources to change over
time.
Document Size: The relative size of each document is important to know. Will most
documents be small and cause little impact on the system or will they be mostly large and
require a lot of processing? This should be determined for each BI tool expected to be used.
Benchmark Results from the Resource Usage Estimator
● Consider the following when using the Resource Usage Estimator:

- The BI 4 Resource Usage Estimator helps calculate the processing load to be handled
by each tier in your system.
- The estimates that the Estimator provides are based on Performance and Reliability
(P&R) sizing benchmark tests performed in SAP test labs.
- The Estimator is used to get initial numbers for processing and memory needs.
- Depending on the BI tool under consideration, additional calculations might be needed
with corresponding changes and additions to the sizing.
Processing and Memory Requirements Calculations

For each tier, especially the processing tier, the processing power and memory requirements
need to be determined. This is the core of the sizing effort. After these numbers are
determined, a scale-out of deployment hardware can be done.
The processing power is calculated and specified in a processing unit called SAPS. This is a
processor and computer independent unit that describes the processing power of a CPU in a
given computer. SAPS is an SAP-derived processing rating that allows you to calculate the
power required by a deployment. It takes into account the I/O processing capabilities of the
computer, in addition to its raw computation abilities. Computers can have different SAPS
processing capabilities even with the same type of CPU.
Overview of the Resource Usage Estimator

The BI 4 Resource Usage Estimator, also called the sizing tool, was previously named the BI 4
Sizing Estimator. The estimates that the BI 4 Resource Usage Estimator provides are based
on Performance and Reliability (P&R) sizing benchmark tests performed in SAP test labs. The
results and this tool help to estimate the load, based on performance results in these lab

tests. They are only estimates and should not be used as simple predictions of performance
or deployment guidance for your project. The Resource Usage Estimator and the Sizing Guide
must be used together to provide effective sizing guidance.
Initialize the Resource Usage Estimator with the number of users of each type for each type of
BI tool. Set the report size sliders to reflect the sizes and types of documents that will be
processed by the system.
Figure 40: Resource Usage Estimator
Resource Usage Estimator Capabilities

Consideration When Using Resource Usage Estimator
● Consider the following points when you use the Resource Usage Estimator:
- BI 4 Resource Usage Estimator is an estimator, not an analyzer.
- It is only a starting point for your calculations.
- Outputs are not numbers you can blindly deploy with.
- This tool is not a replacement for expert advice.
Limitations of Resource Usage Estimator
● The BI 4 Resource Usage Estimator has the following limitations:

- Test results are not linear, so this model is only valid within specific ranges.
- This tool does not take into account fault-tolerance, clustering, scale-out, or topology.
Scope of Resource Usage Estimator
● Resource Usage Estimator provides SAPS (CPU) and Memory for each of the following BI
4 Tiers:
- Web and Application Tiers (Tomcat or any other Web Application Server)
- Intelligence Database Tier (CMS database)

This only provides what a BI will consume. For the database itself, hardware resource
estimation has to be added separately.
- Intelligence Tier
- Processing Tier
● BI 4 Resource Usage Estimator does not include sizing for Explorer, Mobile, or Live Office.
Note:
The RAM calculation is for deployment on one large machine. Scale-out to smaller
16GB or similar machines might be required, depending on the customer’s
hardware availability.
Tips for Using the BI 4 Sizing Guide

Use of the BI 4.3 Sizing Guide
For all deployments, it is necessary to consult a sizing expert in order to validate sizing efforts
after initial planning, using the Resource Usage Estimator and the BI 4.3 Sizing Guide.
Sometimes customers, partners, or consultants develop their own applications, significantly
modify SAP out-of-the-box solutions, or implement complex integrations involving multiple
systems. In these cases, when sizing for the largest deployments or when your sizing
requirements need to be extremely precise, you should consider expert sizing. An expert
sizing is a hands-on exercise performed by or in collaboration with an SAP professional, where
customer-specific data is analyzed and used to achieve a sizing result with greater precision.
The main objective is to determine the resource consumption of customized content,
applications, and usage patterns by taking comprehensive measurements. For more
information, see http://service.sap.com/sizing and go to Sizing Guidelines → General Sizing
Procedures → Expert Sizing.
The following facts are known about sizing:
● The larger the deployment, the larger the sizing exercise.
- More active concurrent users require more detailed analysis (especially 1000+).
- More time is needed to simulate and validate the system deployment.
● Well-designed systems require planning, iteration, and scale-out.
- Estimates are just that: Develop a plan that can be iterated and changed if necessary.
- “Big Bang” deployments rarely work. It is impossible to observe bottlenecks this way.
- Plan to grow and scale from the beginning. Do not size for “today”.
● Architecture for virtual and cloud environments are the same.
- All design principles for physical environments are valid in virtual and cloud
environments.
- Ensure that IT understands that BI’s characteristics are different to other applications.

Overview of BI Virtualization
BI 4.3 Functionality
SAP BusinessObjects Business Intelligence suite (SAP BusinessObjects BI 4.3) is a flexible
and scalable solution that provides the full spectrum of BI functionality, including reporting
and analysis, data exploration, dashboards, and self-service BI. It also gives IT departments a
flexible means to share BI content throughout the entire organization, empowering business
users to make effective, informed decisions using self-service access to information.
Deployable on physical, virtual, and cloud environments, SAP BusinessObjects BI solutions
are flexible enough to best fit the unique needs of each organization while providing a
complete enterprise BI solution. Customers can decide faster, perform better, and achieve
superior results throughout all areas of their business.
The solution is a multi-tier, server-based product that comprises a number of logical servers.
Each report format has its own server modules that are controlled through a single
management interface. These servers run as separate processes and they can all be installed
on one machine or distributed across multiple machines, with multiple instances of individual
servers able to run on each host. This allows for a very flexible and scalable architecture, with
servers dedicated to specific processes and tasks, and of virtually any size, depending on how
many concurrent users the environment needs to support.
SAP Virtualization Strategy

SAP has adopted a single virtualization strategy across the majority of SAP products. This
approach greatly simplifies configuration and support issues, as different SAP products no
longer have separate support policies. Full details are specified in SAP Note 1492000 [Ref. 5]
and apply to all SAP products not explicitly excluded within this note.
SAP will troubleshoot and address performance issues of the SAP BI suite within a virtual
environment, but the customer is responsible for ensuring the operating environment is
configured correctly and operating optimally. During a support incident, SAP Support cannot
specifically check for virtualization-related issues, so a system that is underperforming due to
a poor virtualization environment might never be properly diagnosed.
Customer Responsibilities
● Customers are fully responsible for the following requirements:

- The BI landscape must be sized properly and architecture structured correctly, based
on a consultation with an SAP professional on BI architecture.
- The customer must ensure enough CPU, RAM, and I/O capacity for the host and all
guests are provisioned, configured or reserved, and available at all times.
- The host and hypervisor environment should be optimized using best practices for
performance and stability.
Many customers with physical deployments who experience performance problems typically
have not allocated enough dedicated hardware resources or have designed a substandard BI
system architecture. Having either of these problems in a virtual deployment can have more
performance implications and the effects will be far more noticeable.
In the vast majority of cases, performance problems blamed on virtualization are usually a
result of poor design decisions a customer has made and not virtualization or the SAP
BusinessObjects BI suite.

BI Virtualization Features
Considerations for BI Virtualization
● All instructions for a physical environment are 100% applicable to virtualized BI, which
include the following:
- There is no evidence that deviating from physical tuning within the VM is a good idea.
- You must properly configure the VM itself and the hypervisor.
- You must ensure that you use memory and CPU reservations, otherwise your sizing
might not be valid.
- You should critically evaluate or disregard non-BI virtualization guidance.
- Many SAP Notes and white papers are inapplicable, because they are based on SAP
NetWeaver.
- Some best practices for Java in virtualized environments can be detrimental to BI.
For more information, refer to Additional Information about Using BI Virtualization.
For more information, refer to Additional Information about Using BI Virtualization.
Best Practice Recommendations

The table High-Level Summary of Best Practice Recommendations is a result of SAP’s COIL
tests and analysis.
Table 19: High-Level Summary of Best Practice Recommendations

Recommendation Key Points
Design and ensure a good ● Virtualization gives you the freedom to make a better ar-
system architecture before chitecture than typically possible in a physical deployment.
performing optimizations at
any level. ● Optimization cannot compensate for poor system design.
Poor designs will suffer the same bottlenecks on physical
systems as well.
Follow guidance specifically ● Disregard virtualization guidance for SAP Software unless
for SAP BusinessObjects BI it is specifically for SAP BusinessObjects BI 4.3.
4.3 and disregard previous
studies. ● Disregard previous SAP and non-SAP virtualization studies
for BI as they might be based on previous versions.
Use the latest version of ● Guidance in the whitepaper is supplemental to VMware’s

VMware and follow best practices. To view the whitepaper, go to: http://
VMware’s best practices www.vmware.com/resources/techresources/10296.
guide.
● Use the latest version of VMware ESXi to take advantage
of performance improvements at all layers of the stack
(hardware, OS, application, etc.) .

Review the configuration of ● Ensure configuration at all levels have sensible values.
each level of your hardware
and software stack. ● Use defaults for each stack element, unless following guid-
ance by the specific vendor for that element.
● Always use the latest versions of all components whenever
possible to take advantage of performance improvements.
Use strict CPU (processing ● VMs without CPU reservations may share CPU time with
power) reservations for each other processor intensive guests and negatively impact
BI VM on every host. performance.
● All standard BI sizing and performance expectations are
invalid if CPU reservations are not strictly enforced.
Use strict memory reserva- ● VMs without memory reservations may be forced to page
tions for each BI VM on ev- to disk if the host experiences memory pressure.
ery host.
invalid if memory reservations are not strictly enforced.
Do not use shares, limits, af- ● Any mechanism that divides or shares resources allows
finity, or other artificial the host to provide less than the promised resources re-
mechanisms to divide VM quired for optimal performance.
resources on the host.
invalid if resource sharing features are employed.
Size VMs large enough for BI ● Size your VMs the same way you would on physical nodes.
workloads. If your IT department does not allow for large enough VMs,
seek exceptions or expect the system to struggle.
● Ensure your VMs at least meet the hardware minimum re-
quirements as stated in the SAP BusinessObjects BI 4 Siz-
ing Guide [Ref. 2].
Use more, smaller VMs rath- ● Split very large VMs into smaller ones to better monitor
er than a few very large (>16 and manage resource usage.
CPU) nodes.
● Individual VMs still have inherent bottlenecks regardless of
how powerful or well provisioned the host is.
Always deploy VMtools in ● VMtools provide the mechanism for the host and guest to
every guest. work efficiently together.
● Without VMtools, the system might still run, but all stand-
ard BI sizing and performance expectations should be con-
sidered invalid.

Use strict resource reserva- ● Minimize virtualization overhead to avoid invalidating your
tions and other recommen- BI sizing.
dations from this guide to
ensure your BI sizing is valid. ● Conservatively factor in some overhead to provide a per-
formance buffer.
Use hypervisor-level moni- ● Guest-level monitoring tools may not be hypervisor aware
toring tools. and may not report the true system statistics.
● Work with your IT department to get access to hypervisor-
level tools for monitoring, or work with them to do a per-
formance analysis using tools like vCenter or “esxtop.”
Ensure your landscape re- ● Maintaining license compliance can affect how you deploy
flects your SAP software li- in a virtual environment.
cense and virtualization
rights. ● Ensure you review your specific virtualization rights. If you
have CPU-based licensing, ensure you are calculating the
host’s cores correctly and getting full value from each one
through reservations.
Additional Information about Using BI Virtualization

Evaluating Selected Java Best Practices for On the VMware website, search for the title.
SAP BusinessObjects Business Intelligence 4
On vSphere
ra the title.
Sizing of Backends (BW systems) for Processing Groups

A Processing Group allocates an individual session in the backend. Therefore, the average
Processing Group count should be considered as additional "concurrent users." The effect
might depend on the backend type.
The following describes the sizing for SAP BW as backend:
Memory consumption: The actual result set data held in the session is the same as when used
without Processing Group. However, each session itself has a memory overhead. This can be
estimated by looking at memory consumption of an empty session in transaction SM04. The
overhead might be around 10MB.
Processing power: Processing Groups request more result set data at the same time, which
leads to higher load at a certain point in time but finishes earlier due to the parallel nature.
See SCN article "Design Studio 1.5: View on Parallel Data Source Execution" (http://
scn.sap.com/docs/DOC-64107) for illustrated examples and further insights.

Database Performance Optimization

Database Terms
Lock
Locks are used to control concurrency in a database. When a process locks a row or
table, no other process can access it until the lock is released. The level at which a lock is
requested, at the row or the table level, is referred to as the lock granularity.
Deadlock
A deadlock occurs when two or more processes conflict in such a way that each must
wait for the other to release its lock in order for the other to proceed.
Lock wait
A lock wait occurs when a process must wait for another process to release a lock on a
row or a table.
Lock escalation
A lock escalation occurs when the number of locks on rows or tables in the database
equals the maximum number of locks specified in the database configuration settings.
Avoidance of Performance Bottlenecks
● Meeting the following criteria helps to avoid the most common performance bottlenecks:
- The database system’s cache hit rates are over 90%.
- The optimizer statistics are not older than 24 hours.
- Lock granularity is row locking.
- There are no lock escalations.
- There are no log write waits. The average disk write queue length to the disk drives that
contain the database log files is smaller than five.
Common Performance Bottlenecks
● Some of the more common performance bottlenecks include the following:

- 90% or higher cache hit rate
- Up-to-date optimizer statistics
- Lock granularity causing row locking
- No lock escalations
- No log write waits
The following table examines the most common performance bottlenecks in more detail.

Table 20: Common Performance Bottlenecks: Symptoms, Problems, and Resolutions

Bottleneck Symptoms Problems Resolution
90% or higher cache ● A relatively low ● Disk access is un- ● Providing suffi-
hit rate number of physi- able to keep up cient physical
cal disk reads and with the level of memory.
writes. I/O that the data-
● Configuring suffi-
base server re-
● A relatively low cient cache sizes.
quests.
number of SQL
compiler execu- ● There are long
tions. disk read or disk
write queues.
● There are unnec-
essary SQL state-
ment compilations
or long SQL state-
ment compilation
times.
Up-to-date optimizer Good selectivity esti- ● Long response ● Implementing a

statistics mates of predicates times and low procedure to peri-
in SQL expressions, throughput. odically update
especially for expres- the statistics or to
sions including col- ● Long execution update the statis-
umns with unequal or times for queries. tics after frequent
skewed distribution
● Full table scans. changes to the da-
of column values. tabase.
● Lock escalations.
● Creating statistics
● Lock waits or for tables, col-
deadlocks. umns, and indexes
that are not stale.
● Significant differ-
ences between the ● Setting the sample
estimated number size (percentage
of rows for each or data that is ana-
operator in the lyzed to gather
query plan from statistical infor-
the actual number mation) to a value
of rows. which is sufficient
for the skewed da-
ta distribution.
Lock granularity Increased concur- Lock waits or dead-

●
Setting the lock gran-
causing row locking locks. ularity of your data-
rent execution of
base to row level.
transactions.
● Reduced transac-
tion processing
time due to fewer
lock waits.

Bottleneck Symptoms Problems Resolution
No lock escalations Increased concurrent Lock waits or dead- ● Configuring a suf-

execution of transac- bolts. ficient size of the
tions. lock list.
● Setting the lock
escalation thresh-
old to an appropri-
ate level.
● Keeping the opti-
mizer statistics up
to date.
No log write waits Reduced transaction Lock waits or dead- ● Providing an I/O
processing time due locks. subsystem with
to no I/O waits. sufficient through-
put.
Sizing for SAP BusinessObjects Lumira

SAP Lumira, server for BI platform, brings SAP Lumira content into your SAP
BusinessObjects BI platform deployment. The SAP BusinessObjects BI platform enforces
security on Lumira documents, and allows access and categorization in the same manner as
other BI platform content, allowing you to seamlessly adopt SAP Lumira within your
organization.
This information is provided as a starting point for your deployment planning. Your
experience may vary depending on:
● The complexity of documents created
● The data set size
● Complexity, as well as general user workflow
Note:
The sizing estimate below should only be used as a starting point, as it is based on
the workflows outlined in the table. We strongly recommend volume testing to
validate your sizing estimate, based on the expected usage in your deployment.
Table 21: Sizing Recommendations for SAP Lumira, Server for BI Platform
Maximum Cell Size
(no. of rows * no. of Recommended Maximum Active Concurrent Users
columns)
60,000,000 10 12 15
700,000 15 25 35
Recommended Configuration Scenario

Maximum Cell Size

(no. of rows * no. of Recommended Maximum Active Concurrent Users
columns)
Minimum Memory 32 48 64
Required (RAM in
GB)
Minimum CPU Cores 8 24 24
1. Your hardware should meet the minimum hardware specifications outlined in the SAP
Lumira server for BI platform product availability matrix (PAM).
2. To avoid the user load impacting other BI platform workflows, it is recommended that SAP
Lumira, server for BI platform runs on dedicated hardware resources — according to the
configurations outlined in the table above. There is no hard limit cut-off that the in-
memory data engine can support. The engine will utilize the available memory resources.
3. The sizing recommendations are specific to the hardware configurations outlined in the
table. For larger deployments, involving more than 350 active concurrent users, we
recommend that you add more nodes to your deployment, rather than adding additional
Lumira servers to an existing node to avoid potential memory resource allocation
conflicts. If your deployment requires 350 active concurrent users, you should consider
deploying 10 nodes each, with 64GB RAM and 24 CPU cores.
SAP Lumira, Server for BI Platform Architecture

SAP Lumira, server for BI platform, architecture adds a few additional components to your BI
4 landscape. A technological representation of the system is provided below:
Figure 41: SAP Lumira, Server for BI Platform, Architecture
The Lumira server processes Lumira content on BI platform. This server hosts the in-memory
data engine, which is used as an offline data processing engine for Lumira. It is a separate
product from HANA, but borrows many concepts such as in-memory, column store,

parallelization, and compression. Like other documents in BI platform, Lumira documents are
also saved in the input/ output file repository servers. The data is only loaded into the in-
memory data engine when a user opens a Lumira document.
Lumira Scheduling Service

Lumira scheduling service is a service within the adaptive job server. This server enables
the scheduling of Lumira documents.
Lumira Web Application
The BI launchpad and CMC applications are embedded in the Lumira Web application,
which provides access to Lumira content in BI applications.
Lumira Restful Web Services
Lumira restful Web services provide the web services required by Lumira desktop to
interact with the BI platform, such as login or the ability to save a Lumira document.
Refer to the following links for more information about SAP Lumira, server for BI platform:
● http://scn.sap.com/docs/DOC-63551: contains the latest information regarding Lumira,
server for BI platform, functionalities and support statements.
● http://scn.sap.com/docs/DOC-26507: refer to the architecture process flow section for a
step-by-step explanation of how Lumira user loads are processed within a BI platform
deployment.
Sizing Estimator Use

Overview of Quick Sizer
● Quick Sizer is the online sizing tool of SAP. The tool helps prospects, customers, and
hardware vendors to do the following:
- It speeds up the hardware-planning phase by asking structured questions relating to
usage of business processes that might affect sizing.
- It facilitates the tendering procedure by including links to hardware vendors so that
they can make an offer based on the information provided in the tool.
- It provides content for GoingLive Check to determine if the hardware is sufficient to
smoothly run SAP software.
Note:
Keep in mind that Quick Sizer is a tool for initial sizings only. It is not used for
post-deployment sizings, such as upgrade or re-sizing (except delta-sizing of a
new SAP solution), configuration, landscaping, or customer coding.
Additional Information about Performing an Initial Sizing of a Deployment

Performance and Scalability: Quick Sizer tool On the SAP Service Marketplace, choose
Sizing → Quick Sizer.
ra the title.

Background: Sizing SAP Business Suite On the SAP Service Marketplace, choose
Sizing → Sizing Guidelines → Presentations
and Articles → Background: Sizing SAP Busi-
ness Suite.
Performance and Scalability: Sizing On the SAP Service Marketplace, choose

Sizing.
SAP Standard Application Benchmarks Go to www.sap.com/benchmark.
LESSON SUMMARY


Unit 4
Learning Assessment
1. You can put 10 Webi Processing servers along with a CMS and an FRS in a single VM that
has 12 CPU and 48G memory without impacting performance.
X True
X False
2. The best practice is to have only two CMSs clustered for an BI 4.3 environment, because
only two CMSs can be clustered in a single environment.
X True
X False
3. Web farms are not supported by SAP BusinessObject BI platform.

X True
X False
4. What directly impacts the end sizing numbers?

X A Total number of users
X B Active users
X C Active concurrent users
X D Power users
X E Super power users

5. Which statements are true?

X A The connection server’s performance is dependent on the back-end database

performance.
X B Two Web Intelligence report servers are required per machine as a starting point.
X C A cluster can have two or more CMS clusters on different subnets.
X D The input FRS maintains all the instances that have been produced from reports.
X E One Server Intelligence Agent (SIA) is required to run on each machine regardless
of CPU configuration.
6. Your deployment planning should aim for 90% CPU utilization.

X True
X False
7. For memory usage information, planners should look at average usage, not maximum
usage.
X True
X False
8. Performance of physical and virtual systems degrades when the system utilization is
greater than 80%.
X True
X False
9. A likely issue to encounter when running BI in the cloud is that cloud providers do not
provide visibility into performance.
X True
X False

10. Which is a best practice for sizing virtual environments with VM Ware?
X A Sizing the VMs small protects from excessive swapping.
X B Do not use shares, limits, affinity, or other artificial mechanisms to divide VM

X C Use a few large nodes, rather than several small ones.
X D Use limits to divide VM resources on the host.
11. Which of the following is not an SAP BusinessObjects Business Intelligence conceptual
tier?
X A Client tier
X B Configuration intelligence tier
X C Processing tier
X D Storage tier

X A Virtualization gives you the freedom to make a better architecture than is typically
possible in a physical deployment.
X B Because SAP has a different virtualization strategy for each product, it has a
separate support policy for each product.
X C SAP helps solve issues with virtual environments, but the system must be
configured properly and operating optimally.
X D SAP recommends using shares, limits, affinity, or other mechanisms to divide VM

X E Without VMtools, the system might still run, but all standard BI sizing and
performance expectations should be considered invalid.
X F Previous SAP and non-SAP virtualization studies for BI can be helpful, even if they
are based on previous versions.

13. Which statement is true?

X A A lock escalation occurs when the number of locks on rows or tables in the
database equals the minimum number of locks specified in the database
configuration settings.
X B Quick Sizer is not used for post-deployment sizings, except delta-sizing of a new
SAP solution.

Unit 4
1. You can put 10 Webi Processing servers along with a CMS and an FRS in a single VM that
has 12 CPU and 48G memory without impacting performance.
X True
X False
2. The best practice is to have only two CMSs clustered for an BI 4.3 environment, because
only two CMSs can be clustered in a single environment.
X True
X False
3. Web farms are not supported by SAP BusinessObject BI platform.

X True
X False
4. What directly impacts the end sizing numbers?

X A Total number of users
X B Active users
X C Active concurrent users
X D Power users
X E Super power users


X A The connection server’s performance is dependent on the back-end database

performance.
X B Two Web Intelligence report servers are required per machine as a starting point.
X C A cluster can have two or more CMS clusters on different subnets.
X D The input FRS maintains all the instances that have been produced from reports.
X E One Server Intelligence Agent (SIA) is required to run on each machine regardless
of CPU configuration.
6. Your deployment planning should aim for 90% CPU utilization.

X True
X False
7. For memory usage information, planners should look at average usage, not maximum
usage.
X True
X False
8. Performance of physical and virtual systems degrades when the system utilization is
greater than 80%.
X True
X False
9. A likely issue to encounter when running BI in the cloud is that cloud providers do not
provide visibility into performance.
X True
X False

10. Which is a best practice for sizing virtual environments with VM Ware?
X A Sizing the VMs small protects from excessive swapping.
X B Do not use shares, limits, affinity, or other artificial mechanisms to divide VM

X C Use a few large nodes, rather than several small ones.
X D Use limits to divide VM resources on the host.
11. Which of the following is not an SAP BusinessObjects Business Intelligence conceptual
tier?
X A Client tier
X B Configuration intelligence tier
X C Processing tier
X D Storage tier

X A Virtualization gives you the freedom to make a better architecture than is typically
possible in a physical deployment.
X B Because SAP has a different virtualization strategy for each product, it has a
separate support policy for each product.
X C SAP helps solve issues with virtual environments, but the system must be
configured properly and operating optimally.
X D SAP recommends using shares, limits, affinity, or other mechanisms to divide VM

X E Without VMtools, the system might still run, but all standard BI sizing and
performance expectations should be considered invalid.
X F Previous SAP and non-SAP virtualization studies for BI can be helpful, even if they
are based on previous versions.

13. Which statement is true?

X A A lock escalation occurs when the number of locks on rows or tables in the
database equals the minimum number of locks specified in the database
configuration settings.
X B Quick Sizer is not used for post-deployment sizings, except delta-sizing of a new
SAP solution.

UNIT 5 Deployment and Configuration
of an SAP Business Intelligence
Platform 4.3
Lesson 1
Planning a Deployment Solution 161
Lesson 2
Configuring the Web Tier for High Availability 179
Lesson 3
Configuring the Management Tier for High Availability 187
Lesson 4
Configuring the Storage Tier for High Availability 191
Lesson 5
Configuring the Processing Tier for High Availability 195
Lesson 6
BI Platform Pattern Books and Best Practices for Deployment 201
Lesson 7
Administering Server Groups 207
UNIT OBJECTIVES
● Describe the factors that influence a deployment solution plan

● Develop a deployment strategy for high availability
● Configure the web tier for high availability.
● Configure the management tier for high availability
● Configure the File Repository System (FRS)
● Configure the processing tier for high availability
● Choose a deployment template

Unit 5: Deployment and Configuration of an SAP Business Intelligence Platform 4.3
● Select a pattern for a BI landscape

● Administer server groups

Unit 5
Lesson 1
Planning a Deployment Solution
LESSON OVERVIEW
This lesson discusses factors to consider when you are planning for a highly available, fault-
tolerant BI deployment solution.
LESSON OBJECTIVES
Challenges in BI Solutions
With the rapid changes in today’s market, business, and technology landscape, organizations
need business intelligence (BI) platforms. BI provides real-time performance on big data,
insight with trust across business and social data, and instantly available mobile BI. BI
solutions need to be globally ready, easily scalable, and flexibly deployable.
Organizations Challenges
The following are challenges that organizations must face:
● Managing growing amounts of data

● Analyzing large volumes of data
● Purchasing and maintaining needed hardware
● Providing real-time data access for analysis
A key challenge that organizations of any size in any industry must face is how to manage and
analyze the soaring quantity of data and harness that information to improve the business. IT
is challenged by the high costs associated with the purchase and maintenance of hardware
needed to accommodate large data volumes, while business users need quick, often real-time
access to analyze this information in order to respond to ever-changing market conditions.
Key Factors for High Availability

Horizontal Architecture
The following are components of horizontal architecture:
● External Layer
● Web Server Layer
● Application Server Layer
● SAP BusinessObjects BI Platform

● Data Layer
Figure 42: Horizontal Architecture—External Layer
Horizontal Architecture—External Layer

The following are key components of the external layer in horizontal architecture:
● Client systems
● Reverse proxy
● Load balancer
Figure 43: Horizontal Architecture—Web Server Layer
Horizontal Architecture—Web Server Layer

The following are key components of the Web Server layer in horizontal architecture:

Lesson: Planning a Deployment Solution
● Apache HTTP servers

Load balancer auto routes to either server
● First firewall
Figure 44: Horizontal Architecture—Application Server Layer
Horizontal Architecture—Application Server Layer

The following are key components of the Application Server layer in horizontal architecture:
● Application server machines
Includes BO Web Component Adapter
● LDAP-based authentication server (Sun One, Windows Active Directory)
● Second firewall
Horizontal Architecture—Data Layer

Figure 45: Horizontal Architecture—Data Layer
Corporate Data Stores (Data Warehouse, data marts, etc.) is the key component of the Data
layer in horizontal architecture.
Network Storage Solutions
Figure 46: Network Attached Storage
The BusinessObjects Platform supports the usage of networking storage solutions like
Storage Area Network (SAN) or Network Attached Storage (NAS).

Vertical and Horizontal Scaling

Success with Scalability
The following are considerations when scaling:
● Scalability is a key success factor.

● BO 4.x scales vertically and horizontally.
- Vertical Scaling
Adding more hardware resources, such as processors and memory
- Horizontal Scaling
Running multiple servers on multiple machines
Scalability is a key success factor for business applications in a dynamic environment.

BusinessObjects 4.x scales both vertically and horizontally.
Vertical scaling, also known as scaling up, means adding more hardware resources (for
example, processors and memory) to the same machine. In the context of SAP
BusinessObjects BI 4.x, this means the ability to add multiple servers on the same machine.
Horizontal scaling, also known as scaling out, means adding more machines into the solution.
In the context of BusinessObjects 4.x, this means the ability to seamlessly run multiple
servers on multiple machines .
Additional Information about Factors that Influence a Deployment Solution

Large-scale SAP BusinessObjects BI 4 plat- On the SAP Community Network, search for
form deployments over SAP Sybase ASE and the title.
SAP Sybase IQ databases optimal sizing and
configuration for up to 10,000 concurrent
users
Sizing Estimator http://www.sap.com/bisizing
System Design for High Availability

Risk Management and High Availability
As BI becomes more critical to an organization, more and more companies are designing their
BI systems to be highly available. Some companies additionally factor disaster recovery (also
known as "Business Continuity Planning") into their design.
● When evaluating for risk management while designing for high availability, consider the
following questions:
- How much risk is your customer prepared to undertake versus the cost of mitigating
that risk?
- Is it important to your customer if their BI system is down for an hour, a day, or even a
week?

- How much downtime can your customer tolerate before the loss of their BI system has
a serious impact on their organization?
- Assuming your customer would like to at least partially mitigate the risk, how much are
they willing to spend?
- What level of continuity does your customer need?
- What would your customer do if they lost an entire data center?
High Availability Terminology
● High Availability (HA)

High availability (HA) refers to user access to the system, whether to submit new work,
update or alter existing work, or collect the results of previous work. If a user cannot
access the system, it is described as unavailable. A system becomes unavailable when one
or more components of that system have failed. One obvious solution to this would be to
make a complete copy of all the components of the system.
● Disaster Recovery (DA)
A disaster recovery plan covers the data, hardware, and software critical for a business to
restart operations in the event of a disaster.
Figure 47: High Availability System Design Landscape
The Landscape
When designing your system with high availability or disaster recovery in mind, it is important
to consider each of the components displayed in the figure, High Availability System Design
Landscape. Each of these components is discussed in greater detail in the following sections,
but the three main tiers of a BI system—the web server, web application server and BI

platform tiers—should be instantly recognizable. The external components that are relied
upon are also illustrated in the figure. The green arrows represent the paths where failover is
typically taken care of by the BI platform system and the gold arrows indicate where external
systems must be relied upon to provide failover capability.
Deployment Options
● The following deployment options are available:

- Single-server deployment
- Multi-server distributed deployment
- Scaling up and scaling out
- High-availability deployment
Single-Server Deployments
Figure 48: Single Server Deployment
Single-server deployments are not highly available; therefore, they are not “Enterprise”
architectures. They are basic deployments from which we can build bigger environments.

Multiple-Server Deployments
Figure 49: Application Tier Scaling
Scenario 1: Application Tier Scaling

The deployment shown in the figure, Application Tier Scaling, uses a separate web application
server.
Figure 50: Vertical Scaling

Scenario 2: Vertical Scaling

The deployment shown in the figure, Vertical Scaling uses a web server to serve static
content.
Figure 51: Horizontal and Vertical Scaling of Application Tier: Multiple Business Intelligence Servers
Scenario 3: Multiple Server Distributed Deployment

The deployment shown in the figure, Horizontal and Vertical Scaling of Application Tier:
Multiple Business Intelligence Servers, highlights the usage of multiple web servers,
application servers, and SAP BusinessObjects Servers.

Figure 52: Horizontal and Vertical Scaling of Application Tier: Hardware Redirector
Scenario 4: Multiple Server Distributed Deployment with Hardware Load Balancers

The figure, Horizontal and Vertical Scaling of Application Tier: Hardware Redirector,
illustrates the usage of hardware load balancers to manage user sessions across multiple web
servers.

Figure 53: Horizontal and Vertical Scaling of Application Tier: Clustered Application Servers
Scenario 5: Firewalls Configured Within a Multiple Server Deployment

The figure, Horizontal and Vertical Scaling of Application Tier: Clustered Application Servers,
illustrates the usage of firewall equipment to help secure users session managed in the SAP
BusinessObjects Platform..

Figure 54: Horizontal and Vertical Scaling of Application Tier: Web Tier and BI Platform Cluster
Scenario 6: SAP BusinessObjects BI Cluster

The figure, Horizontal and Vertical Scaling of Application Tier: Web Tier and BI Platform
Cluster, illustrates the CMS system databases and the File Repository shared storage to
showcase the design of a BI Cluster.

Figure 55: Multiple Tier Availability
The figure, Multiple Tier Availability, illustrates a tier by tier multi-machine configuration that
showcases high availability and load-balancing of the SAP BusinessObejcts Platform.
In the Intelligence Tier, in the event of a failure, the workload of the failed CMS is picked up by
an available CMS within the cluster.
Ensuring availability of resources that the CMS cluster depends on (such as the system
database and third-party authentication servers) is critical to the availability of the entire 4.3
deployment.
In the event that an active FRS fails, the passive FRS becomes the active server. When the
previously active FRS is operational again, it is registered with the CMS as a passive FRS.
Ensuring availability of each FRS root folder is critical. There are many possible solutions.
In the Processing Tier, redundant servers are running on separate machines to support high
availability. If one server fails, redundant servers on different machines are still available.
High Availability Clusters Support

Web Client and Web Server
Many customers choose to implement an external web server in front of the BI stack for one
or more of the following reasons:
● Customers want to implement a DMZ.
● Customers want the web server to serve up static web content only (.gif) and want to
remove this load from the Web App Server. Use the wdeploy tool (available as a download
from the tech support website) to achieve this. The standard desktop.war file produced

during installation of the BI platform can be broken into two smaller WAR files: one
containing the static content and the other containing the dynamic JSPs and Servlets.
● Customers want to offload the SSL work from the Web App Servers. However, if you have
one web server, then you have a single point of failure. You can eliminate the single point of
failure by introducing multiple web servers.
Using multiple web servers introduces a new problem: users now have multiple web
servers and multiple URLs to choose from.
DNS round robin is one solution. It is not very popular, but it is very cheap to implement.
Web server software clustering is another solution. But by far the best and most popular
method, especially for enterprise organizations, is to introduce a hardware load balancer.
These hardware appliances present a single URL to the end users. Traffic is then
forwarded to the web server farm behind it. Hardware load balancers tend to be very
reliable.
Figure 56: Hardware Load Balancer
Web Server and Web App Server

Clustered Web App Servers
One important limitation is using BI Launchpad with clustered web application servers (for
example, IBM WebSphere ND). Increasingly, web application servers make use of clustering in
order to implement failover. They replicate a user’s HTTP session on a secondary node so
that if the primary node fails, the user’s session still exists somewhere in the cluster. This is
known as HTTP Session Failover.

Figure 57: Clustered Web Application Servers
Web App Server and SAP BusinessObjects BI Platform

The next tier down from the Web App Server is the SAP BusinessObjects BI platform tier.
When you log into SAP BusinessObjects BI platform through any of the client tools, you are
typically asked to provide the following four pieces of information:
● User name
● Password
● System to log in to
● Authentication type (for example, enterprise, LDAP, active directory, NT)
The system you specify is really the host name (and optionally the port) of a host running a
CMS (it is best to use the fully qualified domain name of the host).
Interestingly, due to the way that SAP BusinessObjects Enterprise failover works, the host
name you specify may not actually be the CMS to which you end up connecting. Clustering is
inherent to the system at every point.
CMS Clustering
The CMS service controls the entire SAP BusinessObjects Enterprise tier and all the
components that reside on the platform. Each CMS service talks to the others to maintain a
dynamic list of all the CMS processes available within the cluster. It passes this list down to
each platform service as they connect to the CMS. If a CMS service dies, all the other services
already have the names of all the other CMS services, and they will automatically try to re-
establish a connection with one of those.
Making a cluster is easy, all you need to do is install another CMS on another server then point
it to the same system repository database. It becomes part of the cluster by using the shared
repository.

Other Cluster Members

Cluster members (that is, Page, Cache and Job Servers) can refer to an actual server within
their command-line parameters. Even if that particular CMS is down when they start they will
still connect to the cluster. It is possible to connect because the CMS specified in the
command line using the -ns switch is not the one to which they will necessarily connect. When
each process starts, it takes the name specified in the command line and looks it up in the
registry (or equivalent for UNIX) to see to which cluster that particular CMS belongs. Once it
is found the cluster, it can see all the other CMS processes within the cluster and will attempt
to connect to the first CMS in the list. If it is unable to do so, it will automatically move onto the
next CMS in the list and so on until it finds an active CMS.
Figure 58: Web Application Servers and the BI Platform Tier
BI Platform Tier: FRS and the File Store

FRS
The FRS is responsible for managing the BI content file store. Although the FRS is composed
of two services or daemons, the Input FRS and the Output FRS, they are rarely separated and
can be thought of as a single service: the FRS. Multiple FRS pairs are necessary.
The FRS file store
The file store beneath the FRS is important to understand. On a Windows server, the path to
the FRS file store is specified either using UNC paths or local paths. Only minimal installations
will keep the file store on a local physical disk. Most deployments will use UNC paths to a
highly-available network file share or a SAN.
By default, the files are stored on the local host's file system of the box onto which you install
the FRS. However, having just one FRS pointing to local file storage can create the following
problems:
● A single point of failure
● The files are not visible to another servers.

Figure 59: FRS File Store Configuration
If you lose one of the servers within the cluster where the files are stored, the backup FRS
pairs will still be able to access the files through the cluster.
LESSON SUMMARY


Unit 5
Lesson 2
Configuring the Web Tier for High Availability
LESSON OVERVIEW
This lesson describes the configuration of each tier in the BI platform, how to deploy a split
environment, and how to configure clusters in a BI platform deployment.
LESSON OBJECTIVES
Web Client to Web Server

For the BI platform, standard IT protection mechanisms apply. There are many BI servers,
and to reduce the attack surface, it is highly advisable to hide the BI servers behind a firewall.
Figure 60: Firewall Protection
Simple DMZs
Demilitarized Zones (DMZs) are the cordoned-off areas of the network that are separated
from the internet by an outward-facing firewall and separated from the rest of the internal
network by another firewall.

Figure 61: DMZ Simple Scenario
Real-Life Scenario
It is becoming more common to extend this model. In the figure, DMZ Realistic Scenario,
there are two DMZs. The web server is in the first DMZ, the application server in the second
DMZ, and database servers and so forth are in the internal network.
Figure 62: DMZ Realistic Scenario
Web servers have weak points, and it is good practice to not allow web servers in the first
DMZ. Perhaps an even more widely accepted standard is to not run any code inside the first
DMZ. The scenario shown in the figure, DMZ Safer Scenario is more commonly used,
especially in combination with Network Address Translation (NAT). Implementing good rules
about what traffic can enter and leave the network can make it a lot harder for malicious users
to find an easy way in and back out.

Lesson: Configuring the Web Tier for High Availability
Figure 63: DMZ Safer Scenario
Because a firewall can be placed between the web and application servers, a scenario with
three DMZs is also possible. In the figure, DMZ Three-Zone Scenario, even more obstacles are
placed in the way of the attacker. The web server remains as vulnerable as in the figure, DMZ
Safer Scenario, but the application server has another firewall protecting it.
Figure 64: DMZ Three-Zone Scenario
Configuration Example
In this example, the BIG-IP system is configured to optimize and direct traffic to both the
Apache web server and the Tomcat application server. The figure, Simple Configuration:
Redundant BIG-IP Local Traffic Manager, shows a simple, logical configuration with a
redundant pair of BIG-IP LTM devices in front of a group of Apache web servers and Tomcat
application servers.

Figure 65: Simple Configuration: BIG-IP Local Traffic Manager
Secure the Communication Channel

Assuming users are logging on with passwords, to prevent man-in-the-middle attacks,
configure your application server for SSL.
Figure 66: SSL Configuration: Web Server
Additional Information
The following links provide step-by-step instructions for the Apache web server setup:
http://wiki.scn.sap.com/wiki/display/BOBJ/Apache
http://wiki.scn.sap.com/wiki/display/BOBJ/Setting+up+Apache+2.4

Web Application Deployment Using WDeploy
Figure 67: Standalone Deployment: No Web Server
Standalone Mode
Deploying web applications’ static and dynamic resources, which are bundled in the .war file
on the web application server, is known as standalone mode.
This makes deployment simpler, but performance may suffer because every type of
transaction, even those requiring static content only, must pass through the Web application
server.

Figure 68: Distributed Deployment: Same Machine
Distributed Mode, Scenario 1

In distributed deployments, Web application dynamic resources are deployed on the Web
application server, and their static resources are deployed on the Web server.
Figure 69: Distributed Deployment: Different Machines
Distributed Mode, Scenario 2

The scenario shown in the figure, Distributed Deployment: Different Machines, could enhance
performance because the Web server can serve up static pages without having to
communicate with the Web application server.
Figure 70: Configuration Best Practices
Best Practices for Configurations

Separating the web server static content and dynamic content and placing each into their own
dedicated machines improves web response speeds and overall SAP BusinessObjects
Platform web tier performance.
Additional Information about High Availability in the Web Tier

An internal error occurred while calling 'proc- http://service.sap.com/sap/support/

essDPCommandsEx' API (Error: notes/1864885
ERR_WIS_30270)
VGX.DLL vulnerability in Microsoft Internet http://service.sap.com/sap/support/
Explorer (CVE-2014-1776) notes/2012498
WIH 444444 error occurs when opening a http://service.sap.com/sap/support/
webi report the second time using the HTML notes/1835730
Web Viewer.
Are 64–bit browsers supported with Busi- http://service.sap.com/sap/support/
ness Objects Enterprise or Business Intelli- notes/1841281
gence?
LESSON SUMMARY


Unit 5
Lesson 3
Configuring the Management Tier for High
Availability
LESSON OVERVIEW
This lesson provides information on CMS clustering, web application deployment, and
declustering a deployment.
LESSON OBJECTIVES
CMS Clustering
CMS Clustering offers benefits for organizations with large or mission-critical
implementations of the BI platform.
Overview of CMS Clustering

Consider the following points:
● A cluster consists of two or more CMS servers working together against a common CMS
system database.
● Organizations with large or mission-critical implements usually run several CMS machines
together in a cluster.
● If a machine that is running one CMS fails, a machine running another CMS will continue to
service BI platform requests.
● This configuration provides high availability support, ensuring that BI platform users can
still access information when equipment fails.
Clustering Requirements
Requirements for Clustering CMS Machines
Ensure the following prerequisites and requirements are met when clustering CMS machines:
● Before clustering CMS machines, ensure that each CMS is installed on a system that
meets detailed requirements for the operating system and database components.
● The database server that hosts the system database must be able to process small
queries very quickly.
● Run each CMS cluster member on a machine that has the same amount of memory and
the same type of CPU as the other machines in the cluster.
● Configure each machine in the cluster in the same manner.

● If your cluster has more than eight CMS cluster members, ensure that the command line
for each CMS includes the out-of-band threads option.
● To enable auditing, configure each CMS to use the same auditing database and to connect
to it in the same manner.
Before clustering CMS machines, you must make sure that each CMS is installed on a system
that meets the detailed requirements (including version levels and patch levels) for the
operating system, database server, database access method, database driver, and database
client as outlined in the Product Availability Matrix.
For the best performance, the database server that you choose to host the system database
must be able to process small queries very quickly. The CMS communicates frequently with
the system database and sends it many small queries. If the database server is unable to
process these requests in a timely manner, BI platform performance will be greatly affected.
For best performance, run each CMS cluster member on a machine that has the same
amount of memory and the same type of CPU as the other machines in the cluster.
Configure each machine similarly using the following guidelines:
● Install the same operating system including the same version of operating system service
packs and patches.
● Install the same version of the BI platform (including patches, if applicable).
● Ensure that each CMS connects to the CMS system database in the same manner and
uses the same native or ODBC drivers. Make sure that the drivers are the same on each
machine and are a supported version.
● Ensure that each CMS uses the same database client to connect to its system database
and that it is a supported version.
● Check that each CMS uses the same database user account and password to connect to
the CMS system database. This account must have create, delete, and update rights on
the system database.
● Ensure that the nodes on which each CMS is located are running under the same operating
system account. On Windows, the default is the LocalSystem account.
● Verify that the current date and time are set correctly on each CMS machine (including
settings for daylight savings time).
● Ensure that all machines in a cluster (including the machines that host the CMS) are set to
the same system time. For best results, synchronize the machines to a time server (such
as time.nist.gov) or use a central monitoring solution.
● Ensure that the same WAR files are installed on all web application servers in the cluster.
For more information on WAR file deployment, see the SAP BusinessObjects Business
Intelligence Platform Installation Guide.
● Ensure that each CMS in a cluster is on the same Local Area Network.
Out-of-Band threads (-oobthreads) are used by clustering pings and clustering notifications.
Since both operations are quick (notifications are asynchronous), the BI platform no longer
requires multiple oobthreads, and only one -oobthread is created.
If your cluster has more than eight CMS cluster members, ensure that the command line for
each CMS includes the -oobthreads <numCMS> option, where <numCMS> is the number of
CMS servers in the cluster. This option ensures that the cluster can handle heavy loads. For

Lesson: Configuring the Management Tier for High Availability
information about configuring server command lines, see the server command lines appendix
in the SAP BusinessObjects Business Intelligence Platform Administrator Guide.
If you want to enable auditing, each CMS must be configured to use the same auditing
database and to connect to it in the same manner. The requirements for the auditing
database are the same as those for the system database in terms of database servers, clients,
access methods, drivers, and user IDs.
Hint:
By default, a cluster name reflects the machine host-name of the first CMS that
you install.
Additional Information about High Availability in the Management Tier

What are the requirements for a CMS cluster

and how do you test to confirm cluster com- http://service.sap.com/sap/support/
munication? notes/1229417
Business Intelligence Platform Administra- http://help.sap.com/businessobject/prod-
tor’s Guide uct_guides/sbo41/en/
sbo41sp3_bip_admin_en.pdf
SAP BusinessObjects Explorer Administra- http://help.sap.com/businessobject/prod-
tor’s Guide uct_guides/sbo41/en/
sbo41sp3_exp_admin_en.pdf
LESSON SUMMARY


Unit 5
Lesson 4
Configuring the Storage Tier for High
Availability
LESSON OVERVIEW
LESSON OBJECTIVES
FRS Overview
Overview of the File Repository System (FRS)
FileStore refers to the disk directories where the actual report files reside. The
BusinessObjects FRSs are responsible for listing files on the server, querying for the size of a
file, querying for the size of the entire file repository, adding files to the repository, and
removing files from the repository. FRSs are also responsible for the creation of file system
objects, such as exported reports and imported files in non-native formats.
In every BusinessObjects Enterprise implementation there is an Input and an Output FRS.
Both manage their respective directories and handle all aspects of file management.
The Input FRS manages all of the report objects and program objects that have been
published to the repository. It can
store .RPT, .CAR, .EXE, .BAT, .JS, .XLS, .DOC, .PPT, .RTF, .TXT, .PDF, .WID files. In the case
of .RPT files, they are stored only as report definition files which do not contain any data. The
Report Properties page of the CMC shows you the location of the Input report files.
The Output FRS manages all of the report instances (saved data copy of the report)
generated by the Report Job Server or the Web Intelligence Report Server, and the program
instances generated by the Program Job Server. It also manages instances generated by the
Web Intelligence Report Server and the LOV Job Server. It can store the following
files: .RPT, .CSV, .XLS, .DOC, .RTF, .TXT, .PDF, .WID.
For .RPT and .WID, files are stored as reports/documents with saved data.
Because the Output FRS stores the report instances, deleting instances would remove
instances not the actual reports. However the report structure will be stored in the Input FRS.
Use of SAN for the File Store

Using a Storage Area Network (SAN) for an SAP BusinessObjects BI platform provides the
following benefits:
● SANs typically provide low latency rates.

● SANs provide powerful replication features within a disaster recovery configuration.

● A mirrored SAN provides snapshot back-ups.
Configurations to Avoid
SAP recommends that you do not install Host Bus Adaptor (HBA) cards in each system for
the following reasons:
● An HBA is a hardware card with fiber channel links that connect directly to the SAN.
- With the HBA installed, the computer senses that it has a local disk installed within the
computer itself.
- It is, therefore, attempting to point the HBA card to the same logical unit number (LUN)
(that is, a patch of disk) on the SAN.
- As two programs can write to different parts of the same file at the same time and each
computer allows the modification, files can become corrupted.
- In theory, multiple FRS processes, running as active or passive, should prevent
corruption, but it still occurs.
FRS Installation Considerations

The following are considerations when installing FRSs "out of the box":
● Initially, each FRS points to a local directory on the server where it was installed.
● This configuration must be changed so file storage is done in a common area.
● In the event of failure, back-up FRSs can access files in the common area.
Proper FRS Installation: Set-up 1

One correct way to set up FRSs is to install an network-attached storage (NAS) head.
● An NAS head is an appliance detected by servers across the network as a file share.
● It manages file locking, because it knows that there is an SAN behind the NAS head.
● It is multi-faceted, appearing as a Windows server message block (SMB) share for
Windows clients or an NFS share for Unix clients.
● SAP BusinessObjects BI platform servers do not need HBA cards because they access the
share across the network using interface cards.

Another correct way to set up FRSs is to use Microsoft clustering to provide a highly-available
network file share. Consider the following points:
● The disk behind the clustered servers can either be a mirrored disk or an SAN.
● The Microsoft server is referenced by the uniform naming convention (UNC) name.
● Only one member of the cluster has a connection to the SAN at any time.
● The clustering takes care of the fail-over when something fails.
● Two FRS pairs can point to the same UNC path.

Lesson: Configuring the Storage Tier for High Availability

A third way to set up FRSs is to use HBA cards, but make the computers aware that the patch
of disk is being shared. Consider the following points:
● HBA cards are used in each server, and a special SAN-aware software driver is installed.
● The driver resides above the HBA, and they are in constant communication with each
other, managing file locking and preventing file corruption.

A fourth way to set up FRSs is to ensure that the SAN is mounted to only one server at a time.
● In the event of failure, server 1 is down.

● The file share is unmounted from server 1 from the SAN end.
● The file share is mounted on server 2 at the SAN end.
● Server 2 is brought up.
● The FRS processes become functional again.

A fifth way to set up FRSs is to locate the file share on a Window cluster. Consider the
following points:
● Create a shared, common clustered folder on another host across the network.
For Windows, create a Network SMB share; for Unix, create an NFS or CIFS.
● Point the FRS pairs to the new folder.
● If you lose one of the servers within the cluster where the files are stored, the backup FRS
pairs can still access the files through the cluster.
● The process is not highly available; it takes several seconds to switch over. However, it is
inexpensive, safe, and reliable. It can also be scripted.
LESSON SUMMARY


Unit 5
Lesson 5
Configuring the Processing Tier for High
Availability
LESSON OVERVIEW
In this lesson, we will review concepts of high availability across the SAP BusinessObjects
Platform processing tier.
LESSON OBJECTIVES
Overview of High Availability in the Processing Tier

High availability can be achieved in the processing tier by including additional servers in your
organization’s deployment.
High Availability in the Processing Tier

To achieve high availability in the processing tier, add the following servers to your
organization’s deployment:
● Adaptive Processing Servers (APSs)

● Cache Servers
● Report Servers
● Web Intelligence Processing Server
Adaptive Processing Servers (APSs)

Creation of APSs
You can create APSs in the following two ways:
● Run the System Configuration Wizard.

● Use the CMC to manually create and configure additional APSs.
Note:
Selecting a deployment template in the wizard or manually creating additional
APSs does not replace system sizing. For more information about BI sizing, go
to http://www.sap.com/bisizing.

System Configuration Wizard

The wizard helps you with the basic configurations of your BI platform system, including
configuring APSs according to predefined deployment templates. The APS configuration
provided by the wizard is a good starting point; however, system sizing must still be
performed.
The wizard is available from the Central Management Console (CMC). For more information
about the wizard, see Introduction to the System Configuration Wizard .
For more information about default deployment templates, see the SAP BusinessObjects BI
platform Deployment Templates document, which is available from within the wizard, and
also at http://help.sap.com/bobip41.
Features of the System Configuration Wizard

The following are features of the System Configuration Wizard:
● Simple workflow to accomplish initial server configuration of the BI system

● Command-line facility to enable programmatic configuration
● Installation of additional APSs that can be configured to meet requirements
Uses for APSs

The installation program installs one APS per host system. Depending on the features that
you've installed, this APS may host a large number of services, such as the Monitoring
Service, Promotion Management Service, Multi-Dimensional Analysis Service (MDAS),
Publishing Service, and others.
A generic server hosts services responsible for processing requests from a variety of sources.
For production or test systems, the best practice is to create additional APSs, and then
configure the APSs to meet your organization’s business requirements.
Report Servers
SAP Crystal Reports 2020 Report Application Server (RAS)
The following are the benefits of using SAP Crystal Reports 2020 Report Application Server
(RAS):
● It provides ad-hoc reporting capabilities.

● It allows users to create and modify Crystal reports using SAP Crystal Reports Server
Embedded Software Development Kit (SDK).
Crystal Reports Processing Server

The following capabilities are provided by the Crystal Reports Processing Server:
● Responds to page requests from Crystal Reports for Enterprise.

● Retrieves data for the report from the latest instance or directly from the data source.
● Generates the report and converts the data to encapsulated page format (EPF) files.
● EPF files are sent to the Crystal Reports Cache Server.
● EPF supports page-on-demand, so only the requested page is returned, not the entire
report.

Lesson: Configuring the Processing Tier for High Availability
● Improves system performance and reduces unnecessary network traffic.
Web Intelligence Processing Server

The following are functions of the Web Intelligence Processing Server:
● It is responsible for generating Web Intelligence documents.

● It obtains document creation requests from the Web Application Server.
● It then communicates with the Input File Repository Server to obtain a copy of the Web
Intelligence document (WID) and the universe definition.
● If an instance of the WID already exists, the Web Intelligence Processing Server obtains the
existing historical instance of the WID from the Output File Repository Server.
Deployment Template Overview

Reasons for Changing from the Default Deployment Size
The BI platform configures a small deployment. The following are considerations when
deploying the BI platform:
● The default small deployment is suitable only for a demo environment on limited hardware.
● You can choose a predefined deployment template to better match your hardware and use
cases.
● Although the template helps with the initial configuration, it does not replace system sizing
and configuration efforts.
The default installation of the BI platform configures a small deployment that is suitable for a
demo environment on limited system hardware. To better match your hardware and intended
use case (for example, preparing a test system or production system), choose one of the
predefined deployment templates from the Capacity view. These templates are intended to
help the BI platform system up and running quickly, and to shorten the initial deployment
time.
Although, choosing an appropriate deployment template helps with the initial configuration
and provides a good starting point, it is not a replacement for system sizing and configuration,
which must be performed. For best performance, size your system by referring to a sizing
guide: http://www.sap.com/bisizing
Considerations When Choosing a Template

Choosing an appropriate deployment template is important for several reasons:
● The request handling capacity of your system is affected by the deployment template you
select. A larger deployment provides greater capacity to handle more requests or more
complex requests. However, a larger deployment requires more system resources.
● Choosing a large deployment does not guarantee better performance, particularly when
you do not have sufficient hardware resources.
● The deployment template should match your business needs and your available hardware
resources. If you choose a deployment template that is too small for your business needs,
or too large for the available hardware resources, the system might suffer reduced
capacity and performance.

● Larger deployment templates provide good compartmentalization. Failures in one product

are unlikely to affect other products. Choose a template that balances resource (RAM)
utilization and performance. For example, if a large amount of RAM is available, you might
want to pick the biggest deployment template that your RAM permits. This will result in
good system compartmentalization.
Note:
The DeploymentTemplates.pdf file describes the deployment templates in
detail. The templates do not specify the number of users that can be supported
because the number of users that can be supported is dependent on load.
Perform the system sizing to determine the number of users that the system must
support, and therefore the amount of RAM, CPU requirements, and all other
system requirements necessary to determine the size of the deployment you
need.
Types of Deployment Template

The following types of deployment templates are available:
● XS: This extra small deployment is typically used as a demo system.

● S: This small deployment is typically used as a development system.
● M: The medium deployment is typically used a test or small production system.
● L: This large deployment is typically used as a production system.
● XL: This extra large deployment is typically used as a large production system.
XS Deployment Template
The XS template is an extra small deployment. This deployment requires 6–8 GB of RAM, 8
GB of Host RAM, and uses one APS. This deployment is typically used as a demo system.
S Deployment Template
The S template is a small deployment template. This deployment requires 12–16 GB of RAM,
16 GB of Host RAM, and uses four APSs. This deployment is typically used as a development
system.
M Deployment Template
The M template is a medium deployment template. This deployment requires 15–25 GB of
RAM, 16–32 GB of Host RAM, and uses 7 APSs. It is typically used as a test production system
or small production system.
L Deployment Template
The L template is a large deployment template. This deployment requires 30–45 GB of RAM,
32–48 GB of Host RAM, and uses 9 APSs. It is typically used as a production system.
XL Deployment Template
The XL template is an extra large deployment template. This deployment requires 40–60 GB
of RAM, 48–64+ GB of Host RAM, and uses 11 APSs. It is typically used as a large production
system.

Lesson: Configuring the Processing Tier for High Availability
LESSON SUMMARY


Unit 5
Lesson 6
BI Platform Pattern Books and Best Practices
for Deployment
LESSON OVERVIEW
In this lesson, we will discuss best practices for deploying SAP BusinessObjects Platform
using Pattern Books.
LESSON OBJECTIVES
Pattern Overview
SAP BusinessObjects BI Platform Deployment in the Real World
In addition to installation efforts, deployment of the BI platform involves the following efforts
to fully leverage the platform:
● Set up firewalls, reverse proxy servers, and load balancers.

● Configure your company’s existing software, such as application servers and database
servers.
● Install and configure BI platform software on multiple machines for scalability and
redundancy.
● Integrate with your company’s existing security infrastructure.
Note:
Setup instructions vary for different operating systems, application server
vendors, and database vendors.

Figure 71: Deployment Patterns
Pattern Prerequisites
Best Practices for BI Deployment: Part I
When designing the architecture, consider the following best practices for BI deployment:
● Size the environment for target usage.

● Deploy BI platform on dedicated hardware.
● Deploy Web Tier on separate server(s) outside the BI platform.
● Deploy CMS and audit databases on separate server(s) outside the BI platform.
● Separate BI platform management tier and processing tiers.
- Isolate the Management and Processing Tiers.
- Limit overall performance impact caused by either set of services.
- Troubleshoot and debug.
● When designing the architecture for high availability, eliminate single points of failure.
- Enable CMS clustering.
- Add redundant hardware.
- Add redundant BI platform services.
- Enable Web Tier clustering.

Lesson: BI Platform Pattern Books and Best Practices for Deployment
Best Practices for BI Deployment: Part II

● Enable high availability for CMS database and FRS file share.
- Use existing technologies outside of BI platform.
● Separate environments for development, testing, and production.
● Have at least one pre-production environments configured similar to the production
environment.
- Allow install and configuration cookbook for production environment.
- Allow contents to be tested in a production-like environment.
- Allow production issues to be reproduced for troubleshooting in a non-production
environment.
● All environments should be on the same BI platform release.
● All environments should have same operating system version, patches, and upgrades.
● Plan for content promotion.
Best Practices for BI Deployment: Part III

● Enable auditing to capture system usage.

● Design and implement the content security model.
● Use physical servers and dedicated resources.
● Keep requirements and differences in mind if using VMWare Virtual Hosts.
● Use Network Optimizer Tool in Global Deployment.
● Use Session Stickiness or Persistence with Load Balancer.
Details of Best Practices for BI Deployment

The CMS Database can be moved to a DB2 database. When designing the architecture,
consider these best practices for BI deployment:
● All environments should be on the same BI platform version and release.
● All environments should have the same operating system version, patches, and upgrades.
● Plan for content promotion as follows:
- Development activities should only be performed in the development environment.
- Use strict rules for content promotion.
- Use Life Cycle Manager tool for content promotion
- Ad hoc Documents are not transferred from development or test to production. They
are immediately created in the production environment by end users.
● Enable auditing to capture system usage.

● Design and implement a content security model.

● Use physical servers and dedicated resources
VMWare Virtual Hosts

When using VMWare Virtual Hosts, keep the following in mind:
● Virtual Servers perform slower than physical servers, if not properly tuned.
● Ensure the BI platform application always has a minimum reservation of CPUs and
memory.
● Ensures BI platform application gets resources when it needs them.
● Rotating CPU usage degrades BI platform performance.
● Use VM CPU Affinity to allow the VM to run on specific host processors.
● Add 20% to BI platform sizing to account for VMWare overhead.
● Size and allocate virtual resources to minimize the likelihood of resource contention.
● Use session stickiness or persistence with Load Balancer.
- It ensures user requests are directed to the same back-end server
Note:
Refer to SAP BusinessObjects Statement of Support for VMWare.
Network Optimizer Tool

Use Network Optimizer Tool for global deployment.
Note:
Refer to Optimize Application Delivery for Global Deployment whitepaper.
● It reduces network bandwidth.

● It enables faster response time.
Pre-Installation Checklist
Architecture Design for BI Reporting Pre-Installation Check List: Part I
In addition to reviewing the product platform support guide, ensure you have performed the
following before installation:
● Review the product platform support guide.

● Ensure software binaries are copied locally on the server.
● Ensure you have acquired product license keys.
● Ensure CMS and audit databases are available and are UTF-8–enabled.
● Ensure Database middleware is installed and configured.
● Ensure servers can communicate with CMS and audit databases.

Lesson: BI Platform Pattern Books and Best Practices for Deployment
● Ensure servers have sufficient free disk space.
Architecture Design for BI Reporting Pre-Installation Check List: Part II

In addition to reviewing the product platform support guide, ensure you have performed the
following before installation:
● Verify that the port number to be used for CMS is free and available.
● Verify connectivity to the CMS using the NetBIOS name of the CMS.
● Verify the Web Server has connectivity with the Web Application Server
● On Windows Platform, perform the following:
- Install user must have local administrator’s rights.
- Do not set up a Windows Server as a domain controller.
- Ensure Windows servers have performance options configured to give background
services priority.
Installation Best Practices

Architecture Design for BI Reporting Installation Best Practices
On Windows platform, perform the following actions:
● Disable anti-virus software before installation.

● Use Add or Remove Programs to run the installation.
● Install software in a non-OS Drive (or Data Drive) such as, D:\ or E:\
● Keep install directory path name short.
For example, use installation directory path D:\SAPBOBJ
● Avoid special charters in the installation path name.

For example, avoid installation directory path C:\Program Files (x86).
Installation Verification
Installation Verification for Architecture Design
After BI platform installation, verify that its components are installed successfully.
● Review the install log:

C:\Program Files (x86)>SAP Business
Objects>InstallData>logs>setupengine.log
● To launch the SAP BusinessObjects BI platform Java BI Launchpad, open a web browser
and navigate to the following URL:
http://<servername>:<portnumber>/BI
● To launch the SAP BusinessObjects BI platform Central Management Console, open a web
browser and navigate to the following URL:
http://<servername>:<portnumber>/CmcApp

● To launch the SAP BusinessObjects BI platform Explorer, open a web browser and
navigate to the following URL:
http://<servername>:<portnumber>/explorer
Additional Information about System Landscapes and Patterns

SAP BusinessObjects Business Intelligence http://help.sap.com/bobip

platform 4.1
BIP on Windows with Mobile and Explorer http://wiki.scn.sap.com/wiki/display/
Pattern Book BOBJ/BIP+on+Windows+with+Mobile+and
+Explorer+Pattern+Book?original_fqdn=wi-
ki.sdn.sap.com
SAP Community Network http://www.sdn.sap.com/
1497394 - Which files and directories should http://service.sap.com/sap/support/
be excluded from an antivirus scan for SAP notes/1497394
BusinessObjects Business Intelligence Plat-
form products
Official Product Tutorials – SAP BI Suite http://scn.sap.com/docs/DOC-7725
LESSON SUMMARY

Unit 5
Lesson 7
Administering Server Groups
LESSON OVERVIEW
This lesson explains how to modify server group membership, clone servers, and configure
server groups. It also provides information on how to set up the BI platform servers, including
troubleshooting and debugging.
LESSON OBJECTIVES
Server Groups
Server groups provide a way of organizing your SAP BusinessObjects BI platform servers to
make them easier to manage.
Server Groups Overview

The following are considerations when using server groups:
● When you manage a group of servers, you need to view only a subset of all the servers on
your system.
● Server groups are a powerful way of customizing SAP BusinessObjects BI platform to
optimize your system for users in different location or for objects of different types.
If you group your servers by region, you can easily set up default processing settings,
recurrent schedules, and schedule destinations that are appropriate to users who work in a
particular regional office. You can associate an object with a single server group, so the object
is always processed by the same servers. Also, you can associate scheduled objects with a
particular server group to ensure that scheduled objects are sent to the correct printers, file
servers, and other resources. As a result, server groups prove to be especially useful when
maintaining systems that span multiple locations and multiple time zones.
If you group your servers by type, you can configure objects to be processed by servers that
have been optimized for those objects. For example, processing servers need to
communicate frequently with the database containing data for published reports. Placing
processing servers close to the database server that they need to access improves system
performance and minimizes network traffic. Therefore, if you had a number of reports that
ran against a DB2 database, you might want to create a group of Processing Servers that
process reports only against the DB2 database server.
If you then configure the appropriate reports to always use this Processing Server group for
viewing, you optimize system performance for viewing these reports. After creating server
groups, configure objects to use specific server groups for scheduling or for viewing and
modifying reports. Use the navigation tree in the Servers management area of the CMC to
view server groups. The Server Groups List option displays a list of server groups in the details
pane, and the Server Groups option allows you to view the servers in the group.

To Create a Server Group

To create a server group, you need to specify the name and description of the group, and then
add servers to the group.
1. In the CMC, navigate to the Servers management area.
2. Choose Manage → New → Create Server Group. The Create Server Group dialog box
appears.
3. In the Name field, enter a name for the new group of servers.
4. In the Description field, enter additional information about the group. Choose OK.
5. In the Servers management area, in the navigation tree, choose Server Groups and select
the new server group.
6. In the Actions menu, choose Add Members.
7. Select the servers that you want to add to this group, and then choose the > arrow. Use
CTRL+click to select multiple servers.
8. Click OK.
You return to the Servers management area, which now lists all the servers that you added to
the group. You can now change the status, view server metrics, and change the properties of
the servers in the group.
Server Subgroups
Subgroups of servers provide you with a way of further organizing your servers.
Server Subgroups Overview

The following are considerations when using server subgroups:
● A subgroup is just a server group that is a member of another server group.

● There are two ways to set up subgroups: you can modify the subgroups of a server group,
or you can make one server group a member of another. The results are the same, so use
the most convenient method.
For example, if you group servers by region and by country, then each regional group
becomes a subgroup of a country group. To organize servers in this way, first create a group
for each region, and add the appropriate servers to each regional group. Then, create a group
for each country, and add each regional group to the corresponding country group.
To Add Subgroups to a Server Group
2. To select the parent group to add subgroups to, in the navigation tree, choose Server
Groups and choose the server group you want.
This group is the parent group.
3. In the Actions menu, choose Add Members.
4. In the navigation tree, choose Server Groups, choose the server groups that you want to
add to this group, and then choose the arrow (>).

Lesson: Administering Server Groups
Use CTRL+click to select multiple servers.
5. Choose OK.
You return to the Servers management area, which now lists the server groups that you
added to the parent group.
To Make One Server Group a Member of Another Server Group
2. Choose the group that you want to add as a member to another group.
3. In the Actions menu, choose Add to Server Group.
4. In the Available server groups list, choose the other groups that you want to add the group
to, and then choose the arrow (>).
Use CTRL+click to select multiple servers.
5. Choose OK.
Modification of the Group Membership of a Server
● You can modify a server’s group membership to add the server to (or remove it from) any
group or subgroup that you have already created on the system.
● For example, if you create server groups for a number of regions, you might want to use a
single Central Management Server (CMS) for multiple regions.
● Instead of having to add the CMS individually to each regional server group, you can
choose the server’s Member of link to add it to all the regions at once.
To Modify the Group Membership of a Server
2. Locate the server whose membership information you want to change.
3. In the Manage menu, choose Properties.
4. In the Properties dialog box, in the navigation list, choose Existing Server Groups.
In the Details panel, the groups you can add to the server appear in the Available server
groups list. Any server groups that the server currently belongs to appear in the Member
of Server Groups list.
5. To change the server's group membership, use the arrows to move the server groups
between the lists, and choose OK.
Administrative Access to Servers and Server Groups for Users

The following are considerations when assigning administrative access to servers and server
groups:
● Administrative rights allow user to start and stop servers.

● Server management can be limited to only the BI platform administrator.

● Sometimes, administrative access must be granted to other people using servers.
Granting administrative rights to users enables them to perform server and server group
tasks, such as starting and stopping servers. Depending on system configuration and security
concerns, you might want to limit server management to the BI platform administrator, or you
might need to provide administrative access to other people using those servers.
Many organizations have a group of IT professionals dedicated to server management. If your
server team needs to perform regular server maintenance tasks that require them to shut
down and start up servers, you need to grant them administrative rights to the servers. You
may also want to delegate BI platform server administration tasks to other people or want
some groups in your organization to control their own server management.
Note:
You can select a server or server group for a publication (not for a particular user).
However, you can assign administrative rights to users or user groups for a
particular server or server group.
To Assign Administrative Rights to Users or User Groups for a Server or Server Group
You can assign administrative rights to users or user groups for a particular server or server
group.
2. To grant administrative access rights, right-click the server or server group you want, and
choose User Security.
3. Choose Add Principals.
4. To give administrative rights to the server or server group, in the Add Principals dialog box,
choose a user or group, and then choose the arrow (>).
5. Choose Add and Assign Security.
6. On the Assign Security screen, choose security settings for the user or group, and choose
OK.
LESSON SUMMARY

Unit 5
Learning Assessment
1. Which layer is not part of a horizontal architecture?

X A Application Server layer
X B Connector layer
X C External layer
X D Web Server layer
2. Which of the following choices is not a deployment option?

X A Single-server deployment
X B Multi-server distributed deployment
X C Internal network deployment
X D Single-CMS deployment
X E Scaling up and scaling out
X F High-availability deployment

X A It is highly advisable to hide BI servers behind a firewall.
X B Demilitarized Zones (DMZs) are areas of the network that are separated from the
internet by an outward facing firewall and separated from the rest of the internal
X C A widely accepted standard is to run all code inside the first DMZ.
X D Web servers have weak points, and it is good practice to not allow Web servers in
any of your DMZs.


X A A cluster consists of two or more CMS servers working together against a common
X B Organizations with large or mission-critical implements usually do not cluster CMS

machines.
X C If a machine that is running one CMS fails, a machine running another CMS will
continue to service BI platform requests.
X D Each machine in a cluster should be configured different to match the

requirements for the services on the machine.

X A The Input FRS manages all the report objects and program objects that have been
published to the repository.
X B The Output FRS manages all the report instances generated by the Report Job
Server or the Web Intelligence Report Server.
X C The Output FRS manages program instances generated by the Program Job
Server, the Web Intelligence Report Server, and the LOV Job Server.
X D Not every implementation requires an Input and Output FRS pair.
6. High availability can be achieved in the processing layer by including which of the following
components in your organization’s deployment?
X A Adaptive Processing Server
X B Cache Servers
X C Report Servers
X D Web Intelligence Processing Server

7. What is the first step to choosing a deployment template?

X A Available Hardware assessment
X B System sizing
X C User survey
X D Use assessment

X A The SAP BusinessObjects Business Intelligence platform can run on only one
machine at a time.
X B Data can be analyzed from a large number of supported database system

(including text or multi-dimensional OLAP systems).
X C The BI platform uses its own databases for storing configuration, auditing, and
other operational information.
X D To fully leverage the BI platform in your organization, you simply have to install it—
no other actions are necessary.
9. What are the two ways that you can set up subgroups?
X A Modify the subgroups of a server group
X B Separate each server group
X C Delete the alternative server group
X D Make one server group a member of another

Unit 5
1. Which layer is not part of a horizontal architecture?

X A Application Server layer
X B Connector layer
X C External layer
X D Web Server layer
2. Which of the following choices is not a deployment option?

X A Single-server deployment
X B Multi-server distributed deployment
X C Internal network deployment
X D Single-CMS deployment
X E Scaling up and scaling out
X F High-availability deployment

X A It is highly advisable to hide BI servers behind a firewall.
X B Demilitarized Zones (DMZs) are areas of the network that are separated from the
internet by an outward facing firewall and separated from the rest of the internal
X C A widely accepted standard is to run all code inside the first DMZ.
X D Web servers have weak points, and it is good practice to not allow Web servers in
any of your DMZs.


X A A cluster consists of two or more CMS servers working together against a common
X B Organizations with large or mission-critical implements usually do not cluster CMS

machines.
X C If a machine that is running one CMS fails, a machine running another CMS will
continue to service BI platform requests.
X D Each machine in a cluster should be configured different to match the

requirements for the services on the machine.

X A The Input FRS manages all the report objects and program objects that have been
published to the repository.
X B The Output FRS manages all the report instances generated by the Report Job
Server or the Web Intelligence Report Server.
X C The Output FRS manages program instances generated by the Program Job
Server, the Web Intelligence Report Server, and the LOV Job Server.
X D Not every implementation requires an Input and Output FRS pair.
6. High availability can be achieved in the processing layer by including which of the following
components in your organization’s deployment?
X A Adaptive Processing Server
X B Cache Servers
X C Report Servers
X D Web Intelligence Processing Server

7. What is the first step to choosing a deployment template?

X A Available Hardware assessment
X B System sizing
X C User survey
X D Use assessment

X A The SAP BusinessObjects Business Intelligence platform can run on only one
machine at a time.
X B Data can be analyzed from a large number of supported database system

(including text or multi-dimensional OLAP systems).
X C The BI platform uses its own databases for storing configuration, auditing, and
other operational information.
X D To fully leverage the BI platform in your organization, you simply have to install it—
no other actions are necessary.
9. What are the two ways that you can set up subgroups?
X A Modify the subgroups of a server group
X B Separate each server group
X C Delete the alternative server group
X D Make one server group a member of another

UNIT 6 Content Management Planning
Lesson 1
Preparing to Manage Content 219
Lesson 2
Upgrading to SAP BusinessObjects 4.3 223
Lesson 3
Managing the Life Cycle of a Deployment 227
Lesson 4
Moving Objects from One Deployment to Another 243
UNIT OBJECTIVES
● Describe the content management process and tools

● Understand update scenarios for SAP BusinessObjects 4.3
● Describe the life cycle of a deployment
● Manage the life cycle of a deployment using the Life Cycle Management (LCM) tool
● Create a new job
● Manage job dependencies
● Schedule and roll back jobs
● Identify factors that affect life cycle management
● Apply best practices for managing the life cycle of a deployment
● Compare objects and files

Unit 6: Content Management Planning

Unit 6
Lesson 1
Preparing to Manage Content
LESSON OVERVIEW
This lesson reviews the content management tools and process.
LESSON OBJECTIVES
Content Management Overview

Managing BI content in BusinessObjects is one of the most interesting and challenging tasks
for every BusinessObjects Architect and Administrator. Proper content management will help
Administrator and Application support teams to manage their environment effectively
because it has a direct implication with content promotion, instance management, and
security modes across different environments.
Content Management Plan
● In general, a content management plan would be useful in the following scenarios:

- A new BusinessObjects implementation project
- A migration project where the content is poorly managed or has virtually no content
management strategy
- A maintenance project where there is frequent additions of BI content without proper
folder setup
Life Cycle Management Business Intelligence Archive Resource (LCMBIAR) Files

LCMBIAR files
The following are considerations when using LCMBIAR files:
● LCMBIAR files contain compressed business intelligence content.

● They can be easily moved.
● They can be selected as the source or destination during a content promotion job.
LCMBIAR files contain compressed business intelligence content. This content can be easily
moved to a different location or SAP BusinessObjects Business Intelligence platform
deployment.
During a content promotion job, you can select an LCMBIAR file as the source or destination if
you cannot connect to two Central Management Servers directly (for example, if your
destination and source deployments are on different physical networks).

Promotion Management Tool

Life cycle Management Definition
● Life cycle management refers to the entire process of designing, developing, and
maintaining an application solution.
● Life cycle management also encompasses the effort to optimize the solution with ongoing
improvements.
● The Promotion Management Tool (PMT) is used only for the BI content life cycle.
For SAP products, life cycle management refers to the complete process surrounding an
application, including gathering the initial requirements, designing the solution, building and
testing the solution, deploying the solution, the ongoing operation of that solution, and the
optimizing of that solution to improve it over time. Ongoing improvements can lead to further
requirements that would then be rolled into a subsequent iteration. So the term “life cycle
management” covers many topics: installation, deployment, change management,
administration, auditing, monitoring, and troubleshooting. The Promotion Management Tool
(PMT) for SAP BusinessObjects BI 4.3 is used only for the BI content life cycle. BI content life
cycle management services are specifically focused on managing the ongoing life cycle for BI
content.
Tool Choices for BI 4.3 Use Cases

Tools for Upgrade and Promotion
● Promotion Management Tool

This tool transports versioned content from one system to another in small, incremental
packages.
● Promotion Management Wizard
This tool provides a Graphic User Interface (GUI) for performing a full copy or a selective
copy of one system to another.
There are two primary tools for upgrade and promotion: the Promotion Management Tool and
the Promotion Management Wizard.
The Promotion Management Tool (previously known as the LCM) transports versioned
content from one system to another system in small, incremental packages. For example, you
can promote content from Development to Test to Production. Content includes primarily
document templates, metadata, and schedules, not document instances. This tool moves 100
objects or less. This tool is not meant to be used for upgrades.
Promotion Management Wizard
The Promotion Management Wizard is a tool that aims to ease the task of CMS content copy.
Instead of using the Command Line Interface (CLI), Promotion Management Wizard offers a
Graphic User Interface (GUI) for performing a full copy or a selective copy. LCMBIAR files are
the same compared to the CMC or CLI versions of Promotion Management. It is a Thick-client
(Full Client GUI) tool that is installed along with the server products

Lesson: Preparing to Manage Content
LESSON SUMMARY


Unit 6
Lesson 2
Upgrading to SAP BusinessObjects 4.3
LESSON OBJECTIVES
SAP BusinessObjects Update Paths

You can migrate your system data and business intelligence content from the previous BI 4.x
versions to SAP BusinessObjects Business Intelligence platform 4.3. The Upgrade
Management Tool is deprecated in SAP BusinessObjects Business Intelligence platform 4.3,
however, you can follow the below mentioned upgrade paths to move to 4.3.
Figure 72: Scenarios for Upgrading to SAP BusinessObjects 4.3
If you have an older deployment, follow these guidelines to upgrade your existing deployment
to BI platform 4.3:
1. If your existing deployment is of XI R2, XI MHF1, XI R2 SP1, BusinessObjects 5/6, or

Crystal Enterprise 9/10, you must first upgrade to XI R2 SP2 (or higher) and proceed from
step 3.
2. If your existing deployment is of XI 3.x, you can directly proceed with the upgrade in step
3.
3. Install BI 4.1/4.2 SPx on a separate machine, and run Upgrade Management Tool from the
4.1/4.2 SPx to migrate the content from the above-mentioned versions to BI 4.1/4.2 SPx
level.

4. Once you have your content in BI 4.1/4.2 SPx level, you can choose either of the methods
in the previous figure to move to 4.3.
Promotion Management Wizard

One of the illustrated upgrade paths above mentions the usage of any promotion
management tool to promote content from BIP42 to a newly installed BIP43 system. This
scenario is especially helpful for organizations that are opting to purchase new hardware for
their BIP43 installation. Administrators have the option of downloading and using the
Promotion Management wizard to perform the update.
The Promotion Management Wizard is a tool that aims to ease the task of CMS content copy.
Instead of using the Command Line Interface (CLI), Promotion Management Wizard offers a
Graphic User Interface (GUI) for performing a full copy or a selective copy. LCMBIAR files are
the same compared to the CMC or CLI versions of Promotion Management. It is a Thick-client
(Full Client GUI) tool that is installed along with the server products.
Promotion Management Wizard is a step-based user interface:
● Welcome step
● Scenario step
● Objects step
● Dependencies (only for selective content promotion)
● Summary step
● Finish step
The Promotion Management Wizard does not create a job that can be reused in the Central
CMS. This saves some space on the host system.
Prior to making a scenario selection, ensure you have enabled the following options:
● Go to options of the Objects step.
Figure 73: Objects Step Options
● Select Exclude Dependencies.
Figure 74: Exclude Dependencies
● Check Object Security. If necessary, check Top Level Security.

Lesson: Upgrading to SAP BusinessObjects 4.3
Figure 75: Object Security
LESSON SUMMARY


Unit 6
Lesson 3
Managing the Life Cycle of a Deployment
LESSON OVERVIEW
This lesson details the deployment lifecycle and how to manage the lifecycle with the Life
Cycle Management tool. This lesson also reviews how to create a new job, manage job
dependencies, and schedule and roll back jobs. Lastly, this lesson teaches basic version
management and best practices for managing the lifecycle of a deployment.
LESSON OBJECTIVES
Life Cycle Management Process

For SAP products, life cycle management refers to the complete process surrounding an
application.
Life Cycle Management Definition
● Lifecycle management refers to the entire process of designing, developing, and

● Lifecycle management also encompasses the effort to optimize the solution with ongoing
improvements.
● The phases of a lifecycle can occur at the same site or at different geographical locations.
● Resources are transferred from one repository to another repository. Their dependencies
add complexity to the move process.
Lifecycle management includes gathering the initial requirements for an application,

designing the solution, building and testing the solution, deploying the solution, the ongoing
operation of that solution, and optimizing the solution to improve it over time. Ongoing
improvements can lead to further requirements that are rolled into a subsequent iteration.
Lifecycle management also describes the change management, administration, auditing,
monitoring, and troubleshooting of an application.

Lifecycle management refers to the set of processes involved in managing information related
to a product’s life cycle and establishes procedures for governing the entire product life cycle.
These phases can occur at the same site or at different geographical locations.
The BI resources that are present in the development repository must be transferred to the
testing repository for testing deployment. The time required to transfer resources from one
repository to another repository must be minimal to obtain a high-quality and competitive
product. These resources also have dependencies that have to be moved from one repository
to another. The dependencies add complexity to the movement of resources because the
resources have to move with their dependents.
Figure 76: Lifecycle Management Process
The Lifecycle Management Console for SAP BusinessObjects Business Intelligence platform
4.3 is now integrated into CMC as the Promotion Management tool, which enables you to
move BI resources from one system to another without affecting the dependencies of the
resources. It also enables you to manage different versions of BI resources, manage
dependencies of BI resources, and roll back a promoted resource to restore the destination
system to its previous state.

Lesson: Managing the Life Cycle of a Deployment
Figure 77: BI Resources Moved to Another System
Importance of Life Cycle Management

Industry regulations (such as the Sarbanes-Oxley Act and HIPPA) require new levels of rigor
when moving content between environments. Lifecycle management of business intelligence
content can help you maintain these requirements with the following features:
Life Cycle Management Requirements and Regulations

Internal controls are required to manage how changes are made, who can access production
systems, and synchronizing changes across complex system landscapes, as follows:
● Reports need to be correct and on time with minimal downtime.

● Changes to systems, data, and processes must be thoroughly tested.
● Sensitive data must be protected.
● Business intelligence has become mission critical.
● Costs can be reduced by avoiding errors, rework, and system downtime.
● Security can be increased by enabling recovery from errors and malicious acts and by
safeguarding information.
Console Overview: Life Cycle Management (LCM)

The Promotion Management tool is also know as the Life Cycle Management Console.
Overview of the Life Cycle Management Console
● The Promotion Management tool has the following uses:

- It is used only for managing the ongoing life cycle for BI content.
- With this tool, administrators can package BI content and promote efficiently it through
multiple environments.

- Administrators can also manage multiple versions of the same BI resources.

- The tool is integrated with the Central Management Console (CMC).
The Promotion Management tool, also known as the Life Cycle Management Console, for SAP
BusinessObjects BI 4.x is used only for the BI content life cycle. BI content life cycle
management services focus on managing the ongoing life cycle for BI content. This tool
allows BI administrators and operations teams to package BI content and associated
dependencies and to promote that content in an efficient, reliable, and repeatable fashion
through multiple environments. BI content life cycle management is a subset of this larger
topic, primarily in the test and deploy phases.
The promotion management tool allows moving BI resources from one repository to another,
manages dependencies of the resources, and rolls back promoted resources at the
destination system, if required. It also supports the management of different versions of the
same BI resource.
The promotion management tool is integrated with the Central Management Console. You
can only promote a business intelligence resource from one system to another if the same
version of the BI platform is installed on both the source and destination systems.
Many BI deployments contain different stages such as development, testing, and production.
Reports and other BI objects often require modification or enhancement due to changing
information and business requirements. Administrators must control how objects are
promoted through these stages, whether the objects are completely new, or the objects have
the rights to overwrite or update the objects that already exist in the destination environment.
Figure 78: Promotion of Multiple Environments
LCM Functions
Features of the Promotion Management Tool
The following are features of the Promotion Management Tool:
● BI content promotion
● Dependencies management
● Job scheduling

● Security rights promotion

● Promotion testing
● Restoration (roll-back) to a previous state
● Event monitoring in the auditing database
● Configuration of tool parameters
● Version management
● Promotion override
The Promotion Management tool supports the following features:

● Promotion - This feature enables you to perform the following tasks:
- Create and update infoobjects in the destination system.
- Create a new job.
- Copy an existing job.
- Edit a job.
- Schedule a job promotion.
- View the history of a job.
● Managing Dependencies - This feature enables you to select, filter, and manage
dependents of infoobjects in the job that you want to promote.
● Scheduling - This feature enables you to specify a time for job promotion rather than
promote a job as soon as it is created. You can schedule the time for a job promotion by
hour, day, week, or month.
● Security - This feature enables you to promote infoobjects with their associated security
rights. You can also use this feature to promote infoobjects associated with application
rights.
● Test Promotion - This feature enables you to check or test the promotion to ensure that all
the preventive measures are taken before the actual promotion of the infoobjects.
● Rollback - This feature enables you to restore the destination system to its previous state
after a job is promoted. You can roll back an entire job or a part of the job.
● Auditing - The events generated by the Promotion Management tool are stored in the audit
database. The Auditing feature enables you to monitor the events that are logged in the
audit database.
● Administration options - This feature enables the administrator to configure the
parameters of the Promotion Management tool..
● Version Management - This feature enables you to manage different versions of the same
document. It also enables you to track the changes in the directory. This is now a separate
area under the Manage Section within BI 4.3 CMC.
● Promoting Overrides - This feature enables you to promote the overrides through a job
promotion.

Overview of Promotion and Version Management Workflows

● The promotion and version management workflow is not designed for the following:
- Backup
- Disaster recovery
- Archiving
The promotion and version management workflow is not able to do these tasks, because it is
specifically designed for promotion workflows and optimized for 100 objects for each
promotion.
However, it might form part of a recovery strategy.
Promotion and Version Management as Part of a Recovery Strategy

Promotion and version management is able to complete the following recovery tasks:
● Content can be re-promoted, thereby restoring lost or corrupted content

● Previously checked-in content can be checked out from version management, thereby
restoring lost or corrupted content.
● Selected content, typically ad-hoc content, can be promoted from production to another
environment, such as development.
Basic Promotion Management Workflow

You want to promote finished content from the development environment into the test
environment and validate the work. After the acceptance testing, you want to push it through
to the production environment. The following describes the basic promotion management
workflow steps:
1. You create a promotion job with Promotion Management, which contains the following:
● A name and source system definition
● A definition of a target system (if not LCMBIAR)
● A list of objects based on the source
2. You run the promotion job, so that the content is promoted from the development
environment into the test environment.
3. You test that content in the test environment.
4. If the test of the content is successful, you can then re-run the same promotion job but
change the target to the production environment (which is consistent with SAP TMS /
CTS+ ).
Note:
Promoting content from the test environment to the production environment does
not follow this principle and so it is considered poor practice.

Basic Version Management Workflows

The following are considerations in a basic version management workflow:
● Check-in
Creates a new revision of an object (like a document or a universe) every time you check it
in.
● Check-out
Overwrites the version in the BusinessObjects Repository with the revision you select.
Administration Options of LCM

The administration options enable you to configure settings before promoting infoobjects
from one SAP BusinessObjects Business Intelligence platform deployment to another SAP
BusinessObjects Business Intelligence platform deployment and SAP deployment. This
section describes how to use the administration options.
Administration Options
Manage Systems
This option enables you to add and remove the host systems.
Override Settings
This option enables you to override the properties of infoobjects within the job that were
promoted to the destination system. It overrides the properties of infoobjects that were
promoted from the source system.
Rollback Settings
This option enables you to configure the rollback process at the system level.
Job Settings
This option enables you to specify the number of job instances that can exist in life cycle
management console system at any instance of time. If the number of jobs exceeds the
specified number, they are automatically deleted. It also enables the user to specify the
number of days for a job, after which the job must be deleted from the life cycle
management console.
VMS Settings
This option enables you to configure version management systems.
Additional Information about Managing the Life Cycle of a Deployment Using the
PMT Tool
Topic Online location
Promotion Management BI 4 Administrator Guide is available in the

SAP Service Marketplace
Promotion Management Architecture http://wiki.scn.sap.com/wiki/display/
BOBJ/Promotion+Management+Architec-
ture+%3A+processes+at+play+in+a
+BI4+landscape

New Job Creation

Interface Elements Used to Create a New Job with the Promotion Management Tool
● Name
● Description
● Keywords
● Save Job in
● Source System
● Destination System
● User name
● Password
● Authentication
You can create a new job using the Promotion Management tool. The table discusses the
elements and fields in the tool interface that you can use to create a new job:
Table 22: GUI Elements and Fields to Create a New Job

Item Description
Name Name of the job that you want to create.

Description Description of the job you want to create.
Keywords The keywords for the contents of the job you want to create
Save Job in You must browse and select a folder to create a job.
Source System The name of the SAP BusinessObjects Business Intelligence platform
system from which you want to promote a job.
Destination System The name of the SAP BusinessObjects Business Intelligence platform
system to which you want to promote a job.
User name The login ID that you must use to log into the source or Destination
system.
Password The password that you must use to log into the source or destination
system.
Authentication The authentication type that is used to connect to the source or desti-
nation system.
Job Dependencies Management

Management of Dependencies During Promotion
The following are considerations when managing dependencies during promotion:
● Infoobjects are dependent on other infoobjects

● During promotion, you can promote all dependencies or select only the ones you want
promoted.
● To select and filter dependents for promotion, you must use the Manage Dependencies
option.
In an SAP BusinessObjects Business Intelligence platform environment, infoobjects are

dependent on other infoobjects. For example, a Web Analysis document is dependent on the
underlying Universe for its structure, content, and so on. While promoting an object, you can
select and filter the dependents that you want to promote or permit the promotion of all the
dependents to another SAP BusinessObjects Business Intelligence platform system. To
select and filter the dependents you want to promote along with the infoobject, you must use
the Manage Dependencies option.
If you do not use this option, the dependents are not promoted along with the job.
Options Used to Manage Dependents

The following options are used to manage dependencies:
● Universe for selected reports

● Selected universes, Universe restriction set
● Access levels set on selected objects
● Connections used by selected Universes
● Business Views for selected reports
● Events, calendars, and profiles used by selected publication
The table discusses options that you can use to manage the dependents:
Table 23: Dependency Management Options

Types of Dependency Objects Description
Universe for selected reports The universe upon which the selected infoobject
is dependent is promoted.
Selected universes, Universe restriction Universes that are dependent on another Uni-
set verse restriction set are promoted.
Access levels set on selected objects Access levels that are used on the selected in-
foobjects are promoted.
Connections used by selected Universes Universe connection objects that are used by the
selected infoobjects are promoted.
Business Views for selected reports Business Views, business elements, the data
foundation, the data connections, and List of Val-
ues (LoVs) that the selected infoobjects depend
on are promoted..
Events, calendars, and profiles used by Event, calendar, and user-profile objects that are
selected publication used by a selected publication are promoted.

Note:
● Dependent objects are computed automatically by the lifecycle management

console tool. These dependents are computed based either on the infoobject
relationships or infoobject properties.
● If you select a folder for promotion, then the contents in the selected folder are
considered as primary resources.
● On the Manage Dependencies screen, when you place the cursor on the
scheduled infoobject, a tool tip appears describing the file name, file path,
created date and time, last modified date and time, next run, expiry, owner, and
recurrence of the schedule.
Job Scheduling
The Promotion Management enables you to specify when a job must be promoted, rather
than promote it as soon as it is created. It also enables you to schedule job promotion at fixed
intervals. This feature is useful for promoting large jobs when the load on the server is at its
minimum. To schedule a job promotion, you must specify a time in the future or select a
recurrence pattern, and you must specify additional parameters.
Testing and Scheduling Benefits

Testing and scheduling include the following benefits:
● Testing before promoting

- You can view the results of a promotion without affecting production systems.
- You are informed if new objects are added, if there are name or CUID conflicts, or if
dependencies are not promoted.
● Test considerations
- No checks are performed to determine if the user promoting has rights on the folders in
the destination.
● Scheduling a promotion
- Promotion jobs can be scheduled when load is at its minimum.
● Scheduling considerations
- Content is selected when the job runs, not when the promotion job is created or
scheduled.
Job Rollback
The Rollback option enables you to restore the destination system to its previous state after a
job is promoted.
Rolling Back Information

The following information about rollbacks is important:

● The purpose of a roll back is to restore a destination system to its previous state.
● Use a roll back in the following scenarios:
- There are production issues.
- The changes must be reversed quickly.
- The scope of changes to be rolled back is large.
● When using CTS+ integration, roll back is only possible for the BI content.
Considerations When Rolling Back Information

● The following considerations apply to rollbacks:
- Enable rollback only for critical systems.
- Enable rollback only when absolutely necessary.
- Avoid rolling back more than one version.
- Enable a full roll back when security changes need to be rolled back.
High-Level Architecture
The figure, High-Level Recommendation Architecture, shows a recommended setup for a
connected system with no air gap or firewall.
Figure 79: High-Level Recommendation Architecture
Recommended High-Level Architecture
● Three BI platform environments are installed: Development, Test, and Production.

● A separate, dedicated BI platform is installed for promotion management.

● Users cannot perform version control on the Production environment.
There are three BI plaform environments: Development, Test, and Production. A separate,
dedicated installation of the BI platform is used just for promotion management. This helps
with the version management workflows. The reason for this separation is to assist with
version management of a promotion job. That is, you have a promotion job and you want to
check in that promotion job. Having a separate environment for promotion management
prevents users from performing version control with their own content in the production
environment.
Figure 80: Two Dedicated Promotion Management Systems
The figure Two Dedicated Promotion Management Systems shows a recommended setup for
a non-connected system with no air gap (for example, no firewall). A non-connected system is
one where there is an air gap or a firewall preventing access between systems.
Two Dedicated Promotion Management Systems

The following is recommended for two dedicated promotion management systems:
● The first system is used to create promotion jobs that are run against the Test
environment.
● The system creates an LCMBIAR file that contains the contents of the promotion job.
● Another promotion job is created on the second promotion management system, which
promotes the LCMBIAR file to the Production environment.
In this architecture, there are two dedicated Promotion Management systems. The first
system is used to create promotion jobs. The promotion jobs are then run against Test.
However, because there is an air-gap surrounding production, the dedicated promotion
management system cannot connect directly to Production. The system creates an LCMBIAR
file that contains the contents of the promotion job. The LCMBIAR file is used as the basis to

create another promotion job on the second promotion management system on the right.
This LCMBIAR file is then promoted into production.
The use of this second dedicated promotion management system is optional and typically not
used.
Benefits of a Dedicated System

The following are benefits of a dedicated system:
● Promotion Management is really a “production” system.

● A dedicated system stores rollback content from a production environment.
● It enables versions of BI content to be re-promoted or old content recovered.
● It allows for “decoupling” of software releases between Promotion Management and other
environments.
Promotion Management is really a “production” system. The system needs to be backed up.
The rollback content is stored as instances in the output File Repository Server. The
versioning of content is stored in Version Management, so you must also back up the version
management database.
A dedicated system stores rollback content from a production environment, which could be
critical if a rollback is required in your Production system.
Together with the Version Management System, it contains the versioning and an audit trail of
your BI content, allowing that content to be re-promoted or old content recovered. It could be
critical to meet compliance regulations. A dedicated system avoids potential issues when
promoting content to which the “Promotion job owner” does not have access. It allows for a
refresh of Development and Test from Production without losing any Promotion
Management-specific data.
It allows for “decoupling” of software releases between Promotion Management and other
environments. You can patch Promotion Management without affecting Production. It allows
the Promotion Management Server to be upgraded without necessarily upgrading
Production. For example, you might want to upgrade Test before Production, but to be
supported, you also need to upgrade the Promotion Management Server.
Mappings and Overrides

Connection overrides occur when a connection is promoted from one environment to the
other and the data source connection needs to be updated accordingly.
Connection Overrides
Connection overrides provide the following connections:
● Universe connections
● Query as Web Service connections
● Crystal Reports direct-to-data connections

Figure 81: Mappings and Overrides
Validation Check Services

Validation check services need to have an Adaptive Job Server and an Adaptive Processing
Server containing the services shown. Only one active Lifecycle Management Service is
supported in each cluster, because this service uses a file-based database for holding over-
ride connections. Only one service can access the file-based database at any time.
The table presents the AJS services and functions.
Table 24: Adaptive Job Server Services

Service Function
Visual Difference Scheduling service Scheduling of comparisons

Lifecycle Management Scheduling service Promotion of Jobs, whether scheduled or not
The table presents the Adaptive Processing Server services and functions.
Table 25: Adaptive Processing Server Services

Service Function
Life Cycle Management service (maximum of ● Scanning, managing, and promotion of

1) overrides
● Used for almost all Version Management
workflows

Service Function
Visual Difference service Comparing workflows with Version Manage-

ment (limited to Promotion Jobs)
Life Cycle Management ClearCase service Needed for both ClearCase and locking and
unlocking items in SubVersion
The location of the file-based database is specified in CMC Applications Promotion

Management in LCM Override Settings.
Best Practices for Life Cycle Management

LCM: Best Practices
Observe the following best practices for Life cycle Management:
● Create folders to organize promotion jobs.

● Use consistent naming convention for promotion jobs.
● Create promotion job templates.
● Enable and run CMS and FRS in the source system when creating a promotion job.
● Run the APS containing the Data Federation Service in both the Source and Destination
while promoting Multi-Source Universe.
Non-Supported LCM Scenarios

The following scenarios are not supported by LCM:
● LCM is not designed for a large object. Optimal performance is 100 objects at a time.
● LCM promotion jobs are not designed for backups of entire repository.
● Promotion jobs cannot include instances, in-boxes and documents in Favorites folder.
Additional Information about Best Practices for Managing the Life cycle of a
Deployment
BI4 Upgrade and Promotion Management On the SAP Community Network, search for
KBAs the title.
SAP Enterprise Support Academy On the SAP Support Portal, choose Support
Programs & Services → SAP Enterprise Sup-
port → SAP Enterprise Support Academy.
LESSON SUMMARY



Unit 6
Lesson 4
Moving Objects from One Deployment to
Another
LESSON OVERVIEW
This lesson teaches how to compare objects and files, and how to move objects with the
Change and Transport System (CTS). It details information on comparing objects and files
and object management best practices.
LESSON OBJECTIVES
Comparison of Objects and Files

Overview of Visual Difference
Visual Difference allows you to view differences between files and objects, as follows:
● It shows the differences between two versions of a LCMBIAR file, an LCM Job, or both.
● It helps you develop and maintain different report types by comparing source to
destination versions.
● It detects missing elements, modified elements, and added elements.
Visual Difference allows you to view the differences between two versions of a supported file
type (LCMBIAR), a supported object type (LCM Job), or both. You can use this feature to
determine the difference between files or objects to develop and maintain different report
types. This feature gives a comparison status between the source and the destination
versions. For example, if a previous version of the user report is accurate and the current
version is inaccurate, you can compare and analyze the file to evaluate the exact issue.
Types of Detected Differences

The following are the three types of visual differences you can detect in a file or an object:
● Removed - An element is missing in one of the file versions, for example, a row, section
instance, or even a block.
● Modified - There is a different value between the source version and the destination
version, for example, cell content or the result of a local variable.
● Inserted - There is an element in the destination version but is not in the source version.
Support Object Types

The following are object types that are supported in Visual Difference:

● LCMBIAR file
● Promotion Management Job (LCM Job)
Comparison Combinations
With Visual Difference, you can compare the following combinations:
● Promotion Management job with another Promotion Management job

● Promotion Management job with an LCMBIAR file
● LCMBIAR file with another LCMBIAR file
● LCMBIAR file with a Promotion Management job
Additional Information about Comparing Objects and Files

On the SAP Community Network, search for

Comparison support (Visual Difference) the title.
LESSON SUMMARY

Unit 6
Learning Assessment
1. A content management plan is useful when migrating from a project that has been poorly
managed.
X True
X False
2. Match the tools to their functions.

BIAR File Contains compressed BI con-

tent.
Upgrade Management Tool
Converts mass amounts of
content and all related objects
from previous versions to BI
4.x.
Transports versioned content
from one system to another
system.
3. The Promotion Management Tool has to be installed separately in BI 4.3 because it is not
integrated with BI 4.3.
X True
X False
4. Lifecycle management refers to the entire process of designing, developing, and

X True
X False

5. Which of the following is not an LCM function.

X A BI Content Promotion
X B Version Management
X C Auditing
X D Security Rights Promotion
6. Job creation is required only for promoting BI content from one environment to another,
not for exporting to LCMBIAR.
X True
X False
7. You cannot check the security rights with the Manage Job Dependencies function.
X True
X False
8. When scheduling a job, which statements are accurate?

X A To schedule a job promotion, you must specify a time in the future or select a
recurrence pattern and you must specify additional parameters.
X B Promotion jobs can be scheduled only when load is greater than 30 percent.
X C Content is selected when the promotion job is created or scheduled.
X D You perform job scheduling with the Promotion Management tool.
9. Which of the following are BI platform environments?

X A Development
X B Production
X C Promotion
X D Test

10. Expert Guided Implementation combines training, live configuration, and on-demand
expertise.
X True
X False
11. Which of the following object types is supported in Visual Difference?

X A WEB Intelligence
X B LCMBIAR
X C Universe
X D Crystal Report 2013

Unit 6
1. A content management plan is useful when migrating from a project that has been poorly
managed.
X True
X False
2. Match the tools to their functions.

BIAR File Contains compressed BI con-

tent.
Upgrade Management Tool
Converts mass amounts of
content and all related objects
from previous versions to BI
4.x.
Transports versioned content
from one system to another
system.
3. The Promotion Management Tool has to be installed separately in BI 4.3 because it is not
integrated with BI 4.3.
X True
X False
4. Lifecycle management refers to the entire process of designing, developing, and

X True
X False

5. Which of the following is not an LCM function.

X A BI Content Promotion
X B Version Management
X C Auditing
X D Security Rights Promotion
6. Job creation is required only for promoting BI content from one environment to another,
not for exporting to LCMBIAR.
X True
X False
7. You cannot check the security rights with the Manage Job Dependencies function.
X True
X False
8. When scheduling a job, which statements are accurate?

X A To schedule a job promotion, you must specify a time in the future or select a
recurrence pattern and you must specify additional parameters.
X B Promotion jobs can be scheduled only when load is greater than 30 percent.
X C Content is selected when the promotion job is created or scheduled.
X D You perform job scheduling with the Promotion Management tool.

9. Which of the following are BI platform environments?

X A Development
X B Production
X C Promotion
X D Test
10. Expert Guided Implementation combines training, live configuration, and on-demand
expertise.
X True
X False
11. Which of the following object types is supported in Visual Difference?

X A WEB Intelligence
X B LCMBIAR
X C Universe
X D Crystal Report 2013

UNIT 7 Publications and Single Pass
Report Bursting
Lesson 1
Designing Publications 253
UNIT OBJECTIVES
● Design a publication
● Personalize publications

Unit 7: Publications and Single Pass Report Bursting

Unit 7
Lesson 1
Designing Publications
LESSON OVERVIEW
This lesson describes how to design and publish objects in the BI platform.
LESSON OBJECTIVES
Publishing Basics
Publishing
Publishing is the process of making documents such as Crystal Reports and Web
Intelligence documents publicly available for mass consumption. The contents of these
documents can be distributed automatically. Distribution occurs via e-mail or FTP, saved
to disk, or managed through the BI platform for Web viewing, archiving, and retrieval, and
automated through the use of scheduling. From within BI launch pad or the CMC, you can
take documents and tailor them for different users or recipients. You can schedule a
publication to run at specified intervals; and you can send it to a number of destinations,
including recipients' BI Inboxes and e-mail addresses.
Publication
A publication is a collection of documents intended for distribution to a mass audience.
Before the documents are distributed, the publisher defines the publication using a
collection of metadata. This metadata includes the publication source, its recipients, and
the personalization applied.
Publications
Publications can help you send information through your organization more efficiently.
Benefits of Publications
● Enable you to distribute information to individuals or groups of users and personalize the
information each user or group receives.
● Provide delivery of targeted business information to groups or individuals through a
password-protected portal, across an intranet, an extranet, or the Internet.
● Minimize database access by eliminating the need for users to send process requests
themselves.

Note:
You can create different types of publications based on Crystal reports or Web
Intelligence documents.
Figure 82: Publication Process
Typically, the publisher (the user who owns and schedules the publication) can view all
publication instances for all recipients; the recipients can view their personalized publication
instances only. This rights setup ensures maximum security for publication data because it
reserves the rights to schedule publications and to view all publication instances for the
publisher only.
Note:
If you are a publisher and want to add yourself to a publication as a recipient, use
two user accounts for yourself, a Publisher account and a Recipient account. The
Publisher account grants you the rights you require when you design and schedule
publications, while the Recipient account grants you the rights of a typical
recipient.
Publication Formats
Formats define the file types that a publication's documents will be published in. A single
document can be published in multiple formats, and these instances can be delivered to
multiple destinations. For publications with multiple documents, you can specify a different
format for each. For publications that contain Web Intelligence documents, you can publish
the whole document or a report tab within the document to different formats.
Any formats you choose for a document apply to all recipients of the publication. For
example, you cannot publish a document as a Microsoft Excel file for one recipient and as a

Lesson: Designing Publications
PDF for another. If you want the recipients to receive instances in those formats, each
recipient will receive a Microsoft Excel file and a PDF.
The following table provides descriptions of each format type:
Table 26: Publishing Formats

Object Type Format
Crystal Reports Crystal Reports
Crystal Reports (RPTR)
Microsoft Excel (97-2003)
Microsoft Excel (97-2003) (Data Only)
Microsoft Excel Workbook Data Only
Microsoft Word (97-2003)
PDF
Rich Text Format (RTF)
Microsoft Word - Editable (RTF)
Plain Text
Web Intelligence documents Web Intelligence
Microsoft Excel
Adobe Acrobat
mHTML
Publication Destinations
Destinations are locations that you deliver publications to. A destination can be an Enterprise
location in which a publication in stored, a BI Inbox, an e-mail address, an FTP server, or a
directory on the file system. You can specify multiple destinations for a publication.
If you are publishing multiple Crystal reports, you can also merge them into a single PDF on a
per destination basis.
If you want to publish a publication as a single ZIP file, choose to zip or unzip the instances on
a per destination basis. For example, zip the instances for e-mail recipients and leave them
unzipped for BI Inboxes.
The following table provides descriptions of each destination type:
Publication Destinations
● Default Enterprise location

● BI Inbox
● Email

● FTP Server
● SFTP Server
● File System
● SAP StreamWork
Note:
● Deliver objects to each user is selected by default for all destinations. However,
in some cases, you may not want to deliver objects to each user. For example,
three recipients have identical personalization values and thus receive the
same data in their publication instances. If you clear Deliver objects to each
user, one publication instance is generated and delivered to all three recipients.
If you select Deliver objects to each user, the same publication instance is
delivered three times (once for each recipient). Additionally, if you are sending
the publication to an FTP server or local disk destination and some recipients
share identical personalization values, you can clear Deliver objects to each
user to decrease overall processing time.
● If you clear Deliver objects to each user, any placeholders that you use when
you configure your destinations will contain the publisher's information and not
the information of the recipients.
Subscriptions
A subscription enables users who are not publication recipients to view the latest instance.
Enterprise recipients can unsubscribe from a publication at any time. Dynamic recipients can
neither subscribe to or unsubscribe from a publication.
Users with the appropriate access rights can subscribe and unsubscribe other users. To
subscribe to or unsubscribe from a publication, you need a BI platform account and the
following rights:
● Access to the BI launch pad or to the CMC
● View rights to see the publication
● Subscriber rights for the user account (Enterprise recipients)
Enterprise recipients can subscribe to or unsubscribe from a publication.
Report Bursting
During publishing, the data in documents is refreshed against data sources and personalized
before the publication is delivered to recipients. This combined process is known as “report
bursting.” Depending on the size of the publication and how many recipients the publication is
intended for, you have several report bursting methods to choose from:
● One database fetch for all recipients
When you use this report bursting method, all documents in the publication are refreshed
once, and then the documents are personalized and delivered to each recipient. This
report bursting method uses the data source logon credentials of the publisher to refresh
data.

This bursting method is used for Web Intelligence document publications. It is also the
recommended option when you want to minimize the impact of Publishing on your
database. This option is secure only when the source documents are delivered as static
documents. For example, a recipient who receives a Web Intelligence document in its
original format can modify the document and view the data associated with other
recipients. However, if the document is delivered as a PDF, the data would be secure.
Note:
- This option is secure for most Crystal reports regardless of whether the
Crystal reports are delivered in their original format.
- The performance of this option varies depending on the number of
recipients.
● One database fetch for each batch of recipients

When you use this report bursting method, the publication is refreshed, personalized, and
delivered to recipients in batches. This report bursting method uses the data source logon
credentials of the publisher to refresh data. The batches are based on the personalization
values you specified for the recipients. The batch size varies depending on the specified
personalization value and is not configurable.
This bursting method is the default option for Crystal report publications. It is also the
recommended option for high-volume scenarios. With this option, you can process
batches concurrently on different servers, which can greatly decrease the processing load
and time required for large publications.
Note:
This option is unavailable for Web Intelligence documents.
● One database fetch per recipient

The data in a document is refreshed for every recipient. For example, if there are five
recipients for a publication, the publication is refreshed five times. This report bursting
method uses the data source logon credentials of the recipient to refresh data.
This option is recommended if you want to maximize security for delivered publications.
Note:
Crystal reports that are based on universes or Business Views support one
database fetch per recipient only to maximize security.
Personalization Methods
Personalization is the process of filtering data in source documents so that only relevant data
is displayed for publication recipients. Personalization alters the view of the data, but it does
not necessarily change or secure the data being queried from the data source.

Figure 83: Personalizing Publications
Profiles in the Publishing Workflow

Profiles are objects in the BI platform that let you classify users and groups. They work with
publications to personalize the content that users see. Profiles link users and groups to profile
values, which are values used to personalize data within a report. Profiles also use profile
targets, which describe how a profile is applied to a report. By assigning different profile
values, the data within a report can be tailored to specific users or groups. Many different
personalized versions of the report are then delivered to your users.
You can create profiles that reflect the roles of users and groups in an organizational
structure. For example, you could have a Department profile that includes all employees in an
organization. The users and groups each have profile values that reflect their roles in the
organization (for example, “ Finance,” “ Sales,” and “ Marketing”). When a publisher applies
the Department profile to a publication, employees receive data that is relevant to their
department.
Profiles refine or filter a document's content; they do not control users' access to data. Using
profiles to display a subset of the data to a user is not the same as restricting the user from
seeing that data. If users have the appropriate rights and access to the document in its
original format, they may still see the complete data for the document by viewing the
document in BI launch pad or the CMC. Profiles filter the view of the data; they do not change
or secure the data being queried from the data source.
Using a profile to personalize a publication is a two-part process. First, you create the profile
in the Profiles area of the CMC. Creating a profile involves these tasks:
1. You create a profile.
2. You add users and groups to the profile.
3. You assign profile values to each user and group for that profile.
4. You specify a global profile target if necessary.
When you create the publication, you perform these tasks:

1. You add users and groups to a publication as recipients.
2. You specify a local profile target for the profile to filter (for example, a field in a Crystal
report).
3. You specify the profile or profiles that will be used for personalization.
You can grant or deny users and groups access to profiles. Depending on how you organize
your profiles, you may have specific profiles that you want to be available only for certain
employees or departments.
Users with access to the CMC can see only profiles that they have the rights to see; therefore,
you can use rights to hide profiles that are not applicable to a particular group.
For example, by granting only the ITadmin group access to IT-related profiles, those profiles
are hidden from users in the HRadmin group, making the profile list easier for the HRadmin
group to navigate.
Profile Targets and Values

To personalize a publication with profiles, you must set profile values and profile targets for
the profile.
Profile targets are data sources that profile values filter and interact with to provide
personalized publications. The two types of profile targets are:
● Local profile target
A local profile target can be a variable in a Web Intelligence document or a field or
parameter in a Crystal report. When you use a local profile target, the source document
that contains the local profile target is filtered for the publication recipients.
● Global profile target
A global profile target can be a universe. You must also specify an object within that
universe. This type of profile target can filter all source documents that use the universe.
Profile values are attributes detailed to specific users or groups when you assign these users
and groups to a profile. When a profile is applied to a publication, the users and groups
assigned to that profile receive versions of the publication that are filtered according to the
profile values set for them.
Note:
Inheritance for profile values works in the same way as inheritance works for
security settings.
You can use global profile targets for publications that contain Web Intelligence
documents. You cannot use global profile targets with Crystal reports.
Profile targets and profile values enable a profile to personalize a publication for recipients.
The users and groups specified for a profile receive filtered versions of the same publication
that only display the data most relevant to them.
Consider a situation where a global sales report is distributed to a company’s regional sales
teams in North America, South America, Europe, and Asia. Each regional sales team only
wants to view the data that is specific to their region. The administrator creates a Regional
Sales profile and adds each regional sales team to the profile as a group. The administrator
assigns each regional sales team a corresponding profile value (for example, the North
America Sales group is assigned “North America”). During Publishing, the publisher uses the

Region field in the global sales report as a local profile target, and applies the profile to the
report. The global sales report is filtered according to the profile values set for each regional
sales team. When the global sales report is distributed, each regional sales team receives a
personalized version that only displays regional sales data.
Resolving Profile Value Conflicts

You might encounter conflicts between profiles when users and groups have been assigned
multiple profiles. If a document is delivered to a user that has two profiles that conflict with
one another, the conflict must be resolved.
For example, Tony is a product manager in the Mexico office. He is assigned a profile called
Region that personalizes his documents to show only data from Mexico. He is also assigned a
different Management profile that personalizes the data to display data for product
managers.
If a document uses both of these profiles, which data will Tony see? According to one profile,
he will see data for Mexico. According to the other profile, he should see only data for product
managers.
SAP BusinessObjects BI platform can resolve this conflict in two ways:
1. Do not merge
SAP BusinessObjects BI platform determines the different possible views of a publication
that could be delivered and produces a unique view for each case. In the example, Tony
would receive one publication personalized to show data for Mexico, and another
publication that shows product manager data.
2. Merge
With this setting, SAP BusinessObjects BI platform again determines the different
possible views of the data, but this time the nonconflicting profiles are merged. This type
of profile resolution is designed for role-based security. In this example, Tony would
receive a single publication personalized to show data for Mexican product managers.
Conflicts between profile values can also arise when a user inherits two contradictory profile
values as a result of group membership. In general, explicitly assigned profile values override
profile values inherited from group membership. A profile value assigned to a user or a
subgroup overrides the profile value inherited from group membership.
For example, David belongs to the North America Sales and Canada Sales groups. The
Canada Sales group is a subgroup of the North America Sales group. These groups are both
added to the Region profile. From the North America Sales group, David inherits a Region
profile value of “ North America”, and from the Canada Sales group, David inherits a Region
profile value of “ Canada”. In this case, the profile value that is assigned to the subgroup
overrides the profile value that is assigned to the group, and David receives a publication with
data for Canada.
Conflicts between profile values can also arise when a user is explicitly assigned a profile value
that contradicts a profile value inherited from group membership. For example, Paula belongs
to the North America Sales group, which has a Region profile value of “ North America”. The
administrator also assigns Paula a Region profile value of “ Spain”. In this case, the profile
value that is assigned to the member overrides the profile value that is inherited from the
group, and Paula receives a publication with data for Spain.
However, sometimes a user can inherit different profile values from two different groups for
one profile. Both groups are hierarchically equal; one group is not a subgroup of the other
group, so one profile value does not override the other. In this case, both profile values are
valid and the user receives a publication instance for each profile value.

As a result of this profile value conflict, sometimes duplicate report instances are included in
different publication instances and sent to the same user. For example, Sandra is a manager
in two North America offices and receives a publication via e-mail that contains two reports.
Report 1 is personalized using the Region profile, for which Sandra inherits the conflicting
profile values “ USA” and “ Canada” from group membership. Report 2 is personalized using
the Role profile, for which Sandra inherits the profile value “ Manager”. If there is no profile
value conflict, after personalization, Sandra receives one e-mail with a merged Report 1
instance (USA and Canada data) and a Report 2 instance (Manager data). Instead, Sandra
receives two e-mails: one e-mail includes a Report 1 USA instance, the other e-mail includes a
Report 1 Canada instance, and both e-mails have the same Report 2 Manager instance.
Hint:
To avoid profile value conflicts that result in duplicate publication instances being
sent, when possible, explicitly assign profile values to users instead of allowing
users to inherit profile values from group membership.
LESSON SUMMARY


Unit 7
Learning Assessment
1. What is a publication?
2. What are dynamic recipients?
3. What are profiles?
4. Profiles control a user's access to data.

X True
X False
5. Describe how profile conflicts are resolved in the BI platform.

Unit 7
1. What is a publication?
A publication is a collection of documents intended for distribution to a mass audience.

Before the documents are distributed, the publisher defines the publication using a
collection of metadata. This metadata includes the publication source, its recipients, and
the personalization applied.
2. What are dynamic recipients?
Dynamic recipients are publication recipients who exist outside of the SAP
BusinessObjects Business Intelligence platform. Dynamic recipients already have user
information in an external data source, such as a database or an LDAP or AD directory, but
do not have user accounts in SAP BusinessObjects Business Intelligence platform.
3. What are profiles?
Profiles are objects in the SAP BusinessObjects Business Intelligence platform that let you
classify users and groups. They work with publications to personalize the content that
users see. Profiles link users and groups to profile values, which are values used to
personalize data within a report. Profiles also use profile targets, which describe how a
profile is applied to a report. By assigning different profile values, the data within a report
can be tailored to specific users or groups. Many different personalized versions of the
report are then delivered to your users.
4. Profiles control a user's access to data.

X True
X False
5. Describe how profile conflicts are resolved in the BI platform.
Do not merge: The BI platform generates a separate publication for each unique view
possible. Merge: The BI platform generates a single publication that contains only the data
common among the conflicting profiles.

UNIT 8 Deployment Administration
Lesson 1
Performing Advanced Troubleshooting of a BI Platform Deployment 267
UNIT OBJECTIVES
● Perform an end-to-end trace with SAP Passport

Unit 8: Deployment Administration

Unit 8
Lesson 1
Performing Advanced Troubleshooting of a BI
Platform Deployment
LESSON OVERVIEW
This lesson provides information on how to troubleshoot a deployment with advanced
diagnostics and SAP Passport. It details system monitoring with tools, advanced diagnostics,
end-to-end tracing, and system performance testing.
LESSON OBJECTIVES
Overview of SAP Passport

The mechanism supporting the end-to-end (E2E) tracing for BI platform is a tool called SAP
Passport. An end-to-end trace analysis analyzes the performance of a single transaction.
SAP Passport’s Usage in Complex Architecture
● End-to-end tracing shows which servers are used for workflows

- No more hunting through flow diagrams and logs when investigating issues
- Filtering out a single user workflow was difficult in previous versions
Use in Complex Architecture

Use E2E tracing to find out what servers are used for workflows instead of hunting process
flow diagrams and logs when investigating an issue.
It is difficult to filter out a single user workflow. Previously we followed thread IDs and filtered
on SI_IDs and user IDs, in order to trace workflow. The administrator must go and turn on
tracing for each individual server. Gleaning an end-to-end trace view from all components was
not previously possible.
End-to-End Tracing
The following are considerations when using E2E tracing:
● Diagnostics across all SAP products

● Required for Solution Manager
● New feature in SAP BI Platform 4.x
Supportability Challenges
The following are supportability challenges when using E2E tracing:

● Complex architecture
● Challenging to manage large number of logfiles
● Tracing must be enabled on all servers
● Difficult to narrow down single workflow
● Unified E2E View not previously possible
End-to-End Scenarios
E2E tracing is useful in many different scenarios.
Examples of E2E Scenarios

The following are examples of scenarios in which E2E tracing is useful:
● Single sign-on and authentication issues

● Explorer performance issues
● Promotion management
● Web Intelligence performance and errors
● Debugging OLAP Workflows
● Troubleshooting publications
● Scheduling failures
● Web service issues

Lesson: Performing Advanced Troubleshooting of a BI Platform Deployment
Architecture of SAP Passport
Figure 84: Correlation ID
The SAP Passport client tool injects a unique identifier, which is Correlation ID (DSR ROOT
CONTEXT ID) into all HTTP requests for a particular workflow and this identifier is forwarded
to all servers used in the workflow. SAP support personnel can put together an end-to-end
trace for the workflow by using this unique identifier.
Figure 85: Request Header
The figure, Request Header, is an illustration of how Fidler 2, a third party host header
inspection tool, provides relevant host header traffic information helpful when
troubleshooting problems related to web navigation workflows.

Figure 86: Trace Log
TRACELOG is designed to determine trace levels from the passport and override the current
trace level. TRACELOG will never lower a trace level to match the passport.
Trace Start-Up
Figure 87: SAP Client Plug-In
The SAP Passport client tool is not installed as part of BI platform. You need to install the SAP
Client plug-in before you can use it.

BI Platform Support Tool
Figure 88: BI Platform Support Tool
BI Platform Support Tool

The following are considerations when using the BI Platform Support Tool:
● Provides visibility into BI 4.x deployment

● Is free from SAP Community Network
● Supports SAP BusinessObjects BI platform 4.0, 4.1, 4.2, and 4.3
● Includes Landscape Inspection Report
- Connects to CMS, extracts from system, generates reports inside client
- Is exported and sent to SAP support when opening a new message
- Includes details about server topology, settings, performance metrics, and memory
settings
- Includes analysis engine the check parameter settings and metric values against
thresholds
- Sends alerts to administrators when thresholds are breached
The BI Platform Support Tool was developed by colleagues in AGS as a standalone tool to
provide visibility into a BI 4.x deployment. The tool is completely free to download on the SAP
Community Network and supports SAP BusinessObjects BI platform 4.0, 4.1, 4.2, and 4.3.
Currently, the primary feature of the BI Support Tool is the Landscape Inspection Report. The
Landscape Inspection Report connects to a CMS system, performs an extraction from this
system then generates a landscape report inside the client. This report can be exported and
sent to SAP support when opening a new message so that the engineer may be aware of the
landscape configuration prior to beginning the message processing. The report includes

details about the server topology, settings, performance metrics, and memory settings. It has
an analysis engine that checks recommended parameter settings and metric values against
predefined thresholds. If any thresholds are breached it alerts the administrator to take action
before the problem becomes a potential system outage. The report also includes statistics
and metrics regarding repository content, scheduled jobs, system capabilities, and more.
Note:
Check the SCN (http://wiki.scn.sap.com/wiki/display/BOBJ/SAP+BI+Platform
+Support+Tool) often to download updates for free.
SAP Notes and SCN Page for End-to-End Tracing

Note 1861180 - Best practice for collecting a BI Platform 4.x end to end trace
SCN Page on How to generate and consume an E2E trace with BI4.x (for non-SolMan
landscapes)
http://scn.sap.com/community/bi-platform/remote-supportability/blog/2012/11/06/how-
to-generate-and-consume-an-e2e-trace-with-bi4x-for-non-solman-landscapes
Performance of End-to-End Trace with SAP Passport

General Steps to Perform an End-to-End Trace with SAP Passport
1. Prepare the environment.
2. Execute the E2E trace.
3. Collect and filter the E2E trace.
4. Analyze the E2E trace.
The figures, SAP Client Plug-In Settings 1 and SAP Client Plug-In Settings 2 show key steps in
performing an end-to-end trace with SAP Passport.

Figure 89: SAP Client Plug-In Settings 1
On the SAP Client Plug-In screen, in the Application field, select Microsoft Internet Explorer
and choose Launch.
Figure 90: SAP Client Plug-In Settings 2

Populate the Business Transaction Name and Net Step TraceLevel fields.
On the BI Launchpad home page, navigate to the Reports Tile.
On the Formatting Sample tab page, choose the Refresh Query icon.
Figure 91: Business Transaction Name Folder
Navigate to the automatically generated folder with the Business Transaction Name you
specified in the SAP Client Plug-in Tool.
Figure 92: Business Transaction ID
In the XML file found in the automatically generated folder, open the file and locate the
BusinessTransaction ID.

Figure 93: SBOP Webapp BI Launchpad Trace GIF File
Navigate to the SBOP Webapp BI Launchpad TRace GIF file and copy it to the e2e_trace
folder, which serves as a staging directory for all copied .glf files to be analyzed.
Figure 94: Search Result Filtering
Navigate to the SAP BusinessObjects Enterprise\Logging directory and do a search for all .glf
files.

Figure 95: runGLFViewer.bat File
Navigate to the runGLFViewer.bat file and open it.
Figure 96: GLF Viewer: Open Files Dialog Box
In the Open Files dialog box, choose Add Files and browse to the e2e_trace directory you
created that has all of the copied .glf files.

Figure 97: GLF Viewer: Open Files Progress Bar
To load the files, choose OK.
Figure 98: Indent Text According to Scope

In the GLF Viewer, choose View and Indent Text According to Scope.
Figure 99: Transaction Call Stack
Review the information that provides workflow details regarding the error the user is
encountering.
Figure 100: Transaction Call Stack: Remove Indentations
In the GLFViewer, choose View and Remove Indentations.

Figure 101: Export Trace File
In the GLF Viewer, choose File and Export current (filtered) view.
To Prepare the Environment for Creating an E2E Trace

In order for the E2E trace to be successfully generated, you must use only the Internet
Explorer browser that is launched by the SAP Client plug-in.
1. Close all the browsers on your image. Using Windows Explorer, browse to the directory
containing the SAP Client plug-in.
2. Start the SAP Client plug-In by executing the file plugin-starter-gui.exe.
3. Set the option for Application to Microsoft Internet Explorer and choose Launch.
4. Define the following properties before you begin your workflow. Under Business
Transaction Name choose a name that describes the workflow that you are capturing and
set TraceLevel to High.
5. Before you start the E2E trace, queue up the browser to the beginning of the workflow you
want to trace. In the same browser window, launch the BI launchpad and log on.
6. Click the Documents tab, then browse to the document folder for which you want to create
the end-to-end trace.
To Execute an E2E Trace
1. In the SAP Client Plug-in window, choose Start Transaction, and then right-click the
document and choose View.
2. After the document is loaded in the viewer, choose Refresh.
3. When the document has finished refreshing, choose Stop Transaction in the SAP Client
Plug-In window. You might receive the message “Settings are not valid.” You can ignore

this message, because it relates to the SMD Agent settings for Solution Manager. Choose
OK and click Exit to close the SAP Client Plug-In window.
To Collect and Filter an E2E Trace
1. Browse to the same directory where you executed the SAP Client Plug-in. Then, browse to
the log directory.
2. In the log directory, browse to the folder named after your Business Transaction Name.
3. Open the file BusinessTransaction.xml, and search for the string BusinessTransaction id=.
Locate the ID associated with the BusinessTransaction. This is the unique identifier
associated with your E2E trace. You will need this ID later.
4. Because the location of the BI launchpad trace (Web Application trace) is not in the same
location as the default logging, copy this trace to a temporary directory. Browse to the C:
\drive and, according to the modified date timestamp, locate the newest folder named
SBOPWebapp_BIlaunchpad_*. Open this folder and copy the *.glf to S:\temp.
5. Copy the BI4 server traces from the default logging directory to the temporary directory.
Browse to S: → Program Files (x86) → SAP BusinessObjects → SAP BusinessObjects
Enterprise XI 4.0 → logging and filter by *.glf. Change the file view to details and sort by
modified date. Finally, copy *.glf from today’s date to the folder S:\temp.
6. Download the latest version of GLF Viewer from the following SMP link. Extract the
downloaded zip file to a folder on the S: drive (for example S:\GLFViewer. Browse to S:
\GLFViewer and launch the GLF Viewer application by executing the file named
runGLFViewer.bat
7. Inside the GLFViewer, choose File → Open. Choose Add Files and add all *.glf files
generated with today’s date.
8. Confirm that the option Should merge all into a single tab is checked. This option will
create the end-to-end view of your traced workflow.
9. Check the option to Filter and only read matching entries, and then under the Column
option select the field named DSRRootContextID. The operator should be contains, and in
the text box, paste in the BusinessTransaction ID that you found previously. Then choose
OK.
To Analyze an E2E Trace
1. A continuous end-to-end trace has been generated by components in the BI platform.

These logs have been filtered to show only the transactions generated for your user’s
workflow. Analyze the Device Name column to determine the component that generated
each transaction.
2. Choose Analysis → Show Event Analyzer. When prompted, choose NO this component is
not a CMC until you are no longer prompted.
3. Expand the Event Analyzer to enlarge the view and choose Start. The Event Analyzer will
play through to the end-to-end trace and will show you which component is issuing the

call-in sequence. With this view, you can see which function or method call is waiting on
one component while other functions complete on other components.
4. Stop and close the event analyzer. Next choose View → Index Text According to Scope.
5. Now inspect the Text column. Notice that transactions that are part of the same call stack
will be indented, making it easier to follow the flow of function calls within a particular
component.
6. To disable indentations, choose View → Remove Indentations.
7. Click Analysis, List Unique to see all the individual servers and components listed in the
trace. This is particularly useful if you want to know more about the BI 4.x servers required
for the processing of your E2E workflow.
8. Save your E2E trace as one trace file by choosing File → Export current (filtered) view.
LESSON SUMMARY


Unit 8
Learning Assessment
1. Which Unique Identifier is used in SAP Passport for End-to-End Tracing?

X A CORRELATION ID
X B SI_ID
X C User ID
X D Thread ID
2. E2E Tracing with SAP Passport will help which of the following?
X A To monitor the overall Server Health State
X B To troubleshoot a particular workflow
X C To tune a query used in Webi report
X D To audit user activity
3. The SAP Passport client tool is not installed as part of the BI platform.
X True
X False

Unit 8
1. Which Unique Identifier is used in SAP Passport for End-to-End Tracing?

X A CORRELATION ID
X B SI_ID
X C User ID
X D Thread ID
2. E2E Tracing with SAP Passport will help which of the following?
X A To monitor the overall Server Health State
X B To troubleshoot a particular workflow
X C To tune a query used in Webi report
X D To audit user activity
3. The SAP Passport client tool is not installed as part of the BI platform.
X True
X False

UNIT 9 Deployment Replication
(Optional)
Lesson 1
Replicating a BI Platform Deployment 287
UNIT OBJECTIVES
● Identify the uses of the Federation application

● Apply replication techniques and best practices

Unit 9: Deployment Replication (Optional)

Unit 9
Lesson 1
Replicating a BI Platform Deployment
LESSON OVERVIEW
This lesson provides instruction on the Federation application and deployment replication. It
teaches how to replicate a job and detect and resolve conflicts.
LESSON OBJECTIVES
Federation Overview
Federation is a cross-site replication tool for working with multiple SAP BusinessObjects
Business Intelligence platform deployment in a global environment. Content can be created
and managed from one BI platform deployment and replicated to other BI platform
deployments across geographical sites on a recurring schedule. You can complete both one-
way replication and two-way replication jobs.
Benefits of Using Federation for Replication

The following are the benefits of using Federation for replication:
● Cross-site tool
● Multiple deployments
● Global environment
● Content management across geographical sites from a single site
● Recurring schedule
● One-way and two-way replication
● Increased performance for end-users
Federation allows you to have separate security models, life cycles, testing, and deployment
times, as well as different business owners and administrators. For example, you can delegate
administration features that restrict the sales application administrator from changing a
human resources application.
Additional Benefits of Using Federation for Replication
● When you replicate content using Federation, you can do the following:
- Simplify administration needs for multiple deployments.

- Provide a consistent rights policy across multiple offices for global organizations.
- Obtain information faster and process reports at remote sites where data resides.
- Save time by retrieving local and dispersed data faster.
- Synchronize content from multiple deployments without writing custom code.
Objects You Can Replicate When Using Federation

You can replicate a variety of objects with Federation, as described in the table:
Table 27: Object Types You Can Replicate with Federation

Category Object Types You Can Repli- Additional Notes
cate
Business Views Business View Manager, Da- All objects are supported, al-
taConnection, LOVx, Data though not at the individual
Foundation, and similar ob- level.
ject types
Reports SAP Crystal reports, Web In- Full client add-in and tem-
telligence, and Lumira De- plates are supported.
signer
Third-Party Objects Microsoft Excel, PDF, Power-
Point, Flash, Word, text, and
rich text
Users Users, groups, Inboxes, Fa-
vorites, and Personal Catego-
ry
Business Intelligence plat- Folders, Events, Categories,
form Calendars, Access Levels,
Hyperlinks, Shortcuts, Pro-
grams, Profiles, Object Pack-
ages, Agnostic
Universe Universe, Connections, and
UniverseOverload
Replication Examples
Scenario 1: A retail company with a centralized design wants to send a monthly sales report to
the different store locations using the one-way replication method. The administrator at the
origin site creates a report that administrators at each destination site replicate and run
against that store’s database.
Hint:
Localized instances can be sent back to the origin site that maintain each
object’s replicated information. For example, it will apply the appropriate log,
database connection information, and so on.

Lesson: Replicating a BI Platform Deployment
Scenario 2: A company was to set up remote scheduling with distributed access. The data is
at the origin site. Pending replication jobs are sent to the origin site to run. Completed
replication jobs are then sent back to the destination sites for viewing. For example, the data
for a report might not be available on the destination site, but the user can configure the
reports to run on the origin site before the complete report is sent back to the destination site.
Replication Scenario 1
● Scenario 1: Retail with a centralized design

- A retail company sends a monthly sales report to different store locations.
- It uses a one-way replication method.
- The administrator at the origin site creates a report.
- Administrators at each destination site replicate and run the report against each store’s
database.
Replication Scenario 2
● Scenario 2: Remote schedule with distributed access

- Data is centralized at origin site.
- Pending jobs are sent to the origin site to run.
- Completed replication jobs are sent back to the destination site for viewing.
- The user can configure the report to run on the origin site before the completed report
is sent back to the destination site.
Federation Terms
BI application
The logical grouping of related Business Intelligence (BI) content with a specific purpose
and audience. A BI application is not an object. One BI platform deployment can host
multiple BI applications, each of which can have a separate security model, life cycle,
testing and deployment timeline, as well as separate business owners and
administrators.
Destination site
A BI platform system that pulls replicated BI platform content from an origin site.
Local
The local system where a user or administrator is connected. For example, the
administrator of a destination site is considered “local” to the destination site.
Locally run completed instances
Instances that are processed on the destination site and then sent back to the origin site.
Multiple origin sites
More than one site can serve as an origin site. For example, multiple development
centers generally have multiple origin sites. However, there can be only one origin site
per replication.
One-way replication

Objects are replicated only in one direction: from the origin site to the destination site.
Any updates made at a destination site remain at that destination site.
Origin site
The BI platform system where the content originates.
Remote
A system that is not local to a user. For example, the origin site is considered “remote” to
users and administrators of the destination site.
Remote connection
An object that contains information used to connect to a BI platform deployment,
including username and password, CMS name, WebService URI, and clean-up options.
Remote scheduling
Schedule requests that are sent from the destination site to the origin site. Reports on
destination sites can be scheduled remotely, which sends the report instance back to the
origin site for processing. Then the completed instance is returned to the destination site.
Replication
The process of copying content from one BI platform system to another.
Replication job
An object that contains information about replication scheduling, which content to
replicate, and any special conditions that should be performed when replicating content.
Replication list
A list of the objects to be replicated. A replication list refers to other content such as
users, groups, reports, and so on, in the BI platform deployment to be replicated
together.
Replication object
An object that is replicated from an origin site to a destination site. All replicated objects
on a destination site will be flagged with a replication icon. If there is a conflict, objects will
be flagged with a conflict icon.
Replication package
Created during the transfer, the replication package contains objects from a replication
job. It can contain all the objects defined in the replication list, as in the case of a rapidly
changing environment or initial replication. Or it can contain a subset of the replication
list if the objects change infrequently compared to the schedule of the replication job.
The replication package is implemented as a BI Application Resource (BIAR) file.
Replication refresh
All objects in a replication list are refreshed regardless of the last modified version.
Two-way replication
Two-way replication acts the same as one-way replication, but two-way replication also
sends changes in both directions. Updates to the origin site are replicated to each
destination site. Updates and new objects on a destination site are sent to the origin site.
Replication Types and Mode Options

There are different replication types and replication modes available.
Replication Types and Modes

You may choose a replication type and replication mode from the following options:

● One-way replication
● Two-way replication
● Refresh from origin
● Refresh from destination
Depending on your selection of replication type and replication mode, you will create one of
four different replication job options: one-way replication, two-way replication, refresh from
origin, or refresh from destination.
One-way replication
With one-way replication, you can only replicate content in one direction—from the origin site
to a destination site. Any changes made to objects on the origin site in the replication list are
sent to the destination site. However, changes made to objects on a destination site are not
sent back to the origin site.
One-way replication is ideal for deployments with one central BI platform deployment where
objects are created, modified, and administered. Other deployments use the content of the
central deployment.
Two-way replication
With two-way replication, you can replicate content in both directions between the origin and
destination sites. Any changes made to objects on the origin site are sent to destination sites,
and changes made on a destination site are sent to the origin site during replication.
To perform remote scheduling and to send locally run instances back to the origin site, you
must select two-way replication mode.
If you have multiple BI platform deployments where content is created, modified,
administered, and used at both locations, two-way replication is the most efficient option. It
also helps synchronize the deployments.
Refresh from origin or refresh from destination
When you replicate content in one-way or two-way replication modes, the objects on the
replication list are replicated to a destination site. However, not all of the objects might
replicate each time the replication job runs. Federation has an optimization engine designed
to help finish your replication jobs faster. It uses a combination of the object’s version and
time stamp to determine if the object was modified since the last replication. This check is
done on objects specifically selected in the replication list and any objects replicated during
dependency checking. However, in some cases the optimization engine might miss objects,
which then are not replicated. In these cases, you can use Refresh from Origin and Refresh
from Destination to force the replication job to replicate content and any dependencies,
regardless of the timestamps. Refresh from Origin only sends content from the origin to the
destination sites. Refresh from Destination only sends content from the destination sites to
the origin site.
Forced Replication of Content

The following three examples describe scenarios using Refresh from Origin and Refresh from
Destination where certain objects will be missed due to the optimization.
Scenario 1: The addition of objects that contain other objects into an area that is being
replicated
Folder A is replicated from the origin site to the destination site. It now exists on both sites. A
user moves or copies Folder B with Report B, into Folder A on the origin site. During the next
replication, Federation will see that Folder B’s timestamp has changed and will replicate it to

the destination site. However, Report B’s timestamp does not change. Therefore, it will be
missed by a regular one-way or two-way replication job.
To ensure Folder B’s content is properly replicated, a replication job with Refresh from Origin
should be used once. After this, the regular one-way or two-way replication job will replicate it
properly. If this example is reversed and Folder B is moved or copied on the destination site,
then use Refresh from Destination.
Replication of Content: Scenario 1

Scenario 2: The addition of new objects using LifeCycle Manager or the BIAR command line
When you add objects to an area that is being replicated using LifeCycle Manager or BIAR
command line, the object might not be picked up by a regular one-way or two-way replication
job. This occurs because the internal clocks on the source and destination systems could be
out of sync when using the LifeCycle Manager or BIAR command line.
Note:
After importing new objects into an area that is being replicated on the origin site,
it is recommended that you run a “Refresh from Origin” replication job. After
importing new objects into an area that is being replicated on the destination site,
it is recommended that you run a “Refresh from Destination” replication job.
● Scenario 2: The addition of new objects using LifeCycle Manager or the BIAR command
line
- An area is being replicated using LifeCycle Manager or the BIAR command line.
- Objects are added to that area.
- The internal clocks on the origin and destination systems might not be synchronized.
- The added objects might not be picked up during a regular one-way or two-way
replication job.
Scenario 3: In between scheduled replication times

If you add objects to an area that is being replicated and can’t wait until the next scheduled
replication time, you can use “Refresh from Origin” and “Refresh from Destination”
replication jobs. By selecting the area where objects have been added, you can replicate
content quickly.

Note:
This scenario can be costly for large replication lists, so it is recommended that
you do not use this option often. For example, it is not necessary to create
replication jobs to refresh from the origin to destination mode on an hourly
schedule. These modes should be used in “run now” or infrequent schedules.
In some cases, you cannot use conflict resolution, including the following
situations:
● Refresh from Origin: Destination site wins option is blocked.
● Refresh from Destination: Origin site wins option is blocked.
● Scenario 3: In between scheduled replication times

- Objects are added to an area.
- Replication must be performed before the next scheduled replication time.
- Either one of the Refresh from Origin or Refresh from Destination replication buttons are
selected for the jobs.
- The area where objects have been added must be selected and the content replicated
quickly.
Conflict Detection and Resolution

In Federation, a conflict can occur when the properties of an object are changed on both the
origin site and destination site. Both top level and nested properties of an object are checked
for conflicts. For example, a conflict can occur if a report or the name of a report is modified
on both the origin and destination sites.
Some instances do not create a conflict. For example, if the name of a report is modified on
the origin site, and the description of the replicated version is modified on the destination site,
the changes merge together and no conflict occurs.
One-Way Replication Conflict Resolution
● In one-way replication, you have two choices for conflict resolution:

- Origin site takes precedence
- No automatic conflict resolution
Origin site takes precedence

If a conflict occurs during one-way replication, the origin site object takes precedence. Any
changes to objects on a destination site are overwritten by the origin site’s information. For
example, if a report is modified on both the origin site and the destination site, the destination
site modification will be overwritten by the origin site version after the next replication job.
Because the conflict is automatically resolved, it is not generated in the log file and does not
appear in the conflicting object list.
No automatic conflict resolution

If a conflict occurs and you select No automatic conflict resolution, the conflict is not resolved,
a log file is not generated, and it does not appear in the conflicting object list. Administrators
can access a list of all replicated objects that are in conflict in the Federation area of the CMC.
Objects in conflict are grouped together by the remote connection they used to connect to
the origin site with. To access these lists, go to the Replication Errors folder in the Federation
area of the CMC, and select the desired remote connection. All replicated objects on a
destination site will be flagged with a replication icon. If there is a conflict, objects will be
flagged with a conflict icon. A warning message also appears in the Properties page.
Two-Way Replication Conflict Resolution
● In two-way replication, you have three choices for conflict resolution:

- Origin site takes precedence
- Destination site takes precedence
- No automatic conflict resolution
Origin site takes precedence

If a conflict occurs during two-way replication, the origin site object takes precedence and
overwrite any changes to the destination site.
For example, user A modifies the name of a report to Report A. User B modifies the name of
the replicated version of the report on the destination site to Report B. After the next
replication job runs, the replicated version on the destination site will revert to Report A. This
action will not generate a conflict in the log file, and the report will not appear in the conflicting
object list, because the conflict was resolved according to user A’s instructions on the origin
site.
Destination site takes precedence
If a conflict occurs, the destination site keeps its changes and overwrites them to the origin
site.
For example, user A modifies the name of a report to Report A. User B modifies the name of
the replication version on the destination site to Report B. When the replication job runs, a
conflict is detected. The name of the destination report remains as Report B. In two-way
replication, changes are also sent back to the origin site. In this example, the origin site is
updated, and its report name is changed to Report B. This does not generate a conflict in the
log file, and it will not appear in the conflicting object list, because the conflict was resolved
according to user B’s instructions.
No automatic conflict resolution
When No automatic conflict resolution is selected, a conflict will not be resolved. The conflict
will be noted in a log file for the administrator, who can manually resolve it.
For example, user A modifies Report A on the origin site. User B modifies the replicated
version on the destination site. When the next replication job runs, the report is in conflict,
because it has changed on both sites and will not be resolved. The destination report is kept
and changes to the origin’s report are not replicated. Subsequent replication jobs behave the
same way until the conflict is resolved. Any changes on the origin site will not get replicated
until the conflict is manually resolved by the administrator or delegated administrator.
Best Practices for Optimizing Replication

You can use Federation to optimize the performance of a replication job. Typically, you should
be able to replicate up to 32,000 objects in each replication job. However, some deployments

might require configurations with smaller or larger replication sizes. If there are a large
number of objects in a single replication job, you can take additional steps to ensure that it
runs successfully:
Additional Steps for Replicating Large Number of Objects
● Obtain a dedicated Web services provider.

● Increase the Java Application server’s available memory.
● Reduce the size of the BIAR files being created.
● Reduce the socket timeout duration.
Figure 102: Optimization of Performance of a Replication Job
Obtain a Dedicated Web Services Provider

In Federation, replicated content is sent using Web services. In a default installation of BI
platform, all Web services use the same Web service provider. Larger replication jobs might
tie up the Web service provider longer and slow down its response to other web service
requests as well as any applications it serves.
If you plan to replicate a large number of objects at once, or run several replication jobs in
sequence, you might consider deploying Federation Web services on its own Java Application
server using your own Web services provider.
To do this, use the BI platform installer to install web services. You must have a Java
Application Server already running. If you do not, install the entire Web Tier Components
option, which will install Web Services and Tomcat.
Increase the Java Application Server’s Available Memory
Increase the available memory of your Java Application Server if your single replication job
replicates many objects or if you are sharing the Application Server with other applications.

Reduce the Size of the BIAR Files Being Created

Federation uses Web Services to replicate content between the origin site and destination
site. Objects are grouped together and compressed into BIAR files for more efficient
transportation. When replicating a large number of objects, configure your Java Application
Server to create smaller BIAR files. Federation will package and compress objects across
multiple smaller BIAR files so the number of objects you want to replicate will not be limited.
Increase the Socket Timeout Duration
The Adaptive Job Server is responsible for running the replication job. During the execution of
the replication job, the Adaptive Job Server establishes a connection to the origin site. When
receiving large amounts of information from the origin site, it is important that the socket
which the Adaptive Job Server is using to receive information does not time out. The default
value is 90 minutes. You can increase the socket timeout duration if you need to.
LESSON SUMMARY

Unit 9
Learning Assessment
1. Federation is a cross-site replication tool for working with a single SAP BusinessObjects
Business Intelligence platform deployment.
X True
X False
2. Conflict can occur in which scenario?

X A When the properties of an object are changed on the origin site.
X B When the properties of an object are changed on the destination site.
X C When the properties of an object are changed on both the origin site and
destination site.
X D When the properties of an object are not changed on the origin site and destination
site.

Unit 9
1. Federation is a cross-site replication tool for working with a single SAP BusinessObjects
Business Intelligence platform deployment.
X True
X False
2. Conflict can occur in which scenario?

X A When the properties of an object are changed on the origin site.
X B When the properties of an object are changed on the destination site.
X C When the properties of an object are changed on both the origin site and
destination site.
X D When the properties of an object are not changed on the origin site and destination
site.

UNIT 10 Disaster Recovery in the SAP
Business Intelligence Platform
4.3
Lesson 1
Planning for Disaster Recovery 301
UNIT OBJECTIVES
● Describe guidelines and best practices for disaster recovery

Unit 10: Disaster Recovery in the SAP Business Intelligence Platform 4.3

Unit 10
Lesson 1
Planning for Disaster Recovery
LESSON OVERVIEW
In this lesson, we consider the importance of being prepared for disaster and best practice in
terms of recovery strategies.
LESSON OBJECTIVES
Disaster Recovery Readiness

You should be familiar with both in-place recovery and disaster recovery.
In-Place Recovery versus Disaster Recovery

The distinction between in-place recovery and disaster recovery can be summarized as
follows:
● In-place restore is the recovery of your production system on the same hardware.
● Disaster recovery is the recovery of your production system in a remote location.
Vertical and Horizontal Scaling
Success with Scalability

The following are considerations when scaling:
Scalability is a key success factor for business applications in a dynamic environment.
BusinessObjects 4.x scales both vertically and horizontally.
Vertical scaling, also known as scaling up, means adding more hardware resources (for
example, processors and memory) to the same machine. In the context of BusinessObjects
4.x, this means the ability to add multiple servers on the same machine.
Horizontal scaling, also known as scaling out, means adding more machines into the solution.
In the context of BusinessObjects 4.x, this means the ability to seamlessly run multiple
servers on multiple machines.

Deployment Solution Backup and Recovery Strategy
Figure 103: Back-Up Strategy
Backup Strategy
The following are considerations when establishing a backup strategy:
● The FRS (Input and Output) folders should be on a highly available SAN or NAS storage
device
● The CMS DB (Audit optional) should be on a DB cluster which has a regular backup
- Weekly full backup
- Daily incremental
- Transactional
● File and machine configurations should be documented and stored on the network
● VMs should also be backed up (weekly)
● Back up files should be stored on another geographical location

Lesson: Planning for Disaster Recovery
Figure 104: High Availability Components
The figure, High Availability Components, illustrates a high level architecture for disaster
recovery planning.

Migration and Back-up of CMS System Data
Figure 105: Migration and Back-up of CMS Data
Once the Disaster Recovery architecture has been designed, the figure, Migration and Back-
up of CMS Data, illustrates the work-flow for how to manage the recovery process.
Disaster and Recovery

Disaster and Recovery Terms
When discussing disaster and recovery, it is important to understand the following terms:
● Disaster
Any unanticipated event that creates a defined problem can be called a disaster. Disasters
are usually considered in terms of severity.
● Disaster Recovery Planning
Disaster recovery is the processes, policies, and procedures involved when restoring
operations that are critical to the resumption of business.
Fault Tolerance Requirements

When discussing fault tolerance requirements, it is important to understand the following:
● There is no single point of failure.

● Faults are isolated to the failing component.
● Faults are contained to prevent the propagation of failure.

Lesson: Planning for Disaster Recovery
● There is no single point of repair.
Network Storage
When discussing network storage, it is important to understand the following terms:
● Storage Area Network (SAN)

SAN is an architecture that attaches remote computer storage devices (such as disk
arrays, tape libraries, and optical jukeboxes) to servers in such a way that, to the operating
system, the devices appear as if they were locally attached.
● Network Attached Storage (NAS)
NAS is essentially a self-contained computer that is connected to a network with the sole
purpose of supplying the file-based data storage services to other devices on the network.
It uses the UNC path to locate files and folders. Its operating system manages its
resources.
Note:
An NAS head is a translator for SAN storage.
The figure Network Storage in the Environment illustrates a high level architecture of how NAS
devices can be leveraged in your SAP BusinessObjects BI platform 4.3 disaster recovery plan.
Figure 106: Network Storage in the Environment

Recovery Plan: Vertical Strategy

A vertical strategy for high availability includes the following:
● Multiple CMS servers are created on different machines.

● A second input FRS and a second output FRS are created.
● Multiple processing servers are included.
● The Tomcat and Apache servers are clustered.
Recovery Plan: Horizontal Strategy

A horizontal strategy for high availability includes the following:
● A second database is implemented as a back-up database, which replicated data on a

constant basis from the CMS system database and the Audit database. This database is
kept inactive.
● The FRS folders are kept on a backed up NAS/SAN storage.
● Another BI platform is implemented but kept inactive. It connects to the backup database
and the NAS/SAN storage, and it does not have to be a mirror of the production BI
platform.
● In case of disaster, the CMS system database and the back-up BI platform are activated.
LESSON SUMMARY

Unit 10
Learning Assessment
1. As it pertains to backups, what are the recommendations in terms of time frequency? In

other words, how often should backups take place?'

Unit 10
1. As it pertains to backups, what are the recommendations in terms of time frequency? In

other words, how often should backups take place?'
The time frequency recommendations for backups are a weekly full backup and daily
incremental backups.

Boe330 en Col17

Uploaded by

Copyright:

Available Formats

Boe330 en Col17

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Boe330 en Col17

Uploaded by

Copyright:

Available Formats

BOE330

SAP BusinessObjects Business

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

American English is the standard used in this handbook.

This information is displayed in the instructor’s presentation

Related or Additional Information

User interface control Example text

Window title Example text

© Copyright. All rights reserved. iii

vii Course Overview

1 Unit 1: Reviewing Architecture, Administration, and Security in SAP

3 Lesson: Describing the BI Platform Architecture, System, and

61 Unit 2: Identifying Requirements

63 Lesson: Assessing your Organization's Environment

67 Unit 3: Planning a Deployment

69 Lesson: Identifying Factors to Consider when Deploying a BI

97 Unit 4: Deployment Design and Sizing

99 Lesson: Designing an SAP Business Intelligence Deployment

159 Unit 5: Deployment and Configuration of an SAP Business Intelligence

161 Lesson: Planning a Deployment Solution

© Copyright. All rights reserved. v

219 Lesson: Preparing to Manage Content

251 Unit 7: Publications and Single Pass Report Bursting

253 Lesson: Designing Publications

265 Unit 8: Deployment Administration

267 Lesson: Performing Advanced Troubleshooting of a BI Platform

285 Unit 9: Deployment Replication (Optional)

287 Lesson: Replicating a BI Platform Deployment

301 Lesson: Planning for Disaster Recovery

vi © Copyright. All rights reserved.

© Copyright. All rights reserved. vii

● Describe the SAP strategic focus on BI

© Copyright. All rights reserved. 1

2 © Copyright. All rights reserved.

SAP BusinessObjects Analytics Editions

© Copyright. All rights reserved. 3

4 © Copyright. All rights reserved.

Functions of the SAP BusinessObjects BI Suite Client Tools

Figure 3: The Maturity of BI from Raw Data to Optimization

© Copyright. All rights reserved. 5

Advantages of the SAP Strategic Focus on BI

Benefits of a BI Strategy to the Organization

Benefits of a BI Strategy to the Line of Business

● Departmental spending achieves more and contributes to the investments of the

Facilitated Discussion: Advantages of the SAP Strategic Focus on BI

6 © Copyright. All rights reserved.

BI Suites on the BI Platform

Leveraging the Cloud for SAP BusinessObjects Business Intelligence Platform

Enterprise BI with SAP BI 4

© Copyright. All rights reserved. 7

Figure 5: SAP BusinessObjects BI 4 for Cloud Deployments

SAP BusinessObjects BI 4 for Cloud Deployment Options

● SAP HANA Enterprise Cloud

8 © Copyright. All rights reserved.

BI Platform System Overview

Figure 6: One Suite for All Insight

Discovery, Prediction, and Creation

● Discover areas to optimize your business.

● Deliver engaging information to users where they need it.

● Securely distribute information across your organization.