SAP BI
2015
SAP BI - Course
Fundamentals
1
SAP BI
2015
Content
Business Intelligence – what is? ............................................................................................................ 3
Why BI? .............................................................................................................................................. 3
1.
OLAP vs OLTP systems .............................................................................................................. 4
2.
What is ETL process .................................................................................................................... 6
3.
What is Star schema? .................................................................................................................. 7
4.
Infoproviders ................................................................................................................................ 12
4.1 Infoproviders overview ................................................................................................................ 13
4.2
Infoproviders type: .................................................................................................................. 14

BI Infocub ................................................................................................................................. 14

DataStore Object (DSO) ........................................................................................................ 16

Multiproviders .......................................................................................................................... 19
Infoobjects:................................................................................................................................... 19
5.
Characteristics InfoObjects ............................................................................................................... 20
InfoObjects: Key Figures .................................................................................................................. 23
6.
Data warehouse workbench – RSA1....................................................................................... 24
7.
Extract data from source system and data source ( extractor) ............................................ 27
8.
Process chain .............................................................................................................................. 30
9.
Create BEX analyser Query ...................................................................................................... 31
Functions of the BEx Query Designer – different panes: InfoProvider, Filter, Row/Columns,
Properties, Tasks ............................................................................................................................... 33
Restricted Key Figures ...................................................................................................................... 35
Calculated Key Figures ..................................................................................................................... 36
10.
Workbooks – reporting ........................................................................................................... 39
2
SAP BI
2015
Business Intelligence – what is?
The reporting, analysis, and interpretation of business data is of central importance to a company
when it comes to guaranteeing a competitive edge, optimizing processes, and being able to react
quickly and in line with the market.
With Business Intelligence (BI), SAP NetWeaver provides data warehousing functionality, a
business intelligence platform, and a suite of business intelligence tools which an enterprise
can use to attain these goals.
With SAP NetWeaver Business Intelligence (BI), SAP AG offers its customers an independent
enterprise data warehouse and reporting solution.
So in summary, Business Intelligence software is the collection of applications needed to make
sense of business data. The Data Warehouse, a component of this Business Intelligence tool
set, is the more specific tool responsible for the cleanup, loading, and storage of the data
needed by the business. Although we will address the overall BI tool set in the next lesson, this
class focuses on the Data Warehouse component.
A Data Warehouse can help to organize the data. It brings together all operative DataSources
(these are mostly heterogeneous and have differing degrees of detail).
The job of the warehouse is to provide this data in a usable form to the whole organization. The
data can then be used for future requirements as the need arises.
As a core component of SAP NetWeaver, BI provides Data Warehousing functionality, a
Business Intelligence platform, and a suite of Business Intelligence tools that enable businesses
to attain the maximum value from the information they collect. Relevant business information
from productive SAP applications and all external Data Sources can be integrated, transformed, and
consolidated in BI.
BI provides flexible reporting and analysis tools to support you in evaluating and interpreting data, as
well as facilitating its distribution. Businesses are able to make well-founded decisions and determine
target-orientated activities on the basis of this analysis.
Why BI?
The effective and flexible BI tool set from SAP helps you to gather any detailed information
from internal and external SAP sources and survey the processes in your company more
clearly than ever before. With BI, your managers are better informed at all levels, enabling them
to make decisions in the short reaction times available in today's dynamic markets. At the
same time, BI helps you to keep costs down in information management.
Relevant business information from productive SAP applications (SAP transactional system) and
external data sources can be integrated, transformed, and consolidated in BI with the toolset provided.
BI provides flexible reporting, analysis, and planning tools to support you in evaluating and interpreting
3
SAP BI
2015
data, and tools for distributing information. Businesses can make well-founded decisions and identify
target-orientated activities on the basis of the analyzed data.
The increasing demand for high-quality business information means that in addition to an integrated
data collection process, detailed data analysis and multimedia presentation options are also required.
The demand for Business Intelligence solutions that incorporate all of these features is immense.
1. OLAP vs OLTP systems
Transaction-orientated OLTP and analysis-orientated OLAP environments must be considered a
single entity. The data for the business processes produces a multitude of information that can not
easily be used for targeted analysis.
Therefore, the source data is initially cleansed, then technically and semantically prepared
homogenized). From the analyses of this data comes knowledge. This helps the organization define its
business strategy and supports the business processes derived from it. The following figures illustrate
this cycle.
Fig 1. Closed Loop: Operative/Informative Environment
Differences between a BI/Data Warehouse System (OLAP) and an OLTP System (transactional
system).
4
SAP BI






