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.

Similar Messages

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

Direct Delta, Queued and Unseralized V3

HI
FOR IM datasources, BF and UM, the guide mentions Direct Delta as the preferred selection. How do we decide this?
Also for LO cockpit DS in SD, what selection is chosen?
Thanks
Harie

hi Harie,
take a look oss note 505700 -LBWE: New update methods as of PI 2002.1 and 500426 - BW extraction SD: alternatives to V3 updating
hope this helps.
505700
Symptom
Up to and including PI 2001.2 or PI-A 2001.2, only the "Serialized V3 update" update method was used for all applications of the logistics extract structures Customizing Cockpit. As a result of the new plug-in, three new update methods are now also available for each application.
The "Serialized V3 update" update method is no longer offered as of PI 2003.1 or PI-A 2003.1. Between installing PI 2002.1 or PI-A 2002.1 and installing PI 2003.1 or PI-A 2003.1, you should therefore switch to one of these new methods in all applications offering alternative update methods.
Rather than describing an error, this note helps you make the right selection of update methods for the applications relating to the logistics extract structures Customizing Cockpit.
Read this note carefully and in particular, refer to the essential notes required for some applications when using the new update methods.
You will also find more detailed information on the SAP Service Marketplace at: http://service.sap.com/~sapidb/011000358700005772172002
Or:
http://service.sap.com/BW > SAP BW InfoIndex > Delta Handling > New Update Methods in Logistics Extraction with PI2002.1 2.0x/3.0x (ppt)
Other terms
V3 update, V3, serialization, TMCEXUPD
Reason and Prerequisites
New design
Solution
1. Why should I no longer use the "Serialized V3 update" as of PI 2002.1 or PI-A 2002.1?
The following restrictions and problems with the "serialized V3 update" resulted in alternative update methods being provided with the new plug-in and the "serialized V3 update" update method no longer being provided with an offset of 2 plug-in releases.
a) If, in an R/3 System, several users who are logged on in different languages enter documents in an application, the V3 collective run only ever processes the update entries for one language during a process call. Subsequently, a process call is automatically started for the update entries from the documents that were entered in the next language. During the serialized V3 update, only update entries that were generated in direct chronological order and with the same logon language can therefore be processed. If the language in the sequence of the update entries changes, the V3 collective update process is terminated and then restarted with the new language.
For every restart, the VBHDR update table is read sequentially on the database. If the update tables contain a very high number of entries, it may require so much time to process the update data that more new update records are simultaneously generated than the number of records being processed.
b) The serialized V3 update can only guarantee the correct sequence of extraction data in a document if the document has not been changed twice in one second.
c) Furthermore, the serialized V3 update can only ensure that the extraction data of a document is in the correct sequence if the times have been synchronized exactly on all system instances, since the time of the update record (which is determined using the locale time of the application server) is used in sorting the update data.
d) In addition, the serialized V3 update can only ensure that the extraction data of a document is in the correct sequence if an error did not occur beforehand in the U2 update, since the V3 update only processes update data, for which the U2 update is successfully processed.
2. New "direct delta" update method:
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.
3. The new "queued delta" update method:
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. 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, 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.
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
- Importing a plug-in Support Packages
- Executing a plug-in 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 documents) 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.
4. The new "unserialized V3 update" update method:
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.
5. Other essential points to consider:
a) If you want to select a new update method in application 02 (Purchasing), it is IMPERATIVE that you implement note 500736. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBV302 report.
b) If you want to select a new update method in application 03 (Inventory Management), it is IMPERATIVE that you implement note 486784. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV303 report.
c) If you want to select a new update method in application 04 (Production Planning and Control), it is IMPERATIVE that you implement note 491382. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV304 report.
d) If you want to select a new update method in application 45 (Agency Business), it is IMPERATIVE that you implement note 507357. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV345 report.
e) If you want to change the update method of an application to "queued delta", we urgently recommended that you install the latest qRFC version. In this case, you must refer to note 438015.
f) If you use the new selection function in the logistics extract structures Customizing Cockpit in an application to change from the "Serialized V3" update method to the "direct delta" or "queued delta", you must make sure that there are no pending V3 updates for the applications concerned before importing the relevant correction in all affected systems. To check this, use transaction SA38 to run the RMCSBWCC report with one of the following extract structures in the relevant systems:
    Application 02:   MC02M_0HDR
    Application 03:   MC03BF0
    Application 04:   MC04PE0ARB
    Application 05:   MC05Q00ACT
    Application 08:   MC08TR0FKP
    Application 11:   MC11VA0HDR
    Application 12:   MC12VC0HDR
    Application 13:   MC13VD0HDR
    Application 17:   MC17I00ACT
    Application 18:   MC18I00ACT
    Application 40:   MC40RP0REV
    Application 43:   MC43RK0CAS
    Application 44:   MC44RB0REC
    Application 45:   MC45W_0HDR.
