All About LO extractors Part 2

In the last post, I gave an introduction about the LO extractors. In the current post I'll discuss about the various update methods and the V1, V2  and V3 processes.  I have tried to simplify the things by providing simple diagrams of the data flow.

All the three methods use V1,V2 and V3 processes. Below is the brief explanation about the three processes:

V1 (Synchronous): This is the time critical synchronous update and is used for updating the actual transaction tables.

V2 (Asynchronous): This is non- time critical update and is used to update statistical tables related to the actual transaction tables. They are usually triggered by the applications themselves.

V3 (Asynchronous): This is also a non time critical update which can be scheduled in the background also. This is similar to the V2 updates but can be scheduled in the background.

SAP has provided three methods to update the delta data to the delta queue:

1. Direct Delta

2. Queued Delta

3. V3 unserialized update

The following diagram shows the flow where the above mentioned three methods are used:

                                                         

1. Direct Delta: This method updates the records in the database tables and the delta queue at the same time using V1 process.

The following data flow shows how the records actually move from the time a new document is created to the delta queue:

The records are updated to the Delta queue in the following order of events:

1. A new sales document is created by the user

2. V1 process updates the new document in the transaction data base tables.

3. The same V1 process updates the records in the delta queue also.

Features:

1. Since the delta queue is also updated at the same moment as the actual data base tables, The V1 process becomes heavy.

2. The process ensures the serialization of the documents.

3. This process is not recommended when the number of documents created or changed exceeds 10,000.

4. Since, the delta queue is updated simultaneously, no monitoring is required and hence a lot of overhead is saved.

2. Queued Delta:  In  this method the delta queue is not updated directly, instead the data is first updated to a extraction queue and then to the delta queue.

The update to the extraction queue happens using the V1 update. However, the data from the extraction queue is loaded to the delta queue by a scheduled job.

The following diagram shows the flow of the data from the transaction tables to the delta queue:

The documents are updated to the delta queue in the following order of events:

1. A document is created by the user.

2. The V1 process updates the record to the data base tables.

3. The same V1 process updates the records to the extraction queue.

4. A scheduled job ( V3 collection run) updates the data from the extraction queue to the delta queue.

Features:

1. In this method also, the V1 process updates the data to the extraction queue during the actual transaction, hence, V1 process bears heavy load.

2. The extraction queue can be viewed using the T code LBWQ.

3. Since the update to the delta queue is using the V1 process, it is not recommended if the number of the documents generated during a day exceeds 10,000.

4. The job is scheduled in the T code LBWE. This job runs periodically and extracts the data from the extraction queue to the delta queue.

5. This update method is independent of the V2 process.

6. Since the V1 process updates the extraction queue, the serialization of the records is maintained.

3. Unserialized V3 Update:  In this update method, The data from the transaction tables is updated to the Update tables via V3 update. The data from the update tables is updated to the delta queue using the V3 collection runs.

The following diagram shows the flow of the data from the Transaction tables to the Delta queue in case of Unserialized V3 update:

The documents are updated to the delta queue in the following order of events:

1. The document is created in the R/3 system.

2. V3 process updates the record to the Update tables.

3. The V3 collective run moves the data from the Update tables to the delta queue.

Features:

1. The data is staged in the update tables. The data comes to the update tables via V3 jobs.

2. The serialization of the document is not maintained in this method. Hence, this method might not update the records correctly, in case, the data source updates the data directly to an DSO.