Skip to main content

What do you mean by Queued Delta Update Method?

"Queued delta" update method:

With queued delta update mode, the extraction data (for the relevant application) is written in an extraction queue (instead of in the update data as in V3) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.

After activating this method, up to 10000 document delta/changes to one LUW are cumulated per datasource in the BW delta queues.

If you use this method, it will be necessary to schedule a job to regularly transfer the data to the BW delta queues (by means of so-called "update collective run") by using the same delivered reports as before (RMBWV3); instead, report RSM13005 will not be provided any more since it only processes V3 update entries.

As always, the simplest way to perform scheduling is via the "Job control" function in LBWE.

SAP recommends to schedule this job hourly during normal operation after successful delta initialization, but there is no fixed rule: it depends from peculiarity of every specific situation (business volume, reporting needs and so on).

When you need to perform a delta initialization in the OLTP, thanks to the logic of this method, the document postings (relevant for the involved application) can be opened again as soon as the execution of the recompilation run (or runs, if several and running in parallel) ends, that is when setup tables are filled, and a delta init request is posted in BW, because the system is able to collect new document data during the delta init uploading too (with a deeply felt recommendation: remember to avoid update collective run before all delta init requests have been successfully updated in your BW!).

By writing in the extraction queue within the V1 update process (that is more burdened than by using V3), the serialization is ensured by using the enqueue concept, but collective run clearly performs better than the serialized V3 and especially slowing-down due to documents posted in multiple languages does not apply in this method.
On the contrary of direct delta, this process is especially recommended for customers with a high occurrence of documents (more than 10,000 document changes - creation, change or deletion - performed each day for the application in question.

In contrast to the V3 collective run (see OSS Note 409239 ‘Automatically trigger BW loads upon end of V3 updates’ in which this scenario is described), an event handling is possible here, because a definite end for the collective run is identifiable: in fact, when the collective run for an application ends, an event (&MCEX_nn, where nn is the number of the application) is automatically triggered and, thus, it can be used to start a subsequent job.

Besides, don’t omit that queued delta process extraction is independent of success of the V2 update.

The ‘queued delta’ is a good friend, but some care is required to avoid any trouble.

First of all, if you want to take a look to the data of all extract structures queues in Logistic Cockpit, use transaction LBWQ or "Log queue overview" function in LBWE (but here you can see only the queues currently containing extraction data).

In the posting-free phase before a new init run in OLTP, you should always execute (as with the old V3) the update collective run once to make sure to empty the extraction queue from any old delta records (especially if you are already using the extractor) that, otherwise, can cause serious inconsistencies in your data.

Then, if you want to do some change (through LBWE or RSA6) to the extract structures of an application (for which you selected this update method), you have to be absolutely sure that no data is in the extraction queue before executing these changes in the affected systems (and especially before importing these changes in production environment !).

To perform a check when the V3 update is already in use, you can run in the target system the RMCSBWCC check report.

The extraction queues should never contain any data immediately before to:

perform an R/3 or a plug-in upgrade
import an R/3 or a plug-in support packages
Serialized V3 Update(If you set this as your delta mode then data will populated into extraction queue tables)


Popular posts from this blog

Step by Step guide on BADI with Filter implementation

Step 1 à Before implementing filter objects to a BADI. We need to deactivate all the implementation for that BADI. Go to SE18 (BADI definition) and from there navigate to all BADI implementation to view all the active implementations for that BADI
Select the BADI implementations listed on the screen and deactivate the implementation. Once done, return back to the initial screen of SE18 and proceed with next step. Step 2 à go to SE18 – BADI Definition screen and change the existing BADI definition that we created in the earlier tutorial. Select the FILTER –DEPENDENT check box under the TYPE section. This will open up the FILTER TYPE field for inputs. And do an F1 on the FILTER TYPE field. Click on the F4 on the FILTER TYPE field name and enter some search criteria to find a relevant data element. And click on the continue button
Select the data element from the list to set up your filter and hit enter. Click on the save button and active the BADI definition. If a BADI implementation alre…

Different Types of Delta Updates

What is the different delta updates and when to use which updates?

Delta loads will bring any new or changed records after the last upload. This method is used for better loading in less time. Most of the std SAP datasources come as delta enabled, but some are not. In this case you can do a full load to the ODS and then do a delta from the ODS to the cube. If you create generic datasources, then you have the option of creating a delta on Calday, timestamp or numeric pointer fields (this can be doc number, etc).

You'll be able to see the delta changes coming in the delta queue through RSA7 on the R3 side.

To do a delta, you first have to initialize the delta on the BW side and then set up the delta. The delta mechanism is the same for both Master data and Transaction data loads.

There are three deltas:
Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extracti…

Creating Hierarchies


In the InfoObject maintenance, the indicator with hierarchies is set for the relevant characteristic, meaning that the characteristic can have hierarchies.


Step 1: Select the InfoObject tree in the Administrator Workbench.
If you have assigned the characteristic to an InfoObject catalog, select the corresponding InfoObject catalog for an InfoArea.
If the characteristic does not belong to an InfoObject catalog, select the Not Assigned Nodes InfoArea and the Not Assigned Characteristics InfoObject catalog.

Step 2:Select the characteristic for which you want to create a hierarchy, choose the context menu with the right mouse button, and then Create hierarchy.

Step 3:In the dialog box, enter the technical hierarchy name, or the hierarchy version if applicable, the time-reference, and at least one short description of the hierarchy. Confirm your entries. You come to the screen Maintain hierarchies. You can now define your hierarchy here.
Creating Nodes and Leaves

Step 4:Sele…