I have also been mucking around with Xcelsius for a parkrun project, more on that later.
To keep an eye on my progress I have built a dashboard to track my running over the current year and so I can visually compare my training year on year.

photo credit: eshm

13.2
You agree that during the course of this contract and after the termination of the contract for whatever reason without limit in point in time you will keep in confidence and shall not disclose to any person unless authorised to do so with the prior written consent of the Company the following:-
13.2.1 Any consultancy know-how, methods, tools, techniques or intellectual capital.

I realised that some of my blog entries or tweets could fall foul of this clause so I asked for written permission to continue blogging generic “work related” content such as Business Intelligence, Data Warehousing, Data Modelling and Business Objects.
Rather than granting this and leveraging the fairly good google rankings that my posts seem to get I was asked to remove all work related posts.
Business Objects Best Practice (higher ranking than BusinessObjects.com)
Business Objects New Features (Page One)
Dimensional Modelling (Ralph Kimball ?)
As such I have password protected all of my work related posts.
If you are struggling to find content there are a variety of searches that could turn up interesting content.
Alternatively you can go to my company site, contact details can be found here or here.

This post is password protected. To view it please enter your password below:

Password:

The purpose of this document is to provide a description of what I consider to be best practice when designing a Business Objects Universe. We will also describe the reasoning behind the suggestion.

1 Connectivity

This section will describe any items around the connection between Business Objects and the underlying database that holds the data.

Native Connectivity

Always use the vendor’s native connectivity where possible. Avoid using generic drivers, e.g. ODBC for Oracle. You always get better performance and more parameters when using the vendors own drivers.

Avoid ODBC

When accessing Microsoft SQL Server databases use an OLDDB connection rather than an ODBC connection. The connection is faster. OLEDB connections store their parameters in the connection definition it’s self whereas an ODBC connection refers to a predefined ODBC connection name which must be defined on every PC and server.

Keep Connections Open

It is possible to define if the database connection is kept open permanently, closed after a specified period of inactivity or closed after each query. The process of creating a database connection is quite “expensive” time wise so it is better to keep connections open for longer. Open connections consume resources on the database server so it is better to keep the number of connections to a minimum.
Generally, connections to the Business Objects repository database should be kept open permanently. Connections to data source databases should generally time out but this is dependant on the typical users usage profile.

Tuning Network Connections

It is possible to fine tune the way that Business Objects uses the network by changing network packet sizes etc. This can make a large difference to problem reports that return a large volume of data.

2 Physical Structure

This section will describe any practices that should be adhered to when implementing the physical data structures into the Business Objects universe.

Alias All Tables

When importing the database tables, immediately create an aliased version. The aliased versions should be the ones that are joined and are used to build objects from. This is done purely to make the generated SQL and the universe it’s self easier to read.

Join All Tables

Every table that will be being used to supply information should be joined to at least one other table. It should not be possible to create a Cartesian product

Index Joins

Ensure that all joins that are implemented in the universe have a corresponding index on the physical table. Queries that join tables together will almost always run faster when the joining fields are indexed.

Count Rows

There is the facility to get designer to count the number of rows in each table. This should always be done and the results displayed in the universe. There are two reasons for this: if data is missing from a particular table it is easier to spot, if you are using Designers built in validation tools it needs the row counts to check the cardinality of the joins.

3 Business Structure

This section will describe any practices that should be adhered to when implementing the logical classes and objectsinto the Business Objects universe.

Classes

Each class should be uniquely named and have an appropriate business description.

Objects

Every object should be uniquely named and have an appropriate business description. If you find you have two versions of the “same” object, for example “Year” you should find out when you would use each and then name them appropriately.

Conditions

You should implement as many condition objects as you can. It should be the exception that users have to manually build a condition. Conditions should come in two flavours. Interactive filters will use the prompt feature to as the user to enter information, for example “Which years?”. Static filters will apply a restriction without any visible interaction, for example “This Year Only”.

Automation

If you intend to schedule reports then you should ensure that any conditions you do use are not interactive. For example; if you were to add the condition “Year=2007” or “Which Years?”, the value that is hard coded or the value that is supplied at schedule time would be used for every subsequent run, even when the calendar year does change.

Core Definitions