You can switch the update method if this report does return any information on open V3 updates. Of course, you must not post any documents in the affected application after checking with the report and until you import the relevant Customizing request. This procedure applies in particular to importing the relevant Customizing request into a production system.
Otherwise, the pending V3 updates are no longer processed. This processing is still feasible even after you import the Customizing request using the RSM13005 report. However, in this case, you can be sure that the serialization of data in the BW delta queues has not been preserved.
g) Early delta initialization in the logistics extraction:
As of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the delta initialization for selected DataSources.
Only the DataSources of applications 11, 12 and 13 support this procedure in the logistics extraction for PI 2002.1.
The early delta initialization is used to admit document postings in the OLTP system as early as possible during the initialization procedure. If an early delta initialization InfoPackage was started in BW, data may be written immediately to the delta queue of the central delta management.
When you use the "direct delta" update method in the logistics extraction, you do not have to wait for the successful conclusion of all delta Init requests in order to readmit document postings in the OLTP if you are using an early delta initialization.
When you use the "queued delta" update method, early delta initialization is essentially of no advantage because here, as with conventional initialization procedures, you can readmit document postings after successfully filling the setup tables, provided that you ensure that no data is transferred from the extraction queue to the delta queue, that is, an update collective run is not triggered until all of the delta init requests have been successfully posted.
Regardless of the initialization procedure or update method selected, it is nevertheless necessary to stop any document postings for the affected application during a recompilation run in the OLTP (filling the setup tables).
500426
Symptom
With the BW extraction with the structures of the logistics extract structures customizing cockpit there is only V3 updating as an update method up to plug-in release PI-2001.2.
To make every possible effort to ensure the transfer of document postings to BW in the correct sequence the parameter "SERIAL" was added to the V3 collective update (refer also to note 385099). If this parameter is set at the start of the V3 collective update, the update data is read and processed by the database in the sequence of its creation time.
However, this procedure gives rise to the following major performance problem:
If documents are entered in an application in an R/3 System by several users that are logged on in different languages, the V3 collective run will only ever process the update entries for one language in a process call. A process call is then started automatically for the update entries of the documents which were entered in the next language. Accordingly, during the serialized V3 update only update entries which were generated in direct chronological sequence and with the same logon language can ever be processed. If the language changes in the sequence of the update entries, the V3 collective update process is terminated and restarted with the new language.
During every restart, the update table VBHDR is read sequentially on the database. If there are very many entries in the update tables, this can cause the processing of the update data taking so much time that more new update records are generated simultaneously than are processed.
Furthermore, the serialization is not 100% guaranteed in all scenarios when the V3 update is used, as described also in note 384211.
From plug-in PI 2002.1 the option is offered for the most important applications of the logistics extract structures customizing cockpit of selecting between several alternative update methods.
The serialized V3 update is no longer provided from plug-in PI-2003.1.
The modification provided here enables you to use the new update methods for the applications 11, 12 and 13 as early as from patch 5 of PI 2001.2 or PI-A 2001.2.
The following update methods are offered:
direct delta (update mode A):
With this update mode the extraction data is transferred directly into the BW delta queues with every document posting. Every document posting with delta extraction becomes exactly one LUW in the corresponding BW delta queues.
If you use this method it is therefore no longer necessary to regularly schedule a job to transfer the data to the BW delta queues. Otherwise there will be a substantial increase in the number of LUWs per DataSource in the BW delta queues since, unlike previously, with V3 updating the deltas of many documents are grouped together to form an LUW in the BW delta queues.
Furthermore you should note when using this update mode that during delta initialization in an application, from the start of the recompilation run in the OLTP no document postings may be made until all delta Init requests have been updated successfully in BW. Otherwise data in documents posted in the interim will be irretrievably lost.
queued delta (Update mode B):
With this update mode the extraction data of the affected application is collected in an 'extraction queue' instead of in the update dataand can be transferred via an update collective run into the BW delta queues, as is already the case during V3 updating.
For each DataSource,1000 delta extractions are summarized by documents of the application to form an LUW in the BW delta queues.
If you are using this method it is thus also necessary to regularly schedule a job for transferring the data to the BW delta queues. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313). You are recommended to schedule the job on an hourly basis in normal operation - that is following the successful delta initialization.
In the case of a delta initialization the document postings of the affected application can be included again after the successful execution of the recompilation run in the OLTP (OLI7BW, OLI8BW or OLI9BW) if you ensure that the update collective run is not started before all delta Init requests are updated successfully in BW.
In the posting-free phase during the recompilation run in the OLTP - as previously - the update collective run should be be run once successfully to ensure that there is no old delta extraction data in the extraction queues during the reinsertion of the document posting.
Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
unserialized V3 update (update mode C):
With this update mode the extraction data of the affected application is written to the update tables as before with the aid of a V3 update module and kept there until the data is read and processed by an update collective run.
However, unlike the current default values (serialized V3 update), in the update collective run the data is read and transferred to the BW delta queues without taking into account the sequence from the update tables. This is why the performance problem described above does not arise in this case.
This method should only be used if, due to the design of the cubes or ODS objects in the BW system, it does not matter whether the data is transferred to BW in exactly the same sequence in which it was generated in the OLTP System.
Other terms
V3 update
Reason and Prerequisites
Additional desired functions.
Solution
If you already want to use one of the above-described new update methods in the applications 11, 12 or 13 with PI 2001.2 or PI-A 2001.2, you can do this with the corrections given here. However, it is vital that you bear in mind the following points:
1. The corrections described here consist ofa modification which is not included in any PI Support Package. Check whether the described corrections are necessary. When you import a PI Support Package, parts of these corrections may be overwritten. When importing the PI Support Package ensure that you have got all of these corrections (SPAM/SPAU).
2. Only copy these modifications in consultation with SAP logistics extraction development.
3. The corrections presented here should only ever be regarded as an interim solution. The functions are only fully available with PI 2002.1 and PI-A 2002.1. You should also consider the option of upgrading soon to PI 2002.1 or PI-A 2002.1.
Note also that if the update methods of the applications 11, 12 and 13 are changed prematurely, other applications can still only offer the serialized V3 update. The performance problem described above continues to apply to these applications. It should, however, be significantly reduced by the absence of the modules of applications 11, 12 and 13.
4. The corrections described here necessitate the importing of Support Package 5 of PI 2001.2 or PI-A 2001.2. The corrections described here are not possible in a lower plug-in release or Support Package status since the functions of the new update methods are not available.
5. If you want to change the update method of an application to "queued delta", you are strongly recommended to first install the most current qRFC version. Refer to note 438015.
6. If you use the corrections below to change from the update method "Serialized V3" to "Direct delta" or "queued delta" in an application, you must ensure that before the corresponding corrections are imported there are no more open V3 updates for the corresponding applications in all affected systems. To check this, you can execute the report RMCSBWCC in the corresponding systems with transaction SA38 with one of the following extract structures:
    Application 11:   MC11VA0HDR
    Application 12:   MC12VC0HDR
    Application 13:   MC13VD0HDR.
