SAP BW/BI Interview Questions and Answers - 3

20) How do we decide what cubes has to be created? Its depends on your project requirement. Customized cubes are not mandatory for all the projects. If your bussines requirement is differs from given scenario ( BI content cubes ) then only we will opt for customized cubes.Normally your BW customization or creation of new info providers all are depending on your source system.If your source system other that R3 then you should go with customization of your all objects.If your source system is R3 and your users are using only R3 standard business scenarios like SD,MM or FI... etc., then you dont want to create any info providers or you dont want to enhance any thing in the existing BW Business Content. But 99% this is not possible. Because surely they should have included their new business scenario or new enhancements.For example, In my first project we implemented for Solution Manager BW implemention. There we have activated all the business content in CRM. But the source system have new scenarios for message escalation, ageing calculation etc., According their business scenrio we could't use standard business content. For that we have taken only existing info objects and created new info objects which are not there in the business content. After that we have created custom data source to info providers as well asreports.

 21) Who used to make the Technical and Functional Specifications? Technical Specification:Here we will mention all the BW objects (info objects, data sources, info sources and info providers). Then we are going to say the data flow and behaviour of the data load (either delta or full) also we can tell the duration of the cube activation or creation. Pure BW technical things are available in this document. This is not for End users document.Functional Specification:Here we will describe the business requirements. That means here we are going to say which are all business we are implementing like SD, MM and FI etc., then we are going to tell the KPI and deliverable reports detail to the users. This document is going to mingle with both Function Consultants and Business Users. This document is applicable for end users also.

22) Give me one example of a Functional Specification and explain what information we will get from that? Functional Specs are requirements of the business user.Technical Specs translate these requirements in a technical fashion.Let's say Functional Spec says,1. the user should be able to enter the Key date, Fiscal Year, Fiscal Version.2. The Company variable should be defaulted to USA but then if the user wants to change it, they can check the drop down list and choose other countries.3. The calculations or formulas for the report will be displayed in precision of one decimal point.4. The report should return values for 12 months of data depending on the fiscal year that the user enters Or it should display in quarterly values. Functional specs are also called as Software requirements.Now from this Techinal Spec follows, to resolve each of the line items listed above.1. To give the option of key date, Fiscal year and Fiscal Version – certain Info Obejcts should be availble in the system. If available, then should we create any variables for them - so that they are used as user entry variable. To create any varaibles, what is the approch, where do you do it, what is the technical of the objects you'll use, what'll be the technical name of the objects you'll crete as a result of this report.2. Same explanation goes for the rest. How do you set up the varaible, 3. What changes in properties willu do to get the precision.4. How will you get the 12 months of data.What will be the technical and display name of the report, who'll be authorized to run this report, etc are clearly specified in the technical specs.

23) What is Customization? How do we do in LO? How to do basic LO extraction for SAP-R3-BW1. Go to transaction code RSA3 and see if any data is available related to your DataSource. If data is there in RSA3 then go to transaction code LBWG (Delete Setup data) and delete the data by entering the application name.2. Go to transaction SBIW --> Settings for Application Specific Datasource --> Logistics --> Managing extract structures --> Initialization --> Filling the Setup table --> Application specific setup of statistical data --> perform setup (relevant application)3. In OLI*** (for example OLI7BW for Statistical setup for old documents : Orders) give the name

of the run and execute. Now all the available records from R/3 will be loaded to setup tables.4. Go to transaction RSA3 and check the data.5. Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.6. Go to BW system and create infopackage and under the update tab select the initialize delta process. And schedule the package. Now all the data available in the setup tables are now loaded into the data target.7.Now for the delta records go to LBWE in R/3 and change the update mode for the corresponding DataSource to Direct/Queue delta. By doing this record will bypass SM13 and directly go to RSA7. Go to transaction code RSA7 there you can see green light # Once the new records are added immediately you can see the record in RSA7.

 24) When we use Maintain Data Source, What we do? What we will maintain? Go to BW system and create a new infopackage for delta loads. Double click on new infopackage. Under update tab you can see the delta update radio button

 25) Tickets and Authorization in SAP Business Warehouse What is tickets? And example? Tickets are the tracking tool by which the user will track the work which we do. It can be a change requests or data loads or what ever. They will of types critical or moderate. Critical can be (Need to solve in 1 day or half a day) depends on the client. After solving the ticket will be closed by informing the client that the issue is solved. Tickets are raised at the time of support project these may be any issues, problems.... .etc. If the support person faces any issues then he will ask/request to operator to raise a ticket. Operator will raise a ticket and assign it to the respective person. Critical means it is most complicated issues ....depends how you measure this...hope it helps. The concept of Ticket varies from contract to contract in between companies. Generally Ticket raised by the client can be considered based on the priority. Like High Priority, Low priority and so on. If a ticket is of high priority it has to be resolved ASAP. If the ticket is of low> priority it must be considered only after attending to high priority tickets. The typical tickets in a production Support work could be: 1. Loading any of the missing master data attributes/texts. 2. Create ADHOC hierarchies. 3. Validating the data in Cubes/ODS. 4. If any of the loads runs into errors then resolve it. 5. Add/remove fields in any of the master data/ODS/Cube. 6. Data source Enhancement. 7. Create ADHOC reports. 1. Loading any of the missing master data attributes/texts - This would be done by scheduling the infopackages for the attributes/texts mentioned by the client. 2. Create ADHOC hierarchies. - Create hierarchies in RSA1 for the info-object. 3. Validating the data in Cubes/ODS. - By using the Validation reports or by comparing BW data with R/3. 4. If any of the loads runs into errors then resolve it. - Analyze the error and take suitable action. 5. Add/remove fields in any of the master data/ODS/Cube. - Depends upon the requirement 6. Data source Enhancement. 7. Create ADHOC reports. - Create some new reports based on the requirement of client. 26) Change attribute run. Generally attribute change run is used when there is any change in the master data..it is used for realingment of the master data..Attribute change run is nothing but adjusting the master data after its been loaded from time to time so that it can change or generate or adjust the sid's so that u may not have any problem when loading the trasaction data in to data targets.the detail explanation about Attribute change run.The hierarchy/attribute change run which activates hierarchy and attribute changes and adjusts the corresponding aggregates is devided, into 4 phases:1. Finding all affected aggregates2. set up all affected aggregates again and write the result in the new aggregate table.3. Activating attributes and hierarchies4. rename the new aggregate table. When renaming, it is not possible to execute queries. In some databases, which cannot rename the indexes, the indexes are also created in this phase.

27) Different types of Delta updates? Delta loads will bring any new or changed records after the last upload.This method is used for better loading in less time. Most of the std SAP data sources come as delta enabled, but some are not. In this case you can do a full load to the ODS and then do a delta from the ODS to the cube. If you create generic datasources, then you have the option of creating a

delta onCalday, timestamp or numeric pointer fields (this can be doc number, etc).You'll be able to see the delta changes coming in the delta queue through RSA7 on the R3 side.To do a delta, you first have to initialize the delta on the BW side and then set up the delta.The delta mechanism is the same for both Master data and Transaction data loads.============ ========= ==There are three deltasDirect Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 deltaextractions of documents for an LUW are compressed for each Data Source into the BW delta queue, depending on the application.Non-serialized V3 Update: With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.