Business Intelligence class: Lesson one

Why is business intelligence (BI) needed?

Modern day Enterprise resource planning (ERP) systems have made it easier to gather
data about almost anything. This can be the date and time a customer ordered a product,
the number of orders over the lifetime of that customer etc. Multiply this amount of data
by the number of customers the company has and you can easily see that for a customer
that has millions of customers, the amount of data gathered is huge. Another problem is
that the data might be saved in different formats, different databases.
But this is necessarily not a problem. If you have a system that can efficiently gather the
data from all theses sources and produce some meaning from it, that can potentially be
powerful information for a company.
This is the goal of SAP business intelligence, to streamline the whole process all the way
from
1. Gathering the data from all available sources
2. Storing it efficiently for fast and easy access,
3. Analyzing the data and creating reports that can be used to draw meaningful
information.
4. Presenting reports in a multimedia format, in the form of charts, images etc.
5. And ultimately help the user in efficient decision making.
If someone asks you, what is a business intelligence system? You tell them it is one that
basically makes sense of data. This is all I have for now, there was more to the lesson.
Stuff about the Data warehouse side of the story and the differences between a
BI/Warehouse (OLAP) system and a classic OLTP system.
Business Intelligence class: Lesson two
The BI system is modeled as a 3-tier architecture. The bottom and entry point is the data
warehouse which is the interface to the source systems. This is where data is brought into
the BI system from all the different data source type like Excel spreadsheets, Oracle
databases or SAP R/3 systems.
The middle layer is the BI server, this is where all the data is stored and it is a format that
is suitable for analytical processing, the data is checked for integrity and successful
loading.
The top layer is the presentation layer, this is where all the tools are used to present
meaningful information to the user. These tools are called the business explorer tools.
Amongst them are the BEx query designer, BEx Analyzer etc. These tools will be
covered in a later lesson Business Intelligence
The BI system is modelled as a 3-tier architecture. The bottom and entry point is the data
warehouse which is the interface to the source systems. This is where data is brought into
the BI system from all the different data source type like Excel spreadsheets, Oracle
databases or SAP R/3 systems.

The middle layer is the BI server, this is where all the data is stored and it is a format that
is suitable for analytical processing, the data is checked for integrity and successful
loading.
The top layer is the presentation layer, this is where all the tools are used to present
meaningful information to the user. These tools are called the business explorer tools.
Amongst them are the BEx query designer, BEx Analyzer etc. These tools will be
covered in a later lesson
The schema used to store transactional databases is the entity model where data is related
in a top-down format. Business intelligence warehouses use the multi-dimensional star
schema and SAP BI has its own version of the star schema which I will cover in another
lesson.Today I will be writing about the architecture of SAP business intelligence and the
differences between the way data is stored in traditional and BI systems. This is the
second post in this series, you can view the first one in this business intelligence class
series hereThe BI system is modelled as a 3-tier architecture, the data warehouse, the BI
platform and the reporting environment.
Data warehouse
The bottom and entry point is the data warehouse which is the interface to the source
systems. This is where data is brought into the BI system from all the different data
source type like Excel spreadsheets, Oracle databases or SAP R/3 systems.
BI platform
The middle layer is the BI platform, this is where all the data is stored and it is in a
format that is suitable for analytical processing, the data is checked for integrity and
successful loading.
Reporting environment
The top layer is the presentation layer, this is where all the tools are used to present
meaningful information to the user. These tools are called the business explorer tools.
Amongst them are the BEx query designer, BEx Analyzer etc. These tools will be
covered in a later lesson

OLAP vs. OLTP

Data in a BI system cannot be stored using traditional formats. Why? Because the
traditional way of storing data in relational databases is meant for easy and fast access but
not fast enough for analytical and reporting purposes. The traditional way of storing data
is optimized for online transactional processing purposes (OLTP), while BI data is stored
for online analytical purposes (OLAP).

What are the differences between these two?

Current vs. historical data

The data in OLTP database are up to date in real time while the data in OLAP is historical
data since it is used for reporting.
High number of users vs. low traffic
Transactional databases are optimized for simultaneous multi-user access while analytical
databases are optimized for large volume of data and lower number of concurrent users
Detailed vs. aggregated
The data in BI systems are aggregated because of their analytical nature. We need to
compute maximum values or average values for example and do not need the detailed
instantaneous values that transactional databases need.
Read-write operations vs. read only
The data in transactional database can be modified unlike in data warehouse scenarios
where the data is being copied over from the source systems. BI data warehouses tend to
have copies of online databases in a format optimized for analytical purposes.
Entity relationship vs. Multi-dimensional
The schema used to store transactional databases is the entity model where data is related
in a top-down format. Business intelligence warehouses use the multi-dimensional star
schema and SAP BI has its own version of the star schema which I will cover in another
lesson.
SAP BI Lesson: What is an InfoObject ?
InfoObject
SAP BI uses certain structures to model real world data. The InfoObject is one of these
structures. InfoObjects are used to evaluate the smallest units of business data. An
example is best to explain this.
A company like IBM will have products and customers. A customer is named John Smith
and he buys a laptop with the model number LAP001. An InfoObject can be used to
model the customer name and the product code. In this case, John Smith is an InfoObject
which is the customer name. LAP001 is also an InfoObject

