New Update Methods for Logistics Extraction with PI 2003.1

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

Delta Extraction with the V3 Update (I) For updating the extraction of transaction data into the logistics applications (MM, PP, SD, LE,...), the technology for collective updates (“V3 updates”) is currently used. This means that the data is collected for the BW system (“delta queue”) in the R/3 update tables before the transfer to the interface. The data is then retrieved there by means of a periodic update process that needs to be started. During this V3 collective run, the data is transferred to the “BW delta queue”, from which they are retrieved by means of “requests” from the BW system.

Delta Extraction with the V3 Update (II) Data Flow Schematic for Logistics Extraction with the V3 Update Document 1 V1 V3 Module Call Docu. Tables Document 2 V1 V3 Module Call Docu. Tables V3 Collective Run (for example, daily or hourly) Delta Request Document n V1 V3 Module Call Docu. Tables Reading and processing of all existing LUWs for a DataSource B BW (PSA, ODS, Cube) Transfer to BW Reading and processing of all existing update data for a module A Delta Queue (Stopped qRFC) One LUW, One Commit Update Tables Time

Delta Extraction with the V3 Update (III) Since updating in ODS objects is permitted in the logistics extraction of transaction data for almost all DataSources, the requirement consists of the delta information in the same sequence to be transferred to the BW system as it occurred in the OLTP system. For example, the consistent storage of status fields in ODS objects can only be ensured with this prerequisite. Thus, the sequence of the existing data records is recognized and taken into account when reading and processing the update data (step A), as well as when transferring data to the BW system (step B). Since the V3 update actually does not recognize the serialized processing of update data, the “Serialized V3 Update” function was created through several corrections in SAP Basis in order to also be able to serialize in step A.

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

Problems with the V3 Update (I) The following problems continue to occur in conjunction with the V3 update in the logistics extraction of transaction data: The serialized V3 update can only ensure the correct sequence of extraction data for a document if the document is not repeatedly changed within the span of a second. Furthermore, the serialized V3 update can only ensure the correct sequence of extraction data for a document if the times are permanently and exactly synchronized for all instances in a system. This is because the creation time of the update record, which is determined by the local time for the application server, is used for sorting the update data. In addition, the serialized V3 update can only ensure the correct sequence of extraction data for a document if it previously had no errors in the V2 update. This is because the V3 update only processes the update data that is successfully processed with the V2 update. Independently of the serialization, update errors that occur in the V2 update of a transaction and which cannot be reposted have the consequence that the V3 updates for the transaction that are still open can never be processed. This can thus lead to inconsistencies in the data in the BW system.

Problems with the V3 Update (II) Multiple Language Problems in a Serialized V3 Update: If there are application documents within an R/3 system from several different users that are logged on to the system in different languages, the V3 collective run always processes the update entries for just one language within a process call. Subsequently, a process call for the update entries for the documents created in the next language is started automatically. Thus, with the serialized V3 update, only the update entries can be processed that were created in a direct, timely sequence and with the same logon language. If the language is changed within the update entry sequence, the V3 collective updating process ends and is reset with the new language. With each reset, the update table VBHDR is read from the database. If a high number of entries exists in the update tables, this can lead to the processing of update data requiring so much time that, concurrently, more new update records are created than are processed.

Problems with the V3 Update (III) Multiple Language Problems in a Serialized V3 Update VBHDR (Each step is a full table scan) :EN: VA01 :EN: VA02 :DE: VA02 :EN: VA01 ....... :EN: VA01 :DE: VA02 ....... :DE: VA02 :EN: VA01 ....... :EN: VA02 ....... Normal V3 Collective Run Serialized V3 Collective Run Step 1: Language :EN: Step 1: Language :EN: Step 2: Language :DE: Step 2: Language :DE: Step 3: Language :EN: Step 4: Language :DE: Step 5: Language :EN:

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

Essential Features with Extraction Updates All serialization and performance problems with the V3 update would be circumvented in logistics extraction if, with document postings, the extraction transferred the extraction data directly into the delta queue, instead of transferring it into the update tables as “temporary storage”. However, the consequence would be that each document posting in the OLTP system would result in exactly one LUW per DataSource in the delta queue. For customers that have a high number of document changes daily, this can lead to having a delta queue that is no longer able to be read. Furthermore, in this solution scenario you would need to ensure with the first document postings after a delta initialization that not only the reconstruction run is already completed in the OLTP system, but also that the delta-init requests in the BW system have successfully ended. Otherwise, the deltas for the first document postings would be irretrievably lost, because the delta queue would not yet be able to include the data. Thus, for customers that have a high number of document changes, an update method is provided that enables the collection of extraction data for the delta queue (in a similar way to the update tables with the V3 update) in order to then transfer the data periodically and compressed into the delta queue.

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

