40
Business Objects Best Practices and Lessons Learnt V1.0

Business Objects Best Practices and Lessons Learnt

  • Upload
    sanj80

  • View
    52

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Business Objects Best Practices and Lessons Learnt

Business Objects Best Practices and Lessons Learnt

V1.0

Page 2: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

DOCUMENT REVISION LIST

Client:

Project:

Document Name: Business Objects Universe Design Best practices

Release Notice Reference (for release):

Rev. No.

Revision Date

Revision Description

Page No.

Prev Page No.

Action Taken

Addenda/New Page

Release Notice Reference

Page 2 of 34

Page 3: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Table of Contents

1 Universe Design Best Practices....................................................................................................5

1.1 Introduction.................................................................................................................................. 5

1.2 Universe Design and Development.........................................................................................5

1.3 Universe Design.......................................................................................................................... 5

1.4 General Universe Development Best Practices.....................................................................6

1.5 Some Real time Best Practices Solutions...............................................................................8

1.5.1 Define default value ‘ALL’ for prompts.............................................................81.5.2 Universe Documentation................................................................................11

References.............................................................................................................................................. 12

2 Business Objects Report Development Best Practices...........................................................13

2.1 Introduction................................................................................................................................ 13

2.2 Desktop Intelligence Documents............................................................................................13

2.3 WebIntelligence Documents...................................................................................................14

2.4 Some real time Best Practices Solutions..............................................................................14

2.4.1 Methods to getting Desktop Intelligence data in Excel sheet..........................142.4.2 Incorporating an Image as a report object......................................................15

3 Business Objects Design and Development Lessons Learnt.................................................16

3.1 Introduction................................................................................................................................ 16

3.2 Lessons Learnt in Reporting....................................................................................................17

3.2.1 Chart...............................................................................................................173.2.2 Drill.................................................................................................................173.2.3 Data source....................................................................................................173.2.4 Report.............................................................................................................173.2.5 Formatting......................................................................................................173.2.6 Functions........................................................................................................173.2.7 Report layout and print...................................................................................183.2.8 Templates.......................................................................................................183.2.9 Scheduling......................................................................................................183.2.10 Report view....................................................................................................183.2.11 Universe Changes...........................................................................................183.2.12 Images............................................................................................................183.2.13 Hyperlinks.......................................................................................................18

3.3 Lessons Learnt in Universe Design........................................................................................19

3.3.1 Dynamic Prompts...........................................................................................193.3.2 Restoration of a Universe Deleted From CMS.................................................19

3.4 Lessons Learnt with Security Implementation.....................................................................19

3.4.1 Ensuring that client-server communication in BO is secured..........................19

4 Business Objects Installation, Configuration and Deployment Best Practices...................20

4.1 Introduction................................................................................................................................ 20

4.2 Back Up and Recovery Best Practices...................................................................................20

Page 3 of 34

Page 4: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

4.2.1 Back Up and Recovery Process Concept.........................................................204.2.2 The Importance of a Proper Back up Sequence..............................................204.2.3 Enterprise Content Back up compared to Server Back up..............................204.2.4 Incremental Back up compared to Full Back up..............................................214.2.5 Cold Back up compared to Warm Back up......................................................214.2.6 Business Objects Content to Back up.............................................................214.2.7 High-Level Sequence of Back up Events.........................................................234.2.8 High-Level Sequence of Recovery Events.......................................................23

References.............................................................................................................................................. 24

5 Business Objects Performance Optimization Best Practices.................................................25

5.1 Introduction................................................................................................................................ 25

5.2 Optimizing Document Design.................................................................................................25

5.2.1 Desktop Intelligence Documents....................................................................255.2.2 WebIntelligence Documents...........................................................................26

5.3 Improving Overall Document Computation Time................................................................27

5.4 Network and System Configuration.......................................................................................28

5.5 General Server Tuning.............................................................................................................29

5.6 Web Servers............................................................................................................................... 29

5.7 Configuring the Cluster Modules............................................................................................30

References.............................................................................................................................................. 30

Page 4 of 34

Page 5: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

1 Universe Design Best Practices

1.1 Introduction

This document serves to illustrate the best practices that could be kept in mind while creating new or modifying existing BusinessObjects universes.

BusinessObjects development is centered on the development of universes. A universe is a business-oriented mapping of the data structure found in databases: tables, columns, joins, etc. It can represent any specific application, system, or group of users. In the BusinessObjects end user modules (this includes WebIntelligence), universes enable end users to build queries from which they can generate reports and perform analysis.

A few real time best practices solutions are also incorporated.

1.2 Universe Design and Development

The following is a general workflow for universe design:

Identify reporting requirements. Identify the database schema relevant to the universe you are creating. Identify the primary and foreign keys of that schema. Ensure there is representative data in that schema. Ensure that the data and structure of that schema is stable and not likely to change

dramatically during development without warning. Insert universe tables one at a time, not in bulk, understanding how each table relates to

rest of the universe. Insert joins based on primary and foreign keys. Decide on cardinalities of joins. Specify cardinalities manually as opposed to using the

Detect Cardinalities feature in Designer, because this feature relies on the structure and content of the database. Knowledge of primary and foreign keys will assist in cardinality decision.

Build relevant objects. Test the universe by building queries in Desktop Intelligence Add any other elements to universe such as predefined conditions, hierarchies

1.3 Universe Design

Follow the general workflow and the following tips to design an effective universe that meets end users’ needs:

Involve users at every step of the universe design and production process, especially in naming objects (this ensures the terminology is correct). During the Build phase, use the iterative process known as Rapid Application Development (RAD), which uses a group of pilot users to test the universes, provide feedback, test modifications, provide feedback, etc. This feedback loop is critical and will result in a more effective universe that will ultimately facilitate ad-hoc queries.

