Can anyone tell me what are V1, V2, V3 update modes. Please tell me the difference between all the three. Are there any other update modes? How are the above different from - Direct Delta , Queued delta and unserialized v3 update methods?
Am actually very confused with the above topics.
It would be great if someone could explain in details.
Thanks in advance,
In this document you can find the information that you need.
V1 denotes time-critical updates used for updating the
actual transaction tables.
V2 denotes non-time-critical updates used for updating
statistics tables related to the transaction tables.
For instance, after a sales order entry transaction
is completed, the corresponding sales order tables would be
updated in V1 mode, and the corresponding statistics tables
would be updated in V2 mode.
V3 update mode(Uses delta queue technology) is similar
to the V2 update mode. The main difference is that V2
updates are always triggered by applications, while V3
updates may be scheduled independently. Many extraction
programs available for mySAP.com applications today use the
delta queue technology to identify deltas.
and also check this
LO Cockpit contains a set of extract structures and enable extraction of logistics data to your SAP BI system via logistics DataSources.
Check the following links
Also check the step by step guide below.
go through this link you will find good scenario on update methods, this is an artical
this is about V1, V2 updates
V1 - Synchronous update
V2 - Asynchronous update
V3 - Batch asynchronous update
These are different work processes on the application server that takes the update LUW (which may have various DB manipulation SQLs) from the running program and execute it. These are separated to optimize transaction processing capabilities.
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,