Universe Overview
Transcript of Universe Overview
SAP BusinessObjects Name Changes SAP BO Business Intelligence 4.0
Key Takeaways:
1. The new SAP BusinessObjects (SAP BO) names don’t 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 well-liked
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, you’ll run into names like “Crystal
Dashboard Design” that are not in use for large enterprise SAP BI products. This is
intentional on SAP’s 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 NetWeaver’s 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 doesn’t 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
Let’s 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”. Let’s 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 wouldn’t 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 UniverseIn 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.
Let’s 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.
Let’s 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. One query to find number of rows from manager table
2. One query to find number of rows from employee table
3. 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 that’s why
databaseshould contain realistic data.
Detect cardinality using automation tool.
To detect cardinality of all joins
1. From Tools->Automation Detection->Detect Cardinality
2. If no joins is selected, it asks for if you want to detect cardinality for all joins.
3. Click OK.
To detect cardinality for specific join
1. Right click on specific join
2. Click on detect Cardinality
To set cardinality manually
1. Double click on join for which you want to set cardinality
2. Edit join dialog appears with join expression
3. Check on cardinality check box
4. Select appropriate 1,N radio box
5. 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 JoinsSince 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. Position The table close to each other
2. Drag the column from one table on the column of other table to which you want to join the table
Defining Joins by using defining join properties in SAP BO UNIVERSE
DESIGNER
1. From Insert menu click on “Join”
1. From “Edit Join” properties select table table1 and table2 in between which you want to create
joins.
2. Select the columns from both the table which would be part of joins
3. Once Columns are selected join expression will be created in expression text boxyou can specify
join operator here if you want to join table using other than “=” operator.
4. Click OK. Join will be created between two tables.
Joins can also be created automatically in SAP BO UNIVERSE DESIGNER
1. Select table you want to create join for.
2. from the editing toolbar click on “Detect Join” icon
3. A dialog will pop up showing possible joins for selected tables based on similar column name
4. Click Insert to create selected join.
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 StructureBuilding 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
Let’s start designing schema by adding tables.
1. Connect to a database by creating data source connection.
2. Launch database table browser in universe. You can launch table browser either by two way
1. Double click on design pane
2. From Insert->Tables menu
1. Select the table of view by clicking on it and click on Insert button to insert a table in SAP BO
Universe designer pane. You can also add table by double clicking on it.
2. After adding all tables in SAP BO Universe designer pane it should like as below. Once 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. Double click on object in designer to view its properties.
2. Click on Properties Tab
3. Click on “Associate a List of Values” checkbox.
4. 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
It’s 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. Click on Edit button on objects edit properties tab
2. The designer query panel will appear showing default object of a LOV
3. Drag drop the condition object in condition pane and specify the appropriate condition.
4. You can also view the SQL of the LOV query by click on SQL icon on toolbar.
5. 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. Click on Tools->List of Values->Edit
2. List of values dialog will appear
3. Select the LOV objects and click on Edit if you want to edit a LOV.
1. In addition to query you can also define LOV for an object using personal data file like CSV and
values from this file can also be used as LOV for an object. To do so.
2. Click on Personal Data and provide the details on Personal data LOV dialog box.
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. Add the object and re-arrange them as per your hierarchy
2. Click on generate LOVs
3. 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. Join the tables using common column between tables.
2. Check the shortcut join check box to mark join as shortcut.
3. Shortcut join is represented as dotted line.
4. 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 organization’s 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 end-
user 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.