A) Initially we don't delete the setup tables but when we do change in extract structure we go for it. We are changing the extract structure right, that means there are some newly added fields in that which r not before. So to get the required data (i.e.; the data which is required is taken and to avoid redundancy) we delete and then fill the setup tables.
To refresh the statistical data. The extraction set up reads the dataset that you want to process such as, customers orders with the tables like VBAK, VBAP) & fills the relevant communication structure with the data. The data is stored in cluster tables from where it is read when the initialization is run. It is important that during initialization phase, no one generates or modifies application data, at least until the tables can be set up.
Q) What is significance of ODS?
It holds granular data (detailed level).
Q) Infoset Query.
Can be made of ODS's and Characteristic InfoObjects with masterdata.
Q) Routines?
Exist in the InfoObject, transfer routines, update routines and start routine.
Q) What are the different variables used in BEX?
Different Variables are Texts, Formulas, Hierarchies, Hierarchy nodes & Characteristic values.
Variable Types are:
- Manual entry /default value
- Replacement path
- SAP exit
- Customer exit
- Authorization
Q) How many levels you can go in reporting?
You can drill down to any level by using Navigational attributes and jump targets.
Q) What types of partitioning are there for BW?
There are two Partitioning Performance aspects for BW (Cube & PSA)
a) Query Data Retrieval Performance
Improvement:
Partitioning by (say) Date Range
improves data retrieval by making best use of database [data range] execution
plans and indexes (of say Oracle database engine).
b) Transactional Load Partitioning
Improvement:
Partitioning based on expected
load volumes and data element sizes. Improves data loading into PSA and
Cubes by infopackages (E.g. without timeouts).
Q) How can I compare data in R/3 with data in a BW Cube after the daily delta loads? Are there any standard procedures for checking them or matching the number of records?
A) You can go to R/3 TCode RSA3 and run the extractor. It will give you the number of records extracted. Then go to BW Monitor to check the number of records in the PSA and check to see if it is the same & also in the monitor header tab.
A) RSA3 is a simple extractor checker program that allows you to rule out extracts problems in R/3. It is simple to use, but only really tells you if the extractor works. Since records that get updated into Cubes/ODS structures are controlled by Update Rules, you will not be able to determine what is in the Cube compared to what is in the R/3 environment. You will need to compare records on a 1:1 basis against records in R/3 transactions for the functional area in question. I would recommend enlisting the help of the end user community to assist since they presumably know the data.
To use RSA3, go to it and enter the extractor ex: 2LIS_02_HDR. Click execute and you will see the record count, you can also go to display that data. You are not modifying anything so what you do in RSA3 has no effect on data quality afterwards. However, it will not tell you how many records should be expected in BW for a given load. You have that information in the monitor RSMO during and after data loads. From RSMO for a given load you can determine how many records were passed through the transfer rules from R/3, how many targets were updated, and how many records passed through the Update Rules. It also gives you error messages from the PSA.
Q) Types of Transfer Rules?
A) Field to Field mapping, Constant, Variable & routine.
Q) Types of Update Rules?
A) (Check box), Return table.
Q) Transfer Routine?
A) Routines, which we write in, transfer rules.
Q) Update Routine?
A) Routines, which we write in Update rules.
Q) What is the difference between writing a routine in transfer rules and writing a routine in update rules?
A) If you are using the same InfoSource to update data in more than one data target its better u write in transfer rules because u can assign one InfoSource to more than one data target & and whatever logic you write in update rules it is specific to particular one data target.
