SAP BW Important Interview Questions Paper-

Part - 3
Q) AS WE USE Sbwnn, sbiw1, sbiw2 for delta update in LIS
THEN WHAT IS THE PROCEDURE IN LO-COCKPIT?
No LIS in LO cockpit. We will have datasources and can be maintained
(append fields). Refer white paper on LO-Cockpit extractions.

Q) Why we delete the setup tables (LBWG) & fill them

(OLI*BW)?

A) Initially we don't delete the setup tables but when we do change in

extract structure we go for it. We r 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 n 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) SIGNIFICANCE of ODS?
It holds granular data (detailed level).

Q) WHERE THE PSA DATA IS STORED?

In PSA table.

Q) WHAT IS DATA SIZE?

The volume of data one data target holds (in no. of records)

Q) Different types of INFOCUBES.

Basic, Virtual (remote, sap remote and multi)

Virtual Cube is used for example, if you consider railways reservation

all the information has to be updated online. For designing the Virtual
cube you have to write the function module that is linking to table,
Virtual cube it is like a the structure, when ever the table is updated
the virtual cube will fetch the data from table and display report
Online... FYI.. you will get the information :
https://www.sdn.sap.com/sdn /index.sdn and search for Designing
Virtual Cube and you will get a good material designing the Function
Module

Q) INFOSET QUERY.
Can be made of ODS's and Characteristic InfoObjects with masterdata.

Q) IF THERE ARE 2 DATASOURCES HOW MANY TRANSFER

STRUCTURES ARE THERE.
In R/3 or in BW? 2 in R/3 and 2 in BW

Q) ROUTINES?
Exist in the InfoObject, transfer routines, update routines and start
routine

Q) BRIEF SOME STRUCTURES USED IN BEX.

Rows and Columns, you can create structures.

Q) WHAT ARE THE DIFFERENT VARIABLES USED IN BEX?

Different Variable's 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 ARE INDEXES?

Indexes are data base indexes, which help in retrieving data fastly.

Q) DIFFERENCE BETWEEN 2.1 AND 3.X VERSIONS.

Help! Refer documentation

Q) IS IT NESSESARY TO INITIALIZE EACH TIME THE DELTA

UPDATE IS USED?
No.

Q) WHAT IS THE SIGNIFICANCE OF KPI'S?

KPI's indicate the performance of a company. These are key figures

Q) AFTER THE DATA EXTRACTION WHAT IS THE IMAGE

POSITION.
After image (correct me if I am wrong)
Q) REPORTING AND RESTRICTIONS.
Help! Refer documentation.

Q) TOOLS USED FOR PERFORMANCE TUNING.

ST22, Number ranges, delete indexes before load. Etc

Q) PROCESS CHAINS: IF U has USED IT THEN HOW WILL U

SCHEDULING DATA DAILY.
There should be some tool to run the job daily (SM37 jobs)

Q) AUTHORIZATIONS.
Profile generator

Q) WEB REPORTING.
What are you expecting??

Q) CAN CHARECTERSTIC INFOOBJECT CAN BE INFOPROVIDER.

Of course

Q) PROCEDURES OF REPORTING ON MULTICUBES

Refer help. What are you expecting? MultiCube works on Union
condition

Q) EXPLAIN TRANPSORTATION OF OBJECTS?

Dev---àQ and Dev-------àP
Q) What types of partitioning are there for BW?

There are two Partitioning Performance aspects for BW (Cube & PSA)
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 (Eg.
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 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)

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)

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?

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.

Q) Why does it take so long to delete from the delta queue (for
example half a day)?

A) Import PlugIn 2000.2 patch 3. With this patch the performance

during deletion is considerably improved.

Q) Why is the delta queue not updated when you start the V3
update in the logistics cockpit area?

A) It is most likely that a delta initialization had not yet run or that the
delta initialization was not successful. A successful delta initialization
(the corresponding request must have QM status 'green' in the BW
System) is a prerequisite for the application data being written in the
delta queue.

