c


 

 

 




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 repeating a delta
request) and the LUWs for the next delta request. An 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.

c
 








 
An 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 from an application extractor.

c
 

  

 

 !
"
"


#! ##


#
 
# 
 
 $

   $

"


 
The number on the overview screen corresponds to the total number of LUWs (see also question 1) 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.
This means that only the records that are ready for the next delta request are displayed on the detail
screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer
exit.

c
% 

  
 $ 


"
"


#
 
# 

 &

 
Only when a new delta has been requested does the source system learn that the previous delta was
successfully loaded into the BW System. The LUWs of the previous delta may then 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 if the first delta is loaded into the BW
System.

c
' 

 


(
 




#



 
Filtering according to selections takes place when the system reads from the delta queue. This is
necessary for performance reasons.

c
) 

 

* 
+
 #

, 




 
#  

 
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 . You can display the current delta data for these DataSources using
TA RSA3 (update mode ='D')

c
 
*



-.*-/01"
$
$
#
#
 &
$

#





 
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 PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta
queue as for a full update. Note, however, that LUWs are not split during data loading for consistency
reasons. This means that when very large LUWs are written to the delta queue, the actual package size
may differ considerably from the MAXSIZE and MAXLINES parameters.

c
2 

  
(
& $ 
 



3#
,$
$$,
 
 4

 
With PlugIn 2001.1 the display was changed: you are now able to define 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.

c
5 


$ $
#
# *


* 1
*c





, 




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

c
+ 

  
(
&


#



3#
,$
#  4


 
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.

c
 

 



 $ 

  
6 $ 

&($



 
It is most likely that a delta initialization had not yet run or that the 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 to be written to the delta queue.

c
 



$


 
7/31c4


 
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 is shorter than 20 characters, 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.

c
 

 

 



 &
6 $ 






 
You posted data in the background. This means that 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.

c
% 

  


$

 
 


  


8
 &

 
 9
 !
 !$ 


 

 
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and
new data from the source system.

c
' 
.

"

" 

:7






 
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.
c
) 
; 

#

$

 


 
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 which may exceed the memory limit.

c
 
.
 $ 
 
 
!:
:(

$ :
$$
 

  .<
&#


 
Before you copy a source client or source system, make sure that your deltas have been fetched from
the delta queue 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 which 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 has to be initialized after the copy.

c
2:
.$

 

# 1c  $



 
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after
informing BW Support or only if this is explicitly requested in a note for Component 'BC-BW' or 'BW-
WHM-SAPI'.

c
5:
*
$




 
&
#
$
#

"
 36 $ 
4!

  
:- 



 
&  

8
:

 
#=$&=

 
The collective run submits the open V2 documents to the task handler for processing. The task handler
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.

c
+:
*
$


&

!



*
c



 
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 you started the internal mode at a time
when the delta initialization was still active, you post data into the queue even though the initialization
had been deleted in the meantime. This is the case in your system.

c
:
.1c37/14."
 >-?>*:.

7/c-!


"


 ?*@!
?/-*?*:7/??*:
 

 



"

#
  
 "


 

&

 
8
9$
#&

 " 7/

 
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 still does not mean that the record has
successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the
ARFCSSTATE means that the record has been written into the delta queue 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 delta extraction 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 confirms and deletes records 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 indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).
However the value 'U' in field 'NOSEND' of table TRFCQOUT is of concern.

c
:


,  
&






$ :#
 



 






:

 &


0!

#
 

"
:


  


#





"


 $ :
 
  $
 ##

 

 


 
Make sure that the change of the extract structure is also reflected in the database and that all servers
are synchronized. We recommend resetting 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.

c
:; 

.


$







 
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 any reason, manually set the request in the monitor
to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already
updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the
data targets concerned.

c
%:
#0.++:!
&/($##
"  $
# $ 

 :
 $ 


 


& &
  




;.
 $ 

 &

 
See the recommendation in Note 505700.

c
':



$ 

 
& &
,  " 
#




"  &
#
 # 


 $


 
There is no strict limit (except for the restricted number area 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 "soft" limits, both the number of LUWs and the average data volume per LUW are
important. As a rule, we recommend bundling data (usually documents) as soon as you write to the
delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the
Logistics Cockpit). The data volume of a single LUW should not be much 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 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather
small practical importance as well since a comparable limit already applies when writing to the delta
queue. 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 is fetched from all connected BWs as quickly as possible. But for other, BW-
specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever
read and fetched from the database per delta request. If this limit is reached within a request, the delta
queue must be emptied by several successive delta requests. We recommend, however, to try not to
reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs
reaches a 5-digit value.