R/3 extraction.{direct delta and queued delta and V3}

Hi,
I am new to BW.Can anyone explain me about R/3 extraction in detail and steps to extract from R/3 to BW.
I understood direct delta.But i couldn't understand queued delta.Can anyone please explain queued delta and also V3.Are queued delta and V3 same?
Detail explanation or links will help a lot.
Thanks,
Sunny.

Hi Sunny,
Procurement - MM :
MM is a part of SCM. There are several section in this, say Procurement, manufacturing, vendor evaluation etc... All can be found under follwoing link.
Please find the procedure and important links for LO extraction..
LO'S Procedure:
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.
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)
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.
Go to transaction RSA3 and check the data.
Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.
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.
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.
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.
Now you can go to your data target and see the delta record.
Re: LO-Cockpit V1 and V2 update
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
Also Refer this link:
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Inventory.. dwload go thru it
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
*Steps*:
1st delet the septup table----lbwg(for application 3)(need to cleanup the setup tables in r/3 side by using (LBWG for AC:03)
1) Fill setup table (fill up the set up tables BX, BF and UM by using (MCNB,OLI1BW and OLIZBW).
for BX(Open stock)-tcode--MCNB,
for BF Tcode(oli1bw)
for UM tcode(olizbw)
after that pull data to BW with (Once the data is ready in RSA3, then in BW you have to set up compression for zero marker update for the Cube (coz is related to Noncummulative Keyfiger scenario) then load BX data. onces its completed load normally the BF and UMs.
BW side:-
make the compression
for BX load normally
and BF&UM(step table data):-compression with zero mark update(select that check box option)
after completion of compression do delta(Note: for deltas follow the compression normally)
http://help.sap.com/saphelp_nw2004s/helpdata/en/29/79eb3cad744026e10000000a11405a/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/c5/a26f37eb997866e10000009b38f8cf/frameset.htm
SD - Enterprise Sales and Distribution
SD comes under CRM application component (ERP Analytics).
sd flow
salesorder:
VBRK - header
VBAP - item
VBEP - scheduling
delivery:
LIKP - header
LIPS - item
billing:
VBRK - header
VBRP - item
shipement
VTTK - header
VTTP - item
customer data
SD links FI table
salesarea data general data companycode data
knvp kna1 knb1
material master data
SD link to MM table
salesdata Basic data salestext data
MARC MARA STXH(Textfile header)
MVKE MAKT STXL
process:
1.sales reresntive enter sales order in R/3 system, it sotres the transaction into three
SD tables.
2.delivery due list is executed for all sales orders and delivers are created in table LIKP, LIPS.
A goodsissue updating MKPF & MSEG.
3.invoice due list is then executed for all deliviers. after an invoice is created, which creates an acct.doc ( BKPF & BSEG, FI TABLES) and set up the receivalbe in table BSID (open tem).
4.The receivalbe is cleared when paymen check is required. anoher acct.doc is created ( BKPF & BSEG) the open receivable is cleared and table BSAD (closed line item) is updated
First u select application component.. SD,MM,FI,PM
then got to rsa5.. u can install data source...
after next step RSA6-Display data sources
Then select our ds which we need to enhance then click on the
append structure (application tool bar)
u can see start with ZAGTFIGL_4 ( fi example)
u given component name and component type ( here given to existing
data element)
save + activate....
then go to the t code CMOD...>there select the project
name--> go to the exit in RSAP0001->
or also u can goto tcode se37 fuction module.. EXIT_SAPLRSAP_001
transactional data
click on display...
then u can see INCLUDE ZXRSAU01( program ) double click it.....
then u can change option click it.
So please follow the link below:
http://help.sap.com/saphelp_nw70/helpdata/en/c5/bbe737a294946fe10000009b38f8cf/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/17/cd5e407aa4c44ce10000000a1550b0/frameset.htm
Check these links,
http://help.sap.com/saphelp_47x200/helpdata/en/dd/55f33e545a11d1a7020000e829fd11/frameset.htm
http://www.sapbrain.com/TUTORIALS/FUNCTIONAL/SD_tutorial.html
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/MYSAP/SR_MM.pdf
http://sap-img.com/materials/what-is-the-dataflow-of-mm.htm
http://www.erpgenie.com/abap/tables_sd.htm
http://www.erpgenie.com/abap/tables_mm.htm
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
/people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
Re: LO-Cockpit V1 and V2 update
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Regards
CSM Reddy

Similar Messages

Read-through/write-behind and queued deletes (and updates)

Hi,
If I am changing the state of objects in a cache and using the write-behind and read-through mechanism what happens when I have deleted or updated an object in the cache but the change has not yet been committed to the database?.
If I delete and object in the cache and the delete DB operation is being queued and during this time try and perform a get against the key for the object is the value read through from the database or is it ignored since the database delete is pending?
For updates I presume that the value in the cache will be used - as the value exists in the cache and a read-through from the database will not be triggered.
Can you clarify the behavior of Coherence under these circumstances, particularly that of a pending delete.
Thanks,
Dave

Hi Dave,
If I am changing the state of objects in a cache and
using the write-behind and read-through mechanism
what happens when I have deleted or updated an object
in the cache but the change has not yet been
committed to the database?.
If I delete and object in the cache and the delete DB
operation is being queued and during this time try
and perform a get against the key for the object is
the value read through from the database or is it
ignored since the database delete is pending?I seem to remember a forum post mentioning that the removes from a write-behind cache are performed synchronously (they are done as part of the backingMap.remove(key)) operation so even if there are were pending updates in the write-behind queue. If I remember correctly, then the above mentioned problem cannot happen.
>
For updates I presume that the value in the cache
will be used - as the value exists in the cache and a
read-through from the database will not be
triggered.
Exactly.
Best regards,
Robert

Defference in Queued Delta and V3 Upadte

Hi Gurus,
Can any one please explain about the difference in Bitween Queued Delta and V3 Upadate.
if i will maintain Queued Delta,then i don't want to maintain V3 Update?
Thanks In Adavane
Regards.

Hi Choudary,
Please find below the difference between the Queued Delta and V3 Update..
>>Queued Delta:
With queued delta update mode, the extraction data is written in an extraction queue and is transferred to the BW Delta Queues by an update collective run.
Upto 10000 document delta/change to one LUW are cumulated per Datasource in the BW Delta Queue.
Queued Delta - Advantages:
Serialization is ensured using the enqueue concept.
Works good when the occurrence of documents is high.
Queued Delta - Disadvantages:
In this case we would need to schedule a job (LBWE-Job Control) to regularly transfer the data to BW Delta Queue.
Subsequently additional monitoring of the extraction queue is required.
Queued Delta Recommended For:
Customers with high occurrence of documents (more than 10000 document changes between delta extractions).
>>Unserialized V3 Update :
The extraction data continues to be written to the update tables using a V3 update module and then is read and processed by a collective update run through LBWE.
Data is read in the update collective run without taking the sequence number into account.
Unserialized V3 Update - Advantages:
Works good when the occurrence of documents is high.
Unserialized V3 Update - Disadvantages:
Serialization is not ensured.
In this case we would need to schedule a job (LBWE-Job Control) to regularly transfer the data.
Subsequently additional monitoring of the extraction queue is required.
Unserialized V3 Update Recommended For:
Only if its irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence (serialization) in which the data was generated in R/3. Basically the functional data flow should not require a correct temporal sequence.
Hope this helps.
Thanks & Regards,
SH

Update method:Queued delta

Hi all,
Is Update queue in Queued delta got any structure?
How it works?
Thanks
Regards
Dheepa

I am not sure if there is any structure for Queued Delta. Not to my knowledge.
The working of the Queued Delta is explained below..
Queued Delta:
With queued delta update mode, the extraction data is written in an extraction queue and is transferred to the BW Delta Queues by an update collective run.
Upto 10000 document delta/change to one LUW are cumulated per Datasource in the BW Delta Queue.
Queued Delta - Advantages:
Serialization is ensured using the enqueue concept.
Works good when the occurrence of documents is high.
Queued Delta - Disadvantages:
In this case we would need to schedule a job (LBWE-Job Control) to regularly transfer the data to BW Delta Queue.
Subsequently additional monitoring of the extraction queue is required.
Queued Delta Recommended For:
Customers with high occurrence of documents (more than 10000 document changes between delta extractions).
Hope this helps.
Thanks & Regards,
SH

Why we will go for Queue delta instead of Unserialized and Direct delta ?

Hi Experts,
Why we will go for Queue delta instead of Unserialized and Direct delta ? specify any reasons for that ?
What happens internally when we use Queue delta , Direct delta ?
I will allocate points to those who help me in detail. My advance thanks who respond to my query.

Hi,
Direct Delta
With this update mode, extraction data is transferred directly to the BW delta queues every time a document is posted. In this way, each document posted with delta extraction is converted to exactly one LUW in the related BW delta queues. If you are using this method, there is no need to schedule a job at regular intervals to transfer the data to the BW delta queues. On the other hand, the number of LUWs per DataSource increases significantly in the BW delta queues because the deltas of many documents are not summarized into one LUW in the BW delta queues as was previously the case for the V3 update.
If you are using this update mode, note that you cannot post any documents during delta initialization in an application from the start of the recompilation run in the OLTP until all delta init requests have been successfully updated successfully in BW. Otherwise, data from documents posted in the meantime is irretrievably lost. The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) A maximum of 10,000 document changes (creating, changing or deleting documents) are accrued between two delta extractions for the application in question. A (considerably) larger number of LUWs in the BW delta queue can result in terminations during extraction.
b) With a future delta initialization, you can ensure that no documents are posted from the start of the recompilation run in R/3 until all delta-init requests have been successfully posted. This applies particularly if, for example, you want to include more organizational units such as another plant or sales organization in the extraction. Stopping the posting of documents always applies to the entire client.
Queued Delta
With this update mode, the extraction data for the affected application is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
Up to 10,000 delta extractions of documents to an LUW in the BW delta queues are cumulated in this way per DataSource, depending on the application.
If you use this method, it is also necessary to schedule a job to regularly transfer the data to the BW delta queues ("update collective run"). However, you should note that reports delivered using the logistics extract structures Customizing cockpit are used during this scheduling. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313).There is no point in scheduling with the RSM13005 report for this update method since this report only processes V3 update entries. The simplest way to perform scheduling is via the "Job control" function in the logistics extract structures Customizing Cockpit. We recommend that you schedule the job hourly during normal operation - that is, after successful delta initialization.
In the case of a delta initialization, the document postings of the affected application can be included again after successful execution of the recompilation run in the OLTP (e.g OLI7BW, OLI8BW or OLI9BW), provided that you make sure that the update collective run is not started before all delta Init requests have been successfully updated in the BW.
In the posting-free phase during the recompilation run in OLTP, you should execute the update collective run once (as before) to make sure that there are no old delta extraction data remaining in the extraction queues when you resume posting of documents.
Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
If you want to use the functions of the logistics extract structures Customizing cockpit to make changes to the extract structures of an application (for which you selected this update method), you should make absolutely sure that there is no data in the extraction queue before executing these changes in the affected systems. This applies in particular to the transfer of changes to a production system. You can perform a check when the V3 update is already in use in the respective target system using the RMCSBWCC check report.
In the following cases, the extraction queues should never contain any data:
- Importing an R/3 Support Package
- Performing an R/3 upgrade
For an overview of the data of all extraction queues of the logistics extract structures Customizing Cockpit, use transaction LBWQ. You may also obtain this overview via the "Log queue overview" function in the logistics extract structures Customizing cockpit. Only the extraction queues that currently contain extraction data are displayed in this case.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) More than 10,000 document changes (creating, changing or deleting a document) are performed each day for the application in question.
b) In future delta initializations, you must reduce the posting-free phase to executing the recompilation run in R/3. The document postings should be included again when the delta Init requests are posted in BW. Of course, the conditions described above for the update collective run must be taken into account.
Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
With this update mode, the extraction data of the application in question continues to be written to the update tables using a V3 update module and is retained there until the data is read and processed by a collective update run.
However, unlike the current default values (serialized V3 update); the data is read in the update collective run (without taking the sequence from the update tables into account) and then transferred to the BW delta queues.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method since serialized data transfer is never the aim of this update method. However, you should note the following limitation of this update method:
The extraction data of a document posting, where update terminations occurred in the V2 update, can only be processed by the V3 update when the V2 update has been successfully posted.
This update method is recommended for the following general criteria:
a) Due to the design of the data targets in BW and for the particular application in question, it is irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence in which the data was generated in R/3.
Thanks,
JituK