For todays post, I will be talking about InfoObjects. SAP BI uses certain structures to
model real world data. The InfoObject is one of these structures. InfoObjects are used to
evaluate the smallest units of business data. An example is best to explain this.
A company like IBM will have products and customers. A customer is named John Smith
and he buys a laptop with the model number LAP001. An InfoObject can be used to
model the customer name and the product code. In this case, John Smith is an InfoObject
which is the customer name. LAP001 is also an InfoObject.
The Enterprise Data warehouse: BI Lesson
Data warehouse.
Today I will explain the Data warehouse component of the BI system and what its role is
in the system.
The data warehouse is the entry point of the BI system from all other data sources. It is
responsible for extracting the data from a various data sources, performing integrity
checks, aggregating and storage of the data.
A business intelligence component is normally run from a system separate from the
operative systems of the company. This is because the way data is stored in for BI
purposes is different. From the previous lesson you learned about the OLAP model, the
BI system needs to be able to carry out OLAP processing on large amounts of data.
Data acquisition
The first component of the data warehouse I will talk about is the data acquisition layer.
This is responsible for feeding the BI system with data. The data can come from various
source systems and is platform independent. Here are the various types of data sources
that can be used to feed a BI system with data.
Flat files
This comes mostly in the form of Excel spreadsheets. The data in the files can be
imported using CSV formatted data.
BI Server
The BI server acts as the host for the data warehouse. It stores all the master and
transaction data.
Before the data can be stored, it has to go through a process of cleansing and aggregation.
The techie word used here is called ETL, extraction, transformation and loading.
The data is extracted from the various source systems to the temporary storage area called
the persistent storage area (PSA) and then undergoes transformation which means the
data in cleansed of duplicates, integrity violations etc. After this is done, the data can now
be stored.

In the next lesson, I will

talk about either the InfoCube or the InfoObject. I have to decide which should logically
come up first.
If you like this post, please click here to subscribe to my blog and you will receive the
lessons directly as they are posted.
Business Intelligence Lesson: What is an InfoCube ?
In SAP business Intelligence, InfoProviders are the basis of most of the reporting you will
be doing in the real time. They are the objects that serve your reports with data. Hence the
name InfoProviders.
There are two types of InfoProviders, these are listed below

InfoCube, this type of InfoProvider stores the data in the system and makes it
available for reporting.
Virtual providers for example a Multiprovider, this will be covered in a later
lesson but basically, this is a type of InfoProvider that does not store the data
physically but combines the data from multiple InfoCubes into one view.As far as
reporting is concerned, it does not know how the data is stored. Physically or not,
the data is being presented to the reporting query in the same way.

A standard installation of SAP BI comes with a lot of default InfoCubes that models
many business processes from Financials to Sales and distribution. As a SAP BI
consultant, most of the time you will not need to create your own InfoCube but rather use
one out of the box or customize the existing one to suit your needs.

An InfoCube is modelled after the extended star schema shown in the picture above. The
fact table in the center of the cube contains the key figures. The fact table is surrounded
by dimensions which contain characteristics.
These are some statistics that are important if you plan to take the certification exam or
during interviews.
An InfoCube consists of one fact table that is used to store key figures.
The maximum number of key figures that the fact table can store is 233
The same fact table can have a minimum of 4 and a maximum 16 dimension
tables.
3 of these dimension tables are supplied by SAP. They are the Unit, data package,
and time dimensions.
The customer can create 13 dimensions.
Each of the 13 dimensions can have a maximum of 248 InfoObjects.
Each InfoObject can also contain master data in the form of Text, Attributes and
Hierarchies.
So you can see how advanced modelling is done in SAP business intelligence. This
allows for efficient reporting at the later stages.
The ETL Process : Business Intelligence Lesson
Todays post is about the ETL process, which forms the basis of data flow in the SAP BI
system.I will go into detail on what the E,T and L stand for and how they are tied together
to move data into BI and up into the the point where it ready for reports to be made on
that data.
The ETL process brings data from external sources into the BI system which will be used
later for analysis. There are three stages in this process, which is derived from the
abbreviation ETL
Extraction
Transformation
Loading
Extraction