The change is possible if you are not referred to open V3 updates. Of course, no document postings should be made in the affected application after the check with the report until the transfer of the corrections. This procedure applies in particular to the importing of the corrections into a production system.
7. If you are already using the update mode "queued delta" with one of the applications 11, 12 or 13 with the corrections stored here before PI 2002.1 and if you want to make changes to the extract structures in this phase via the cockpit, you should ensure that there is no data in the extraction queues before you execute these changes in the affected systems. In particular this applies to the transportation of changes into a production system. In this case it is not sufficient to execute the check report RMCSBWCC recommended in the cockpit and to eliminate the problem areas specified there.
Below we describe how you can check and ensure this condition.
8. When you import PI 2002.1 the changes made here will always be ineffective and you will get the update method "serialized V3" again as the preset update method.
If you have already changed to a different update method in advance in one of the applications 11, 12 or 13 via the corrections stored here, you must consider the following points during the plug-in upgrade to PI 2002.1 or PI-A 2002.1:
a) Before the upgrade you must ensure that there is no more data in the extraction queues MCEX11, MCEX12 and MCEX13. Otherwise it may no longer be possible to process the data, which may have to be deleted from the queues, due to an extract structure enhancement with the new plug-in. You can do this by starting the collective update report (RMBWV311, RMBWV312 or RMBWV313) and by subsequently checking the extraction queues using transaction SMQ1.
b) After the upgrade you must ensure that before the inclusion of new document postings, the update method of the corresponding application used in advance by the corrections specified here is also set in the cockpit of the logistics extraction (LBWE), and that this setting is transported into all clients of the affected systems.
Note in this context that the corrections specified here change the update method so that it is client-independent. The new functions in the cockpit of the logistics extraction from PI 2002.1 or PI-A 2002.1 then allow the client-specific selection of the update methods.
9. If you want to use the update method "direct delta" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
10. If you want to use the update method "direct delta" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
11. If you want to use the update method "direct delta" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
12. If you want to use the update method "queued delta" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
13. If you want to use the update method "queued delta" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
14. If you want to use the update method "queued delta" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
15. If you want to use the update method "unserialized V3 update" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
16. If you want to use the update method "unserialized V3 update" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
17. If you want to use the update method "unserialized V3 update" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).

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

