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.