If you find you need to define the same object in multiple places or you have an object that extends the definition of an existing object, you should not redefine the logic of the core object every time it is used. For example MyCustomers = case ownerID when 1234 then customerID end. If I then wanted a MyGoodCustomers object I should not redefine “My Customers” but reuse the definition already in place. This is done via the @Select syntax. MyGoodCustomers=@Select(MyClass,MyCustomers) and > 1000000. This means that if the definition of MyCustomers ever changes it only needs to be changed in a single place.
In reality, I would store the value of 1000000 used above in an object again so that there is a single place where this is defined.

Hidden Objects

If you are using core definition objects, you may end up with objects that simply hold definitions but should not be used in their own right. These objects can be hidden. Hidden objects are still accessible to @Select calls but do not appear in the object list for users to select them.

Where Clauses

Every object has the ability to have a where clause added to it. This should never be used. If you add where clauses to objects then when you select multiple measures, these where clauses are combined. For example Sales2006 = select sum(sales) from sales where year=2006. Sales2007 = select sum(sales) from sales where year=2007. If I were to use both measures in the same query then the result would be: select sum(sales), sum(sales) from sales where year=2006 and year=2007. It is not possible for a single row to belong to both years so no data would be returned.
The “correct” way to implement this object would be Sales2007=select sum(case year when 2007 then sales else null) from sales.

4 Linked Universes

Linked universes are a great way to maintain different “versions” of the “same” universe. For example you may wish to have an exact copy of your live universe but point it at your training database. You will not want to maintain your training universe every time your production universe changes. Using the live universe as a kernel of the training universe and only changing the universe connection will allow this to happen automatically.

Parameters

Universe parameters are not automatically replicated between linked universes.

Contexts

When you create a linked universe the contexts contained in the core universe are not propagated into the linked universe. If you wish to have an “exact” copy then you must re-implement the contexts and also maintain them on an ongoing basis.

5 Parameters

This section will describe any parameters that can be applied to the universe that will have an affect.
This is an example where you may wish to have multiple versions of a universe, one for scheduling with no limits in place and one for novice users with very tight limits.

Limit Size Of Result Set

This option allows you to restrict the number of rows that a single query that a user runs will return. This is one of the features that will prevent ill thought out queries from saturating the network. The value used will be dependant on the number of rows that a “typical” report returns.

Limit Execution Time

This option allows you to set the maximum time in seconds that a users query will run for. This is one of the options that will prevent long running queries from consuming resources on both your database server and your Business intelligence server. The value of this will be dependant on the “typical” report execution time.

Warn If Cost Estimate Exceeds

When a user submits a query and this option is enabled and the underlying database supports the feature then you can warn users if the expected duration of their query exceeds a particular value. The value of this will be dependant on the “typical” report execution time.

Limit Size Of Long Objects

Databases have the option of holding large volumes of data in a single field. Each “long” field in each row can contain a maximum of 4GB of data. If all of this data was returned then this could easily saturate the network and the memory of the local PC. We would recommend that this value is kept quite low to limit the volume of data returned by this field. We would also question as to why long fields are included in the universe in the first place.

Allow Use Of Sub Queries

Sub queries are a way of restricting queries based on the results of others. This is not something that novice users would be using but it is an easy way to implement complex selection criteria.

Allow Use Of Union, Intersect and Minus Queries

These set based operators are easy ways to compare different result sets. We would recommend that this is enabled as other ways to answer the same questions are very complex.

Allow Complex Operands in Query Panel

Selecting this option gives you access to the full range of operands in the query panel. This should normally always be selected unless the universe is targeted at novice users.

Multiple SQL Statements for each Context

If you write a query that requires to access multiple contexts, this parameter specifies that a separate SQL statement should be used for each context. This should normally be enabled if your universe contains contexts.

Multiple SQL Statements for each Measure

When using a relational data source certain structural conditions can exist; chasm and fan traps. One way to resolve these is to tell Business Objects to write a separate SQL statement for each table that is providing a measure. This should normally be selected when using relational data sources.

Allow Selection of Multiple Contexts

Contexts are one way to prevent loops, chasm traps and fan traps. If this is the reason that you have created a context then this option should not be selected.

Cartesian Products (Warn / Prevent)

A Cartesian Product is when no join has been defined between two tables. In this circumstance every row of the first table will be joined to every row of the second table. The setting of this parameter is not relevant. Every table that is defined in the universe should be joined to at least one other.

Core Order Priority

