BUSINESS OBJECT IMPORTANT FEATURES

1.Generating LOVS

List of values or LOV 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.

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 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 universe subfolder on the system file system.

The default location is

C:\Documents and Settings\\Application Data\Business Objects\Business Objects 12.0\Universes\@\

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 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.

1.FUNCTIONS IN BUSINESS OBJECT

a.@prompt

Description:Use this function to prompt user for a value will be used during report run. For example if you want to run a monthly report against a specific month, you have to prompt the user to enter the Month or even select it from the list of value displayed.Before we start:I assume that you are familiar with BO universe designer and BO web inelegance. If you need to go through universe or Webi rich client tutorial please use the following links:

Universe Tutorial:

BO Fast user guide Part # 1 [Navigation]:

BO Fast user guide Part # 2[Report View mode]

Universe Parameters

Syntax:@prompt ('prompt text (1)', 'type (2)', 'list of values(3)', 'mono/multi(4)', 'free/constrained(5)')

Parameters:

Param

Description

Mandatory

Values

1

Text used to prompt the user when he trying to run/refresh the report

Yes

N/A

2

Type of the expected value entered by the user and also must be same type of the object that we will use the prompt return value to compare with

Yes

A: alphanumericC: stringD: DateN: NumberU: Unicode

3

List of values that will displayed to the user if he click on the Values button when he prompted to enter a value

No

Object defined to retrieve list of values

4

Number of valued allowed

No

Mono: user can select one value onlyMulti: user can select Multi Values

5

User can edit enter a value by himself or not.

No

Free: user can type his own valueConstrained: user must select from list of values.

Where to use this function:You can use this function anywhere; this is some places that you can use this function

Filter: you can use this function to prompt the user for a value that will use in filtering the retrieved data. [Click here for more information about conditions & Pre-defined filters in BO]

Where clause: when you create an object you can use this function in the where clause.

Select clause: you can use this function even in the select clause see examples.

Derived table: you can use this function in your derived table query. [Click here for more information about how to use prompt with derived tables]

Tips and Tricks:

You can use the same prompt in more than one place; just make sure that the prompt text exactly the same when you use it with other universe objects.

You can use data conversion function to convert the prompt returned value before using it. For example if the prompt return "Jan09" and you want to compare it with a Date column in database you have to convert it before using it. In our case we will use to_date (@prompt(,,,,,),'MONYY').

If your prompt will return multi value use IN operation instead of equal (=)

Note that not all users having permission to view list of values while they trying to run or refresh the report by default. The administrator should grant this permission to this user.

If you will use the free mode (user can type what he want) you should give a hint in the prompt text message about the data format expected. For example if the user should enter month in format (MON YY) then the prompt message should be descriptive like "Please enter month like Jan 09".

Example # 1 (simple prompt):We need to create a new condition that will prompt user to enter a valid date to display data related to this date in our report. Create a new condition with the specification below [Insert --> Condition]

Name: As of Date prompt

Description: Prompt user to enter a specified as of date value

Where:@select(Dimensions/As of Date) = @prompt ('Enter As of Date:', 'D', ['Dimensions/As of Date'], mono, constrained)

Notes:

Red single quote places. It will give you error message "Parse failed: invalid definition UNV0023"

Example # 2 (Prompt returns multi values):We need to create a new condition that will prompt user to select cities that he wants to display revenue dataCreate a new condition with the specification below [Insert --> Condition]

Name: Cities prompt

Description: Prompt user to select one or multiple cities to filter data according to

Where:@select(Dimensions/City) IN @prompt ('Select one or more cities from the list:', 'C', ['Dimensions/City'], Multi, constrained)

Notes:

We used Multi key word instead of mono this time this to indicate that the prompt will return one or more values.

Note also we used the IN operator instead of equal. This is because the return value is a collection of values not one single value as the previous example.

Example # 3 (user type Free Prompt):We need to create a new condition that will prompt user to type the city that he want to display report data for.Create a new condition with the specification below [Insert --> Condition]

Name: City prompt

Description: Prompt user to select or type a city

Where:@select(Dimensions/City) = @prompt ('Type a City name:', 'C', ['Dimensions/City'], mono, free)

Notes:

Note that we have used free key word instead of constrained. This will give the user the flexibility to type the city name directly without need to select form list of values.

