Ref: SDN Wiki.
Author: Davide Cavallari

Summary
We need to add a user-defined field to a LO-Cockpit DataSource. This field can change with no other field of the standard extract structure changing at the same time. We want this change to be registered by the DataSource's delta queue.

In the following example we will see how to add a custom field for the sales rep specified in a sales document. We will assume that the sales rep is modeled as a line-item partner function, and we will therefore enhance the DataSource 2LIS_11_VDITM (Sales Document Item Data).

Related Content
Introduction
1. Enhancing the LIS communication structure
2. Customizing the extract structure
3. Implementing the extraction logic for delta process
4. Implementing the extraction logic for the initialisation run

Introduction
The extraction process for the Logistics DataSources (those found in the LO Customising Cockpit, transaction code LBWE) is pretty complex. No wonder that, when you need to add a custom field to one of such DataSources, you have to pay especially carefull attention in order to avoid losing data from the DataSource's extraction or delta queues. On top of that, if your custom field is delta relevant as well, you may well end up with a broken delta process, where document changes are not always sent to the delta queue.

Here delta relevant means that when this field changes, this change should be felt by the V3 delta process, even though no additional field in the standard extract structure changes. It can be difficult to figure out exactly which steps are needed to ensure that the delta process works--although there is some good piece information around, such as this one, all in all I find the documentation available is pretty fragmented.

In the following I will concisely discuss an example which illustrates how to add a custom field for the sales rep specified in a sales document. We will assume that the sales rep is modeled as a line-item partner function, which in our example will have the value 'Z1'. We will therefore enhance the DataSource 2LIS_11_VDITM (Sales Document Item Data). I will not give details as to use the LO Customising Cockpit (LBWE) or implement an enhancement through the CMOD, though. If you need information about these tools, you should probably look for some specific documents on these topics as well. I do not even expalain the concept of before- and after-image records--should you need such information please refer to the related content section at the end of this document.

1. Enhancing the LIS communication structure
First of all, we need to add an extra field (YYKAM, in the example) in the LIS communication structure for sales documents' item data (MCVBAP).

We will insert an append structure (ZAMCVBAPUS, in the example) into the include structure MCVBAPUSR, and insert the new field YYKAM into this append structure:



2. Customizing the extract structure
The custom field YYKAM is now available in the LO Customizing Cockpit (transaction code LBWE), so we can add it to the extract structure MC11VA0ITM:



3. Implementing the extraction logic for delta process
In this step we will implement the code for extracting the value of the sales rep when a sales order's line item is created, modified or deleted (delta process). In the last step, instead, we will implement the extraction logic needed when performing the initialisation of a delta process.

