SAP BI QUESTIONS & ANSWERS-4

SAP BI QUESTIONS & ANSWERS-4 :-


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 what ever logic u write in update rules it is specific to particular one data target.

Q) Routine with Return Table.
A) Update rules generally only have one return value.However, you can create a routine in the tab strip key figure calculation, by choosing checkbox Return table. The corresponding key figure routine then no longer has a return value, but a return table. You can then generate as many key figure values, as you like from one data record.

Q) Start routines ?
A) Start routines u can write in both updates rules and transfer rules, suppose you want to restrict (delete) some records based on conditions before getting loaded into data targets, then you can specify this in update rules-start routine.
Ex: - Delete Data_Package ani ante it will delete a record based on the condition

Q) X & Y Tables ?
X-table = A table to link material SIDs with SIDs for time-independent navigation attributes.
Y-table = A table to link material SIDs with SIDS for time-dependent navigation attributes.
There are four types of sid tables
X time independent navigational attributes sid tables
Y time dependent navigational attributes sid tables
H hierarchy sid tables
I hierarchy structure sid tables

Q) Filters & Restricted Key figures (real time example)
A) Restricted KF's u can have for an SD cube: billed quantity, billing value, no: of billing documents as RKF's.

Q) Line-Item Dimension (give me an real time example)
A) Line-Item Dimension: Invoice no: or Doc no: is a real time example

Q) What does the number in the 'Total' column in Transaction RSA7 mean ?
A) The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repetition of a delta request) and the LUWs for the next delta request. A LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.

Q) How to know in which table (SAP BW) contains Technical Name / Description and creation data of a particular Reports. Reports that are created using BEx Analyzer.
A) There is no such table in BW if you want to know such details while you are opening a particular query press properties button you will come to know all the details that you wanted.You will find your information about technical names and description about queries in the following tables. Directory of all reports (Table RSRREPDIR) and Directory of the reporting component elements (Table RSZELTDIR) for workbooks and the connections to queries check Where- used list for reports in workbooks (Table RSRWORKBOOK) Titles of Excel Workbooks in InfoCatalog (Table RSRWBINDEXT)

Q) What is a LUW in the delta queue ?
A) A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor.

Q) Why does the number in the 'Total' column in the overview screen of Transaction RSA7 differ from the number of data records that is displayed when you call the detail view ?
A) The number on the overview screen corresponds to the total of LUWs (see also first question) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both, the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out.
Thus, only the records that are ready for the next delta request are displayed on the detail screen. In the detail screen of Transaction RSA7, a possibly existing customer exit is not taken into account.

Q) Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading ?
A) Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System.

Q) Why are selections not taken into account when the delta queue is filled ?
A) Filtering according to selections takes place when the system reads from the delta queue. This is necessary for reasons of performance.

Q) Why is there a DataSource with '0' records in RSA7 if delta exists and has also been loaded successfully ?
A) It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor (delta for master data using ALE change pointers). Such a DataSource should not be displayed in RSA7. This error is corrected with BW 2.0B Support Package 11.

Q) Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue ?
A) The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area and so on).
Caution: As of Plug In 2000.2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Please note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the DeltaQueue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.

Q) Why does it take so long to display the data in the delta queue (for example approximately 2 hours) ?
A) With Plug In 2001.1 the display was changed: the user has the option of defining the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition and so on.

Q) What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted ?
A) You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.  The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.