What is differences extraction queue, delta queue and uddate queue ?

hi guru's
What is differences between extraction queue, delta queue and uddate queue ? can u describe briefly?
Thanks & Regards
nandi

Dear Prabha,
Basically when any document is posted in R/3, it is updated to the update table, from there it is taken to our delta queue for send it to BW side.
When extraction starts, data is sent to BW from delta queue. then again this cycle starts.
When you post any document in OLTP system (eg SAP R3),
say create sales order by VA01, then posting is made to application tables (VBAK/VBAP) through V1 and also to sm other tables through V2, Communication structure written to update queue/extraction queue/delta queue(directly) as per the update mode selected. V3 is always followed by V2 and we are supposed to schedule it.
From this delta queue, data is extracted by BW infopackages.
There are various update methods according to which extraction or delta queue are used, so when document posting takes place it also write data into extraction queue (through V1 update) and if we use queued delta method then this data is collected in collection run and written to delta queue and from this delta queue we request for data from BW.
There are lots of posts on SDN for this, please have a look on those.
one for your reference...
https://www.sdn.sap.com/irj/sdn/profile?userid=3507509
Hope it helps...
Message was edited by:
Ashish Tewari

Can anyone give me an example of direct, queued and unserialized delta?

hi all,
Can anyone give me an example of direct, queued and unserialized delta for fi and sd applications.
thanxs in advance
regds
hari

