SAP BusinessObjects Name Changes SAP BO Business Intelligence 4.

0
Key Takeaways: 1. The new SAP BusinessObjects (SAP BO) names dont officially go into effect until the release of SAP Business Objects 4.0 in 2011. BO 4.0 will rollout with an SAP-style ramp-up in late 2010 with a broader release in 2011 once initial KPIs are met. That means the older names will still appear in prominent places for a number of months, including on Service Marketplace. 2. SAP took an inclusive approach with this round of name changes, consulting with user groups before making the names official. The end result? A bit more simplicity in naming, and the preservation of one universally wellliked product name: Web Intelligence (or Webi as most call it). The rumors about Webi changing to other names like Interactive Analysis can now be squelched. Webi will remain Webi. 3. There is still some naming variation with small market (high volume) products. If you dig into SME BO naming, youll run into names like Crystal Dashboard Design that are not in use for large enterprise SAP BI products. This is intentional on SAPs part and not intended to create confusion at the enterprise level. 4. The XI monicker, used extensively in the BusinessObjects world, is being eliminated from future releases, starting with 4.0. This is a welcome shift for SAP users, who are still working through the shift from Exchange Infrastructure (XI) to Process Integration (PI) for NetWeavers middleware stack. SAP Business Objects 4.0 Name Changes: SAP BusinessObjects (SAP BO) Enterprise Premium is now SAP BusinessObjects Business Intelligence Suite.This name change is not an issue for SAP customers but it is a shift for BusinessObjects users who are used to the BOE abbreviation. Crystal Reports is now SAP Crystal Reports. Translation: SAP owns Crystal now, and doesnt want you to forget it. In seriousness: the SAP in front of Crystal is intended to distinguish the enterprise edition from the high volume edition of Crystal Reports in the SME space.

SAP Business Objects Xcelsius Enterprise is now SAP BusinessObjects Dashboards. Context: SAP wanted to move the popular dashboarding product further from associations with Excel as it expands Dashboards to non-financial users. As logical ammunition for this change, SAP points out that as of BusinessObjects 4.0, Dashboard users no longer need to use the Excel layer to author their queries. Given the wide recognition of the older name, this is the most significant name change in the 4.0 release. SAP BusinessObjects Voyager (aka Advanced Analysis Web, Pioneer) is now SAP BusinessObjects Analysis. Many thought this new name would be Advanced Analysis, but there was a good argument for keeping the product name simple. In the BI industry, Advanced Analysis implies advanced, predictive analytics, whereas the new BO Analysis name more accurately reflects the OLAP-based nature of the tool, with OLAP providing a structured and historical view of data rather than a predictive emphasis.

There are, however, two roadmap paths involved: 1. Most SAP BusinessObjects(SAP BO) users will transition in 4.0 from SAP BusinessObjects(SAP BO) Voyager to SAP Business Objects Analysis, Edition for OLAP. This is a web-based version of the tool.

2. SAP BEx Analyzer or BEx Web Analyzer users will have the option of migrating to either Analysis, Edition for OLAP, or more likely for BEx Analyzer users, SAP BusinessObjects Analysis, Edition for Microsoft Office, which SAP envisions as the successor to the BEx Analyzer tool many SAP BW users are familiar with. One important clarification: the Microsoft edition of Analysis is also OLAP-based. BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP Business Objects Universe Designer Preventing Chasm and Fan Traps
DEC 12TH Posted by admin in SAP BusinessObjects 4 comments

SAP Business Objects Preventing Chasm and Fan Traps!

In this article I would like to talk about Chasm traps and Fan traps. These are problems that we often experience while building universes and reports. When encountering these traps, one may wonder what is going on? How come my sum statements arent adding up correctly? Or why am I missing some rows? A properly designed universe will help avoid these problems. In addition, a good understanding about measures and contexts from report designers will help as well. Chasm Traps Lets talk about Chasm traps first. In short, a Chasm trap can be imagined as a bottomless pit where some rows may unknowingly fall in and never come back out. So when viewing a report caught in a Chasm trap, one may ask Hey where did Record X go??.

