210 SAP BW (BI) NW 7.0 Interview Questions with Answers & Explanations – eBook
Sample SAP BI (BW) NW 7.0 Interview Questions with Answers
SAP BW interview questions can cover a very wide range.
Here is a sample of questions that a typical BW Consultant can be expected to face.
Q 1. What are the Key differences between an OLTP system and a Data Warehousing system?
Answer:
Level of detail: The OLTP layer stores data with a very high level of detail, whereas data in the Data Warehouse is compressed for high-performance access (aggregation).
History: Archiving data in the OLTP area means it is stored with minimal history. The Data Warehouse area requires comprehensive historical data.
Changeability: Frequent data changes are a feature of the operative area, while in the Data Warehouse, the data is frozen after a certain point for analysis.
Integration: In contrast to the OLTP environment, requests for comprehensive, integrated information for analysis isare very high.
Normalization: Due to the reduction in data redundancy, normalization is very high for operative use. Data staging and lower performance are the reasons why there is less normalization in the Data Warehouse.
Read access: An OLAP environment is optimized for read access. Operative applications (and users ) also need to carry out additional functions regularly, including change, insert, and delete.
Q 2. List the differences between BW 3.5 and BI 7.0 versions.
Answer:
SAP BW 7.0 is called SAP BI and is one of the components of SAP NetWeave. Some of the major differences are:
1. No Update rules or Transfer rules (Not mandatory in data flow)
2. Instead of update rules and Transfer rules new concept introduced called transformations.
3. New ODS introduced in additional to the Standard and transactional.
4. ODS is renamed as DataStore to meet with the global data warehousing standards.
5. In Infosets now you can include Infocubes as well.
6. The Re-Modeling transaction helps you add new key figures and characteristics and handle historical data as well. This facility is available only for info cube.
7. 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.
8. The monitoring has been improved with a new portal based cockpit.
9. Search functionality has improved!! You can search any object. Not like 3.5
10. transformation replaces the transfer and update rules.
11. Remodeling of InfoProviders supports you in Information Lifecycle Management.
12. Push of XML data into BI system (into PSA) without Service API or Delta Queue 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:
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.
17. User management (includes new concept for analysis authorizations) for more flexible BI end user authorizations.
Q 3. What is the responsibilities & tasks of a BW Technical person vs a BW Functional person?
Answer:
Although the definitions vary from case to case, In general the Functional consultant, derives the functional specification from the business requirement document. This job is normally done either by the business analyst or system analyst who has a very good knowledge of the business.
In some large organizations/projects there is a business analyst as well as a system analyst.
In case of new business requirements or request for new reports or queries, the requirements are discussed with the business by the business/system analyst. These refined requirements are then used to generate the functional specification document. In the case of BW it could be the logical design in DATA MODELING.
After further review, this logical design is translated to physical design . The physical design results in the definition of the required dimensions, key figures, master data, etc.
Once this process is approved and signed off by the requester(users), conversion of this into practically usable tasks using the SAP BW software is done.
This is the technical person’s job. The whole process of creating an InfoProvider, InfoObjects, InforSources, Source system, etc falls under the Technical domain
Q 4. What do you understand by system landscape? What kind of landscapes are possible with SAP Netweaver?
Answer:
A landscape is a logical grouping of systems. The grouping of landscape can be horizontal or vertical.
Horizontal landscapes comprise of two or more SAP systems (system IDs – SIDs) that support “promote to production” of software for a particular piece or set of functionality – for example, the development, quality assurance and productive systems for the BI functionality is the “BI landscape”.
Vertical landscapes comprise of the systems in a particular area of the landscape – for example, all of the systems that run productive services are the “production landscape”.
SAP NETWEAVER BASED SYSTEM LANDSCAPE DEPLOYMENT OPTIONS
As with any software implementation, and SAP NetWeaver based systems are no different in this case, the ideal software landscape to support the implementation is comprised of environments supporting three distinct needs that provide a solid ‘promote to production’ change management and change control process for all configuration and developments.
These environments should provide:
An environment where customizing and development can be performed. The environment should be representative of the productive environment and contain all product production customizing, developments and a sampling of production data. In addition new projects’ developments, customizing and data will exist in the system and this environment will be used for unit testing. This environment is used for as the initial environment for resolution of production issues and routine maintenance support.
An isolated and stable environment for testing the customizing, developments, and maintenance support changes. The environment is representative of the productive environment and contains all product customizing, developments and in most cases production quality data. In addition this environment will also have newly completed customizing/developments that are in quality testing phase prior to productive release. The typical testing that occurs in this environment is regression and integration testing. No development tasks are performed in this environment, just quality assurance tasks. This environment may also be used for replicating and debugging productive issues.
An isolated and stable production environment. The environment is the system of record and only contains productive customizing and developments. No development tasks are performed in this environment, just productive tasks. This environment may additionally be used for debugging productive issues.
This ‘promote to production’ scenario is recommended when implementing any system based on SAP NetWeaver.
This is typically called a “Three System Landscape” with 1 Production system (PRD), 1 Quality Assurance system (QAS), and 1 Development System (DEV).
Many customers supplement a three system landscape with a fourth environment: A standalone sandbox environment used for destructive testing, learning, and testing. The landscape is still called a three system landscape as the sandbox is not part of the ‘promote to production’ landscape.
A customer can choose to combine the above environments in a more minimal 2 system landscape – this landscape is not typical for SAP deployments and the customer must manage the additional risk and challenges of separating and isolating the different environment activities from each other and maintaining a stable and productive environment.
Furthermore customers can choose to extend the three system landscape to become a 4 system landscape. This can be appropriate for customers who have:
– Extensive distributed and parallel development teams, or
– If the customer has the need to separate the quality assurance processes into two distinct environments.
These can result in the following additions to the ‘Three System Landscape’ to create a ‘4 system landscape’:
– Additional Development system: An additional consolidation system is inserted into the landscape to consolidate distributed developments and customizing.
– Addition of an additional quality environment into the landscape and assigning specific testing needs to each of the quality environments (typically it is seen that one system performs Application and performance testing and the second is used for integration, user acceptance and regression testing).
Development System (DEV)
All customizing and development work is performed in this system. All system maintenance including break-fixes for productive processes is also performed in the system. After all the changes have been unit tested, these changes can be transferred to the quality assurance system (QAS) for further system testing.
The customizing, development and production break-fix changes are promoted to the QAS system using the change management system. This ensures consistency, management, tracking and audit capabilities thus minimizing risk and human error by eliminating manual repetition of development and customizing work in each system.
Quality Assurance System (QAS)
After unit testing the customizing, development and break-fix changes in the development system (DEV), the changes are promoted to the quality assurance system (QAS). Here, the configuration, development or changes undergo further tests and checks to ensure that they do not adversely affect other modules.
When the configuration, development or changes have been thoroughly tested in this system and signed off by the quality assurance team, it can be promoted to the production system (PRD).
Production System (PRD)
A company uses the production system (PRD) for its live, productive work. This system— containing the company’s live data—is where the real business processes are executed. The other systems in the landscape provide a safe approach to guaranteeing that only correct and tested (that is not defective) new developments and/or customizing configurations get deployed into the productive system. Additionally they ensure that changes to productive developments and configuration by either project enhancements or maintenance do not adversely affect the production environment when deployed. Therefore the quality of the DEV and QAS system and the implemented change management processes directly impacts the quality of the production system.
Q 5. We have frequent load failures during extractions? How are you going to analyse them?
Answer:
Loads can fail due to various reasons, some of which are transient and others have to be addressed specifically.
Some of the common failure reasons are:
– Data inconsistency in the source system. You can monitor these issues in T-code -> RSMO and PSA (failed records).
– Issues of work process scheduling and IDoc transfer to target system from source system. These issues can be re-initiated by canceling that specific data load and ( usually by changing Request color from Yellow – > Red in RSMO).. and restarting the extraction.
– Invalid characters in the Source System
– Deadlock in the system
– Previous load failure , if the load is dependent on other loads
– Erroneous records
– Issues around RFC connections
Q 6. Can you give some business scenarios wherein you have used the standard Datastore Object?
The diagram below shows how standard DataStore objects are used in this example of updating order and delivery information, and the status tracking of orders, meaning which orders are open, which are partially-delivered, and so on.
There are three main steps to the entire data process:
1. Loading the data into the BI system and storing it in the PSA.
The data requested by the BI system is stored initially in the PSA. A PSA is created for each DataSource and each source system. The PSA is the storage location for incoming data in the BI system. Requested data is saved, unchanged, to the source system.
2. Processing and storing the data in DataSource objects
In the second step, the DataSource objects are used on two different levels.
a. On level one, the data from multiple source systems is stored in DataSource objects. Transformation rules permit you to store the consolidated and cleansed data in the technical format of the BI system. On level one, the data is stored on the document level (for example, orders and deliveries) and constitutes the consolidated database for further processing in the BI system. Data analysis is therefore not usually performed on the DataSource objects at this level.
b. On level two, transfer rules subsequently combine the data from several DataStore objects into a single DataStore object in accordance with business-related criteria. The data is very detailed, for example, information such as the delivery quantity, the delivery delay in days, and the order status, are calculated and stored per order item. Level 2 is used specifically for operative analysis issues, for example, which orders are still open from the last week. Unlike multidimensional analysis, where very large quantities of data are selected, here data is displayed and analyzed selectively.
3. Storing data in the InfoCube
In the final step, the data is aggregated from the DataStore object on level two into an InfoCube. The InfoCube does not contain the order number, but saves the data, for example, on the levels of customer, product, and month. Multidimensional analysis is also performed on this data using a BEx query. You can still display the detailed document data from the DataStore object whenever you need to. Use the report/report interface from a BEx query. This allows you to analyze the aggregated data from the InfoCube and to target the specific level of detail you want to access in the data.
Here are some more questions (without answers) on ‘BW Modelling’
Q. Aggregates improve query performance. Give some examples where you felt the need to create aggregates.
Q. When might you consider putting two un-related characteristics in a single dimension table?
Q. We have a dimension with potentially million of records. We are planning to use ‘Category Dimension’. Can you explain how this works?
Q. What step by step approach would you recommend while designing an InfoCube? What are the key factors that need to be kept in mind?
Q. What kind of factors would you consider before deciding whether to use BI Accelerator or a BI Aggregate?
Q. What is table partitioning? How does it improve performance? What are the prerequisites?
Q. We have existing live cubes, but due to new requirements, we need to add
1. Adding a navigation attribute or a hierarchy
2. Adding a characteristic
3. Adding a key figure
4. Changing the dimension tables
What are the steps to be taken for each of these?
Q. What do you know about RDA (Real Time Data Acquisition)? What are the methods of transferring data to the BI system with RDA?
Q. The concept of “requests” is important in BI. What purpose do ‘request’ ids serve? How is this concept relevant for ‘compression’?
Q. What is ‘BI statistics’? How does it help with Query performance Optimization?
Q. What are the two main transfer methods? What are their advantages? Which one is commonly used?
Q. What is an expert routine? Can you provide a business scenario where the expert routine may be used?
Q. When would you use a Virtual provider based on DTP?
Q. What are some of the benefits of ‘Queued Delta’?
Q. Your company wants to analyze the purchase requisitions created in the SAP OLTP system in BI. The required reports are also to be supported using the old material number that was transferred from the legacy system to the material master in the SAP OLTP system. Language dependent texts are also required. How will you model this?
Q. The record mode concept deals with the question of how changes to data records are recorded in the delta process. What are the possible values of record mode and what do they indicate?
Q. If the datasource does not support ‘delta’, you might look at using pseudo delta. What is pseudo delta? What are the problems with using it? How can these problems be overcome?
Q. Your company would like to establish a direct open connection to your Microsoft Access database. How can this be done?
Get More Interview Questions & Answers to the questions above!
Click on the link below to find out more.
210 SAP BW (BI) NW 7.0 Interview Questions with Answers & Explanations – eBook