hi,
Update Methods,
a.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
a. Update methods: (serialized) V3
Transaction data is collected in the R/3 update tables
Data in the update tables is transferred through a periodic update process to BW Delta queue
Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
V2 Update errors can lead to V3 updates never to be processed
Update methods: direct delta
Each document posting is directly transferred into the BW delta queue
Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Less monitoring overhead of update data or extraction queue
Cons:
Not suitable for environments with high number of document changes
Setup and delta initialization have to be executed successfully before document postings are resumed
V1 is more heavily burdened
Update methods: queued delta
Extraction data is collected for the affected application in an extraction queue
Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Suitable for environments with high number of document changes
Writing to extraction queue is within V1-update: this ensures correct serialization
Downtime is reduced to running the setup
Cons:
V1 is more heavily burdened compared to V3
Administrative overhead of extraction queue
Update methods: Un-serialized V3
Extraction data for written as before into the update tables with a V3 update module
V3 collective run transfers the data to BW Delta queue
In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
V2 update has to be successful
hope it helps
partha

When use "Direct Delta", "Queued Delta" and "Unserialized V3"?

Hi, I saw here a loot of threads asking the diference between these update methods.
But my question is simple, When I use one or another?
Like, Direct Delta I can use in real time data aquisition! (it´s just an exemple, i do not know if is possible).
But to clarify the question of the use of this methods, some exemples of when is recommended to use one type or another will be very usefull.
Thanks

