sapnote_0000505700

26.10.2012 Page 1 of 7

SAP Note 505700 - LBWE: New update methods as of PI2002.1

Note Language: English Version: 11 Validity: Valid Since 21.07.2004

Summary

SymptomUp to and including PI 2001.2 or PI-A 2001.2, only the "Serialized V3update" update method was used for all applications of the logisticsextract 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 PI2003.1 or PI-A 2003.1. Between installing PI 2002.1 or PI-A 2002.1 andinstalling PI 2003.1 or PI-A 2003.1, you should therefore switch to one ofthese new methods in all applications offering alternative update methods.Rather than describing an error, this note helps you make the rightselection of update methods for the applications relating to the logisticsextract structures Customizing Cockpit.

Read this note carefully and in particular, refer to the essential notesrequired for some applications when using the new update methods.

You will also find more detailed information on the SAP ServiceMarketplace at: http://service.sap.com/~sapidb/011000358700005772172002Or:http://service.sap.com/BW > SAP BW InfoIndex > Delta Handling > New UpdateMethods in Logistics Extraction with PI2002.1 2.0x/3.0x (ppt)

Other termsV3 update, V3, serialization, TMCEXUPD

Reason and PrerequisitesNew design

Solution

1. Why should I no longer use the "Serialized V3 update" as of PI 2002.1or PI-A 2002.1?

The following restrictions and problems with the "serialized V3update" resulted in alternative update methods being provided with thenew plug-in and the "serialized V3 update" update method no longerbeing provided with an offset of 2 plug-in releases.

a) If, in an R/3 System, several users who are logged on in differentlanguages enter documents in an application, the V3 collective runonly ever processes the update entries for one language during aprocess call. Subsequently, a process call is automatically startedfor the update entries from the documents that were entered in thenext language. During the serialized V3 update, only update entriesthat were generated in direct chronological order and with the samelogon language can therefore be processed. If the language in thesequence of the update entries changes, the V3 collective updateprocess is terminated and then restarted with the new language.For every restart, the VBHDR update table is read sequentially on

26.10.2012 Page 2 of 7


the database. If the update tables contain a very high number ofentries, it may require so much time to process the update datathat more new update records are simultaneously generated than thenumber of records being processed.

b) The serialized V3 update can only guarantee the correct sequence ofextraction data in a document if the document has not been changedtwice in one second.

c) Furthermore, the serialized V3 update can only ensure that theextraction data of a document is in the correct sequence if thetimes have been synchronized exactly on all system instances, sincethe time of the update record (which is determined using the localetime of the application server) is used in sorting the update data.

d) In addition, the serialized V3 update can only ensure that theextraction data of a document is in the correct sequence if anerror did not occur beforehand in the U2 update, since the V3update only processes update data, for which the U2 update issuccessfully processed.

2. New "direct delta" update method:

With this update mode, extraction data is transferred directly to theBW delta queues every time a document is posted. In this way, eachdocument posted with delta extraction is converted to exactly one LUWin the related BW delta queues.If you are using this method, there is no need to schedule a job atregular intervals to transfer the data to the BW delta queues. On theother hand, the number of LUWs per DataSource increases significantlyin the BW delta queues because the deltas of many documents are notsummarized into one LUW in the BW delta queues as was previously thecase for the V3 update.If you are using this update mode, note that you cannot post anydocuments during delta initialization in an application from the startof the recompilation run in the OLTP until all delta init requestshave been successfully updated successfully in BW. Otherwise, datafrom documents posted in the meantime is irretrievably lost.

The restrictions and problems described in relation to the "SerializedV3 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 ordeleting documents) are accrued between two delta extractions forthe application in question. A (considerably) larger number of LUWsin the BW delta queue can result in terminations during extraction.

b) With a future delta initialization, you can ensure that nodocuments are posted from the start of the recompilation run in R/3until all delta-init requests have been successfully posted. Thisapplies particularly if, for example, you want to include moreorganizational units such as another plant or sales organization inthe extraction. Stopping the posting of documents always applies tothe entire client.

26.10.2012 Page 3 of 7


3. The new "queued delta" update method:

With this update mode, the extraction data for the affectedapplication is compiled in an extraction queue (instead of in theupdate data) and can be transferred to the BW delta queues by anupdate collective run, as previously executed during the V3 update.Up to 10,000 delta extractions of documents to an LUW in the BW deltaqueues are cumulated in this way per DataSource, depending on theapplication.If you use this method, it is also necessary to schedule a job toregularly transfer the data to the BW delta queues ("update collectiverun"). However, you should note that reports delivered using thelogistics extract structures Customizing cockpit are used during thisscheduling. There is no point in scheduling with the RSM13005 reportfor this update method since this report only processes V3 updateentries. The simplest way to perform scheduling is via the "Jobcontrol" function in the logistics extract structures CustomizingCockpit. We recommend that you schedule the job hourly during normaloperation - that is, after successful delta initialization.In the case of a delta initialization, the document postings of theaffected application can be included again after successful executionof the recompilation run in the OLTP, provided that you make sure thatthe update collective run is not started before all delta Initrequests have been successfully updated in the BW.In the posting-free phase during the recompilation run in OLTP, youshould execute the update collective run once (as before) to make surethat there are no old delta extraction data remaining in theextraction queues when you resume posting of documents.