Looking at the eFashion Universe (note that this is a modified version of the efashion universe), we see that there are 2 fact tables that join to 2 of the same dimension tables. If we do not set a context for each of the fact tables in the universe, we will only get 1 query when building a report that involves measures from both fact tables. SELECT Article_lookup.Article_id, Shop_facts.Amount_sold FROM Article_lookup, Shop_facts, product_promotion_facts, Calendar_year_lookup WHERE ( product_promotion_facts.Week_id=Calendar_year_lookup.Week_id )

AND ( Article_lookup.Article_id=Shop_facts.Article_id ) AND ( Article_lookup.Article_id=product_promotion_facts.Article_id ) AND ( Shop_facts.Week_id=Calendar_year_lookup.Week_id ) Since the promotion fact table and shop fact table are joined in the same query, we will only get results that are in both the promotion fact and shop fact table. In reality we want all available products even if they are not on promotion. The products that are not on promotion will fall down the bottomless pit and report designers will be wondering where they have gone. Fan Traps Fan trapsare another common problem and occur when a measure is overstated. So using the same example above, thepromotion cost measure is a sum of promotion costs. Lets say for one product we might have 5 entries in the shop fact table and 2 entries in the promotion fact table. Instead of a one-to-many join for the promotion fact table, we now have a many-to-many join which will cause a cartesian product. The promotion cost for that product will be 5 times higher than what its supposed to be since we have 5 entries in the shop fact table.

Prevention To prevent falling into these traps, we must properly set our contexts in the universe. Here we set a context for both the promotion fact and shop fact. As a rule of thumb we should always set contexts for facts.

Setting contexts for these 2 facts will now produce 2 queries that will be synchronized thus returning the correct results because now we have 2 seperate

joins instead of 2 joins in the same table.

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP Business Objects Universe Designer Best Practices

DEC 12TH Posted by admin in SAP BusinessObjects 3 comments SAP Business Objects Universe Designer best practices

SAP BUSINESS OBJECTS UNIVERSE DESIGNER: object creation Object and class naming should be in business terms so that it makes sense to the end-user. This also reduces development overhead since reports can use descriptions out-of-the-universe, instead of editing headers or creating report level variables. All objects should have help text or usage information corollary from above. Object formatting should preferably be done at the BO Universe level. Pre-build condition objects in the BO Universe rather than forcing users to build conditions for reports. Build logic into objects translate code, common calculations etc rather than forcing users to do it in report variables. Avoid using WHERE clauses in the object definitions; use CASE statement instead. In most cases, using WHERE clause will return incorrect results when similar objects are included in the result set, due to combined restrictions imposed by the multiple WHERE clauses. Use aggregation in all measure objects to push the aggregation to the database wherever the performance bottleneck is likely to be BO server and the database performance is optimal. Generally the database is much more powerful at doing aggregation calculations, and this also reduces the volume of data to be transported over the network. All measure objects should include aggregation functions for projection. When this is not included, BO will not automatically roll-up the data in the report, which could result in incorrect data and analysis. Note that in the 3.0 version of BO Designer, a new feature Database Delegated projection function is available to take care of these anomalies while doing averages for instance. Use Custom LOVs or cascading prompts to display LOVs where hierarchies and numerous values are involved. Use relative date objects for scheduling e.g. Today, Yesterday, Previous Month etc. Create a separate class to contain these reporting objects this helps in improving maintainability. Use dynamic HTML in objects where required to avoid users having to build it in report variables end users wouldnt like to code hyperlinks themselves, but would love to have an object which when clicked can lead them to Google Maps for example.

 Use contexts in universes having multiple fact tables this helps in getting your measures (built from multiple fact tables) right. Use derived tables to define measures dependent on multiple fact tables. Use derived tables to reduce complexity of queries to be written by users or in place of views or procedures. A note of caution here: Use derived tables sparingly. If you have access to the database or DBA and can get views or tables created for the same purpose, go with it rather than using derived tables. This is not only to push the logic and work closer to the database, but also to take care of the performance and maintainability aspects. Exceptions to this include cases where your derived table may include a prompt which would restrict the number of rows returned and thus improve performance over a conventional view. Reuse code with @Variable. Reuse interactive objects with @Where (if you use them at all). Use @Prompt syntax for conditions and interactive objects where input values are likely to change or absence of prompt would lead to inaccurate values or unacceptable query response times. Also make sure regularly used conditions e.g. current year / latest date should not have prompts to avoid annoying users. To limit the number of objects created to avoid user confusion, build interactive objects with @Prompt syntax followed by additional OR clause to include All condition. E.g. ALL IN @Prompt(Enter Value or ALL,A, Class\Object,multi,) OR Table.Column IN @Prompt(Enter Value or ALL,A, Class\Object,multi,) SAP BO Universe design: resolving join and performance problems To resolve a chasm trap, define a context for each table at the many end of the joins. To resolve a fan trap, create an alias table for the table producing the multiplied aggregation. Create a 1:1 join between the original and the alias tables. Modify the select statement to use the columns from the alias table instead of the original table. Use of contexts should be evaluated w.r.t. use of aliases for resolving join issues, to take care of maintainability of code. Integrity checks on the BO Universe structure, parsing of objects, joins, contexts, detecting loops etc is mandatory. If you wish to use Business Objects to help you detect fan traps or chasm traps you must set the cardinality on the joins. Do not rely on BO to suggest the cardinality this is often erroneous, based on the records sample that BO fetches for each table. Uncheck the Multiple sql statements for each measure option in BO Universe parameters, if this is not required for resolving any join problems. This option should be checked if the measures being retrieved in the same query involve different tables. Prevent Cartesian product should be checked,