Note that if the user type Paris while the stored value in @select(Dimensions/City) is PARIS then the query will return no data. To solve this issue you can use the Upper or lower function that will return the given string in upper case format or lower case format.UPPER(@select(Dimensions/City)) = UPPER(@prompt ('Type a City name:', 'C', ['Dimensions/City'], mono, free))

If you want the user to type multiple cities use this form@select(Dimensions/City) IN @prompt ('Type Cities name:', 'C', ['Dimensions/City'], Multi,free)Please note that user will enter values comma separated without space Like: (Paris,London,Roma,Cairo)

Example # 4 (From To prompt):We need to create a new condition that will prompt user to enter "From Date" and "To Date" to display data related to this period in our report. Create a new condition with the specification below [Insert --> Condition]

Name: From To prompt

Description: Prompt user to enter a specified period

Where:@select(Dimensions/As of Date) Between @prompt ('From Date:', 'D', ['Dimensions/As of Date'], mono, constrained) AND @prompt ('To Date:', 'D', ['Dimensions/As of Date'], mono, constrained)

Example # 5 (Use prompt with dimensions):We need to create a new dimension that will display customer segment description based on what language user will select.Prerequisites:

Language dimension Created.

Segment English Description created.

Segment France Description created.

Segment Dutch Description created.

Segment Arabic Description created.

Create a new Dimension with the specification below [Insert --> Dimension]

Name: Customer Segment Description

Description: Customer Segment Description based on the user selected language.

Select: Decode(@prompt ('Select Language:', 'C', ['Dimensions/Language'], mono, constrained),'EN', @select(Dimensions/Segment English Description),'FR', @select(Dimensions/Segment France Description),'DE', @select(Dimensions/Segment Dutch Description),'AR', @select(Dimensions/Segment Arabic Description), @select(Dimensions/Segment English Description))

Prompt in SAP Business Objects WEBI Report

Introduction:

There is 2 types of filters that you can use in create query in your Webi report.

Static Filters: Doesn't need any interaction from the end user. the criteria or filter values are impeded inside the filter and will submitted directly to the database. Static filter is either created in the universe and you can just drag and use them. They will appears like a yellow cone. You can also create your own static filters by dragging an object and set you filter values to constant or select from list of values. Again, when you refresh data fro your report it will not ask the end user to enter any values as the filter values already defined.

Dynamic Filters: [Also known as prompt] It will prompt or ask the end user to enter or select filter values before submitting the query to the database. You can create your prompt in the universe designer and make it available and ready for use or you can do it on the report development time. For more information about how to create prompt in universe click here.

To create a prompt in info view or rich client data query just drag the object that you want to use it as a prompt let say Region or Product for example. Then select the required operator, lets say Equal to or greater than. After that you need to select Prompt in the filter value.

The following window will displayed to set the prompt the following prompt options:

Prompt Text: Enter the text that will be displayed for the end user to ask him to enter or select value.

Prompt Properties:

Prompt with list of values: Will display a list of values for the selected object to the end user. the end user will be able to select one or multiple value instead of entering them manually.

Keep Last Value selected: Will keep the last value entered by the end user selected.

Select only from list: end user will not be able to enter any data manually and he will just forced to select from the list of values. of course this option will be enabled only of we selected the prompt with list of values option.

Optional prompt: If this option is selected the end use will be able to skip this prompt. the value will be considered only if the end user selected a value for this prompt.

Set Default Values: You can enter Default values here.

Best Practice:

As you can create static and dynamic filter in the universe you need to differentiate between them. we used to write [Filter] beside the static filter name like: Last Year [Filter]. and we use the ? at the end of filter name if it is a dynamic one [Prompt] like: Enter Year ?

Choose a clear prompt message

If you will use the prompt with list of values option then you have to optimize it from the universe to insure the performance

Derived Table in SAP Business Objects Universe Designer

Overview:

Derived table is one of the features provide by SAP business objects universe designer. It is a logical table created on the semantic layer level [Universe] and will be executed at run time. This is different from physical table as physical table store data and can be manipulated by DDL and transactional statement. While in Derived table it acts like database view.

How to create and implement Derived tables:

Open universe designer and right click on any empty space in the right ban (physical layer) OR go to insert menu and select derived table

Type a proper name for your derived table.

Write the SQL select statement that will be used to define your derived table in: Enter SQL Expression Area

You can use Table & Columns panel in the bottom left corner to make it easier for you when selecting the required column in your derived table definition.

You can select a derived table from derived table panel to create a nested derived table.

You can select the required operator from the operator panel in your calculated fields.