Keep the universe business-focused, for example when naming objects and classes.

Page 5 of 34

Page 6: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Build universes by referring to existing company documents. Build universes by starting with user requirements. Specify standards for: Universe names: always carefully choose the universe name, as renaming a

production universe is not recommended. If you change a universe name, you will have to re-point all documents created in that universe to the new name.

Object definition guidelines Simple object names Complex object names Aggregate object names Class names Alias names Help text

1.4 General Universe Development Best Practices

Take user requirements at face value, remaining in business terms. Basic rules of thumb:

Do not normalize. Database designers apply a series of rules to eliminate redundancy of information in a database, i.e. having the same piece of data stored in more than one place. Use Multi-Dimensional Modeling instead.

When several developers are working on one universe, remember that the Lock universes on import feature will only prevent people from exporting over the universe in the repository. This feature will not prevent someone from importing the universe and making changes, although they will not be able to export those changes back to the repository until the lock has been removed. Therefore if several developers have the ability to import and export the same universe, coordinate their efforts to avoid development on a universe that is out of date.

Use the comments text box (File > Parameters > Summary > Comments) to record the status and changes of a universe for other developers. This text is only visible in DESIGNER, whereas the description text (shown on the Definition tab) is visible to end users when they select an available universe. Use this latter description to represent a business description of the universe's purpose.

Always define cardinality, even for self joins, to avoid cardinality warning messages. Lay out your structure window with cardinalities facing the same direction. This helps

you identify and visualize the contexts. Use the Tools > Detect Contexts feature of Designer to manage your contexts. Always arrange tables logically in the structure window. Always detect loops and contexts. Always check integrity. If the universe is bigger than 1MB, divide it into multiple universes. When you select

File > Open, you load the universe into RAM. For example, if the universe is 1.39 MB, then it uses 1.5MB RAM. This could have had an impact on the RAM available to your system.

Use aggregate awareness, which speeds up query time by using special tables containing pre-calculated data. Do all aggregations on the server side instead of in the document (this can result in huge saving of time).

Define aggregate SQL functions on universe measures. Fewer rows will be returned from the database thus making reports smaller and the calculation of their variables, ranks and alerters quicker.

Remove unnecessary lists of values, such as on dates and measure objects. Base lists of values on lookup tables.

Page 6 of 34

Page 7: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

After the Build Phase, ensure an adequate Quality Control phase to verify the universes for technical accuracy (adherence to standards, review of object definitions for syntactic accuracy, validation of joins).

In Designer, under File > Parameters > SQL, set the following parameters: Set Cartesian products to Prevent. Universes should not allow Cartesian Products

since they are a symptom of incomplete joins and will affect performance and accuracy of query results.

Select the multiple path options as shown below. Multiple SQL statements for each measure can negatively impact performance, although you may choose to enable this option during development since it may solve some fan trap situations.

Page 7 of 34

Page 8: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

1.5 Some Real time Best Practices Solutions

1.5.1Define default value ‘ALL’ for prompts

Problem:

For every BO report with Prompts and LOV, one of the most expecting requirements from the users is the ability to select a default value for Prompts, which will bring all the records without restriction of the prompt value. For ex: In Prompt for selecting particular country, sometimes they need to view the result for ALL country. Since BO definitely needs any text as input for prompt, so we need to substitute any default text like ALL

Solution

We have to edit the LOV object and make one UNION with the new default ALL object and also define prompt accordingly. Just by selecting the string (ALL) as a default value for the prompt, will generate the report without any restriction by the prompt value.

Implementing method:

Below are the steps to include (ALL) in the list of values for an object “Error code”, such that final LOV for error code will have the (ALL) text also.

Step 1: Create one object as below: Object name- LOV with ALL option Select clause- <ALL>Associate any table -

Click the icon “Tables” to associate any table to this object It is better to define the object on any reference table to obtain good performance.

(Make sure that the reference table should have at least one record at any point of time, so that it will result (ALL) for UNION in LOV object)See the below Screenshots for reference

Page 8 of 34

Page 9: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Sample tables

Page 9 of 34

Page 10: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Step 2:Select the object (for e.g.: Error code) we need to provide as LOV Go to object properties-EDIT

Now if you see the Error code object in the SQL window, the SQL will be as belowSELECT DISTINCTref_customer_score_errors.ERROR_CDFROMref_customer_score_errors

Step3:Click the UNION icon (Combine Queries) in SQL window and choose the new object ‘LOV with ALL option ' in second part of UNION

Now your SQL will be as shown below: SELECT DISTINCTref_customer_score_errors.ERROR_CDFROMref_customer_score_errorsUNION SELECT DISTINCT '(ALL)'FROMref_customer_score_error_log

This SQL will give us the LOV with ALL, while clicking the values button during refreshing the report having prompts.

Page 10 of 34

Page 11: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Step4:Create one condition object having prompt for Error code as: ref_customer_score_errors.ERROR_CD = @ Prompt (‘Enter the Error code [or (ALL) for default]’,’A’, ‘Error code’,MONO,FREE)OR‘(ALL)’ = @ Prompt (‘Enter the Error code [or (ALL) for default]’,’A’,’error code’, MONO, FREE)

Advantages 1) We can achieve the result for all relevant inputs2) In order to change anything in the LOV or removing the database prefix we can do it in a single object 3) Easy to maintain the LOV for larger numbers of objects.