as should there be limits placed on the number of records returned and the time for the sql connection to prevent runaway queries which can bring the database down to its knees and cause an outage for all users. SAP BO Universe design: optimization / miscellaneous Use shortcut joins wherever possible to reduce number of tables used in a query Use aggregate tables /materialized views with aggregate awareness set up to improve query performance Use keys instead of labels where possible to take care of index awareness benefits of performance and uniqueness Use the JOIN_BY_SQL parameter to shift process from BO server to database wherever the bottleneck for performance is the BO server and the database performance is optimal. Update the .prm files to enable access to custom SQL functions and improve help text Do not use derived tables instead of aggregate tables. Turn off LOVs for all dimension and detail objects that are redundant or not required. This prevents performance problems when users inadvertently click on the Values and the query sets to return all the IDs or other irrelevant data. Consider using linked universes with a master kernel universe to ensure consistent dimensions across multiple universes

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP Business Objects Universe Designer Development Process Define Join Cardinalities
DEC 11TH Posted by admin in SAP BusinessObjects

Define Cardinalities in SAP Business Objects Universe

In previous post we have learned how to set up join in SAP BO universe. in this post we will lean what is cardinality and how to define cardinalities in SAP BusinessObjects Universe. What is cardinality in SAP BO Universe Designer? Cardinality means a relationship between two tables based on a join. Means how many rows of one table will match with rows in other tables when these tables are joined. Setting up cardinality is very important to resolve loops SAP BO universe. Lets take a practical example of cardinality. A manager can have many employees reporting to him, so the relationship between manager and employee table is 1-N. The cardinality can be any of one type. One-to-One (1-1) One-to-Many(1-N) Many-to-many (N-N) Many-to-one(N-1)

Setting up cardinality manually or using automatic detection tool Cardinality in universe design is based on a logical algorithm, which uses physical count of record from the table.

The automatic detection tool only gives correct cardinality if the database is populated with realistic data. Also, the automatic detection tool fires three queries for every join to set the cardinality. So if you have lots of table in schema, automated cardinality detection tool is not a good idea as it might overload the database with queries. Lets take an example of how cardinality detection tool works. Manager table has multiple employees reporting to each manager so cardinality of manager and employee table is 1-N. Let understand how automated cardinality detection tools determines the cardinality for this join. 1. 2. 3. One query to find number of rows from manager table One query to find number of rows from employee table One query to find number of rows when these two tables are joined

If manager table has 10 rows, Employee table has 20 rows. 1st query will return 10, second query will return 20, and third query will return 20 which would tell that employee table is at many sides and manager table is at 1 side. The output of queries is very important for automated tool and thats why databaseshould contain realistic data. Detect cardinality using automation tool. To detect cardinality of all joins 1. 2. 3. From Tools->Automation Detection->Detect Cardinality If no joins is selected, it asks for if you want to detect cardinality for all joins. Click OK.

To detect cardinality for specific join 1. 2. Right click on specific join Click on detect Cardinality