Check syntax of your derived table definition and resolve SQL errors if any.

Click ok to complete your derived table.

Now you will be able to see your derived table in the physical layer and you can start use it as a normal table (Join, Create objects,etc)

Using Prompt in derived table:

You can use a prompt in the definition of derived table. When you use any object related to this derived table it will prompt the end user to enter the required values. You can use prompt in the where clause as well as in calculated column definition.

Nested Derived Table:

Nested derived table is a derived table created on top of another derived table. This is a new feature in BO XI 3.0 and onward. You will use one derived table to define the other one. Normally we use nested derived tables if we want to simplify the design when have a very complex business logic. In that case we will build small derived tables and we will start using them in the bigger one. Please note that you can create as many derived tables as you wish but you only allowed to nest up to 20 level of derived table.

List of derived tables:

for very large universe it will be impossible to manage your derived tables if you dont have a centralized place to access them. List of derived table window will give you that function. to access it click on tools menu, then select List of derived tables. you can edit remove or add derived tables from that window.

Derived table best practice, advantages & disadvantages:

Write your derived table name in capital letters and without spaces. You can use _ as a separator between words. Example: AB_EXAMPLE_TABLE_DRV

Use _DRV as a suffix to your derived table name to segregate between derived tables and other tables (Aliases & physical tables)

If you have a permission to create a DB view, then it is better to use it and imported to your physical layer.

Use derived tables in the following cases:

If you need to use a prompt inside your table.

If you have a complex logic to be implemented and you can do it from report level.

If you have one big lookup table and you want to create specific mini lookups.

Always check syntax before creating derived table.

Give calculated columns a meaningful name as it will be displayed in the table view.

Use nested derived tables when you have very complex business logic. This will make your universe more readable and understandable by other developers.

You may encounter a bad performance when using derived table as it is a logical table and there is no data stored in it. You can create an index or adjust table space or do any performance enhancement on your derived table. But on the other hand you can be carful by optimizing the performance for the SQL select statement used in the derived table definition.

Add SQL comments in the definition of your derived table to explain your derived table and make it easier for other developers to know why this derived table was created. You can also describe business logic and column definition.

Remember this constrain: Nesting derived table is limited to 20 level

Derived Table Examples:Derived table:

Nested Derived Table:

Derived table with prompt:

Using @Variable Functions in the Universe

I wrote an article earlier this year regardingthe use ofthe @Variable universe function in the END_SQL universe parameterto help DBAsidentify Business Objects queries (see related article Identifying SAP BusinessObjects queries using END_SQL). The @Variable function can also be used in the SELECT clause of objects for display to the user or in the WHERE clause to restrict data. For example, in my presentation Secure Universes Using Restriction Sets, I implemented row-level security on the eFashion universe using @Variable('BOUSER'). Row-level security can also be implemented inside of the universe by the use of a mandatory condition, a great new feature introduced in Designer XI 3.0.

NOTE: Starting with BI 4.0, the Designer application from XI R2/XI 3.0/XI 3.1 is now knownas the Universe Design Tool.

The SAP BusinessObjects XI 3.1 universe designer manual (click to download from SAP Help Portal)describes for the first time several new system variables. Its unclear whether the variables were introduced with XI 3.0 (theyre not documented in the XI 3.0 edition of the universe designer manual) or were simply undocumented in previousreleases. While on the subject of documentation, allow me to mention that Dave Rathbunelegantly describes several previously undocumented attributes to the @Prompt function(see Dave Rathbuns article Designer XI 3 New Feature: Extended Prompt Syntax) that are finally documented in the XI 3.0/XI 3.1 universe designer documentation (p. 537-538).

The built-in @Variables for XI 3.1 are BOUSER, DBUSER, DBPASS, DOCNAME, DPNAME, DPTYPE, UNVNAME, and UNVID. To use them, place them inside of single quotes as a parameter to the @Variable function. It is important to note that @Variable is a universe function (along with @Prompt, @Select, @Where, etc.) to be used in the Universe Design Tool (Designer), not a report-level function to be used within Web Intelligence.

I created some objects in a universe to demonstrate each @Variable. Their values can be seen in the Web Intelligence report below. One minor lesson learned during the creation of this blog post: I had originally named the Web Intelligence document Using @Variables, but this wreaked havoc with SQL generation because I was also using @Variable('DOCNAME') in the END_SQL of the universe. A minor recursion problem, apparently. That is why the sample Web Intelligence document is instead named Using AT Variables.

