BOBJ directly on SAP ECC or on top of BEx queries??

building semantic layer
1

Hi all,

I work as a BI Developer for a company who are currently having SAP implemented. Having had the Finance module implemented meant I was to draw the data from ECC into a SAP Business Warehouse (BW) and then use BEx queries to report on the BW. Personally, I found BEx Query Designer to be limited in what it could do, yes it made easy work of producing formatted reports (especially with its Hierarchy catering) from the BW but trying to provide the End-Users with any bells and whistles (dynamic reports, adjusting the layout to meet demands etc…) it wasn’t capable of and didn’t achieve what was asked of it.
Okay, so BEx was a tool that was used for years but now SAP have bought out Business Objects, and customised BOBJ for SAP’s needs, we all should focus on using BOBJ for reporting - right?
My knowledge of the SAP and BOBJ is limited as I am only starting use it now. We do have implementation partners helping us but I would like to understand for myself, and not rely on the implementation partners decision, on the best approach of using BOBJ to create reports so I look for your advice and guidance on what is the best and forward thinking method, not what people are use to due to their experiences.
So my questions are:-

  1. Can BOBJ report on SAP ECC and other databases without the need for BEx queries?
  2. An approach that has been suggested is to use BEx queries as a middle layer between the ECC and the BOBJ reports - if this is the case then why would I have to create a report using BEx just to create the same report using BOBJ? Sounds like duplication!
  3. If BEx as a middle layer is being suggested do you think it is because the person suggesting it feels more comfortable using BEx?

What I’m trying to understand and find out is is there any reason to use BEx to be the middle layer for reporting on top of SAP ECC, or can we do away with BEx and just use BOBJ for reporting on SAP ECC? I’m looking for you answers, links and Pros/Cons.

Thanks in advance.

dan1 (BOB member since 2012-07-12)

2

1/ 18 months ago I was advised that reporting directly could/would invalidate our SAP licence
2/ This is the way that we have been advised. In XI3.1 you need to create a universe over the Bex query, in v4, you can point Webi straight at the Bex query which vastly reduces maintenance overheads.
3/ See above - it’s the recommended method.

The problem is that there are SAP implementation partners that have little BO experience; you can usually tell them, they refer to the tool as BOBJ (pronouncing it bobjay) because that’s the reference code for it in SAP’s documentation. They are providing the right solution though but that’s possibly because it’s been briefed to them. Ingo Hilgefort’s postings on the SAP website are a useful read for you.

3

I’m currently working with a client who is looking to retrieve data not just from SAP but also from Hyperion and other external data sources.

In this instance, I believe the best answer is to use the IDT to federate all of the data and allow it to be used as a single source for the Webi reports.

Am I correct???

Eileen King :us: (BOB member since 2002-07-10)

4

The best way is to load all that data into one target database (be that SAP BW or a relational data warehouse).

Using the data federator engine (=IDT with multi-source universe) might consume a lot of memory on the SAP BI BusObjects server running the DF engine (part of APS) during query execution time of a Webi report.

Andreas :de: (BOB member since 2002-06-20)

5

1st Question that should be asked is; What database platform are you using?

If the answer is Hana, then the next question is; What licensing model are you on?

If the answer is “BW on Hana” or “Runtime” or “Hana for applications and accelerators”, then good luck! The licensing for the BI tools in this instance is somewhat frustrating :hb:

If you are on Hana as a database platform, then using BOBJ is possible in virtually the same way as with any other data source. The choice is yours, depending on what the needs of your users are.

The SAP books are good, as is the advice in many forums, essentially pushing Bex if you use BW, thing to keep in mind though is that this advice is generally levelled at those that have a heaftly pre-existing investment in BW and Bex, which is not necessarily the best approach for a green fields implementation, or a new piece of work. But rather than go through it all here is a link to a best practice document than runs through the pro’s and con’s http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00922ede-de2f-2f10-c2aa-f9b0f6495d34?QuickLink=index&overridelayout=true&53571127135179.

If you are not on Hana and just a regular installation of BW on another database platform, then your options are either through Bex or Data Federator. Again, there are a lot of considerations to take into account, but in short, my understanding is;

Use Bex if - You are needing the multidimensional features made available through either the BW or Bex functionality, or needing large datasets.

Use DF if - You are needing highly filtered and/or restricted resultsets or if you want to model in a relational environment or the arguable extra flexability available in a Universe.

Beware! Data Federated Multisource Universes definately have their drawbacks. Suggest you read this awesome artical here http://bobj.sapbiblog.com/2012/04/11/to-federate-or-not-to-federate/

Best bet, IMHO, if you haven’t got Hana, try and get it, then you have the best of both worlds, you can use BW reporting if you really must (and cant think of any reason not to, no matter how weak), but ideally can use the entire BI suite over Hana tables, or over Hana Information Models either directly or through a Single Source Universe.

Anyway, HTH

Oh, your questions…

  1. Crystal and a couple of the other tools can go direct on ECC, but generally best practice dictates not to go against OLTP.
  2. Couldn’t agree more
  3. As above

Corey

coreya :new_zealand: (BOB member since 2008-12-16)