WHAT ARE THE VARIOUS UPDATES METHODS & UPDATE MODES AVAILABLE IN LO- EXTRACTION:
This topic is explained also in LO EXTRACTION MADE SIMPLE IN MY BLOG:
First when we are going to update methods, first we must know about updates, because updates are used in update methods!
i. V1 - Synchronous update
ii. V2 - Asynchronous update
iii. V3 - Batch asynchronous update
i. V1 - Synchronous update:
· V1 update is defined as direct delta is synchronous type uses time critical technology and its nature of update is automatic, where the process done only once and never 2nd time.
· It is used for single update work process & belongs to a same LUW (Logical Unit Of Work), reads data from documents & uses direct delta & writes to application tables.
· V1 update can be scheduled any time, with a mandatory step of locking users to prevent simultaneous updates.
· V1 is carried out for critical/primary changes & these affects objects that has controlling functions in SAP System
· During the process of creation of an order, the V1 update writes data into the application tables and the order gets processed.
ii. V2 - Asynchronous update:
· V2 update is defined as queued delta, is asynchronous statistical update type uses non-time critical (for updating statistical tables of transaction tables) and its nature of update is never automatic, uses report RMBW311.
· The process not done in a single update & carried out in separate LUW, reads data from documents and uses extractor Queue & w rites to application tables.
· V2 update is scheduled hourly, with a mandatory step of locking users to prevent simultaneous updates.
· A V2 is executed for less critical secondary changes & are pure statistical updates resulting from the transaction.
· V1 updates must be processed before V2
iii. V3 - Batch asynchronous update:
· V3 is defined as Un-serialized is collective update / synchronous with background schedule or batch synchronous update , uses delta queue technology and the nature of update is never automatic, which runs in background uses report RSM13005.
· The process can be done at any time after V1, V2 updates. i.e. V3 uses V1 or V2 +v3 update, reads data from documents & uses delta queue collective run call and writes to application tables.
· V3 can be scheduled at any time, with a mandatory step of locking users to prevent simultaneous updates.
B. UPDATE MODES:
The LO DataSource implements its delta functionality using the above discussed V1, V2 & V3 update methods, individually or by combination of them.
P1 2002.1 is the upgraded version. So what are the update modes that are available with LO DataSource as of P1 2002. 1.
i. DIRECT DELTA
ii. QUEUED DELTA
iii. SERIALIZED V3 UPDATE
iv. UNSERIALIZED V3 UPDATE
i. DIRECT DELTA: V1 update
Document postings and update sequence is 1:1. I.e. the direct delta V1 updates directly the document positions to the BW Delta Queue and this is extracted to BI System periodically.
In doing so each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
Users are locked but any postings are done so is completely lost. Because from start of recompilation run in OLTP until all init requests have been successfully updated in BW.
SUITABILITY: Suitable for customers with fewer documents and no monitoring of update data/extraction queue required SERIALIZATION BY DOCUMENT: Posting process ensures serialization of document by document, while writing delta to Delta Queue within V1
EXTRACTION: Extraction is independent of V2 update
SUITABILITY : V1 is more heavily burden& Not suitable f high number of documents
Re-initialization process (User Locks): Setup and initialization required before document postings are resumed.
ii. QUEUED DELTA V2 (V1+V3) update: **SAP RECOMMENDS**
Delta queues essentially are tables capturing the key values of changed or inserted records or the entire transaction records Data is pushed to extraction queue by means of V1 update and to delta queue same as V3 update. As we know that V3 is a collective run the data collected in extraction queue and scheduled background. SAP recommends queued delta for customers with high amount of documents.
Uses REPORT RMBWV311 for collective run and the naming convention is MCEX_UPDATE_<APPLICATION> for example for sales its MCEX_UPDATE_11s.
SUITABILITY: Suitable for customers with high amount of documents (SAP
SERIALIZATION BY DOCUMENT:
No serialization as it’s a statistical update, which is run after V1
EXTRACTION: Extraction is independent of V2 update
IMPLEMENTATION: **SAP RECOMMENDS**
DISADVANTAGES : No disadvantages
iii. UNSERIALIZED V3 UPDATE
Data extracted from application tables is written to update tables using unserialized V3 update mode. By using collective update the so extracted data is processed. The Important point to consider here is that the data is read without a sequence from update tables and are transferred to BW delta queue. Un serialized update, which is run after V1 & V2 doesn’t guarantee serialization of the document data posted to delta queue. This method is not suggestible as the entries in the delta queue are not equal to the updates that made to application. This method V3 results erroneous data, when data from DataSource is updated to DSO in overwrite mode, so the previous data is over written by the last update. But this V3 is suggestible when updating data to ODS or InfoCube. V3 runs and process the data after V2 with which the data is processed.
SUITABILITY : Suitable for customers with high amount of documents
SERIALIZATION BY DOCUMENT : No serialization as it’s a statistical update, which is run after V1 & V2 but the un serialised V3 doesn’t guarantee serialisation of the document data.
EXTRACTION : collective
DOWN TIME : Not efficient
IMPLEMENTATION : LESS
Not suggested if documents subjected to large changes with tracking changes
IV. SERIALIZED V3 UPDATE
Here the tables are updated consistently and the main problem in this method is, the user locks not there and the document postings occur as we are extracting data. It’s arduous as the data will not have consistency. E.g. document changed twice or thrice when extracting data.
Hey: the important difference we to analyze here is!
Serialized V3 Vs Un-serialized V3
As the term serialization itself mean, sequentially i.e. Data is read sequentially and transferred to the BW Delta Queue. Un-serialized mean, the process is not in a sequence i.e. data is read in the update collective run without taking the sequence into account and then transferred to the BW delta queues.
As per the data flow, serialized and un-serialized V3 updates, I can say that these are twins, with different process.
Thanks for reading!