2015
Level of detail: The OLTP layer stores data with a very high level of detail, whereas data in
the Data Warehouse is compressed for high-performance access (aggregation).
History: Archiving data in the OLTP area means it is stored with minimal history. The Data
Warehouse area requires comprehensive historical data.
Changeability: Frequent data changes are a feature of the operative area, while in the Data
Warehouse, the data is frozen after a certain point for analysis.
Integration: In contrast to the OLTP environment, requests for comprehensive, integrated
information for analysis isare very high.
Normalization: Due to the reduction in data redundancy, normalization is very high for
operative use. Data staging and lower performance are the reasons why there is less
normalization in the Data Warehouse.
Read access: An OLAP environment is optimized for read access. Operative applications (and
users) also need to carry out additional functions regularly, including change, insert, and
delete.
Fig. 2 Comparison: OLTP Systems and OLAP Systems
5
SAP BI
2015
2. What is ETL process
The ETL process, sometimes called the data flow is a list of the steps that raw (source) data must
follow to be extracted, transformed, and loaded into targets in the BI system. This ETL process is
shown at the bottom of the following figure.
Specifically for BI, the ETL it is the process of taking raw DataSource data from a source
system(created in RSO2 or if it is SAP standard, activated in RSA6), applying transformation
rules to it, and loading it to an InfoProvider (target).
ETL process is shown in the picture bellow with steps from 1 to 5:
1. Data source to “EXTRACT”
2. Transformation to “TRANSFORM”
3. **optional
4. Infopackage to “LOAD” and 5. DTP also to “LOAD”
6
SAP BI
2015
3. What is Star schema?
See also link video:
https://www.youtube.com/watch?v=BqDuhwCjfAM
In Data Warehousing and Business intelligence (BI), a star schema is the simplest form of
dimensional model, in which data is organized into facts and dimensions.
A fact is an event that is counted or measure, such as a sales or quantity.
A dimension contains reference information about the fact, such as date, product, or customer.
A star schema is diagramed by Fact/Transaction table surrounded by
Dimensions/Master table.
The resulting resembles a star.
Before you create an InfoCube, you want to understand the underlying database model in a more
technical way.
7
SAP BI
2015
Aici, mai jos o sa intelegem diferenta intre modul de configurare si acces al tabelelor in sistemul
OLTP (SAP transactional), comparativ cu sistemul BI.
Se vorbeste de schema relationala normalizata din OLTP comparativ cu star schema din BI,star
schema care este vazuta in 2 feluri: clasic si extended:

In OLTP is a Highly Normalized Relation Database Schema
Almost all OLTP system are designed using a highly normalized relational schema.
Fig. Normalized OLTP database schema
A very simplified example of a sales order is shown on the above figure. As described in the figure,
normalization is the process of removing repeated data from a table to auxiliary connected tables,
thereby making the original table much smaller. This decrease in size, combined with only the most
basic indexing scheme, helps when creating, updating, and deleting records. The price paid for this
advantage is a decrease in performance for analysis-type queries.
 The Classic Star Schema in BI
