Skip to Content

Whom are you with? Tom or Jerry???

Hello Everyone!

This blog is about a conversation which happened between two BW developers Tom and Jerry. They are working together on a project and have just come out of a requirements gathering session. Both look pensive and slowly begin this conversation…here we go…

TOM: It was a good session Jerry.
JERRY: Yes Tom, but the report layout requirement is puzzling me. Just look at the figure here.














Users need List of all the sales orders which were rejected either due to “Damaged Delivery” or due to “Bad Quality” and additionally they want 2 column at the end Shipping point and Mfg. Plant.

TOM: Yes, that’s right. So what is troubling you?

JERRY: You see, they specifically mentioned that if Reason = “Damaged Delivery” show the Shipping Point value and DO NOT show Mfg. Plant. Where as, if the Reason = “Bad Quality” show Mfg. Plant and hide Shipping point. How can we hide specific char values in the report?

TOM: Yeah, I see your point. Let me think… it! Let’s modify the extractor with the logic that if Reason Code = “Damaged Delivery” –> Plant = blank
If Reason Code = “Bad Quality” —> Shipping Point = Blank
This will solve our problem.

JERRY: Hmmn…I can think of another solution.
1. Create a Virtual Infoprovider with the fields needed in the report
2. Create a transformation from our existing cube to Virtual provider and in the transformation apply the same logic you said just now.
3. We will build our query on top of the Virtual Provider

TOM: I see, but if we modify the extractor we do not have to do all this additional development.

JERRY: I do not think we should do modify the extractor. Let us get the as it is to BW and then use virtual provider, because if we modify the extractor we will lose either Shipping Point or Plant information the data.

TOM: Don’t worry about it; this is the “only” report which is built on this cube. So there shouldn’t be any issue. Let’s change the extractor as per the report logic.

JERRY: Think about it again Tom! I agree there isn’t any other report on this cube today, but what if there is another requirement tomorrow with a requirement to display all values of Shipping Point or Plant?

TOM: Let us not worry about it right now. Changing the extractor will reduce the development and we can deliver the report faster. Users will be happy!

JERRY: Quick….probably yes, but not a long term solution. Building Virtual Provider will take some additional development effort but the source data would be intact. We should stage the source data as it is in BW and the report specific logic should be addressed in BW.

TOM: No Jerry….we should change the extractor.

JERRY: No, we should go with Virtual Provider in BW

TOM: Change the Extractor…!!!

JERRY: Build the logic in BW…!!!

(…and the debate continues…)

So friends, what do you think after reading this conversation….whose side you are on? Agree with Tom or support Jerry?

Do let me know in your comments… 🙂

