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. Re: LO-Cockpit V1 and V2 update
2. /message/2746337#2746337 [original link is broken]
Just a final curiosity. I’m wondering how the LO extractors behave in the case of *full* updates (rather than an init update followed by *delta* updates).
Would this scenario be technically possible, though possibly not optimal? Where the data would be pulled from by the BW system? Or rather a setup initialization would be needed every time before a full update is performed?
Regards, Davide
As per my understanding,full update is possible in LO extractors.In the full update whatever data is present in the setup tables(from the last done init) is sent to BW.
But setup tables do not receive the delta data from the deltas done after the init.
So if ur full update should get ALL data from the source system,u will need to delete and re-fill setup tables.
(Picture in 2nd point seems to confirm this..shows as init/full upload)
regards,
Vishvesh
Yes I agree with you, I think a re-initialization of the setup table is needed every time one wants to perform a full update in BW.
Cheers, Davide
You are right.The setup tables are the base tables for the Datasource used for Full upload.So if you are going for only full uploads, you will have to setup each time
regards
Happy Tony
Vitaliy
I will appreciate if you can give the reference here.
Regards
Happy Tony
Regards,
Vitaliy
IMHO, this blog has to be withdrawn.
Thanks for pointing this out. As we have written in our Community Guidelines we don’t tolerate material that is not your own.
We will pull this blog. Tony Happy please be original or at least quote your sources and add your personal view next time.
Sorry, Mark.
And thanks to the community that keeps us honest and has such integrity.
Marilyn
I do compare contributions to a professional comunity like SDN with such to a scientific community. In science to get something published you have to fulfill one ore more of a few simple rules
– present a genuine new view onto a matter
– add new insight (information) to a matter
– compile several existing views to gain new insights into a matter
and maybe
– in an editorial work on someone other’s work describe why YOU think this work is relevant
This blog would not fulfil any of those points since it simply does not add any information to the matter; IMHO some work like this would never be published in a scientific context.
What’s worse actually, given usual search and indexing mechanisms, a blog like this would later eventually result in a situation where the author of this blog will be credited for the content of this work by citation in a follow-up work although this work (and it’s author) doesn’t add any new information.
Well, maybe I can spark a little discussion on what’s bloggable and what isn’t and the community finds a common understanding to get along without the need to implement a peer-reviewing process.
regards, anton
I do agree with you. But let me try to explain the circumstances made me to publish this blog.
I hope you are familiar with the forums. I am a regular visitor of BI forum. We have amble examples of similar collection of writings on the same topic (LO Cockpit Mystery). Still I have seen many users requesting for the clarification on the existing writings and raise repeated queries. I understand that, it’s all a mater of search to get the right one, but if I do the search for the right one from the many postings and put it together for them, don’t you think it’s some thing useful.
Still our busy community friends post queries again on these topics. So now I have a blog to reply them.
I am with you in your suggestion but looking at the community forums I say this blog may help them a lot.
Let me know your view
Thanks
Happy Tony
I do very much appreciate your open words and get your point.
IMHO in the forum one could give the link to the original presentation at http://www.vsng.nl .
If one isn’t confident that this link will be active for long enough, one could – given the permission of the authors – check the document into the SDN WIKI, write an entry in the Wiki, describing the content, tagging it and link to it. Later one could supply the link to the WIKI entry in reply to a forum question.
(Really only) my 2 cents.
Best regards, anton
https://websmp201.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700009421482000E
2)SD extraction
https://websmp201.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700002719062002E
3)There is an excellent presentation by Helmut von – which i am unable to find on sapnet ( i have a copy thou) – the presentation link in the blog – mainly derives from this.
4) There are OSS notes available to use Hash tables for LO Cockpit – so that you do not need downtime to make structure changes – was one of the pain points earlier. I have not implemented this – but maybe I will write an article once i do it
would you mind to share ? you can reach me at sapgroup77@yahoo.com