V-3 Updates

[Former Member]

Can some1 please brief me about V-3 Updates???

[Former Member · Accepted solution]

Hi,

Synchronous update (V1 update)

Statistics update is carried out at the same time (synchronous) as the document update (in the application tables).

Asynchronous update (V2 update)

Document update and the statistics update take place in different tasks. So, V1 and V2 updates dont require any scheduling activity.

Collective update (V3 update) As for the previous point (V2), document update is managed in a separate moment from the statistics update one, but, unlike the V2 update.

V3 collective update must be scheduled as a job (via LBWE). Remember that the V3 update only processes the update data that is successfully processed with the V2 update

Taking an example -

If you create/change a purchase order (me21n/me22n), when you press 'SAVE' and see a success message (PO.... changed..), the update to underlying tables EKKO/EKPO has happened (before you saw the message). This update was executed in the V1 work process.

There are some statistics collecting tables in the system which can capture data for reporting. For example, LIS table S012 stores purchasing data (it is the same data as EKKO/EKPO stored redundantly, but in a different structure to optimize reporting). Now, these tables are updated with the txn you just posted, in a V2 process. Depending on system load, this may happen a few seconds later (after you saw the success message). You can see V1/V2/V3 queues in SM12 or SM13.

V3 is specifically for BW extraction. The update LUW for these is sent to V3 but is not executed immediately. You have to schedule a job (eg in LBWE definitions) to process these. This is again to optimize performance.

V2 and V3 are separated from V1 as these are not as realtime critical (updating statistical data). If all these updates were put together in one LUW, system performance (concurrency, locking etc) would be impacted.

Serialized V3 update is called after V2 has happened (this is how the code running these updates is written) so if you have both V2 and V3 updates from a txn, if V2 fails or is waiting, V3 will not happen yet.

BTW, 'serialized' V3 is discontinued now, in later releases of PI you will have only unserialized V3. (This is explained nicely in the weblog).

hope this helps,

Thanks and Regards,

MuraliManohar.

[Former Member]

Thanks

[Former Member]

In Bw 3.x we have 4 update

1) serialized .

2)unseiralise.

3)direct update.

4)Queue.

Since serialized having drown backs. Sap has removed in new versions

Unserialized V3 update:

With this update mode, the extraction data of the application being viewed is

written to the update tables with an V3 update module and is kept there until

the data is read with an update collection run and processed. The data in the

update collection run, however, is read from the update table without considering

sequence and is transferred to the BW delta queue.

Direct delta:

With this update mode, the extraction data is transferred directly to the BW delta

queue with every document posting. The sequence of the transfer thus agrees with

the chronological order of data creation.

Benefits and properties of “Direct Delta”:

• By writing to the delta queue within the V1 posting process, serialization by

document is ensured with the enqueue concept of applications.

• For customers with fewer documents, the process is recommended if a

downtime is possible in the initialization process during restructuring and

delta init requests.

• V1 is more burdened by this process than with V3 or “Queued Delta”. For

customers with the amount of documents mentioned above, this is not really

a factor.

• Extraction is independent of V2 updating.

• Additional monitoring of update data or extraction queue is not required.

Queued delta:

With this update mode, instead of being collected in the update data, the extraction

data from the affected application is collected in an extraction queue and can be

transferred to the BW delta queue, in a similar manner to the V3 update, with an

update collection run. Depending on the application, up to 10,000 delta extractions

of documents can be aggregated to an LUW in the BW delta queue per DataSource.