SAP BW Interview Questions and Answers: 1

Q) I want to delete a BEx query that is in Production system through request. Is anyone aware about it?

A) Have you tried the RSZDELETE transaction?

Q) What are the five ASAP Methodologies?

A: Project plan, Business Blue print, Realization, Final preparation & Go-Live - support.

1. Project Preparation: In this phase, decision makers define clear project objectives and an efficient decision making process (i.e. Discussions with the client, like what are his needs and requirements etc.). Project managers will be involved in this phase (I guess). A Project Charter is issued and an implementation strategy is outlined in this phase.

2. Business Blueprint: It is a detailed documentation of your company's requirements. (i.e. what are the objects we need to develop are modified depending on the client's requirements).

3. Realization: In this only, the implementation of the project takes place (development of objects etc) and we are involved in the project from here only.

4. Final Preparation: Final preparation before going live i.e. testing, conducting pre-go-live, end user training etc. End user training is given that is in the client site you train them how to work with the new environment, as they are new to the technology.

5. Go-Live & support: The project has gone live and it is into production. The Project team will be supporting the end users.

Q) What is landscape of R/3 & what is landscape of BW. Landscape of R/3

A) Landscape of b/w: u have the development system, testing system, production system Development system: All the implementation part is done in this sys. (I.e., Analysis of objects developing, modification etc) and from here the objects are transported to the testing system, but before transporting an initial test known as Unit testing (testing of objects) is done in the development sys. Testing/Quality system: quality check is done in this system and integration testing is done.

Production system: All the extraction part takes place in this sys.

Q). Difference between infocube and ODS?

A: Infocube is structured as star schema (extended) where a fact table is surrounded by different dim table that are linked with DIM'ids. And the data wise, you will have aggregated data in the cubes. No overwrite functionality. ODS is a flat structure (flat table) with no star schema concept and which will have granular data (detailed level). Overwrite functionality.

Differeces Between DSO and InfoCube

Posted by SAP BI-BO on Thursday, September 23, 2010

The main difference in Reporting from Info cube and ODS/DSO is that InfoCube is meant for Multi-Dimensional reporting while ODS/DSO reporting is like 2 dimensional reporting.

There are many points which will clearly state that reporting from Info cube is far better than that from DSO.

Some major differences:

DSO
- Detailed form of data
- Flat file formate structure
- Two dimentional
- Performance is less as compared to cube
- Overwrite data functionality

InfoCube
- Summerised form of data
- Star schema
- 16 dimentional
- Additive data functionality
- Performance is better as compared to ods

InfoCube is prepared to visualize aggregation data and with the star schema relational tables, the data is accessed in better ways in terms of performance.

So if you use report in DSO performance is very slow compared to performance in InfoCubes.

Q) What is ODS?

Data Store Objects

Posted by SAP BI-BO on Tuesday, October 19, 2010

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.

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.

1. The Standard DataStore Object consists of three tables (activation queue, active data table, and change log). It is completely integrated in the staging process. In other words, data can be loaded into and out of the DataStore Objects during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.

Architecture and Functions of Standard DataStore Objects

Standard DataStore objects consist of three tables:

Active Data table

This is where the current status of the data is stored. This table contains a semantic (business-related) key that can be defined by the modeler (order number, item, or schedule line, for example). It is very important that the key be correctly defined by the modeler, as a match on the key initiates special delta processing during the activation phase (discussed later). Also, reporting via the BEx uses this table.

Change Log table

During the activation run, changes are stored in the change log. Here, you can find the complete history of the changes, since the content of the change log is not automatically deleted. The connected targets are updated from the change log if they are supplied with data from the DataStore object in the delta method. The change log is a PSA table and can also be maintained in the PSA tree of the Data Warehousing Workbench. The change log has a technical key consisting of a request, data package, and data record number.

Activation Queue table

During the DTP, the records are first written to this table. This step is necessary due to the complex logic that is then required by the activation process.