Note: The default value can be any text i.e. ALL, (ALL) etc such that the prompt should also changed accordingly. The reason behind the usage of ‘(‘ as suffix and prefix for ALL is , while listing in LOV, (ALL) will be listed first in order. such that it’s easy to choose

1.5.2Universe Documentation

Problem: Documenting the Universe details in text format.

In Earlier version of Business objects saving the Universe in text format is not possible directly. So it’s very difficult to document universe in object by object level. Since we used to manually copy and paste each object's Description, SQL, Joins, Conditions etc., from Universe to excel sheet

Solution

Here comes a report, which can be used to simplify your task for creating the 'Universe/report handover document'. Now this report can be used to extract them directly from the repository.

Detach the following universe to c:\Program Files\BO51\BusinessObjects 5.0\Universe ( or your default universe location)

Open it in the Designer and change the Owner name of all the tables to you repository name

Create the report in BO with required information and refresh it. Assign the particular available Universe name in repository as filter. You are done. A report with all the required information like object definitions and conditions will be generated.

This is an ad hoc universe. You can generate different reports as per your need from this universe. This universe has every detail you would need from your universe for documentation. This will simplify loads of your documentation work.

Page 11 of 34

Page 12: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

References

Universe Design Guidelines Document

Page 12 of 34

Page 13: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

2 Business Objects Report Development Best Practices

2.1 Introduction

This document serves to illustrate the best practices that could be kept in mind while creating reports in either Desktop Intelligence or Web Intelligence reports.

A few real time best practices solutions are also incorporated.

2.2 Desktop Intelligence Documents

The following tips are specific to Desktop Intelligence documents:

When creating full-client Desktop Intelligence documents, reduce the number of calculations in a document to the required minimum (including the count calculation). Calculations (variables and formulas) created at the document level are performed upon the opening of the report by the BusinessObjects process (busobj on Windows and bolightsvr on UNIX). The more variables and formulas created at the document level, the heavier the load on system resources, and the greater the impact on performance when the report is opened or refreshed.

With Desktop Intelligence documents, have the first tab be cover sheet containing information about the document. This opens up very quickly even if the tabs have to be generated.

It’s better to create a single document with multiple report tabs rather than separate queries for separate documents, as this will result in more efficient processing for an On-Line Transaction Processing (OLTP) system.

You can create different Desktop Intelligence reports by adding more tabs that represent the data in numerous ways or use filters to display different values for a dimension for each report tab. This method works well with universes built on transaction databases where performance is an issue.

Limit data providers in the creation of a Desktop Intelligence documents. Each data provider requires a separate connection to the database. A busobj /bolightsvr process synchronizes all the data from each provider. The more data providers need be synchronized, the more machine resources are required by the busobj /bolightsvr to accomplish this task.

If you have multiple reports on separate report tabs and these reports draw their data from the same source, do not create a separate data provider for each report. Instead, create a “base” data provider that contains the data used by all the reports. Since Desktop Intelligence retrieves data for each data provider, it is more efficient to retrieve data once and distribute it to several reports than to retrieve the same data several times.

Example : Create reports showing revenue by country and resort, and revenue by country. In this example the Revenue and Country objects are common to both reports. Instead of creating a data provider for each report you create a data provider containing the Revenue, Country, and Resort objects and use these objects in both reports.

Page 13 of 34

Page 14: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

You can use the Query Panel to modify a data provider by selecting: Data > Edit Data Provider.

Create Summary / Detail documents in Desktop Intelligence using View > Outline. This allows you to fold and unfold the sections and/or data that correspond to a break in the current block.

Break up large Desktop Intelligence documents into separate report tabs, so that the PDF/HTML is only generated for the tabs that the user requests. Less data is therefore transferred to the client browser.

Choose the presentation format for Desktop Intelligence documents according to their intended distribution media.

2.3 WebIntelligence Documents

The following tips are specific to thin-client (Web Intelligence) documents:

Avoid calculating sums and percentages in Web Intelligence documents encompassing several thousand rows. The count calculation has a negative impact on performance on very long documents.

Avoid designing 600-page long Web Intelligence documents! This is a guideline, and not a concrete limit, but considers the impact on the server of processing such a document. Beyond the document processing stage, consider the load on your network as the client requests such a document. Consider the number of users that request this particular document. All of these performance factors contribute to the response time of large and complex documents. Large Web Intelligence documents have an especially negative impact in extranet and WAN deployments, which are network-bound. The smaller the web pages transferred to the client, the fewer clients response time is affected by the network.

Use drill functionality or the Web Intelligence hyperlink index for section navigating. When creating Web Intelligence documents, use the Row Count per Page option in

the Web Panel. This allows you to cut your document page by page. This may help some performance issues, as users will be able to see the first page of the document before the server can download the other pages.

2.4 Some real time Best Practices Solutions

2.4.1Methods to getting Desktop Intelligence data in Excel sheet

Problem: Before implementing BusinessObjects, most of the users are familiar with Microsoft Excel.So even though they can able to view or refresh the data using BusinessObjects, they like to have the same data in Excel for their familiar data manipulation.

Solution:Replicating the same formatting of BO to Excel is difficult in earlier version like 5.1, but now in the latest version there is an option to save directly as Excel .also there are different methods to do the same.

Methods of getting BusinessObjects data into Excel with pros and cons

1. In Desktop Intelligence: Edit-> Copy All: in Excel: Paste Special -> text Advantage: Retains sections, filters, groupings, formula/variable results Disadvantage: Colours are lost, no export of graphs

Page 14 of 34

Page 15: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

2. In Desktop Intelligence Data -> View Data -> Results tab: Export -> File Format: MS Excel Advantage: Directly creates an excel file, exports whole data cube Disadvantage: Loses all formatting and calculations

3. In Desktop Intelligence: Save As .txt; In Excel: Open created .txt file; Advantage: Retains formatting (sections, filters, groupings) and formula/variable results. Disadvantage: Loses colours and graphs, two-step procedure, need to re-do for each report in the Desktop Intelligence document

4. In Desktop Intelligence: Save as HTML; In Excel: Open created HTML file; Advantage: Only method that retains all formatting and calculations incl. graphs, saves all reports in the Desktop Intelligence document in one step; Disadvantage: Two-step procedure; creates the HTML files in a sub-folder structure

5. In Desktop Intelligence: Click exactly on border of a table -> Copy; in Excel: Paste; Outcome: Pastes static image file of that particular table into Excel / PowerPoint etc.

6. In Desktop Intelligence: Edit -> Copy All; In Excel: Paste Special ->Picture (Enhanced Metafile). Outcome: Copies the whole report as picture into Excel / PowerPoint etc.

7. In Desktop Intelligence: Use the available Desktop Intelligence _VBA methods DP.ConvertTo() or Report.ExportAs() - for Advanced Users

8. Use the 'Copy to DDE' option (Data-> View Data -> results Tab -> Export; in Excel: Paste Special -> Paste Link)) to dynamically update the data cube results in Excel