Q) What is the relationship between RSA7 and the qRFC

monitor (Transaction SMQ1)?
A) The qRFC monitor basically displays the same data as RSA7. The
internal queue name must be used for selection on the initial screen of
the qRFC monitor. This is made up of the prefix 'BW, the client and the
short name of the DataSource. For DataSources whose name are 19
characters long or shorter, the short name corresponds to the name of
the DataSource. For DataSources whose name is longer than 19
characters (for delta-capable DataSources only possible as of PlugIn
2001.1) the short name is assigned in table ROOSSHORTN.

In the qRFC monitor you cannot distinguish between repeatable and

new LUWs. Moreover, the data of a LUW is displayed in an
unstructured manner there.

Q) Why are the data in the delta queue although the V3 update
was not started?

A) Data was posted in background. Then, the records are updated

directly in the delta queue (RSA7). This happens in particular during
automatic goods receipt posting (MRRS). There is no duplicate transfer
of records to the BW system. See Note 417189.

Q) Why does button 'Repeatable' on the RSA7 data details

screen not only show data loaded into BW during the last delta
but also data that were newly added, i.e. 'pure' delta records?

A) Was programmed in a way that the request in repeat mode fetches

both actually repeatable (old) data and new data from the source
system.

Q) I loaded several delta inits with various selections. For

which one is the delta loaded?

A) For delta, all selections made via delta inits are summed up. This
means, a delta for the 'total' of all delta initializations is loaded.
Q) How many selections for delta inits are possible in the
system?

A) With simple selections (intervals without complicated join conditions

or single values), you can make up to about 100 delta inits. It should
not be more.

With complicated selection conditions, it should be only up to 10-20

delta inits.

Reason: With many selection conditions that are joined in a

complicated way, too many 'where' lines are generated in the
generated ABAP source code that may exceed the memory limit.

Q) I intend to copy the source system, i.e. make a client copy.

What will happen with may delta? Should I initialize again after
that?

A) Before you copy a source client or source system, make sure that
your deltas have been fetched from the DeltaQueue into BW and that
no delta is pending. After the client copy, an inconsistency might occur
between BW delta tables and the OLTP delta tables as described in
Note 405943. After the client copy, Table ROOSPRMSC will probably be
empty in the OLTP since this table is client-independent. After the
system copy, the table will contain the entries with the old logical
system name that are no longer useful for further delta loading from
the new logical system. The delta must be initialized in any case since
delta depends on both the BW system and the source system. Even if
no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an
InfoPackage, you should expect that the delta have to be initialized
after the copy.

Q) Is it allowed in Transaction SMQ1 to use the functions for

manual control of processes?
A) Use SMQ1 as an instrument for diagnosis and control only. Make
changes to BW queues only after informing the BW Support or only if
this is explicitly requested in a note for component 'BC-BW' or 'BW-
WHM-SAPI'.

Q) Despite of the delta request being started after completion

of the collective run (V3 update), it does not contain all
documents. Only another delta request loads the missing
documents into BW. What is the cause for this "splitting"?

A) The collective run submits the open V2 documents for processing to

the task handler, which processes them in one or several parallel
update processes in an asynchronous way. For this reason, plan a
sufficiently large "safety time window" between the end of the
collective run in the source system and the start of the delta request in
BW. An alternative solution where this problem does not occur is
described in Note 505700.

Q) Despite my deleting the delta init, LUWs are still written into
the DeltaQueue?

A) In general, delta initializations and deletions of delta inits should

always be carried out at a time when no posting takes place.
Otherwise, buffer problems may occur: If a user started the internal
mode at a time when the delta initialization was still active, he/she
posts data into the queue even though the initialization had been
deleted in the meantime. This is the case in your system.

Q) In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the

