SAP BI Prepared By SIT-----Tehno-Functional Module

SAP BI Prepared By SIT-----Tehno-Functional Module
SAP BI
Page 1 of 150
Table of contents
1 Introduction to Business Intelligence & Data Warehousing
1.1. Business Intelligence and Data Warehousing
1.2. The Classic Star Schema
1.3. Introduction to SAP BW
1.4. SAP BW Architecture
1.5. The SAP BW Star Schema
1.6. Introduction to Administrator Workbench (AWB)
2 Introduction to InfoObjects & InfoCubes
2.1. Introduction to InfoObjects
2.2. Types of InfoObjects
2.3. Characteristic InfoObject
2.4. Creating a Characteristic in the InfoObject Tree
2.5. Key Figures
2.6. InfoCubes
2.7. BasisCubes
2.8. Creating an InfoCube in the InfoProvider Tree
2.9. Technical Implementation of SAP BW Star Schema
3 Data Transfer Process in SAP BI
3.1. Overview of Data Transfer Process
3.2. Data Transfer Process – Example
3.3. Creating and Managing DTP
3.4. Error Handling of DTP
3.5. Error Stack in DTP
3.6. Temporary Storage for DTP
3.7. DTP Monitor
3.8. Managing InfoCubes-Data Maintenance
3.9. Using BW Monitor
4 Data Store Objects (DSO)
4.1. Data Store Object definition:
4.2. Data Store Object Types
4.3. Data Store Object Administration
5 MultiProviders
6 Aggregates
6.1. Using Aggregates
7 Admin Cockpit
8 Process Chains
9 Generic R/3 Data Extraction
9.1. Creating Views in R/3
9.2. Creating DataSources in R/3.
Page 2 of 150
9.3. Loading Data from R/3 into BW

10 Logistics Cockpit
10.1. What is Logistic Cockpit (LC)?
10.2. Logistic Cockpit Functions
11 Reporting and Analysis
11.1. SAP BW Business Explorer
11.2. Working with BEx
11.3. BEx Analyzer
11.4. Restricted Key Figures
11.5. Calculated Key Figures
11.6. Variables
11.7. Content Variables
11.8. Exceptions
11.9. Creating Exceptions
11.10
. Conditions
12 BEx Web Application Designer
12.1. Introduction
12.2. Features
Page 3 of 150
ERP
What is ERP?
Enterprise Resource Planning or ERP is an industry term for integrated,

muti-module application software packages that are designed to serve and
support multiple business functions. An ERP system can include software for
manufacturing, order entry, accounts receivable and payable, general
ledger, purchasing, warehousing, transportation and human resources.
Evolving out of the manufacturing industry, ERP implies the use of packaged
software rather than proprietary software written by or for one customer.
ERP Market Leaders
• Oracle Apps
• People soft, Inc.
• JD Edwards
• SAP
The company name, SAP, is an acronym for Systems, Applications and
Products in Data Processing (in German: Systemanalyse und
Programmentwicklung). The company was founded in 1972 by four former
IBM employees. The company's headquarters are in Walldorf in Germany.
Benefits of R/3
• Integration
• World wide Usage
• Real Time processing
• Flexibility
Page 4 of 150
SAP Delivers
Solution for…
All geographic regions
19 industry solutions
Solutions for companies of any size
Solutions for companies and end user
Scalable for your company
Continuous development of technology
Continuous value innovation
Based on user
Applications are immediately applicable
The Objective
Make the SAP Software easier to learn, use and more
adjustable
The Way
Listening (Competition, user visits)
Revisiting all SAP-applications in the lab
New visual design “intuitively usable”
New interactions “high speed”
New more individual, role based user interface
“adjusted on my requirements”
Co-operation with international recognised design experts
Business Processes: ASAP-Methodology
ASAP Roadmap
Continuous
Project
Preparation Final Improvement
Preparation
Go Live &
Business Realization Support
Blueprint
Page 5 of 150
Introduction to Business Intelligence

& Data Warehousing
1.1. Business Intelligence and Data Warehousing
Business Intelligence is a technology based on customer and profit oriented

models that reduce operating costs and provide increased profitability by
improving productivity, sales, and service and help to make decision-making
capabilities at no time. Business Intelligence Models are based on multi
dimensional analysis capabilities.
BI solutions differ from and add value to standard operational systems

(OLTP systems – Online Transaction Processing systems) in three ways -
• By providing the ability to extract, cleanse and aggregate data from

multiple operational systems into a separate data mart or data
warehouse
• By storing data often in a star or multi dimensional cube format, to
enable rapid delivery of summarized information and drill down to
detail
• By delivering personalized, relevant informational views and
querying, reporting and analysis capabilities for gaining deeper
business understanding and making better decisions faster
To implement BI, the following technologies are used-

• Data Marts/ Data Warehouses - A data warehouse is a subject
oriented, integrated, time variant, non-volatile collection of data in
support of management's decision-making process. To facilitate data
retrieval for multi dimensional analytical processing, a special
database design technique called a star schema is used very often.
• Extraction, Transformation and Loading (ETL) - Data is extracted

from multiple source systems. Data is cleansed and transformed and
into a consistent format and structure. The cleansed data is loaded
into the data warehouse.
• On-Line Analytical Processing (OLAP) and Data Mining - Analysis tools

are applied against the data warehouse to analyze and mine the
data.
The main differences between an OLTP and an OLAP system are as follows –
Page 6 of 150
Criteria OLTP data OLAP data

Purpose OLTP servers handle OLAP servers handle
mission critical management critical
production data accessed data accessed through
through simple queries. an iterative analytical
investigation.
Time Scale Organization’s day-to- Historical data for trend
day operational data. analysis.
Current data.
Organization Organized around Organized around
business functions. information topics.
Values Typically coded data Typically descriptive
(e.g. product codes) for data (e.g. product
efficiency reasons. names) for ease-of-use
reasons.
Operations Insert, Delete, Update. Read only.
performed
Table 1.1: Comparison of OLTP and OLAP Data
Difference Between BW and BI Data Flow.
BW DATA FLOW.
BI DATA FLOW.
Page 7 of 150
1.2. The Classic Star Schema

The star schema derives its name from its graphical representation like a
star. This database schema classifies two groups of data: facts (sales or
quantity, for example) and dimension attributes (customer, time, and
material, for example).
A fact is measure that answers the questions like “how much?” and “how
many?” The fact data (values for the facts) are stored in a highly normalized
fact table. A dimension is a textual description of the dimensions/features
of the business. The dimension answers the questions “Who? What? When?”
For example, the dimensions of a product may include product name, brand
name, size, and packaging type.
As shown in figure 1.1, a fact table appears in the middle of the graphic,
along with several surrounding dimension tables. The central fact table is
usually very large, measured in gigabytes. It is the table from which we
retrieve the statistical data. The size of the dimension tables amounts to
only 1 to 5 percent of the size of the fact table. Foreign keys tie the fact
table to the dimension tables.
Page 8 of 150
Classic Star Schema
EXTENDED STAR SCHMEA.
Extend star schema, dimension and master data table are different. (Master data resides outside the
Infocube and dimension table, inside Infocubecube).
Page 9 of 150
Connecting Master Data Tables to an InfoCube
DIFFERENCE BETWEEN STAR SCHMA(Classic) AND EXTENDED(BW) SCHMA

Classic Star Schema BW Star Schema
Fact Key Figure
Dimension Attribute Characteristic
Described Attribute Attribute

Text
- External Hierarchies
Dimension Tables Dimension Tables