9. Embed a Desktop Intelligence report by calling it in Excel via Insert-> Object -> Create from File (Mark Option 'Link to file'); ( Disadvantage: not very reliable).

2.4.2 Incorporating an Image as a report object

Problem:

Corporate Logo is not appearing in Desktop Intelligence report while accessing from remote locationA report will mostly have the respective corporate logo in header, after exporting to repository and then while viewed by various users, it’s not visible to them, that is because the image file is missing in the local system /server. so that image file also need to be exported to the server , so that anybody who is having access to server can able to view the corporate logo in business objects report.There is another best way to do this

Solution:

Normal procedure to include a picture was Insert->Picture then drag the pointer in report followed by selecting the required picture available in a particular location/path.

The most effective way to include corporate logo is Open the Corporate logo in MS-Paint Select All by pressing Ctrl + A and copy In Desktop Intelligence report insert a free standing cell and paste the picture

Page 15 of 34

Page 16: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Advantages

The Logo/Picture can be viewed anywhere by any user in remote location without having the image file in Server /local system

Page 16 of 34

Page 17: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

3 Business Objects Design and Development Lessons Learnt

3.1 Introduction

The purpose of this document is to share the experience, mainly the challenges in developing a reporting solution using WebIntelligence 6.5. WebI, in its new, enhanced version 6.5, is definitely more than WebI 2.x. This document is more of a review of this product in comparison with its thick client equivalent. Some points listed here might be well known to the developers. But many of them, one would come to know, only when involved in a development project.

Page 17 of 34

Page 18: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

3.2 Lessons Learnt in Reporting

3.2.1Chart

3D chart option is very poor, and cannot be used for any business need.Size of the chart cannot be auto fitFilters can be applied only for dimensions and not for metrics. Hence filtering the zero

values in a chart/table is not possible unless it is done at query level.

3.2.2Drill

Synchronized drilling across multiple blocks in the same report requires “Option->View->Drill Options-> Synchronize drill on report blocks” to be checked. If the same data provider is used for multiple reports in the same tab of the document, synchronized drilling is possible. Synchronized drilling is not possible in full client.

If columns are added in drill mode, they disappear when the drill is removed. If drill is enabled again, the columns won’t reappear. So all changes in the report blocks must be done with drill off’.

Column headers won’t change with the drill level. Post fetch drill cannot be stopped if users drill further below / above the level set in scope of

analysis.

3.2.3Data source

WebI requires the data source to be a universe. Unlike Full client, it cannot use data from personal data files.

Queries cannot be synchronized i.e. Linking feature is not availableQueries cannot be overridden.Where condition cannot use an object as the Right Hand Side operand.Set operations cannot be performed between two queries.Source universe cannot be changed in the same way as that of Full client, i.e., if you change

the universe name, the report will be irrecoverably lost as there is not a way to change the universe name in the report manually. Or we can say, a report pointing to universe ‘X’ cannot be pointed to universe ‘Y’ as we do with full client reports.

3.2.4Report

Macros cannot be used

3.2.5Formatting

Copy between two tabs is not possibleFormatting changes should be done in “structure” mode (To obtain this mode click “view

structure” button in the tool bar.) In results mode any format change requires server-client interactions and consumes more time.

Custom sort is not possible If existing columns in a report have “auto fit” property, then a newly added column will

inherit the “auto fit” property. In WebI, the parameter delimiter for built in functions is “;”, whereas it is “,” in Full client.

3.2.6Functions

Page 18 of 34

Page 19: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Ranking is not possible. Workaround is to create rank objects in the universe and use in reports.

3.2.7Report layout and print

If the page lay out is set as landscape/portrait, it alters only the page view. When it goes to print, it requires us to manually set it in the printer properties to be landscape/portrait again.

3.2.8Templates

Report Templates cannot be used to develop reports. Workaround is to create a report with common standards and styles from the universe, which can be used as a base for creating reports further. This can be used only for reports developed using the same universe. (It would mean that for every universe, create one standard dummy report, which can be modified for actual development)

3.2.9Scheduling

As Macros cannot be used, it is not possible to archive reports with their title reflecting the reporting period. Reports can be scheduled with “non overwrite” mode, and be saved or sent to inbox. Users have to sort it by date to pick up archived reports of a specific period.

3.2.10 Report view

Draft mode to see the report without page breaks cannot handle very large reports running for several pages (though data decides the page limit, our experience is that cannot handle more than 100 pages. This may also depend on hardware capacity)

3.2.11 Universe Changes

Every time when a universe is changed, it may take a while to see the changes across multiple servers (propagation delay). Also the user has to log off from the current session and log back in to see the changes.