If you are using linked universes then this should be set to YES in the derived universes. This forces the order of the classes and objects to match the order as they are defined in the kernel universe.

6 Security

Depending on the nature of the data you may require to restrict access to the information held in the universe. There are two main methods of implementing this.

Database Security

This is the most secure method to implement security. Each Business Objects user requires a corresponding database login with matching usernames and passwords. The universe connection is then defined so that it uses the users credentials. The definition of the scope of the data that the user has access to is defined in the source database.
This is the preferred solution as it is a more generic solution. This means that even if the user chooses to use a differing query tool, the security cannot be bypassed.

Universe Security

This method involves using a generic logon to the database. The definition of the security roles are stored wither in the universe it’s self via object definitions or in database tables, which are included in the universe. This solution is good as it means that control of the security definition is either data driven or in the control of the Business objects universe designer. Using the previous method, the control of the security is the remit of the DBA. The disadvantage of this method is that if any other query tool is used then the data becomes unsecured. There si also the risk that the user will have the ability to rewrite the SQL that Business Objects produces prior to running the query, allowing them to remove or change the security implementation.

7 Summary

These are what I would consider to be the current best practices when designing business intelligence universes. As is always the case there are times when many of these can and should be ignored. This list should not be used dogmatically but pragmatically. If you are having any particular problems then a member of our Service Delivery team would be happy to work with you to resolve them.

Twitter

I have invested a lot of content to Twitter this year.
This is primarily due to the convenience of the platform racking up almost 1200 updates in the year here.

Flickr / Photography

I can’t find a way to get stats for the year so here are my top five photos:

Web Site / Blog

By far the most popular post on the site was the photos page here.
Second most popular page is the “About Me” page here.
As for the blog entries themselves they rank at:
1 – Business Objects XI 3.0 New Features – Conditional Prompts
2 – Crystal Xcelsius – Filtered Rows From A Filter Component
3 – Modelling Change In Your Dimensions
4 – Business Objects XI 3.0 New Features – Change Data Tracking
5 – Dimensional Modelling – Facts
As you can see here the site only really started getting traffic last January so that gives me 17300 page views.

Personal Stuff

Obviously the biggest news of the year was the passing of my daughter Emma.
Celebrating the Life of Emma Berry Goodman
And the year ends on another low point with the passing of another member of my extended family.
George Miller – Footballer | 1939 – 2008

=a2 & “-” & b2 & “-” & c2

I then build a filter component that looks at A2:D500 and tell it that I want three filters.
I tell it that the destination cell is on a separate sheet “Controls!A1″, I call this cell the “SelectedKey”
This gives me a component that allows me to select the unique combination of the three keys, Date, Product and Customer and record the selected value, but how do I then show the multiple rows that are associated with this SelectedKey?
Use a ComboBox component:
The labels come from the key column RawData!D2:D500
The Insertion Type is Filtered Rows.
The Source Data is RawData!D2:Z500
The Destination is a new sheet FilteredRows!D2:Z500
On the Behaviour tab set the selected item to reference Controls!A1 which stores the selected key.
When the filter component selection changes, the SelectedKey is updated, this changes the selected value in the Combo Box which filters the rows.
We don’t want the users to see the Combo Box so my preference is to create a panel container and put all of my “hidden” or “debugging” components in it. The panel container can then be hidden using the Dynamic Visibility setting.

In my example I wanted to filter multiple datasets using the same criteria so I simply added multiple Combo Box components, each with their own source and destination ranges but each referring to the same selected key field.
This was by far the easiest way to implement this.

I know that I should be using QAAWS or Live office and doing this all interactively, but for this customer they wanted to manipulate a static dataset.

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

I know that I covered this in my video post, but I hated the quality of the video, so here is a similar post with pictures (click on hem to see larger versions).

You no longer need to splash out on fancy dashboarding software (although Xcelsius is good !) to quickly highlight when your data is changing. A new feature in Business Objects Web Intelligence (WebI) 3.0 allows you to add this feature to any document.

Query

How do you set up your query to be able to track the changes in your data?

You don’t have to do anything, just create your query as you normally would.

Edit Report

This is where the magic happens! First of all you have to enable the track changes feature which is in the top right hand corner of the Edit Report window.

This gives you your first choice: Do you want to track changes between each refresh of your document or do you want to track changes from a fixed set of data?

