V1.0
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 Addend a/New Page Release Notice Reference
Page 2 of 30
Table of Contents
1 1.1 1.2 1.3 1.4 1.5 Universe Design Best Practices ........................................................................................................... 5 Introduction ...................................................................................................................................... 5 Universe Design and Development ................................................................................................. 5 Universe Design ............................................................................................................................... 5 General Universe Development Best Practices ............................................................................... 6 Some Real time Best Practices Solutions........................................................................................ 8 1.5.1 1.5.2 Define default value ALL for prompts ............................................................. 8 Universe Documentation ........................................................................... 11
References .................................................................................................................................................. 12 2 2.1 2.2 2.3 2.4 Business Objects Report Development Best Practices ..................................................................... 13 Introduction .................................................................................................................................... 13 Desktop Intelligence Documents ................................................................................................... 13 WebIntelligence Documents .......................................................................................................... 14 Some real time Best Practices Solutions ....................................................................................... 14 2.4.1 2.4.2 3 3.1 3.2 Methods to getting Desktop Intelligence data in Excel sheet ................................. 14 Incorporating an Image as a report object ....................................................... 15
Business Objects Design and Development Lessons Learnt ............................................................ 16 Introduction .................................................................................................................................... 16 Lessons Learnt in Reporting .......................................................................................................... 17 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.2.10 3.2.11 3.2.12 3.2.13 Chart ................................................................................................... 17 Drill ..................................................................................................... 17 Data source........................................................................................... 17 Report ................................................................................................. 17 Formatting ............................................................................................ 17 Functions ............................................................................................. 17 Report layout and print ............................................................................. 18 Templates............................................................................................. 18 Scheduling ............................................................................................ 18 Report view ........................................................................................... 18 Universe Changes ................................................................................... 18 Images ................................................................................................ 18 Hyperlinks............................................................................................. 18 Dynamic Prompts .................................................................................... 19 Restoration of a Universe Deleted From CMS .................................................. 19 Ensuring that client-server communication in BO is secured ................................. 19
3.3
3.4
4 4.1 4.2
Business Objects Installation, Configuration and Deployment Best Practices .................................. 20 Introduction .................................................................................................................................... 20 Back Up and Recovery Best Practices .......................................................................................... 20 Page 3 of 30
Business Objects Universe Design Best practices Back Up and Recovery Process Concept ....................................................... 20 The Importance of a Proper Back up Sequence ............................................... 20 Enterprise Content Back up compared to Server Back up .................................... 20 Incremental Back up compared to Full Back up ................................................ 21 Cold Back up compared to Warm Back up ...................................................... 21 Business Objects Content to Back up ............................................................ 21 High-Level Sequence of Back up Events ........................................................ 23 High-Level Sequence of Recovery Events ...................................................... 23
References .................................................................................................................................................. 24 5 5.1 5.2 Business Objects Performance Optimization Best Practices ............................................................. 25 Introduction .................................................................................................................................... 25 Optimizing Document Design ........................................................................................................ 25 5.2.1 5.2.2 5.3 5.4 5.5 5.6 5.7 Desktop Intelligence Documents .................................................................. 25 WebIntelligence Documents ....................................................................... 26
Improving Overall Document Computation Time ........................................................................... 27 Network and System Configuration ............................................................................................... 28 General Server Tuning ................................................................................................................... 29 Web Servers .................................................................................................................................. 29 Configuring the Cluster Modules .................................................................................................... 30
References .................................................................................................................................................. 30
Page 4 of 30
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 businessoriented 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
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. Build universes by referring to existing company documents. Build universes by starting with user requirements.
Page 5 of 30
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
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 precalculated 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. 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:
Page 6 of 30
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 30
1.5
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 30
Sample tables
Page 9 of 30
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 below SELECT DISTINCT ref_customer_score_errors.ERROR_CD FROM ref_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 DISTINCT ref_customer_score_errors.ERROR_CD FROM ref_customer_score_errors UNION SELECT DISTINCT '(ALL)' FROM ref_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 30
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 inputs 2) 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 its easy to choose
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 30
References
Page 12 of 30
2 Business Practices
2.1 Introduction
Objects
Report
Development
Best
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
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. Its 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.
Page 13 of 30
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
Page 14 of 30
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).
Page 15 of 30
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 16 of 30
3.2
3.2.1 Chart
3D chart option is very poor, and cannot be used for any business need. Size of the chart cannot be auto fit Filters 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.2 Drill
Synchronized drilling across multiple blocks in the same report r equires 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 wont reappear. So all changes in the report blocks must be done with drill off. Column headers wont 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.4 Report
Macros cannot be used
3.2.5 Formatting
Copy between two tabs is not possible Formatting 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.6 Functions
Ranking is not possible. Workaround is to create rank objects in the universe and use in reports.
Page 17 of 30
3.2.8 Templates
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.9 Scheduling
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 mod e, 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.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 Rep ort 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 18 of 30
3.3
3.4
Page 19 of 30
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
Page 20 of 30
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 servers operating system as well as any applications and data stored on the servers 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.
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
Page 21 of 30
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 Tables This 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 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 Page 22 of 30
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.
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 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 23 of 30
References
Business Objects Document: Backup and Recovery Best Practices.
Page 24 of 30
5.2
Dissatisfaction with the performance of a product is sometimes due to the users 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.
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. Its 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 f or 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.
Page 26 of 30
5.3
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.
Purge
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 27 of 30
Uncheck this
5.4
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 28 of 30
5.5
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. 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. Page 29 of 30
5.7
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 30 of 30