3.2.12 Images

Images can be a part of the report in Full client. But in WebI, we must place the image files in WebI server or any other server that can talk to WebI server to show them on reports (This might be required for displaying logo)

3.2.13 Hyperlinks

Hyperlinks are used to connect source (parent) reports to target (child) reports. For WebI to read the cell content as HTML, the “Read content as” checkbox under Report properties->cell properties->Display needs to be checked. Values alone can be passed as parameters to the target reports. The parent report cannot call the documents stored in personal docs, as they do not have document ids.

Page 19 of 34

Page 20: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

3.3 Lessons Learnt in Universe Design

3.3.1Dynamic Prompts

Dynamic Prompts are developed such that key word in prompt is ‘MaxDate’ and the maximum value will be taken from LOV. Hence while scheduling the report, every time Default value is ‘MaxDate’ but the value differs based on the refreshed LOV. This helps to get the refreshed report avoiding the user to refresh again hence reduces the number of hits to the database and thus performance increases.

3.3.2Restoration of a Universe Deleted From CMS

A newer version of a universe was accidentally overwritten by an older version in the CMS. So the same was later deleted from the CMS through the CMC. Because of this action the universe couldn’t be opened and all reports made using this universe couldn’t be run. So to counter this problem an empty universe was created with exactly the same name as that of the universe which was previously deleted and the same was exported. Then from CMC, in the list of universes, the physical path of the universe on the BO server was found. Following this path on server the existing .unv file was replaced with the latest version of .unv file.

So the lessons learnt from this were: Always lock a universe while importing. Never delete a universe directly from CMC. Always maintain a back up of .unv file while over writing it. Create a BIAR file of the universes & reports daily as a back up.

3.4 Lessons Learnt with Security Implementation

3.4.1Ensuring that client-server communication in BO is secured

Whenever a request from a client browser hits the BO server, the Web application server decodes the request and forwards it to appropriate BO service. This means in order to have secure communication; a security certificate needs to be embedded in the Web service so that it will be invoked every time a request hits the web server. This security certificate can be generated or imported from a trusted certification authority. To generate the certificate, we used the “keytool” utility provided with Java. This process creates a .keystore file (contains a certificate-key pair) which will be used for authentication. Next, we provided the path to this file in the Tomcat configuration properties (i.e. by editing the server.xml file). Once this is done & Tomcat restarts successfully, environment is secured i.e. all communications can be through “https” instead of “http”.

Page 20 of 34

Page 21: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

4 Business Objects Installation, Configuration and Deployment Best Practices

4.1 Introduction

The purpose of this document is to outline recommended best practices during the installation, configuration and deployment of Business Objects XI Release 2 server and/or desktop products.

Methods to back up and recover data for key BusinessObjects XI Release 2 system components are extensively illustrated. These procedures are used to reduce data loss, optimize data recovery, and minimize the delay before resumption of normal business operations.

4.2 Back Up and Recovery Best Practices

4.2.1Back Up and Recovery Process Concept

A back up and recovery plan consists of precautions to be taken in the event of a full system failure due to a natural disaster or a catastrophic event. The plan aims to minimize the effects of the disaster on the daily operations so that the organization is able to maintain or quickly resume mission-critical functions. It is recommended, as part of a BusinessObjects Enterprise disaster recovery plan, to involve an implementation of redundant servers in a back up system, which mirrors the primary system. In the event that the primary system goes down, the back up system is still available and becomes the operational system.It is a best practice to back up BusinessObjects servers on a daily basis.

4.2.2The Importance of a Proper Back up Sequence

Without backing up the Enterprise system databases and the file repository, no restoration of the environment is possible.Good back up integrity requires shutting down certain BusinessObjects services prior to capturing the back up. Under certain conditions, failure to follow a proper service shut down sequence before backing up could result in one or both of the following consequences:• False sense of security in the quality/integrity of the back up• Inability to fully recover BusinessObjects if the back up is of poor integrity

4.2.3Enterprise Content Back up compared to Server Back up

Enterprise content back up focuses on the essential components of Enterprise only. With an Enterprise content back up, one can recover a BusinessObjects environment from scratch on a different hardware environment if necessary.Enterprise content back up does not insure the operating system or any applications, including the Enterprise executables and DLLs; however, it does insure all of the intellectual content that is created and customized by users of the Enterprise system, and that is the most important thing. Content back up also will not insure one against corrupted or deleted Enterprise application DLLs/EXEs or other operating system problems, but these can be

Page 21 of 34

Page 22: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

resolved by performing a re-installation of operating systems or Enterprise. Enterprise content back ups are relatively fast and inexpensive to capture. This document mostly focuses on a Enterprise content back up strategy.A server back up is the deepest type of back up. Typically, this is a full back up that captures every byte on every local hard disk in a server. This type of back up insures the server’s operating system as well as any applications and data stored on the server’s local drives. It

is a valuable type of back up, but can also be slow and expensive to capture and later restore. A server back up should incorporate the same data as an Enterprise content back up.

4.2.4 Incremental Back up compared to Full Back up

A full back up captures every targeted byte. Full back ups are the safest and least complex type of back up to restore, but they are also the slowest and most expensive to capture and maintain. Where resources allow, Business Objects advises capturing full back ups once per week.An incremental back up begins as a full back up. Thereafter, upon each subsequent back up, only the files changed since the last back up are captured. Incremental back ups are faster and less expensive to capture, but they are less robust than full back ups. Because of this, incremental back ups are usually acceptable for daily back ups.

4.2.5Cold Back up compared to Warm Back up