For this demo I’m going to select Auto Update so that I can see the changes between each refresh. In order for track changes to work you need to have two datasets, so I’m going to select the “Refresh Now” option and select the year 2005.

As you can see my 2004 section has been struck through and the 2005 section has been shown in blue. This is because I completely changed my dataset. If I remove the year section and redo the change tracking you will see how track changes works better when you give some thought to your document design.

Now we can see, highlighted in green, all the values that have increased, highlighted in red the values that have decreased, and struck through and values that no longer exist. At a glance I am not worrying as on the whole I am selling more product that last year.

If you lose track of what you are comparing, it is listed at the bottom of the screen:

As you can see, this confirms the type of change tracking and the two refresh dates that are being compared. What I am not sure of is how to confirm the parameters that were used in each case.

If I then refresh the report again, this time for 2006:

Here we can see that we have (re)introduced some product lines and these are highlighted in blue.

I need to print this report out and the red and green are unreadable on my cheap black and white printer, what can I do? There is a “Hide Changes” button, the middle of these three:

Clicking this hides the highlighting of the changed data. The data it’s self is still kept.

Clicking the button again will re-display the colour highlights. Compare this with clicking the leftmost button “Deactivate Data Tracking”, this discards the “previous” version of the data and disables the highlighting facility.

The rightmost button; “Data Tracking Options” gives you access to change the formatting of the data changes. You may need to do this as increased values may not always be good (Green).

From this same window you can use the “Reference Data” tab to change back to a fixed data set for your baseline comparison if you wish.

This is obviously no replacement for a fully featured dashboarding product such as Xcelsius but it is “easier” to use than the Alerting feature that we are used to use within reports.

I’m going to start a small series of posts showing you what’s new in Business Objects XI 3.0

I’m starting off small; with Conditional Prompts.

The Problem

Just to clarify. A conditional prompt is a question that is placed in the query that allows you to fine tune the results that you return from your database. The problem is; sometimes you want to see “some” of the data, other times you want to see it all. This is fine if you are a report developer as you can edit the query to add or remove the prompt. If you are a report consumer then you are stuck with the query as it has been developed.

When you use a prompt object it will ask you “Enter value(s) for Year:” for example and then allow you to select one or more years. If you want to see all years, then you have to select every value from the list. This is fine for years as there are not so many of them. When you have “lots” of values this becomes a pain to select, you might miss one, your query becomes “ugly” as it has all of the selected values embedded within the SQL and some databases actually put a limit on the number of values that you can pass in this manner.

The “Old” Solution

Using versions prior to XI 3.0 the way that you got around this problem was to manually edit your condition objects. Rather than having a “simple” condition:

Dates.Year in @Prompt('Enter value(s) for Year:')

You would manually edit this to become:

(Dates.Year in @Prompt('Enter value(s) for Year:')
or
'All' = @Prompt('Enter value(s) for Year:'))

This works because if the user types in ‘All’ then ‘All’ = ‘All’ would be true for every row, so you get all of your data.

The problem with this method is that the user has to type in ‘All’, most users prefer to use a list of values (LoV) to select the values you want. You then have to manually edit the SQL that populates the LoV values to be something along the lines of:

select distinct year from dates union select 'All' from dual;

Again, this works but is more manual editing. This then has to be done on every object that you think that you will need this feature on.

The XI 3.0 Way

As of XI 3.0 there is a much more elegant (less labour intensive) way to do the same thing.

When you are building your query and you create a query filter you will see a new option denoted by the question mark icon to the right of the prompt text.

(by clicking on any of these images you will see a larger version)

Clicking this icon opens the prompt properties dialog box.

Here I have ticked the “Optional prompt” box to tell XI that I may not always want to supply values.

When I now refresh my query it asks me for the values I wish to associate with the prompt. Note the new text “(optional) If no value is selected, this filter will be removed.”

For the moment I’m going to select a single year, 2004.

When I run my report, you can see that only a single years data has been returned as requested. I have altered my report to also display the SQL used and notice how there is a “where” clause to restrict the year to a single value.

If I now re run the report but do NOT supply a year:

The report runs and shows me all years:

However, notice that this time there is no where clause to restrict the data.

Summary

Whilst this may not be the most earth shattering piece of new functionality, it is on that I think will speed up the report development process as it removes a lot of the simple but mundane tasks that a Designer had to do. It also results in much more efficient queries being sent to the database so the users should get their results just a little bit faster.