New Update Methods (I) With PI 2002.1 the following new update methods for logistics extraction will be offered: 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.

New Update Methods (II) Data Flow Schematic for Logistics Extraction with Direct Delta Document 1 V1 Docu. Tables Extraction Module with V1 Update Document 2 V1 Docu. Tables Extraction Module with V1 Update Delta Request Document n V1 Extraction Module with V1 Update Docu. Tables Reading and processing of all existing LUWS for a DataSource B BW (PSA, ODS, Cube) Transfer to BW Delta Queue (Stopped qRFC) Time

New Update Methods (III) 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.

New Update Methods (IV) Data Flow Schematic for Logistics Extraction with Queued Delta Document 1 V1 Filling extraction queue from the V1 update Docu. Tables Document 2 V1 Docu. Tables Filling extraction queue from the V1 update Extraction Collective Run (recommended hourly) Delta Request Document n V1 Docu. Tables Filling extraction queue from the V1 update Reading and processing of all existing LUWs for a DataSource B Reading and processing of all entries in the extraction queue for an application A Delta Queue (Stopped qRFC) One LUW, One Commit BW (PSA, ODS, Cube) Transfer to BW Extraction Queue Time

New Update Methods (V) 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.

Affected Applications - Availability 02 – Purchasing 03 – Inventory Control 04 – Manufacturing 05 – Quality Management 08 – Transport 11 – SD Verkauf BW 12 – LE Versand BW 13 – SD Faktura BW 17 – Plant Maintainance 18 – Customer Care 45 – Agency Business 40 – Retail 43 – Retail POS Kassierer 44 – Retail POS Bons PI 2002.1 PI 2003.1

New Update Methods (PI 2002.1) The new update methods are available for selection together with the update method “Serialized V3 Update” in the Logistics Extraction Structures Customizing Cockpit (LBWE) for each application: PI 2002.1 Old Method New Methods New methods are optional

New Update Methods (VII) The new function from the logistics queue overview (LBWQ) is available for monitoring the extraction queues instead of former SM13 transaction. It can also be called up from the pushbutton in the Cockpit:

PI 2003.1 - Available Update Methods New methods are mandatory

Migration Procedure The migration to the new update methods will happen automatically during the upgrade. The following preconditions are escential: The update tables of the particular application have to be empty. All entries within V3 Update for the particular application have to be processed. All entries in the Extraction Queue (transaction LBWQ) have to be processed. After successfull migration the Extraction Queue entries have to be collected into the Delta Queue via the Reports RMBWV3<Appl.- No.>

Agenda Delta Extraction with the V3 Update Problems with the V3 Update Essential Features New Update Methods Technical Details

Technical Details (I) In the first delivery with PI 2002.1, the update method “Serialized V3 Update” is delivered for the first time as a default setting in order to ensure upward compatibility and to allow the customers to get to know the new methods themselves. The update method “Serialized V3 Update” will no longer be offered as of a later Plug-In (planned with PI 2003.1). The update methods are stored in the new customizing table TMCEXUPD. For applications that are delivered with PI 2002.1 and have no entries in table TMCEXUPD, no selection of alternative methods is possible for the time being.

Technical Details (II) SAP Note 505700 offers help for selecting the correct update method. When using the method “Queued Delta”, it is strongly recommended, according to SAP Note 438015, that you use the newest qRFC version. (QRFC-Version 6.20.045, Supplement 9) When using the new update methods “Direct Delta” and “Queued Delta”, the extraction with the new V1 update modules, such as MCEX_UPDATE_11_V1, is updated. In the case of “Queued Delta”, the storage of data occurs from there in the extraction queue with the RFC MCEX_UPDATE_11_QRFC.

Technical Details (III) Call Hierarchy for the Application 11 Example Direct Delta Queued Delta V3 Update MCEX_UPDATE_CALL_11 Dialog MCEX_UPDATE_11_V1 MCEX_UPDATE_11 RSC1_TRFC_QUEUE_WRITE MCEX_UPDATE_11 RSC1_TRFC_QUEUE_WRITE MCEX_UPDATE_11_QRFC MCEX_UPDATE_11 RSC1_TRFC_QUEUE_WRITE V1 Update Extraction Collective Run V3 Collective Run

Copyright 2004 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®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. ORACLE® is a registered trademark of ORACLE Corporation. INFORMIX®-OnLine for SAP and Informix® Dynamic ServerTM are registered trademarks of Informix Software Incorporated. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML 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, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.