Objective: In this Blog I would like to bring your attention to an excellent piece of work by Glenn Cheung and Ramond Leenders of www.vnsg.nl which will give a crash understanding of the LO cockpit. I will be covering the delta mechanism explained in the presentation and there by direct you to this masterpiece.
Before starting the matter, I sincerely apologize for not working in the correct way with the material in my previous posting of this blog, that was not original. I admit that I have made the mistake of not giving credit to the author. I thank Vitaliy for pointing this and SDN community for giving me an opportunity to correct it.
1. Positioning of LO Cockpit extraction
2. How the data flow from OLTP to BW system
Transaction postings lead to:
1. Records in transaction tables
2. For an initial load a setup needs to be executed which reads the transaction data and stores the data in a setup table
3. These setup tables are read during an initial or full load
4. Further transactions are posted into the transaction tables and also caught into Update tables / Extraction Queue.
5. A periodically scheduled job transfers these postings into the BW delta queue
6. This BW Delta queue is read when a delta load is executed.
3. The Update Modes
a. < 2002.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
a. Update methods: (serialized) V3
• Transaction data is collected in the R/3 update tables
• Data in the update tables is transferred through a periodic update process to BW Delta queue
• Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
• Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
• V2 Update errors can lead to V3 updates never to be processed
• Details in SAP Note 505700
b. Update methods: direct delta
• Each document posting is directly transferred into the BW delta queue
• Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Less monitoring overhead of update data or extraction queue
Cons:
• Not suitable for environments with high number of document changes
• Setup and delta initialization have to be executed successfully before document postings are resumed
• V1 is more heavily burdened
Note: Con 2: a delta queue has to present to collect the document postings. This queue is only available after a successful delta initialization.
c. Update methods: queued delta
• Extraction data is collected for the affected application in an extraction queue
• Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Suitable for environments with high number of document changes
• Writing to extraction queue is within V1-update: this ensures correct serialization
• Downtime is reduced to running the setup
Cons:
• V1 is more heavily burdened compared to V3
• Administrative overhead of extraction queue
d. Update methods: Un-serialized V3
• Extraction data for written as before into the update tables with a V3 update module
• V3 collective run transfers the data to BW Delta queue
• In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Note: i. Pro 2: In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each Data Source into the BW delta queue, depending on the application.
ii. Pro 4: Even without a successful initial load and thus no BW delta queue yet available, document postings are already collected in the extraction queue.
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
• Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
• V2 update has to be successful
Note: Issue 1: Each Material Movement delivers a new Material Document, so no problem when updating into ODS/Cube.
Source:
Logistics Extraction Cockpit
References:
1.
2. /message/2746337#2746337 [original link is broken]
Before starting the matter, I sincerely apologize for not working in the correct way with the material in my previous posting of this blog, that was not original. I admit that I have made the mistake of not giving credit to the author. I thank Vitaliy for pointing this and SDN community for giving me an opportunity to correct it.
1. Positioning of LO Cockpit extraction
2. How the data flow from OLTP to BW system
Transaction postings lead to:
1. Records in transaction tables
2. For an initial load a setup needs to be executed which reads the transaction data and stores the data in a setup table
3. These setup tables are read during an initial or full load
4. Further transactions are posted into the transaction tables and also caught into Update tables / Extraction Queue.
5. A periodically scheduled job transfers these postings into the BW delta queue
6. This BW Delta queue is read when a delta load is executed.
3. The Update Modes
a. < 2002.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
a. Update methods: (serialized) V3
• Transaction data is collected in the R/3 update tables
• Data in the update tables is transferred through a periodic update process to BW Delta queue
• Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
• Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
• V2 Update errors can lead to V3 updates never to be processed
• Details in SAP Note 505700
b. Update methods: direct delta
• Each document posting is directly transferred into the BW delta queue
• Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Less monitoring overhead of update data or extraction queue
Cons:
• Not suitable for environments with high number of document changes
• Setup and delta initialization have to be executed successfully before document postings are resumed
• V1 is more heavily burdened
Note: Con 2: a delta queue has to present to collect the document postings. This queue is only available after a successful delta initialization.
c. Update methods: queued delta
• Extraction data is collected for the affected application in an extraction queue
• Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Suitable for environments with high number of document changes
• Writing to extraction queue is within V1-update: this ensures correct serialization
• Downtime is reduced to running the setup
Cons:
• V1 is more heavily burdened compared to V3
• Administrative overhead of extraction queue
d. Update methods: Un-serialized V3
• Extraction data for written as before into the update tables with a V3 update module
• V3 collective run transfers the data to BW Delta queue
• In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Note: i. Pro 2: In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each Data Source into the BW delta queue, depending on the application.
ii. Pro 4: Even without a successful initial load and thus no BW delta queue yet available, document postings are already collected in the extraction queue.
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
• Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
• V2 update has to be successful
Note: Issue 1: Each Material Movement delivers a new Material Document, so no problem when updating into ODS/Cube.
Source:
Logistics Extraction Cockpit
References:
1.
2. /message/2746337#2746337 [original link is broken]
15 Comments