Hi Eduardo,
You can use the update mode in the below mentined scenarios
Direct Delta: You can use this delta if your have lower number of transactions i.e., Less number of document modifications. AS this results in lesser number of transactional data/Records to be picked.
Queued Delta: you can choose this update mode if you have more number of documents/trasactions with
more number of documents changes posted in ur R3 as it results in more in number trasactions.
Serialised Delta: It is the best method to get data to SAP BW.
In general if Supermarkets will opt for Queued Delta as they needs to record large number of transactions and for them this mode is best suited.
Direct Delta is opt by big companies where there will be lesser number of records and changes

Sequence of operations - Direct Delta, Queued Delta, Unserialized V3 Update

Is the below understanding about each update method correct?
a) Direct Delta
- The user selects a process (e.g. creating, updating or deleting a purchase order), fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the Application Tables.
- This or another module inserts delta relevant information (e.g.: before and after image, the key for deletion, reverse image, etc) about this PO in the Communication Structures.
- Another module reads the Comm Structures and inserts this information in the Delta Queue.
- COMMIT the operations in the App Tables and in the Delta Queue.
- The user receives a success message.
b) Queued Delta
- The user selects a process, fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the App Tables.
- This or another module inserts delta relevant information about this PO in the Comm Structures.
- Another module reads the Comm Structures and inserts this information in the Extraction Queue.
- COMMIT the operations in the App Tables and in the Extraction Queue.
- The user receives a success message.
- Periodically, a Collective Run inserts this information in the Delta Queue and deletes it from the Extraction Queue.
c) Unserialized V3 Update
- The user selects a process, fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the App Tables.
- COMMIT the operations in the App Tables.
- The user receives a success message.
- This or another module inserts delta relevant information about this PO in the Comm Structures.
- Another module reads the Comm Structures and inserts this information in the Information Structures (also known as Statistical Tables), as part of the LIS data flow u2013 as I understand it has nothing to do with LO data extraction, but it is coded this way.
- If the inserts into the Information Structures work well, another module reads the Comm Structures and inserts this information in the Update Table.
- Periodically, a Collective Run inserts this information in the Delta Queue and deletes it from the Update Table.
Thanks
César Menezes