Multidimensional data models are needed for the creation of Enterprise Data Warehousing (EDW) or
OLAP applications, in other words, for analytical applications.
The problems with OLTP's normalized design preclude it being used to support complex, ad hoc data
analysis.
The classic star schema, as illustrated in the following figures, is the most frequently used
multidimensional model for relational databases.
This database schema classifies two groups of data:
1. facts (sales amount or quantity, for example) and
2. dimension attributes (customer, material, or time, for example).
8
SAP BI
2015
Facts, sometimes called measures, are the focus of the analysis for a business process.
The fact data (values for the facts) is stored in a highly normalized fact table.
The values of the dimension attributes are stored from a technical perspective, in various denormalized
dimension tables.
Din perspectiva afacerii, aceste tabele sunt vazute in mod colectiv ca reprezentand dimensiuni ale
procesului de afaceri, pe scurt acestea sunt numite dimensiuni (dimensions).
The dimension tables are linked relationally with the central fact table by way of key relationships.
In star schema de mai jos, cheia tabelelor de dimensiuni este o cheie generata automat (DIM ID) care
in mod unic defineste o combinatie a valorilor atributelor dimenisiunii (campurile dintr-o dimensiune,
aici, sunt numite attribute ale dimensiunii).
DIM ID va fi o cheie externa in fact table. In acest fel, toate inregistrarile din fact table pot fi
identificate in mod unic.
Fig. Classic star schema
In BI, campurile din dimensiuni sunt numite characteristici si Facts, din fact table sunt
reprezentate de indicatori sau key figure.
9
SAP BI
2015
Fig. Star schema: Functional view
Fig. Populated star schema with example for cost center
 The BI Schema: An Extended Star Schema
Although the figure above is a functional definition of a star schema, from the BI system perspective it
not complete. The complete BI schema on which we base much of the EDW is a much enhanced
10
SAP BI
2015
(refined) star schema. The improvements eliminate both technical and business-reporting problems
experienced with the classic star schema.
Before we can delve into the schema of a BI InfoCube, we need to review characteristics InfoObjects.
We want to focus on master-data-bearing characteristics InfoObjects. The figure below shows two of
the many master-data-bearing characteristics delivered by BI. Although characteristics InfoObjects are
the attribute fields on the dimension tables, the characteristics that have their own master data tables
connected to them are very important in our overall schema design.
Fig. Master-Data-Bearing Characteristics InfoObjects
11
SAP BI
2015
Fig. BI InfoCube: An Extended Star Schema
4. Infoproviders
12
SAP BI
2015
4.1 Infoproviders overview
InfoProviders are objects for which you can create and
execute queries in SAP BI.
These include objects that physically store data – the
data targets, such as:
-
InfoCubes,
-
Data store objects (DSO objects),
-
and InfoObjects (characteristics with attributes
or texts).
They also include objects that do not contain any actual
data, such as:
-
InfoSets,
-
RemoteCubes and
-
MultiProviders (Union combined to for
views)
InfoProviders are the objects or views relevant to reporting. The system supplies data targets
with data from the source systems using a load process (or by writing directly into the tables for
transactional object types (for planning part)).
13
SAP BI
2015
4.2 Infoproviders type:
 BI Infocub
An InfoCube comprises the fact table and its associated dimension tables in a star
schema.
InfoCubes are the central objects of the multidimensional model in BI. Most BEx reports and
analyses are based on these. From a reporting perspective, a InfoCube describes a self-contained
data set within a business area, for which you can define queries.
A InfoCube consists of a quantity of relational tables arranged multidimensionally, meaning that it
consists of a central fact table surrounded by several dimension tables. SID tables link these
dimension tables to their respective master data tables.
Hint: There are various types of Infoproviders in BI. The Infoprovider with type InfoCube is the
Infoprovider most relevant for modeling discussions, since physical database objects (objects that
contain data) are the core of your BI project.
14
SAP BI
2015
Fig. A Bigger Example of an Extended Star Schema
15
SAP BI
2015
Steps for creating an Infocub:
See video for creating infocub: https://www.youtube.com/watch?v=W3U57XJl_kE
 DataStore Object (DSO)