(Contain Master Data) (do not contain Master data
Dimension = Dimension Table Dimension =

Dimension Table (optional),
SID Tables,
Master Data Tables (optional)
Page 10 of 150
1.3. Introduction to SAP BW

The SAP Business Information Warehouse (SAP BW) is a state-of-the-art,
end-to-end data warehouse solution developed by SAP. It enables users to
analyze data from operative SAP applications as well as from other business
applications and external data sources such as databases, online services
and the Internet.
SAP BW enables Online Analytical Processing (OLAP) for staging of
information from large amounts of operative and historical data. SAP BW
server is pre-configured for core areas and processes and allows users to
examine the relationships in all areas of an organization.
With the Business Explorer (BEx), SAP BW gives a flexible reporting and
analysis tool to support strategic analyses and decision-making processes
within an organization. These tools include querying, reporting and OLAP
functions.
1.4. SAP BW Architecture

SAP BW architecture is made up of three functional layers.
• Source Systems
• SAP BW Server
• SAP BW OLAP
Figure 1.2: SAP BW Three Layer Architecture
1.4.1. Source Systems

A source system is a reference system that functions as a data provider for
SAP BW. SAP BW distinguishes between four kinds of source systems:
Page 11 of 150
1.4.1.1. mySAP.com Components

SAP BW is fully integrated into the new mySAP.com world. SAP has provided
a set of predefined extraction structures and programs, called DataSources,
to extract the source data from mySAP.com components and then to load
the data directly into SAP BW.
A SAPI (Service Application Programming Interface) is an SAP-internal
component that is delivered as of Basis release 3.1i. Communication
between mySAP.com components and SAP BW takes place via this SAPI.
1.4.1.2. Non-SAP Systems

The open architecture of SAP BW allows data to be extracted from
heterogeneous sources across the organization thus making it possible to
have consolidated data basis for reporting. SAP delivers various tools,
which allow these interfaces to be implemented quickly and efficiently.
In heterogeneous system landscapes, an important requirement is that the

different data structures and content are consolidated before being loaded
into SAP BW. You can use an ETL tool such as Ascential DataStage to load
data from heterogeneous systems, such as Siebel and PeopleSoft, transform
this data into a single format and then load it via a Business Programming
Interface into SAP BW. BAPI is the interface used for the structured
communication between SAP BW and external systems. Both data providers
and ETL tools use this interface.
SAP automatically supports automatic import of files in CSV or ASCII format

for flat files as standard.
The SOAP (Simple Object Access Protocol) RFC Service is used to read XML
data and to store it in a delta queue in SAP BW. The data can then be
processed further with a corresponding DataSource and SAPI.
1.4.1.3. Data Providers

SAP BW can also be supplied with target-orientated data from various
providers. For example, you can compare the market research data
provided by an agency with your own operative data. Again, BAPI is used for
the transfer of data supplied by the data providers to SAP BW.
1.4.1.4. Databases
SAP BW allows data to be loaded from external relational database systems.
A DataSource is generated based on the external table structure, enabling
table content to be loaded quickly and consistently into SAP BW.
DB Connect is a way, which allows relational databases to be accessed
directly. Here, SAP DB MultiConnect is used to create a connection to the
database management system (DBMS) in the external database. By
Page 12 of 150
importing metadata and original data, the necessary structures can be

generated in SAP BW and the data can be loaded into the SAP BW system.
1.4.2. SAP BW Server

SAP BW server provides a 'Staging Engine', which controls the data loading
process. It also features SAP BW databases, which store master, transaction
and metadata.
The Administrator WorkBench (AWB) is responsible for the control,

monitoring and maintenance of all data procurement processes. The
Administrator WorkBench is the place where you define all relevant
information objects, plan load processes using a scheduler, and monitor
them using a monitor tool. However, before the data is in a suitable form to
be stored, it must be prepared by the Extraction, Transformation and Load
(ETL) process.
1.4.3. SAP BW OLAP

The Online Analytical Processing (OLAP) processor allows you to carry out
multi-dimensional analyses of SAP BW data sets. It also provides the OLAP
tools with data via the BAPI, XML/A or ODBO (OLE DB for OLAP) interfaces.
In principle, the OLAP area can be divided into three components:
• BEx Analyzer (Microsoft Excel based)
• BEx Web Application
• BEx Mobile Intelligence
You can use these tools to carry out both Microsoft Excel and Web-based
analyses across several dimensions (such as time, place, product, and so on)
simultaneously.
1.5. The SAP BW Star Schema

The multi-dimensional model in SAP BW is based on the SAP BW star
schema. SAP came up with the enhanced star schema to resolve the
problems experienced with the classic star schema. Figure 1.3 shows the
crossover between the classic star schema shown in the Figure 1.1 and the
SAP BW star schema. For the time being, only components relevant to the
modeling view are taken into consideration.
Page 13 of 150
SAP BW Star Schema
The main distinction between a classic start schema and SAP BW star
schema is that in the SAP BW star schema the dimension tables do not
contain master data information. This master data information is stored in
separate tables, called master data tables. We can think of the SAP BW star
schema as two self-contained areas:
• InfoCube
• Master Data Tables/Surrogate ID (SID-) Tables
1.5.1. InfoCube
InfoCubes are the central objects of the multi-dimensional model in SAP
BW. Reports and analyses are based on these. From a reporting perspective,
an InfoCube describes a self-contained data set within a business area, for
which you can define queries.
An InfoCube (BasisCube) consists of a number of relational tables- a central
fact table surrounded by several dimension tables- combined on a multi-
dimensional basis.
Page 14 of 150
InfoCube
In the SAP BW- star schema, the facts in the fact table are referred to as
key figures and the dimension attributes as characteristics. The dimension
tables are linked relationally with the central fact table by way of foreign
or primary key relationships. In contrast to the classic star schema, the
characteristic values are not stored in the dimension tables. A numerical SID
key is generated for each characteristic. This foreign key replaces the
characteristic as the component of the dimension table. Here, SID stands
for Surrogate ID (replacement key). In the graphic above, these keys are
given the prefix SID_. For example, 'SID_MATERIAL' is the SID key for the
characteristic 'MATERIAL' ('MATERIAL_ID').
Each dimension table has a generated numerical 'primary key', called the
dimension key. In the graphic above, this dimension key is denoted with
the prefix DIM_ID_. Here, 'DIM_ID_MATERIAL' is the dimension key for the
material dimension table.
As in the classic star schema, the primary key of the fact table is made up
of dimension keys ('DIM_ID_DATENPAKET', 'DIM_ID_ZEIT', 'DIM_ID_EINHEIT',
'DIM_ID_KUNDE', 'DIM_ID_MATERIAL').
1.5.2. Master Data Tables/SID Tables

Additional information about characteristics is referred to as master data in
the SAP BW. The master data is classified into three types:
• Attributes
• Texts
• (External) hierarchies
Page 15 of 150
Master data information is stored in separate tables called master data

tables (separately for attributes, texts and hierarchies). These tables are
independent of the InfoCube. For example, as shown in the Figure 1.3, the
attribute ‘material group’ is stored in the attribute table, the text
description for 'material name' is stored in the text table and the material
hierarchy is stored in the hierarchy table for the characteristic 'MATERIAL'.
In this way, the characteristic 'MATERIAL' is the primary key for the master
data tables belonging to this characteristic.
As mentioned earlier, precisely one numerical SID key is assigned to each

characteristic. This assignment is made in a SID table for the respective
characteristic, whereby the characteristic becomes the primary key in the
SID table. As shown in the Figure 1.5, the SID key 'SID_MATERIAL' is assigned
to the characteristic 'MATERIAL' in the SID table for characteristic
'MATERIAL'. The SID table is connected to the associated master data tables
via the characteristic key.
Master Data Tables
1.5.3. Connecting Master Data Tables to an InfoCube

Master data tables are connected to an InfoCube (and thus to the key
figures of the fact table) by way of the SID tables. The following graphic
illustrates this.
Page 16 of 150
Connecting Master Data Tables to InfoCube
The excavation of master data from the dimension tables using SID
technology allows you to use the same master data with different
InfoCubes. In other words, the master data is InfoCube-independent, and
can be used by several InfoCubes at the same time.
Sharing Master Data Tables among InfoCubes
Page 17 of 150
1.5.4. Comparison of SAP BW Star Schema and Classic Star

Schema
Classic Start Schema SAP BW Star Schema

Cube InfoCube
Measure Key figure or KPI
Fact table Fact table
(Dimension) Attribute • Characteristic
• Navigational attributes
• Display attributes
• (External) Hierarchy node
Dimension (Table) • Dimension table
• Master table
• Text table
• External hierarchy Table
• (SID) Table
NA Standard business content
NA Hierarchies
NA MultiProviders
NA Remote cubes
Comparison of SAP BW Star Schema and Classic Star Schema
1.5.5. Advantages of the SAP BW Star Schema

The use of automatically generated INT4 keys (SID keys, DIMID keys) enables
faster access to data than via long alphanumeric keys. Thanks to the
excavation of master data from the dimension tables using the SID
technique, the following modeling possibilities exist:
1.5.6. Disadvantages of the SAP BW Star Schema
A large number of joining operations take place due to introduction of
various tables. This could slow down the data access operations as
compared to the classic star schema.
1.5.7. SAP BW Star Schema Restrictions

To summarize the features of SAP BW Star Schema, remember the following
points.
• Maximum of 1 fact table per InfoCube
• Maximum of up to 16 dimension tables (containing different
characteristics) per InfoCube
• Minimum of 4 dimension tables (3 system reserved plus at least 1 user
defined) per InfoCube
• Maximum of 248 characteristics per dimension table
• Maximum of 233 key figures per InfoCube
Page 18 of 150
• The SAP BW star schema does not contain master data, hierarchy, or
texts (these data are stored outside of the star schema and are
readily available for querying).
1.6. Introduction to Data Warehousing Workbench:

The Data Warehousing Workbench (DWB) is the central tool for performing
the tasks in the data warehousing process. It provides data modeling
functions as well as functions for control, monitoring and maintenance of all
processes in SAP NetWeaver BI having to do with data procurement, data
retention, and data processing.
BW RSA1OLD Tcode screen, Administrator Workbench in 3.X
Page 19 of 150
RSA1 Tcode screen, Data warehousing Workbench in BI 7.X.
Functional Areas of the Data Warehousing Workbench:

• Modeling
• Administration
• Transport connection
• Documents
• Business Content
• Translation
• Metadata Repository
Page 20 of 150
Data Warehousing Workbench
• Modeling
- Database objects and Transformations are created
• Administration
- Load Scheduling, Monitoring and data Administration
• Transport Connection
- Specialized BI Transport Tool set
• Documents
- Central GUI for Maintenance of Documents
• BI Content
- Delivered Content is activated for Use
• Translation
- BI Objects( Queries, InfoCubes and so on) descriptions are Translated for
Multiple language support
• Metadata Repository
- Power Users and Functional Experts can find details on delivered and custom
content objects
Page 21 of 150
2 Introduction to InfoObjects &

InfoCubes
2.1. Introduction to InfoObjects

InfoObjects in SAP BW are the smallest available information modules or
fields. They contain the technical and specialist information for master and
transaction data in SAP BW. InfoObjects are part of the Metadata
Repository. They are uniquely identified with their technical name.
InfoObjects are the basic components of the SAP BW star schema. An
InfoObject is a generic term for SAP BW business evaluation objects.
2.2. Types of InfoObjects

The InfoObjects are divided into 2 types viz.
• Characteristics
Time Characteristics
Units
Technical Characteristics
• Key figures
1. Characteristics: In SAP-BW, attributes located in the dimension tables

are called Characteristics. In traditionally data modeling, a characteristic is
a field that allows activity to be categorized such as customer, customer
group, material, material group, product, product group, sales organization,
fiscal year, period, and regionSAP BW offers four possible data types for
characteristics:
1. CHAR (character)
2. NUMC (Numeric Character)
3. DATS (Date)
4. TIMS (time)
2. Key Figures (quantitative information, e.g., amount, count, quantity)
Key Figures – A key figure is a data element from a fact table and usually
represents numeric data that can be measured, such as revenues and gross
profit. The key figure InfoObjects provide the values to be evaluated. E.g.
Quantity sold (0QUANTITY), Amount (0AMOUNT), Headcount etc. In other
words, they represent the facts in the conventional data warehouse.
Characteristics - Characteristic InfoObjects are business reference objects,
which are used to analyze key figures E.g. Plant (0PLANT), Country
(0COUNTRY), Material (0MATERIAL), Product (MYPRODUCT). Characteristics
provide different views for analyzing the facts. The dimensions are formed
using Characteristic InfoObjects.
Page 22 of 150
Time Characteristics - Time characteristics form the time reference frame

for data analyses and evaluations. They are delivered with Business
Content. It is not possible to define your own time characteristics. Some of
the time characteristics available are Calendar Day (0CALDAY), Calendar
Month (0CALMONTH), Calendar Year (0CALYEAR), and Fiscal Year
(0FISCYEAR).
Units - The Unit InfoObjects enable key figure values to be associated with
their corresponding units in evaluation. E.g. Currency unit (0CURRENCY) can
be associated with the key figure Amount (0AMOUNT) and value unit (0UNIT)
with Quantity (0QUANTITY).
In SAP BW, all dependent objects need to be activated before they can be
used, including InfoObjects, InfoCubes,and so forth. Additionally, custom
InfoObjects can be created (e.g., to define a custom data file).
InfoObjects are organized in two areas of the SAP BW Administrator

Workbench (AWB):
1. InfoArea. An InfoArea is a folder in the AWB used to store and

organize related InfoObjects.
2. InfoObject Catalog. An InfoObject catalog is a folder in the AWB

containing related InfoObjects.
There are two types of InfoObject catalogs:
1. Characteristics
2. Key Figures
2.3. Characteristic InfoObject
As mentioned earlier, the characteristics InfoObjects are the business
reference objects using which we analyze the facts. While creating such
characteristics in SAP BW, the following tab pages are available in the
maintenance menu.
• General
• Business Explorer
• Master data/texts
• Attributes
• Hierarchy
• Compounding
General
This tab page is used to determine the basic properties of a characteristic,
for example description, data type (CHAR, NUMC, DATS or TIMS), length
(max. 60. characters in case of CHAR or NUMC) and conversion routine (E.g.
ALPHA, MATN1).
Page 23 of 150
Figure 2.1: Creating Characteristic InfoObject – General
Note: If the Attribute Only check box under Miscellaneous block is

selected, the attribute can be used only as a display attribute
Business Explorer (BEx)
This tab page is used to set the display defaults during reporting in the
Business Explorer (BEx).
Master data/texts
On this tab page, you determine whether or not the characteristic can have
attributes or texts.
Attributes
Attributes are themselves InfoObjects (characteristics/key figures) that are
used to describe characteristics in greater detail. For example, the
characteristic Customer Number can be described in more detail with other
InfoObjects like Customer Type and Customer Class, Address etc. If the
With master data indicator was set on the Master data/texts tab page you
are able to specify attributes and properties for these attributes together
with the characteristic on the Attributes tab page.
Page 24 of 150
Creating Characteristic InfoObject – Attributes
Attributes can be of 2 types – Display Attributes or Navigation Attributes.
Display Attributes - Display attributes can only be used as additional

information in reporting when combined with the characteristic. In other
words, in reporting, you cannot navigate within the dataset of a data target
(InfoCube or ODS object).
Navigation Attributes - Navigation attributes allow the users to navigate in

reporting. When a query is executed, the system does not distinguish
between navigation attributes and characteristics for a data target
(InfoCube or ODS) .
Example: The characteristic InfoObject "cost center" has the navigation
attribute "company code" (amongst others). In turn, this characteristic has
the navigation attribute "company". In this case, "company" is a transitive
attribute that you could activate as navigation attribute.
Note:
• If a characteristic InfoObjects is defined as Attribute Only, you can
only use this characteristic InfoObjects as a display attribute for another
characteristic.
• The extensive use of navigation attributes leads to a large
number of tables and joins, which can reduce performance.
Page 25 of 150
(External) Hierarchy
Hierarchies are used in analysis to describe alternative views of the data. A
hierarchy comprises of multiple nodes and leaves. The nodes stand in a
parent-child relationship and the hierarchy leaves are represented by the
characteristic values
SAP BW has a unique hierarchy implementation. Hierarchies are tree-like
structures on characteristic’s domain (e.g., ship to and bill to). In SAP BW,
hierarchies are a type of master data.
A hierarchy can be created using three methods:
1. Import from flat file

2. Manual creation in BW
3. Import from SAP R/3 (preferred option)
Two components of interest for hierarchies are:

• Leaves. A leaf is a characteristic value and represents the last level
of a hierarchy. The SID value for a leave is a positive random integer.
• Node. A node is a set of leaves in a hierarchy. The SID value for a
node is a negative random integer.
Creating Characteristic InfoObject - Hierarchy
Page 26 of 150
Time-Dependent Hierarchy Structure

You determine here whether or not the hierarchy structure (a hierarchy
node) is to be time-dependent. The hierarchy is then constructed for the
current key date or for the key date specified in the query.
Time-Dependent Hierarchy Structure for Char. 'Cost Center'
Time-Dependent Hierarchy Structure for Char. 'Cost Center'
Note:
• You cannot create hierarchies for characteristics that are
referenced to other characteristics (Reference characteristic).
• A characteristic can have more than one hierarchy.
• If a characteristic is to have hierarchies; the maximum length
(of the characteristic value) with compounding is restricted to 32
instead of 60 characters.
• Hierarchies can have a maximum of 98 levels.
Compounding
In Compounding, a field or another object is attached to an InfoObject. A
compounding characteristic is when the object’s definition is incomplete
without the definition of another characteristic. In other words the meaning
of master data depends on the source of the data.
Example:
Cost center 100 stands for sales and distribution in controlling area 1000,
and it also stands for sales in controlling area 2000. In this case, you would
define a "cost center" to "controlling area" characteristic compounding.
Page 27 of 150
Creating Characteristic InfoObject - Compounding
Note - Performance can be affected when "compounded" characteristics are

used extensively, particularly when a large number of characteristics are
included in a compounding. Compound attributes requires overhead, so you
should not use them unless it is absolutely necessary.
Some examples of compounding are:

CO. Cost center has a compound object controlling area.
MM. Storage location has a compound object plant.
A compound field is similar to a superior organizational field in SAP R/3.

2.4. Creating a Characteristic in the InfoObject Tree
1. In the initial screen of the Data Warehousing Workbench, choose the

function area Modeling InfoObjects.
2. Create/maintain an InfoArea
InfoAreas constitute the uppermost evaluation criteria in the InfoObject
and data target tree. The InfoObject tree contains InfoAreas beneath
the initial InfoObjects node. Under an InfoArea node, you can find more
InfoAreas or InfoObject catalogs. You can create an InfoArea via the
Page 28 of 150
context menu for the initial node, or using an InfoArea already in the
system.
3. Create/maintain an InfoObject Catalog with type characteristic.
InfoObject Catalogs are used to group InfoObjects together to provide

both a better overview of them and to arrange them logically according
to application-specific perspectives. An InfoObject Catalog has the type
characteristic or key figure. Under an InfoObject Catalog, there are
either characteristics/units/time characteristics or InfoObject tree key
figures. An InfoObject Catalog is created via the context menu for an
InfoArea.
4. Choose Create InfoObject via the context menu for the InfoObject
Catalog.
5. Enter a technical name (3-9 characteristics) and long description for

the characteristic (either a reference characteristic or a template
characteristic) and confirm your entries.
6. Maintain the tab pages

• General
• Business Explorer
• Master data/texts
• Hierarchy
• Attributes
• Compounding
When defining a characteristic, you need to enter at least the

description, data type and length. All other settings on the General and
other tab pages are optional.
7. Save and activate the “new” characteristic.

Activating the characteristic generates the objects in the Data Dictionary
(DDIC) that belong to it. These include the data element, domain and
master data tables for attributes/ texts/hierarchies. If attributes, texts or
hierarchies, or a combination there of are assigned to the characteristic,
this characteristic is called a Master data-carrying characteristic. A
characteristic is a SAP BW object that physically contains data in the
appropriate tables (master data and SID tables). Objects with these
properties are called data targets in SAP BW. In the same way, a
characteristic can also be an InfoProvider. Objects are called InfoProviders
in SAP BW when queries based on them can be defined/ executed.
Page 29 of 150
Figure 2.8: SID Tables
2.5. Key Figures

As we know, the key figure InfoObjects represent the business facts such as
quantity, amount, count and so on. The following tab pages are available in
the maintenance menu, with which you can define key figure InfoObjects
and change settings.
• Type/Unit
• Aggregation
• Additional Properties
2.5.1. Type/Unit
On this tab page, you determine the key figure type (amount, quantity,
number etc.), the data type (currency field / floating point number,
quantity filed/ floating point number etc.) as well as the currency /
quantity unit.
Page 30 of 150
Creating Key Figure InfoObject – Type/Unit
For the key figure types amount, quantity and number, you can choose
between the data types decimal number and floating-point number. For the
date and time key figure types, you can choose the decimal display if these
fields are to be included in the calculation. If you choose the amount or
quantity key figure type, you must assign a currency or quantity unit to this
key figure. For the key figure type amount, you can choose between a fixed
currency (EUR, for example) and a variable currency, (OCURRENCY) for
example.
For the key figure type quantity, you can choose between a fixed quantity
unit, KG for example, or a variable quantity unit, OUNIT for example.
2.5.2. Aggregation
Default BEx settings for aggregation of the key figure are done using this tab
page. This is required for the meaningful evaluation of the key figure. The
aggregation behavior determines whether or not, and in which way, the key
figure values can be summarized using the different characteristics/their
values within the evaluation.
Page 31 of 150
Creating Key Figure InfoObject – Aggregation
2.5.3. Aggregation
In this field, you specify the function (SUM/MAX/MIN) which determines the
way in which the key figure is aggregated "by default" for the same key (--
>standard aggregation behavior).
Cumulative/Non-cumulative Values
Cumulative values (revenue, for example) are key figures for which key
figure values must be posted in every time unit that is being reported on
(time period-specific values).
Non-cumulative values (warehouse stock, for example) are key figures that
are only evaluated for selected time periods (markers).
The values for the remaining periods are calculated from the value in a
marker and the non-cumulative changes (in-/out- flow) that lie in between.
2.5.4. Additional Properties

This tab page is mostly used to change default settings for the key figure
display type (number of decimal places, display scaling and so on) in BEx.
Page 32 of 150
Creating Key Figure InfoObject - Additional Properties
2.5.5. Creating a Key Figure in the InfoObject Tree

1. In the initial screen of the AWB, choose the function area Modeling
InfoObjects
2. Create/Maintain an InfoArea within the InfoObject tree
3. Create / Maintain an InfoObject Catalog with type key figure within
the InfoArea
4. Choose Create InfoObject form the context menu of the
InfoObjectCatalog
Enter the technical name (3-9 characters) and a long description for the
key figure (either a reference key figure or a template key figure) and
confirm your entry. (You need a reference characteristic for an
‘Elimination of Internal Business Volume’ in the query.)
5. Maintain the tab pages

• Type / Unit
• Aggregation
• Additional Properties
•
(If a key figure is defined with a reference, the additional tab page
Elimination also appears.)
6. Save and activate the key figure
Page 33 of 150
Activating the key figure generates corresponding DDIC objects. As

mentioned above, if a key figure is defined with a reference, the additional
tab page Elimination appears in the InfoObject maintenance. On this tab
page, one or more characteristic pairs are specified, with reference to
which the key figure can be eliminated upon execution of a BEx query. The
characteristics in the pair must have the same reference characteristic.
Instead of a characteristic you may also use a navigation attribute. A typical
example of such a pair would be “sending Cost center”(0SEND_CCTR) and
“receiving Cost center”(0RECV_CCTR).
2.6. InfoCubes
A cube : which means it consists of a fact table and a surrounding group of
dimension tables, all of which contain data that logically belong together,
and are linked relationally. Cubes are the central objects, upon which
reports and analyses are based in multidimensional modeling. InfoCubes are
the central objects of the multi-dimensional model in SAP BW. Reports and
analyses are based on these. An InfoCube describes a self-enclosed data set
for a business area from a reporting perspective. Queries can be defined
and/ or executed on the basis of an InfoCube. InfoCubes contain the
transaction data in multidimensional format. In SAP BW a cube is called an
InfoCube.
Infoprovider types:
Physical Data Stores:
• Basic Cubes
• InfoObjects (characteristics with attributes or texts)
• ODS objects that have the indicator for BEx reporting
Virtual Data Stores:

• InfoSets
• Remote Cubes
• SAP Remote Cubes
• Multi-Providers
2.7. BasisCubes
As already mentioned, a BasisCube consists of a quantity of relational tables
arranged together in a star schema.
. Fact table
A BasisCube consists of one fact table, in which key figure values are
stored. A fact table can contain a maximum of 233 key figures.
Facts and Key Figures

The star schema is based on facts and fact tables. Facts are data elements
from a fact table.
Page 34 of 150
Fact
A fact is a measure that is normally (cumulative) and answers the question
“how much?” or “how many?” A fact is referred to as a key figure in the SAP
BW extended star schema. Revenues and expenses are examples of typical
facts. Examples of non-cumulative facts include closing stock price, daily
movements, or inventory levels.
Fact Table
Facts, of course, reside in a fact table. A fact table is the central table in a
star schema. It contains key figures and dimension IDs that point to the
dimension tables. In a star schema, typically
• The fact table is very large with small dimension tables.
Dimensions and Characteristics
The dimensions and characteristics are key components of a
multidimensional model/star schema. The dimensions represent the points
in the star.
Dimension
A dimension is a textual description of the dimensions/features of the
business. The dimension answers the questions “who? what? when?” For
example, the dimensions of a product may include product name, brand
name, size, and packaging type. Dimensions are stored in dimension tables.
The term dimension refers to dimension tables, and characteristics will be
used as the content of dimension tables.
It is important to note that the SAP BW InfoCube/star schema is limited to a
minimum of 4 and a maximum of 16 dimension tables:
A BasisCube usually has four dimension tables also called Reserved

Dimension.
1. Units dimension table – This dimension exists if at least one key
figure is of type ‘amount’ or ‘quantity’. Key figures of type Unit need
to access the Unit dimension table during queries, which may cause
degradation in system performance.
2. Data package dimension table – This dimension is always present in
a BasisCube. To identify discrete packets of information loaded into
the InfoCube (this is needed to delete, reload, or maintain packets
individually)
3. Time dimension Table - This dimension is always present in a
BasisCube. Holds the time characteristics needed for analysis
4. A user-defined dimension for example material dimension table
It is important to note that the SAP BW InfoCube/star schema is limited to a

minimum of 4 and a maximum of 16 dimension tables:
• Three standard/reserved dimensions (time, packet ID, and unit)
Page 35 of 150
• At least one dimension to be defined by the SAP BW administrator

• The SAP BW system administrator can create up to 13 dimension
tables (computed by 16 – 3 reserved).
Structure of a BasisCube
Dimensions
A dimension in SAP BW is nothing but a grouping of logically related
characteristics under a single umbrella term. A maximum of 248
characteristics can be combined within a dimension.
Line Item Dimension

Characteristics can be defined as line items. In other words, aside from this
characteristic, no other characteristics can be assigned to a dimension. This
kind of dimension is called a line item dimension (degenerated dimension).
This option is used when a characteristic has a large number of values
(order number, for example), which, in combination with other
characteristics, would lead to a large increase in dimension tables for the
fact table, detrimentally affecting query performance.
Page 36 of 150
Line Item Dimension
Remote Cube
A Remote Cube is also called a Virtual Cube. It is an InfoCube whose
transaction data are not managed in SAP BW but in a remote system.
2.8. Creating an InfoCube in the InfoProvider Tree

1. In the-initial screen of the Data Warehousing Workbench, choose the
function area Modeling InfoProvider.
2. Create/maintain an InfoArea within the InfoProvider tree
3. Via the context menu (Right mouse click) for the InfoArea, choose
Create InfoCube
4. Select either Standard or Real Time as the InfoCube type.
5. Specify a technical name (3-9 characters) and a description for the
InfoCube/Template InfoCube.
6. Select Create. If you want to create a copy of an already existing
InfoCube, you can enter an InfoCube as a template. The Edit
InfoCube screen appears.
7. Transferring InfoObjects:
• The InfoObjects that are to be added to the InfoCube are divided
into the categories characteristic, time characteristic, key figure
and unit. You have to transfer at least one InfoObject from each
category.
• On the right side of the screen, you define the InfoCube. Using
the Drag&Drop function, assign the InfoObjects in the dimensions
and the Key Figures folder. It is possible to select several
InfoObjects at once. You can also transfer entire dimensions using
Drag&Drop. The system assigns navigation attributes
Page 37 of 150
automatically. These navigation attributes can be switched on for

reporting in BEx.
Figure 2.14: Characteristics for Cube

8. Create dimensions: The dimensions data package, time, and unit are
available as the default setting. The data package dimension contains
technical characteristics. Time characteristics and units are
automatically assigned to the corresponding dimensions. In the
context menu of the Dimensions folder, you can create additional
dimensions under Create New Dimensions.
Figure 2.17: Defining Dimensions for a Cube
Note: You can mark a dimension as a line item dimension. In addition, you
can also set the Card. Height indicator to indicate high cardinality. This is
used if the dimension has at least 10-20% the size of the fat table in terms
of number of records. In this case, B tree indices are created instead of
bitmap indices.
9. For better performance, partition the InfoCube using Extra

Partitioning menu.
Page 38 of 150
The number of partitions depends upon the span of time for which the
data is stored in the InfoCube and the actual volume of data. E.g. As
shown in the Figure 2.17, out of total 62 partitions, 60 partitions
correspond to months ranging from January’2001 to December’2005.
One partition is for the transaction data before January’2001 and one is
for the data after December’2005.
Figure 2.18: Partitioning a Cube

Note:
• Partitioning of the fact table is limited to 0CALMONTH or
0FISCPER.
• After partitioning, physically there will be more than one fact
table.
• Partitioning should be set up on creation of the InfoCube and
occur after data have been loaded (partitioning can occur if
data are in the InfoCube by using “Repartition” option.)
10. Save and activate the new InfoCube.
2.9. Technical Implementation of SAP BW Star Schema

As mentioned earlier, upon activation of InfoObjects and InfoCubes a
number of DDIC objects- mainly tables and views - get generated. These
DDIC objects are the way in which the SAP BW data model is realized
technically.
2.9.1. Master Data Tables

When a master data-carrying characteristic is activated, master data tables
(attributes, text, hierarchies) are generated in the characteristic
maintenance depending on the settings in the respective tab strip. In
multidimensional data modeling, master data are not part of the model.
Page 39 of 150
2.9.2. Text Table

A text table is created if the ‘With texts’ checkbox is flagged prior to the
creation and subsequent activation of the InfoObject. You can select the
following properties here: (refer to Figure 2.18)
• Short text
• Medium-length text
• Long text
• Texts are language-dependent
• Texts are time-dependent
The selection options affect the text table key. For example, in a time-
dependent and language dependent text table, the two fields LANGU
(language key) and DATETO (date valid to) belong to the text table key.
Only one text table is generated for each characteristic.
With Texts
Legend:
{...} "Compounded" characteristic
/BIC/<...> Newly-created characteristic
LANGU Language key
DATETO Date valid to
DATEFROM Date valid from
Page 40 of 150
TXTSH Short description (20 characters)

TXTMD Medium-Iength description (40 characters)
TXTLG Long text description (60 characters)
Time-dependant Texts
2.9.3. Attribute Tables

If you have not deselected the indicator in the ‘With master data’ checkbox
(the checkbox is checked by default) on the Master Data/texts tab page,
you can maintain attributes for the master data-carrying characteristics on
the Attributes tab page. You can choose to define display attributes and
navigation attributes as either time-dependent or time-independent. In this
section, we only look at display attributes in greater detail. A maximum of
two attribute tables can be generated for display attributes (time-
dependent and time-independent attributes) for each master data-carrying
characteristic.
Page 41 of 150
Attribute Tables
Example:
OBjVER attribute
2.9.4. Hierarchies
The hierarchy table (H table) is used to store the hierarchical relationships
between characteristic values, when external hierarchies are used for the
characteristic. Only one H table is ever generated even if a characteristic
contains several hierarchies. In other words, the H table contains all
hierarchies.
Page 42 of 150
With Hierarchies
Hierarchy table
SID Table, External Hierarchies

Providing that the ‘With hierarchies’ indicator was set in characteristic
maintenance, the following SID tables are always generated with the H
table.
Page 43 of 150
3 Data Transfer Process in SAP BI

3.1. Overview of Data Transfer Process
SAP Netweaver 2004s includes a new DataSource concept, changes in

InfoPackages, a new data agent called the data transfer process (DTP),
the removal of the InfoSource as a mandatory data staging layer, and the
consolidation of all data transformations into a single object called BI
transformations.
3.1.1. Definition
DTP is an object that determines how data is transferred between two
persistent objects – E.g. from Staging (PSA) layer to Enterprise Data
Warehousing Layer, or from Enterprise Data Warehousing Layer to
Architected Data Marts Layer.
3.1.2. Data flow in SAP Netweaver 2004s BI
Data flow in SAP Netweaver 2004s BI

The figure illustrates an example of a data update from the DataSource to
an InfoProvider. The data can be updated from an InfoProvider to another
InfoProvider using a data transfer process. The data transfer process can
also be used to control data distribution from a BI system into any target
outside of the BI system. For this purpose, a data transfer process with an
open hub destination is used as the target. The following are the ways of
data transfer:
Page 44 of 150
• The InfoPackage controls the transfer of data from the source to the
entry layer of BI.
• The data transfer process controls the distribution of data within BI.
• By using Infospoke BI can be used as the source system, whereby he
data can be loaded from BI to any other destination.
3.1.3. Key Benefits of DTP
• Loading data from one layer to others except Infosources

• Separation of delta mechanism for different data targets
• Enhanced filtering in dataflow
• Improved transparency of staging processes across data warehouse
layers (PSA, DWH layer, ODS layer, Architected Data Marts)
• Improves performance: optimized parallelization
• Enhanced error handling for DataStore object (error stack)
• Repair mode based on temporary data storage
3.2. Data Transfer Process – Example
Within SAP Netweaver 2004s infopackages can only load data from source
system to PSA without any semantic transformation. What can be done here
is a technical transformation (e.g. conversion exit to transform data from
external format to internal format). Transformations can be defined
between a source and a target for data transformation or conversion. DTP is
responsible for data loading from one persistent layer to the other. Every
path from persistent source to target is a DTP. This means that besides
InfoSource any other objects like InfoProviders, DataSources, DSO can be
the source or target for the DTP. Consider the following example:
2004s BI - Enhanced Data Flow Concept
Page 45 of 150
• Infopackages only can load data from Source System to PSA without
any semantic transformation
• PSA will physically store the data
• Data can be loaded from PSA to DSO via DTP
• All the infopackages and DTPs should be included in process chain for
automations.
3.3. Creating and Managing DTP
3.3.1. Creating a DTP
Creation of Data Transfer Process
• Go to RSA1 transaction (Data Warehousing Workbench)

• DTP is assigned to the target object
• Define transformation for the target object , by right clicking on the
target object and selecting ‘create transformation’ option(Add
Transformation Slide)
Page 46 of 150
Creation of Transformation
• Once transformation is defined, DTP can be defined for the target

object by right clicking on the transformation.
3.3.2. Tabs and Settings in DTP – Extraction Tab
Figure 3.3.2: Extraction tab inside DTP
Page 47 of 150
• Two types of extraction mode – Full and Delta

• For delta loading, we need to define two DTPs – one full and one
delta – to load data from source to target
• The filter function makes it possible to load a set of data to the data
target instead of the complete volume of data
• Different data selections can be made via different DTPs for the
same or for different data targets
• We can define the package size, whether the currency conversion
should be switched on or whether it is possible to load the data from
the change log of the DSO
3.3.3. Tabs and Settings in DTP – Update Tab
Update tab inside DTP

In update tab we can decide the type of error handling. There are 3 types:
• ‘No Update, No Reporting’ – Once errors occur, the whole data
package is terminated. The request is not released for reporting
• ‘Valid Records Update, No Reporting (Request Red)’ – Valid records
are only updated but data is available for reporting only after
manual processing of the request
• ‘Valid Records Update, Reporting Possible (Request Green)’ – Valid
records are updated and also available for reporting
Page 48 of 150
3.3.4. Tabs and Settings in DTP – Execute Tab
Figure 3.3.4: Execute tab inside DTP
• Within the execute tab we can see all the process steps during the
data loading
• Process step filters out records with the same key
• It means if error handling is switched on and there are infoobjects
which have the update mode ‘overwrite’ in the transformation, new
records with the same key at the incorrect records will be filtered
out during data loading
3.4. Error Handling of DTP
3.4.1. Error Handling Overview
The following flowchart illustrates how error handling works with the DTP.
We have the option in the Update tab of DTP where we can choose whether
error handling feature should be switched on or not.
Flowchart for error handling
Page 49 of 150
3.5. Error Stack in DTP
The following are some features of Error Stack:

• Stores erroneous records
• Keeps the right sequence of records – for consistent DataStore
handling
• Key of error stack defines which data should be detained from the
update after the erroneous data record
• After correction, Error DTP updates data from error stack to data
target
• Once the request in the source object is deleted, the related data
records in error stack are automatically deleted
3.6. DTP Monitor
3.6.1. Monitor Screen of DTP
Monitor Tab of DTP
• This is integrated in InfoProvider management screen and integrated

in DTP maintenance
• Additional information: duration of each step
• Temporary storage access – if activated
• Error stack is displayed in DTP Monitor
Page 50 of 150
4) Creating Error DTP from the update tab of standard DTP.
5) Once Error DTP gets created, we can check the status of Standard DTP
which is changed from create to display, and can also check the Error DTP
under the Object for which we created the standard DTP.
Page 51 of 150
6) Error DTP
7) Schedule the Error DTP from Execute tab.
Page 52 of 150
8) In the Error DTP process monitor it’s showing 3 records that we corrected
in Error Stack in earlier steps.
9) We can also check the status of Standard DTP, it’s also Green now
(without errors).
Page 53 of 150
10) We can also check the records updated status of Standard and Error DTP
in the manage tab of data target.
3.7. Managing InfoCubes-Data Maintenance