Krishna
Thanks for your attention, but I've already read:
- Roberto Negrou2019s blogs,
- OSS Note 505700,
- Power point u201CNew Update Methods for Logistics Extraction with PI 2003.1u201D (quoted in the OSS Note, link u201Chttp://service.sap.com/~sapidb/011000358700005772172002u201D),
- many threads wich provided very useful information.
I need now more detailed information, step by step operation on each update method, like I posted in the thread.
Actually I want to cross this information with another thread I posted (), about Figure 6 (Comparison among call function hierarchies involved in different update methods).
This Figure is showed in Negrou2019s Episode Three and in the power point. I believe that this figure is wrong or at least is missing something.
Do you know about these two points, or can you please forward to someone who can help us ???
Thanks
César Menezes

LIS Extractor (LE Shippments) Direct Delta, no queue visible

Hi gurus,
I am new in data extraction and I have the following problem:
I am trying to set up the datasouces for deliveries (application 12) through the cockpit.
I have set the update mode to Direct Delta, I have deleted the setup tables, then performed initiaization. Everything seems to be ok BUT when I check RSA7 and SMQ1 for these queues, nothing is displayed. Ofcourse, I check after making some changes to one delivery.
Previously, when the update mode was Queued Delta, I could see these changes in SMQ1 but not in RSA7 (there was no queue at all).
Because I was not allowed to change the update mode as long as there were records in the outbound queue, I deleted this queue in SMQ1 and now, after changing it, it's no queue at all in the outbound queue monitor.
I hope I described the problem clearly and I hope you can help me. Points will be rewarded.
Thanks!
null

Hi Andreea,
Please see the following pdf for an explanation of the various update modes:
<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7312ec94-0501-0010-0da3-a49815566423#426,15,New Update Methods (II)">https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7312ec94-0501-0010-0da3-a49815566423#426,15,New Update Methods (II)</a>
For deliveries I would recommend staying with queued delta.

Direct delta and Quedue delta

Hi,
Direct delta :extraction data is directly loading into BW Delta queue.
Does this deltas will be loading BW delta queue or SMQ1?
In BW where it will be loading as first step and how abt Queue delta mechanism?

hi,
1. Direct delta.
When a Document is posted it first saved to the application table and also directly saved to the RSA7 (delta queue) from here it is being moved to BW.
so u can understand that for Delta flow inR/3 Delta queue is the exit point.
2. Queued Delta
When a document is posted it is saved to application table, and also saved to the Extraction Queue ( here is the different to direct delta) and you have to schedule a V3 job to move the data to the delta queue periodically and from their it is moved to BW.
hope this help you
regards
harikrishna N

How to delete the data in update queue and delta queue for Queued delta?

Dear BWers,
How do i delete the delta queue and update queue data before i fill the setup tables for a extraction based on Queued delta. Please help.
Thanks
Raj

Hi Raj,
I think you need some ground work for the LO extraction same as others here. Please read the 3 blogs expliciltly created for LIS by Robert Negro.
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
As well, the OSS 380078 would clear your doubts reagrding the the BW QUEUE mainatinance.
Please let me know if these material has been suffecient enough.
regarda,
raj

Queued delta, unserialised v3 update, direct delta

Can you any body tell what are the advantages between queued and other(Un serilised, direct) deltas.

Chk these links
What is a queued delta?
Disadvantages of Queued Delta
P.S : Always search the forums before creating a new thread.
Avoid redundant threads.
Regards,
Balaji V

Direct delta and Qued delta.............

Hi Gurus !
Both Direct delta and Qued delta in LO are independent of the success of the V2 Update process( Roberto Negro too mentioned this in his weblog).This means that V2 update Exists both in Direct and qued delta( Am I correct?).
As the data is written in the Delta que within V1 Update
for the case of direct delta, in Extraction que in Qued delta , where does the V2 Update come into the Picture?
Pls can anyone help in this regard.
Regards
Durai

Hi !
I am very eager to know the answer.
Regards
Durai

Queued delta enable extractions having entries in SM13. Is this correct?

I Have the following issue:
The 11 application module in LBWE is Queue delta enabled
But I am seeing the changes to VA02 in SM13. why is this?
Thanks
Simmi

Hi simmi:
when ever we change the structure (enhancements, user exit) to any LO extractor its always a good practice to make sure we transport the request to prod on the same day and also make sure we do our setup tables and re-initilization's on the same day. as mentioned by you, you have a time lag and i think thats causing you some discrepancies. any ways, check in SM13 and if you think you can sustain with the data volume go and do a INIT to capture everything. or else go according to the date whe you do a load.
assign points if helpful
kalyan

R/3 extraction.{direct delta and queued delta and V3}

Similar Messages

Maybe you are looking for