Wednesday, May 27, 2009

SAP BW Universe

SAP BW universe is different from conventional Business Objects universe.
The idea behind creating a SAP BW universe starts from the infocube one designs in BW and the Bex Query on the top of it.
Let me starts from step 1 of creating a universe using SAP BW as backend.
The first step is to design the infocube. Now a lot of people has asked the question, which is better - designing an infocube and accessing it using universe or creating a bex query on the top of the infocube and using that instead. My answer is it depends. Both have pros and cons. Somewhere you may find bex query is better as it is flexible and lets you create custom aggregated dimensions and key figures and also allows using aggregate navigation on the contrary infocube is more like a base data plateform. However if you look into the performance an infocube has better performance then bex query. It has a better tracking allowance then bex query.

If you look from a report designer prospective any custom objects can be created report level. If the reporting requirement is not that complex and there is not much adhocing requirement then one may go for infocube directly as it will give a better performance than a bex query. Given an example if one like to create aggregated measures , he may create it in report level as well as universe level. Report level is going to be much simpler as it adheres to the traditional business objects variable design concept however creating an aggregated measure in universe is complex. It needs xml coding and not very easy to implement. https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0a45246-ce76-2b10-e688-f5c8206203eb

This link provides best practices while creating aggregated measures in BW universes.

One caveat - ONE CANNOT CREATE AGGREGATED DIMENSIONS or CUSTOM DIMENSION IN BW UNIVERSE.
Creating custom dimension is only possible in report level , however if one object should be available to every single user then one must create it in infocube level.

Here comes the advantage of using bex query. Looks very small at the beginning however when one looks at the amount of work one has to do in order to include a new object to the infocube compared to an object in bex query , it makes more sense to go for bex query.

If one needs a new custom dimension derived from existing dimension and also it should to be available to all the users then bex query is the solution. Adding a new dimension in bex query is fairly simple, also as one doesnt have to reload the infocube with data in order to populate the dimension it seems fairly the right choice, on the other hand if one adds a new dimesion to infocube, one must populate the column too
Let me now go back to BW universe.
Steps to create a new universe

1. Login to universe designer


2. Click on new

3. Create a new connection - SAP BW - Choose the infocube or the bex query. If you dont see any infocube or bex query you may would like to discuss this with your SAP BW Admin person as the username you used to login doesnt have the rights. Please refer to the SAP integration kit administrator guide for the rights.


4. Once click okie the universe would look something like this






There will be nothing on the right panel. Only classes and objects on left hand panel. Also the classes would be arranged in the same order as in infocube. The detail object concept is vastly used here. Detail objects are nothing but all the attributes for that dimension. You may have to hide most of it as it brings everything from the master table.
For better performance it is always better to point to the dimension directly. For example [0BILLTOPRTY].[LEVEL01] will have a better performance than [0BILLTOPRTY].[LEVEL01].[[20BILLTOPRTY]].[Value]. So while designing the infocube dimension you should choose the description to be the value and key as an attibute, As most of the time one would like to see the description then the key value.
Another point to be noted is do not cut and paste the objects in order to rearrange it as once you refresh the structure it would rearrange it back and hide or delete the once you moved. So better to copy and paste and hide the one you dont want to see.
Universe anomalies
1. You cannot see the list of values for dimension. You cannot customize them. You cannot create cascading prompts.
2. You can only create custom measures . You cannot create custom dimensions.
3. You dont have row level and sql level security. You only have object level security.
4. You can create filters and make them global or local to a class , this may help you to achieve a little bit of row level security
5. Filters are also defined in XML coding, different than conventional way. You may refer to the document mentioned above for further details.
6. Hierarchy - SAP BO XI 3.1 has solved the hierarchy problem with sap bw. Still once has to arrange the objects in the universe level in order to achieve hierarchy.
7. No Non ASCII / ASCII parameter will work here.
Another major anomaly with SAP universe is the way one always has to include a key figure in a report in order to get a valid set of data. If one adds two different dimensions and no key figure it would create a cross join between these two objects. SAP explanation is two dimension has no related between them till the time there is a valid key figure giving sense a relation between these dimensions, which to me seems pretty acceptable.
I think i have covered most of the universe design. Please let me know if you have any question. later on i will be touching how to create custom measures and filters and how you may increase the performance.
Thanks
-Arpan B.



Friday, May 15, 2009

SAP Business Objects Vs Old Business Objects`

A Very Good Morning,
I am a old religious follower of Business Objects starting from 6x where it suppose to be a typical reporting tool, pretty much comparable to OLAP reporting tools like Cognos, microstrategy. Reports were pretty much created in Desktop Intelligence, saved in local machine and then using version controlled to infoview. Pretty much developer used to create the reports as they used to be complex. Following Datawarehousing concept in every step used to be daily routine. Talking about agile methodology and Ralph Kimball used to make us smile.
Business Objects in its native form is an extremely powerful tool, as it allows developers with a good knowledge in databases SQL to create amazingly difficult reports with ease,and surprise the business users a lot. The thin layer of difference between a report created by a developer and a business user was intact. The layer was good for us as we are the developers and that is our bread and butter. And also the continous interaction between business user and the IT personal is very important for a company as it allows a free flow of knowledge between these two groups. This also allows the sequential growth of the company data and data management.
Coming back to Business Objects, it allows a single platform to create complex reports combining data from disparate systems or putting differnt kind of business rules within the report layer and providing a flexibility to provide data for different audiences using the same data mart, whereas it also allows a business user to create adhoc reports it satisfy their smaller need.
Then came the era of designing different kind of tools , acquisition of business objects by SAP and the overall idea of datawarehousing was clouded by the SAP and its fancy tools. like SAP BW , SAP XI. These tools are good within their own terms, pretty power ful and flexible. However given the case , they are also away from the concept of CWM. Very much intact within SAP and also strictly following the SAP rules is making these tools very difficult to accept atleast for developers like me. Every time one is working with SAP he will face the problem," SAP doesnt allow external tools to access its data directly, it has to go via a either integration kits or you just cant do it"
Currently i am working with SAP BW and as i am mentioned i am a BO follower so still engaged with Business Objects. During the next set of our jouney towards BO to SAP i would like to elaborate the transition of methodology, the momentary stepping away from the concept of data warehousing and how you can still hold on to the new concept as well as walking along side the CWM/Datawarehousing.
Also the major reason to start this blog is to give a open platform for the old BO developers to learn the integration with SAP BW/R3 and what possible problem one face while doing it for the first time. Also i felt the information is kept like a secret, away from all the BO guys who are not member of so called "SAP group". Initally i felt it very hard to learn a lot of things about the new BO as it is not placed in a proper way in sdn.sap.com site, also coded in the SAP terminology.I would like to break the jinx.

-Wait for new post on SAP Business Objects...