You can use the Manage function to display the content of the fact table or
concrete characteristic values (from a view of the table provided by the
data browser). You can also repair and reconstruct indexes, delete
erroneously loaded requests, roll up requests in the aggregates, compress
the content of the fact tab1e, and reload requests that were deleted from
the BasicCube. Select the BasicCube to be managed and from the context
menu, choose Manage. Six tab pages appear:
• Contents
• Performance
• Requests
• Rollup
• Collapse
• Reconstruct
The graphic displays the initial screen for InfoCube Management, including
the tab pages mentioned above.
3.7.1. Maintaining InfoCube Data

As shown in the Figure 4.22, from the Data Warehousing Workbench, right
click the concerned InfoCube, and then select Manage.
Figure 3.22: Manage InfoCube

3.7.2. Contents
This tab page lists all characteristics involved in the BasicCube for the
associated dimensions. Via InfoCube Content, you can display the key figure
values for the BasicCube, as well as the characteristics, SIDs for the
Page 54 of 150
characteristics and key figures of the Cube via a view. Fact Table can be
used to display a list of all dimension keys and key figures for the individual
transaction data records (the fact table content).
Via Selection, you can use a pre-selection to delete the data records
matching these selection criteria from the BasicCube. If you select the cost
center having cost center number T900000004250, all data records with this
value are deleted from the BasicCube.
Figure 3.23: Manage InfoCube: Contents

