Can anyone give me an example of direct, queued and unserialized delta?

Question

hi all,
Can anyone give me an example of direct, queued and unserialized delta for fi and sd applications.
thanxs in advance
regds
hari

Answer 1

hi,
Update Methods,
a.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
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
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
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
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
hope it helps
partha