Delta load - LIS extractor to several target - test load to single target

Hi
I want have a daily delta load from a LIS extractor to 3 targets (ODS's). I would like to make a test delta load to one of the 3 targets (because it has been reconstructed).
Will it cause any problems if I make a delta load from the LIS extractor to one of the targets and not all of the targets? Will the records that I loaded in my test load arrive in the two other targets when the daily delta runs later on?
Kind regards,
Torben

Hi Torben,
you can do this if you first load the data to PSA, because when you load the data with delta infopack the delta queue will be reset in source system. But the data will remain in PSA, so you can upload again (to same infoprovider or different one if update rules exists) from PSA.
Sarhan.

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

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

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

Direct Delta, queued , Non-serialized V3 Update

could someone out here help me in understanding the Direct Delta, queued , Non-serialized V3 Update...
i mean a detailed level explanation.... or just in case u have any document then kindly pass it on.... to [email protected]

Hi,
Update Methods,
a.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
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 extraction is posted for exactly one LUW in the respective BW delta queues.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
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.
(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
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
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
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 this helps
regards
CSM Reddy

Direct delta, serialized delta, unserialised delta, queued delta

I want to know the difference between these four;
1. Direct delta
2. Serialized Delta
3. Unserialized Delta
4. Queued Delta

Hi,
refer to this .../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

Extension of LIS extractor - possible to delta enable field from Z-table?

Hi Experts
We have to get data from a date field in a custom Z-table (delivery related) in R/3 to BW.
We would like to get the date by extending a delivery LIS extractor with a new field and make some ABAP to lookup the correct value in the custom Z-table.
A requirement is though that if the date in Z-table is changed then we need to get the update value to BW. Therefore, we need to delta enable the new field in the append structure - but that ain't possible is it?
Alternatively will we have to make a new DataSource based on the custom Z-table and somekind of full load (with a fake delta).
Thanks.
Kind regards,
Torben

Torben,
If your custom Z-table does not contain too much data and doesn't change too often it might be an option to turn on DB logging (Technical settings -> Log data changes). Do not do this for large tables containing transactional data as the logs will consume a lot of diskspace!
Each insert/mod/deletion will be logged and in in a user-exit you can use FM DBLOG_READ_WITH_STATISTIC to check if something has changed and then append the corresponding data to your data package.
Grtx!
Marco

Difference between Direct delta and delta Queue

Hi,
1.ease explain me the concept of Direct delta and delta queue in LO extraction
2.Why set up tables are used and initially why the data is deleted for th setup tables.
3.Please explain me the LO extraction with an example.
Thanks
Alok

Dear Aloka,
1.
Direct delta:
transactional data or application posting will be directly available in the delta queue table with out any intermediate tables. then that data will be extracted from r/3 to bw.
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
Queued delta:
first the data posting will available in the extraction queue table. then there periodic job run take that data to queued delta table.
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
2.
Setup tables are used for Full/Initial Update.
Instead of pulling data from DB Tables directly, we r filling Setup tables and extracting data from the Setup tables, which dont have performance impact on DB Tables.
Setup tables are application specific.
It is cautious method to delete Setup tables before filling it for a specific DataSource.
3.
Re: LO-Cockpit V1 and V2 update
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Regards,
Ram.

Direct Delta behaviour in a BI 7.0 Upgrade

Hi all,
We are in an BI Upgrade process and a doubt raises regarding DIRECT delta.
Scenario:
The BW 3.1 will upgrade to BI 7.0 but the R/3 4.7 will remain the same.
There are some r/3 logistics extractors with DIRECT delta enabled.
Considering the Upgrade best practices is recommended to stop the V3 process in r/3 side, but the Direct Delta has no V3 process, so, which are the reccomendations for upgrade process considering DIRECT-DELTA ?
Can R/3 Direct-delta remain active during the BI Upgrade or should we stop the current delta and re-initialize 'without any data' after upgrade ?
Best Regards,
Mauro.

Kedar,
Most of the cases, the BI Upgrade process takes from 2 to 4 days, so is very difficult to keep the productive r/3 system sttoped for the logistic processes.
Our plan is :
     1) block the users in r/3 side until the delta queue has been emptied.
     2) load from r/3 to BW all Delta data from delta queue.
     3) make sure all delta load were made and the QM status are green in the BW side.
     4) unblock the users in r/3 side after the step 3. (Delta queue is free to new postings)
     5) initialize the PREPARE phase for BI migration.
     6) Execute the Upgrade
     7) Restablish the r/3 source system
     8) Execute the delta loads from r/3 (to obtain the delta data since step 4)
