Day 8

SAP BW Training

System Administration Tasks

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

Challenges

Modelling parallelization

for optimal performance

Avoid lock

situations

Guarantee correct

sequence of

administration

processes

Avoid

unwanted

dependencies

Performance

Stability

Requirements Cost

5

BI Admin Cockpit (1)

6

Process Chains

7

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

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

Admin of InfoCubes

11

Requests

12

Compressing Cubes

13

Admin of DSO: Overview

14

Admin of DSO: Contents

15

Admin of DSO: Requests

16

Admin of DSO: Change-Log Deletion

In management for the DSO, choose Environment→ Delete Change Log Data.

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

Basic InfoCube vs. VirtualProvider

19

Infoproviders vs. Data Targets

20

Direct Access by Virtual-Provider

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

Direct Access by DTP

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

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

‘Re’- Modeling

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

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

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

DataSources Based on Flat Files

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

RDA – Real Time Data Acquisition

Analysis reporting (OLAP) vs. Operational reporting (OLTP)

32

RDA: Definition and Features

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

RDA Architecture

Thank You.