table TRFCQOUT, some entries have the status 'READY', others
'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses
mean? Which values in the field 'Status' mean what and which
values are correct and which are alarming? Are the statuses
BW-specific or generally valid in qRFC?
A) Table TRFCQOUT and ARFCSSTATE: Status READ means that the
record was read once either in a delta request or in a repetition of the
delta request. However, this does not mean that the record has
successfully reached the BW yet. The status READY in the TRFCQOUT
and RECORDED in the ARFCSSTATE means that the record has been
written into the DeltaQueue and will be loaded into the BW with the
next delta request or a repetition of a delta. In any case only the
statuses READ, READY and RECORDED in both tables are considered to
be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It
is set before starting a DeltaExtraction for all records with status READ
present at that time. The records with status EXECUTED are usually
deleted from the queue in packages within a delta request directly
after setting the status before extracting a new delta. If you see such
records, it means that either a process which is confirming and
deleting records which have been loaded into the BW is successfully
running at the moment, or, if the records remain in the table for a
longer period of time with status EXECUTED, it is likely that there are
problems with deleting the records which have already been
successfully been loaded into the BW. In this state, no more deltas are
loaded into the BW. Every other status is an indicator for an error or
an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).

The value 'U' in field 'NOSEND' of table TRFCQOUT is discomforting.

Q) The extract structure was changed when the DeltaQueue

was empty. Afterwards new delta records were written to the
DeltaQueue. When loading the delta into the PSA, it shows that
some fields were moved. The same result occurs when the
contents of the DeltaQueue are listed via the detail display.
Why are the data displayed differently? What can be done?

Make sure that the change of the extract structure is also reflected in
the database and that all servers are synchronized. We recommend to
reset the buffers using Transaction $SYNC. If the extract structure
change is not communicated synchronously to the server where delta
records are being created, the records are written with the old
structure until the new structure has been generated. This may have
disastrous consequences for the delta.

When the problem occurs, the delta needs to be re-initialized.

Q) How and where can I control whether a repeat delta is

requested?

A) Via the status of the last delta in the BW Request Monitor. If the
request is RED, the next load will be of type 'Repeat'. If you need to
repeat the last load for certain reasons, set the request in the monitor
to red manually. For the contents of the repeat see Question 14. Delta
requests set to red despite of data being already updated lead to
duplicate records in a subsequent repeat, if they have not been
deleted from the data targets concerned before.

Q) As of PI 2003.1, the Logistic Cockpit offers various types of

update methods. Which update method is recommended in
logistics? According to which criteria should the decision be
made? How can I choose an update method in logistics?

See the recommendation in Note 505700.

Q) Are there particular recommendations regarding the data

volume the DeltaQueue may grow to without facing the danger
of a read failure due to memory problems?

A) There is no strict limit (except for the restricted number range of

the 24-digit QCOUNT counter in the LUW management table - which is
of no practical importance, however - or the restrictions regarding the
volume and number of records in a database table).

When estimating "smooth" limits, both the number of LUWs is

important and the average data volume per LUW. As a rule, we
recommend to bundle data (usually documents) already when writing
to the DeltaQueue to keep number of LUWs small (partly this can be
set in the applications, e.g. in the Logistics Cockpit). The data volume
of a single LUW should not be considerably larger than 10% of the
memory available to the work process for data extraction (in a 32-bit
architecture with a memory volume of about 1GByte per work process,
100 Mbytes per LUW should not be exceeded). That limit is of rather
small practical importance as well since a comparable limit already
applies when writing to the DeltaQueue. If the limit is observed,
correct reading is guaranteed in most cases.

If the number of LUWs cannot be reduced by bundling application

transactions, you should at least make sure that the data are fetched
from all connected BWs as quickly as possible. But for other, BW-
specific, reasons, the frequency should not be higher than one
DeltaRequest per hour.

To avoid memory problems, a program-internal limit ensures that

never more than 1 million LUWs are read and fetched from the
database per DeltaRequest. If this limit is reached within a request,
the DeltaQueue must be emptied by several successive DeltaRequests.
We recommend, however, to try not to reach that limit but trigger the
fetching of data from the connected BWs already when the number of
LUWs reaches a 5-digit value