The code for the delta extraction has to be written into the function EXIT_SAPLMCS1_002 (this function refers to the sales orders' line items) of the enhancement MCS10001 (SIS: Statistics update, sales documents). This can be done via the transaction CMOD:



Every time a line item is changed, deleted, or added, the EXIT function is called two times: one execution step processes the status of the data before the change (before-image), while the other the status after the change (after-image).

The field YY_KAM has to be filled with the value of the sales rep before or after the change, depending on whether the record is the before- or after-image. We can figure out which record is being processed through the field i_xmcvbap-supkz--its value being 1 for the before-image or 2 for the after-image record:

01.
*----------------------------------------------------------------------*
02.
* INCLUDE ZXMCVU02 *
03.
*----------------------------------------------------------------------*
04.
* importing VALUE(I_XMCVBAK) LIKE MCVBAKB STRUCTURE MCVBAKB
05.
*" VALUE(I_XMCVBUK) LIKE MCVBUKB STRUCTURE MCVBUKB
06.
*" VALUE(I_XMCVBAP) LIKE MCVBAPB STRUCTURE MCVBAPB
07.
*" VALUE(I_XMCVBUP) LIKE MCVBUPB STRUCTURE MCVBUPB
08.
*" VALUE(I_XMCVBKD) LIKE MCVBKDB STRUCTURE MCVBKDB
09.
*" VALUE(I_CONTROL) LIKE MCCONTROL STRUCTURE MCCONTROL
10.
*" EXPORTING
11.
*" VALUE(E_XMCVBAPUSR) LIKE MCVBAPUSR
12.
*" STRUCTURE MCVBAPUSR
13.
*----------------------------------------------------------------------*
14.
*
15.
* [...]
16.
*
17.
[...]
18.

19.
DATA lv_old_kz VALUE '1'.
20.
DATA lv_new_kz VALUE '2'.
21.
22.
[...]
23.
24.
CASE i_xmcvbap-supkz.
25.
26.
** before-image record
27.
WHEN lv_old_kz .
28.
29.
[...]
30.
31.
** after-image record
32.
WHEN lv_new_kz.
33.
34.
[...]
35.
36.
ENDCASE.
37.
[...]
Being the sales rep a partner function, its before- and after-image values will be read from internal tables YVBPA and XVBPA respectively. These two internal tables are defined and filled in the program SAPMV45A, and to access to their content we need to reference them through the ABAP instruction ASSIGN:

01.
FIELD-SYMBOLS:TYPE table.
02.
FIELD-SYMBOLS:TYPE table.
03.
04.
DATA lv_old_kz VALUE '1'.
05.
DATA lv_new_kz VALUE '2'.
06.
DATA tb_pa LIKE vbpavb OCCURS 0 WITH HEADER LINE.
07.
REFRESH tb_pa. CLEAR tb_pa.
08.
09.
CASE i_xmcvbap-supkz.
10.
11.
** before-image record
12.
WHEN lv_old_kz .
13.
""reference to before-image table
14.
ASSIGN ('(SAPMV45A)YVBPA[]') TO.
15.
IF sy-subrc EQ 0.
16.
tb_pa[] =.
17.
18.
[...]
19.
20.
ENDIF.
21.
22.
**after-image record
23.
WHEN lv_new_kz.
24.
""reference to after-image table
25.
ASSIGN ('(SAPMV45A)XVBPA[]') TO.
26.
IF sy-subrc EQ 0.
27.
tb_pa[] =.
28.
ENDIF.
29.
30.
ENDCASE.
31.
[...]
When users modify the sales rep in an order line item, they can enter the original value again. When this happens, the before-image and the after-image values for the field YYKAM have to be the same. In this case, however, the table YVBPA does not contain the before-image value, so we will need to fetch it from the after-image table XVBPA:
01.
** before-image record
02.
WHEN lv_old_kz .
03.
""reference to before-image table
04.
ASSIGN ('(SAPMV45A)YVBPA[]') TO.
05.
IF sy-subrc EQ 0.
06.
tb_pa[] =.
07.
08.
READ TABLE tb_pa WITH KEY parvw = 'Z1'.
09.
"Z1 is the sales rep's partner function
10.
IF sy-subrc ne 0.
11.
""when user does not change the sales rep, Y- table does not
12.
""contain the partner function Z1, so before-image state has to be
13.
""read from X- table.
14.
ASSIGN ('(SAPMV45A)XVBPA[]') TO.
15.
IF sy-subrc EQ 0.
16.
tb_pa[] =.
17.
ENDIF.
18.
ENDIF.
19.
20.
ENDIF.
Here is the complete example code:

01.
*----------------------------------------------------------------------*
02.
* INCLUDE ZXMCVU02 *
03.
*----------------------------------------------------------------------*
04.
* importing VALUE(I_XMCVBAK) LIKE MCVBAKB STRUCTURE MCVBAKB
05.
*" VALUE(I_XMCVBUK) LIKE MCVBUKB STRUCTURE MCVBUKB
06.
*" VALUE(I_XMCVBAP) LIKE MCVBAPB STRUCTURE MCVBAPB
07.
*" VALUE(I_XMCVBUP) LIKE MCVBUPB STRUCTURE MCVBUPB
08.
*" VALUE(I_XMCVBKD) LIKE MCVBKDB STRUCTURE MCVBKDB
09.
*" VALUE(I_CONTROL) LIKE MCCONTROL STRUCTURE MCCONTROL
10.
*" EXPORTING
11.
*" VALUE(E_XMCVBAPUSR) LIKE MCVBAPUSR
12.
*" STRUCTURE MCVBAPUSR
13.
*---------------------------------------------------------------------------*
14.
*
15.
* See SAP Note 216448 for information on 'before-' e 'after-image'
16.
*---------------------------------------------------------------------------*
17.
18.
FIELD-SYMBOLS:TYPE table.
19.
FIELD-SYMBOLS:TYPE table.
20.
21.
DATA lv_old_kz VALUE '1'.
22.
DATA lv_new_kz VALUE '2'.
23.
DATA tb_pa LIKE vbpavb OCCURS 0 WITH HEADER LINE.
24.
REFRESH tb_pa. CLEAR tb_pa.
25.
26.
CASE i_xmcvbap-supkz.
27.
28.
** before-image record
29.
WHEN lv_old_kz .
30.
""reference to before-image table
31.
ASSIGN ('(SAPMV45A)YVBPA[]') TO.
32.
IF sy-subrc EQ 0.
33.
tb_pa[] =.
34.
35.
READ TABLE tb_pa WITH KEY parvw = 'Z1'.
36.
IF sy-subrc ne 0.
37.
""when user does not change the sales rep, Y- table does not
38.
""contain the partner function Z1, so before-image state has to be
39.
""read from X- table.
40.
ASSIGN ('(SAPMV45A)XVBPA[]') TO.
41.
IF sy-subrc EQ 0.
42.
tb_pa[] =.
43.
ENDIF.
44.
ENDIF.
45.
46.
ENDIF.
47.
48.
** after-image record
49.
WHEN lv_new_kz.
50.
""reference to after-image table
51.
ASSIGN ('(SAPMV45A)XVBPA[]') TO.
52.
IF sy-subrc EQ 0.
53.
tb_pa[] =.
54.
ENDIF.
55.
56.
ENDCASE.
57.
58.
** we take the line-item value unless not present
59.
** in which case we take the header value
60.
READ TABLE tb_pa WITH KEY posnr = i_xmcvbap-posnr
61.
parvw = 'Z1'.
62.
IF sy-subrc NE 0.
63.
READ TABLE tb_pa WITH KEY posnr = '000000'
64.
parvw = 'Z1'.
65.
ENDIF.
66.
67.
IF sy-subrc EQ 0.
68.
MOVE tb_pa-lifnr TO e_xmcvbapusr-yykam.
69.
ENDIF.
4. Implementing the extraction logic for the initialisation run
The code in the EXIT above is only run when a sales document line is created, modified, or deleted (delta process). However, that code is not executed during the initialisation of the delta process, i.e. when all data from setup tables are loaded in BW.

In order for the extraction to take place also during the initialisation run, we need to implement the same extraction logic in the function EXIT_SAPLRSAP_001 (normally used to enhance non-LO transactional DataSources) of the enhancement RSAP0001 (Customer function calls in the service API).

Since we have already implemented the extraction logic for the delta process, we have to make sure that the code we put here is executed only when data are requested in full mode--i.e. when the field i_updmode has the value 'F' (transfer of all requested data), 'C' (initialization of the delta transfer), 'S' (simulation of initialzation of delta transfer), or 'I' (transfer of an opening balance for non-cumulative values, not relevant in our case), but not when its value is 'D' (transfer of the delta since the last request) and 'R' (repetition of the transfer of a data packet):

01.
[...]
02.
03.
CASE i_datasource.
04.
05.
[...]
06.
07.
WHEN '2LIS_11_VAITM'.
08.
DATA: s_mc11va0itm LIKE mc11va0itm.
09.
10.
LOOP AT c_t_data INTO s_mc11va0itm.
11.
wk_tabx = sy-tabix.
12.
13.
*-- The following code must be executed during initialisation only
14.
*-- (the extraction logic for delta update in EXIT_SAPLMCS6_002)
15.
*
16.
** we take the line-item value unless not present
17.
** in which case we take the header value
18.
19.
* only during initialisation
20.
IF i_updmode EQ 'F' OR " F Transfer of all requested data
21.
i_updmode EQ 'C' OR " C Initialization of the delta transfer
22.
i_updmode EQ 'S' OR " S Simulation of Initialzation of Delta Transfer
23.
i_updmode EQ 'I'. " I Transfer of an opening balance for non-cumulative values
24.
* D Transfer of the Delta Since the Last Request
25.
* R Repetition of the transfer of a data packet
26.
27.
SELECT SINGLE lifnr INTO l_lifnr
28.
FROM vbpa
29.
WHERE vbeln = s_mc11va0itm-vbeln AND
30.
posnr = s_mc11va0itm-posnr AND
31.
parvw = 'Z1'.
32.
33.
IF sy-subrc NE 0.
34.
SELECT SINGLE lifnr INTO l_lifnr
35.
FROM vbpa
36.
WHERE vbeln = s_mc11va0itm-vbeln AND
37.
posnr = '000000' AND
38.
parvw = 'Z1'.
39.
ENDIF.
40.
41.
IF sy-subrc EQ 0.
42.
MOVE l_lifnr TO s_mc11va0itm-yykam.
43.
ENDIF.
44.
ENDIF.

Forum post in BI General: Re: Collapsed request in infocube-How to get delta back
https://forums.sdn.sap.com/thread.jspa?threadID=588063&messageID=4236057#4236057

Yes you are correct SVR,

We can not delete request once it is compressed. Selective deletion is not usefull in this case.

You can try following -- Be careful -- follow steps -- first try in Dev

If you know last requests generated todays delta in base/source ODS and those requests are available in PSA for reconstruction.... then...

1. Delete initialization from this source ODS to all 3 targets.
2. If requests are available for reconstruction, delete required requests from ODS.
3. Now initialize without data transfer from ODS to 3 targets(2cubes + 1ods).
4. Reconstruct deleted requests in Source ODS(it generated delta)
5. Pust delta to 3 targets.

Hope it helps
Srini

- - - - - - - - - - - - - - - - - - - - - -

Visit the SAP Developer Network at https://www.sdn.sap.com.

Question 1
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.

Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).