Cold back ups are a best practice and by far the preferred type of back up to capture on a daily basis. The Central Management Server (CMS) service must be stopped before a true cold back up of the CMS system database and File Repository Server (FRS) can occur. Stopping the CMS will prevent users from accessing the Enterprise system, a factor which must be taken into consideration when scheduling cold back ups.To aid in stopping and restarting Enterprise XI services before and after a cold back up occurs, it is recommended that two scripts be used, one to stop the relevant services and the other to restart them. These scripts can be executed before and after the database back up process begins. The UNIX distribution of Enterprise includes the ccm.sh script to assist in the start, stop and restart process.A warm back up usually allows applications and users to continue to maintain connections to the database and Enterprise XI while the back up occurs. Because of this, a warm back up exposes the possibility that the CMS and Performance Management (PM) tables and FRS will be captured in a state of change; furthermore, the FRS, CMS and PM tables could be captured in an out-of-sync state, a situation which compromises the integrity and usefulness of the back up.It is recommended to back up the CMS system database and PM repository once daily with incremental back ups and a full back up only once per week. The frequency of back ups may be revised based on an acceptable amount of time for recovery to satisfy your company’s requirement.

4.2.6Business Objects Content to Back up

There are several content-oriented elements that must be backed up daily in order to recover from a disaster. Routinely backing up all of the following content elements will enable you to recover from virtually any type of disaster (virus, hardware failure, natural disaster, and so on).

Page 22 of 34

Page 23: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

4.2.6.1 Database Back up

Central Management Server System Tables

This database contains all the user rights and metadata information about reports and universes, as well as the data connection information. Because the CMS database is the heart of the environment, it is absolutely critical to frequently back up this database. Without this database, the environment cannot be restored. It should be backed up daily.Performance Management System TablesThis database stores metrics, Key Performance Indexes (KPI), metadata, and key relationships that drive dashboards and scorecards. In many Enterprise environments, these tables will be stored in the same physical database as the CMS system tables, making it easy to capture during a routine back up of the CMS tables. This database should be captured at the same frequency as the CMS system database, ideally on a daily basis.

File Repository

This is a standard OS file share that contains all the report templates and instances for the environment. The file repository typically ranges in size from 1 GB to 100 GB depending on the size and complexity of the deployment. Since the file repository is designed to exist in synchronicity with the CMS tables, it should be backed up at exactly the same time as the CMS system tables.Failure to capture the file repository and CMS system tables simultaneously, when the CMS and FRS services are stopped, could result in poor back up integrity. This is because of the increased risk for orphaned report objects or report pointers in the CMS system database if a database restore becomes necessary. Orphaned report pointers are those records in the CMS system database that do not point to a valid input or output file in the Enterprise Input or Output FRS. If a user were to select a report object or report instance that was orphaned, an error message would occur and they would not be able to access that object or instance. Orphaned input or output files in the file repository are a benign problem compared to orphaned pointers in the CMS tables. Only the Input and Output subfolders need to be backed up (the Temp folder can be ignored).

Local audit log files

When auditing servers is enabled, each BusinessObjects server writes audit records to a log file local to the server. At regular intervals, the CMS communicates with the audited servers to request copies of records from the local log files. These log files need to be backed up daily.

Auditing Tables

This database contains usage statistics and auditing information for the environment. A back up of this database is not needed to recover from a disaster because the information this database contains is the least important of all BusinessObjects components.

4.2.6.2 Custom Java applications/code

Any programmatic customizations to InfoView or other custom user interfaces should be backed up as frequently as they change. During active development periods, these items

Page 23 of 34

Page 24: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

should be backed up daily. Thereafter, they can be backed up weekly or monthly, or as often as the code is modified. Currently, Business Objects Integrated System consists only of Port Director Dashboards and does not contain any custom code.The back up and recovery process should be revised once more projects are integrated into it.

4.2.6.3 Database Connections (ODBC DSNs)

Special database connections (such as ODBC DSNs) can not be easily captured and restored via normal back up processes. Because of this limitation, a back up and recovery plan should cover connectivity parameters for all known data sources. At a minimum, it would cover:• The name of the ODBC DSN• The name of the target database• The type of target database in Oracle• The user ID and password used to connect to the database• A listing of the reports that rely on the data source• Any other pertinent information that an administrator can use to recreate the data source manually if necessary

4.2.6.4 Query Data Source – Data Warehouse

Although technically not Enterprise components, all reporting databases and cubes should be backed up on a daily basis or at least as frequently as the data changes.

4.2.7High-Level Sequence of Back up Events

1. The Central Management Server (CMS) and all job-processing and Performance Management servers should be stopped by an automated script. This action:i. Releases the CMS’ connection to the system database.ii. Releases Performance Management’s connection to its tables in the CMS system database.iii. Prevents users from accessing Enterprise.iv. Prevent report jobs/analytics from executing (and terminates any report jobs/analytics already in execution).v. Assures the continued integrity of the Enterprise File Store.

2. After the Enterprise services have stopped, the IT Administrator should capture the back up of the components mentioned in the Business Objects Content to Back up section.

3. After the back up is complete, the IT Administrator restarts the Enterprise services. This can be done by an automated script.

4.2.8High-Level Sequence of Recovery Events

4.2.8.1 Web and BusinessObjects XI Release 2 System Files

If necessary, rebuild and restore the system, ensuring that the number and size of disk volumes are the same or larger than the previous system. If you must rebuild a system by starting with an empty hard drive, install the OS on the same disk as before, then recreate the partitions and volumes as they were on the damaged system. If recovering only

Page 24 of 34

Page 25: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Enterprise content, make sure to install Enterprise on the same drive as on the original system.

4.2.8.2 Web and BusinessObjects XI Release 2 Data Files