To set cardinality manually 1. 2. 3. 4. 5. Double click on join for which you want to set cardinality Edit join dialog appears with join expression Check on cardinality check box Select appropriate 1,N radio box Click ok.

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP BusinessObjects Universe Designer Development Process Define Joins

DEC 11TH Posted by admin in SAP BusinessObjects

SAP Business Objects (SAP BO) Universe Designer Development Process Define Joins
Since now we have inserted table in designer pane. We need to define joins between tables. For correct SQL query generation its very important to define joins correctly. There are two different ways to define joins in SAP BusinessObjects Universe Designer. Define joins manually in schema Using edit join dialog by specifying join properties Defining joins manually in Schema in SAP BO UNIVERSE DESIGNER 1. 2. the table Position The table close to each other Drag the column from one table on the column of other table to which you want to join

Defining Joins by using defining join properties in SAP BO UNIVERSE DESIGNER 1. From Insert menu click on Join

1. 2. 3. 4.

From Edit Join properties select table table1 and table2 in between which you want to Select the columns from both the table which would be part of joins Once Columns are selected join expression will be created in expression text boxyou can Click OK. Join will be created between two tables.

create joins.

specify join operator here if you want to join table using other than = operator.

Joins can also be created automatically in SAP BO UNIVERSE DESIGNER 1. 2. 3. name 4. Click Insert to create selected join. Select table you want to create join for. from the editing toolbar click on Detect Join icon A dialog will pop up showing possible joins for selected tables based on similar column

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

Building SAP BUSINESSOBJECTS Universe Designing Structure

DEC 11TH Posted by admin in SAP BusinessObjects 6 comments

Building SAP BUSINESSOBJECTS (SAP BO) Universe Structure

Building SAP BO Universe structure involves designing schema, creating joins. A schema in SAP BO Universe is a logical representation of underlying database schema. Designing Schema This is the very first step of SAP BO Universe design. Designing schema involves adding table, setting up joins and cardinalities and then assessing schema for possible joins problems and fixing them.

To design a good schema SAP BO Universe designer is expected to know the basics of database schema design, business concepts, relationship between different tables and reporting need. Add Tables Lets start designing schema by adding tables. 1. 2. way 1. Double click on design pane 2. From Insert->Tables menu Connect to a database by creating data source connection. Launch database table browser in universe. You can launch table browser either by two

1. 2.

Select the table of view by clicking on it and click on Insert button to insert a table in After adding all tables in SAP BO Universe designer pane it should like as below. Once

SAP BO Universe designer pane. You can also add table by double clicking on it. tables are added it is represented graphically along with its all columns

1.

After adding all tables in SAP BO Universe designer pane it should like as below.

Tips: When tables are added to designer pane it gets arranged horizontally. To arrange them properly click on arrange table icon You can change the table display by pressing Ctrl+T which would be very helpful if you have lots of table in universe.

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP BusinessObjects Universe Designer List of Values (LOVs) & Cascading LOVs
DEC 11TH Posted by admin in SAP BusinessObjects

SAP BusinessObjects (SAP BO) Universe Designer List of Values (LOVs)

List of values or LOVs is a distinct list of data values associated with an object. When any dimension of details object is created LOV is assigned to an object automatically. Use of List of values( SAP BO LOVs) When user needs to filter data in a query based on specific object values, User can simply view the LOV of that objects and choose the value on which they want to filter the data.

e.g. if COUNTRY dimension has following distinct values A,B,C and if user wants to filter the data of country B, user can put a filter on Country dimension and choose the B as filter while executing the query.

How to create a SAP BO LOV for an object. 1. 2. 3. 4. Double click on object in designer to view its properties. Click on Properties Tab Click on Associate a List of Values checkbox. Select other LOV options based on requirement.

When first LOV is created it is stored in .LOV file name at BO universe subfolder on the system file system. The default location is C:Documents and Settings<UserName> Application DataBusiness ObjectsBusiness Objects 12.0Universes@<ServerName><UniverseName> LOV Options List Name Its the name of LOV file by which it will stored on local file system. User can override the default name and can enter his own LOV name. Maximum character limit is 8. Allow Users to Edit List of Values When checked this option allows report users to edit the list of values of an objects. The purpose of a list of values is usually to limit the set of available values to a user.

