LO Extraction Part 4 Update Methods

Transcription

1 LO Extraction Part 4 Update Methods Applies to: SAP BI, Business Intelligence, NW2004s. For more information, visit the EDW homepage. Summary This part of the article series explains the various update modes and the working methodology in LO extraction. Author: P Renjith Kumar Company: SAP Labs India PVT Ltd Created on: 19 August 2010 Author Bio P Renjith Kumar is presently working in SAP Labs India PVT Ltd and specializes in Extraction and Modeling areas of BI. Basically as an ABAP consultant, he has extensive cross functional experience and has been with end to end SAP ERP and BI implementation projects across manufacturing domain SAP AG 1

2 Table of Contents Prerequisite... 3 Introduction... 3 Direct Delta:... 3 Queued Delta:... 3 Non-serialized V3 Update:... 3 Unserialized V3 Update... 4 When to use this?... 4 Queued Delta... 5 Benefits and Features of the Queued Delta :... 6 Direct Delta... 9 Concept... 9 Performance Factor... 9 When you can use this? Benefits and Features of the Direct Delta : Tables for update methods Related SAP OSS note Related SAP OSS note Related Content Reference to my previous articles Copyright SAP AG 2

3 Prerequisite Kindly read the previous 3 part of the article, it will make you to feel comfortable to read this article. Introduction In Transaction LBWE you can see three different update methods, now we will see that in detail. With PI the following new update methods for logistics extraction will be offered: Direct Delta Queued Delta 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 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. This is shown below Now we will see the document flow during the different update modes SAP AG 3

4 Unserialized V3 Update The extraction data of the application being viewed is written to the Update Queue with an V3 update module and is kept there until the data is read with an update collection run and processed. 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. Note: In this mode, the delta records may not arrive in the same order in the BW as they were generated in the OLTP system. In particular, this can cause problems in the BW when using ODS objects. The method Unserialized V3 Update does not ensure serialization of the document data. Update to the DataStore objects is not recommended if serialization is desired. When to use this? 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. Note: Scheduling V3 Update in parallel The V3 update already uses collective processing. You cannot do this in parallel SAP AG 4

5 Queued Delta The extraction data from the concerned application is collected in an Extraction Queue. Then the data will be transferred to Delta queue, in a similar manner to the V3 update, with an update Collections run. 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 SAP AG 5

6 Benefits and Features of the Queued Delta : By writing in the extraction queue within the V1 update process, the serialization of documents is ensured by using the enqueue concept for the applications. By collecting data in the extraction queue that is processed regularly (preferably hourly, as recommended), this process is especially recommended for customers with a high occurrence of documents. The collective run uses the same reports as before (RMBWV3<Appl.-No.>,...). Report RSM13005 will not be provided any more. By collecting new document data during the delta-init request, the downtime in the initialization process can be reduced for the reconstruction run (filling of the setup tables). V1 immeasurably more burdened than by using V3. Collective run clearly performs better than the serialized V3. Especially the critical aspect of multiple languages does not apply here. Event Handling possible. In contrast to the V3 collective run, a definite end for the collective run is measurable, and a subsequent process can be scheduled. After the collective run for an application has ended, an event (&MCEX_11,...) is automatically triggered which, if defined, can be used at the start of the subsequent job. Extraction is independent of success of the V2 update. Note: 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 SAP AG 6

7 Note: 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 When to use this method? More than 10,000 document changes (creating, changing or deleting a documents) are performed each day for the application in question SAP AG 7

8 Useful reports in Queued delta The deltas for logistics extractor are moved depending on the setup of Job Control in LBWE.To manually move the deltas we can run the R/3 programs depending on Application Components.Use the following programs to move the deltas manually.go to transaction SE38 in R/3 and run the relevant program to move data from LBWQ to RSA7. 02 Purchasing RMBWV Inventory Controlling RMBWV Shop Floor Control RMBWV Shipment RMBWV SD Sales BW RMBWV LE Shipping BW RMBWV SD Billing BW RMBWV SAP AG 8

9 Direct Delta The extracted data is transferred directly to the delta queue with the Document Posting. Thus the sequence of the transfer of document agrees with the chronological order of data creation. Concept 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. Performance Factor 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. Note: 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 SAP AG 9

10 When you can use this? 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. Benefits and Features of the Direct Delta : By writing in the delta queue within the V1 update process, the serialization of documents is ensured by using the enqueue concept for applications. For customers with a low occurrence of documents, the process is recommended if a downtime is possible in the initialization process during the reconstruction and the delta-init request. V1 is more heavily burdened by this process than with V3 or the delta queue. But for customers with the above-mentioned document occurrence, this is certainly not critical. Extraction is independent of V2 update. Additional monitoring of update data or extraction queue does not apply 2010 SAP AG 10

11 Tables for update methods The update methods are stored in the new customizing table TMCEXUPD: LO Data Extraction: Update Control of Applications The field MCAPP denotes application and Update Mode gives details on update mode 2010 SAP AG 11

12 2010 SAP AG 12

13 Related SAP OSS note LBWE: New update methods as of PI Changes to extraction structure in Customizing cockpit 2010 SAP AG 13

14 Related Content Please include at least three references to SDN documents or web pages. SDN SAP Help Reference to my previous articles LO Extraction Part 1 SD Overview ecdeb4e53ff1?quicklink=index&overridelayout=true LO Extraction Part 2 Database Update Logic af09a680f591?quicklink=index&overridelayout=true LO Extraction Part 3 Extractor Logic 8b559bf0f75b?QuickLink=index&overridelayout=true For more information, visit the EDW homepage 2010 SAP AG 14

15 Copyright Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iseries, pseries, xseries, zseries, eserver, z/vm, z/os, i5/os, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this docume nt serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty SAP AG 15