Skip to Content
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

image

2. How the data flow from OLTP to BW system

image

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

image

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

image

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

image

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.

image

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]

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Davide Cavallari
    Nice compact Blog, many thanks, especially for the clear positioning of the LO Cockpit within the Business Content extractors.

    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

    (0) 
    1. Vishvesh Bahirat
      Hi 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

      (0) 
      1. Davide Cavallari
        Hello Vishvesh, thank you for your replay!

        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

        (0) 
    2. Happy Tony Post author
      Hi 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

      (0) 
  2. Witalij Rudnicki
    Hi Tony. Could you clarify one thing? Slides and texts in your weblog are 1:1 with presentation that I saw prepared by Glenn Cheung and Ramond Leenders in 2003. I think it would be worth to mention what is an original source of information you present.

    Vitaliy

    (0) 
        1. Mark Finnern
          Hi Vitaliy,

          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.

          (0) 
  3. Marilyn Pratt
    Thanks to the authors for graciously allowing this content to be published and bravo, Happy Tony, as it takes courage to admit a mistake.
    And thanks to the community that keeps us honest and has such integrity.
    Marilyn
    (0) 
  4. Anton Wenzelhuemer
    …at least the original authors are cited correctly now but I cannot refrain from discussing this issue a little bit further though I don’t want to pick on the author primarily.

    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

    (0) 
    1. Happy Tony Post author
      Hi 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

      (0) 
      1. Anton Wenzelhuemer
        Hello 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

        (0) 
  5. Arvind Bhaskar
    1) Very old one – but I thought was the best ever written, delta methods may have changed – but this captures everything you need to know
    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

    (0) 

Leave a Reply