Extraction is the process of bringing in raw data from a range of supported source
systems into the persistent storage area (PSA). The two objects that are active in this
process are the source systems and the PSA, which is sometimes referred to as the
datasource. The PSA stores the data temporarily before the transformation process begins
There are lots of supported source systems which can be used to bring data into the PSA.
XML, you can post data from web services that support the SOAP protocol to the
BI system
Data can also be extracted from custom databases. For example Oracle or SQL
server databases. These use the DBConnect/UDConnect adapters
Flat files like excel can serve the BI system with data using file interfaces
Data can also be retrieved from SAP systems like HR, MM, SD, CRM. These
connect using the BI service API
SAP BI Training : Transformation rules
It has been a while since my last post, there have been a lot of questions and emails going
back and forth with you all. If you would like to take part in the discussion, and you are
not subscribed yet, please do so in the box on the right.
Today, I am going back to basics and continuing the SAP BI training lessons. This is the
reason I started this blog but
I have found out that the SAP landscape is wide and people have more questions not
neccessarily pertaining to SAP Business Intelligence. Please let me know if you would
like to see more posts on SAP BI.
Transformations
The topic of the day is Transformation. Transformation is all about mapping fields from
source systems to destination databases. Sometimes, the mapping is one-to-one i.e you
have a field in the source table that maps directly to the destination. It is also possible that
the fields are not matched up correctly.
For example, length of the fields might be different in both or the way figures are
calculated might also be different. A good example is VAT. The amount of value-added
tax charged differs from country to country and this needs to be transformed
(recalculated).
Transformation rules are used to perform these operations.
Transformation rules
Normally, when mapping fields on the InfoSource to the fields in the InfoCubes,the
mapping was always one to one. In real time, this is not always the case. Some
InfoObjects are not present in the InfoSource fields but have to be calculated. These
calculations are done through transformations.
There are 7 different types of tranformations.
Direct assignment
Constants
Reading master data
Routines
Formula
Time updates
No transformation

I shall use an example to explain these transformations. Take a look at the table below. It
shows a simplistic view of a potential InfoSource that I want to transform to fields in the
InfoCube. The InfoSource has the following fields, Product, Sales quantity and
Price/unit. The destination InfoObjects are Product, Sales quantity, price per unit and
revenue.

Source fields

Destination fields
Direct assignment
This will copy the value in the source field directly into the target field. For example the
products, sales quantity will be transformed using direct assignment.
Constants
This transformation rule will fill the target field with a specified value. For example, the
import data field can be filled with todays date.
Routines
Routines are special code written to handle complex cases. There are start routines, end
routines and expert routine Start routines are used to pre process the data before
transformation, for example they can be used to eliminate empty fields before the process
starts. This makes the process efficient when there a lot of records being imported and a
handful will be empty fields.
End routines are used to post process the data on a package-by-package basis. This can
be used for integrity checks etc.
Routines are mostly written by ABAP consultants, you as a BI consultant will have to
supply the specifications for the routine you would like to implement.
I will explain the rest (Formulas, Reading master data and time updates) in a later post.
Do you have any special area of SAP business intelligence you would like more
explanation on? Please leave a comment and let me know.

ETL PSA Soure system

Transformation
After the data has been extracted from the source system, it has to be cleansed and
transformed into something meaningful for the BI system. After the transformation has
been done, it can be stored in the InfoObjects.
InfoSources are used for transformation. It serves like an adapter between the source
systems and the InfoCubes.
All the fields in the source system are mapped to the corresponding fields (InfoObjects)
in the InfoCube. For example customer name will correspond to client name InfoObject.
The InfoSource serves to make the InfoCube independent of the source system. When a
source system is swapped for another one, only the InfoSource gets to change.
Transformation rules are be applied to the InfoSource. This can be either direct
correlations, formulas or combinations. I will discuss more on transformation rules in a
later lesson
Loading
The next step in the process is to load the data into the end target. The end target referred
to in this case is the InfoProvider of which there are many types. The load process will be
different depending on which type of InfoProvider is being used. You can either have
records being added and records being updated with some change management going on.
Now that the data is loaded, the stage is set for reports to be made. This is the reason why
BI exists, to display reports for intelligent business decisions can be made.There you
have it, the ETL process being a major part of getting data ready for reports.
Frequently used TRANSACTION CODE in SAP BI

S.No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