• Status COL_RUN INIT: without Delete_Flag but with VB_Flag (records are updated).

• Status COL_RUN OK: with Delete_Flag (the records are deleted for all modules with COL_RUN -- OK)

With the IN_VB flag, data are only deleted, if there is no delta initialization. Otherwise, the records are updated.
MAXFBS : The number of processed records without Commit.

Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.

Question 4
Why has SM13 not been emptied even though I have started the V3 update?

• The update record in SM13 contains several modules (for example, MCEX_UPDATE_11 and MCEX_UPDATE_12). If you start the V3 update only for one module, then the other module still has INIT status in SM13 and is waiting for the corresponding collective run. In some cases, the entry might also not be deleted if the V3 update has been started for the second module.In this case, schedule the request RSM13005 with the DELETE_FLAG (see question 2).

• V3 updating no longer functions after the PI upgrade because you did not load all the delta records into the BW system prior to the upgrade.Proceed as described in note 328181.

Questions and answers related to T-Code: RSA7(Delta Queue)

This note maintained here for my quick reference and for those dont have SAP Notes access :-)

Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
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.

Question 2:
What is an LUW in the delta queue?
Answer:
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.

Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
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.

Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
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.

Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.

Question 6:
Why is there a DataSource with '0' records in RSA7 if delta exists and has been loaded successfully?
Answer:
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')

Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
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.

Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
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.