If they can edit a list, you no longer have control over the values they choose. Normally, if you are not using a personal data file as a list of values source, you clear this option to ensure that users do not edit lists of values. Automatic Refresh before Use When selected this option LOV will be refreshed each times it is referred and used in report. You should choose this option only if contents of underlying column are frequently changing. This options should be use very carefully after evaluation. If this option is not selected LOV is refreshed first when the objects is used in a user session. Hierarchical Display Select the Hierarchical Display property to display the cascading list of values as a hierarchy in Web Intelligence. Export with BO Universe When this option is selected LOV file associated with object is exported to universe CMS and gets stored as XML on CMS Viewing the LOV of an object To view the LOV of an objects click on display button on properties tab of an object

Modifying the LOV of an object

You can remove the values from LOV of an object by applying a filter or add values to LOV by adding a column. Apply condition on LOV To apply condition on LOV 1. 2. 3. 4. 5. Click on Edit button on objects edit properties tab The designer query panel will appear showing default object of a LOV Drag drop the condition object in condition pane and specify the appropriate condition. You can also view the SQL of the LOV query by click on SQL icon on toolbar. Run the query to test the values after applying condition on LOV

View and Edit LOV of complete universe You can also view all the object which has LOV associated with them and edit them. 1. 2. 3. Click on Tools->List of Values->Edit List of values dialog will appear Select the LOV objects and click on Edit if you want to edit a LOV.

1. 2.

In addition to query you can also define LOV for an object using personal data file like Click on Personal Data and provide the details on Personal data LOV dialog box.

CSV and values from this file can also be used as LOV for an object. To do so.

Cascading LOV

Cascading LOV is a LOV associated with hierarchy of an object in the universe. Cascading LOV is created, and if any of the object is used as prompt filter in report query, user has to answer series of values from cascading LOV. How to create Cascading LOV 1. Click on Tools->List of Values->Create Cascading LOV.

1. 2. 3.

Add the object and re-arrange them as per your hierarchy Click on generate LOVs Click OK.

Now if you use any of the objects as prompt in query. It will prompt the hierarchical LOV to user. BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP BusinessObjects Universe Designer Shortcut Join and Usage

DEC 11TH

Posted by admin in SAP BusinessObjects

SAP BusinessObjects Universe Shortcut Join and What is its use in BO

Shortcut join In SAP BusinessObjects (SAP BO) Universe Designer Shortcut join is a join that joins tables by bypassing middle table that exist in the universe. Generally shortcut joins are used to generate more efficient query by reducing the joins in the query. e.g. Consider following scenario. If we want to see article and its sold amount the query will join article_lookup and shop_facts through product_promotion_fact,

However this is not a efficient query as we can simple join article_lookup ans shop_facts using article_id.

But creating such a join, It will introduce a loop in SAP BO universe, now you can solve this loop using alias or shortcut join. Lets see how we can solve this using shortcut join. Instead of creating normal join between article_lookup and shop_fact, we will create shortcut join. Now check the loop. You could see that, loop has been resolved. How to create shortcut join In SAP Business Objects (SAP BO) Universe Designer 1. 2. 3. 4. Join the tables using common column between tables. Check the shortcut join check box to mark join as shortcut. Shortcut join is represented as dotted line. Click OK.

BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP BusinessObjects Universe Designer Testing Process and Best Practices

DEC 11TH Posted by admin in SAP BusinessObjects 5 comments SAP BusinessObjects Universe Designer Testing Process and Best Practices There has been a lot of questions from SAP BO developers about the best strategy to test a universe. In this post, We will talk about how to test a SAP BusinessObjects universe once the development/design Process is completed. Before we begin testing the universe, it is a good practice to refresh the universe structure. Refreshing the universe structure detects if any columns were added/removed to/from the tables, if any tables were removed from the database or if any tables were renamed in the database.

