BI Admin Cockpit (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)
Admin of InfoCubes
1. View data
2. Selective Deletion
. Performance (Indexes)
1. Delete Indexes,
2. Repair Indexes, and
3. Create Index (Batch)
• 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)
Virtual Providers - Types
Various VirtualProviders are available depending upon their use in
1. VirtualProviders based on Data Transfer Processes (Direct-access DTP).
2. VirtualProviders with BAPIs
3. VirtualProviders with function modules
 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
Other Virtual Providers
 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
 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
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.
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.
A remodeling rule is a collection of changes to your InfoCube that you perform simultaneously.
For InfoCubes, you have the following remodeling options:
1. You can add or replace characteristics with the following:
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.
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
– 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
– Reason: Delta Mechanism & Delta-Queue (1 DataSource per Client only)