about v1, v2 and v3 processes

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

From: http://forums.sdn.sap.com/thread.jspa?threadID=331913

Comments are closed.