Do you think that will it work ?
Regards,
Mauro.

Setup table Administration with Direct Delta mode

Hi guys,
I have a direct delta as update mode for my 2LIS_11_VAITM extractor in R/3.
I'd like to know if I have to manage the relative setup table (MC11VA0ITMSETUP) with this update mode also.
For instance, If I delete an ODS content and restart a new INIT on BW system, do I need to delete and then to fill the setup table?
In general, Do I need always to menage the setup table with each kind of update mode (direct delta, queued delta and V3 update)?
if you know the answers, please reply me direcly without insert link.
Many Thanks.

yes, you do....the initial loads for lo datasources are completely independent of the delta loads and hence of the delta method...
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
M.

"Direct Delta" Update Method - Why need for Collective update

Hi folks,
I have been going through LO Cockpit in detail and read quite extensively about new update methods and still have one doubt.
1)Why there is "Job control" for "Direct Delta" Update method in LO Cockpit?.
If I understand Direct Delta correctly, Application data is directly posted to Delta Queue by SAP Update management using V1 and when the Delta request comes from BW it is read from the Delta queue. So...
2)why bother about collective run and
3)where exactly are we going to collect from - there is no intermediate storage like extraction Q or update tables?
One more question. I noticed that Delta queue is a stopped qRFC. what does this mean?

Hi Jay,
These questions have been answered by Roberto Negro in full detail of his 3 episode Blog...
Please read his blog.
Click Weblogs above and search for Roberto Negro.
--Jkyle

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

Similar Messages

Maybe you are looking for