LO-Cockpit V1 and V2 update
Can anyone tell me what is the difference between V1 and V2 update.
I read Robert Negro's weblog and he has stated
1. The serialized V3 update can guarantee the correct sequence for the extraction data of a document only if there were no errors in the V2 update. This is because the V3 update only processes update data for which a V2 update has be carried out successfully.
Why is V3 dependent on V2, what is V2 and V1 update?
The requirement in 'delta' capturing on R/3 side is to be able to capture the delta 'exactly once in order'.
Take an example of the same PO item changing many times in quick succession.
V1 (with enqueue mechanism) ensures that the OLTP tables are updated consistently. Update table gets these update records which may or may not end up in correct sequence (as there is no locking) when it reaches BW. 'Serialized V3' was to ensure this correct sequence of update records going from update tables to delta queue (and then to BW).
Since update table records have the timestamp, when the V3 job runs, it can sequence these records correctly and thus achieve 'serialization'. However, there is a technical problem with this. The timestamp recorded in update record is sent by the application server (where user executed the txn) and if there are multiple app servers there might be some inconsistency in their system time which can cause incorrect serialization.
Another problem is in the fundamental design of the V3 process. V3 Job sequences the updates on timestamp, and then processes the update records from update table (to send it to delta queue), but it does so for one language at a time (update record also has user logon language stored). Why this is done is not clear to me, but it is a basic design feature and can not be subverted.
This causes a potential issue if multiple logon languages are used by users. Serialization may not happen correctly in such a case. Take a case where the first update (based on earliest timestamp) to be processed is in language EN (for same PO item). V3 job is then going to process all the update records of language EN in chronological sequence before going to next language records. If another language update (for same PO item) happened in between two EN language updates, this is going to be processed later after all EN updates are processed and thus become out of sequence. The weblog mentions this scenario.
These two constraints remain for 'serialized V3' where 'serialization' couldn't be truly achieved. Hence newer PIs have discarded 'serialized V3' altogether and now you do not have this option (if you are using a newer PI).
If you use 'serialized V3', you have to be clear that the 'serialization' may not always work in the above two scenarios (multi language environment, and multiple app servers or updates to same records in same second(as timestamp has granularity upto second level only)).