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.