1. Restore the back up of the CMS system database.2. Restore the back up of the PM repository.3. Install/configure the data source client software to point to the restored database and report source.4. Restore the Input and Output File Repositories.For replicating on a second server, conduct the installations as above and use the Business Objects Import Wizard to import the required information from one Enterprise system to another.Individual files from a specific date can be restored from the file system back up tapes. If it is necessary to restore entire file systems, the most recent full system back up tape should be restored first, followed by the first incremental back up, then the second incremental back up, and so on until the file system is fully restored.

Page 25 of 34

Page 26: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

References

Business Objects Document: Backup and Recovery Best Practices.

Page 26 of 34

Page 27: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

5 Business Objects Performance Optimization Best Practices

5.1 Introduction

This document serves to illustrate a few best practices that can be followed to enhance and optimize the performance of a Business Objects deployment in the aspect of document design, document computation time, network and system configuration and general server tuning.

5.2 Optimizing Document Design

Dissatisfaction with the performance of a product is sometimes due to the user’s tendency to use the product in a way for which it was not designed. Documents that take a long time to run and refresh may not be designed in an optimal manner. Reports that are excessively long or complex may therefore lead to display issues such as long response time. It is therefore important to strategically design documents with your system, network, and user population specifics in mind. These variables can be drastically different between deployments, and as a result, there are no fast rules on designing documents. The following general tips are designed to guide you in creating a document design strategy appropriate to your deployment:

Documents over 200 MB will significantly impact performance. Keep and monitor your document size to well below this limit. The smaller, the better. In general, limit document size to approximately 5 MB, but performance depends on your specific deployment, available resources, network specifics, etc.

As with universe development, involve end users as soon as possible, as often as possible, and at every stage. Create document prototypes to demonstrate both for feedback and "educational" purposes. This will enable you to design the type of document that best needs your end users’ information needs.

Define standards for document variable, block, table, chart, column, tab, and data provider names. This makes maintenance easier.

Give each data provider a meaningful, user-friendly name. Produce a standard corporate document template, which may incorporate header/footer,

title, logo, date/time, font and calculation formats. Save this as the default template. Whenever possible, use breaks to have better control over white spaces. Use sections for

better navigability. Remove redundant or unused variables. Give each document a unique identifier. For example, make its title a combination of letters

and/or numbers: A100, A101 etc. Keep documents in 'sets' and reflect this in the numbering. For example all inventory documents run from IN1000 to IN9999, all customer-related documents run from CU1000 to CU9999 etc. This makes identifying the document easier for retrieval, removes any confusion when relating to technical support.

Restrict the amount of data returned to the client by placing conditions on query objects. This is especially valid over slower networks.

Use user prompts in standard documents to restrict data and display relevant data to individual users under a common format. This can reduce the number of documents being developed for multiple users, and it avoids the possible wide-scale distribution of documents containing large and potentially irrelevant amounts of data.

Page 27 of 34

Page 28: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

5.2.1Desktop Intelligence Documents

The following tips are specific to full-client (Desktop Intelligence) documents: When creating full-client (Desktop Intelligence) documents, reduce the number of

calculations in a document to the required minimum (including the count calculation). Calculations (variables and formulas) created at the document level are performed upon the opening of the report by the Desktop Intelligence process (BusObj on Windows and bolightsvr on UNIX). The more variables and formulas created at the document level, the heavier the load on system resources, and the greater the impact on performance when the report is opened or refreshed.

With Desktop Intelligence documents, have the first tab be a cover sheet containing information about the document. This opens up very quickly even if the tabs have to be generated.

It’s better to create a single document with multiple report tabs rather than separate queries for separate documents, as this will result in more efficient processing for an On-Line Transaction Processing (OLTP) system.

You can create different Desktop Intelligence reports by adding more tabs that represent the data in numerous ways or use filters to display different values for a dimension for each report tab. This method works well with universes built on transaction databases where performance is an issue.

Limit data providers in the creation of a Desktop Intelligence documents. Each data provider requires a separate connection to the database. A BusObj/bolightsvr process synchronizes all the data from each provider. The more data providers need be synchronized, the more machine resources are required by the BusObj/bolightsvr to accomplish this task.

If you have multiple reports on separate report tabs and these reports draw their data from the same source, do not create a separate data provider for each report. Instead, create a “base” data provider that contains the data used by all the reports. Since Desktop Intelligence retrieves data for each data provider, it is more efficient to retrieve data once and distribute it to several reports than to retrieve the same data several times.

Example: Create reports showing revenue by country and resort, and revenue by country In this example the Revenue and Country objects are common to both reports. Instead of

creating a data provider for each report you create a data provider containing the Revenue, Country, and Resort objects and use these objects in both reports.

You can use the Query Panel to modify a data provider by selecting: Data > Edit Data Provider Create Summary / Detail documents in Desktop Intelligence using View >Outline. This allows

you to fold and unfold the sections and/or data that correspond to a break in the current block.

Break up large Desktop Intelligence documents into separate report tabs, so that the PDF/HTML is only generated for the tabs that the user requests. Less data is therefore transferred to the client browser.

Choose the presentation format for Desktop Intelligence documents according to their intended distribution media.

5.2.2WebIntelligence Documents

The following tips are specific to thin-client (Web Intelligence) documents:

Avoid calculating sums and percentages in Web Intelligence documents encompassing several thousand rows. The count calculation has a negative impact on performance on very long documents.

Avoid designing 600-page long Web Intelligence documents! This is a guideline, and not a concrete limit, but consider the impact on the server of processing such a document. Beyond the document processing stage, consider the load on your network as the client

Page 28 of 34

Page 29: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