Testing a universe will need to be done in two phases: 1. Testing metadata in SAP Business Objects (SAP BO) Universe In this phase, wewill test the integrity of the entire universe. In other words, we will: Test syntax(parse) of all the objects in the universe Test syntax of all the joins in the universe Test syntax of all the predefined conditions in the universe Make sure that there are no loops BusinessObjects Loop Defination: BO Loop is nothing but a closed circular flow; it can be overcome by making use of Alias and Context. Make sure that there are no fan/chasm traps BusinessObjects Traps Defination: Chasm trap The Chasm trap occurs when two many to one joins converge on a single table. For example a customer can place many orders/and or place many loans. Fan trap The Fan trap occurs when a one to many join links a table which is in turn linked by another one to many join. Make sure there are no Isolated tables; which means that each table is added to atleast one context(if there are contexts defined in the BO universe) Make sure that there are no loops within contexts(if there are contexts defined in the universe) Thanks to SAP BusinessObjects, there is a check integrity tool included in the universe designer application that will assist we in performing all the aforementioned tasks. However, for the tool to rightly detect/resolve loops, traps etc, we will have to set the cardinality correctly. We should never use the detect cardinality option in the designer application. Why? Because the application will have no idea about your data, so we should set the cardinality for all the joins yourself manually as we know our data well. Besides what has been listed above, we will have to make sure that for each measure object, there is an appropriate aggregate function defined in the select clause and an

appropriate projection defined on the properties tab of the object. Though this is not directly related to testing, it will help you enhance the performance of the reports by pushing the pain of aggregating data down to the database server. The projection setting will display data in reports at the appropriate level of detail.

2. Testing data in SAP Business Objects (SAP BO) Universe In this phase, we will test the actual data that will be extracted from the database using the objects, joins etc defined in the universe. This is a bit tricky when compared to testing the metadata of the universe. Here are a couple of methods that I use to test the actual data: Unit Testing or System Testing: Create reports on top of the universe and verify the numbers against already existing reports. Create adhoc reports using the BO universe by dragging and dropping objects into the query panel(WebI or DeskI). Take a look at the generated SQL and see if it makes sense, especially check whether the joins are defined as per the data model. Create enough reports so that all the objects in the BO universe are tested. User Acceptance Testing: Let the business users create adhoc reports using the universe and verify the data. Please be sure to include all the users from whom we got the requirements for the universe. This is probably the best method in my opinion. Users are well aware of the data and this way we can also get their sign off. BO Designer, BusinessObjects Designing Developement, SAP BO Designer, SAP Business objects Designing Developement, SAP Business objects Developer, SAP BusinessObjects Designing Developement, SAP BusinessObjects Developer

SAP Business Objects(SAP BO) Universe creation Best Practices

DEC 4TH Posted by admin in SAP BusinessObjects SAP Business Objects(SAP BO) Universe A SAP Business Objects(SAP BO) Universe is the semantic layer that resides between an organizations database and the end user but more importantly, it is a business representation of data warehouse or transactional database. It allows the user to interact with their data without having to know the complexities of the database or where the data is stored. Data manipulations on the universe will not affect the underlying database. The BO universe is created using familiar business terminology to describe the business environment and allows the user to retrieve exactly the data that interests them. Universes are made up of objects and classes that are mapped to the source data in the database and accessed through queries and reports. A universe contains A connection parameter to a single data structure. SQL structures called objects that map to actual SQL structures in the database. All objects are grouped into classes and subclasses. A schema of the tables and joins from the database. The objects are built from the tables that are included in the schema. Benefits of using SAP BO Universe The Universe Designer application allows users to create universes using simple GUI. Data security data exposed by the universe can be limited to a specific group of users. All data is secure. The data is read-only so there is no danger of the data being edited or changed by the end user. Changes made to universe data will not affect the original data. Maintenance of the universe is easy. End-users can use a simple interface to create reports and analysis and work with consistent business terminology.

Where can we use the SAP BO Universe

Best Practices in Building a SAP BO Universe 1. It is a good practice to build Universe piece-by-piece. 2. Avoid using automatic universe creation wizard. Universe created using wizard will be complex and difficult to understand. 3. Insert tables into universe one at a time. 4. Take each table, joins and cardinality one at a time. 5. Use short cut joins whenever possible to reduce no. of tables used in a Query. 6. Name the objects using common business terms as it would be easy for the enduser to understand. 7. Define measurable objects properly as not every number is a measure.

8. Maintain object formatting format the object in the same way every time it is used. 9. Object formatting should be done at the Universe Level. 10. While using complex objects build common calculations into universe where ever possible. 11. Never load user with complicated queries. 12. Lock the universe when editing to prevent other users from editing the same universe.