The @Variable('BOUSER')returns the name of the InfoViewuser running queries in the document, which in this example is DMarks. Prior to XI Release 2, there was a @Variable('BOPASS'), but it has been depreciated for security reasons. Similar to BOUSER/BOPASS, @Variable('DBUSER') and @Variable('DBPASS') return the username and password only if the user has database credentials enabled in their user profile in the CMC. If the database username/password is defined by a universe connection, these @Variables will be blank.

@Variable can also be used to return information about the current report. The @Variable('DOCNAME') is the saved name of the report. The @Variable('DPNAME') returns the name of the data provider, as defined in the Query properties in the Web Intelligence Edit Query panel. In the screen shot below, I have renamed the default Query 1 to My Data Provider.

The @Variable('DPTYPE') describes the data provider type. I was unable to find an enumerated list in the documentation, but a standard universe on a relational database has an @Variable('DPTYPE')value of DPUNIVERS. I can only speculate that universes constructed from stored proceduresor OLAP cubes probably have different values.

The @Variable('UNVNAME')returns the name of the universe as defined on the Parameters tab of the Universe Properties. I lamented that XI R2did not have a variable (at least not documented) to identify the universe, soits a welcome addition. In my example, the name of the universe is Dashboard.

The @Variable('UNVID')is a new variable in XI 3.1. It returns the ID of the universe object, which is listed next to the CUID in the CMC. The universe in this example has an ID of 1303.

Beginning with XI 3.1 SP2, universe designers can use two new locale variables.@Variable('PREFERRED_VIEWING_LOCALE')is the users Preferred Viewing Locale, the locale chosen by the user to display metadata and data in his reporting tool.@Variable('DOMINANT_PREFERRED_VIEWING_LOCALE') can be used to categorize or roll up preferred viewing locales.

SAP BusinessObjectsBusiness Intelligence 4.0 supports the followingXI 3.1 @Variables: BOUSER, DBUSER, DOCNAME, DOMINANT_PREFERRED_VIEWING_LOCALE, DPNAME, DPTYPE, PREFERRED_VIEWING_LOCALE, UNVNAME, and UNVID. BI 4.0 also adds a new variable DOCIDand CMC-defined user attributes. The @Variable functions can be used in classic UNV universes created by the Universe Design Tool (formerly Designer) or the Information Design Tool. These functions are documented in theSAP BusinessObjects Business Intelligence 4.0 Information Design Tool User Guide on the SAP Help Portal.

The last item Id like to bring up isnt a universe-level @Variable, but a new Web Intelligence function that has been sorely missed and a welcome addition to XI 3.x. The ReportName() function returns the name of the current report tab in the Web Intelligence document. Ive often wanted to use the name on the report tab in the report title and now I can. SAP liked this new function so much that it is used for the default report title cell in Web Intelligence 4.0.

@Variables have many applications and I hope this article will help you take advantage of them in your universes.

Condition (Pre-Defined filter) in BO Universe designerOverview:

It is a best practice to create pre-defined filters (known as conditions) to help end business users to define the required filters in their analysis and reports. for example if we have the following account statuses:

N: Normal

D: Dormant

I: In Active

C: Closed

Assume that there is business rule that state the following: active accounts are the accounts which is normal or dormant.

The best practice is to create a pre-defined filter (Active accounts) which will filter only normal and dormant accounts as per the definition. this filter will be available in the business model and the end user can easily select this filter in his/her report or analysis to narrow the report results to only active accounts.

As a best practice, you should define all your business rules during business requirements gathering session. then you need you data analyst to translate it in a technical IT form (usually SQL condition). Then you need to create the corresponding conditions (Pre-defined filters) in the business model at BO universe designer.

How to create a condition (pre-defined filter):

First you need to switch to condition list, then navigate to the folder that you want to create your condition in. this folder should some how related to your condition. for example if you have a product class (folder) and you want to create a condition to filter on electronic products like TVs, Radiosetc. then the product folder is the best place to create that condition. click on the condition icon (yellow cone) and then follow the steps in the following section to define your condition

what you need to define you condition (pre-defined filter):

Condition Name: this name should be descriptive and in business terms. For the earlier active account example. we named our filter active account because this describe the business rule clearly.

Condition description: You should write a description here about this filter, when to use it. what you expect when you use it.

Condition where: this should contains the technical SQL statement generated by the data analysis for the business rules. you can use the formula editor for more complex conditions.