3.7.3. Performance
This tab page allows you to influence load and query performance using the
Delete Indexes, Repair Indexes and Create Index (Batch) functions.
Page 55 of 150
Manage InfoCube: Performance

To improve data loading performance, it is recommended that you
delete the indexes, load the data, and the recreate the indexes. To
automate this job, click Create Index button
Figure 3.28: Delete Indexes

Check all the options and click Execute Changes button. Pl note that the
next time when you load data into this InfoCube, you will receive a
message, just click Yes button
• Rolling up aggregates will automatically repair the aggregate indexes
• In the same way, we can check, delete, and create statistics.
• If the DB Statistics status is red, click Refresh statistics
• To automate this process, click Create Statistics
3.7.4. Requests
All requests (data requests) that were loaded into the BasicCube are
displayed on this tab page. In BW, each data load from BW Scheduler is
considered as a request and is assigned a unique request number consisting
Page 56 of 150
of 30 characters and is stored as an integer value called a request id, in the

data packet dimension of the InfoCube.
On the Request tab page, you can see the status (red, yellow, green) of
previous data load processes. The following table shows the values of the
request ID status:
Manage InfoCube: Requests
Table 3.8: Request Id QM Status

Each request has its own unique number (request ID). You can see this in
the following graphic. By using a request ID (a unique key generated by the
system) to indicate each request, the system can maintain a chronological
update history. It allows the system administrator to identify specific
upload sequences that had errors.
BW provides a useful function that allows us to check whether one data load
request overlaps with another. For that select request 31501 and then click
Page 57 of 150
Manage InfoCube: Check Requests
Click to check the overlapping. The result contains information about

the overlapping. If overlapping is present, the result also tells us whether
we can delete the request.
3.7.5. Rollup
If activated and filled aggregates exist for the BasicCube and you then load
new requests into the BasicCube, you need to roll these up into the
aggregates as well.
Manage InfoCube: Rollup
Page 58 of 150
3.7.6. Compress/Collapse
As mentioned above, each data load process is uniquely identified within a
BasicCube using a request ID, which is included in the package dimension.
This allows you to look at individual requests in detail. Using request Ids can
have the effect that a data record with the same content (where all
characters are the same except for the request ID) appears more than once
in the fact table. The result is an unnecessary increase in the data volume.
The greater data volume reduces performance in Reporting, since every
time a query is executed; the system accesses data via the request ID. This
is because data records are only aggregated within a request. To save
storage, space and improve read performance, you can compress a
BasicCube, whereby the request ID is set to null. Data records with the
same dimension key are aggregated. During compression, data records are
written to the BasicCube E table and the compressed requests are removed
from the F table. Newly requested requests are written again to the F table
and can then be compressed if required (see graphic).
Compressing the InfoCube

This function comes with a disadvantage: Compressed data can no longer be
deleted from the InfoCube using request IDs. In other words, BasicCube data
can either be deleted via Selective Deletion or it can be deleted
completely.
For performance reasons, and to conserve storage space, we recommend

that you compress the BasicCube as soon as you know that the request was
loaded correctly and that no more data is to be deleted from the InfoCube.
Page 59 of 150
Figure 3.28: Manage InfoCube: Collapse

The Collapse tab page deals with the InfoCube compression. As mentioned
earlier, each InfoCube has two fact tables: the F and E fact table. We load
data into the F fact table, where the dates are grouped according to load
request. The F table allows us to check for overlapping requests and to
delete unnecessary requests. Note that F fact table is an overhead in terms
of performance and space utilization. Further, while executing a query, the
OLAP processor must aggregate key figures to eliminate the request
information in the data packet dimension.
Therefore, BW allows us to aggregate the F table and saves the aggregated

data in the E fact table and this process is called InfoCube Compression.
Upon compression, request id is set to zero and hence not available.
For instance, we want to compress request 31839, enter 31839 into the
Request ID and then click . BW will compress 31839and
request below 31839. However, to delete records whose key figures are all
0, select the With Zero Elimination.
On order to delete a compressed request, we must either delete all off the
E Fact table data or use the Request reverse posting (Read everything in
manually) function in the Monitor-Administrator Workbench.
Page 60 of 150
3.7.7. Reconstruct
You can use this function to reconstruct requests that were already rolled
up into a BasicCube and that have since been deleted (update requests into
the BasicCube).
This function can only be used when the data is held in the PSA.
The system transfers the data after you confirm your entries. By default,
the data is returned as a display list.
Figure 3.30: Manage InfoCube: Reconstruct

3.8. Using BW Monitor
BW Monitor enables us to trouble shoot during the load process. Simply put,
you may use BW Monitor to display the status of data loads and find out
when, where, and how errors (if any) occurred.
• Select the InfoCube, and then click .
Page 61 of 150
Figure 3.31: Monitor Button
• Click to continue. Leave Date Selection blank, as we want to

list the status of all data loads.
Figure 3.32: Date Selection
• We see the status of all data load (successful and failed). Double
click on the last failed load operation to get the details.
Figure 3.33: Monitor: Status
• Click under Status tab to display the error. The

message box is displayed.
Page 62 of 150
Error Messages
• Under the Details tab page, we can see how the data flowed and
where the errors have occurred.
Monitor: Details
To review the status of other data loads, we can click New Selection (F5)
button .
Monitor: New Selection
Page 63 of 150
4 Data Store Objects (DSO)

The ODS object played an important role in the former version of BI
warehouse management. This has been succeeded by the compatible but
superior object type “Data Store Object” in SAP NW 2004s.
Data Store Object offers certain performance improvements as well as
enhanced capabilities in analysis.
Enhanced capabilities at one glance:
Full compatibility to the former ODS Object – No migration needed
DSOs can be used in analysis – Regardless of settings and type
New Data Store Object Type – Write – optimized
Transactional ODS is now called as ‘Data Store Object for Direct
Update’.
Various Types of the Data Store Objects

1. Standard
2. Direct Update
3. Write-Optimized
4.1. Data Store Object definition:

New Data Store Object Settings:
Data Store Object Type: Can only be set/changed if there is no data
in the DSO.
New DataStore Object Settings
Page 64 of 150
4.2. Data Store Object Types
4.2.1. Data Store Object Types Overview:

Data Store Primary Usage Table Structure Integration
Object into
Type EDW ODS Delta Fast Others Activation Active Change Dataflow
Layer Layer Capability Access(No Queue Data Log
Activation)
Standard X X Delta X X X Via
determination Staging(DTP)
from after
images on
record level
Write- X On request X Staging Layer, X Via
Optimized level especially for Staging(DTP)
large sets of
data with
unique key
Direct No delta X For external X Via APIs,
Update capability applications staging into
and analysis subsequent
processes(APD) targets
possible
4.2.2. Standard Data Store Object:
Figure 5.2.2: Standard DataStore Object
Page 65 of 150
1) SIDs Generation upon Activation

Improves Query performance
Queries are also possible if SID values are not generated
2) Unique Data Records
Available only if ‘SIDs Generation upon Activation’ is set.
Activation Process is optimized.
3) For non-reporting scenarios write – optimized DSOs are recommended
than standard DSOs
4) Enhanced Activation Process:
5) Structure (Tables):
Structure of the Standard Data Store Object is similar to that of the
standard ODS in BW3.5
Contains -
1. Activation Queue
2. Active Data
3. Change Log
Activation Queue:
Used to store the data to be updated in the Data Store

Object which has not been activated.
After activation data is deleted from this table
Technical Keys Of Activation Queue
Page 66 of 150
Active Data Table:

When the request is activated data moves from Activation
Queue to this table.
Change Log:
Change history for delta mechanism from the Data Store

Object into other infoprovider.
Figure: Structure of DSO

The Activation Process features the following:
Single scan on the Activation Queue for all parallel activation
processes
Packages are stored in cluster – No scan necessary at the restart
Activation Queue contains Request SID (instead of GUID) – no join
with request SID necessary
Package fetch instead of single select
4.2.3. Write-optimized Data Store Object:
Figure 5.2.3: Settings Of Write –optimized DSO
Page 67 of 150
1. Definition:
The Data is stored simply in one version

Only one table exists – Active Data Table with key and data fields of
its definition
Active Data Table is partitioned according to the Request ID.
There is no change log table - delta capabilities are not needed
o To access most recent data use a date field in the Data Store
Object definition
3. On Data Warehousing Workbench:
This icon indicates that

this is Write-Optimized
DSO
4.2.4. Data Store Object for the Direct Update:
Settings Of DSO for Direct Update
1. Definition:
- The Data is stored simply in one version

- Only one table exists – Active Data Table with key and data fields of
its definition
Page 68 of 150
- This type of the Data Store Object can be used for analysis processes
e.g. with the Analysis Process Designer (APD)
3. On Data Warehousing Workbench:
This icon indicates that

4.3. Data Store Object Administration this is DSO for Direct
Update
4.3.1. Overview
Figure 5.3: New Monitor Concept in DSO
There is new monitor concept installed for the Data Store Object
administration:
Load monitor like 3.X Monitor
Logs for DSO- request processing
Frames like ‘Contents’ and ‘Reconstruction’ are same as that of earlier