Definition
A DataStore object serves as a storage location for consolidated and cleansed transaction
data or master data on a document (atomic) level.
This data can be evaluated using a BEx query.
A DataStore object contains key fields (like document number or document item) and data
fields that, in addition to key figures, can also contain character fields (like order status or
customer).
16
SAP BI
2015
The data in a DataStore object can be updated with a delta update into InfoCubes (standard)
and/or other DataStore objects or master data tables (attributes or texts) in the same system or
across different systems.
Unlike multidimensional data storage using InfoCubes, the data in DataStore objects is
stored in transparent, flat database tables. The system does not create fact tables or
dimension tables.
DS Oject Types
SAP BI distinguishes between three DataStore object types: Standard, Write Optimized, and Direct
Update. These three flavors of DataStore Objects are shown in the following figure.
Type
Structure
Data
SID
Supply
Generation
Possible
Standard
Consists of three
From data
DataStore
tables: activation
transfer
Object
queue, table of active
process
Yes
data, change log
Write-
Consists of the table of
From data
Optimized
active data only
transfer
DataStore
No
process
Objects
DataStore
Consists of the table of
Objects for
active data only
From APIs
No
Direct Update
See also video for creating DSO:
https://www.youtube.com/watch?v=2iXDtRNuNeE or/and
https://www.youtube.com/watch?v=kNOjQd4xC88
Business Example
Your company is about to retire a legacy sales reporting system. Although you are not complete with
your InfoCube modeling decisions, your sales team has decided to use a DataStore object to store data
from this legacy system before it disappears.
To make sure this is a good decision, you want evaluate the DataStore objects and their features and
functions. You also want to make sure you can add a InfoCube in the data flow in the future.
DataStore Object: Purpose and Features
A DataStore object is used to store consolidated and cleansed data (transaction data or master data) on
a document level (atomic level). Although DataStore Objects can store master data, and there are valid
reasons for this, they primarily store detailed transaction data DataStore Objects are positioned in the
over all warehouse design, as shown below. They can be used to support detailed operational
17
SAP BI
2015
reporting, or can be part of the of the warehouse, where they can be used to hold years of
potentially needed data.
Fig. DataStore Objects: Purpose
One major difference between DataStore Objects and InfoCubes is that DataStore Objects have
the option to overwrite records, where InfoCubes do not. This is a huge difference!
Cubes create a new record if the characteristics in two different records are not exactly the same. For
example, you would not want a new record if you loaded the same sales order once with status open
and once with status closed? I think you can see that the answer in most cases is no!
Features and Functions of DataStore Objects



Designed to save cleansed data at a document level
o consolidated or overwritten
Overwrite function
o Characteristics that are not part of the record identifier (Key) always overwrite (for
example, Order Status)
o Key Figures (for example, Sales Amount or Number of document lines) can be set to
Overwrite, Add, or not update at all
Reporting via BEx
o Direct reporting is optional (used for DataStore Objects positioned in the Operations
DataStore section)
o Can be made unavailable** for DataStore Objects used for staging and pure data
storage functions in the warehouse section of your architecture
18
SAP BI

2015
o ** No authorization to report would be given to users for these DS objects
Normal reporting scenarios involve a drilldown from InfoCube to the DS object
Since a DataStore object is designed like a table, it contains key fields (document number and item, for
example) and data fields. Data fields can not only be key figures but also character fields (order status,
customer, or time, for example). You can use a delta update to update DataStore object data into
connected InfoCubes or into additional DataStore objects or master data tables (attributes or texts) in
the same system or in different systems.
In contrast to multidimensional DataStores for InfoCubes, data in DataStore objects is stored in flat,
transparent database tables. Fact and dimension tables are not created.
With DataStore objects, you can not only update key figures cumulatively, as with InfoCubes, but
also overwrite data fields. This is especially important for transaction-level documents that change
in the source system. Here, document changes not only involve numerical fields, such as order
quantities, but also non-numerical ones such as ship-to parties, delivery date, and status. Since the
OLTP system overwrites these records when changes occur, DataStore objects must often be
moceled to overwrite the corresponding fields and update to the current value in BI.
 Multiproviders
