Best Practices For Universe and Webi

Business Objects - Guidelines and Best Practices

Before designing and develop the universe and reports, there would be little things to remember that can help to design which in long terms helps for ease of maintenance, readability and helps to avoid rework for simple mistakes.

Universe Design: Guidelines & Best Practices

Introduction        
Gives the basic guidelines/practices that could be followed in any Universe Design

Connection
--> when using a repository, always define a SECURED Connection to the Database.
--> Use the Universe Property panel to define the Universe Use and Version (last update).
--> Define the Connection Name that helps for Easy Database Identification.
--> Parameters - SQL Tab - Multiple SQL statements for each measure to be unchecked.
--> Parameters - SQL Tab - Cartesian Products - Prevent is checked.

Class
--> Define Universe Classes / Subclasses as per the business logic & Naming Convention.
--> Involve the business users in defining the classes hierarchy and business names for the classes and objects.
--> AVOID Auto Class generation in the Designer.
--> Give description for the use of each Class/Subclass.
--> Avoid deep level of subclasses as it reduces the navigability and usability.

Objects
--> Object to be used in calculation HAS to be Measure Objects.
--> Object to be used in Analysis HAS to be Dimension Objects.
--> Give description for the use of each Object.
--> Include an (E.g.) In the description for Objects used in LOV.
--> Do not set LOV Option for each Dimension. Use it only for required Objects, esp. those to be used in Report Prompts.
--> Keep "Automatic Refresh before Use" option clicked for LOV Objects:
--> If LOV is editable by the user, provide a significant name to List Name under object properties.
--> All the measure objects should use aggregate functions. This will ensure that the aggregation happens at the database for the selected dimensions.
--> Avoid having duplicate Object names (in different classes).
--> Format for objects of type Numeric, Currency & Date should be defined.

Predefined Conditions
--> Give description for the use of each pre-defined condition.
--> If Condition is resulting in a prompt, make sure associated Dimension Object has LOV.
--> Time dimension related predefined conditions such as Current year, Current month, Previous year, Last (x) weeks, etc. can be defined to make it easy for scheduling daily/weekly/period based reports.

Tables
--> Alias Tables should be named with proper functional use.
--> Arrange the tables in the Structure as per Business/Functional logic. This helps other Universe users in understanding.
--> It is always best to bring the tables without joins and build them manually. It helps the designer to understand the intricacies of the model.

Joins & Context
--> AVOID keeping hanging (not joined) tables in the structure.
--> AVOID having joins that are not part of any context.
--> Give proper functional naming to the context for easy identification.
--> AVOID having 1:1 joins.

Import/Export
--> Make sure of the path for Import, which usually is always in the Business Objects' Universe folder.
--> LOCK the universe if Administrator/Designer does not want any user to Import/Export.
--> DO "Integrity Check" before Exporting the Universe.

Report Design: Guidelines & Best Practices

Introduction
Gives the basic guidelines/practices that could be followed in any Report Design.

General
--> Give meaningful names for the report tabs --> For complex reports, keep an overview report tab explaining the report --> Use the Report properties to give more information about the report

Data providers
--> Each Data provider should be given a name that reflects the usage of the data its going to fetch.
--> Select Objects in such a fashion that the resulting SQL gives a hierarchical order of Tables. This helps to achieve SQL Optimization.
--> Avoid bringing lot of data into the report which will unnecessarily slow down the report performance.

Report Variables
--> Follow the naming convention of "var_" as prefix to each report level variable. This helps to identify Report Variables different from Universe Objects.
--> Each variable that carries a calculation involving division should have IF <Denominator> <> 0 THEN <Object>. This avoids display of #DIV/0 errors in the report.
--> Avoid having deep nested calculations which will slow down the performance of the report.

Report Structure
--> Make use of Report Templates when having most of the report with similar structures. This makes the work to move faster and consistent across.

Report Formats
--> All the reports should have page layout set in a printable manner. (Landscape/Portrait, Fit in 1 page wide or/and 1 page tall are different options).
--> All the reports should have page numbers in the footer.
--> All the reports should have Last Refreshed Timestamp in the header or footer.
--> All the above can be standardized by using templates

Report CELL Formats
--> All Numeric should be given Number format as per the language Eg. For German #.##00 for English #,##00.
--> Number cells should have a Right Alignment while Text cells should have Left Alignment.
--> Cell showing Percentage should carry the % text (either Column Header or in each cell).
--> Indenting should ALWAYS be done using the Indenting Tool and NOT by using " ".