version.
a) Load Monitor:
Monitor view is divided into two frames

Header view and
Details view
Header View: Displays all relevant objects which do depend to the transfer
process.
Page 69 of 150
Figure 5.3: Header View
Details View: Displays all the relevant steps with timestamp of the transfer
process.
Figure 5.3: Details View
Page 70 of 150
b) Logs for DSO – Request Processing:
Figure 5.3: Logs for DSO
1. This log information can also be viewed via transaction

RSODSO_SHOWLOG
Parameters Required:
Request ID
Name of the Data Store Object
Page 71 of 150
Figure 5.3: Transaction RSODSO_SHOWLOG

2. Different entry points are possible via transaction:
Activation of Data
Loading Data
Delete Data
Rollback of Data
All operations
3. All operations are also displayed when clicking on the icon within the
DSO administration Manage
View.
4. For each operation there is detailed information.
Page 72 of 150
5 MultiProviders
Sometimes, there are complex reporting demands for which you need to
combine data from several InfoCubes. These complex requests are carried
out using a MultiProvider. MultiProviders enable us to combine any
InfoProviders you choose in order to build a new semantic layer for
reporting, with having to change the data store.
An InfoProvider is an object using which queries can be defined and

evaluated. InfoProviders are the objects / views relevant to reporting. For
this reason it does not matter if these objects contain data or not.
InfoProviders can be:
• InfoCubes (BasisCubes, virtual cubes)
• ODS objects
• InfoSets
• MultiProviders
According to the above definition, data targets are also always InfoProviders
(but not vice versa).
A MultiProvider is a special InfoProvider that combines data from several

InfoProviders, providing it for reporting. The MultiProvider itself does not
contain new data. Its data comes exclusively from the InfoProviders on
which it is based. A MultiProvider can be made up of various combinations
of the following InfoProviders:
• InfoCube
• ODS object
• InfoObject
• InfoSet
Figure: MultiProvider Concept
Page 73 of 150
5.1. Advantages of MultiProvider

• This concept provides you with advanced analysis options, without you
having to fill new and extremely large InfoCubes with data. You can
construct simpler BasisCubes with smaller tables and with less
redundancy.
• The individual BasisCubes and ODS objects can be individually
partitioned.
MultiCube only exists as long as a logical definition. The data is still stored
in the InfoProviders on which they are based.
In a MultiProvider, each characteristic of the MultiProvider must match
precisely one characteristic or navigation attribute in each InfoProvider
involved.
5.2. MultiProvider, Application Example

Three BasisCubes are available. The first BasisCube contains customer order
data, the second contains delivery data and the third billing data. The three
BasisCubes have the following common characteristics: ONUM(order
number), CUS (customer) and PROD (product).
Sales Order Delivery Billing

•ONUM : Order Number (C) • ONUM : Order Number (C) • ONUM : Order Number (C)
•CUS : Customer (C) • CUS : Customer (C) • CUS : Customer (C)
• PROD : Product (c) • PROD : Product (c) • PROD : Product (c)
•OOAT : Order Date (C) •DDAT : Delivery Date (C) •BDAT : Billing Date (C)
•SALP : Sales Person (C) •DELP : Delivery Person (C) •BILP : Billing Person (C)
•OQTY : Order Quantity (K) •DQTY : Delivered Quantity (K) •BQTY : Billing Quantity (K)
•OPRI : Order Price (K) •DPRI : Delivery Price (K) •DPRI : Delivery Price (K)
Figure 6.2: Basic Cubes
You can now define a MultiProvider that includes these common

characteristics as well as the key figures of the BasisCubes involved. The
MultiProvider can now be used in queries.
Page 74 of 150
Sales Process
• ONUM : Order Number (C)
• CUS : Customer (C)
• PROD : Product (C)
• OQTY : Order Quantity (K)
• OPRI : Order Price (K)
• DQTY : Delivered Quantity (K)
• DPRI : Delivery Price (K)
• BQTY : Billing Quantity (K)
• BPRI : Billing Price (K)
Sales Order Delivery Billing

•ONUM : Order Number (C) • ONUM : Order Number (C) • ONUM : Order Number (C)
•CUS : Customer (C) • CUS : Customer (C) • CUS : Customer (C)
•PROD: Product (C) • PROD: Product (C) • PROD: Product (C)
•OOAT : Order Date (C) •DDAT : Delivery Date (C) •BDAT : Billing Date (C)
•SALP : Sales Person (C) •DELP : Delivery Person (C) •BILP : Billing Person (C)
•OQTY : Order Quantity (K) •DQTY : Delivered Quantity (K) •BQTY : Billing Quantity (K)
•OPRI : Order Price (K) •DPRI : Delivery Price (K) •DPRI : Delivery Price (K)
Figure 6.3: MultiProvider

A query executed using a MultiProvider is divided up across the involved
InfoCubes using several select statements, which can be processed in
parallel. This gives you further improvement in system performance. The
OLAP processor presents the combination of the results from the individual
select statements as the query result.
In case where a characteristic does not have a corresponding characteristic

in a particular BasisCube, the data is presented in the query with the
characteristic value Not Assigned.
Page 75 of 150
MultiProvider Queries
MultiCube
Sales Process
Info Cube Info Cube

Sales Order Billing
Info Cube
Delivery
Figure : MultiProvider Queries
A key figure contained in a MultiProvider must be selected from at least one

of the InfoProviders involved. Generally, the key figure is supplied from
precisely one InfoProvider. However, there are some situations in which it
makes sense to select from more than one InfoProvider.
5.3. Creating a MultiProvider
1. In the context menu for your InfoArea, right Click and choose Create
MultiProvider…
Figure 6.5: Create MultiProvider…
2. The following screen is displayed: Give the name of the MultiProvider,

Short Description and InfoArea Name, and then click on
Page 76 of 150
Figure : Edit MultiProvider

In the subsequent window, you can select the objects involved in the MultiProvider
viz., InfoCubes/ODS Objects…tab page and the click
Figure 6.7: Select Relevant InfoProviders
3. Use Drag&Drop to transfer the required InfoObjects into MultiProvider.

Entire Dimension of cube can be transfer into multiprovider.
Page 77 of 150
Figure : Edit MultiProvider: Characteristics
4. You use Identify Characteristics and Select Key Figures to make

InfoObject assignments between MultiProviders and InfoProviders.
Page 78 of 150
Figure 6.9: Identification of Characteristics involved
5. Check, save and activate, your MultiProvider.
Page 79 of 150
6 Aggregates
An aggregate is a materialized, aggregated view of BasicCube data. In an
aggregate, the dataset for a BasicCube is stored redundantly and
persistently in summarized for on the database. Like database indexes,
aggregates also improve system performance without the need for end-user
intervention or end-users having to know how to perform this procedure,
Aggregates can be created for the following:
• Characteristics
• Attributes
• Hierarchies
6.1. Using Aggregates

The large quantity of data records in the fact table leads to poor query
response time. By using the aggregates, the data volume is reduced for each
query access, because the data is stored in a compressed form. This
increases the reading performance for queries. Within the aggregate, data
can be summarized by time, by characteristics, or by the available
hierarchies.
6.1.1. Properties at Aggregates
Technical properties, such as content and status properties, belong to the
properties of aggregates. This information is stored in the RSDDAGGRDIR
table.
Figure : Request before Rolling Up
Page 80 of 150
In the above figure, the first request with number 41239 was not rolled up
into the aggregate and is also Request is available for reporting is also not
clicked, hence is not available for reporting. In the RSDDAGGRDIR table, a
read pointer is set to request 40424 in the RNSID_TO field. This read pointer
refers to the OLAP processor, which request is available for reporting during
the query execution.
After the roll-up of request 41239, you see that the reporting request is
available, and the read pointer in the RSDDAGGRDIR table is set to request
41239.
Figure: Request after Rolling Up

Steps to follow for Roll-Up:
1. A new request is written into the BasisCube leads to a new RNSID in
the fact table.
2. Roll-up the new request into the aggregate
3. During the roll-up, the read pointer is set to the new request. This
new request is now available for reporting.
6.1.2. Compression of Aggregates
You can automatically compress aggregates during the roll-up. This causes
the request(s) to be written into the E fact table of the aggregate cube
during the roll-up. This removes the request ID. By doing so, a compression
can be executed across all the requests. Data records with the same
characteristic value are aggregated. If a request has to be deleted after the
compression then all aggregates have to be deactivated first. This can take
a long time. If you compress the aggregates first when the InfoCube is also
Page 81 of 150
compressed, then it is possible to delete a rolled-up but not yet compressed

request without taking up a great amount of time.
If characteristic data have been changed, we must activate the change
before BEx Analyzer can display the new data. To change the data entry,
Activate master data
There are two ways of activating master data. Choose Modeling-
>InfoObject->Your InfoArea->Your Characteristics (MaterialC). Right click
choose Activate master data, as shown in the figure.
Figure 6.5: Activate Master Data
The second way Apply Hierarchy/Attribute Change not only allows us to

