1. Day 8
SAP BW Training

2. System Administration Tasks

3. 3
Purpose
Daily and periodic tasks needed to maintain the data warehouse
List the tools available for administration of the warehouse
System Administrator's job

4. 4
Challenges
Modelling parallelization
for optimal performance
Avoid lock
situations
Guarantee correct
sequence of
administration
processes
Avoid
unwanted
dependencies
Performance
Stability
Requirements Cost

5. 5
BI Admin Cockpit (1)

6. 6
Process Chains

7. 7

8. 8
BI Admin Cockpit (2)
1.
2.
3. Change Run (updates)
4. Broadcasting (mailing lists)
5. Analysis Authorization (RSECADMIN)
6. Meta-Data Search and Documents (RSODADMIN)
7. Remodeling (RSMRT)
8. Repartitioning (table-level partitioning)
9. Request Administration Archiving (archive old request)
10.Analysis of BI Objects (RSRV)
11.Current Settings (Standard Config. Tasks)

9. 9
Admin of InfoCubes
. Contents
1. View data
2. Selective Deletion
. Performance (Indexes)
1. Delete Indexes,
2. Repair Indexes, and
3. Create Index (Batch)
. Requests
• Request ID # and Status [Green/Yellow/Red]
. Roll-Up (Aggregate-it for baby-infocubes)
. Compress (zip the data)
. Reconstruct ( Only valid with 3.x data flow objects)

10. 10
Admin of InfoCubes

11. 11
Requests

12. 12
Compressing Cubes

13. 13
Admin of DSO: Overview

14. 14
Admin of DSO: Contents

15. 15
Admin of DSO: Requests

16. 16
Admin of DSO: Change-Log Deletion
In management for the DSO, choose Environment→ Delete Change Log Data.

17. 17
Virtual Provider
VirtualProviders are InfoProviders with
transaction/master data that is not stored in the object
itself, but which is read directly in reporting.

18. 18
Basic InfoCube vs. VirtualProvider

19. 19
Infoproviders vs. Data Targets

20. 20
Direct Access by Virtual-Provider

21. 21
Virtual Providers - Types
Various VirtualProviders are available depending upon their use in
these different
scenarios:
1. VirtualProviders based on Data Transfer Processes (Direct-access DTP).
2. VirtualProviders with BAPIs
3. VirtualProviders with function modules

22. 22
Direct Access by DTP

23. 23
[1] Direct Access – Virtual Providers
Use this VirtualProvider if:
 You need very up-to-date data from an SAP source system
 You only access a small amount of data from time to time
 Only a few users execute queries simultaneously on the database
Do not use this VirtualProvider if:
 You request a large amount of data in the first query navigation step, and no
 appropriate aggregates are available in the source system
 A lot of users execute queries simultaneously
 You frequently access the same data

24. 24
Other Virtual Providers
[2] The BAPI-based option allows reporting using data from non-SAP systems.
The external system transfers the requested data to the OLAP processor via the
BAPI.
[3] The function-module-based VirtualProvider supplies a clean interface to
allow your custom code to be the source data.
• It is a very flexible way to populate a VirtualProvider,
• but it is also more work, as you own code must be created.
– One example of the use of these function-module-filled providers is in Business
Consolidation.

25. 25
‘Re’- Modeling

26. 26
Options for changing the data model of an InfoCube
There are different options for changing a data model of an InfoCube:
1. Adding a navigation attribute or a hierarchy
2. Adding a characteristic
3. Adding a key figure
4. Changing the dimension tables
Concern 1: If you want to include a navigation attribute in your data model, you can
activate an existing display attribute in a characteristic from a navigation attribute. If the
required attribute is not available, you can include it in the attribute table; however, you
must then load the relevant master data of the characteristic.
Concern 2 & 3: If you also want to enrich your historical data with the new information,
you must delete the data in your InfoCube, insert the new InfoObject and reload the data.
You must also add the new information, that is, integrate it in the data flow.
Concern 4: In this case, you must first delete the data in your InfoCube; you can then
rebuild the dimension tables and load the data again.

27. 27
Prerequisites
Before you start remodeling, we recommend that you backup data for security.
In addition, ensure the following:
1. You must stop process chains that run at regular intervals and affect the relevant
InfoProvider until the remodeling is complete.
2. There must be sufficient tablespace on the database.
3. After remodeling, you must check which BI objects linked to the InfoProvider were
deactivated (for example, transformation rules, MultiProviders, queries). You must
manually reactivate these.
Caution: During the remodeling process, the InfoCube is locked against loading and
changes. All dependent objects are deactivated and must be reactivated manually
afterwards. Aggregates and BI accelerator indexes must be reconstructed. The valid
authorization objects are the same as those for maintaining InfoCubes.

28. 28
Features
A remodeling rule is a collection of changes to your InfoCube that you perform simultaneously.
For InfoCubes, you have the following remodeling options:
For characteristics:
1. You can add or replace characteristics with the following:
 A Constant
 An attribute of an InfoObject of the same dimension
 A value of another InfoObject of the same dimension
 A customer exit (for user-specific source code)
2. You can delete characteristics.
For key figures:
 You can add a constant.
 You can add a customer exit (for user-specific source code).
 You can replace key figures using a customer exit (for user-specific source code).
 You can delete key figures.
Note: It is not yet possible to remodel InfoObjects and DataStore objects. This function is
planned for future releases.

29. 29
DataSources Based on Flat Files

30. 30
DataSources Based on Flat Files
Object that contains all the settings necessary to load and parse a file when it is
initiated by the InfoPackage:

31. 31
RDA – Real Time Data Acquisition
Analysis reporting (OLAP) vs. Operational reporting (OLTP)

32. 32
RDA: Definition and Features

33. 33
RDA Implementation
Data can be transferred from the source to the entry layer in BI (the PSA) in two ways:
1. Using a Web Service push:
– A Web service push can write the data directly from the source to the PSA.
– The data transfer is not controlled by BI.
– An InfoPackage (for full upload) is required only to specify request-related settings
for RDA;
– it is never executed, as the data is pushed into the BI PSA by a Web service.
2. Using the BI Service API:
– If the source data is based on a source in an SAP source system, the BI Service
API is used.
– Many of the steps are the same as with normal delta extractions, such as the
requirement for an InfoPackage to initialize delta. This step allows for delta loads
to occur in the future.
• DataSources used for RDA cannot be used for standard extraction (scheduling using InfoPackages).
– DataSource can have one extraction mechanism only (RDA or scheduled data
transfer).
– Reason: Delta Mechanism & Delta-Queue (1 DataSource per Client only)

34. 34
RDA Architecture

35. Thank You.