Formula Editor:

Mandatory filters:

You can site your condition to be used as a mandatory filter in your universe or class by ticking the following option while creating your condition:

Use filter as mandatory in query:Apply on universe: filter will be applied on every query generated using this universe.apply on class: filter will be applied if any object used from the current class.apply on list of values: filter will be applied on all LOV (list of values) generated for each object inside this class (folder). Please note that this option available only after you select apply on class

Types of conditions:

filters: it doesnt need any input from the user. it will apply the criteria impeded inside this condition when dragged to the query filter.

Prompt: It will ask the end user for his input to apply the filet.

Q. Effect of cardinalities

The cardinality of a join does not have a role in the SQL generated when you run a query. However, Designer uses cardinalities to determine contexts and valid query paths.

A context is a collection of joins which provide a valid query path. You use contexts to resolve join problems that can return too many or too few rows because of the way that tables are linked in the target database. Contexts affect the SQL generated for a query as they either direct the end user to take a particular join path, or solve a join path problem:

"You need to verify that cardinalities are correctly set for all joins in your schema to ensure that you have the correct contexts, and that you have valid join paths."

Setting cardinalities can also help you understand how tables are related in the database, and to graphically identify potential join path problems in your schema.

he main impact is that you will not be able to use the detect context functionality.

There are other minor points, but that is the most important. It will not affect the way that queries are generate

Personally, I see absolutely no reason for not setting cardinalities. Like adding object descriptions, it's another step closer to a properly-constructed universe that you'd be happy to inherit.

Every thing works fine as it is with or without cardinalities.

Defining cardinalities will give you lot of advantages:

1. Automatic context detection

2. Avoiding warning messages during Integrity check

3. Confusion to new users viewing or modifiing the universe

So its always best practice to define cardinalities. Other than that every thing works fine.

Q. Types of Joins in Business Objects Universe

Following join types are available in Business Objects Universe Designer which can be used to join two tables.

Equi-Join

Equi-join is join which uses = equal operator to join two tables. Generally equi join is used to join primary table using primary key with foreign tale using foreign key

When two tables are used using equi-join it returns all those rows from selected table which matches the equality condition.

Outer Join

Outer join links two tables using a join operator. When tables are linked using outer joins the select query returns all the records which matches the join condition and returns all the records from one table even though do not match the join condition.

There are two types of outer join

Left Outer join: This outer join returns all the records from left table even when they do match the join condition.

Right Outer join: This outer join returns all the records from right table even when they do match the join condition.

You should avoid using outer joins as it may cause query to run slower. Outer joins should be placed at the end of a join path otherwise it maybe causes other queries to match a NULL equality condition which might give an error.

Theta Join

A theta join is a between-type join thats joins tables based on a relationship other than between two columns. It is generally used to demonstrate ranges. A theta join can use any operator other than equality operator.

Lets see how to create a theta join

1. From Insert menu click on join to create a new join

2. Select the table1 which should be joined to another table using between operator.

3. Select the table2

4. Now select the two columns from table two which should represent the range.

5. Set the cardinality to N-1

6. Click Ok

This theta joins uses between operators to join two tables

Shortcut Join

A shortcut join is a join which provides shorter way to join two tables by avoiding intermediate tables between join paths of tables. It is very helpful to improve the performance of a query as it reduces number of joins in a query.

Shortcut joins are also useful to solve loops in a Universe.

Lets take an example of Shortcut join.

Shop_facts, Article_lookup and product promotion facts are joined through Article id. Now if we want to see Duration and amount sold the query will have un-necessary join of shop_fact and Article_lookup table as there is no join between shop_facts and product_promotion_fact.

However if we join shop_facts and product_promotion_fact, it will create a circular loop which might confuse universe to decide on which join path to take. This can be avoided by using shortcut join instead of using normal join. Shortcut join is represented by dotted line in designer.

Self Restricting Join

Self restricting join is not actually a join but a restriction on a table. Generally it is used to restrict the data returned by a table.

To create a self restricting join

1. Click on Insert menu and click on join to create new join

2. Select the table on which you want to create self restricting join.

3. Select the same table name from table 2 combo box also.

4. Select the column which should be used for self-restricting join.

5. Edit the expression and put the restriction condition

6. Click OK.

Cardinality of self restricting join should be set to 1:1 otherwise it gives error while detecting contexts.

Try to create each type of join in BO universe and practice it and test it using Query Panel.