If you want to use the functions of the logistics extract structuresCustomizing cockpit to make changes to the extract structures of anapplication (for which you selected this update method), you shouldmake absolutely sure that there is no data in the extraction queuebefore executing these changes in the affected systems. This appliesin particular to the transfer of changes to a production system. Youcan perform a check when the V3 update is already in use in therespective target system using the RMCSBWCC check report.

In the following cases, the extraction queues should never contain anydata:

- 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 logisticsextract structures Customizing Cockpit, use transaction LBWQ. You mayalso obtain this overview via the "Log queue overview" function in thelogistics extract structures Customizing cockpit. Only the extractionqueues that currently contain extraction data are displayed in thiscase.

The restrictions and problems described in relation to the "SerializedV3 update" do not apply to this update method.


26.10.2012 Page 4 of 7


a) More than 10,000 document changes (creating, changing or deleting adocuments) are performed each day for the application in question.

b) In future delta initializations, you must reduce the posting-freephase to executing the recompilation run in R/3. The documentpostings should be included again when the delta Init requests areposted in BW. Of course, the conditions described above for theupdate 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 inquestion continues to be written to the update tables using a V3update module and is retained there until the data is read andprocessed by a collective update run.However, unlike the current default values (serialized V3 update), thedata is read in the update collective run (without taking the sequencefrom the update tables into account) and then transferred to the BWdelta queues.

The restrictions and problems described in relation to the "SerializedV3 update" do not apply to this update method since serialized datatransfer is never the aim of this update method. However, you shouldnote the following limitation of this update method:

The extraction data of a document posting, where update terminationsoccurred in the V2 update, can only be processed by the V3 update whenthe V2 update has been successfully posted.


a) Due to the design of the data targets in BW and for the particularapplication in question, it is irrelevant whether or not theextraction data is transferred to BW in exactly the same sequencein 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, thedata will still be written to the V3 update. The update data canthen 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 note486784. Otherwise, even if you have selected another update method,the data will still be written to the V3 update. The update datacan 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 youimplement note 491382. Otherwise, even if you have selected anotherupdate method, the data will still be written to the V3 update. The

26.10.2012 Page 5 of 7


update data can then no longer be processed using the RMBWV304report.

d) If you want to select a new update method in application 45 (AgencyBusiness), it is IMPERATIVE that you implement note 507357.Otherwise, even if you have selected another update method, thedata will still be written to the V3 update. The update data canthen 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 latestqRFC version. In this case, you must refer to note 438015.

f) If you use the new selection function in the logistics extractstructures Customizing Cockpit in an application to change from the"Serialized V3" update method to the "direct delta" or "queueddelta", you must make sure that there are no pending V3 updates forthe applications concerned before importing the relevant correctionin all affected systems. To check this, use transaction SA38 to runthe RMCSBWCC report with one of the following extract structures inthe 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 anyinformation on open V3 updates. Of course, you must not post anydocuments in the affected application after checking with thereport and until you import the relevant Customizing request. Thisprocedure applies in particular to importing the relevantCustomizing request into a production system.

Otherwise, the pending V3 updates are no longer processed. Thisprocessing is still feasible even after you import the Customizingrequest using the RSM13005 report. However, in this case, you canbe sure that the serialization of data in the BW delta queues hasnot 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 deltainitialization to perform the delta initialization for selectedDataSources.Only the DataSources of applications 11, 12 and 13 support thisprocedure in the logistics extraction for PI 2002.1.

26.10.2012 Page 6 of 7


The early delta initialization is used to admit document postingsin the OLTP system as early as possible during the initializationprocedure. If an early delta initialization InfoPackage was startedin BW, data may be written immediately to the delta queue of thecentral delta management.

When you use the "direct delta" update method in the logisticsextraction, you do not have to wait for the successful conclusionof all delta Init requests in order to readmit document postings inthe OLTP if you are using an early delta initialization.

When you use the "queued delta" update method, early deltainitialization is essentially of no advantage because here, as withconventional initialization procedures, you can readmit documentpostings after successfully filling the setup tables, provided thatyou ensure that no data is transferred from the extraction queue tothe delta queue, that is, an update collective run is not triggereduntil all of the delta init requests have been successfully posted.

Regardless of the initialization procedure or update methodselected, it is nevertheless necessary to stop any documentpostings for the affected application during a recompilation run inthe OLTP (filling the setup tables).

Header DataRelease Status: Released for CustomerReleased on: 21.07.2004 14:31:25Master Language: GermanPriority: Recommendations/additional infoCategory: ConsultingPrimary Component: BW-BCT-LO Logistics - General

The Note is release-independent

Related Notes

Number Short Text762951 Organization of structure changes in the LBWE728687 Delta queued: No data in RSA7652310 LBWE: Message MCEX 140 with extract structure change637312 Changing the fallback update method589997 SYSTEM_IMODE_TOO_LARGE dump during update from LBWQ

26.10.2012 Page 7 of 7


Number Short Text567747 Composite note BW 3.x performance: Extraction & loading507357 LO-AB BW extraction: Enhancements for Plug-In 2002.1500736 BW: Enhancements in Purchasing for PI 2002.1491382 Preparations for new update methods as of PlugIn 2002.1486784 BW extraction MM-IM: Enhancements for Plug-In PI 2002.1328181 Changes to extraction structures in Customizing Cockpit

Attributes

Attribute ValueTransaction codes SA38

Documents

sapnote_0000505700