requests such a document. Consider the number of users that request this particular document. All of these performance factors contribute to the response time of large and complex documents. Large Web Intelligence documents have an especially negative impact in extranet and WAN deployments, which are network-bound. The smaller the web pages transferred to the client, the fewer clients response time is affected by the network.

Use drill functionality or the Web Intelligence hyperlink index for section navigating.

Page 29 of 34

Page 30: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

5.3 Improving Overall Document Computation Time

Keep the number of variables to a minimum. Avoid linking multiple queries into a single document. Avoid having a single query with multiple select statements being "joined" or "synchronized"

by Desktop Intelligence. For Oracle connectivity, right-click on a table and use the Number of rows in table option.

This can optimize querying when Oracle is running in rule-based mode. Do not store data within a full-client document, especially if the document will be refreshed

on open in InfoView. In Desktop Intelligence, when you export a document to the repository, make sure the data is purged from the cube: View > Data Manager > Results tab, Purge button.

As a document without data takes up less space in the repository, the export, import and refresh of the document are considerably quicker, as is the opening of the document in InfoView.

Do not store HTML within a document, especially if the document will be refreshed on being opened in InfoView (File > Publish to Corporate Documents, HTML Options button: Deselect the Store generated HTML in document option).

You can reduce the time it takes to open the Desktop Intelligence document and generate the HTML by breaking down the document into smaller documents and/or by breaking the report into separate report tabs. We suggest that you:

Create a document per section and/or per report tab. Reduce the number and/or the complexity of the formulas in your documents whenever

possible.

Page 30 of 34

Purge

Page 31: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

5.4 Network and System Configuration

Closely monitor your system for bottlenecks, especially when performance is less than satisfactory. Bottlenecks are caused when part of the system is not running fast enough to keep up with the demands placed on it. The most common bottlenecks occur for the following reasons:

Slow disks or disk arrays aren't able to handle I/O requests quickly enough The system is starved for memory, so applications are forced to swap to disk, which can

slow response The system is out of processor power The network interface is overloaded Remove as many network components in the system as possible between the Web

Intelligence server, the repository and the corporate databases. Keep all the system components physically close to each other. It is especially important to keep the database and the Web Intelligence server close to each other.

Put Web Intelligence, the repository and the corporate database on a switched hub, preferably the same switched hub. This hub should be running at least 100 mbps full duplex.

Use the fastest network cards and hardware possible. Remove all unrequired protocols. Use optic fibre when possible. Keep all system components in the same subnet and going into a dedicated switch. Any extranet server should have as few devices as possible between it and the WAN

connection. Under Windows 2000, select Background services in the Application response box (My

Computer > Properties > Advanced > Performance Options):

Page 31 of 34

Uncheck this

Page 32: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

5.5 General Server Tuning

The server should be dedicated to Web Intelligence system usage.

Purchase machines that will allow more CPUs to be added later. CPU will often be the first resource that Web Intelligence uses up.

You can never have too much memory on a server. Remember, though, that memory is not the only possible bottleneck in a deployment.

When estimating the number of servers you need for your user population, use the formulas contained in the Business Objects documentation, specifically the Deployment Guide and the UNIX Performance, Optimization and Sizing Guide in particular if you have a UNIX server, but understand that these are just general guidelines. Each configuration and type and conditions of usage is different; you will only be able to pinpoint what your optimal configuration is by benchmarking, benchmarking and more benchmarking.

“The most serious bottleneck is an overloaded or slow disk (I/O).” from Sun Performance and Tuning, Adrian Cockcroft & Richard Pettit. Choose SCSI disks for the best I/0 performances and, if using RAID arrays, put frequently accessed files on RAID 0 or 0+1.

Use RAID disks for Storage, with the operating system on its own disk (RAID 0 or 1, and the Application and Web Intelligence servers on RAID 5).

5.6 Web Servers

Web servers are an element of your deployment that can be tuned relatively easily to improve performance. If you are deploying a cluster, you can put your web server on a Windows or a UNIX node, but UNIX is recommended because it has the best throughput.

Page 32 of 34

Page 33: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

Never bind web servers to virtual IP addresses. You can bind web servers on the same network interface in other ways, such as by binding them on different ports rather than addresses.

For example:

webserver1 = http://ipaddress:8080 webserver2 = http://ipaddress:9090

5.7 Configuring the Cluster Modules

General Advice

Disable logging whenever and wherever it is not absolutely necessary. This includes Web Intelligence internal and user activity traces, as well as logging on the web server, CORBA/ORB, and middleware. Note that user logging must be enabled if AUDITOR is being used.

Use the WIGenerator parameter Node Load Factor to take full advantage of the capacity of each cluster machine.

To minimize dead user sessions due to users closing the browser rather than logging out, drop WIGenerator and other module timeouts to 20-30 minutes. You can set session timeout to 60 minutes.

If possible, process thin-client documents on certain machines, and full-client documents on others.

Put the heavier processing load on cluster nodes, leaving the cluster manager freer to perform its control and management functions.

Use the fastest disk possible on the server running the WIStorageManager and WISessionManager, as the throughput on this server is one of the critical aspects for performance.

In larger deployments, an all cluster manager deployment (therefore multiple clusters, using a Cisco Local Director or equivalent) may be the best strategy if you are concerned about system uptime. If every machine is a cluster manager, failover is excellent! Multiple session managers can speed up login, and can, depending on the workflow, minimize network traffic. Note that this multiple cluster manager configuration is not supported for use with a single instance of AUDITOR.

References

Business objects Document: BO Best Practices for Performance Tuning

Page 33 of 34

Page 34: Business Objects Best Practices and Lessons Learnt

Business Objects Universe Design Best practices

========= End of Document =========

Page 34 of 34