Question 9:
What is the purpose of the function 'Delete Data and Meta Data in a Queue' in RSA7? What exactly is deleted?
Answer:
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.

Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.

Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
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.

Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
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.

Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
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.

Question 14:
Why does the 'Repeatable' button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, 'pure' delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.

Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.

Question 16:
How many selections for delta inits are possible in the system?
Answer:
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.

Question 17:
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?
Answer:
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.

Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
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'.

Question 19.
Despite the delta request only 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"?
Answer:
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.

Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
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.

Question 21.
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?
Answer:
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.

Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
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.

Question 23.
How and where can I control whether a repeat delta is requested?
Answer:
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.

Question 24.
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?
Answer:
See the recommendation in Note 505700.

Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
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.

---> Some more related Notes....
873694 - Consulting: Delta repeat and status in monitor/data target
771894 - No data during delta upload: Selection on Z* fields
723935 - Adding the TID display to the DeltaQueue monitor
691721 - Restoring lost data from a delta request
576896 - Checks when PSA contains incorrect data for delta requests
574601 - BW-SAPI: Endless loop when confirming qRFC LUWs
417307 - Extractor package size: Collective note for applications
417189 - BW/SAPLEINS - Online update of delta queue
405943 - Calling an InfoPackage in BW causes short dump
377732 - Collective SAP note SAP BW BCT 2.1C for EBP 2.0 and 3.0