activate master data but may also be applied for hierarchy changes.
Further, if the attribute you changed happens to be an aggregate.
Steps to follow:
Select Apply Hierarchy/Attribute Change… on the tools menu (either from
InfoObjects or InfoProvider tree.
Page 82 of 150
Figure 6.6: Apply Hierarchy/Attribute Change
Figure 6.7: Execute Hierarchy/Attribute Changes: InfoObject List
Page 83 of 150
In the above screen, you can schedule the activation by clicking

to execute in background mode or schedule for
immediate execution by selecting . To list changed
characteristic choose . The next dialog box is displayed
which shows list of changed characteristics.
Figure . Choose InfoObject from the List
You cannot delete master data if they are used by other BW objects. The
SID table /BIC/SMATERIALC contents are shown in the next screen. The X in
column DATAFL indicates that an InfoCube uses the corresponding entry,
and the X in column INCFL indicates that a hierarchy uses the entry.
Figure 6.9: DATAFL field from the S Table
Page 84 of 150
7 Admin Cockpit
Your organization works productively with BW. You want to get an overview
of how the system is used, the volume of data and the resources consumed.
You also need constant updates on how the system response time changes
over time.
8 Process Chains
8.1. Overview of Process Chains
8.1.1. Definition
A process chain is a sequence of processes that wait in the background for
an event. Some of these processes trigger a separate event that can start
other processes in turn.
8.1.2. Uses
In an operating BW system there are a multitude of processes in addition to
the loading process that occur regularly.
Process chains help us to
• Automate the complex schedules in BW with the help of the event-

controlled processing,
• Visualize the schedule by using network applications, and
• Centrally control and monitor the processes.
8.1.3. Data Load Cycle
Figure : Typical Data Load Cycle for Process Chain
Page 85 of 150
8.1.4. Types of Process Chains

• Local Chain: This is the simple process chain.
• Meta Chain: This is the main chain which contains one or more local
chains
• Remote Chain: This is the process chain which is in some other
system than in BW
8.2. Structure of Process Chains

A process chain consists of a start process, individual application processes
and the so-called collection processes.
The start of the process chain is defined with the start process. All other
chain processes are scheduled to wait for an event.
The application processes are the actual processes. BW supports process
types of the following categories:
• Load process and post processing processes

• Data target administration processes,
• Other BW processes
• ABAP Program
We also have the option to include process chains as processes themselves

in another process chain. In doing so, we need to determine whether we are
dealing with a local process chain or a remote process chain. A local
process chain comes from processes that are scheduled in the BW system
itself. It is scheduled as a process in the same BW system. A remote process
chain calls a process chain that needs to be run by using a destination in
another system. After terminating the process chain in another system, this
is confirmed in the BW system and terminates the remote process chain
there.
We can access the process maintenance screen via transaction RSPC. It

enables:
• Easy creation of process chains via drag & drop

• Creation of items
Page 86 of 150
Figure 8.2: Transaction RSPC – Process Chain Maintenance
8.2.1. Application processes
• Application processes represent BW activities that are typically

performed as part of BW operations. Examples include:
Data Load
HACR
Aggregate Rollup
Reporting Agent Settings
• Other special types of application processes are:
Start Variant – a process that exists to trigger process chain
execution (It is part of every process chain)
ABAP program
Another process chain
Remote process chain
Operating system command
Customer built processes
Page 87 of 150
8.2.2. Start Variant
Figure : Start variant configuration
• The start variant can be used by just one process chain

• Start variant helps in specifying the condition for the start of the
process chain
Page 88 of 150
9 Generic R/3 Data Extraction

In this chapter we will see how to use generic R/3 data extraction
capability. Generic R/3 data extraction allows us to extract virtually any
R/3 data. In other words, Generic data extraction is a function in Business
Content that supports the creation of DataSources based on DB tables,
views or InfoSet queries.
In this chapter we will discuss how to load the appropriate R/3 data into the
new material characteristic ZMATERIAL. Its master data will be extracted
from MARA.
FieldsData Type Length Decimal Short Text

Places
MANDT CLNT 3 0 Client
MATNR CHAR 18 0 Material Number
MTART CHAR 4 0 Material Type
MATKL CHAR 9 0 Material Group
Table 9.1: MARA fields for ZMATERIAL Master Data
FieldsData Type Length Decimal Short Text

Places
MANDT CLNT 3 0 Client
SPRAS LANG 1 0 Language Key
MATNR CHAR 18 0 Material Number
MAKTX CHAR 40 0 Material Description
Table 9.2: MARA fields for ZMATERIAL Text
9.1. Creating Views in R/3

First we need to create two views: ZMARA_ATTR Master data and
ZMARA_TEXT for texts.
To create a view for the master data, run the transaction SE11, enter a
name for the object, select the views option in the Dictionary objects
block, and then click .
Page 89 of 150
Figure 9.1: ABAP Dictionary: Initial Screen
Select the Database view option and then click .
Figure 9.2: Choose View Type
The view consists of one table MARA. Enter this name in Table/Join
Conditions tab page and in view fields, enter all the fields of table 8.1.
Page 90 of 150
Figure 9.3: Maintain View
Then save, check and activate the view.
Similarly, you create ZMARA_TEXT. Refer to table 8.2 for fields.
To link the text with the master data, the field MATNR of the table MARA
must be equal to the field MATNR of the table MAKT.
9.2. Creating DataSource in R/3.
Run transaction SBIW and click Maintain Generic DataSource, or you may
run transaction RSO2.
Page 91 of 150
Figure 9.4: Maintain Generic DataSource
You select in the above screen. The next screen

is displayed
Figure 9.5: Create DataSource
Page 92 of 150
You enter a name ZMARA_ATTR as the name of the DataSource and then
click . The next screen is displayed. Enter all the details in this
screen.
Figure 9.6: Save DataSource
Save the DataSource ZMARA_ATTR as local object. On saving a new

window is displayed, check Material Number and click the DataSource.
Page 93 of 150
Figure 9.7: DataSource: Edit
Note: To test extract, go to menu DataSource->Start Extraction (F8) or click

on . After extraction to see the output list again go to menu DataSource-
>Output list or click .
Similarly, you create ZMARA_TEXT DataSource.
Once you have created ZMARA_ATTR and ZMARA_TEXT DataSources, the

next step is to replicate these DataSources in the SAP-BW, so that identical
structures of the DataSources are created in BW system.
Next step is to logon to SAP-BW system. Go to Modeling->Source System and

right click D47 Client 107 and select Replicate DataSources. As in the figure
Page 94 of 150
Figure 9.8: Replicate DataSources
Upon Replicating DataSources, double click on P08 Client 107 another

window is displayed as shown in the figure.
Figure 9.9: DataSource is replicated
Now you need to create a characteristic ZMARA. Table 9.3 shows the
attributes of the characteristic ZMARA.
Page 95 of 150
Characteristic Attribute Compounding

ZMARA
MTART
MATKL
Table 9.3 Characteristic ZMARA Master Data
Note that the replication of DataSources from the source system SEND001
has already determined the client from which to extract.
9.3. Loading Data from R/3 into BW
To load the Master data and text follow the same steps discussed in the
earlier chapter. However, you need to assign DataSource(s) ZMARA_ATTR
for characteristic ZMARA and for texts choose ZMARA_TEXT.
Page 96 of 150
10 Logistics Cockpit
10.1. What is Logistic Cockpit (LC)?
The Logistics Customizing Cockpit is the central administration tool for

extract structures. You use it to transfer Logistics transaction data from the
OLTP system into the BW system. The extract structures are filled by the
R/3 communication structures of the individual Logistics applications. It’s a
new technique to extract logistics information and consists of a series of a
standard extract structures (that is, from a more BW perspective, standard
datasources), delivered in the business content
For extracting logistic transactional data from R/3, a new generation of

datasources and extractors, no longer based on LIS (Logistic Information
System) information structures, was developed starting from BW Release
2.0B and PI 2000.1 or PI-A 2000.1 (valid from R/3-Release 4.0B ).
The tools for the logistics extract structures can be found in the IMG for BW
(transaction SBIW (see Fig.1. below)): access into your OLTP system, choose
Customer-Defined DataSources -> Logistics -> Managing Extract Structures.
The Cockpit contains the following functions:

• Maintaining extract structures
• Maintaining DataSources
• Activating updates
• Controlling updates
Page 97 of 150
10.2. Logistic Cockpit Functions
Fig.1: SBIW
With the LC, several data structures are delivered and, for each level of
detail, there exists an extract structure as well as a datasource (that
already represents a BW extract view).
When you create and save a sales order (as other transactional tasks),
the document is processed in the memory and then stored into
application (and database) tables. In LC extraction technique (see Fig.2)
we have at our disposal different LIS communications structures (like the
MCVBAK, MCVAP, MCVEP and so on for sales orders) that we can decide
to use for our reporting purposes when the application is running and
during memory processing.
Fig.2: LC Delta Process for Sales Order Schedule Lines
Page 98 of 150
2LIS_11_VASCL is the standard LC datasource to extract order schedule

lines related information. MC11VA0SCL represents its linked extract
structure. Remember that it’s possible to enhance that, but you can’t
create new extract structures (on the same standard datasource). Within
LC (LBWE) (see Fig.3) a tool is provided that enables you to add fields
from the LIS communication structures (to the extract structure) without
having to do any modifications.
Fig.3: Logistic Cockpit customizing screen
In the maintenance screen (see Fig.4), on the left side, you see what has
already been selected in the standard extract structure and on the right
side, you see all the available fields of the communication structures
where you can select fields from for the update.
Page 99 of 150
Fig.4: Maintenance screen
It’s enough to highlight the row and click on the left-arrow: (every)
selected field is included automatically in a generated append structure
for the corresponding include structure of the extract structure When
you successfully complete this step, the traffic light icon turns red. This
indicates that you changed the structure.
At this point, you have to generate the datasource (see Fig.6): here you
can (among the other things) choose fields that can be selected .For
various reasons, it is not possible to offer all the fields contained in the
LIS communication structure for selection in the extract structure; these
fields are hidden It is also possible that a key figure is inverted (refer to
OSS Note 382779 ‘Cancellation field in the datasource maintenance’ for
details).
After maintenance in this step, the traffic light turns yellow.
Page 100 of 150

Fig.5: Datasource generation
Once you activate the update, data is written to the extract structure
and the traffic light then turns green. Our enhancement process is
completed and now you can schedule (if required by your delta method)
the delta job control process. I.e. select the job control process given
below and schedule the job providing the start date and print parameters
at the required frequency (see Fig.6)
In fact, scheduling timing process is very important and it should be

based on the basis of
1) The amount of activities on a particular OLTP system and on

E.g. A development system with a relatively low/medium of
new/modified/deleted documents may only need to run the V3 update
(explained later) on a weekly/daily basis. Instead, a full production
environment, with really many thousands of transactions everyday, may
have to be updated hourly; otherwise postings will queue and can affect
performance heavily.
2) The particular requirements related to the updating needs of data

displayed in BW reports.
e.g. If the reporting timing refers to a monthly periodic view,

successfully monthly scheduling the V3 update will ensure that all the
necessary information structures are properly updated when new or
existing documents are processed in the meanwhile.
Page 101 of 150

Finally, the right choice will be the result of all these considerations; by
doing so, the information structures in BW will be current and overall
performance will be improved.
Fig.6: Scheduling the control job
One the job gets scheduled the records get pulled into the delta queue
(RSA7) in the OLTP system. This will be the source for delta requests
emerging from the corresponding BW system.
Fig.7: Delta Queue
Page 102 of 150

11 Reporting and Analysis

11.1.SAP BW Business Explorer
The Business Explorer (BEx) is a SAP BW component that provides flexible
reporting and analysis tools that you can use for strategic analysis and
supporting the decision-making process in your organization. These tools
include querying, reporting and OLAP functions. The BEx enables a broad
range of users to access SAP BW information: Using the Enterprise Portal,
Intranet/Internet {Web Application Design) or using mobile end devices WAP
or I-mode enabled mobile telephones, and personal digital assistants).
The following is an overview of BEx functional areas:
Figure 9.1: BEx Functional Areas
11.1.1. Query, Reporting, and Analysis

The data basis of SAP BW is divided into self-contained business data targets
(InfoProviders). You analyze the data basis of SAP BW by defining queries
for data targets in the BEx Query Designer. You can determine the way in
which the data from your chosen data target is analyzed by selecting and
combining characteristics and key figures or reusable structures in a query.
11.1.2. Web Application Designer
Web Application Design allows you to implement generic OLAP navigation in
Web applications and in Business Intelligence cockpits for both simple and
highly individual scenarios. These scenarios can be created using customer-
defined interface elements using standard markup languages and Web
design APIs. Web Application Design encompasses a wide spectrum of
interactive Web-based Business Intelligence scenarios that you can modify
to suit your requirements using standard Web technology.
You can use the BEx Web Application Designer, the desktop application for
creating Web applications, to generate HTML pages that contain SAP BW
specific content such as various tables, charts or maps. You can have the
Web applications as URLs and access them from the Internet, Intranet, or
Page 103 of 150

mobile devices. You can also save Web applications as iViews and integrate
them into an Enterprise Portal.
An assistant, the Web application wizard, has been integrated into the Web
Application Designer to support you when creating Web applications. It uses
an automatic step-by-step procedure and a simplified design process.
11.2.Working with BEx

Using the SAP BW reporting functions, you can evaluate a dataset from an
InfoProvider according to various characteristics and key figures. To do this,
you define a query for your chosen InfoProvider in the BEx Query Designer.
You have various options for calling up the Query Designer:

. From the BEx Analyzer open dialog box
. As a separate program using Start Programs Business Explorer
Query Designer
. Using the Web Application Designer (see the BEx Web Application
Designer unit)
. With Crystal Reports
11.2.1. Functions of the BEx Query Designer

The following graphic gives an overview of the BEx Query Designer functions
that you can call from the Query Designer toolbar. The functions are
described within the context of query definition.
Quit and Use Query: With this function, you leave the Query Designer
and use the query you have defined.
Exit Query: Choose Exit Query if you want to leave the Query Designer.
Your entries are not saved.
Display Query on the Web: Using this function, you can display the query
in a default view on the Web, once you have saved your query definition.
New Query: Choose this function if you want to create a query. The BEx
Open dialog box appears and you can select the InfoProvider here that
contains the data that you want to evaluate in the query.
Page 104 of 150

Open Query: This function takes you directly to the BEx Open dialog box.
The, you can choose from queries in your History, Favorites, Roles, or from
the InfoAreas.
Save Query: You use this function to save a modified query under its
current name. If the query does not yet have a technical name, the system
automatically offers the function Save Query As....
Save Query As...: You use this function to save a query under a new
technical name. You can save the query in your favorites or in a role.
Delete Query: You use this function to delete the query. You can only
delete the query if it is not being used in workbooks, Web templates,
Crystal Reports, or reporting agent settings.
Exception: You use this function to define exceptions for a query.
Note: Exceptions are deviations from normal key figure values, as defined
by you, and are highlighted in color in the query view. Using the small arrow
next to the exceptions symbol, you can change or create exceptions. For
more information, see the Exceptions and Conditions unit.
Condition: You use this function to define conditions for a query.
Note: For each characteristic, you can give limit conditions to the key figure
values, in order to determine, for example, all sales revenues above or
below a specified threshold value. The chosen characteristics are displayed
in the query with restricted key figures. Using the small arrow next to the
conditions symbol, you can change or create conditions.
Define Cells: This function is only available for queries with two
structures. You can define formulas and selection conditions for cells
explicitly. In this way, you control the values of cells that appear at the
intersections of structural components. This function enables you to access
individual cells in queries or to assign special values to these.
Query Properties: Choose this function if you want to change the

description of the query or define the settings for the result position,
display options, numeric display, zero display, and key date of the query.
Page 105 of 150

Check Query: Using this function, you can check a new or saved query
for errors before you save it.
Query Where-Used List: Using this function, you can find out in which
objects (workbooks, Web templates, Crystal Reports, or reporting agent
settings) the query is used.
Display <-> Change: Using this function, you can switch between the
display and change modes.
Change Query (Global Definition): You choose this function if you are in
the Local Query Definition and want to switch to the Global Definition.
Table Display: You can create a query for tabular reporting, as well as
for Online Analytical Processing (OLAP) reporting, by activating or
deactivating the Table Display mode in the query definition when defining a
query. This function is only available for queries with one structure. You
can only have queries with two structures in the multi-dimensional display.
They are not suitable for OLAP reporting.
Technical Name: Using this function, you can show/hide the technical
names of the query components.
Context Menu: This function enables you to display the current context
menu without using the right mouse button (for example, for use with a
touch screen).
Help: This function takes you to the SAP BW online documentation. The
BEx Query Designer section is displayed automatically there in the BEx
documentation.
Using the small arrow next to the help symbol, under the About... entry,
you can see the version of the Query Designer, with the support package
number and the revision.
11.2.2. Creating a Query

To define a new query, start the Query Designer and choose New Query. In
the New Query: Select InfoProvider dialog box, select the required
InfoProvider.
Page 106 of 150

Figure : New Query: Select InfoProvider
Once you have selected the InfoProvider, the Query Designer is displayed as
shown in the following graphic.
Page 107 of 150

Figure 9.3: Query Designer : New Query
The Query Designer is divided into six sub areas:

1. Directory tree of the selected InfoProvider.
Once you have selected the required InfoProvider, all available objects
(dimensions, key figures, structures) are display in the directory tree in the
left screen area of the Query Designer.
2. Columns
You define the columns of your report in this area.
3. Rows
You define the rows of your report in this area.
4. Free Characteristics
You transfer those characteristics into the free characteristics areas that
are not displayed in the first instance when you execute the query in the
BEx Analyzer or one the Web. You can then integrate these characteristics
through navigation steps. You can also use free characteristics for selecting
filter values in the report.
Page 108 of 150

5. Filter
The characteristics displayed in the filter appear neither in the drilldown
nor as free characteristics in the query analysis. These characteristics are
only used as global filters on the cube data.
6. Preview (displayed in gray on the screen)

This area gives a preview of the query results area. To create a query, you
can expand or collapse the InfoProvider directories by clicking on the plus
or minus symbol. By expanding the key figure node in the InfoProvider tree,
for example, you can display a list of all the key figures for the
InfoProvider.
Use Drag & Drop or Choose CTRL C + CTRL V to transfer the characteristics,
key figures, and structures of the InfoProvider into the Filter, Rows,
Columns, or Free Characteristics areas of the Query Designer.
The following graphic shows the Query Designer with a query definition.
Figure 9.4: Query Definition
Once you have defined a query, choose Save Query or Save Query As... . If
you have not yet saved the query, you have to enter a query description and
a unique technical name. You can also choose where you want to save the
Page 109 of 150

query (in your roles, favorites). You can use Save Query As... to save
existing queries under a different name.
Figure 9.5: Save Query
Once you have saved the query, you have the following options:
• You can execute the query in the BEx Analyzer and include it in a
workbook. To do this, choose Quit and Use Query.
• You can display the query on the Web in a default view. To do this,
choose Display Query on the Web.
• You can use the query in the Web Application Designer as a data
provider for Web items.
11.3.BEx Analyzer
Once you choose Quit and Use Query from the Query Designer, a report is
displayed in Microsoft Excel sheet. The report contains the query
description, a filter area and the result area. The filter area contains the
characteristics and free characteristics chosen in the query definition.
Page 110 of 150