Tcode
RSA1
RSA11
RSA12
RSA13
RSA14
RSA15
RSA2
RSA3
RSA5
RSA6
RSA7
RSA8
RSA9
RSBBS
RSD1
RSD2
RSD3
RSD4
RSDBC
RSDCUBE
RSDCUBED
RSDCUBEM
RSDDV
RSDIOBC
RSDIOBCD
RSDIOBCM
RSDL
RSDMD
RSDMD_TEST
RSDMPRO
RSDMPROD
RSDMPROM
RSDMWB
RSDODS
RSDS
RSIMPCUR
RSINPUT
RSIS1
RSIS2
RSIS3
RSISET

Description
Administrator Work Bench
Calling up AWB with the IC tree
Calling up AWB with the IS tree
Calling up AWB with the LG tree
Calling up AWB with the IO tree
Calling up AWB with the ODS tree
OLTP Metadata Repository
Extractor Checker
Install Business Content
Maintain DataSources
BW Delta Queue Monitor
DataSource Repository
Transfer Application Components
Maintain Query Jumps (RRI Interface)
Characteristic maintenance
Maintenance of key figures
Maintenance of units
Maintenance of time characteristics
DB connect
Start: InfoCube editing
Start: InfoCube editing
Start: InfoCube editing
Maintaining
Start: InfoObject catalog editing
Start: InfoObject catalog editing
Start: InfoObject catalog editing
DB Connect Test Program
Master Data Maintenance w.Prev. Sel.
Master Data Test
Initial Screen: MultiProvider Proc.
Initial Screen: MultiProvider Proc.
Initial Screen: MultiProvider Proc.
Customer Behavior Modeling
Initial Screen: ODS Object Processng
Data Source Repository
Load Exchange Rates from File
Manual Data Entry
Create InfoSource
Change InfoSource
Display InfoSource
Maintain InfoSets

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

RSKC
RSLGMP
RSMO
RSMON
RSOR
RSORBCT
RSORMDR
RSPC
RSPC1
RSPCM
RSRCACHE
RSRT
RSRT1
RSRT2
RSRTRACE
RSRTRACETEST
RSRV
SE03
SE06
SE07
SE09
SE10
SE11
SE18
SE18_OLD
SE19
SE19_OLD
SE21
SE24
SE80
RSCUSTA
RSCUSTA2
RSCUSTV*
RSSM
SM04
SM12
SM21
SM37
SM50
SM51
SM58
SM59

Maintaining the Permittd Extra Chars

Maintain RSLOGSYSMAP
Data Load Monitor Start
BW Administrator Workbench
BW Metadata Repository
BI Business Content Transfer
BW Metadata Repository
Process Chain Maintenance
Process Chain Display
Monitor daily process chains
OLAP: Cache Monitor
Start of the report monitor
Start of the Report Monitor
Start of the Report Monitor
Set trace configuration
Trace tool configuration
Analysis and Repair of BW Objects
Transport Organizer Tools
Set Up Transport Organizer
CTS Status Display
Transport Organizer
Transport Organizer
ABAP Dictionary
Business Add-Ins: Definitions
Business Add-Ins: Definitions (Old)
Business Add-Ins: Implementations
Business Add-Ins: Implementations
Package Builder
Class Builder
Object Navigator
Maintain BW Settings
ODS Settings
Authorizations for Reporting
User List
Display and Delete Locks
Online System Log Analysis
Overview of job selection
Work Process Overview
List of SAP Systems
Asynchronous RFC Error Log
RFC Destinations (Display/Maintain)

82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

LISTCUBE
List viewer for InfoCubes
LISTSCHEMA
Show InfoCube schema
WE02
Display IDoc
WE05
IDoc Lists
WE06
Active IDoc monitoring
WE07
IDoc statistics
WE08
Status File Interface
WE09
Search for IDoc in Database
WE10
Search for IDoc in Archive
WE11
Delete IDocs
WE12
Test Modified Inbound File
WE14
Test Outbound Processing
WE15
Test Outbound Processing from MC
WE16
Test Inbound File
WE17
Test Status File
WE18
Generate Status File
WE19
Test tool
WE20
Partner Profiles
WE21
Port definition
WE23
Verification of IDoc processing
DB02
Tables and Indexes Monitor
DB14
Display DBA Operation Logs
DB16
Display DB Check Results
DB20
Update DB Statistics
KEB2
DISPLAY DETAILED INFO ON CO-PA DATA SOURCE R3
RSD5
Edit InfoObjects
SM66
Global work process Monitor
SM12
Display and delete locks
OS06
Local Operating System Activity
RSKC Maintaining the Permittd Extra Chars
SMQ1 qRFC Monitor (Outbound Queue)