You must be Logged on to comment or reply to a post.
  • Hi,
    That’s a nice and thought-inspiring blog. It reminds me of other similar discussions I have had.
    My position is clear: Jerry is right, because Jerry’s approach preserves the information that is in the cube. Tom’s approach would make the BW stupider than it is just because of one query that doesn’t want to see this information. If Tom’s approach is followed, and not just in this example, but as a tendency in design, you will have many extractors, ODSs and cubes designed specifically for particular queries, which is a bad thing unless performance issues absolutely force you to do this.
    It’s better to have all-purpose extractors that load the information into BW without more loss of information than absolutely necessary, than do most of the filtering and hiding in queries.
    • Hi Thorsten,
      Thank you for the comment.
      I understand the point you have made. Though Tom says that his approach would aviod additional development, but in the long run this approach to design would make him create lot of extra objects(one extractor or ODS or Cube er query..)..and that is certainly not right!
      • Hey Amol,

        History says Jerry is always smarter than Tom. So I’d agree with Jerry’s solution. However if Tom’s concerns are to be considered and provide a quick solution I would create two additional infoobjects, referenced to original infoojects, add to the existing cube and write the logic in the transformation and use these new characteristics in. This way we dont create additional objects, have the source data intact in cube, provide a quick solution and dont have to worry about the performance of Virtual provider. What do you think?

        The reference of objects is to have the master data available in the reports.


        • Kalyan – I agree with your view point. The basic difference in Tom and Jerry’s approach was…whether to build the logic in source system or in BW.
          With your solution, we will be build the logic in BW…I am sure Jerry would agree to this 🙂

          Thanks for the comment…

  • The perfect theoretical answer is that both fields should come to BW. But projects do not always need perfect or theoretically perfect solutions. When time, skills etc are in shortage, projects will go for less perfect solutions.

    The source of truth is the ECC information, and that is always available to go back to – even if a less than perfect solution is put in BW to fix an emergency issue. Also, there might be no one else in the team who understands virtual providers. And depending on effort, cost to maintain etc – some times it is more efficient to just take current requirements as golden, even if you suspect they might change some date in future.

    So Tom or Jerry might be right, and I cannot take sides 🙂

    • Yes Vijay…it depends!
      Other that the conventional project management variables (Scope, Cost & Schedule) you have brought in another important point to the discussion…Skill!
      This could be one of the influencing factors which determine the design of the project. It could be either the designer’s skill or the developers skill.
      Obviously there are some situations when Tom is right.


  • Hi,

    Although I’m not a BW expert – and thus, can’t really judge who is right- I really liked the format of the blog as a conversation. I think providing content in this format is one of best ways to present technical information in a form that people can easily understand and entertains them at the same time.

    You may wish to provide other examples using the same characters. I’ve done similar work in the BPX wiki (BPX Community Project) and found it a great way to tell a relevant story.


    • Hi Richard – Thank you for the feedback and I am glad you liked the format of the blog.

      I think I should now continue eavesdropping on Tom & Jerry’s conversations ;-))


  • Given the context would take the side of Jerry, given the fact the Cube they are talking about does not have huge amount of data or if the selection is not for a bigger data set. As we all know virtual providers are not well known for huge amount of data sets (performance issues).

    Also, we can take Tom’s suggestion partially and have additional characteristics which satisfy the reporting requirements by either adding characteristics to the existing InfoCube or if the reporting requirement is limited to certain dataset by building another reporting layer InfoCube which also helps maintaing EDW architecture.

    So, as other people have mentioned there is no one certain solution for a give issue in BW.

    But as I mentioned earlier, will have to go with Jerry if the above were the only two options.

    Nice idea for the conversation….keep posting.


    • Yep…performance is indeed one of major parameter to assess a design…and we need to know if Virtual Provider can really support the data set needed in the report before agreeing with Jerry.

      Adding additional characteristics to the Infocube is also a good solution. But again, in this case the logic for report is built in BW not at the extractor level. So we fundamentally agree with Jerry 🙂

      Thanks for the feedback Dharma!

  • Hi Amol, Really liked the way you have tried to put the technical information in the form of a conversation. As far as the solution goes, i am with Jerry as keeping SPOT layer data in BW & then modifying it afterwards based on the requirement seems to be scalable solution.

    Keep Posting!!


  • Hi ,

    The Blog has been presented in a very innovative manner !!
    To me  Jerry ‘s solution seems good go with as  it would be better not to restrict the data from entering into BW . In future  if at all there is a requirement to use this data then the current design can be manipulated  to cater to the needs .

  • A blog in conversation format surely attracts readers and makes an interesting reading. Also this blog gives a good thought on the best development approach to be followed in a real project scenario.
    With my experience, I would go with Jerry’s approach as we should always have the raw data as it is in BW. Doing BW changes than extractor changes is the best way to be prepared for future changes and requirements.Having a second layer infocube or virtual provider for reporting purposes is surely the best approach.


  • Well, BW is basically an OLAP system and raw data are not to be tampered unless absolutely necessary. Once you have all data in BW – it is always possible to report in the manner you want.

    Also taking a long term view – i am sure, there’s gonna be requirement in future for that data and then that adds up to additional development again.

    Using Jerry’s solution approach , we would be in very good position to provide all data in future and that’ll make it Quick !! – users happy !!


  • Hi Amol,
              Tom mentions something about “modifing the extractor”. Can you pls tell me how that is done?

    Thank you

  • Whatever the outcome of the debate, the format you present your information in is very engaging and entertaining.  A quick look at your stats show that it was a “best read” blog.  So bravo on your creativity.  Kudos on your content.