Figure 9.6: A Report in BEx Analyzer
11.3.1. Navigation within BEx Analyzer

The context menus available at various cells allow you perform operations
like Sort, Filter, Drill Down, Drill Across, and Remove Drill Down etc. that
help to analyze the data. The characteristics can be displayed as only Key,
or only Name, or both. You may use short or long descriptions for the
characteristics. The analyzer allows you to navigate back once you perform
such operations.
IF you do not want to display the values for a characteristic choose Remove
Drilldown from context menu for that characteristic in the filter area.
Drill Across option allows you to display the values of a characteristic in

columns.
11.3.2. Saving query as a workbook

You may save the generated report as a workbook using either of the
following options –
Click on the Save button and then choose Save as new workbook …
Choose the menu path, Business Explorer Save Save as new workbook…
Page 111 of 150

Workbooks are used if we require more formatting options and need to

perform complex calculations (E.g. Using VBA Micros etc).
11.3.3. Changing the query

Depending on your current position in the Query Designer or Analyzer, you
have different options for changing a query:
If you have called the Query Designer, in the SAP BEx Query: Choose Query,
select a query.
You have two options for changing the query definition from a report in the
Analyzer:
• Choose Change Query (Global Definition) : By doing this, you can change
the query definition.
• Choose Change Query (Local View): Changes made to the query here
correspond to navigation in the report and are not saved in the query
definition.
11.3.4. Filtering Data in the Query Definition

It is often necessary to restrict (filter) characteristics to specific
characteristic values in your reports. For example, if you are interested in
the sales volume of a particular branch of a world-wide corporate group,
but the InfoProvider contains the sales volume for the entire organization,
you can restrict the query definition to the relevant branch, so that only the
key figure for this branch appear in the report.
You can restrict (filter) the characteristic values of a characteristic in the

Rows, Columns, Free characteristics, and in the Filter.
There are two ways of restricting characteristics:

• By selecting a characteristic from the InfoProvider of the characteristic
(in the tree structure in the left part of the screen) and double-clicking
on the values icon, the selection menu for fixed values is displayed. You
can select single values or values from a value area. The fixed values
selected appear in the directory tree under Values. You can use Drag &
Drop to include these in your query definition.
• You can also restrict a characteristic that you have already included in
the definition. Call the context menu for the characteristic and choose
Restrict. The Selection for ... dialog box appears. The following graphic
shows the selection dialog box for the Material characteristic.
Page 112 of 150

Figure 9.7: Filtering data
A restriction on a free characteristic affects the entire query, even if the

free characteristic is not in the drilldown.
Characteristics in the global filter appear neither in the drilldown nor as
free characteristics in the analysis. You cannot navigate in the analysis
using the characteristic values in the filter. These characteristics are only
used to filter the data from the InfoProvider.
11.3.5. Including Text Elements in BEx Analyzer Reports

You have the option of displaying different text elements as additional
information in a query (for example, the author, last changed by,
InfoProvider, etc.). These text elements are referred to as the header
information of the query.
. Author: User who defined the query.
• Last Changed by: User who last changed the query definition. Navigation
steps are not recorded as changes to the definition.
• InfoProvider: InfoProvider whose data is evaluated in the query.
• Query Technical Name: Technical name that you entered when you
saved the query.
• Key Date: Contains the date for which the time-dependent master data
is selected. You create a key date either in the query definition (query
properties) or provide the value using a variable (for more information,
see the Query Properties unit). If no key date has been defined, the
system date is taken as the key date.
Page 113 of 150

• Changed At: Date and time at which the query definition was last
changed.
• Status of Data: Time at which the data from the last request was posted
to the InfoProvider. This can be evaluated for reporting.
• Current User: User who currently has the query open or who has inserted
it into a workbook.
• Last Refreshed: Data and time at which the query data was last
refreshed. This is the time at which you displayed the text elements (the
system has to refresh the query in order to display the text elements).
• Variables, Filter Values, Conditions, Exceptions: Depending on the
current query definition, additional text elements (variables, filter
values, conditions, and exceptions) may also be displayed.
11.3.6. Properties of Key Figures

The various components of a query have specific properties that reproduce
important functions. You call the properties dialog box from the context
menu for the key figure for which you want to define properties, by
selecting Properties.
In the Properties of the Selection/Form dialog box for a structure part, you
can set a range of functions.
Page 114 of 150

Figure 9.8: Properties of Key Figure
• Description: You can change the automatically determined key figure

description here (basic key figure, restricted key figure, calculated key
figure) here.
• Technical name
• Display: You can assign a unique technical name to structure parts such
as key figures. This is optional. You can choose whether the key figure is
to be highlighted in the report here. You can hide key figures that you
only need for calculating formulas, and do not want to display in the
analysis. You can also mark as selection as constant so that this selection
can no longer be changed by navigation and filter at runtime.
• Number Display: You can set the scaling factor in the Number Format
area. Caution: The scaling factor is not automatically displayed in the
report. You have to set the scaling factor display separately in the query
properties. You can define the number of decimal places here and
Page 115 of 150

reverse the +/- signs. The reverse +/- signs is only a display function. It
has no influence on calculation in formulas.
• Calculations: You can use this function to recalculate result rows and
individual values that are displayed in the version according to particular
criteria. E. g. You want to calculate the result on the basis of the
average of all displayed sales volumes instead of on the basis of total
sales volume.
• Currency Translation: In the Query Designer you can set a currency
conversion key and a target currency in the properties dialog box for a
structure part.
11.3.7. Properties of Characteristics

The various components of a query have specific properties that reproduce
important functions. You call the properties dialog box from the context
menu for the characteristic for which you want to define properties, by
selecting Properties.
In the Characteristic Properties dialog box, you can make settings for a
range of functions that affect the key figures for this characteristic in the
query drilldown.
Figure 9.9: Properties for a Characteristic
Page 116 of 150

You can define the following properties for characteristics:

• Description: The text provided in the InfoObject maintenance appears
here. You can change the text and display it in the query.
• Display As: This is where you determine the form in which the
characteristic values are displayed, as long as they were created in the
InfoObject maintenance for the characteristic:
No Display
Key and Name
Name and Key
Name
Key
Long or Medium Name
Display of Results
• Suppress Results Rows: You can structure the appearance of your report
by using this function to determine whether the results rows are
displayed Always, Never or With Only One Value.
• Normalized to: You can use this function to normalize key figure values
to a specific characteristic. When values are normalized, the key figures
are displayed as a percentage in relation to the chosen result. You can
select the Query Result, Overall Result and Result (interim result) as the
reference value. The characteristic is normalized only if it is in the
drilldown.
• Cumulative: This function aggregates the values of the characteristic

values (the nth value is aggregated with the n+1 value).
• Sorting: You can make settings for sorting within the characteristic. You
can use the following:
The characteristic itself, sorted by key or name,
All attributes of the characteristic sorted by Key or Name
The sort sequence is either Ascending or Descending. You cannot use
the attribute that you have selected for sorting in the display.
• Display Hierarchy: You can display the characteristic hierarchically. You

make the necessary settings for this here.
11.4.Restricted Key Figures

Restricted key figures are (basic) key figures of the InfoProvider that are
restricted (filtered) by one or more characteristic selections. The key figure
that is restricted by one or more characteristic selections can be a basic key
figure, a calculated key figure, or a key figure that is already restricted. By
using restricted key figures, you can focus the query result on certain
Page 117 of 150

values. Unlike a filter, whose restrictions are valid for the entire query, for
a restricted key figure, only the key figure in question is restricted to its
allocated characteristic value or characteristic value interval. Scenarios
such as comparing a particular key figure for various time segments, or
plan/actual comparison for a key figure if the plan data is stored using a
particular characteristic, can be realized using restricted key figures.
11.4.1. Defining Restricted Key Figures

You can create restricted key figures at InfoProvider level, or locally in the
query definition. Restricted key figures that are defined at InfoProvider
level are available in every query definition of the InfoProvider in question.
1. To define a restricted key figure at InfoProvider level, from the Query

Designer choose Restricted Key Figure in the context menu on the left-
hand side under Key Figure.
To define a restricted key figure at query level, use Drag &Drop to drag
the key figure to be restricted into a Query Designer directory. In the
context menu, choose Edit, or select the heading of the Rows or
Columns directory and use the secondary mouse button to choose New
Structure. Select the structure directory and use the secondary mouse
button to choose New Selection from the context menu. The New
Selection dialog box appears.
2. Enter a description of the restricted key figure into the text field.
3. If another key figure was selected, use Drag & Drop to choose the key
figure of the InfoProvider, and place it on the right-hand side of the
Selection window
4. Use Drag &Drop to move the characteristic whose characteristic value
you want to use to restrict the key figure to the right-hand side of the
Selection window.
5. From the context menu of the characteristic, choose Restrict.
6. Select the characteristic values you require for the restriction.
7. Confirm your entries by choosing OK.
8. For the definition at InfoProvider level, you enter a technical name in
the dialog box, and confirm your entry by choosing OK. The newly
defined key figure can be found in the Restricted Key Figures directory.
In the case of definition at query level, the new restricted key figure is
already part of the structure.
11.4.2. Selection Conditions for the Selection of Filter Values

When defining a restricted key figure, you want to select the restricting
characteristics, individual characteristics values, value ranges, hierarchy
nodes, or characteristic variables. When selecting value ranges, the
following operations are available:
Between
Greater than or equal to
Page 118 of 150

Less than or equal to

Greater than
Less than
The following figure shows the definition of a restricted key figure, which
will give the Sales amount only for year 2002.
Figure 9.10: Defining a Restricted Key Figure
The following is a snapshot of a report, which uses the restricted key figure
defined above to compare overall sales with the sales made in year 2002.
Page 119 of 150

Figure : A Report with a Restricted Key Figure
11.5.Calculated Key Figures

In the Query Designer, you can use a formula to calculate key figures that
are not in the InfoProvider by using basic key figures, restricted key figures,
and existing calculated key figures in the formula definition.
Defining Calculated Key Figures
You can use all basic key figures of the InfoProvider in question, as well as
the newly defined restricted and calculated key figures of the InfoProvider,
to define new calculated key figures. You can define calculated key figures
at both query level and InfoProvider level. At query level, the calculated
key figure is valid only for the query in question. If you create a calculated
key figure at InfoProvider level, you can use it in all queries that are based
on the same InfoProvider.
11.5.1. Defining Calculated Key Figures at InfoProvider Level

1. Select the Key Figure directory, and choose New Calculated Key Figure
from the context menu. You reach the New Calculated Key Figure dialog
box.
2. Enter a description of the calculated key figure into the text field.
3. Define the required formula using basic key figures, restricted key
figures, formula operators, and functions. You can use Drag & Drop to
transfer the formula components into the formula field.
Key figures always have the same units when a query is executed. This
means that the formula is semantically incorrect if you add a currency unit
(for example, EUR) to a unit of weight (for example, kg). If you want to
calculate values without using units, you should use the Value Without
Dimension function. See Data Functions.
4. Check the formula definition, and choose Formula Syntax Check.
Page 120 of 150

The Formula Syntax Check function only checks the syntax of the formula. It
does not check whether the formula is semantically sound, for example,
whether the units are compatible.
5. Choose OK. In the Properties of the Calculated Key Figure dialog box,
assign a technical name, and choose OK. If you choose Enhance, the dialog
box is enhanced with aggregation behavior or exception aggregation
options.
6. The new calculated key figure is available under Calculated Key Figure,
and can be included in the definition using Drag & Drop. To define
calculated key figures, you have to include key figures needed for the
calculation in the definition, and choose New Formula from the context
menu of the Key Figure directory. These formulas are available only locally
in the query definition.
If you are defining calculations in the columns as well as in the rows, a
formula collision can occur in the interfaces of the two formulas. You can
therefore define which of the formulas is to be used.
Figure 9.12: Defining a Calculated Key Figure
Page 121 of 150

The following snapshot of a report shows the use of the calculated key
figure defined above.
Figure 9.13: A Report with a Calculated Key Figure
11.6.Variables
For flexible reporting we often need variables. Variables are query
parameters that you define in the Query Designer and that are filled with
values only when you execute the query or Web application.
Variables act as placeholders for:

. Characteristic values
. Hierarchies
. Hierarchy nodes
. Texts
. Formula elements
Variables are reusable objects.
The variables defined in the Query Designer are available in all
InfoProviders for use in query definition. Variables are not dependent on the
InfoProvider, but rather on the InfoObject for which they were created.
Variables enable you to set queries more flexibly (query parameterization).
When using variables in the Query Designer, you do not choose fixed
characteristic values, hierarchies, hierarchy nodes, texts, or formula
elements, but rather you set variables as placeholders. These are then filled
with values at query runtime (when you insert the query into a workbook,
when you refresh a workbook or when you launch the query on the Web). If
you use variables, a query definition can then serve as the basis for many
different queries.
11.7.Exceptions
The readability of a report improves if the threshold values are shown with
different colors. This is done using Exceptions on a query level.
Page 122 of 150

The functions in exception reporting enable you to select and highlight

unusual deviations of key figure values in a query. You can see deviations
from pre-defined threshold values or intervals in the query result displayed
in different colors if the exception is active. Spotting these deviations early
provides the basis for timely and effective reactions.
11.8.Creating Exceptions
You create an exception in the Query Designer using the symbol Exception
New Exception.
Figure 91: Defining Exceptions in the Query Designer
In the dialog box that appears, you can specify a meaningful Description and
set the exception to Active. The exception is applied as soon as you execute
the query. If you do not set the active flag, you can activate the exception
in the report itself. In the BEx Analyzer, from the BW toolbar Layout Display
Exceptions you also have the option of adding an additional line between
the filter and results areas for each exception and activating or deactivating
the exception from there. There is an item for Web applications that you
can integrate into your template for the same purpose. You can use
exceptions to evaluate one or all key figures in your query definition. If you
Page 123 of 150

want to use exceptions selectively on specific key figures in your query

definition, you have to define an exception for each key figure accordingly.
11.8.1. Exception Values

