How to find in which Queries an infoobject is used

Is there a table which I can use to find in which queries a particular info-object is used ?


U can use two function modules

RSZ_I_BASIC_CHA_WHERE_USED

RSZ_I_BASIC_KEYFIG_WHERE_USED

First one for characteristics, second one for keyfigures.
For ur case (navigational attribute) use the first function module.

Goto se37, give the function module name, press F8,

In I_IOBJNM, give ur infoobject name,
In I_OBJVERS, give A (for Active version)
In I_QUERIES_ONLY put X
Press F8 (will take some time if ur infoobject has been used in more queries)

Now E_T_COMPLIST shows the number of queries ur infoobject has been used. Click on contents box next to it.
You ll find the queries in the COMPID field.

 

Difference between Lo & FI extraction

Difference between Lo & FI extraction

LO Extraction:

Lo extraction for the full load data is taken from SETUP tables to BW when we run Full loadAnd the deltas are from DeltaQueue

 

FI Extraction:

No setup tables for FI Extraction. Full upload in FI, data will be taken from R/3 tables And for deltas we need to initialize the delta process(Infopackage level,update tab) then it will create an entry in Delta queue(RSA7) in R3 by displaying Datasource technical name.

Once the datasource is initialized, it means that the Datasource is capable of accepting deltas from the next load. So for deltas the data will be taken from R3 tables and pass through RSA7.

 

0FI_GL_4, 0FI_AP_4, 0FI_AR_4 use an After Image Delta

Delta type “Extractor“:

·         Delta records are directly selected from the R/3 tables using a

timestamp mechanism.

·         Delta records are directly transferred to BW. No record is written to

the BW delta queue.

After Image Delta:

·         FI line items are transferred from the source system in their final

state (= “After Image“).

·         This delta method is not suitable for direct InfoCube update.

·         ODS object is obligatory to determine the delta for InfoCube update.

Where BW Delta Queue is used:

·         Delta queue and BW scheduler ensure correct serialization of the

records (e.g. inserts must not pass changes)

·         Distribution of delta records to multiple BW systems.

·         Selection criteria of Delta-Init upload are used to “couple” the

datasources logically.

All about SAP BI.... very nice Blog for BI

http://bisharath.blogspot.com/

Change Status of DTP Request

Scenario
Consider following situations
DTP load for DSO is running more than its due time i.e. (taking more time to load data) and hence stays in yellow state for a long time and you want to stop the load to the DSO by changing the status of the loading request from yellow to red manually, but you deleted the ongoing background job for the DTP load.
A master data load through DTP failed as the background job for DTP failed with a short dump and you want to start a new DTP load but you cannot as there is a message saying “The old request is still running”. You cannot change the status for the old request to red or green as there is message “QM-action not allowed for master data”. You cannot delete the old request due to the message “Request cannot be locked for delete”.
Solution
When old request in Scenario 1 & 2 is in yellow status and you are not able to change / delete the request, it’s actually in a pseudo status. This request sits in table RSBKREQUEST with processing type as 5 in data elements USTATE, TSTATE and this 5 is actually "Active" status which is obviously wrong.One of the possible solutions is to ask a basis person to change the status to 3 in both USTATE and TSTATE and then it allows reloading the data. Once the data is successfully loaded, you can delete the previous bad request even though it is still in yellow. Once the request is deleted, the request status gets updated as "4" in table RSBKREQUEST.
There is one more alternative solution, wherein you can manually change the status of the old request to red or green by using the function module RSBM_GUI_CHANGE_USTATE.
Following are the steps to change the QM Status of a yellow request to red/green by using RSBM_GUI_CHANGE_USTATE

Links for SAP BW/BI

ABAP program to find BI lookups and code Patterns
http://wiki.sdn.sap.com/wiki/display/BI/ABAP+program+to+find+BI+lookups+and+code+Patterns

How to Create a Good InfoCube

Try to limit the number of records in the dimension tables. Use the following guidelines:
1. If an InfoObject has almost as many distinct values as there are entries in the fact tables, the dimension this InfoObject belongs to should be defined as a line item dimension. If the dimension is defined in this manner, the system will write the data directly to the fact table instead of creating a dimension table that has almost as many entries as the fact table.
On the other hand, if there are several dimension tables with very few entries (for example, less than 10), these smaller dimensions should be combined into one dimension

2. Group related characteristics into one dimension only. Unrelated characteristics can use too much disk space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in 100,000,000 records).



3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.



4. Remove all "High-Cardinality" indicators from the InfoCube definition,generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries. When in doubt, do not set a dimension with high cardinality



5.Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.