SAP BW interview questions

 

SAP BW 3.5 Vs  SAP BI 7.0

1. In Infosets now you can include Infocubes as well.

2. The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only for info cube.

3. The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 - 100. This BI accl is a separate box and would cost more. Vendors for these would be HP or IBM.

4. The monitoring has been imprvoed with a new portal based cockpit. Which means you would need to have an EP guy in ur project for implementing the portal ! :)

5. Search functionality hass improved!! You can search any object. Not like 3.5

6. Transformations are in and routines are passe! Yess, you can always revert to the old transactions too.

7. The Data Warehousing Workbench replaces the Administrator Workbench.

8. Functional enhancements have been made for the DataStore object:
New type of DataStore object
Enhanced settings for performance optimization of DataStore objects.

9. The transformation replaces the transfer and update rules.

10. New authorization objects have been added

11. Remodeling of InfoProviders supports you in Information
Lifecycle Management.

12 The Data Source:
There is a new object concept for the Data Source.
Options for direct access to data have been enhanced.
From BI, remote activation of Data Sources is possible in SAP source systems.

13.There are functional changes to the Persistent Staging Area (PSA).

14.BI supports real-time data acquisition.

15 SAP BW is now known formally as BI (part of NetWeaver 2004s). It implements the Enterprise Data Warehousing (EDW). The new features/ Major differences include:
a) Renamed ODS as DataStore.
b) Inclusion of Write-optmized DataStore which does not have any change log and the requests do need any activation
c) Unification of Transfer and Update rules
d) Introduction of "end routine" and "Expert Routine"
e) Push of XML data into BI system (into PSA) without Service API or Delta Queue
f) Intoduction of BI accelerator that significantly improves the performance.
g) Load through PSA has become a must. I am not too sure about this. It looks like we would not have the option to bypass the PSA Yes,

16. Load through PSA has become a mandatory. You can't skip this, and also there is no IDoc transfer method in BI 7.0. DTP (Data Transfer Process) replaced the Transfer and Update rules. Also in the Transformation now we can do "Start Routine, Expert Routine and End Routine". during data load.

New features in BI 7 compared to earlier versions:

i. New data flow capabilities such as Data Transfer Process (DTP), Real time data Acquisition (RDA).

ii. Enhanced and Graphical transformation capabilities such as Drag and Relate options.

iii. One level of Transformation. This replaces the Transfer Rules and Update Rules

iv. Performance optimization includes new BI Accelerator feature.

v. User management (includes new concept for analysis authorizations) for more flexible BI end user authorizations.

13A  Responsibilities of an implementation project... For ex, Lets say If its a fresh implementation of BI or for that matter you are implementing SAP...

First and foremost will be your requirements gathering from the client. Depending upon the requirements you will creat a business blueprint of the project which is the entire process from the start to the end of an implementation...

After the blue print phase sign off we start off with the realization phase where the actual development happens... In our example after installing the necessary softwares, patches for BI we need to discuss with the end users who are going to use the system for inputs like how they want a report to look like and what are the Key Performance Indicators(KPI) for the reports etc., basically its a question and answer session with the business users... After collecting those informations the development happens in the development servers...

After the development comes to an end the same objects are tested in quality servers for any bugs, errors etc., When all the tests are done we move all the objects to the production environment and test it again whether everything works fine...

The Go-Live of the project happens where the actually postings happen from the users and reports are generated based on those inputs which will be available as an analytical report for the management to take decisions...

The responsibilites vary depending on the requirement... Initially the business analyst will interact with the end users/managers etc., then on the requirements the software consultants do the development, testers do the testing and finally the go-live happens...

What are the objects that we peform in a production Support project?

In production Suport Generally most of the project they will work on monitoring area for their loads(R3/ NON SAP to Data Taggets (BW)) and depending up the project to project it varies because some of them using the PC's and Some of them using Event Chains. So its Depends up on the Project to project varies.

What are the different transactions that we use frequently in Production support project? Plz explain them in detial.. Generally In Production Support Project , we will use the check the loads by using RSMO for Monitoring the loads and we will rectify the errors in that by using step by step analysis.

The consultant is required to have access to the following transactions in R3.

1. ST22
2. SM37
3. SM58
4. SM51
5. RSA7
6. SM13

Authorizations for the following transactions are required in BW

1. RSA1
2. SM37
3. ST22
4. ST04
5. SE38
6. SE37
7. SM12
8. RSKC
9. SM51
10. RSRV

The Process Chain Maintenance (transaction RSPC) is used to define, change and view process chains.

Upload Monitor (transaction RSMO or RSRQ (if the request is known)

The Workload Monitor (transaction ST03) shows important overall key performance indicators (KPIs) for the system performance

The OS Monitor (transaction ST06) gives you an overview on the current CPU, memory, I/O and network load on an application server instance.

The database monitor (transaction ST04) checks important performance indicators in the database, such as database size, database buffer quality and database indices.

The SQL trace (transaction ST05) records all activities on the database and enables you to check long runtimes on a DB table or several similar accesses to the same data.

The ABAP runtime analysis (transaction SE30)

The Cache Monitor (accessible with transaction RSRCACHE or from RSRT) shows among other things the cache size and the currently cached queries. The Export/Import Shared buffer determines the cache size; it should be at least 40MB.