new update methods by plugin

8/8/2019 New Update Methods by Plugin

http://slidepdf.com/reader/full/new-update-methods-by-plugin 1/28

New Update Methodsfor Logistics Extractionwith PI 2003.1



¥ SAP AG2004, 2

Agenda

Problems with the V3 Update

New Update Methods

Delta Extraction with the V3 Update

Essential Features

Technical Details



¥ SAP AG2004, 3

Agenda


New Update Methods


Essential Features

Technical Details



¥ SAP AG2004, 4

Delta Extraction with the V3 Update (I)

For updating the extraction of transaction data into the logisticsapplications (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 thenretrieved 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.



¥ SAP AG2004, 5

Delta Extraction with the V3 Update (II)

Data Flow Schematic for Logistics Extraction with the V3 Update

Update Tables

Time

V3 Collective Run

(for example,

daily or hourly)

Delta Queue(Stopped qRFC)

One LUW,

One Commit

Delta

Request

BW (PSA,

ODS, Cube)

Transfer to BW

Document 1V1

Docu.

Tables

Document 2V1

Docu.

Tables

Document nV1 Docu.

Tables

A B



¥ SAP AG2004, 6

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), aswell 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.



¥ SAP AG2004, 7

Agenda


New Update Methods


Essential Features

Technical Details



¥ SAP AG2004, 8

Problems with the V3 Update (I)

The following problems continue to occur in conjunction with the V3update in the logistics extraction of transaction data:

The serialized V3 update can only ensure the correct sequence of extractiondata for a document if the document is not repeatedly changed within thespan of a second.

Furthermore, the serialized V3 update can only ensure the correct sequenceof extraction data for a document if the times are permanently and exactlysynchronized for all instances in a system. This is because the creation timeof the update record, which is determined by the local time for theapplication server, is used for sorting the update data.

In addition, the serialized V3 update can only ensure the correct sequenceof extraction data for a document if it previously had no errors in the V2update. This is because the V3 update only processes the update data thatis successfully processed with the V2 update.

Independently of the serialization, update errors that occur in the V2 updateof a transaction and which cannot be reposted have the consequence thatthe V3 updates for the transaction that are still open can never beprocessed. This can thus lead to inconsistencies in the data in the BWsystem.



¥ SAP AG2004, 9

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 theserialized 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.



¥ SAP AG 2004, 10

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

.......

Problems with the V3 Update (III)

Multiple Language Problems in a Serialized V3 Update

Normal V3 Collective Run Serialized V3 Collective Run

Step 1:

Language :EN:

Step 2:

Language :DE:

Step 1:

Language :EN:

Step 2:Language :DE:

Step 3:

Language :EN:

Step 4:Language :DE:

Step 5:

Language :EN:



¥ SAP AG 2004, 11

Agenda


New Update Methods


Essential Features

Technical Details



¥ SAP AG 2004, 12

Essential Features with Extraction Updates

All serialization and performance problems with the V3 update would becircumvented in logistics extraction if, with document postings, theextraction 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 theOLTP system would result in exactly one LUW per DataSource in thedelta queue. For customers that have a high number of documentchanges 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 thefirst document postings after a delta initialization that not only thereconstruction run is already completed in the OLTP system, but alsothat the delta-init requests in the BW system have successfully ended.Otherwise, the deltas for the first document postings would beirretrievably lost, because the delta queue would not yet be able toinclude the data.

Thus, for customers that have a high number of document changes, anupdate method is provided that enables the collection of extraction datafor the delta queue (in a similar way to the update tables with the V3update) in order to then transfer the data periodically and compressedinto the delta queue.



¥ SAP AG 2004, 13

Agenda


New Update Methods


Essential Features

Technical Details



¥ SAP AG 2004, 14

New Update Methods (I)

With PI 2002.1 the following new update methods for logistics extractionwill be offered:

Direct Delta:With this update mode, the extraction data is transferred with each documentposting directly into the BW delta queue. In doing so, each document postingwith delta extraction is posted for exactly one LUW in the respective BW deltaqueues.

Queued Delta:With this update mode, the extraction data is collected for the affectedapplication instead of being collected in an extraction queue, and can be

transferred as usual with the V3 update by means of an updating collective runinto the BW delta queue.In doing so, up to 10000 delta extractions of documents for an LUW arecompressed for each DataSource into the BW delta queue, depending on theapplication.

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 updatingcollective run and are processed. However, in contrast to the current defaultsettings (serialized V3 update), the data in the updating collective run arethereby read without regard to sequence from the update tables and aretransferred to the BW delta queue.



¥ SAP AG 2004, 15

New Update Methods (II)

Data Flow Schematic for Logistics Extraction with Direct Delta

Time


Delta

Request

BW (PSA,

ODS, Cube)

Transfer to BW

Document nV1 Docu.

Tables

B

Document 2V1

Docu.

Tables

Document 1V1

Docu.

Tables



¥ SAP AG 2004, 16

New Update Methods (III)

Benefits and Features of the ³Direct Delta´:

By writing in the delta queue within the V1 update process, theserialization 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 deltaqueue. 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.



¥ SAP AG 2004, 17

New Update Methods (IV)

Data Flow Schematic for Logistics Extraction with Queued Delta

Extraction Queue

Time

Extraction Collective Run

(recommended hourly)


One LUW,

One Commit

Delta

Request

BW (PSA,

ODS, Cube)

Transfer to BW

Document 1V1

Docu.

Tables

A B

Document 2V1

Docu.

Tables

Document nV1 Docu.

Tables



¥ SAP AG 2004, 18

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 theapplications.

By collecting data in the extraction queue that is processed regularly(preferably hourly, as recommended), this process is especially recommendedfor 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 inthe 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 thecritical 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 ismeasurable, and a subsequent process can be scheduled. After the collectiverun for an application has ended, an event (&MCEX_11,...) is automaticallytriggered which, if defined, can be used at the start of the subsequent job.

Extraction is independent of success of the V2 update.



¥ SAP AG 2004, 19

02 ± Purchasing

03 ± Inventory Control

04 ± Manufacturing

05 ± Quality Management

08 ± Transport

11 ± SD Verkauf BW12 ± 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

Affected Applications - Availability



¥ SAP AG 2004, 20

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:

New Methods

Old Method

PI 2002.1

New methods are

optional



¥ SAP AG 2004, 21

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:



¥ SAP AG 2004, 22

PI 2003.1 - Available Update Methods

PI 2003.1

New methods are

mandatory



¥ SAP AG 2004, 23

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.>



¥ SAP AG 2004, 24

Agenda


New Update Methods


Essential Features

Technical Details



¥ SAP AG 2004, 25

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.



¥ SAP AG 2004, 26

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.



¥ SAP AG 2004, 27

Technical Details (III)

Call Hierarchy for the Application 11 Example

Direct Delta Queued Delta V3 Update

Dialog

V1 Update

V3 Collective Run

Extraction

Collective Run

MCEX_UPDATE_CALL_11

MCEX_UPDATE_11_V1

MCEX_UPDATE_11

RSC1_TRFC_QUEUE_WRITE

MCEX_UPDATE_11


MCEX_UPDATE_11_QRFC

MCEX_UPDATE_11




¥ SAP AG 2004, 28

No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress 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 componentsof 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 ® , andOS/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 SoftwareIncorporated.

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 WebConsortium, 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 productsmentioned are trademarks or registered trademarks of their respective companies.

Copyright 2004 SAP AG. All rights reser ved

new update methods by plugin

Documents