On the Exception Values tab page, you enter your values by first choosing
New. An alert level row always consists of a From field, a To field and an
Alert Level field. If you leave the From or the To value empty, this gives an
infinite value definition. You choose Transfer to add your entries to the list
of threshold values.
Hint: You can proceed as follows to make entering large values with many
zeros easier:
An apostrophe after the value means multiply by a thousand, two mean
multiply by a million and three mean multiply by a billion (for example: 1.=
1,000, 1,5..= 1,500,000).
By defining variables as threshold values, you can influence defined

exceptions flexibly. You can allocate the available alert levels as you wish.
You can set the alert colors red, yellow and green, each in three shades, as
required. The colors relate to the color characteristic values of the format
templates delivered by SAP and symbolize traffic-light colors.
You can include all values or specific intervals (for example, only those
falling below the threshold value in the red area) in the threshold value
catalog. You can enter fixed point or floating-point numbers for the values
you are defining.
With key figures that exceed the threshold value and are on the border
between two intervals, the worst alert level is always shown (for example,
interval 0 to 1000 alert level 9 and 1000 5000 alert level 8, the sales volume
key figure is 1000 - alert level 9 is used as the basis for identification
Cell Restrictions
On the Cell Restrictions tag page, you can specify whether a restriction with
regard to the use of the exception applies Only to the Totals (default
setting) or to All values (therefore not a restriction).
You can choose New to define an operator for each characteristic in the
query definition, and a value for each operator. You also choose Transfer
here to add your restrictions to the list.
You have the following selection options for the operators:

. Everything: The cell context is not restricted. The exception applies for
every drilldown state of the characteristic.
Page 124 of 150

. Totals Only: The exception affects only the aggregated values of the
characteristic.
. Everything Except Totals: The exception affects all values except for the
aggregated values of the characteristic.
. Fixed Value: The exception applies only to a specific characteristic value
of the characteristic, which you can determine in the search help in the
value field. You can also use a characteristic value variable here. To do
this, select Variables Entry. You are then given the option of using or
changing an existing characteristic value variable, or of creating a new one.
. Level: The exception applies only to specific hierarchy levels of the

characteristic. You enter the required hierarchy level in the value field
here.
Note that you have to list all characteristics that you defined in the Cell
Restrictions in the drilldown of the report, since the exception takes effect
only then. If there is a characteristic in the drilldown that is not recorded in
the cell restrictions, the effect that the exception has depends on whether
you selected Totals Only or All on the Cell Restrictions tab page. If you
selected All, it does not matter where you integrate the characteristic in
the drilldown, the exception is applied accordingly. However, if you
selected Totals Only you have to place this characteristic at the end of the
drilldown, otherwise the exception does not take effect.
The following snapshot of a report shows the cells in different colors as per
the exception.
Page 125 of 150

Figure x.x : A report with an Exception applied
11.8.2. Changing and Deleting Exceptions

You can change exceptions in the Query Designer using the symbol
Exception Change Exception.
If you want to delete or changing a list entry, highlight the entry using your
cursor and choose Delete, or OK if you want to make changes.
You can change exceptions in the Query Designer using the symbol
Exception Change Exception. Use the cursor to highlight the exception that
you want to delete and choose Delete to confirm. Hint: If you execute your
report on the Web, you can create, change, activate and deactivate
exceptions using the List of Exceptions Web item. You can delete an
exception using the context menu only if you created the exception in the
Web application itself.
You can define several exceptions in a query for different value assignment
areas or for different versions. If the threshold value areas overlap when
you activate several exceptions, the worst (highest) alert level counts.
Page 126 of 150

11.9.Conditions
Sometimes it is desired to flexibly restrict a report so that only the most
important information is displayed. This should enable a more efficient
analysis of data when large amounts of data are analyzed. This is achieved
using conditions.
By defining you have the option of analyzing the query results in more
detail. You can analyze combinations of characteristics using ranked lists,
thereby displaying your ten best customers by sales revenue, for example.
By defining value limits you can display all key figure values above or below
a certain value. The data is restricted accordingly in the results area of the
query, so that you only see the area that interests you. You can define
multiple conditions for a query, and then activate or deactivate them in the
report itself to create different views of the data.
11.9.1. Defining Conditions

You can make restrictions in the Query Designer, using Condition. As a
prerequisite, you have to have created a query definition for which one or
more conditions can be defined.
In the dialog box that appears, you specify a meaningful Description and set
the condition to Active. If the condition has the status Active, it is used in
the report as soon as you execute the query. If you do not set the active
flag, you can activate the condition in the report itself. In the BEx Analyzer,
from the BW toolbar Layout Display Conditions you also have the option of
adding an additional line between the filter and results areas for each
condition and activating or deactivating the condition from there. There is
an item for Web applications that you can integrate into your template for
the same purpose.
You can set conditions for all characteristics, single characteristics and
characteristic combinations in the report drilldown, that is, in the results
area in the BEx Analyzer or in the table item.
Hint: If you restrict conditions for a report to Single Characteristic or

Combinations of Characteristics, you have to ensure that the characteristic
or the combination of characteristics is integrated into the report drilldown
for the restrictions defined to take effect.
Page 127 of 150

Figure 97: Defining a Condition
11.9.2. Features
In the area Display all values for which at least one of the following
conditions applies, you choose New to select a Key Figure for which a
condition is to be used. In the second field, you can see the operators for
specifying value definitions. You choose Transfer to add your entries to the
list of conditions and choose New to define more conditions. You save your
conditions by choosing OK and you can then display your report in the BEx
Analyzer or in the browser.
A condition row consists of a key figure, an operator, and a value for the
operator. In query definitions that contain two structures, there is an
additional field for defining a structural component.
You can use the following operators for threshold value conditions::
• Equal to - Example: Invoiced quantity equals 1000
• Not equal to - Example: Line item not equal to 5
• Less than - Example: Sales revenue less than 100,000 EUR
• Greater than - Example: Incoming orders greater than 1,000,000 EUR
• Less than or equal to - Example: Sales revenue less than or equal to
100,000 EUR
Page 128 of 150

• Greater than or equal to - Example: Incoming orders greater than or

equal to 1,000,000 EUR
• Between - Example: Sales from/to, with the option of defining these
values using a variable request
• Not Between - Example: Sales from/to excluded from display, with the
option of defining these values flexibly at runtime.
In the variable definition, select Variable Entry. You are then given the
option of choosing an existing variable from the dropdown box, changing
the variable or creating a New Variable.
You can use the following operators for ranked list functions:
. Top N - Example: Display the sales revenue of the top 5 customers
. Bottom N - Example: Display the bottom3 (lowest) incoming orders
. Top % - Example: Restriction to 20%of the best revenue, in order
. Bottom % - Example: List of 15%of the customers with the lowest sales
revenue, in order
. Top Sum - Example: You get a list of the products with the highest sales
revenues where the total sales revenue makes up 20,000 EUR. All sales
revenues are sorted in descending order and then the sum is calculated
until the threshold value of 20,000 EUR is exceeded. All products, including
the product that takes the sales volume over the 20,000 EUR mark, are
listed.
. Bottom Sum - Example: As with Top Sum but here, a ranked list is sorted
in ascending order of products with the weakest sales revenue until a sum
greater than or equal to 20,000 EUR is reached. All products, including the
product that takes the sum over the 20,000 EUR mark are also listed here.
The following figure shows a report where only Top 2 Customers according
to Sales are displayed.
Page 129 of 150

Figure x.x : A report with a condition applied.
11.9.3. Calculate
Result As to display the Summation. If you are using the browser, you can
call the context menu and then choose Properties Local Properties
Calculate Result As Summation.
11.9.4. Using Several Conditions in a Report

If you are using several conditions in one report, conflicts can arise which
lead to automatic deactivation. The following status descriptions appear in
the display:
. Variant
Reason:
The condition relates to a characteristic that is not included in the
drilldown.
The condition relates to a characteristic combination that is not included in
the drilldown.
. Not Used
Reason:
The condition relates to a characteristic that is drilled down using an active
display hierarchy.
The condition relates to a characteristic that is included through the
activation of another condition, leading to a collision, and is therefore
Page 130 of 150

deactivated (however, you can reactivate this condition and automatically

deactivate the last condition activated).
If you activate a condition for a combination of characteristics, the results

row is no longer displayed.
11.9.5. Changing and Deleting Conditions

To change existing conditions, in the Query Designer choose Condition
Change Condition. The Selection dialog box appears. Highlight the required
condition and confirm with OK. In the Define Condition dialog box, you can
add new conditions to the list, or highlight existing conditions to change or
delete them.
You can also delete conditions from the Selection dialog box by highlighting
the relevant conditions and choosing Delete to remove it from the list.
If you execute your report on the Web, you can create, change, activate
and deactivate conditions using the List of Conditions Web item. You can
delete a condition using the context menu only if you created the condition
in the Web application itself.
Page 131 of 150

12 BEx Web Application Designer
12.1.Introduction
The BEx Web Application Designer is a desktop application for creating Web
applications with BI-specific content. Using the BEx Web Application
Designer, you can create an HTML page containing BI-specific content such
as various tables, charts, or maps. This HTML page (Web application) forms
the basis of Web applications with complex interaction, as well as Web
cockpits and iViews. The command wizard and pattern wizard are integral
parts of the Web Application Designer. Using the command wizard, you can
easily generate commands from the Web Design API and include them in
your Web template. Using the pattern wizard, you can configure BI patterns
to a certain extent and tailor them to meet your needs.
12.2.Features
The initial view of the BEx Web Application Designer has four different
screen areas in addition to the menu and toolbars as depicted in the figure
below
● Web Items Screen Area (1)

● Web Template Screen Area (2)
● Errors and Warnings Screen Area (3)
● Properties Screen Area (4)
Page 132 of 150

After selecting Create a new web application , you will get a new screen
wherein you can add web items from the left of your screen to create a web
application. Let us create a simple web application having A table a Chart
and a Navigation Block.You can drag and drop these elements from under
the Standard Web Items pane into the WAD layout.
Page 133 of 150

Select on Create a new data provider and the following window will pop-up
Browse for a query you have created . We have selected a query created on
one of the BW Statistics Cube here YTBD_STATS_QUERY. And select ok.
Page 134 of 150

Select the table in your right hand pane and check the properties tab in
your left pane.. Assign the Info provider DP1 to the table. Repeat the same
process for the chart and the Navigation block.
Save the Web template and run this web template in the browser.
12.3.Sample Web Dashboards
Page 135 of 150

GENERIC EXTRACTION
STEPS:
Go to se11,select view button
Page 136 of 150

Page 137 of 150

Page 138 of 150

Page 139 of 150

Page 140 of 150

Page 141 of 150

Page 142 of 150

Page 143 of 150

Page 144 of 150

Page 145 of 150

RSA3 TO CHECK THE NUMBER OF RECORS IN DS.
GO TO RSA1 IN BW.
Page 146 of 150

Page 147 of 150

Page 148 of 150

SELECT RSDS AND PROCESS THE SAME STEPS.
Page 149 of 150

AFTER REPLICATION PROCESS IS SAME AS CUBE CRATION.
Page 150 of 150

SAP BI Prepared By SIT-----Tehno-Functional Module

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SAP BI Prepared By SIT-----Tehno-Functional Module

Transféré par

Droits d'auteur :

Formats disponibles

SAP BI Prepared By SIT-----Tehno-Functional Module

9.3. Loading Data from R/3 into BW

Enterprise Resource Planning or ERP is an industry term for integrated,

ERP Market Leaders

• World wide Usage

• Real Time processing

Business Processes: ASAP-Methodology

Introduction to Business Intelligence

Business Intelligence is a technology based on customer and profit oriented

BI solutions differ from and add value to standard operational systems

• By providing the ability to extract, cleanse and aggregate data from

To implement BI, the following technologies are used-

• Extraction, Transformation and Loading (ETL) - Data is extracted

• On-Line Analytical Processing (OLAP) and Data Mining - Analysis tools

Criteria OLTP data OLAP data

1.2. The Classic Star Schema

Classic Star Schema

EXTENDED STAR SCHMEA.

Connecting Master Data Tables to an InfoCube

DIFFERENCE BETWEEN STAR SCHMA(Classic) AND EXTENDED(BW) SCHMA

Fact Key Figure

Dimension Attribute Characteristic

Described Attribute Attribute

Dimension Tables Dimension Tables

Dimension = Dimension Table Dimension =

1.3. Introduction to SAP BW

1.4. SAP BW Architecture

Figure 1.2: SAP BW Three Layer Architecture

1.4.1. Source Systems

1.4.1.1. mySAP.com Components

1.4.1.2. Non-SAP Systems

In heterogeneous system landscapes, an important requirement is that the

SAP automatically supports automatic import of files in CSV or ASCII format

1.4.1.3. Data Providers

importing metadata and original data, the necessary structures can be

1.4.2. SAP BW Server

The Administrator WorkBench (AWB) is responsible for the control,

1.4.3. SAP BW OLAP

1.5. The SAP BW Star Schema

SAP BW Star Schema

1.5.2. Master Data Tables/SID Tables

Master data information is stored in separate tables called master data

As mentioned earlier, precisely one numerical SID key is assigned to each

Master Data Tables

1.5.3. Connecting Master Data Tables to an InfoCube

Connecting Master Data Tables to InfoCube

Sharing Master Data Tables among InfoCubes

1.5.4. Comparison of SAP BW Star Schema and Classic Star

Classic Start Schema SAP BW Star Schema

1.5.5. Advantages of the SAP BW Star Schema

1.5.7. SAP BW Star Schema Restrictions

1.6. Introduction to Data Warehousing Workbench:

BW RSA1OLD Tcode screen, Administrator Workbench in 3.X

RSA1 Tcode screen, Data warehousing Workbench in BI 7.X.

Functional Areas of the Data Warehousing Workbench:

Data Warehousing Workbench

2 Introduction to InfoObjects &

2.1. Introduction to InfoObjects

2.2. Types of InfoObjects

1. Characteristics: In SAP-BW, attributes located in the dimension tables

2. Key Figures (quantitative information, e.g., amount, count, quantity)

Time Characteristics - Time characteristics form the time reference frame