A MultiProvider is a type of InfoProvider that combines data from a number of InfoProviders and makes
it available for analysis purposes. The MultiProvider itself does not contain any data. Its data comes
entirely from the InfoProviders on which it is based. These InfoProviders are connected to one another by a
union operation.
5. Infoobjects:
See video: https://www.youtube.com/watch?v=J5HeVILc-y8
The Importance of InfoObjects in BI
InfoObjects are the smallest available information modules or fields in BI. They can be uniquely
identified by their technical name.
Before we move on, let's provide a definition: Infoobjects are bricks of infoproviders.
They are divided into:
characteristics (for example, customers),
units characteristics (for example, currency or amount unit),
time characteristics (for example, fiscal year),
technical characteristics (for example, request number),
key figures (for example, revenue).
Key Figure InfoObjects
provide the values to be evaluated. Examples of key figure nfoObjects:
- Quantity (0QUANTITY)
- Amount (0AMOUNT)
Characteristics InfoObjects
are business reference objects that are used to analyze key figures.
Examples of characteristics InfoObjects:
- Cost center (0COSTCENTER)
19
SAP BI
-
2015
Material (0MATERIAL)
Time Characteristics InfoObjects form the time reference frame for many data analyses and
evaluations. They are delivered with BI Content.
Examples of time characteristics InfoObjects:
- Calendar day (0CALDAY) . Time characteristic with the largest granularity
- Calendar year (0CALYEAR) or fiscal year (0FISCYEAR) – Time characteristic with the
smallest granularity
Units InfoObjects can be specified along with the key figures. They enable key figure values to be
paired with their corresponding units in evaluations.
Examples of units InfoObjects:
- Currency unit (0CURRENCY) . Holds the currency of the transaction ($,EUR, and so on)
- Value unit (0UNIT) . Holds the unit of measure (Gallon, Inch, cm, PC)
Technical characteristics InfoObjects have an organizational function within BI. Examples of
technical characteristics InfoObjects:
- Request ID (0REQUID)
- Change ID (0CHNGID)
Characteristics InfoObjects
Characteristics InfoObjects are used to analyze key figures, for example, Customer (characteristic)
Sales (key figure).
The Maintenance menu of creating a characteristic contains in RSA1 the following tab pages:
. General
. Business Explorer
. Master data/texts
. Attributes
. Hierarchy
. Compounding
20
SAP BI
2015
Fig. Characteristics: General Tab
Data types of characteristics are:
CHAR (Character String ),
NUMC ( Character string only digits),
DATS ( Date field (YYYYMMDD) stored as char(8)
TMS – Time fiels (ffmmss), stored as char(6)
21
SAP BI
2015
Master data tab page:
On this tab page, you determine whether or not the characteristic can have attributes or texts. If the
characteristic is to have its own texts, you need to make at least one text selection (short, medium-length,
or long text, that is, 20, 40, or 60 characters). The attributes are assigned to the characteristic on the
Attributes tab page. By selecting any of these checkboxes, the characteristic is designed to bear master
data.
Attribute tab page:
Attributes are InfoObjects (characteristics or key figures) that are used to describe
characteristics in greater detail. For example, the characteristic cost center can be described in more
detail with the profit center and person responsible information about the cost center or if we take as
an example the characteristic material, attributes of the material can be Length, width or color.
If you define attributes as display attributes, you can use these attributes only as additional
information in reporting when combined with the characteristic.
22
SAP BI
2015
In other words, in reporting, you cannot navigate within the dataset of an InfoProvider using these
attributes.
If you define attributes as navigation attributes, you can use them to navigate in reporting.
When a query is executed, the system does not distinguish between navigation attributes and
characteristics for an InfoProvider. In other words, all navigation functions in the query are also
possible for navigation attributes.
InfoObjects: Key Figures
Business Example
Although you could use the BI Content key figure 0AMOUNT, your project team is not sure that they
can use the same settings for this key figure in all areas of the BI implementation. For this reason, you
are considering making a copy of 0AMOUNT and using the copy in your cost center analysis BI
project.
InfoObject Catalogs
The warehouse has many objects in it. In order to find these objects easily, we organize them into
different types of folders. InfoObject catalogs are just one of the types of available folders in the
warehouse. The figure below shows all the available folders associated with InfoObjects and what
they contain.
Fig.Folders in BI: InfoObject-Related
Key Figures InfoObjects
You can define key figures InfoObjects and change settings on the following tab pages on the
Maintenance menu:
- Type/unit
- Aggregation
- Additional Properties
Type/Unit Tab Page
23
SAP BI
2015
On this tab page, you determine the key figure type (amount, quantity, number and so on), the data
type (currency field/floating-point number, quantity field/floating-point number, and so on), and the
currency/quantity unit.
Type/unit tab:
Fig. KeyFigure InfoObject: Type/Unit Tab
6. Data warehouse workbench – RSA1
See video: https://www.youtube.com/watch?v=AX1tF4LUKiU
Business Example
To perform maintenance and administration tasks for your BI Data Warehouse, you need to learn the
features and functions of the Data Warehousing Workbench and how to access them. You also need
general navigation skills, such as searching for objects and adding them to your favorites. Knowing
how to use the search function and other functions will make working in BI much easier.
Data Warehousing Workbench
This section describes the functions performed using the Data Warehousing Workbench (transaction
code RSA1). The DWWB is the central tool for the BI technical professional.
24
SAP BI
2015
Fig. Data Warehousing Workbench: A Central Tool
The functions of the DWWB are defined below:
 Modeling
o Database objects and transformations are created
 Administration
o Load scheduling, monitoring, and data administration
 Transport Connection
o Specialized BI transport tool set (discussed in BW360)
 Documents
o Central GUI for the maintenance of documents
 BI Content
o SAP delivered content it is here and can be activated for use
 Translation
o BI object (queries, InfoCubes, and so on) descriptions are translated for multiple
language support
 Metadata Repository
o Power users and functional experts can find details on delivered and custom content
objects
25
SAP BI
2015
Fig. Functions of DWWB
Fig. Data Warehousing Workbench: Modeling
26
SAP BI
2015
Fig. Data Warehousing Workbench: Administration (Running the
Warehouse)
7. Extract data from source system and data
source ( extractor)
See video:
https://www.youtube.com/watch?v=IOMgus_GEaQ
Optional videos:
https://www.youtube.com/watch?v=oQaS28w-cN4
https://www.youtube.com/watch?v=3wRZWXkZ4sc
27
SAP BI
2015
For extracting data, the following tools and objects are needed:

Source System:
A Definition
A source system is any system that is available to BI for data extraction and transfer purposes.
Examples include SAP ECC (transactional or OLTP), File, SAP BI, custom system-based Oracle
DB, PeopleSoft, and many others.
Fig. Source System Types and Interfaces

DataSource (extractor):
A Definition
DataSources are objects used to extract and stage data from source systems.

Persistent Staging Area (PSA) is an industry term and is defined as:
1. The storage and processing to support the transformation of data.
2. It is typically temporary.
3. Is not constructed to support end-user or tool access-BEX.
4. Specifically built to provide working (or scratch) space for ETL processing.
Technically, it is transparent database table in which request data is stored. A PSA is created
per DataSource and source system. It represents an initial store in BI, in which the requested
data is saved unchanged from the source system.
28
SAP BI

2015
Transformations
Once the data arrives in the PSA, you then have to cleanse / transform it prior to physical storage in
your targets. These targets include InfoObjects (master data), InfoCubes and DataStore Objects.

InfoPackages and Data Transfer Processes
The design of the data flow uses metadata objects such as DataSources, Transformations and
InfoProviders.
Once the data flow is designed, the InfoPackages and the Data Transfer Processes (DTP) take
over to actually manage the execution and scheduling of the actual data transfer. As you can see
from the figure below, there are two processes that need to be scheduled.
InfoPackages is loading the data from the source system.
InfoPackage is the BI object that contains all the settings directing exactly how this data should be
uploaded from the source system. The target of the InfoPackage is the PSA table tied to the specific
DataSource associated with the InfoPackage.
29
SAP BI
2015
Fig. InfoPackages and Data Transfer Processes Initiate the Data Flow
DTP is the data transfer process. It is that object that controls the actual data flow (filters, update mode
(delta or full) for a specific transformation between 2 infoproviders or from PSA to a infoprovider.
8. Process chain
Business Example
You realize that all the daily tasks of your BI project would never get done without the use of automation.
Tasks such as the deletion of data, scheduling of InfoPackages, triggering of data transfer processes into
targets, compression of InfoCubes, and so on, are too numerous to manage without a specialized tool.
You want to investigate the use of process chains to accomplish this much-needed automation.
Purpose of Process Chains
There are many nightly, weekly, or monthly tasks that are performed in your BI system. The basics of
just one InfoCube load is shown in the figure below, still needed are multiple tasks to support master
data loading, and then these need to be multiplied by all the different master and transactional targets
in your system.
30
SAP BI
2015
Process chains provide a drag-and-drop scheduling interface for background tasks that occur in
BI.
Process chains are accessed under transaction RSPC or under the appropriate link in Data Warehousing
Workbench.
Process chains allow:
1. Automatization of the complex schedule of tasks in BI
2. Visualization of processes by using network graphics
3. Central control and monitoring of tasks (processes) in the same or linked chains
9. Create BEX analyser Query
See video: https://www.youtube.com/watch?v=mfvQT9zXm_s
The Business Explorer (BEx) is a component of SAP BI that provides flexible reporting and analysis
tools that you can use for strategic analysis and supporting the decision-making process in your
organization. You can use the BEx tool to display past and present data in differing levels of detail
and from different perspectives, on the Web and in Microsoft Excel.
Business Example
You use SAP BI to define reports that enable standardized navigation functions in analyses, independent
of the source operational system.
You want to define simple reports, execute these, and make changes to the report definition.
Calling the BEx Query Designer
Using the SAP BI 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.
By selecting and combining the InfoObjects in a query, you determine the way in which data from the
chosen InfoProvider is evaluated.
31
SAP BI
2015
You have various options for calling up (opening) the Query Designer:
 From the BEx Analyzer
 As a separate program using Start → Programs → Business Explorer → Query Designer
 UsingtheWeb Application Designer (see the BEx Web Application Designer unit)
 FromtheBEx Report Designer
Fig. They way of data to reporting and analysis
Fig. SAP Business Intelligence
32
SAP BI
2015
Functions of the BEx Query Designer – different panes: InfoProvider,
Filter, Row/Columns, Properties, Tasks
The following figure 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. Please note,
toolbar functions are context sensitive which means that certain buttons may be inactive if they are not
valid for your context. (i.e. the Save button is inactive until there is something to save!)
Fig. Query toolbar
Fig. Query Designer Layout (filter view)
33
SAP BI
2015
The Query Designer contains many different panes, some panes are only displayed when a function
button is pressed. However, we will now describe the key panes:
1. Directory tree of the selected InfoProvider.
Once you have selected the required InfoProvider, all available objects (dimensions, key figures,
structures) display in the directory tree in the left screen area of the Query Designer.
In this example, you can see the directory tree for the InfoProvider InfoCube Customer Cube
T_SDDEMO2.
2. Characteristic Restrictions
Here you define the characteristic filter values which apply to the entire result set.
3. Default Values
In this pane you define the characteristic filter values which should be used for the initial view of the
result set. The user may choose to modify these filters in the result.
4. Properties
Here is where the settings relevant to the currently highlighted query object are displayed. You can
also make changes to the setting here. Often there will be multiple tabs used to organize the settings in
this pane.
5. Messages
This pane is where informational or error messages are displayed.
Fig. Query Designer Layout (rows/columns view)
6. Free Characteristics.
Put the characteristics which you want to offer to the user for navigation purposes in this pane. These
characteristics do not appear in the initial view of the query result set, the user must use a navigation
control in order to make use of them.
You do not define the filter values here.
34
SAP BI
2015
7. Columns
Here is where the query objects (key figures or characteristics) must be placed if you want them to
appear in the columns of the results set.
8. Rows
Here is where the query objects (key figures or characteristics) must be placed if you want them to
appear in the rows of the results set.
9. Preview
This pane gives you an idea of what the layout of the results set will look like when you execute the
query.
10. Tasks
A list of suitable tasks relating to highlighted query object are displayed here, you can click on any of
the tasks in the list to go directly to the settings.
11. Where Used
This pane provides information relating to the use of the query object.
Restricted Key Figures
Business Example
You need restricted key figures in order to be able to define detailed reports. For example, you want to
list sales volumes for individual time segments next to each other in the report. If you create them at
the InfoProvider level, you are then able to reuse the individual key figures in other reports.
Defining 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 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.
The Restricted key figures defined at InfoProvider level and can be used for all queries in which
that infoprovider it is used.
35
SAP BI
2015
Fig. Defining Restricted Key Figures
Calculated Key Figures
Business Example
The use of complicated calculations for information analysis is the order of the day. This requires various
mathematical functions such as percentage functions and totals functions. You can take basic key
figures, restricted key figures or calculated key figures to define new calculated key figures. For
example, you use the restricted key figures for two specific years to calculate the difference between
the sales volumes of the years in question.
Functions for Defining 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.
Below are examples and explanations of the functions available as operators when you define a
calculated key figure.
Percentage Functions:
Percentage Variance (%)
<Operand 1> % <Operand 2>
36
SAP BI
2015
Gives the percentage variance of operand 1 from operand 2.
Example: Planned Sales Volume% Actual Sales Volume gives the percentage by which the actual
sales volume exceeds the planned sales volume.
Percentage Share (%A)
<Operand 1> %A <Operand 2>
Gives the percentage share of operand 1 of operand 2.
Example: Sales Volume %A Incoming Orders specifies the percentage share of sales volume made up
of incoming orders.
Percentage Share of Result (%CT)
%CT<Operand>
Specifies how high the percentage share is in relation to the result. The result means the result of
aggregation at the next level (interim result).
%CT Incoming Orders specifies the share of incoming order values of each individual characteristic
value (for example of each customer) in relation to the characteristic's result (for example, customer of
a division).
Data Functions
Counts
COUNT(<Expression>)
Delivers the value 1 if the expression named in <Expression> is not equal to 0. Otherwise, delivers the
value 0.
NDIV0 (x): Is equal to 0 with division by 0, otherwise x.
NDIV(<Expression>)
Delivers 0 if the expression named in <Expression> gives a division by 0 in the calculation.
Otherwise, the result is the value of the expression.
Is used to:
- Avoid the output of an error message
- Continue calculating with a defined result
Result
SUMCT <Operand>
Delivers the result of the operand in all rows or columns (see Percentage Functions %CT).
Overall Result
SUMGT<Operand>
Delivers the overall result of the operand (see Percentage Functions %GT).
Report Result
SUMRT<Operand>
Delivers the report result of the operand (to distinguish between the overall and the report result, see
also Percentage Functions %GT and %RT).
Mathematical Functions
These include:
Maximum
Minimum
Absolute Value
Smallest integer value larger than operand
Division (integers)
37
SAP BI
2015
Defining Calculated Key Figures at the Query Level
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 the query level and the InfoProvider level. At the query level, the
calculated key figure is valid only for the query in question. If you create a calculated key figure at the
InfoProvider level, you can use it in all queries that are based on the same InfoProvider.
Fig. Calculated Key Figures
To define calculated key figures at the query level, you have to include key figures needed for the
calculation in the query definition, and choose New Formula from the context menu of the Key Figure
structure. 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.
Defining Calculated Key Figures at the InfoProvider Level
To define calculated key figures at the query level, you can include all types of key figures which are
defined at the InfoProvider level, these include basic key figures, restricted key figures and, of course,
calculated key figures. However you must remember that you do not have access to all operators as
some operators only make sense at the query level. Don't forget that once you have defined the
calculated key figure at the InfoProvider level it is not automatically included in your query, you
must drag and drop it to where it should be used !
Caution: Any calculated key figure defined at the InfoProvider level can be used in others
queries. Query developers may want to try to change the definition (or just the name) of your
calculated key figure so it fits their purpose. They will receive a warning message if they try to do this,
38
SAP BI
2015
but assuming they do have the correct authorizations they can make the changes. These changes will
affect all queries where the calculated key figure is used.
10.
Workbooks – reporting
See video;
https://www.youtube.com/watch?v=lfjhC8GOBj4&list=PLyH9U1E43FYqGiaxunNkLE
vv1ZeqpxAMH
http://help.sap.com/saphelp_nw70ehp2/helpdata/en/ba/45583ca544eb51e10000000a1140
84/content.htm?frameset=/en/ba/45583ca544eb51e10000000a114084/frameset.htm&curr
ent_toc=/en/e3/e60138fede083de10000009b38f8cf/plain.htm&node_id=1697&show_child
ren=false
Din link-ul alaturat expandati va rog ramura cu Analysis & Reporting: Bex Analyser
39