1. Go to transaction code RSA3 and see if any data is available related to your DataSource. If data is there in RSA3 then go to transaction code LBWG (Delete Setup data) and delete the data by entering the application name.

2. Go to transaction SBIW –> Settings for Application Specific Datasource –> Logistics –> Managing extract structures –> Initialization –> Filling the Setup table –> Application specific setup of statistical data –> perform setup (relevant application)

3. In OLI*** (for example OLI7BW for Statistical setup for old documents : Orders) give the name of the run and execute. Now all the available records from R/3 will be loaded to setup tables.

4. Go to transaction RSA3 and check the data.

5. Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.

6. Go to BW system and create infopackage and under the update tab select the initialize delta process. And schedule the package. Now all the data available in the setup tables are now loaded into the data target.

7. Now for the delta records go to LBWE in R/3 and change the update mode for the corresponding DataSource to Direct/Queue delta. By doing this record will bypass SM13 and directly go to RSA7. Go to transaction code RSA7 there you can see green light # Once the new records are added immediately you can see the record in RSA7.

8. Go to BW system and create a new infopackage for delta loads. Double click on new infopackage. Under update tab you can see the delta update radio button.

9. Now you can go to your data target and see the delta

Some more info @

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1096

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1106

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1183

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1262

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1522

If already Full Loads are available then we need to start Delta loads, then we need to convert Full Loads to Repair full loads to start Delta loads.

Use Program : RSSM_SET_REPAIR_FULL_FLAG to convert Full loads to Repair Full.

1. Go to T Code: SE38 or SA38 and provide program name(RSSM_SET_REPAIR_FULL_FLAG) and execute.

3. we can see all available Full requests in ODS.

Custome Infoobjects Tabels:
/BIC/M -- View of Master data Tables
/BIC/P -- Master data Table, Time Independent attributes
/BIC/Q -- Master data Table, Time Dependent attributes
/BIC/X -- SID Table, Time Independent
/BIC/Y -- SID Tabel, Time Dependent
/BIC/T -- Text Table
/BIC/H -- Heirarchy Table
/BIC/K -- Heirarchy SID Table

Standard Infoobjects Tabels(Buss. Content):
Replace "C" with "0" in above tables.
Ex: /BI0/M -- View of Master data Tables

Standard InfoCUBE Tables :
/BI0/F -- Fact Table(Before Compression)
/BI0/E -- Fact Table(After Compression)
/BI0/P -- Dimension Table - Data Package
/BI0/T -- Dimension Table - Time
/BI0/U -- Dimension Table - Unit
/BI0/1, 2, 3, .......A,B,C,D : -- Dimension Tables

