New Update Methods in Logistics Extraction With PI2002.1 2.0x_3.0x (Ppt)

New Update Methods for Logistics Extraction with PI

2002.1

Helmut von Stetten, SAP AG

SAP AG 2002, New Update Methods for Logistics Extractions, 2

Agenda

Problems with the V3 Update

New Update Methods

Delta Extraction with the V3 Update

Essential Features

Technical Details


Agenda


New Update Methods


Essential Features

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

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

V3 M

od

ule C

all

Docu.

Tables

Document 2V1

V3 M

od

ule C

all

Docu.

Tables

Document nV1

V3 M

od

ule C

all

Docu.

Tables

Rea

ding

and

pro

cess

ing

of

all e

xist

ing

upda

te d

ata

for

a m

odul

e

A

Rea

ding

and

pro

cess

ing

of a

ll

exis

ting

LUW

s fo

r a

Dat

aSou

rce

B


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


New Update Methods


Essential Features

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.


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:







Agenda


New Update Methods


Essential Features

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


New Update Methods


Essential Features

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

Time


Delta Request

BW (PSA, ODS, Cube)

Transfer to BW

Document nV1

Extraction Module

with V1 U

pdate

Docu.

Tables

Reading and processing of a

ll

existing LUW

S for a

DataSourc

e

B

Document 2V1

Docu.

Tables

Extraction Module

with V1 U

pdate

Document 1V1

Docu.

Tables

Extraction M

odule

with V

1 Update


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

Extraction Queue

Time

Extraction Collective Run(recommended hourly)


One LUW,One Commit

Delta Request

BW (PSA, ODS, Cube)

Transfer to BW

Document 1V1

Fillin

g extractio

n q

ueu

e

from

the V

1 up

date

Docu.

Tables

Rea

ding

and

pro

cess

ing

of

all e

ntri

es in

the

extr

actio

n

que

ue fo

r an

app

licat

ion

A

Rea

ding

and

pro

cess

ing

of a

ll

exis

ting

LUW

s fo

r a

Dat

aSou

rce

B

Document 2V1

Docu.

Tables

Fillin

g extractio

n q

ueu

e

from

the V

1 up

date

Document nV1 Docu.

Tables

Fillin

g extractio

n q

ueu

e

from

the V

1 up

date


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 (RMBWV311,...). 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. 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.


New Update Methods (VI)

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 Update Methods (VII)

The new function from the logistics queue overview (LBWQ) is available for monitoring the extraction queues. It can also be called up from the pushbutton in the Cockpit:


Agenda


New Update Methods


Essential Features

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.

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

Dialog

V1 Update

V3 Collective Run

ExtractionCollective 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



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.

Copyright 2002 SAP AG. All rights reserved

New Update Methods in Logistics Extraction With PI2002.1 2.0x_3.0x (Ppt)

Documents

Transcript of New Update Methods in Logistics Extraction With PI2002.1 2.0x_3.0x (Ppt)