BW Tables:
BTCEVTJOB -- To check List of jobs waiting for events
ROOSOURCE -- Control parameters for Datasource
ROOSFIELD -- Control parameters for Datasource
ROOSPRMSC -- Control parameters for Datasource
ROOSPRMSF -- Control parameters for Datasource
-- More info @ ROOSOURCE weblog
RSOLTPSOURCE -- Replicate Table for OLTP source in BW
RSDMDELTA -- Datamart Delta Management
RSSDLINITSEL, RSSDLINITDEL
-- Last valid Initialization to an OLTP Source
RSUPDINFO -- Infocube to Infosource correlation
RSUPDDAT -- Update rules key figures
RSUPDENQ -- Removal of locks in the update rules
RSUPDFORM -- BW: Update Rules - Formulas - Checking Table
RSUPDINFO -- Update info (status and program)
RSUPDKEY -- Update rule: Key per key figure
RSUPDROUT -- Update rules - ABAP routine - check table
RSUPDSIMULD -- Table for saving simulation data update
RSUPDSIMULH -- Table for saving simulation data header information
RSDCUBEIOBJ -- Infoobjects per Infocube
RSIS -- Infosouce Info
RSUPDINFO -- Update Rules Info
RSTS -- Transfer Rules Info
RSKSFIELD -- Communication Structure fields
RSALLOWEDCHAR -- Special Characters Table(T Code : RSKC, To maintain)
RSDLPSEL -- Selection Table for fields scheduler(Infpak's)
RSDLPIO -- Log data packet no
RSMONICTAB -- Monitor, Data Targets(Infocube/ODS) Table, request related info
RSTSODS -- Operational data store for Transfer structure
RSZELTDIR -- Query Elements
RSZGLOBV -- BEx Variables
RXSELTXREF, RSCOMPDIR -- Reports/query relavent tables
RSCUSTV -- Query settings
RSDIOBJ -- Infoobjects
RSLDPSEL -- Selection table for fields scheduler(Info pak list)
RSMONIPTAB -- InfoPackage for the monitor
RSRWORKBOOK -- Workbooks & related query genunid's
RSRREPDIR -- Contains Genuin id, Rep Name, author, etc...
RSRINDEXT -- Workbook ID & Name
RSREQDONE -- Monitor: Saving of the QM entries
RSSELDONE -- Monitor : Selection for exected requests
RSLDTDONE -- Texts on the requeasted infopacks & groups
RSUICDONE -- BIW: Selection table for user-selection update Infocubes's
RSSDBATCH -- Table for Batch run scheduler
RSLDPDEL -- Selection table for deleting with full update scheduler
RSADMINSV -- RS Administration
RSSDLINIT -- Last Valid Initializations to an OLTP Source
BTCEVTJOB --To check event status(scheduled or not)
VARI -- ABAP Variant related Table
VARIDESC -- Selection Variants: Description
SMQ1 -- QRFC Monitor(Out Bound)
SM13 -- Update Records status

T Code : LBWQ --> QRFC related Tables
TRFCQOUT,
QREFTID,
ARFCSDATA
More info @ Note 728687 - Delta queued: No data in RSA7

RSIMPCURR -- To Transfer Exchange Rates
RSIMPCUST -- To Transfer Global Settings from source system
RS_TRANSTRU_ACTIVATE_ALL -- To Activate Transfer Rules
-- Useful whenever we need to activate transfer rules in Quality or Production system after transports.
RSAU_UPDR_REACTIVATE_ALL -- To Activate Update Rules
SAP_CONVERT_TO_TRANSACTIONAL -- To change Basic Cube to Transactional Cube
RSAR_PSA_CLEANUP_DIRECTORY -- To Clean PSA and Change log
SAP_INFOCUBE_DESIGN -- To know statistics(Size) of Cubes
-- Useful to know the size of Fact Tables and Dimension Tables
RSSM_SET_REPAIR_FULL_FLAG -- To change request status from Full load to repair full
-- Useful to start delta loads, If full loads are already present in data target from same data source
RSDDS_AGGREGATES_MAINTAIN -- For Hierarchy/Attribute Change run
RSDDS_CHANGERUN_MONITOR -- To Check Change run Status
RSDG_ODSO_ACTIVATE -- To Activate ODS in background. very much useful when BEx reporting switched on.
RSDG_IOBJ_ACTIVATE -- To Activate Infoobjects(Mass Activation)
RSDG_MPRO_ACTIVATE -- To Activate MultiProviders
RSDG_CUBE_ACTIVATE -- Activation of InfoCubes
RS_COMSTRU_ACTIVATE_ALL -- Activate all inactive communication structures
RSCONN07 - SAP Connect Administration(System Status)
RSAOS_METADATA_UPLOAD_BATCH -- To replicate single datasource from Source(R/3)
RSDRD_DELETE_FACTS -- To delete data selectively from infoprovider(ODS or CUBE)
RSAR_LOGICAL_SYSTEMS_ACTIVATE -- Activate All SAP Source Systems (After BW Upgrade)
RSDS_DATASOURCE_ACTIVATE_ALL -- Activate All DataSources of a Log System
RSTCC_ACTIVATE_ADMIN_COCKPIT -- Perform all steps to activate the content for the BI Admin Cockpit
RSTCC_ACTIVATEADMINCOCKPIT_NEW -- Activate Content for the BI Admin Cockpit