Deployment

Deploying the Business Objects System
BusinessObjects Enterprise 6 Business Intelligence Windows and UNIX
Copyright
No part of the computer software or this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from Business Objects S.A. The information in this document is subject to change without notice. If you find any problems with this documentation, please report them to Business Objects S.A. in writing at documentation@businessobjects.com. Business Objects S.A. does not warrant that this document is error free. Copyright Business Objects S.A. 2003. All rights reserved. Printed in France.
Trademarks
The Business Objects logo, WebIntelligence, BusinessQuery, the Business Objects tagline, BusinessObjects, BusinessObjects Broadcast Agent, Rapid Mart, Set Analyzer, Personal Trainer, and Rapid Deployment Template are trademarks or registered trademarks of Business Objects S.A. in the United States and/or other countries. Contains IBM Runtime Environment for AIX(R), Java(TM) 2 Technology Edition Runtime Modules (c) Copyright IBM Corporation 1999, 2000. All Rights Reserved. This product includes code licensed from RSA Security, Inc. Some portions licensed from IBM are available at http://oss.software.ibm.com/icu4j. All other company, product, or brand names mentioned herein, may be the trademarks of their respective owners.
Use restrictions
This software and documentation is commercial computer software under Federal Acquisition regulations, and is provided only under the Restricted Rights of the Federal Acquisition Regulations applicable to commercial computer software provided at private expense. The use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth in subdivision (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at 252.2277013. U.S. Patent Numbers 5,555,403, 6,247,008, and 6,578,027. 375-50-610-01
Patents Part Number
Contents
Contents Figures Preface Maximizing Your Information Resources 3 9 13
Information resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Useful addresses at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Part I Conceptual Overview Chapter 1 Introduction 23
Standard SQL reporting configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 The secure Business Objects configuration . . . . . . . . . . . . . . . . . . . . . . . . . 27 What can you do with the Business Objects solution? . . . . . . . . . . . . . . . . . 28 The Business Objects product line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Desktop products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Server products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Developer Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Administration products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Database Access Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Demonstrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Developer Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 How deployment documentation has changed . . . . . . . . . . . . . . . . . . . . . . 58 How terminology has changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Contents
Chapter 2
System Architecture and Communication
63
Deployment architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3-tier architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 The client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 The middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Database components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 What products are associated with each architecture? . . . . . . . . . . . . . . . . 78 What platforms are associated with each architecture? . . . . . . . . . . . . . . . 81 What is a cluster? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Why use distributed configurations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 What is CORBA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 The Application Server Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Changes in architecture and communication . . . . . . . . . . . . . . . . . . . . . . . 94 Chapter 3 How the System Is Administered 97
The systems administrative layer components . . . . . . . . . . . . . . . . . . . . . . 99 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Administering Broadcast Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Monitoring and analyzing system activity . . . . . . . . . . . . . . . . . . . . . . . . . 108 How administration has changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Chapter 4 The Repository and Security 117
Data security through the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 The role of Supervisor and Designer in security . . . . . . . . . . . . . . . . . . . . 120 Repository domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 How clients access the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Which components access the repository? . . . . . . . . . . . . . . . . . . . . . . . . 127 Using multiple repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 The repository and your data warehouse . . . . . . . . . . . . . . . . . . . . . . . . . 130 Working with or without a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Repository compatibility issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 User authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Network and system security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Contents
Part II Planning your Deployment Chapter 5 Deployment Considerations 143
Pre-deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Education: providing the tools to be successful . . . . . . . . . . . . . . . . . . . . . 146 Performance: what is acceptable and how can you attain it? . . . . . . . . . . 147 Server sizing: efficiently supporting peak user activity . . . . . . . . . . . . . . . . 148 Deployment configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Data management: making data accessible . . . . . . . . . . . . . . . . . . . . . . . 150 Protecting your system and your resources . . . . . . . . . . . . . . . . . . . . . . . . 151 Users: know their numbers, profiles, groups and rights . . . . . . . . . . . . . . . 152 Documents: what type, how complex? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Load balancing: matching system processes and server resources . . . . . 158 Disaster recovery: what can you do about it? . . . . . . . . . . . . . . . . . . . . . . 159 Deployment procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Chapter 6 Modeling your System 163
Designing your architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Selecting your systems software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Selecting your systems operating system . . . . . . . . . . . . . . . . . . . . . . . . . 170 Deployment models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Cluster architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Repository architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Database and repository location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Centralized or decentralized architecture? . . . . . . . . . . . . . . . . . . . . . . . . . 187 Global deployment scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Contents
Chapter 7
Supported Deployment Configurations
201
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 2-tier deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 3-tier architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Combined 2- and 3-tier deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Basic intranet deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Basic extranet deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 DMZ configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 IP redirectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Multiple clusters in an intranet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Alternative extranet deployment configurations . . . . . . . . . . . . . . . . . . . . 231 Single-cluster intranet/extranet deployment options . . . . . . . . . . . . . . . . . 235 Deployment configuration summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Part III Installing and Configuring the System Chapter 8 Installing the Products 243
Pre-installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Copying the license file to each machine . . . . . . . . . . . . . . . . . . . . . . . . . 246 Fresh installation or upgrade? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 What do you install on what machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Installing on Windows machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Installing under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Installation update, repair, uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Installing Service Pack updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Installing BusinessObjects from InfoView . . . . . . . . . . . . . . . . . . . . . . . . . 260 Tips for the mass installation of desktop products . . . . . . . . . . . . . . . . . . 261 How has installation changed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Contents
Chapter 9
Getting the System Up and Running
267
How has configuring and starting the solution changed? . . . . . . . . . . . . . . 269 Configuring the server system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Creating the repository with Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Defining access rights with Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Creating universes with Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Making sure youre ready to start the system . . . . . . . . . . . . . . . . . . . . . . 288 Starting up the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Tuning the system using the Administration Console . . . . . . . . . . . . . . . . 290 Setting the locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Creating and sharing documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Part IV Part V Practical Deployment Specifics Chapter 10 From Development to Production 303
The development lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Planning the pre-production environment . . . . . . . . . . . . . . . . . . . . . . . . . 310 Creating the lifecycle environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Migrating between environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Planning and building the production environment . . . . . . . . . . . . . . . . . . 335 Chapter 11 Implementing Supported Deployment Configurations 337
Deployment rules for all configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Implementing a basic intranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . 344 Implementing a basic extranet deployment . . . . . . . . . . . . . . . . . . . . . . . . 345 Implementing a DMZ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Implementing an IP redirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Implementing a single web server for intranet and extranet users . . . . . . . 356
Contents
Chapter 12
Deploying and Managing the Repository
357
Choosing a repository database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 How much space should you allot for the repository? . . . . . . . . . . . . . . . . 362 The location of repository domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Deploying and using multiple repositories . . . . . . . . . . . . . . . . . . . . . . . . . 367 Optimizing the security domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Making documents available to users of other repositories . . . . . . . . . . . 372 Changing a clusters repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Chapter 13 Deploying Specific Products 375
Overall product deployment guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Choosing your applications and how they are deployed . . . . . . . . . . . . . . 379 Deploying InfoView/WebIntelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Deploying BusinessObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Deploying Broadcast Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Deploying Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Chapter 14 Deploying WebIntelligence for OLAP Data Sources 415
WebIntelligence OLAP server as part of the cluster . . . . . . . . . . . . . . . . . 417 Setting up the dedicated OLAP node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 The caching service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 The Universal Drill-through Service (UDS) . . . . . . . . . . . . . . . . . . . . . . . . 426 Installing the OLAP caching and UDS services on cluster nodes . . . . . . . 427 Configuring the OLAP caching and UDS services on cluster nodes . . . . . 429 Defining the OLAP connection in WebIntelligence . . . . . . . . . . . . . . . . . . 439 Appendix A How Products Compare Functionally 441
InfoView vs. WebIntelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 BusinessObjects: 2-tier vs. 3-tier mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence . . . . . . . . . 446 Processing different types of documents in InfoView . . . . . . . . . . . . . . . . 448 Version 2.x/5.x vs. 6.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 Index 457
Contents
Figures
1-1 Example of a Business Objects product deployment . . . . . . . . . . . . . . . 24 1-2 A standard SQL reporting configuration . . . . . . . . . . . . . . . . . . . . . . . . . 26 1-3 Secure Business Objects reporting configuration . . . . . . . . . . . . . . . . . 27 1-4 BusinessObjects document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1-5 Sending a BusinessQuery file to other users . . . . . . . . . . . . . . . . . . . . . 34 1-6 InfoView home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 1-7 InfoView document list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 1-8 WebIntelligence document viewed in InfoView . . . . . . . . . . . . . . . . . . . 38 1-9 A WebIntelligence HTML Report Panel . . . . . . . . . . . . . . . . . . . . . . . . . 40 1-10 A WebIntelligence Java Report Panel . . . . . . . . . . . . . . . . . . . . . . . . . 41 1-11 Developer Suite Welcome screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 1-12 Creating user groups in Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 1-13 Universes: from the document editor to the database . . . . . . . . . . . . . 49 1-14 Auditor in the Business Objects system . . . . . . . . . . . . . . . . . . . . . . . . 50 1-15 Analyzing user activity using Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . 50 1-16 The Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 1-17 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 1-18 Entrance point to Business Objects multimedia Quick Tours . . . . . . . 56 2-1 2-tier deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2-2 Simple 3-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2-3 Business Objects system 3-tier architecture . . . . . . . . . . . . . . . . . . . . . 69 2-4 Example InfoView home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2-5 The web and application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2-6 A Business Objects cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2-7 How the ORB works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 2-8 The CORBA container/component model . . . . . . . . . . . . . . . . . . . . . . . 87 2-9 How the ASF works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2-10 Setting the number of WIQT processes . . . . . . . . . . . . . . . . . . . . . . . . 90 2-11 The Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3-1 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figures
10
3-2 The Broadcast Agent Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Administering the Audit facility in the Administration Console . . . . . . 3-4 Auditor web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 The repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Security through the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Both corporate database and repository in Oracle . . . . . . . . . . . . . . . 4-3 Corporate database in DB2 but repository in Sybase . . . . . . . . . . . . . 4-4 Repository in DB2, with different corporate databases . . . . . . . . . . . . 4-5 Different parts of the repository on different databases . . . . . . . . . . . 4-6 Setting the authentication method in the Administration Console . . . . 4-7 Three levels of security at login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Typical proportions of user types in a Business Objects deployment . 6-1 Administration products on Windows machines outside cluster . . . . . 6-2 Processing power vs. number of nodes in a Windows cluster . . . . . . 6-3 Setting the clusters locale and charset in the Administration Console 6-4 Choosing the security domain from BusinessObjects (3-tier) . . . . . . . 6-5 Setting the WILoginServer refresh period . . . . . . . . . . . . . . . . . . . . . . 6-6 Centralized architecture with a single cluster . . . . . . . . . . . . . . . . . . . 6-7 Centralized architecture with failover . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 Decentralized architecture with centralized security domain . . . . . . . 7-1 2-tier configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Combined client/server and n-tier architecture deployment . . . . . . . . 7-3 Basic intranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Standard extranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Typical DMZ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Communication protocols in a DMZ configuration . . . . . . . . . . . . . . . 7-3 Typical DMZ topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Reverse proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Deployment schema for an IP redirector . . . . . . . . . . . . . . . . . . . . . . . 7-6 IP redirector with sticky command enabled . . . . . . . . . . . . . . . . . . . . . 7-7 IP redirector with multiple clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 User request redirected to next web server/primary node . . . . . . . . . 7-9 One web server pointing to one primary node . . . . . . . . . . . . . . . . . . 7-10 Multiple web servers pointing to one primary node . . . . . . . . . . . . . . 7-11 Running one web server within a single cluster . . . . . . . . . . . . . . . .
106 108 109 121 124 130 131 131 131 135 137 153 173 178 181 183 186 188 191 195 205 208 210 213 216 217 218 221 225 226 227 229 232 234 235
Figures
11
7-12 Multiple web servers with a single cluster . . . . . . . . . . . . . . . . . . . . . 236 8-1 Welcome screen for the Windows installer . . . . . . . . . . . . . . . . . . . . . 251 8-2 The Installation Type screen in the Windows installer . . . . . . . . . . . . . 253 8-3 Custom Setup window in the Windows installer . . . . . . . . . . . . . . . . . 254 8-4 Screen from the Business Objects installer for UNIX . . . . . . . . . . . . . 256 8-5 Selecting products for installation in the UNIX installer . . . . . . . . . . . . 257 8-6 License check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 9-1 The English graphical interface for the Configuration Tool . . . . . . . . . 272 9-2 The Configuration Tools Cluster Configuration Tree . . . . . . . . . . . . . . 274 9-3 The Administration Setup wizard in Supervisor . . . . . . . . . . . . . . . . . . 280 9-4 Assigning user rights with Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . 283 9-5 Creating a universe in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 9-6 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 9-7 Starting the session stack using the Administration Console . . . . . . . 292 9-8 Example three-node cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 9-9 Setting node weight using the Administration Console . . . . . . . . . . . . 295 9-10 Setting the default language during Business Objects installation . . 296 9-11 Setting a clusters language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 9-12 Setting the user interface language in InfoView . . . . . . . . . . . . . . . . . 298 9-13 How 3-tier users access BusinessObjects documents . . . . . . . . . . . 299 10-1 The development lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10-2 Creating repository domains with Supervisor . . . . . . . . . . . . . . . . . . 317 10-3 Migrating universes from development through production . . . . . . . . 319 10-4 Creating users and groups for lifecycle environments . . . . . . . . . . . . 320 10-5 Exporting universes to the repository . . . . . . . . . . . . . . . . . . . . . . . . . 324 11-1 Example deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 11-2 Intranet deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 11-3 Standard extranet deployment schema . . . . . . . . . . . . . . . . . . . . . . . 345 11-4 Typical DMZ deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 11-5 Example deployment configuration using an IP redirector . . . . . . . . . 348 11-6 Single web server for intranet and extranet users . . . . . . . . . . . . . . . 356 12-1 Scan and Repair dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 12-2 Selecting the security domain/repository in 3-tier BusinessObjects . 367 13-1 2-tier BusinessObjects deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 380 13-2 BusinessObjects document viewed in InfoView . . . . . . . . . . . . . . . . . 381
Figures
12
13-3 3-tier deployment of BusinessObjects . . . . . . . . . . . . . . . . . . . . . . . . 13-4 Dedicated server/double repository for Auditor . . . . . . . . . . . . . . . . . 13-5 Dedicated server/single repository for Auditor . . . . . . . . . . . . . . . . . 14-1 Recommended cluster deployment for OLAP processing . . . . . . . . 14-2 Module enablement for the clusters OLAP node . . . . . . . . . . . . . . . 14-3 OLAP services running on the WebIntelligence OLAP node . . . . . . 14-4 OLAP services on a different node from WebIntelligence OLAP . . .
383 411 413 417 424 427 428
Figures
Maximizing Your Information Resources
preface
14
Overview
Information, services, and solutions
The Business Objects business intelligence solution is supported by thousands of pages of documentation, available from the products, on the Internet, on CD, and by extensive online help systems and multimedia. Packed with in-depth technical information, business examples, and advice on troubleshooting and best practices, this comprehensive documentation set provides concrete solutions to your business problems. Business Objects also offers a complete range of support and services to help maximize the return on your business intelligence investment. See in the following sections how Business Objects can help you plan for and successfully meet your specific technical support, education, and consulting requirements.
15
Information resources
Whatever your Business Objects profile, we can help you quickly access the documentation and other information you need.
Where do I start?
Below are a few suggested starting points; there is a summary of useful web addresses on page 18. Documentation Roadmap The Documentation Roadmap references all Business Objects guides and multimedia, and lets you see at a glance what information is available, from where, and in what format. View or download the Business Objects Documentation Roadmap at www.businessobjects.com/services/documentation.htm Documentation from the products You can access electronic documentation at any time from the product you are using. Online help, multimedia, and guides in Adobe PDF format are available from the product Help menus. Documentation on the web The full electronic documentation set is available to customers with a valid maintenance agreement on the Online Customer Support (OCS) website at www.businessobjects.com/services/support.htm Buy printed documentation You can order printed documentation through your local sales office, or from the online Business Objects Documentation Supply Store at www.businessobjects.com/services/documentation.htm Search the Documentation CD Search across the entire documentation set on the Business Objects Documentation CD shipped with our products. This CD brings together the full set of documentation, plus tips, tricks, multimedia tutorials, and demo materials. Order the Documentation CD online, from the Business Objects Documentation Supply Store, or from your local sales office.
Information resources
16
Multimedia Are you new to Business Objects? Are you upgrading from a previous release or expanding, for example, from our desktop to our web solution? Try one of our multimedia quick tours or Getting Started tutorials. All are available via the Online Customer Support (OCS) website or on the Documentation CD.
How can I get the most recent documentation?

You can get our most up-to-date documentation via the web. Regularly check the sites listed below for the latest documentation, samples, and tips. Tips & Tricks Open to everyone, this is a regularly updated source of creative solutions to any number of business questions. You can even contribute by sending us your own tips. www.businessobjects.com/forms/tipsandtricks_login.asp Product documentation We regularly update and expand our documentation and multimedia offerings. With a valid maintenance agreement, you can get the latest documentation in seven languages on the Online Customer Support (OCS) website. Developer Suite Online Developer Suite Online provides documentation, samples, and tips to those customers with a valid maintenance agreement and a Developer Suite license via the Online Customer Support (OCS) website.
Send us your feedback

Do you have a suggestion on how we can improve our documentation? Is there something you particularly like or have found useful? Drop us a line, and we will do our best to ensure that your suggestion is included in the next release of our documentation: documentation@businessobjects.com
NOTE
If your issue concerns a Business Objects product and not the documentation, please contact our Customer Support experts. For information about Customer Support visit: www.businessobjects.com/services/support.htm
17
Services
A global network of Business Objects technology experts provides customer support, education, and consulting to ensure maximum business intelligence benefit to your business.
How we can support you?

Business Objects offers customer support plans to best suit the size and requirements of your deployment. We operate three global customer support centers: Americas: San Jose, California and Atlanta, Georgia Europe: Maidenhead, United Kingdom Asia: Tokyo, Japan and Sydney, Australia Online Customer Support Our Customer Support website is open to all direct customers with a current maintenance agreement, and provides the most up-to-date Business Objects product and technical information. You can log, update, and track cases from this site using the Business Objects Knowledge Base.
Having an issue with the product?

Have you exhausted the troubleshooting resources at your disposal and still not found a solution to a specific issue? For support in deploying Business Objects products, contact Worldwide Customer Support at: www.businessobjects.com/services/support.htm
Looking for the best deployment solution for your company?

Business Objects consultants can accompany you from the initial analysis stage to the delivery of your deployment project. Expertise is available in relational and multidimensional databases, in connectivities, database design tools, customized embedding technology, and more. For more information, contact your local sales office, or contact us at: www. businessobjects.com/services/consulting.htm
Looking for training options?

From traditional classroom learning to targeted e-learning seminars, we can offer a training package to suit your learning needs and preferred learning style. Find more information on the Business Objects Education website: www.businessobjects.com/services/education.htm
Services
18
Useful addresses at a glance

Address
Business Objects Documentation www.businessobjects.com/services/ documentation.htm
Content
Overview of Business Objects documentation. Links to Online Customer Support, Documentation Supply Store, Documentation Roadmap, Tips & Tricks, Documentation mailbox.
Business Objects Documentation mailbox documentation@businessobjects.com Product documentation www.businessobjects.com/services/ support.htm
Feedback or questions about documentation.
The latest Business Objects product documentation, to download or view online.
Business Objects product information Information about the full range of Business Objects products. www.businessobjects.com Developer Suite Online www.techsupport.businessobjects.com Knowledge Base (KB) www.techsupport.businessobjects.com Available to customers with a valid maintenance agreement and a Developer Suite license via the Online Customer Support (OCS) website. Provides all the documentation, latest samples, kits and tips. Technical articles, documents, case resolutions. Also, use the Knowledge Exchange to learn what challenges other users both customers and employees face and what strategies they find to address complex issues. From the Knowledge Base, click the Knowledge Exchange link. Practical business-focused examples.
Tips & Tricks www.businessobjects.com/forms/ tipsandtricks_login.asp
19
Address Online Customer Support www.techsupport.businessobjects.com
Content
Starting point for answering questions, resolving issues. Information about registering with Worldwide Customer Support. The range of Business Objects training options and modules.
www.businessobjects.com/services Business Objects Education Services www.businessobjects.com/services/ education.htm
Business Objects Consulting Services Information on how Business Objects can help maximize your business intelligence investment. www.businessobjects.com/services/ consulting.htm
Useful addresses at a glance
20
About this guide

This guide describes the overall Business Objects solution and how you can deploy it.
Audience
This guide is intended particularly for the IT specialists and administrators responsible for installing and deploying the Business Objects system. The first chapter in this guide provides a summary of what the system can do, and each of the products in the Business Objects line. This chapter is intended for a much broader audience, including users of the products.
Conventions used in this guide

The conventions used in this guide are described in the table below. Convention This font Indicates Code, SQL syntax, computer programs. For example: @Select(Country\Country Id). This font is also used for all paths, directories, scripts, commands and files for UNIX. Placed at the end of a line of code, the symbol ( ) indicates that the next line should be entered continuously with no carriage return.
Some code more code
$DIRECTORYPATHNAME The path to a directory in the Business Objects installation/configuration directory structure. For example: $INSTALLDIR refers to the Business Objects installation directory. $LOCDATADIR refers to a subdirectory of the Business Objects installation directory called locData.
Conceptual Overview
part
Introduction
chapter
24
Overview
What do we mean by deployment? Deployment is the distribution and arrangement of Business Objects query, reporting and analysis tools within a network infrastructure:
Application server
Extranet users
Primary node
Web server Business Objects cluster on intranet Corporate database 2-tier users (BusinessObjects, BusinessQuery)
Internet
Outer firewall
Inner firewall
Repository
Secondary node Administrators (Supervisor, Designer) 3-tier users (InfoView WebIntelligence BusinessObjects Broadcast Agent)
Figure 1-1 Example of a Business Objects product deployment
Initially offered for use in a standard client-server environment, Business Objects products can now be deployed and used over intranets, extranets and the World Wide Web. This means that users can access documents from wherever they are, using a standard web browser. Additionally, documents can be automatically broadcast to users at scheduled intervals. These documents can be set up so that the information made available to recipients is determined by their particular user profile.
Introduction
25
Each deployment is different. How your deployment is structured and configured depends on the number of users supported, the type of information access that you want your users to have, the number and types of databases youre using, the geographical distribution of your company, and so on. Before looking at the specific products Business Objects has to offer, it may be useful to review some basics, and to look at the reasons companies choose Business Objects as their database query, reporting, and analysis tool.
26
Standard SQL reporting configurations

Before the introduction of applications such as the Business Objects product suite, companies relied on database analysts and SQL specialists to directly access their databases and produce meaningful documents. This type of information access provides a direct link to the corporate database, and allows a large amount of functionality and customization by building unique combinations of SQL statements. However, it is not particularly flexible or easy to modify, since it requires a sufficient level of expertise to build the SQL statements into a coherent reporting environment. Also, data security is limited to the security mechanisms which are built into the corporate database.
Corporate database SQL
Client
Figure 1-2 A standard SQL reporting configuration
Introduction
27
The secure Business Objects configuration

As companies expand and diversify, it becomes more and more important that these functions be made accessible to non-specialized users within the company. A simplified interface is required; one that allows users to execute in-depth database queries, and generate comprehensive and professional documents, without needing to understand the underlying processes. This is the interface that Business Objects delivers with its Business Intelligence software products.
Corporate databases Client
Network
Business Objects servers
Client
Repository
Figure 1-3 Secure Business Objects reporting configuration
The Business Objects product suite uses a repository a database that is stored in a relational database management system. The repository is used by the various Business Objects products and modules to secure access to your data warehouse and to provide a deployment infrastructure for the Business Objects applications.
The secure Business Objects configuration
28
What can you do with the Business Objects solution?

Enterprises are inundated with data about their businesses from multiple sources, and need tools to gain more insight and control over complex business operations. Business Objects technology enables decision-makers in an organization to access, analyze, report and share corporate information without requiring any technical knowledge. This domain is called business intelligence, or BI. What can you get out of it? Reduced cost, greater efficiency, faster transactions and increased revenue. With BI, organizations around the world can link their customers, suppliers, partners and internal services to share information and work together in new ways. Based on its web-based thin-client product, WebIntelligence, and its webenabled full-client product, BusinessObjects, the Business Objects solution provides a robust and secure way to access, analyze and share information, either within an enterprise via an intranet, or beyond an enterprise via an extranet.
Intranets and extranets

An intranet is a network that reaches across all the different entities of an organization. TCP/IP has become a popular protocol since it allows network administrators to easily split heavy network traffic into smaller domains using subnets, which provides links between them using routers. It takes advantage of existing Internet standards such as the standard client-server model. You can picture the Internet as a massive TCP/IP network, where intranets are just smaller, organization-wide TCP/IP networks that provide company-related information to employees. When a company opens its intranet to selected business partners, the intranet becomes an extranet. Suppliers, distributors, and other authorized users can connect to the company's intranet over the web to view the selected subset of data the company makes available. Business Intelligence represents the move of organizations around the world to link their customers, suppliers, partners and internal organizations, to share information, work together in new ways, and to generate greater revenues.
Introduction
29
How does Business Objects fit into business intelligence?

As organizations establish their business offerings on the web, several implications have emerged surrounding the role of business intelligence. If you take a look at any e-business application framework, there are more aspects to it than just placing a sales order on the web. Once the sales order is placed companies need to take a look at previous transactions, they need to search on a particular product based on certain criteria, they probably need to define their profile and from time to time get alerted on promotions on a product based on their profile. The Business Objects distributed architecture perfectly fits these various aspects of customer interaction, enabling customers to communicate and share data over the web with their customers, partners and suppliers.
What can you do with the Business Objects solution?
30
The Business Objects product line

The Business Objects product line can be broken down into: Desktop products Server products Developer Suite Administration products Database Access Packs Demonstrations
Introduction
31
Desktop products
Business Objects Desktop products include: BusinessObjects BusinessQuery From the Business Objects Technical Support website at http://www.techsupport.businessobjects.com, you can also obtain a set of Rapid Deployment Templates, which are pre-defined universes for quick interfacing of Business Objects products with packaged solutions such as SAP and Baan.
BusinessObjects
BusinessObjects is the integrated query, reporting and analysis solution for business professionals that allows you to access the data in your corporate databases directly from your desktop and present and analyze this information in a BusinessObjects document. BusinessObjects makes it easy to access this data, because you work with it in business terms that are familiar to you, not technical database terms used in SQL. You dont need any knowledge of the database structure or technology. Once youve used BusinessObjects to access the data you need, you can present the information in documents as simple as tables, or as sophisticated as dynamic documents with drillable charts.
Desktop products
32
Figure 1-4 BusinessObjects document
You can then save those documents for your own personal use, send them to other users, save them to the corporate repository, or send them to Broadcast Agent Publisher for automatic refresh and distribution. This Windows product allows users to: build queries and create BusinessObjects documents, as well as view, refresh, schedule, distribute and print them. You can also work offline with a local copy of a document. view, refresh, schedule, distribute, drill and print BusinessObjects documents but not create or edit them The BusinessObjects product can be deployed in 2- and 3-tier architectures.
Introduction
33
BusinessObjects in 3-tier mode 3-tier deployments of BusinessObjects bring you all of the reporting options and most of the data analysis functions of the 2-tier version of the flagship product BusinessObjects in a zero-administration solution. This deployment of BusinessObjects offers the following advantages: The client machine is automatically configured during installation. Middleware is installed on the server so data access is centralized and easier to maintain. A Business Objects server handles both login and data access. In this scenario, BusinessObjects runs on a Windows PC as a standalone Windows application. Each time you launch the product, it checks that it is compatible with the server version; if it is out of date, you are prompted to update your client version. Only the minimum required software is installed on the client PC, all middleware and online help files remains on the server, and security and access is handled through Business Objects server. This means no client-side administration is required.
Desktop products
34
BusinessQuery
BusinessQuery for Excel is an add-in tool that provides Microsoft Excel with fully functional database access.
Figure 1-5 Sending a BusinessQuery file to other users
With BusinessQuery, you can access your corporate databases from Excel using familiar business terms. All BusinessQuery commands are available through the BusinessQuery menu and toolbar that appear in Excel. The result is easy and intuitive information access with guaranteed, reliable results. When you run a query, BusinessQuery automatically places the results into Excel cells. There is no need to copy or export the results to Excel. Nor are the results a static embedded object. Instead, they can be used with the full range of Excel functions, including calculations, charts, and pivot tables. BusinessQuery provides you with a one-step graphical interface called the Query Panel, that you use to build and run queries using standard Business Objects universes.
Introduction
35
Server products
Server products include: InfoView WebIntelligence Broadcast Agent
InfoView
At the core of the Business Objects BI solution is InfoView, the portal to your organizations information capital.
Figure 1-6 InfoView home page
InfoView is the web-based entry point for accessing WebIntelligence and BusinessObjects documents, as well as any type of third-party document. It collects and consolidates a companys BI information and presents it in a secure, organized, and personalized view to users both inside and outside your organization. With InfoView you can customize the look of your interface, manage, save, distribute, print and schedule documents for automated processing by Broadcast Agent Publisher from your office, home, or around the world, using the corporate intranet, an extranet, or the World Wide Web.
Server products
36
The InfoView document catalog At the heart of InfoView are the document lists which can be customized to suit your needs.
Figure 1-7 InfoView document list
Whether you are looking for a sales report, a financial statement, or an inventory spreadsheet sheet, the InfoView portal provides an instant overview of all the documents to which users have access rights. You can also search for particular documents by using the Search facility. The Home page can contain up to three document lists: The Corporate Documents list contains files that have been saved or added to a document domain in the corporate repository and made accessible to workgroups within the corporation or organization. The Personal Documents list contains documents users have saved for their own personal use. The Inbox Documents list contains documents sent by other users.
Introduction
37
A variety of readers provide top-quality viewing and printing capabilities for any type of document or file in the system. InfoView lets you view, refresh, manage and distribute documents, but not create or modify them. To do that, you need the WebIntelligence and/or BusinessObjects products, or other, third-party applications. Powerful information distribution InfoView lets you efficiently distribute documents both inside and outside your organization. It provides a secure interface for aggregating, managing and sharing critical information. Extranet providers can offer exceptional customer service and reduce costs in their supply chain. Their customers can enjoy self-service access to information tailored to their specific needs. Using the powerful broadcasting services of Broadcast Agent Publisher, you can schedule the automatic refresh and distribution of documents to colleagues or partners via the repository, the web, an intranet, or an extranet.
WebIntelligence
WebIntelligence allows users to access, analyze, and share corporate data over intranets and extranets for both relational (RDBMS) databases and online analytical processing (OLAP) servers. To access WebIntelligence, you log onto the business intelligence portal InfoView via your Internet browser. You can then create and edit WebIntelligence documents or analyze WebIntelligence reports. Using InfoView, you can save WebIntelligence documents to the corporate repository or share documents with other users.
Server products
38
Figure 1-8 WebIntelligence document viewed in InfoView
If your deployment includes Broadcast Agent Publisher, you can also schedule WebIntelligence documents for data refresh and distribution to other users. There are two WebIntelligence product modules: WebIntelligence - for reports based on RDBMS data sources WebIntelligence for OLAP Data Sources - for reports based on OLAP data providers
Introduction
39
WebIntelligence WebIntelligence provides the ability to create documents based on relational databases. It allows you to: interact with WebIntelligence documents, by applying filters and sorts to report values, and to analyze report data using drill create or edit WebIntelligence documents and to download WebIntelligence documents to Acrobat PDF format or Microsoft Excel format files with the original data definition and formatting The ability to include filters and prompts at the query level enables you to restrict the information in documents to the information needs of specific user groups. Standard formatting options help you create professional reports with a corporate look and feel. WebIntelligence license holders connect to a Business Objects universe, mapped to a corporate RDBMS data source, via InfoView. You can choose between two WebIntelligence Report Panels to define the query and reports within a WebIntelligence document: The WebIntelligence DHTML Report Panel, designed for users with basic reporting needs, provides a tab-by-tab workflow to define queries and report formats. Its pure DHTML technology makes it idea for extranet users, because no software is downloaded to the user's PC. An additional deployment option gives customers the ability to create custom HTML/ DHTML query interfaces and workflows for their unique environment using the WebIntelligence SDK.
Server products
40
Figure 1-9 A WebIntelligence HTML Report Panel
The reporting features in the HTML Report Panel include the ability to customize chart and table formats, insert breaks and calculations, apply sorts, and add multiple report filters. Documents created with the HTML Report Panel contain a single report and a single table or chart.
Introduction
41
The WebIntelligence Java Report Panel, designed for power users, provides a drag-and-drop interface similar to BusinessObjects. Users download the Java Report Panel to their local PC via their Internet browser.
Figure 1-10 A WebIntelligence Java Report Panel
The advanced feature set of the Java Report Panel includes all the features provided by the WebIntelligence HTML Report Panel plus: the ability to create multiple table, charts, and reports in a single document, build sub-queries using advanced filters, and use a graphical formula editor to build custom formulas and save formulas as variables. Both report panels are integrated with InfoView. Users set their analysis and document creation options on the InfoView Options pages.
Server products
42
WebIntelligence for OLAP Data Sources WebIntelligence for OLAP Data Sources enables users to create reports on multidimensional (OLAP) data sources on Hyperion Essbase, IBM DB2 OLAP Server, Microsoft Analysis Services, and SAP BW data providers. Using WebIntelligence for OLAP Data Sources, you connect to an OLAP data provider via InfoView, and then select a specific data cube to generate a report. You can navigate the cube then drill, slice, and dice directly on that OLAP cube. WebIntelligence has an easy-to-use DHTML drag-and-drop interface. The feature set includes synchronized grid and chart views, drilling on charts, and the ability to rank, sort, and filter values. Cascading style sheets enable you to provide a standard customized look and feel for WebIntelligence OLAP documents across your organization.
Broadcast Agent
With this release, the Broadcast Agent application has expanded to embrace two separate products which together significantly boost its power and scope: Broadcast Agent Scheduler Broadcast Agent Publisher Broadcast Agent Scheduler Encompassing all the functions known as Broadcast Agent in previous releases, Broadcast Agent Scheduler is the integrated enterprise report and broadcast application that allows business users to save to the repository, push, and broadcast pre-built or ad hoc reports on corporate data in batch mode, via the Internet, InfoView, and a wide range of output devices. Its state-of-the-art architecture and broadcasting technology make Broadcast Agent Scheduler a key component for large-scale enterprise deployments. End users can schedule documents for processing and distribution at times which suit their businesses. This can help reduce network traffic congestion, and enables documents to be printed or refreshed on the web at off-peak times (for example, during the night). For example, a standard production report that needs to be refreshed and distributed before every shift at an oil refinery could be scheduled by Broadcast Agent to execute every working day at 7 AM, 4 PM, and 11 PM.
Introduction
43
End users can even set conditions so that Broadcast Agent Scheduler processes and distributes documents only when events such as increased revenue occur. Fully integrated with VBA, Broadcast Agent Scheduler also allows users to customize BusinessObjects document processing by attaching macros that perform specific tasks such as paging and e-mail distribution. From an administration point of view, Broadcast Agent Scheduler is part of the Business Objects distributed solution across a CORBA network.
Broadcast Agent Scheduler generally runs on its own server in the back office, not on client machines. Unlike other enterprise reporting servers, Broadcast Agent Scheduler can execute both BusinessObjects and WebIntelligence documents in batch mode.
NOTE
Broadcast Agent Scheduler corresponds to the Broadcast Agent option in the Business Objects installer. Broadcast Agent Publisher Broadcast Agent Publisher is a server-based publishing system that allows you to broadcast business information to a mass audience through the web and email. Working alongside Broadcast Agent Scheduler, Broadcast Agent Publisher provides: an e-mail-based publication mechanism. By defining a group of users as recipients for a broadcast mail, you can easily distribute information to a chosen list of people, including those in an extranet environment. The recipients in turn can be given the option to unsubscribe from the distribution list and therefore stop receiving the broadcast. a mechanism for the secure delivery of targeted business information to groups or individuals through a password-protected portal, across an intranet, extranet, or the Internet.
NOTE
The installation of Broadcast Agent Publisher is separate from the Business Objects installer used for the other server products.
Server products
44
The Broadcast Agent Publisher email component This Broadcast Agent Publisher component allows you to use email either to notify a list of recipients that key information is available, or make that information directly available. Recipients can subscribe to the publications that are the most useful to them, and how often they want to receive them. As with the Broadcast Agent web component, you can specify the intervals at which you want to broadcast, and a condition that must be met before a publication is broadcast. You can also send a publication to a list of recipients taken from a Business Objects report. The Broadcast Agent Publisher web component This component allows you to process, publish and manage enterprise reports on the server. Using its enhanced report bursting feature, you can send a refreshed BusinessObjects report to a list of recipients and ensure that these recipients will see only the data they are authorized to see according to their access rights or hierarchical level. Recipients can then take advantage of Publishers new hyperlink navigation, versioning and comment capabilities. Broadcast Agent Publisher provides web-based administration for these publications, delivered over the web via InfoView. Web publishers can manage all the data used in creating publications, including users, profiles and base documents. Broadcast Agent Publisher comes with a configurable means of automatically populating and synchronizing users with external source systems. This allows IT managers and information publishers to deploy easily from almost any user data source.
Introduction
45
Developer Suite
The BusinessObjects object model provides application developers with tools to customize BusinessObjects and Designer. Developers can create internal scripts and OLE automation applications for external applications. These features allow developers to tailor data presentation and retrieval using BusinessObjects within their own software environment.
Figure 1-11 Developer Suite Welcome screen
Developer Suite
46
Developer Suite provides developers with three key advantages: A rich set of business intelligence components Developer Suites broad range of customization options run from a slight modification of the Business Objects interface, to completely integrating BusinessObjects or InfoView with other applications, such as those used in finance, human resources, sales, marketing and manufacturing. A state-of-the-art business intelligence infrastructure No matter what kind of customization theyre doing, developers will rely on the Business Objects infrastructure. When combined, the centralized repository, powerful semantic layer, and robust security system are the ideal underlying structure for a large business intelligence deployment. An easy-to-use and fast development environment Develop and deploy customized applications with speed and efficiency, thanks to the use of industry standard technology like Visual Basic for Applications (VBA) for BusinessObjects and Designer, as well as Active Server Pages (ASP) and JavaServer Pages (JSP) for WebIntelligence. Business Objects components are also available through a standard API. Developer Suite comes with additional documentation containing pre-written code, as well as development examples for both training purposes and accelerating the development process.
Introduction
47
Administration products
Administration products include: Supervisor Designer BusinessObjects Auditor additional products which are not purchased separately, such as The Configuration Tool, the Administration Console and the Diagnostics tools (UNIX only) For a full overview of how the system is administered, see How the System Is Administered on page 97.
Supervisor
Supervisor is the control center for the administration and security of your entire Business Objects deployment. It allows you as supervisor not only to set up and maintain a secure environment for the overall Business Objects system, but to create powerful and easy-to-use structures for distributing information between users. This information is centralized through relational data accounts called repositories. Supervisor creates the repository around which the Business Objects solution is built, defining the location and connectivity of the repository domains as well as the main administrator, or general supervisor. With Supervisor, you define users and user groups. You can control user access to Business Objects products and even the functions they contain, and manage the exchange and distribution of the universes and documents of all users.
48
Figure 1-12 Creating user groups in Supervisor
Supervisor lets administrators fine-tune user permissions through the use of security commands, which control with great flexibility what product functionality is available, both in the user interface and through programmability. Supervisor controls access of users and groups to resources such as documents, universes, stored procedures and repository domains, and also sets inheritance chains, so that permissions can be handed down to subgroups and users by default or set specifically per resource for any user or group.
Designer
Designer is the tool administrators use to create, manage, and distribute universes for BusinessObjects and WebIntelligence users. A universe is a file that contains connection parameters for one or more database middleware, and SQL structures called objects that map to actual SQL structures in the database such as columns, tables, and database functions. BusinessObjects and WebIntelligence users connect to a universe, and then run queries against a database. They can do data analysis and create documents using the objects in a universe, without seeing, or having to know anything about, the underlying data structures in the database. The following diagram shows the role of objects as the mapping layer between a database schema and the Query Panel in BusinessObjects, or the Report Panel in WebIntelligence, that users use to create queries to run against database tables.
Introduction
49
Query Panel in BusinessObjects Report Panel in WebIntelligence
objects
database schema
database
Figure 1-13 Universes: from the document editor to the database
Designers distribute universes to users by exporting them to the repository, or distributing universes through a file system. BusinessObjects and WebIntelligence users can then access the universe in the repository, or from a directory on a file system, to create documents.
BusinessObjects Auditor
BusinessObjects Auditor is a web-based product that allows you to monitor and analyze user and system activity for 3-tier deployments of BusinessObjects, Broadcast Agent Publisher, InfoView and WebIntelligence, and display the results on a user-friendly web interface. This information provides valuable insight into your Business Objects deployment, enabling you to optimize your Business Intelligence solution.
50
Auditor on Business Objects server
Relational databases Business Objects server
Auditor clients
Repository Corporate database
Business Objects users
Figure 1-14 Auditor in the Business Objects system
Auditor enables you to determine who is using a particular Business Objects system, how often they are using it, and what data they are accessing:
Figure 1-15 Analyzing user activity using Auditor
Introduction
51
You can use Auditor to: monitor your Business Intelligence system by examining user activity, access rights, resource information (documents, universes), and system information (such as response time, Broadcast Agent Publisher details, and server load). analyze system trends over daily, weekly, and monthly periods delete or modify unused objects and reports, in order to provide users with easier and quicker access to essential information. accelerate analysis by using the Favorites and Dashboard features, which give you direct access to the queries you want to see. optimize your data warehouse and speed up refresh actions by tracking frequently-used queries. Auditor can help identify situations where aggregate tables or additional indexes can be used. generate new billing opportunities by highlighting the most popular documents
52
The Configuration Tool

The Configuration Tool provides you with the means to configure your 3-tier deployments ORB and third-party components so that a specific set of Business Objects server processes is started by the ASF whenever the node is started. It also ensure that users can access the Business Objects system through client applets or applications such as web browsers, report editors or viewers, 3-tier BusinessObjects, etc.
Figure 1-16 The Configuration Tool
As your deployment evolves, you can use this tool as often as necessary to configure, reconfigure or remove a cluster node, even if the setup is not involved.
Introduction
53
Administration Console
The Administration Console serves as a central control panel for each Business Objects cluster. At any given time it shows you at a glance what servers are running in the cluster, and what modules are enabled on each server. The Administration Console also allows you to enable, disable and define settings for the modules on each server, thereby tuning the solution to optimize its performance.
Figure 1-17 The Administration Console
54
Diagnostics tools
Under UNIX, a set of troubleshooting tools is incorporated in the standard product. These tools can: retrieve critical system data, such as information concerning the operating system, hardware and software configuration check to make sure all required files, libraries and directories are in place and if relevant, correctly configured monitor key system resources collect the critical information you need to provide should you decide to take an issue to Business Objects Support Most of these tools produce both on-screen output and a log file to record the information they collect. For more information, see the UNIX Diagnostics Tools Guide.
Introduction
55
Database Access Packs

With Business Objects, you can retrieve and manipulate data from your existing relational database management system (RDBMS) server. Before you start running Business Objects products, you need to make sure that you have set up the right connections. Connecting with Business Objects is as easy as making sure your RDBMS middleware is installed and installing a Business Objects Data Access driver. Youll need these two components to make a connection between your database and your Business Objects product. Once the connection is made, the user can retrieve data from your RDBMS without having to write a single line of SQL. With this version of WebIntelligence, you can now modify WebIntelligence connection parameters separately from BusinessObjects parameters. For more information about RDBMS connections, see the Data Access Guide.
Security Access Packs

With BusinessObjects Enterprise 6.1, you can manage the identity of your Business Objects users in a corporate LDAP (Lightweight Directory Access Protocol) directory. LDAP allows you to store user information for all your enterprise applications including the Business Objects suite in a single corporate directory, thereby improving scalability, performance and ease of administration. Using an LDAP directory provides new options for authentication, or identifying and giving system access to users, and authorization, or the calculation of specific user rights. Business Objects users who remain in the repository are authenticated and authorized via the repository, as in the regular Business Objects system. Users who are externalized in LDAP, but still remain in the repository are authenticated via LDAP and authorized in the repository. Externalized LDAP users are authenticated in LDAP, but are authorized via a unique process that combines LDAP and the repository. For more information, see the LDAP Access Pack Guide.
BusinessObjects OLAP Connect

BusinessObjects OLAP Connect is a data provider that lets BusinessObjects users access Microsoft SQL Server OLAP Services (MS OLAP Services) and SAP Business Information Warehouse (SAP BW) servers.
Database Access Packs
56
Demonstrations
This category contains a set of demonstrations and multimedia tours: The Demo Kit installs sample universes, databases and reports A set of multimedia quick tours of some of the Business Objects products
Figure 1-18 Entrance point to Business Objects multimedia Quick Tours
Introduction
57
Developer Suite
Developer Suite is a set of programming tools for customizing, extending, and integrating Business Objects products. For example, using Developer Suite programmers can write applications that: manage user sessions create and open documents manage categories build and edit queries view and format reports manage users and groups
Programming languages
The programming language programmers use to access the features of Developer Suite depends on which functions they access and the platform on which their custom application will run. To access the functions of On this operating system BusinessObjects Designer WebIntelligence Server Windows only Windows only Windows only Use And this scripting language JScript JavaScript VBScript Windows and UNIX JSP Report Engine Server Administration Server Windows and UNIX JSP Java Java
VB/VBA VB ASP
Developer Suite
58
How deployment documentation has changed

With BusinessObjects Enterprise 6, the Deployment Guide was extended and reorganized to provide you with more complete and detailed information on deploying the Business Objects solution. To allow you to find what youre looking for more easily in this wealth of information, with version 6.1 we have divided the bulk of the Deployment Guide into two separate guides: This guide, Deploying the Business Objects System, contains the basic conceptual and practical information you need to deploy the system. How the Business Objects System Works contains a functional overview of the system, as well as workflows describing in technical detail how the system handles nearly every type of request. Other chapters in the version 6.0 Deployment Guide have been moved to other guides: Part VI, Securing your System, is now part of the Business Objects Security Guide. Part VII, Customizing your Solution, is now part of Customizing Enterprise 6 Without Programming.
Organization of this guide

This version of the guide has been organized according to the following principles: It first provides the basic conceptual background information you need to understand the Business Objects solution, then provides the practical information you need to actually deploy the system. For those readers who are familiar with previous versions of Business Objects, it provides a synopsis of what has changed with this release concerning a particular functional area. In many chapters, therefore, you will find a section explaining how Business Objects has changed since the last version.
Introduction
59
Some of the new topics included in this guide since version 5.x/2.x are: How to model your systemadvice on answering the following types of questions: how many clusters should you use, how many repositories, where should the security domain and databases be located in a geographically dispersed environment How to set up a pilot deployment environment, then how to migrate to a production environment Supported deployment configurations and how to implement them How various Business Objects products compare functionally The following table summarizes each part of this book and describes the information it covers. Part number and title I Conceptual Overview Type of information Conceptual Description Overview of the Business Objects product line, basic deployment architectures and their CORBA infrastructure, how the system is administrated, and the systems central repository Description of what you need to consider before deploying the solution, including the deployment process, how to model your solution, the choice of platform, and the deployment configurations available to you Overview of everything you need to do to get the system installed and up and running How to create a development deployment then move to a production environment, as well as how to implement your chosen deployment configuration and deploy each component in the Business Objects solution
II Planning your Deployment
Conceptual
III Installing and Configuring the System IV Practical Deployment Specifics
Conceptual
Practical
How deployment documentation has changed
60
Windows and UNIX pathnames

For reasons of simplicity, if the same directory path is valid for both Windows and UNIX platforms, the path is written in Windows notation. This means, for example, that the following Windows path: $INSTALLDIR\nodes\<Machine Name>\<Cluster Name>\temp is equivalent to this UNIX path: $INSTALLDIR/nodes/<Machine Name>/<Cluster Name>/temp
Introduction
61
How terminology has changed

Since the previous release, some of the deployment terminology used in the Business Objects documentation has changed: Term as used in previous releases New term or definition Business Objects Services Administrator Client-server Cluster terminology: Cluster manager Cluster node Administration Console 2-tier Cluster terminology: Primary node Secondary node All nodes in the cluster, including the primary node, are called cluster nodes. Distributed system/solution/ architecture 3-tier system/solution/ architecture The term distributed now refers exclusively to deployments in which processing is distributed over more than one server in the cluster. Enterprise Server Products WebIntelligence system WebIntelligence server Zero Admin BusinessObjects, the zero-administration deployment of BusinessObjects, or ZABO InfoView terminology: Publishing a document Uploading a third-party file Server products Business Objects system Business Objects server 3-tier deployments of BusinessObjects, or BusinessObjects in 3-tier mode InfoView terminology: Saving a document to the repository Adding a third-party file
How terminology has changed
62
Introduction
chapter
64
Overview
This chapter describes the Business Objects system at its most basic level. It covers the following topics: Business Objects can be deployed in 2- or 3-tier environments. This chapter discusses what these architectures mean, the products with which they are associated, and the platforms on which they can run. The basic unit in a Business Objects deployment is called a cluster. This chapter describes what clusters are, and the roles played by their components. The communication both within Business Objects clusters and between clusters and end users is provided through a CORBA architecture. This chapter describes how CORBA works, and how Business Objects interfaces with it for maximum efficiency and stability. Lastly, this chapter summarizes what has changed since version 5.x/2.x in terms of the systems CORBA-related components and how the system uses them. For much more detailed technical information about the system and how it works, see the How the Business Objects System Works guide.
65
Deployment architectures
You can deploy the Business Objects solution in one or both of the following: A 2-tier client-server environment, using BusinessObjects and Broadcast Agent A 3-tier environment, using one or more of the Business Objects server products InfoView, WebIntelligence and Broadcast Agent, as well as a 3-tier deployment of BusinessObjects
2-tier environment
In a 2-tier deployment, Windows applications and connectivities are installed on clients. The application implements all business logic. If you are using BusinessObjects alone, there is no server at all, except a single centralized database server hosting the Business Objects repository. Because the application must be installed and configured separately on each machine, the total cost of ownership is high.
Corporate database
Client machines (full client) Repository
Figure 2-1 2-tier deployment
66
3-tier environment
In a 3-tier server deployment, the Business Objects system is set up on one or more server machines. Users access the system through the client applications InfoView, WebIntelligence, and BusinessObjects (3-tier deployment), using standard web browsers. All of the business logic and connectivities are installed on the servers, not the clients.
Business Objects servers Web server Intranet Application server Repository Database
Users on client machines
Figure 2-2 Simple 3-tier architecture
Using a 3-tier architecture allows for much larger deployments than a traditional architecture can handle. It also reduces the total cost of ownership for large-scale deployments. Any tier can be updated or modified independently of the other tiers. The tiers can also run on different operating system platforms. It provides self-service data access for end users, and high availability and performance. It cuts maintenance and deployment costs by using zero-administration clients (only the deployments servers to maintain).
67
It uses Java applets, which ensures platform independence and low cost of ownership as well as maintaining the intuitive drag and drop interface that full client users are used to. The compact Java applets are automatically downloaded to the thin-client web browser. All processing is carried out on the middle-tier servers. If you distribute components over several servers, you can optimize the use of the server resources, reduce the workload on the web server, and increase performance. This can also provide failure recovery if the components are installed on more than one server, as well as help isolate the processes in case of failure.
Today, the standard Business Objects deployment is a 3-tier one.
68
3-tier architecture overview

A 3-tier architecture is one in which applications are broken up into layers (or tiers). It includes: the client, from which users access the Business Objects system functions the middle tier includes both the web tier and the Business Objects server components the database tier Each of these tiers is described in more detail below. In this architecture, server products share common server resources. These products can be installed either on a single physical server, as is often the case in UNIX deployments for example, or distributed over several servers in what we refer to as a distributed deployment. In this case, Business Objects modules, or processes, can run on different machines, and the system automatically recognizes all the machines in the system, as well as the distributed services at runtime. Whether the 3-tier solution is deployed over a single machine or over several, the set of server nodes hosting Business Objects components is called a cluster. For more information, see page 82.
69
Here is an illustration of the three tiers in this type of architecture:

Client InfoView, WebIntelligence, BusinessObjects in web browser
Client tier
HTTP Application server
Presentation layer
Web server ASP/JSP pages ASP/JSP engine
Middle tier
API proxy
IIOP
Processing layer
Business Objects Processing components API
Functional services Local storage and system caches
Database tier
Data server Repository
Figure 2-3 Business Objects system 3-tier architecture
70
The client
Users access the Business Objects system through a portal which provides them with personalized access to their organizations information capital. This portal is provided by the InfoView client:
Figure 2-4 Example InfoView home page
Through this portal, accessed through a standard web browser, users can view, refresh and distribute all the documents to which they have access rights. They can also access WebIntelligence and BusinessObjects in 3-tier mode. A Business Objects deployment can contain several portals, depending on its size, complexity and geographical distribution. There is no client-side administration of the Business Objects system. No middleware is required on the client, and for InfoView and WebIntelligence client use, no application software is installed. For BusinessObjects in 3-tier mode, client software is installed and used to create and edit documents, but all connectivity is provided by the server components in the middle tier. By contrast, in a 2-tier deployment, the BusinessObjects client is the Windows application (BusObj.exe) that runs on the users desktop. This application gives users the ability to access a repository of universes and BusinessObjects documents, and to retrieve data from databases.
71
The middle tier

The middle tier includes both the web layer and the business layer. Together they communicate with the other tiers to handle security and connectivity information and handle all the processing of requests coming from the client. This tier also provides programming access to the systems server components for developers who want to customize the solution.
The presentation layer

The presentation layer contains the web and application servers used to generate the HTML and DHTML used in InfoView and WebIntelligence. It also contains all the communication and data translation layers that enable lightweight components to communicate with the system using the standard web HTTP protocol. The web server stores static web pages like document lists, and bitmaps used in InfoView. It also serves as a router relaying requests from the client to the application server and beyond to the Business Objects cluster. The application server processes dynamic pages and hosts the active components which accept requests from clients then route them to the Business Objects processing layer for processing.
The middle tier
72
Client computer WebIntelligence applet
Web browser 3-tier BusinessObjects
Web server
Static files Static HTML pages and bitmaps
HTTP server routing
Application server WebIntelligence servlet
WebIntelligence JSP pages REBean
InfoView JSP pages HSAL/JHSAL WIBean
Business Objects processing components
Figure 2-5 The web and application servers
For detailed background information on the role of the application and web servers in the Business Objects system, see How the Business Objects System Works. ASP or JSP? The Business Objects system supports both IIS and J2EE application server technologies (although not on the same server). The type of application server being used dictates the technology of Business Objects presentation layer components that are used: ASP pages and COM components (WICOM, RECOM) run on Windows IIS web/application servers JSP pages and Bean components (WIBean, REBean) run on J2EE application servers For more detailed information, see How the Business Objects System Works.
73
The Business Objects processing layer

The Business Objects processing components constitute the operational arsenal of the Business Objects server products. Called modules when they can be administered, these processes handle: user login and authentication, checking with the Business Objects central repository the creation and cessation of all Business Objects user sessions, and track all user activity from the time users log in until they log out the generation of document lists the creation, processing, distribution, storage and caching of BusinessObjects, WebIntelligence and third-party documents The client applications access these processing components through APIs (WIReportServer, WIAPIBroker) and interface components (WIDispatcher) hosted within the cluster. The processes in this layer can be divided into two categories: those which provide a framework of services to document processing components the processing components themselves
NOTE
You can find detailed information about how all these processes work together for each type of Business Objects transaction, in How the Business Objects System Works.
74
Application services components Application services components include the following processes: Component Description
Connection Server Connectivity layer used to control execution of SQL requests. Used by WebIntelligence and WILoginServer. WILoginServer Audit Server WISessionManager Speeds login process by providing a cache for repository security. Works with Connection Server. Writes records of 3-tier user activity for Auditor and into the Audit database. Creates and manages InfoView user sessions. With BusinessObjects Enterprise version 6.1, this process is part of the session stack, and therefore is enabled on each node in the cluster. Manages the systems cache and personal document storage areas. Business Objects systems must have at least one, but may have several WIStorageManagers. Provides an application programming interface for managing Business Objects web security. You can use Administration Server to create and delete users and groups, to add users to groups or to set user profiles, from an external application created using Business Objects SDKs.
WIStorageManager Administration Server
75
Business Objects processing components The Business Objects 3-tier system includes many of the same system components in previous versions of the Business Objects system. They include: Component WIDispatcher Description Used in 3-tier deployments of BusinessObjects and for displaying WebIntelligence 2.x documents, the WIDispatcher receives a translated request from the HSAL/ JHSAL and decides which process the request should be sent to. Launches and manages a pool of BusinessObjects processes via OLE Automation under Windows (local calls only), and CORBA under UNIX. It also manages multitasking and maintains user context. BusinessObjects processes (BusObj.exe under Windows and bolight under UNIX) are the components used to process BusinessObjects documents. One session is launched per job. This differs from accessing or refreshing WebIntelligence documents, where one session is launched per user. WIReportServer WIQT Report engine that processes WebIntelligence 6.x documents. This process has several functions, each of which has been given its own name: It handles all document exchange with the repository and the system caches. This set of functions is known as WIQT Repository Access. It serves as a report engine for processing WebIntelligence 2.x documents and manages the processing of BusinessObjects documents via BOManager. This is called WIQT Report Engine. It serves as an SQLBO proxy for BusinessObjects in 3tier mode, running SQL requests sent by the HTTP protocol. This is called WIQT SQLBO. Each WIQT process is dedicated to a single InfoView user session; each user session therefore has its own dedicated WIQT.
BOManager
The middle tier
76
Component Scheduler
Description Working with Broadcast Agent, the Scheduler periodically polls the repository to detect tasks to run. It then communicates with BOManager (for BusinessObjects documents) and calls a WIQT or WIReportServer for document processing. Provides the server interface for calls from the InfoView ActiveX viewer and BusinessObjects in 3-tier mode. It receives calls from the client via WIDispatcher, which are then passed to BOManager to process full client documents for ActiveX viewer WIQT to process document exchange and SQL orders Used at the application server level, acts as the interface between the client and the business processing (middle tier) layer. It is the gateway for InfoView and WebIntelligence 2.x document processing, called each time an ASP/JSP page invokes the WICOM/WIBean component. WIAPIBroker interacts with: WISessionManager for session creation WIQT for document and list processing WIStorageManager for cache data
WIADEServer
WIAPIBroker
BusinessObjects processes WIQT_batch BOL_batch WIReport Server_batch
Acting as report engines for BusinessObjects documents, these processes are called BusObj.exe in Windows and bolight in UNIX. A WIQT that permits batch WebIntelligence 2.x document processing by Broadcast Agent. A UNIX process used for batch processing with Broadcast Agent. A report engine for processing WebIntelligence 6.x documents in Broadcast Agent.
77
Database components
The data server tier contains repositories and corporate databases: A Business Objects repository contains user profiles, documents and universe definitions. A universe is the business-intelligent semantic layer that maps to data in the database, in everyday terms that describe your business situation. Users create BusinessObjects and WebIntelligence documents using a universes objects and classes which map to the required data in the corporate database. See the Designers Guide for more information on universes. A deployment can have more than one repository. For more detailed information on repositories, see The Repository and Security on page 117. A corporate database is a source of the actual data used in BusinessObjects and WebIntelligence documents.
Database components
78
What products are associated with each architecture?

Within each environment, you can deploy Business Objects products in different ways and combinations. The following tables list a variety of deployment types as well as the products needed to create the architecture. Designer and Supervisor are not included in these charts but are needed to deploy all architectures.
Types of 2-tier deployments and associated products

Deployment type Standard BusinessObjects in 2-tier mode Standard BusinessObjects in 2-tier mode with scheduling support Product(s) BusinessObjects on each workstation BusinessObjects on each workstation, Broadcast Agent on the server
79
Types of 3-tier deployments and associated products

The following table lists deployment types and their associated products: Deployment type WebIntelligence document display and interactive refresh only WebIntelligence document display and interactive refresh, with scheduling support BusinessObjects document display and interactive refresh only BusinessObjects document display and interactive refresh with scheduling support BusinessObjects document access, refresh and editing WebIntelligence and BusinessObjects document display and interactive refresh WebIntelligence and BusinessObjects document display and interactive refresh, with scheduling support
NOTE
Product(s) InfoView, WebIntelligence InfoView, WebIntelligence, Broadcast Agent InfoView InfoView, Broadcast Agent BusinessObjects in 2- or 3-tier mode, InfoView (to download 3tier BusinessObjects) InfoView, WebIntelligence, BusinessObjects in 2- or 3-tier mode InfoView, WebIntelligence, BusinessObjects in 2- or 3-tier mode, Broadcast Agent
In any deployment processing BusinessObjects documents, BusinessObjects in 2-tier mode is not actually part of the 3-tier system. It resides on separate client machines which save BusinessObjects documents to the repository. Once these documents are stored in the repository, they are accessible to InfoView and BusinessObjects users using the 3-tier system.
What products are associated with each architecture?
80
Functional deployment examples To allow users to create and interactively refresh both WebIntelligence and BusinessObjects documents, the deployment must include InfoView, WebIntelligence and 2- or 3-tier BusinessObjects. A deployment that permits users to access, refresh, and schedule both WebIntelligence and BusinessObjects documents from their browsers must include InfoView, WebIntelligence and 2- or 3-tier BusinessObjects. Any deployment requiring scheduling support must include Broadcast Agent.
81
What platforms are associated with each architecture?

Business Objects server products can run on Windows as well as a variety of UNIX platforms including Sun Solaris, IBM AIX and HP-UX. 2-tier Business Objects deployments are exclusively Windows-based. The client application BusinessObjects is a Windows process called BusObj.exe that cannot run on any other platform. A 3-tier architecture, however, allows you to use Windows or UNIX servers.
What platforms are associated with each architecture?
82
What is a cluster?
Clusters are the basic unit in a 3-tier Business Objects solution. A cluster is the node or set of nodes that collectively provide the functional operation of a given portal. Clusters can contain the following elements: The primary node serves as the central coordinator between all the nodes in the cluster. There is one and only one primary node in a cluster; if the cluster contains only one node, it is a primary node. Optional secondary nodes run the ORB components required to communicate with the primary node and start Business Objects processes on the secondary node, as well as optional services. Both primary and secondary nodes are considered cluster nodes. Under Windows, only one node can be configured per server machine. Under UNIX, multiple nodes can be hosted on a single machine, as long as each of them belongs to a different cluster.
Users on client applications Application server Web server Network Business Objects primary node
Secondary node
Figure 2-6 A Business Objects cluster
Because the application server uses CORBA to communicate with the clusters API and interface components, the application server is also considered to be part of the cluster.
83
What is the primary nodes role?

The primary node performs the following services: It tracks and manages processes throughout the system using WIClusterManager. It records various system and user activities. The primary node occupies a critical position in the Business Objects system. Should it fail, the entire system needs to be stopped and restarted.
NOTE
In previous releases, the clusters single WISessionManager was required to be enabled on the primary node. With BusinessObjects Enterprise 6.1, WISessionManager is enabled on each processing node in the cluster, thereby removing it as a single point of failure.
What is the secondary nodes role?

Secondary nodes rely on the primary node to provide the infrastructure required to allow multiple servers to work together. You can configure a secondary node to run only a subset of the full complement of Business Objects modules using the Administration Console. The Console allows you to tailor the structure of your system and more efficiently serve the needs of your users. For example, if you find that the load on a particular type of server process within the system is high, you can dedicate a machine to just that process.
What is a cluster?
84
Why use distributed configurations?

The distributed object technology underlying the Business Objects system provides scalability and flexibility because components of the Business Objects middle tier can either run on a single machine or be distributed across multiple machines in the cluster. The systems distributed component architecture provides three major benefits: Failover A distributed system can also provide failure recovery: when system components are installed on more than one server, if a server stops working, the system can continue to use the same required components on other servers. Scalability User populations using this type of Internet technology can be much, much larger than we have traditionally seen. As the document processing needs and the user population in your organization grow, you can manage the extra workload simply by adding servers to the system. Load balancing When you have enabled multiple instances of certain key Business Objects modules over several nodes, the distributed system automatically performs load balancing across component servers. You can also weight the transaction loads to optimize the use of more or less powerful processors, thus optimizing the use of server resources, reducing the workload on the web server, and improving performance. All of these advantages are made possible by the use of CORBA and the Business Objects Application Server Framework, or ASF.
85
What is CORBA?
The Common Object Request Broker Architecture (CORBA) is an architecture which allows applications to communicate with one another no matter where they are in a network, or who manufactured them. CORBA communication is provided through vendor-dependent middleware called the Object Request Broker, or ORB. The ORB establishes the client-server relationships between objects (services or processes) which allow it to route requests from clients to objects, then route responses from objects back to their client. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine, or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client doesnt need to know where the object is located, its programming language, its operating system, or anything other than the object's interface. The ORB can therefore provide interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnect multiple object systems.
1. The client requests an object.
Client 3. The ORB returns the results to the client.
Object Request Broker
2. The ORB locates the object on one of the servers connected to it, and implements the request.
Servers
Figure 2-7 How the ORB works
What is CORBA?
86
Clients and servers communicate using a subset of the General Inter-ORB Protocol (GIOP) on TCP/IP called the IIOP (Internet inter-Orb Protocol). This type of CORBA architecture was first introduced in the Business Objects solution with the first release of WebIntelligence 1.0. Since then, this infrastructure has become the basis of the entire Business Objects system.
87
The Application Server Framework

The ASF simplifies and standardizes the behavior of CORBA servers, and provides additional benefits such as improved load balancing and failover. This light application server: encapsulates all calls to the ORB in a single abstraction layer manages the object life cycle, handling creation, activation, registration and deactivation manages the distribution of objects between the nodes in a cluster improves load balancing and failover provides an interface for administering cluster nodes and their objects The ASF is started and stopped when the node on which it resides is started and stopped.
The container/component model

The ASF is based on a simple CORBA container/component model. In this model, CORBA components run inside containers hosted on the application server. These containers act as the interface between the components and client requests. To communicate with a component, clients access the container hosting the component, and it is the container which in turn invokes the components methods.
Application server 1. The client invokes the required components container. Container Component
Client 2. The container invokes the components methods.
Figure 2-8 The CORBA container/component model
88
Within the ASF: Server objects such as the Business Objects processes, are viewed as components, and the ASF acts as the container hosting those components. The ASF encapsulates all the ORBs object activation and lifecycle mechanisms through a set of predefined methods (internal interface) and callbacks (callback interface). The internal interface controls all interactions with the POA, managing the server objects life cycles, and manages all communication with the container. The callback interface lets the ASF notify servers and objects of events in objects life cycles. Through the ASFs client interface, clients use the ASF to locate the objects they need. The ASF therefore acts as a gateway to the CORBA naming and trading services. Once the object is located, the client uses the objects IOR to request the object, directly invoking the objects own methods as exposed through the objects external interface.
Client External interface Business Objects server objects treated as ASF components
ASF container ASF client interface Internal interface APPLICATION SERVER FRAMEWORK ORB Callback interface
Figure 2-9 How the ASF works
The Business Objects system therefore accesses the ORB through the ASF.
89
ASF daemons
The ASF has its own daemons: This daemon... WIProcessManager Does this... Manages the Business Objects systems process lifecycle. For more information, see the following section. Launches and monitors WIProcessManager and CORBA processes. If any of these processes fails, the ASF Guard restarts it.
ASF Guard
The importance of WIProcessManager The WIProcessManager: manages cluster activity (active/inactive nodes, previously handled by WIClusterNode/WIClusterManager) starts and stops Business Objects processes and monitors their activity by restarting them if they fail handles load balancing (previously handled by WIGenerator and restricted to WIQT, now extended to all modules through the nodes Node Weight parameter) manages all Administration Console workflows (previously routed through WIClusterNode/WIClusterManager) creates and manages the WIQT process pool. This pool contains a set of preregistered WIQT processes, which are allocated to a unique WIQT session. Each WIQT manages a single session. When this session is created, a WIQT process is reserved in the pool and declared in the ORB. When the WIQT process terminates, the context is released, put back into the pool, and reallocated to another process.
90
The number of processes in the WIQT pool is indicated in the localnode.xml file. You can modify this number in the Administration Console:
Figure 2-10 Setting the number of WIQT processes
WIProcessManager also manages bolight registration/activation/shutdown under UNIX.
How the ASF improves fault tolerance

CORBA ensures fault tolerance for persistent objects. In CORBA, persistence means that if an object is removed from memory, or if the container hosting the entity dies, the entity is recreated with the same object ID at the first request. ASF services (nearly all Business Objects processing modules) and entities are persistent objects. This means that if the server hosting these objects crashes, the ASF automatically reactivates the objects with the same object ID and on the same machine, at the first client request. Furthermore, all references to persistent objects stay valid, but the object context is reinitialized if it has not been saved.
How the ASF ensures failover

The ASF Guard process running on each node of the cluster guarantees perfect CORBA process failover. It monitors CORBA processes and relaunches them if they or the computers hosting them crash.
91
How the ASF enhances load balancing

In previous versions of Business Objects, administrators could set a parameter for the WIGenerator module called the Node Load Factor. This allowed you to weight the transaction load of the WIQT processes for a specific server dynamically. For example, if a particular cluster node machine was much more powerful than other nodes in the cluster, you could make sure it received more WIQT processes by giving it a higher Node Load Factor than the other machines in the cluster. Likewise, if one machine was particularly restricted, by giving it a low Node Load Factor, you could make sure it did not penalize the entire system.
When a new user session started, instead of automatically sending the new transaction to the node running the fewest transactions, the WISessionManager sent it to the machine whose current session count/Node Load Factor ratio was the smallest. This was called the load ratio.
With this release, the ASF extends this load balancing mechanism to the processing load for the entire server. It is now called the node weight. For more information on setting this parameter, see the System Administrators
Guides.
92
ASF configuration
You configure the ASF/ORB using the Configuration Tool.
Figure 2-11 The Configuration Tool
This tool handles all the post-installation tasks you need to configure web and application servers, Business Objects servers and clusters, and all other system components you need to get your system up and running. You can launch this tool either directly from Business Objects installation, or as an independent application. For complete information, see the Installation and Configuration guides. Configuration information is contained in a script, which the Configuration Tool launches once you are finished. This script: creates the ASF configuration file configures Orbix 2000 using the Orbix configuration tool in command line mode sets the Orbix environment
93
You can find detailed information on using the Configuration Tool in the Installation and Configuration guides. For an overview, see Configuring the server system on page 270.
94
Changes in architecture and communication

How has the system architecture and CORBA communication changed with BusinessObjects Enterprise 6?
95
What has changed What is was Business Objects architecture and terminology Communication between all Business Objects server components was provided by a CORBA-compliant object request broker called Visibroker.
What it is now Communication between all Business Objects server components is provided by: The new CORBAcompliant object request broker Orbix 2000 The ASF (Application Server Framework) that encapsulates Orbix 2000 and provides the communication framework for Business Objects modules. The name has been changed to primary node and secondary node to adapt to ASF terminology. The functions are still primarily the same. Pools of multi-instance modules are created at system startup, ready to be used as requests come in.
The main node in a cluster was called cluster manager and the other nodes were called cluster nodes.
New instances of multiinstance modules were registered and started as requests for them were received.
Visibroker configuration In Orbix 2000, this required a server parameter parameter no longer exists. called the OSAgent Port. It has been replaced by a set of ports and a cluster name that are required to configure Orbix 2000. Visibroker relied on two processes: oad and osagent. These processes no longer exist. They have been replaced by the Orbix 2000 processes: itconfig_rep, itttrader, itnaming, itnode_daemon, and itlocator.
Changes in architecture and communication
96
What has changed What is was Obligatory system In version 5.x/2.x of the components Business Objects suite, application servers were required only when customized applications were being used.
What it is now With this release, the standard Business Objects suite uses JSP or ASP and therefore a third-party application server is required as part of the system to interpret the calls.
How the System Is Administered
chapter
98
Overview
Administering the Business Objects solution includes tuning the modules on specific cluster nodes, starting nodes and whole clusters and monitoring the activity of the system and its users. You can do all this using the Administration Console. This chapter describes: the processes underlying the Business Objects administration layer what the Administration Console looks like and what you can do with it the systems configuration files and where they are located how you administer Broadcast Agent how you administer the systems audit facility and Auditor application what has changed in administration since the last release
NOTE
This chapter provides just an overview. For complete information about administering Business Objects clusters and modules, see the System Administrators Guides.
99
The systems administrative layer components

As described in Chapter 2, the Business Objects 3-tier systems processing layer is provided by the set of processes installed and enabled on nodes within the cluster. Each machine also hosts a central component to start these processes and provide administration features. The administrative layer is primarily server-side, except for the Administration Console client component. Although some components are platform-specific, the administration layer is designed as a cross-platform framework. Heres a quick reference to the executables in the administrative layer:
Executable Description
WIOrb (UNIX)
WIOrb is responsible for starting and stopping both the ORB and the Business Objects processing components on a node. This process is used as an external tool by the site manager to get the list of Broadcast Agents from the repository when needed. It provides all Business Objects security-compliant features.
WIAdminBOTools
The systems administrative layer components
100
Executable
Description
WIAdmToolStop
This additional tool is involved when server products have to be stopped on a machine. Depending on the machine type (primary or secondary node), the WIAdmToolStop component connects to the site manager or machine manager and requests shutdown operations. Note: On Windows platforms, the Wimanager stops services by starting WIAdmToolStop.
WISiteLog
This process provides a server object for auditing features, registered with the ORB. It runs on the primary node machine. The audit object lets you log events in text files or in a database through a Business Objects securitycompliant connection.
WINotify
A Windows graphical tool hosted by the task bar, providing: The immediate status of the Wimanager Product start / stop on the machine A link to administration help A link to the Administration Console Product version information
101
The Administration Console

The Administration Console acts as a control panel for overseeing a Business Objects cluster. Powerful and easy-to-use, the Administration Console lets you monitor and control all the servers and modules in your system from a single machine, regardless of how many servers are part of your 3-tier configuration: It gives you a birds-eye view of the real-time status of each server machine and module in your system. It allows you to enable and disable both individual modules, and the set of base modules called the session stack, required for processing during each user session. This allows you to start and stop a distributed system from one place. It lets you set module parameters. You can also use it to trace various types of activity in the system. Although some administrative tasks are required before you can use the system, you can and certainly will repeat them regularly the system is used. As you discern user habits and performance bottlenecks, you will use the Console to tune your system to perform at its best under every type of circumstance.
Session stacks
In past versions of Business Objects, the processing of client requests in the same InfoView user session could be distributed over several machines in the cluster, using the CORBA communication protocol. With BusinessObjects Enterprise 6.1, this processing is speeded up by having all of the requests for a single user session processed by modules on the same cluster node. These modules include: WISessionManager This breaks with previous enablement rules, in which only one WISessionManager could be enabled per cluster. WIAPIBroker WIQT (there is a pool of these processes) WIReportServer WIDispatcher WIADEServer BOManager (and its pool of BusObj/bolight processes)
102
This set of modules is called the session stack. Administrators start or stop all these modules at the same time, simply by clicking a single Disable/Enable button in the Administration Console. If the session stack is not enabled on a node, the node cannot process user requests. The following Business Objects modules do not belong to a nodes session stack, and therefore can be started and stopped individually: WILoginServer WIStorageManager Broadcast Agent Manager Administration Server When do session stacks not have to be enabled? The session stack does not have to be enabled on a cluster node when: the node hosts client applications of WebIntelligence SDK such as Business Objects Application Foundation, Dashboard Manager, or WebIntelligence for OLAP Data Sources only. In this scenario, the machine is configured as a cluster node, but in order not to slow the machine down, all document processing is handled by the session stacks on the other nodes in the cluster. the node is used exclusively for the execution of SQL requests toward a specific database. In this case, again, the machine is configured as part of the cluster, with Connection Server enabled on it. Session stacks are enabled on other nodes in the cluster, which in turn are clients of the node dedicated to database access.
103
The Console interface

The Administration Console looks like this:
In the view above, you can see at a glance which modules are running on the cluster server, as well as the language the cluster is using. You can also access a list of all the users currently logged into the system. You can enable and disable each cluster nodes session stack, as well as other, individual modules on the server, or shut down the server altogether. Other views in the Console allow you to administer and tune the system by enabling, disabling and configuring specific modules on specific nodes in the cluster. For example you can set how and when a module launches processes, the maximum number of active documents allowed, the number of documents that may be concurrently open, the maximum number of processes, and so on.
104
Types of Administrator Console

The Administration Console comes in two forms: as a Java applet which the Business Objects administrator accesses through a standard web browser as a standalone Windows application (administrator.exe) available from the Windows Start menu This program makes direct calls to a Java virtual machine (Java 2) running the Java Administration Console applet described above. This application is used in deployments containing 2-tier deployments of BusinessObjects and Broadcast Agent only, which do not use a web server.
Who can use the Administration Console?

Because administration tasks represent critical server operations, only the Business Objects systems administrator, with specific rights within the Business Objects system, can use the Console. With this release, administrators log into the Administration Console through a new mechanism, WILoginServer. This provides tighter and more detailed control over the people who use the Console, and what they can do with it.
Types of administration
Administration tasks can be classified in four different groups: Some administration tasks impact the entire cluster. Cluster administration includes enabling and disabling cluster nodes and changing a clusters language. The disabling and enabling of session stacks on each node in the cluster. Module administration includes configuring, enabling and disabling modules on specific nodes. Session administration includes monitoring the users logged into the system at any time, and ending user sessions when necessary. This type of fine-tuning allows you to tailor your system to meet your user populations requirements in the most efficient way. For example, you can adapt the transaction load for a module on a certain node to take into account the power of the server hosting it. If the server machine is particularly powerful, you can direct the system to send proportionately more specific types of requests than other, less powerful servers.
105
Administering Broadcast Agent

With this release, the term Broadcast Agent is used to designate two Business Objects server products: Broadcast Agent Scheduler and Broadcast Agent Publisher. Because Broadcast Agent covers two different functional areas, the Business Objects system provides two tools for administering it: The product itself relies upon a set of processes within the Business Objects 3-tier system. You can administer these processes using the standard Administration Console. When BusinessObjects in 2-tier mode and/or InfoView users schedule documents with Broadcast Agent for automatic refresh and distribution, each request is called a task. Administrators can monitor and modify various aspects of these scheduled tasks using the Broadcast Agent Console.
NOTE
For complete information concerning Broadcast Agent administration, see the Broadcast Agent Administrators Guide.
Tuning Broadcast Agent components using the Administration Console

The Broadcast Agent system depends upon the following Business Objects modules: Broadcast Agent Manager Schedulers BOManager BusObj (Windows) and bolight (UNIX) processes WISessionManager WIQT (Windows) and wiqt (UNIX) processes You can create Schedulers and tune all these processes using the Administration Console.
106
EXAMPLE Using the Administration Console to tune Broadcast Agent components
Schedulers check the repository at regular intervals for documents flagged for scheduled processing. When a document is due to be processed, they signal the local CORBA daemon to signal a BOManager or WIQT on the first available machine to process the document. You can determine how frequently the Scheduler queries the repository by setting the Scanning Repository Delay parameter for the Broadcast Agent Manager on which the Scheduler runs. When a scheduled task is due, the Scheduler sends the task to the required process on the least busy machine. You can make sure more processing is done on more powerful machines by adjusting the Node Weight for the relevant modules on those machines. This weights the systems default load-balancing algorithm. If a task fails, the Scheduler automatically tries again after a length of time set using the Delay between retry parameter for each Scheduler.
The Broadcast Agent Console

Once BusinessObjects and/or InfoView users have scheduled documents for automatic distribution with Broadcast Agent, you can monitor this activity with the Broadcast Agent Console.
Figure 3-2 The Broadcast Agent Console
107
This simple tool connects with the repository to check for all tasks flagged as being scheduled for processing. The Console displays information about these tasks, and can also be used to modify tasks. For example, you can cancel a task or reschedule it for a different time. Using the Broadcast Agent Console, you can: manage task status, for example by cancelling a task that is blocking the server modify task properties, for example by adding or removing users on the distribution list customize Console display, for example by removing from the display those documents which Broadcast Agent has successfully processed
108
Monitoring and analyzing system activity

The Business Objects system provides you with several ways of monitoring all the requests and processes passing through the 3-tier system, coming from InfoView, WebIntelligence, Broadcast Agent and BusinessObjects, including a variety of log files and an Audit facility.
Administering the Audit facility

The Audit facility tracks critical information relating to user and system activity and places it in the user.log file, or a relational database where it can be accessed with Business Objects products. This information includes the duration of a users request as well as the time the system takes to respond. In this way, you can determine how many users were active at any given time, and thus check the number of concurrent users in the system (that is, users who are making the server work as opposed to the users who are merely logged in). You use the Administration Console to enable and disable the Audit facility, and to specify whether the audit information is stored in a database or a flat log file:
Figure 3-3 Administering the Audit facility in the Administration Console
109
Administering Auditor
BusinessObjects Auditor uses the information stored by the Audit facility in a database to monitor and analyze user and system activity for all Business Objects server products, displaying the results in a web interface.
Figure 3-4 Auditor web interface
As the Auditor administrator, you not only have to set up, configure and maintain Auditor to work correctly with the Business Objects 3-tier system, but you also: manage user access rights through Supervisor manage the universes Auditor users use, through Designer manage the set of predefined indicators, or special Auditor documents, and optionally create new ones for use by other users in the company It is also recommended that you build a separate repository for Auditor. For more information, see Deploying Auditor on page 409. For complete information about administering Auditor, see the BusinessObjects Auditor Guide.
Monitoring and analyzing system activity
110
How administration has changed

This section provides a brief description of the broad changes between version 5.x/2.x and this release concerning administration of the Business Objects system:
111
What has changed Business Objects architecture and terminology
What is was Communication between all Business Objects server components was provided by a CORBA (Common Object Request Broker Architecture)compliant object request broker called Visibroker.
What it is now Communication between all Business Objects server components is provided by: The new CORBA-compliant object request broker Orbix 2000 The ASF (Application Server Framework) that encapsulates Orbix 2000 and provides the communication framework for Business Objects modules The name has been changed to primary node and secondary node to adapt to ASF terminology. The functions are still primarily the same. Pools of multi-instance modules, such as WIQT and BusinessObjects processes, are created at system startup, ready to be used as requests come in. In Orbix 2000, this parameter no longer exists. It has been replaced by a set of ports and a cluster name that are required to configure Orbix 2000. These processes no longer exist. They have been replaced by the Orbix 2000 processes: itconfig_rep, itttrader, itnaming, itnode_daemon, and itlocator.
The main node in a cluster was called cluster manager and the other nodes were called cluster nodes. New instances of multi-instance modules were registered and started as requests for them were received.
Visibroker configuration required a server parameter called the OSAgent Port.
Visibroker relied on two processes: oad and osagent.
112
What has changed
What is was The processing of client requests in the same InfoView user session could be distributed over several machines in the cluster, using the CORBA communication protocol.
What it is now With version 6.1, processing is speeded up by having all of the requests for a single user session processed by modules on the same cluster node. These modules include: WISessionManager This breaks with previous enablement rules, in which only one WISessionManager could be enabled per cluster. WIAPIBroker WIQT (there is a pool of these processes) WIReportServer WIDispatcher WIADEServer BOManager (and its pool of BusObj/bolight processes)
WISessionManager was enabled With version 6.1, on only one node in the cluster. WISessionManager is enabled on all nodes used for system processing. At login, WIQT: With version 6.1, created the session directory WISessionManager assumes all these responsibilities. at session creation, then set the sessions environment copied the .key and .lsi files contained the sessions timeout mechanism cleaned up the session directory and removed it once the session was terminated
113
What has changed Administrative layer components
What is was
What it is now
Requested shutdowns were WIAdmToolStop no longer managed by the WIAdmToolStop exists. Its functions are handled process. by WIProcessManager. WIKill was used to destroy server WIKill no longer exists. Its processes when ORB functions are handled by components crashed and WIProcessManager. registered servers had to be killed. WIOrb was used to start/stop the CORBA layer and the Business Objects processes. Under UNIX, it was also used to access the boconfig.cfg file. The system is now started under Windows by WIProcessManager. Under UNIX, WIOrb no longer starts/stops processes, but it is still used to access the boconfig.cfg file. $INSTALLDIR\bin\ administrator.exe
The location of the Administration Consoles executable under Windows
$INSTALLDIR\server\system2.5\ bin\administrator.exe
114
What has changed Administration Console
What is was
What it is now
The tool was called the Business The tool is now called the Objects Services Administrator. Administration Console. The Administration Console contained: Information Action bar View pages They have been renamed: Top bar Module pages
No Logout and About box features A Logout and an About box were provided. button have been added to the top bar. The Monitor one more Broadcast Agent on and Stop Monitoring a Broadcast Agent on buttons were used to create and delete a Scheduler. You could enable or disable the Broadcast Agent Manager module. These buttons no longer exist. They have been replaced by the buttons: Add Remove The Enable/Disable button no longer exists. It has been replaced by the buttons: Start all Stop all With version 6.1, these processes are part of each nodes session stack, which is enabled or disabled as a single component.
You could enable or disable WISessionManager, WIAPIBroker, WIReportServer, BOManager, WIADEServer, WIQT and WIDispatcher separately.
115
What has changed
What is was
What it is now This component no longer exists. Its functions are now handled by the application server. WIGenerator no longer exists. A new WIQT module manages the Max active time and Max inactive time parameters.
Administrated modules The system contained the WIHSALManager module.
The system contained the WIGenerator module. This module managed the WIQT processes and its parameters Max WIQT active time Max WIQT inactive time Node Load Factor was a WIGenerator parameter. N/A
It has been replaced by Node Weight, a host parameter. New modules have been added: Administration Server WILoginServer WIReportServer You now enable/disable a nodes entire session stack instead of separately enabling/ disabling its component modules (BOManager, WIADEServer, WIAPIBroker, WIReportServer, WIDispatcher, WIQT, WISessionManager). With version 6.1, the authentication method is a WILoginServer parameter. Authentication choices include all previous choices, plus External authentication, which allows administrators to use an external LDAP directory for authentication and authorization.
N/A
You set the systems authentication method as a WISessionManager parameter. Authentication choices included: BusinessObjects standard Windows authentication Basic authentication No authentication
116
What has changed Administration tasks
What is was The cluster's language could be changed.
What it is now You can change the cluster's country and charset.
Events from only one cluster at a Multi-cluster auditing is time could be saved in a database possible. for auditing purposes. You could activate an internal trace for the modules: WIGenerator WIDispatcher WISessionManager The same audit database could not be used for more than one cluster manager. The internal tracing facility no longer exists. It has been replaced by an external tracing method. The Business Objects system supports multi-cluster auditing.
The Repository and Security
chapter
118
Overview
The repository is a database that is stored in a relational database management system. The repository is used by different Business Objects applications to: secure access to your data warehouse provide a deployment infrastructure for Business Objects applications Your deployment relies on the power of the repository to support the advanced features of the Business Objects solution. This chapter describes: which Business Objects components access the repository the repository domains and how Business Objects clients know where to access them why you might want to use multiple repositories how to choose a repository database which will allow you to get the most out of your Business Objects deployment how you can work with or without a repository compatibility issues you may encounter with this version of the repository This chapter also provides a broad overview of other security issues, such as: Authentication and authorization Common network and system security techniques
REMINDER
The repository is a separate entity from the database containing the corporate data your users will display and analyze in documents they create using Business Objects.
119
Data security through the repository

Security is an increasingly important issue in todays organizations. Implementing and maintaining security for a large number of users can be a costly operation, and has implications for long-term deployment requirements and user functionality. Business Objects has placed equal importance on the ability to protect the security of data and on the empowerment of users to access, analyze and share it. One of the main strengths of the Business Objects product suite is the range of security options and capabilities provided by the centralized repository. Because security can be applied within universes at the user and group levels, Business Objects can meet the security needs of most types of organizations.
NOTE
You may want to build on these basic security options by incorporating broader security measures such as firewalls, which filter the requests leaving and coming into your system from the outside. For more information on this and general network and system security, see the Business Objects Security Guide.
Data security through the repository
120
The role of Supervisor and Designer in security

The Supervisor application manages a major part of Business Objects security. It provides an easy to use graphical interface by which you can set up and maintain a secure environment for users. It also provides a powerful and easy to use structure for distributing information to be shared by all users. This information is centralized in Business Objects repositories. With Supervisor, you can define users and user groups as well as assign profiles to them. You can control user access to Business Objects products, and manage the exchange and distribution of the universes and documents of all users. Supervisor also lets you manage your company as groups of users with profiles that you determine. User profiles include user identification (user name and password), the products and modules they can work with, the universes they can access, and the documents that they can share. Once you have defined such profiles for all the users in your company, you can use Supervisor to manage repositories and data accounts. The supporting role in Business Objects security is played by Designer. It allows you to: Restrict a universe object so that only end users with the appropriate security access level can use it. In this way, you can prohibit certain end users from viewing information of a sensitive or critical nature. Impose joins on tables for security reasons
121
Repository domains
The repository consists of several domains. Each repository includes one security domain, as well as one or more universe and document domains.
Corporate database
Universe domain (semantic layer) Designer (creates and manages universes)
Document domain
Security domain
Scheduled document processing with Broadcast Agent
Supervisor (creates and manages users and groups, granting access to universes, documents, applications, connections and all other resources)
Repository
Users
Figure 4-1 The repository
Each domain serves a specific purpose: The security domain is the core of the repository and is used to store information about users, the groups they belong to, the applications and features they can use, the universes they have access to, and the documents they have shared.
Repository domains
122
The universe domain is used to store each shared universe. This is the area to which designers can export the universes that they create. Each universe is a meta-model of the related corporate database. The document domain is used to store the contents of each shared document and file. This is the area to which users can save Business Objects documents, or add other types of files to the portal to be shared by other users. This is also where documents such as templates, scheduled documents, and documents or files sent from users to other users are stored. Broadcast Agent accesses the document domain to run automated Business Objects document-processing tasks.
In many deployments, administrators choose to create multiple repository domains to support the requirements of their organizations. For instance, it is possible to create a deployment that features a single security domain, but two universe domains and five document domains. Different groups of users will then have access to specific universe and document domains.
123
How clients access the repository

Business Objects clients make use of the repositorys security and resourcesharing features through two files: The .key file The .lsi file
The .key file

The address of the security domain must be recognized by all clients using Business Objects products in online mode, so that users can communicate with the other domains of the repository in a transparent manner. This address is contained in the .key file, which is created in Windows when you use Supervisor to create the repository, or in UNIX, using the wmainkey script. You must distribute this file to all authorized users: For BusinessObjects users in 2-tier deployments, administrators must copy the appropriate .key file(s) to each workstation. In 3-tier deployments, administrators create the .key file(s) on the Business Object servers using Supervisor or the wmainkey utility.
124
Universe domain (semantic layer)
Document domain
Controls access to universes
Controls access to documents
Security domain
Repository .key file
Figure 4-1 Security through the repository
To access documents, at login users must select a repository to which they have been granted access (via a .key file), and must enter a valid user name and password. User access to specific universes, objects, documents and data can be further restricted using Supervisor and Designer. For more information, see the Supervisors Guide, Designers Guide, and the Business Objects Security Guide.
NOTE
With BusinessObjects Enterprise 6.1 you can also use an LDAP directory for authentication and authorization. For more information, see the LDAP Access Pack Guide.
125
The .lsi file

The .lsi (Local Security Information) file stores security information required to run Business Objects products without connecting to the repository (see page 132). This information includes precalculated security attributes for a user or user group based on data taken from the repository when the user is working online. It is created the first time a user connects to the repository and is updated with each new session. Session functional daemons obtain the security data for all but real-time users directly from the .lsi file. Because the .lsi file replaces the systems need to connect to the repository when users log in, the entire login process is speeded up.
NOTE
In previous releases, this file was called objects.lsi or objects.ssi, depending on its location in the $INSTALLDIR\LocData or $INSTALLDIR\shData directory respectively. For more information, see How the Business Objects System Works.
126
Where are the .key, .rkey and .lsi files located?

The supervisor creates the .key files in the $INSTALLDIR\locData (for local connections) for $INSTALLDIR\shData (for shared connections) directory. For desktop products such as BusinessObjects in 2-tier mode, administrators: - fetch .key files from these directories ($INSTALLDIR\locData and $INSTALLDIR\shData) - create .lsi (for all products) and .rkey files (for BusinessObjects in 3-tier mode only) in the $PROFILEDIR\Application Data\Business Objects\BusinessObjects Enterprise 6\lsi directory Server products use the $INSTALLDIR\nodes\<node name>\<cluster name>\locData directory for .key as well as .lsi files. Administrators are still in charge of deploying .key files to all Business Objects cluster nodes.
127
Which components access the repository?

The repository is the processing center of your deployment. It is in the repository domains that user access is secured, and shared universes and documents are stored. Because of its central role in any deployment, the repository is integral to most of the product components, and is accessed by the following components: Component Connection Server WILoginServer (via Connection Server) Reason for accessing the repository Provides connectivity to the repository for both WILoginServer and WebIntelligence queries At login, authenticates the user against the repository and creates the .lsi file using the precalculated data stored in its cache Saves the specified authentication method set as a WISessionManager parameter in the Administration Console to the repository Handles most InfoView workflows, including retrieving WebIntelligence and third-party documents from the repository, and saving them to the repository Serves as the report engine for documents in WebIntelligence Processes all document exchanges with the repository for 3-tier deployments of BusinessObjects
WIQT
BusObj.exe (Windows)/ bolight (UNIX)
Handles the viewing and refreshing of BusinessObjects documents in the repository from the InfoView ActiveX viewer
Which components access the repository?
128
Component Scheduler The Broadcast Agent Console All desktop products
Reason for accessing the repository Scans the repository at regular intervals for scheduled tasks that are due to be executed Manages and defines scheduled document processing tasks, storing this information in the repository Three examples: Supervisor writes security information related to users, groups, universes and documents into the repository. Designer exports/imports universes to and from the repository to share them with users. BusinessObjects exports documents to the repository for shared usage.
129
Using multiple repositories

The larger your deployment, the more information must be channeled through one repository security domain. The risk of security domain bottlenecks has been considerably reduced with the use of WILoginServer. Nonetheless, the more users you have, the more useful it may be to provide two or more repositories, each with its own security domain, as well as a series of document and universe domains. The use of multiple repository security domains can speed up network response times for BusinessObjects, since it circumvents the restrictions of a single security domain. If you have a large number of users based in different locations, it may be more efficient to divide them between two or more repositories, each with its own unique security domain. You can also create a series of document and universe domains. Deploying multiple repositories can be particularly useful in international configurations, where you can considerably speed up your network response times. For example, rather than having a single, centralized repository located in Europe that serves large numbers of users in both Europe and North America, a second repository can be created in North America for those users, reducing network congestion for all. Before setting up multiple repositories, however, understand that no interaction between repositories is supported, and therefore the domains in one repository can rapidly become desynchronized with those in another repository. For more information, see Deploying and using multiple repositories on page 367.
Using multiple repositories
130
The repository and your data warehouse

When you set up your Business Objects reporting environment, you deploy at least two databases: the repository your corporate database(s) or data warehouse(s) When you first run Supervisor, you must select a database on which you will store your repository. In some deployments, the repository will be created in the same relational database management system used to host the database. In other cases administrators will choose to develop their warehouse in one database while hosting their repository on another system. For example, you could have: A company that hosts both its corporate database and its repository in an Oracle database (see Figure 4-2). A company that hosts its corporate database in DB2 but chooses to host its repository in a Sybase database (see Figure 4-3). A company that hosts its repository in a DB2 database, with connections to three different corporate databases based on different database types (see Figure 4-4). A company that hosts different parts of its repository (the security, document and universe domains) in separate databases, which connect to each other and to the corporate databases as required (see Figure 4-5). These choices are left to the administrators responsible for the deployment, and are based on the requirements of the organization and the end users.
Repository
Oracle
Corporate database
Figure 4-2 Both corporate database and repository in Oracle
131
Repository
Sybase
DB2
Corporate database
Figure 4-3 Corporate database in DB2 but repository in Sybase
Corporate databases Oracle Repository DB2 Informix DB2
Figure 4-4 Repository in DB2, with different corporate databases
Repository domains Database1 Security domain Database2 Document & universe domains Database3 Document domain Informix Informix Informix Corporate databases
Figure 4-5 Different parts of the repository on different databases
The repository and your data warehouse
132
Working with or without a repository

You can work with BusinessObjects and Designer in two modes: workgroup mode, where you work in an environment without a repository enterprise mode, where you work with a repository The mode in which you save your files determines whether other users are able to access them. By default, files are saved in the mode in which you are already working. For example, if you launched a session in enterprise mode, any file you save is automatically stored in that mode. However, if you want to make a document accessible to another user working without a repository, then you must check the Save for all users option in the Save as document dialog box. Within enterprise mode, you can work in either of two modes: online mode offline mode
Online mode
In online mode, the default mode, you work connected to the repository. This allows you to share resources with other users, and retrieve and send documents using Broadcast Agent.
Offline mode
If you start BusinessObjects or Designer in offline mode, you will be connected to neither a repository nor a BusinessObjects web connection. This means you will not be able to retrieve and send documents using Broadcast Agent. If you are not connected to a repository, you can still work with documents and universes stored locally on your computer and even create and refresh documents if you have a connection to the database and the database connection and security information is stored on your computer.
133
If you start a 3-tier deployment of BusinessObjects in offline mode, you can continue to work on documents stored locally; you can work on the formatting of your reports or analyze data in existing reports, for example, and work with the data contained in the document to build new reports. You can also choose to start BusinessObjects in offline mode because you know you have no remote connection at all for example, on a plane and want to continue to work on documents you have stored locally.
NOTE
You must have already logged on at least once in online mode before you can work in offline mode.
Working with or without a repository
134
Repository compatibility issues

The version 6.x repository, with all its domains, is basically unchanged compared to 5.x. There are no new columns or tables, only new data (such as document types). This means that 2.x/5.x applications and a 2.x cluster (2.6 or later) can function with a 6.x repository. The reverse, however, is not true: Version 6.x applications and a 6.x cluster cannot function with a 5.x repository. A version 6.x Supervisor and a 5.x Supervisor can function on the same machine. However, 6.x Supervisor cannot function on a 5.x repository, and versions from 5.1.5 on of Supervisor cannot function on a 6.x repository. For more information, see Migrating from a Previous Version.
135
User authentication and authorization

Authentication is the process of identifying an individual, usually based on a username and password. Authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. The Business Objects system administrator can apply authentication security at several levels. Some of these measures can be applied by setting a WILoginServer parameter in the Administration Console:
Figure 4-6 Setting the authentication method in the Administration Console
Each level of security has its own advantages and disadvantages:
136
Type of security Business Objects standard authentication
Description This is provided through the security domain, which is set up when a repository is first created. Each repository that you create has its own security domain, which contains references to the universe and document domains. At login, the users username and password are checked against the security domain. Business Objects grants the privileges associated with UserName.
Operating system security (Windows authentication)
The system checks user names against Windows user names. If the names are the same, users can then launch a Business Objects application simply by double-clicking its icon, without entering any user identification. This type of security allows users to access Business Objects documents through their own individual accounts using their RDBMS user names and passwords only. At login, there is no connection to the repository. Business Objects identifies users by logging into LDAP with the user name and password. See the LDAP Access Pack Guide.
RDBMS security (not present in the Administration Console)
External authentication
When deploying the Business Objects system, you must carefully choose the security mechanisms youre going to use, bearing in mind the suitability and constraints of each security mechanism in terms of your particular deployment. The System Administrators Guides provide you with this type of information.
137
Corporate database
Database UserID and password
Repository
Business Objects UserID and password
Users
Windows UserID and password
Windows users only
Figure 4-7 Three levels of security at login
NOTE
For more detailed information concerning authentication and authorization, see the Business Objects Security Guide. For information concerning the workflows involved in processing authentication and authorization, see How the Business Objects System Works. You can also authenticate users using an external corporate LDAP directory. For more information, see the LDAP Access Pack Guide.
138
Network and system security

The rapid growth of networks and networking technology, both within and between organizations, has greatly increased peoples access to information. However, putting information within the reach of those who you want to have it also puts that information within the reach of those who you dont want to have it. Open network communication is vulnerable to: Electronic wiretapping, where anyone can monitor a data exchange and decipher the conversation, including stealing financial and other data Sabotage, which can be as simple as disrupting the data flow or as complex as modifying purchase orders or database queries False identification, where a site claims to be a company or entity that its not or a client claims to be another person The vulnerability of network data means you must make sure that information transactions between computers are secure. There are a number of ways to do this: Isolate the Business Objects network from all means of access, such as modem lines and outside network connections. This is the most secure way to protect a network, but also prevents the networks users from easily contacting other networks and external resources. Secure transactions to and from the local network by encrypting or encoding the data between the sending and receiving computers. Other security measures are effective at keeping intruders out of a private network, but have the unfortunate side effect of also keeping out the people you want to have access. Place a firewall around the network. A firewall limits or prevents outside access to the network, while allowing network users access to networks outside. Some firewalls prevent any access to the network from outside, others require user authentication before allowing access inside, and some even require authentication before allowing users inside to go outside the firewall. When you deploy server products, you must be extremely careful to choose products that can work with secured links between servers and clients. In a 3-tier Business Objects deployment, the communication between the cluster server and the requesting browser must be secure.
139
NOTE
For detailed information about securing your system from unwanted intrusion, see the Business Objects Security Guide. This new guide covers techniques for protecting the system and each component in it, from users machines and web browsers, through the systems web and application servers, middleware and Business Objects server components.
Common network protection techniques

Three common strategies for maintaining network security are: Public Key Infrastructure Public Key Infrastructure is a way to authenticate users securely over a network. Companies like Digital Signature, E-Lock, SHYM and Chrysalis are a few commonly known providers of PKI solutions. PKI uses public-key cryptography which generates key pairs -- one public, the other private (asymmetric). Owners of key pairs use private keys to encrypt/decrypt. Others use public keys to en/decrypt. Digital certificates Another way to secure network protocols is to use digital certificates. Applications use client/server side certificates to deploy web applications, where only the client with the client certificate on its machine can successfully view and use information. SSL SSLs allow the encryption of data between interacting entities by setting an encryption key for all the clients requiring HTTPS access. The only way to decrypt the data is to have a valid key that is issued by the server and has been accepted by the client. By contrast, HTTP does not encrypt data; it is a connectionless protocol, and is therefore easy to hack. SSL incorporates the use of both encryption keys and digital certificates, and is therefore highly recommended. For more information, see the Business Objects Security Guide.
Network and system security
140
Common system security techniques

Two commonly-used security mechanisms are: Firewalls Most Business Objects deployments use firewalls. Firewalls shield a site or subnet from protocols and services that can be abused from hosts outside the subnet. Firewalls can greatly improve network security and reduce risks to hosts on the subnet by filtering inherently insecure services. As a result, the subnet network environment is exposed to fewer risks, since only selected protocols will be able to pass through the firewalls. Firewalls also provide the ability to control access to site systems. For example, some hosts can be made accessible from outside networks, whereas others can be effectively sealed off from unwanted access. A site can prevent outside access to its hosts except for special cases such as mail servers or information servers. Reverse proxies You can use reverse proxying to camouflage the Business Objects system from external users accessing parts of your internal network. You can find more detailed information about both of these options in Supported Deployment Configurations on page 201.
Planning your Deployment
II
part
Deployment Considerations
chapter
144
Overview
The most efficient way to deploy the Business Objects solution varies from site to site. What is true for all implementations, however, is that planning your deployment carefully, evaluating the needs of your organization and users, and designing a realistic, step-by-step implementation process involving as many representative groups in your organization as possible are critical. Getting the process right is the key to first-time success. Whether youre a new or an existing Business Objects administrator, you need to consider a number of human and technical issues before you can effectively plan your deployment. This chapter lists the most important deployment issues and tells you where you can turn in the Business Objects documentation for more detailed information on each.
145
Pre-deployment checklist
Before you actually install the Business Objects software and set up your system, you should consider these fundamental deployment issues: Who are your users? What types of documents and other files will be processed? How can you make data accessible to everyone? How can you protect your system from unwanted intrusion, and how can you confine access to sensitive data to specific users? What types and configurations of servers are needed? How can you distribute transaction loads across the 3-tier system to optimize performance? How can you plan for disaster recovery? How can you acquire the technical expertise to deploy Business Objects products?
The bottom line

In any deployment environment, users will expect: that the system be easy to use This is partly the responsibility of Business Objects, which with this release has endowed the systems portal with a new interface designed to make its use simpler and more agreeable than ever. Your responsibility, however, is to keep the entire system as simple as possible (small, targeted universes, cellnamed document categories, etc.), and to educate and progressively familiarize your users with the system so that they can get the most out of it as quickly as possible. that the system respond rapidly If the system does not respond rapidly and reliably, users will simply not use it. These expectations should drive the implementation.
Pre-deployment checklist
146
Education: providing the tools to be successful

Any deployment requires particular baseline knowledge to be successful. The development and IT team requires a collection of skills: data warehouse expertise Windows and/or UNIX administration expertise generic Business Objects product and deployment knowledge Dont forget the users, however. No matter how technically fine-tuned a Business Objects deployment is, if the users are ignorant, or even hesitant about using the system, the implementation will take longer and be more costly. Involve user input from the beginning, and give users the knowledge they need to use the system comfortably and efficiently. The more they get out of using the system, the more theyll use it. Your deployment will involve two broad categories of users: The minority will be a small set of power users, who actually create, edit, and distribute the bulk of the systems documents. These users will require WebIntelligence and/or BusinessObjects end user skills. To get them up and running most rapidly, training may be required. The great majority of users, however, will probably be using the systems portal, InfoView, or the desktop BusinessObjects to view and refresh existing documents. These users will require less in-depth training. A good start would be having them use the multimedia tutorials BusinessObjects, WebIntelligence and InfoView Quick Tours, as well as the Getting Started manuals.
147
Performance: what is acceptable and how can you attain it?

The first step in obtaining acceptable performance is actually defining the response times that are acceptable to your users. Performance requirements and even possibilities differ with each deployment, depending on specific user needs, geographical location and deployment configurations. Once you have defined the performance goals for your specific deployment, you should identify factors in your particular deployment which may be affecting performance. They can include: Hardware issues Hardware issues include limited CPU, the speed and capacity of the disk subsystem, and available physical memory. Business Objects should be installed on dedicated server(s). Database issues The performance of the database can affect overall Business Objects performance. Factors that affect database performance include the physical distance between the Business Objects server and the data warehouse. Repository issues The size and complexity of the repository database structure affect performance. Users Far beyond the simple number of registered users your system will support, you must consider the number of users actually consuming system resources at any given time. What are users doing? How, to what extent and when are they stressing the system? Network issues The networks capacity (bandwidth, latency, delays and geography (LANs vs. WANs), as well as the tools it supports (routers, gateways and proxies) all impact the response times you can expect from your Business Objects system. In short, every major parameter in your deployment has some impact on performance. These parameters are described in the following sections.
Performance: what is acceptable and how can you attain it?
148
Server sizing: efficiently supporting peak user activity

How many server machines do you need for your deployment? You need to support not the average concurrent use, but the peak concurrent use. This can be up to 40% higher than average! In a typical system, approximately 15% of the users are logged in at any one time 15% of these users are actually using the systems resources You need to identify how the users are using the system: What percentage of processed documents will be WebIntelligence documents? What percentage will be BusinessObjects documents? What percentage will be other types of files? What percentage will have interactive refresh capabilities for WebIntelligence and BusinessObjects documents? There are so many variables in this type of system fine-tuning that you can determine what server configuration best supports your end-user population only by trial and error.
Capacity planning
Capacity planning is the process of sizing an overall system in relation to usage load, user profile, usage frequency, hardware, and server connections, and predicting the point at which the current resources will no longer be able to sustain the demands made on the system. Capacity planning extends the sizing process by adding the dimension of future needs. Every deployment evolves. Effectively sizing your solution for your current needs is an immediate solution; as the needs of your current user population increase or evolve towards more complex reporting, the load on your system increases. This means taking into account the systems scalability, or its ability to continue to perform up to required standards despite increases in load. A scalable application not only continues to perform well, but performs better when resources are optimized. Skilled and prudent capacity planning will enable you to delay as much as possible the point at which your system becomes saturated.
149
Deployment configuration
Which deployment configuration is best suited to your organizations needs? What types of deployment configurations are possible given your organizations resources?
2- or 3-tier architecture?
In a 2-tier deployment, Windows applications and connectivities are installed on clients, and the applications themselves implement all business logic. Using a 3-tier architecture allows for much larger deployments: Any tier can be updated or modified independently of the other tiers. It provides self-service data access for end users, and high availability and performance. It cuts maintenance and deployment costs by using zero-administration clients (only the deployments servers to maintain). It uses Java applets, which ensures platform independence and low cost of ownership as well as maintaining the intuitive drag and drop interface that fullclient users are used to. All processing is carried out on the middle-tier servers. UNIX operating systems are supported for this type of architecture. If you decide on a 3-tier architecture, the type of configuration you choose will depend upon such factors as: performance security providing failover stability geographical distribution expense ease of implementation and administration The deployment configurations supported by Business Objects for this release are described in Supported Deployment Configurations on page 201.
Cluster and repository architecture

Do your goals require single or multiple clusters? More than one repository? Where should they be located? These concerns are addressed in Modeling your System on page 163.
Deployment configuration
150
Data management: making data accessible

Typically, a common goal with a 3-tier deployment is for everyone in the organization to gain access to data, from top to bottom. In order to meet all your organizations data access needs with one system, the system must be easy to use: Universe design must be simple. Each universe object must justify its place in the universe relative to the other objects, so each object must be ultimately linked logically, or in some sense understandable to the user, to all the other objects. In general, a universe built against a data warehouse/data mart is easier to use than a universe built against an On-Line Transaction Processing (OLTP) database.
The database or data warehouse

The performance of the corporate database engine can play a significant role in overall system performance. Business Objects has customers who access tables with over 5 million rows and have a response time of a couple of seconds. A large data warehouse does not limit Business Objects functionality or performance but the associated indices, the size of the query, and the physical distance between the Business Objects server and the data warehouse can impact performance. Also, the number of open middleware connections may be limited for a given database. You should verify the maximum number of open connections with your database vendors.
What is your companys geographical distribution?

Are you deploying on a worldwide basis, or locally within a geographically confined area? Universal data access also means lots of data movement and data being distributed around the organization. In geographically distributed deployments, you also need to strategically locate data warehouses, system clusters, and the repository so that theyre closest to the heaviest transaction loads. You will also need to decide whether you need more than one of each. For more information, see Modeling your System on page 163.
151
Protecting your system and your resources

It is important to be able to share valuable information. It is just as important, however, to keep this information safe from unwanted access and intrusion. You will need to develop a solid security strategy to protect your system and the resources within it.
Allowing users access

User authentication is the process of identifying an individual, usually based on a username and password. Authorization represents the subsequent process of giving individuals access to system resources based on their identity. Within the Business Objects solution, Supervisor manages the major part of this type of security. It allows you to control when and how users can access, analyze and share data through object- and row-level security, table mapping, and blockand section-level security. You can also restrict user rights on the corporate database.
Protecting against attack

Network security involves the TCP/IP protocol layer, communication with the web and application servers, and the transmission of data packets between clients and servers. Application security, or secure communication between application modules, involves applications protocol and communication between servers. Measures you should consider for this type of security include: Network security options SSL Firewalls and DMZ configurations Reverse proxies For more information on these and other security issues, see the Business Objects Security Guide.
Protecting your system and your resources
152
Users: know their numbers, profiles, groups and rights

You need to know how many users you will be supporting, as well as the type of users, and their particular requirements. You also need to identify which users will have access to which services (document creation, document viewing, data analysis, web access), as well as the users hierarchical levels (general supervisors, supervisors, designers, users, etc.).
Types of users
The way in which users use the system is one of the most variable elements of a deployment. User behavior can be predicted based on several factors, the first of which is their user profiles. Not all users perform the same actions, log in with the same frequency, or represent the same load on your system. When analyzing the performance of your system, you must take into consideration the different actions and habits of those using your system resources. To make this distinction clear, we have designed four user profiles to represent the different types of user activities in a deployment. These user profiles are: Reader The Reader is the business user in a deployment. Readers have the rights required to open and read documents: Corporate, Personal, and/or Inbox, depending on the rights granted in Supervisor. The Reader typically consults pre-created reports on a daily or weekly basis, and does not have rights to refresh or create documents. Interactive The Interactive user uses the systems for the same purpose as the Reader. In addition, the Interactive user can refresh documents and lists of available documents.
153
Analyst The Analyst has a more complex relationship with the data in documents. The analyst can drill, rank, and slice and dice the data in documents. The analyst considers the data from different perspectives than that presented in the original format of the document. Advanced The Advanced user has a power user profile. The advanced user has the rights required to query the database, to create documents, and to format the data. Advanced users can send, save, publish and broadcast documents.
If you have a large percentage of mobile users, such as a sales force who are constantly on the move, then access to documents via the web from their laptop computers will be critical. Proportion of each type of user in a typical deployment Heres a diagram providing typical proportions of each type of user in a Business Objects deployment. The actual proportion of each type of user, of course, depends on the specific deployment.
Power users
Analysts
Readers and Interactive users combined
Figure 5-1 Typical proportions of user types in a Business Objects deployment
154
User activity
The three different user activity levels are registered, active, and concurrent. Registered users are those who possess a user profile in the repository, regardless of their rights or profiles. The total number of registered users is one dimension used to measure the size of the deployment. The number of registered users in a system by itself, however, provides no information about the load on the systems resources. Active users are users who are logged into the system but are not currently using system resources. Each user has an associated live WIQT process running in the system, but no other resources are used. Typically this corresponds to users who have performed an action such as refreshing a document, but are now viewing the document without invoking server CPU. Concurrent users are logged in and are actually consuming system resources, whether or not they are performing the same actions. Before you begin, you need to determine two critical user activity ratios: the total supported users ratio (total user population to active users) and the user activity ratio (concurrent users to active users). The registered:active users ratio The registered:active users ratio impacts the total number of users the system will support. For a 3-tier deployment, the smaller the proportion of registered users logged into the system at any given moment, the more total users the system will support with fewer servers. For example, if one user in four were active, the smallest configuration would support between 160 and 280 users. If only one user in fifteen is logged on at any one time, the smallest configuration would support from 600 to 1,050 users.
155
The concurrent:active users ratio This ratio, only relevant in a 3-tier deployment, is defined as concurrent users to active users. This ratio impacts the server's CPU usage: the more concurrent users there are, the more CPU is used. The fewer average concurrent users per number of active users, the more users each CPU can support. The number of concurrent users and the database access affect performance. The login is one aspect of this, however the biggest part will depend on how many users will create and refresh documents as well as how many documents users exchange through the repository. With user activity, performance measures are linear. We highly recommend using BusinessObjects Auditor to determine exactly how users are using your system. This product can help you understand user patterns, fine-tune the deployment, and plan for the future. The impact different workflows, different document types, and architecture design have on performance is critical.
156
Documents: what type, how complex?

The Business Objects system provides full processing of two types of documents: BusinessObjects documents WebIntelligence documents There are different advantages in using each type of document within each environment. After reviewing the differences between the two types of documents, you can decide what deployment is best suited to your users needs.
REMINDER
The Business Objects system can provide access to all types of files, and allow users to upload, download, send and save them. These files cannot, however, be edited or scheduled.
BusinessObjects documents vs. WebIntelligence documents

The most significant difference between BusinessObjects and WebIntelligence documents is that BusinessObjects documents can be much more complex than WebIntelligence documents due to additional reporting features in the BusinessObjects product. WebIntelligence documents, however, can allow for much larger deployments.
Size of documents
The size of the documents being used or created has a significant impact on the network traffic and the memory of the server machine. If users are constantly refreshing large documents, this will saturate the network as well as consume memory on the server. A solution that limits the bottlenecks that can be caused by the refreshing and distribution of large documents is to schedule them with Broadcast Agent.
157
Number of documents
The number of documents a typical user can access in the repository also affects the system. The larger the number documents, the more the system works, the longer the process takes. But remember this affects the whole deployment's performance because the system will be busy each time a user refreshes a list, which in turn slows down performance for all other user activities.
Documents: what type, how complex?
158
Load balancing: matching system processes and server resources

One of the greatest advantages of a distributed architecture is the capacity to distribute system transactions over several and indeed, increasing numbers of servers. When youre setting up your system, you need to decide exactly how you are going to share the transaction load. You can balance loads over servers by strategically distributing high-traffic system modules (or processes) across several machines, or in some cases, by directing a greater proportion of transactions to higher-capacity servers. You can dedicate certain servers to a single type of process, or provide for several types of processing on several servers. For more detailed information, see the System Administrators Guides.
159
Disaster recovery: what can you do about it?

Throughout your pilot project and your production deployment, you must be able to identify potential critical points of failure: the repository the data warehouse the clusters primary node You also need to have a plan for failure recovery. For example, you might use a multiple cluster deployment, so that if one cluster goes down, the other cluster can take over.
Disaster recovery: what can you do about it?
160
Deployment procedure
All business intelligence solutions need careful planning, execution and management. 3-tier solutions are especially complex, but as they typically service must larger user populations, they require less deployment and maintenance time per user.
Launching your pilot project

If you are planning a large deployment, set up a pilot project first. The pilot project should be as representative as possible of your entire project, and should be tested before investing time and resources in an actual production project. A pilot project will allow you to test and tune your deployment, and to iron out any configuration and operational problems that arise from your particular setup and chosen tools. Based on this feedback, you can then realistically plan your actual deployment. Use BusinessObjects Auditor for tracking and analyzing how users are using your system, what the server load is at peak times etc., as it will help you monitor and analyze your Business Objects deployment. For more information on development lifecycle environments and the migration to a full-scale production environment, see From Development to Production on page 303.
Bring in Business Objects expertise

Web-based delivery is still a relatively new approach. Business Objects offers a complete range of support and services to ensure you the maximum business benefit from your business intelligence deployment. A global network of Business Objects and business intelligence technology experts provides customer support, education, and consulting that can be tailored to fit the needs of any organization.
161
Customer Support Business Objects operates three global customer support centers staffed with acknowledged experts in our technology. Using an industry-leading call management and problem-reporting system, all engineers share their knowledge to accelerate case resolution time. The Business Objects online customer support (OCS) website let you log cases, update case information, and track case progress autonomously via the Internet. Using the OCS, you have online access to the Business Objects knowledge base 24 hours a day, seven days a week. So no matter what time it is, you can access the most up-to-date product and technical information at Business Objects to help answer your questions. From that site, you can also access the full range of product documentation in Adobe Acrobat PDF format, as well as a variety of tips for using the Business Objects solution to its fullest. Consulting Business Objects offers a full range of consulting services to assist customers in all stages of the development life cycle, from initial analysis through to delivery. Depending on your needs, our involvement can range from an advisory status to managing the whole project. Business Objects consultants have in-depth product knowledge and experience in using and deploying Business Objects products in many companies across different market sectors. In addition, consultants offer specialized experience in relational and multidimensional databases, connectivities, and use of data design tools, as well as embedding product technology using scripting and customization techniques. Contact your local sales office for more information.
Deployment procedure
162
Conclusion
Virtually no organizations needs remain frozen. User populations expand, evolve, or relocate. Technology continues its steady advance, and just as steadily, users demand more out of a systems performance. Your organization may decide to port to UNIX, or extend its reach across the web via an extranet. No matter how carefully youve planned and managed your Business Objects deployment, chances are you will never really see the end of the deployment procedure. However your system evolves, keep the same rules in mind: Start small. Think big. Define what acceptable performance means for your deployment, then expand, trace, volume test, benchmark, analyze and tune. And dont hesitate to bring in the expertise you need, when you need it.
Modeling your System
chapter
164
Overview
Deploying the Business Objects solution for maximal use and benefits requires more than just installing and configuring Business Objects products. You must first create an optimal operating environment for the solution, weighing the anticipated size of your deployment, then the software and deployment architecture that will best support it. Modeling your solution means designing the physical system capable of meeting your users needs and delivering the levels of performance you expect. It means considering the supported deployment configurations recommended for the size and type of deployment, then choosing the cluster and repository architecture best adapted to your user populations requirements. What is your companys geographical distribution? How will most of your users use the system? Where are the data sources? How complex is the computing? What is the network bandwidth? Depending on the factor most likely to cause the first bottleneck in your system, you may have an obvious choice as to the type of architecture to adopt. This chapter covers: Selecting your systems operating system Selecting your systems software Deployment models Cluster architecture Repository architecture Database and repository location Centralized or decentralized architecture? The last section in the chapter uses a fictional company planning to deploy the Business Objects solution to 700 users spread across several sites worldwide to illustrate the different deployment architectures, their advantages and disadvantages.
NOTE
This chapter represents a high-level discussion of the factors that can impact which architecture suits specific goals. It does not go into all the details you need to consider, and should be used to generate discussions with Business Objects professional services.
165
Designing your architecture

What do you want the architecture you choose for your Business Objects solution to deliver? Some of the principal goals on which you might focus include: Ease of management and ongoing maintenance Acceptable performance Failover and redundancy Round-the-clock operation In small deployments, architecture concerns are relatively simple. In these deployments, a small user population often works out of a single physical site, and a simple, centralized deployment architecture may be the optimal solution, with a single repository and corporate data source deployed on a single network. Bigger deployments, however, can serve thousands of users scattered over multiple sites around the globe. Geographically-distributed deployments have a host of constraints of their own. These configurations often span time zones and languages, involve multiple networks and can serve thousands of users scattered over several physical sites. In these situations, designing your systems architecture for optimal use will require juggling a host of parameters, unique to each situation and ever-evolving.
Key factors in architecture design

Here are some key questions youll need to answer before making any architecture decisions: Where are your users physically located? What are the usage profile(s) that represent the key user service level response time? How do you envision the users will use the system? Ad hoc, report consumers, extranet, intranet? Where is the data that is required to support the queries in this profile(s)? Do you have a single data warehouse and/or do all sites have their own data? Do you replicate data to local areas?
166
What is the bandwidth of the network connecting the users to the Business Objects server, and the Business Objects server to the data source? Given this bandwidth, what is the optimal configuration for moving required data? Will Broadcast Agent be used as a way to pre-generate documents, and thereby leverage off-peak CPU time? Are you delivering cross-corporate information to all sites, or to some sites only?
Information you must have before determining your architecture

You should have the following information on hand in order to define the scope of your global Business Objects deployment strategy: Database or data warehouse Database engine and version Network location Repository database (network locations) Security domain Universe domains Document domains Redundancy and failover? Business Objects products InfoView/WebIntelligence? BusinessObjects? Broadcast Agent Publisher? Server location (network) Network access Bandwidth of each network Web server load balancing? If so, what hardware is being used? WAN vs. Dialup access
167
Server hardware on each server Memory CPU Disk access: --Speed --Failover RAID? Shared storage device? (Will it cope with the load?) Network Interface Cards (NICs) Security and authentication Firewalls Is Single Sign On a requirement? BusinessObjects documents % of all documents being processed Number Average size Average number of rows Average number of tabs WebIntelligence documents % of all documents being processed Number Average size Average number of rows Users Total user population (registered users) Number of users on Network1
168
Number of users on Network2 Number of users on Network2 % 2-tier BusinessObjects users % InfoView users Maximum % active users Maximum % concurrent users Document scheduling Number of scheduled documents How often? What time of day should tasks be run? Refresh-time window the database is available for batch processing (How long does each job take on average? If you are priming the cache with HTML, this will increase the duration of the job.)
169
Selecting your systems software

The functional infrastructure of the operating environment in which you run your Business Objects system is determined by the software of which it is composed. To help you to use Business Objects products in optimal conditions, Business Objects has defined a set of stacks, or sets of third-party software with which the Business Objects system will interact optimally, in specific sets and combinations. Each stack includes the servers operating system, the database and the language being used, along with other components like supported web and application servers and middleware. Particular combinations and versions of all the other components that make up the solutions operating environment are supported to run with each of these operating systems. You can find up-to-date, more detailed information about each of these stacks (such as exact version and Service Pack numbers) in the PAR.
The PAR
The PAR (Product Availability Report) is the official guide to the current and future product offerings of Business Objects. You can find a link for it at www.techsupport.businessobjects.com It contains the most up-to-date information concerning: language support platform support third-party support (third-party applications that can be used with Business Objects, like web and application servers) web browser support Before making any decisions about the software you will use as the infrastructure for your Business Objects system, check with the PAR or your local Business Office sales office.
Selecting your systems software
170
Selecting your systems operating system

Business Objects supports Windows or UNIX platforms for its server products. The operating system you choose depends on the size and complexity of your deployment and the characteristics of the operating systems themselves.
UNIX
Organizations need robust, dependable servers servers that crash rarely, and that dont have to be rebooted every time new software is installed. But organizations also need powerful, user-friendly software. Business Objects for UNIX offers a high-performance combination of power and flexibility that benefits everyone. UNIX servers can be twice as fast as Windows servers if there are no bottlenecks elsewhere in the system, and they can handle substantially greater numbers of users. For this reason, UNIX servers are especially adapted to large-scale Business Objects deployments serving thousands of users. Servers running Business Objects server products on UNIX offer system administrators the advantages of administering robust, reliable UNIX software, while still enabling PC users to make use of the powerful functionality, yet easyto-use interface that are the hallmarks of Business Objects software. You can perform almost all tasks on UNIX clusters. There are, however, some restrictions. See page 171.
NOTE
Users may encounter problems when viewing, editing or sharing documents containing OLE 2 objects, using a Business Objects server on UNIX.
171
Heres a summary of some of the advantages and disadvantages of using a UNIX system: Pros More scalable, better security Supported to install databases and all Business Objects components on one big UNIX server Cons No VBA macros in Broadcast Agent
Windows
Particularly adapted for smaller deployments, Windows systems have the advantage of supporting the full set of Business Objects products and functionality. Heres a summary of some of the advantages and disadvantages of using a Windows system: Pros Local Java Administrator Console applet Lower hardware and software costs than UNIX Windows ease-of-use Cons You need good understanding of COM/DCOM Security issues, hackers target Windows IIS servers
When do you need a Windows cluster?

Some tasks or task aspects must still be run on Windows servers: All processing involving OLAP data sources Visual Basic procedures Personal data files, including XML data providers Custom macros for Broadcast Agent tasks All processing requiring stored procedures All processing requiring Free Hand SQL Also, some connectivities are not available on UNIX, such as all OLAP, Microsoft SQL Server and others.
172
What administrative functions require a Windows machine?

Administrative functions belong to two broad categories: those pertaining to the overall Business Objects solution those pertaining to the 3-tier architecture in itself, such as running Broadcast Agent and/or InfoView Business Objects system administration Under UNIX, the Administration Console is a web application displayed using a browser. Even if the application server hosting the Administration Console is located on UNIX, you need a Windows machine to run the browser. Business Objects does not support UNIX for Supervisor or Designer. Therefore, you need a Windows machine to: create and manage the Business Objects repository create and manage users and user groups (although you can also create a customized application using the Administration SDK to handle this) define database connections create, manage, import and export universes define fundamental Broadcast Agent criteria, such as the Broadcast Agents user name and password, the groups to which each Broadcast Agent is assigned, and the document domain and channels it uses
173
The Windows machine(s) you use for these critical functions does/do not, however, need to be part of a cluster in your 3-tier system as illustrated in this deployment configuration:
Client machines of 3-tier system Web server Cluster Primary node Database
Application server
Repository
Client administration machines (Supervisor, Designer)
BusinessObjects, BusinessQuery users
Figure 6-1 Administration products on Windows machines outside cluster
Some of these administrative definitions are stored in the repository, where the nodes in your cluster(s) can access them. Others, such as settings defined using the Administration Console and the Configuration Tool are stored on the server. Monitoring Broadcast Agent and the Business Objects system Broadcast Agent administrators and users use the Broadcast Agent Console to track and modify the scheduled processing of documents. If you are running Broadcast Agent under Windows, you can run the Broadcast Agent Console on the Broadcast Agent server itself, in addition to running it remotely from a client machine. If you are using UNIX for your Broadcast Agent server, then you cannot run the Broadcast Agent Console on the UNIX machine but must instead run it remotely.
174
OLE 2 objects and UNIX OLE 2 objects are specific Microsoft objects. Consequently, users may encounter problems when viewing, editing or sharing documents containing OLE 2 objects, using a Business Objects server on UNIX. To insert a logo or other image in a document, then share that document via server products installed on UNIX, users can save the image as a bitmap (.bmp). You can do this in Microsoft Paint or a similar application.
Are mixed Windows/UNIX clusters supported?

Mixed-platform clusters, known as heterogeneous clusters, are not supported for this release. Again, it is possible to use a Windows machine for administrative purposes and still have a UNIX cluster.
175
Deployment models
Drawing on its customers experience, Business Objects has defined three deployment models designed to represent three typical deployments. We refer to these models as small, medium and large, in reference principally to the relative sizes of the deployments repositories. Other parameters taken into account are: the number of registered users in the system the percentage of all users who are active at peak usage the percentage of each type of user in the user population (power users, analysts, interactive users and passive readers) the hardware dedicated to each element the deployment scenario and configuration Here are some rough guidelines for determining the deployment model to which your deployment corresponds: Deployment model Small Medium Large Registered Documents accessible Size/complexity of users for each user documents 500 5000 Over 5000 100 500 500 Small/simple Medium/fairly complex Medium/fairly Large/highly complex Medium/fairly Large/highly complex In these deployment models, the proportion of each of the four user profiles (see page 152) typically evolves as the deployment grows:
Deployment models
176
Deployment % model Power users Small Medium Large 10 5 5
% 15 15 10
% 50 35 25
% 25 45 60
Analysts Interactive users Passive readers
For example, in large deployments, the proportion of passive readers, who use the least system resources because they see only pre-generated reports, expands considerably. Conversely, as deployments grow, the proportion of power users, who actually create Business Objects documents decreases. As stated before, as deployments grow, the sheer numbers of users and volume of data being processed demand consideration of more complex, in some cases decentralized deployment architectures. See the following sections for more information.
177
Cluster architecture
Cluster architecture has to do with the number of servers you include in each cluster, and the number of clusters you use in your overall Business Objects system. The servers belonging to any cluster must always be at the same physical site, sharing the same network segment.
Additional secondary or additional primary node?

Each cluster you deploy must have one (and only one) primary node. When the demand on the system requires extra processing power, you can add as many servers as you require. You can add additional nodes to your system in two different ways, however: by adding a secondary node to an existing cluster by creating an additional primary node, thereby creating a new cluster by adding a client node to the existing cluster This is only applicable for JSP deployments, as with ASP you cannot split the web and application servers. If, for example, you were running the application server on the same machine as a Business Objects server, you could move the application server onto a dedicated machine. In JSP configurations, you could also separate the web server from the application server.
When should you do what?

Certain obligatory processes must be running in any active cluster. These include the CORBA and ASF processes required for communication between the cluster servers, and with the other components in the Business Objects system. WIStorageManager and WILoginServer must be enabled on the primary node. The session stack must be enabled on any node which will be processing documents or document lists. If you add another primary node to your system (and thereby create a new cluster), you will be duplicating these processes; as these processes are already running in the initial cluster, you may not actually need them for handling transactions. In this instance, you may therefore be consuming system resources needlessly.
178
If you add another secondary node to an existing cluster, not only do you avoid duplicating mandatory processes, but you can direct all the new servers processing power toward specific processing transactions by activating and deactivating the relevant Business Objects modules with the Administration Console. With each server dedicated to fewer types of transactions, performance improves. On the other hand, duplicating these key processes also has its benefits, such as removing single points of failure. Processing power vs. number of machines in a cluster At some point, of course, adding a new cluster to your deployment makes more sense than adding another node to an existing cluster. The following chart illustrates the relationship between an increasing number of machines in a cluster, and the additional processing power the cluster actually derives from a new machine:
Processing power Theoretical results Experienced results
Number of machines in a cluster
Figure 6-2 Processing power vs. number of nodes in a Windows cluster
The additional processing power added by each new machine decreases as the number of nodes in the cluster increases. Why? Some processes exist only once in the cluster. A certain amount of communication, such as CORBA, needs to occur within the cluster under any circumstances, and this takes up processing/resources.
179
The combination of these factors means that there is a point at which it is better to have multiple clusters than one. (This in itself introduces different problems, such as setting up shared storage.) Generally speaking, a Windows cluster should not contain more than four or five servers. After the addition of two or three secondary nodes, you should use benchmarking tests to determine whether the amount of extra processing power a new node will procure is still greater than the power brought by the addition of an entire new cluster. You can measure processing power through a comparison of response times.
NOTE
When using powerful machines like UNIX servers, you will probably gain more processing power per machine by adding additional primary nodes.
When should you use multiple clusters?

In general, having multiple clusters increases: failover capability scalability (multiple WISessionManager processes, and so forth) Here are some specific circumstances in which this may be particularly appropriate: When too many users spoil a clusters performance When you want failover capacities for a primary node When you want Broadcast Agent failure recovery When your deployment is geographically distributed When you are using multiple repositories Although a server in one cluster cannot interact directly with a server from a different cluster, it can exchange information through: the repository, which can be linked to all of the configured clusters shared storage (personal documents, MyInfoView settings, corporate document caches, etc.) When too many users spoil a clusters performance You should deploy multiple clusters if you have a large number of users that you want to break down into smaller groups, each with an individual primary node to improve performance. Each of these clusters will then be sized as though it were a standalone cluster, with its own user group. All users can still access the same repository, and can exchange documents in the usual way.
180
When you want failover capacities for a primary node By default, there is no primary node failover. If you have only one cluster and its primary node fails, then the entire cluster will also go down. Setting up multiple clusters can thus provide fault tolerance: when one cluster goes down, simply direct users to another, functioning cluster. When you want Broadcast Agent failure recovery Multiple clusters are also useful for Broadcast Agent failure recovery. If two or more Broadcast Agents monitor the same queue from the same repository, the work load will be load-balanced across them. Should a Broadcast Agent cluster go down, then the others will not be directly affected, but will continue as normal. The remaining Broadcast Agents, of course, will be required to process more jobs. When your deployment is geographically distributed You must use multiple clusters if your server deployment covers more than one time zone. Although the location of the clusters clients is theoretically irrelevant, response times are better when clients are geographically close to the servers processing their requests.
181
All nodes in the cluster must be configured in the same language; you do this first by choosing the languages to install, then choosing each nodes default language during the node installation. You can change these settings from the Site Properties page in the Administration Console:
Figure 6-3 Setting the clusters locale and charset in the Administration Console
NOTE
Starting with BusinessObjects Enterprise 6.1, users can select the default interface language and country they want to use from among installed Western languages. For InfoView and WebIntelligence, they do this in the InfoView Options pages. For desktop products such as BusinessObjects, Designer and Supervisor, they set this in the applications Options dialog box. The language selected by the user therefore overrides the cluster language.
182
When Broadcast Agent is used to refresh and distribute documents, their time and dates automatically correspond to the client machines local times. When you are using multiple repositories If you are supporting large numbers of users, you may want to speed up logins and document access by using multiple repositories. In this case, you must set up multiple clusters, each of which points to a particular repository. Users can select the repository to which they want to connect by using the URL corresponding to the appropriate cluster.
183
Repository architecture
Each repository contains a single security domain, as well as one or more document and universe domains. Repository architecture concerns how many of each type of domain are deployed and where they are located, as well as how many repositories you are using in the overall deployment.
When should you use multiple repositories?

A multi-cluster configuration allows a given user population to access a different cluster to speed up login time or better manage network traffic. Users are divided into sub-groups and a cluster is dedicated to each of these sub-groups. To select the security domain they want to use, users simply point their browsers to the cluster connected to the appropriate repository. This is the equivalent of what is called security domain selection in BusinessObjects.
Figure 6-4 Choosing the security domain from BusinessObjects (3-tier)
This is particularly useful in international configurations. For example, rather than having a single, centralized repository located in New York serving large numbers of users in the United States and Europe, you can create a second repository and cluster in Europe for European users. This not only speeds up response times dramatically for European users, but reduces the network congestion experienced by all users.
Repository architecture
184
In an InfoView deployment, you'll need to set up a separate cluster for each repository; users then login to a server in the cluster pointing to the repository of their choice. Remember, though, that you can't transparently share resources across repositories. For information about synchronizing repositories, see page 368. For more information, see Using multiple repositories on page 129.
When should you use multiple document/universe domains?

It makes sense to use multiple document and/or universe domains in the following situations: To manage different versions of your documents and universes. Almost every deployment involves creating different sets of domains: one set for development, one for testing, one for user acceptance testing, one for production. This enables you to migrate universes and documents from one set of domains to another in a controlled and mature way. When the sheer quantity of documents being processed by the deployment demands their organization into separate domains When you have a medium or large deployment in which users at multiple physical sites share the same repository For example, a company whose headquarters is located in San Jose, California, has two subsidiaries, one in Paris, and one in London.
185
Database and repository location

Business Objects server products are very network-dependent. If they are run on poor networks, their performance will be poor as well, whereas good networking can result in excellent response times. The two major processing/data interactions in Business Objects are: The login process and repository access for shared resources Querying the corporate databases to generate document lists or refresh the data in existing documents The location of the various repository domains and corporate databases or data warehouses is a strategic factor in any deployments performance, especially in geographically-distributed deployments. The golden rule? The closer the repository domain/database is to the Business Objects processing layer, the less traffic in the cluster, and the faster the response time.
Where should the repository be located

With BusinessObjects Enterprise 6, network traffic related to the security domain is reduced by the WILoginServer process, which handles authentication/ authorization for the Administration Console, Administration Server, InfoView and 3-tier deployments of BusinessObjects. At system startup, WILoginServer retrieves the authorization information for all users from the security domain, precalculates a security model, then stores it in a system cache. When users log in, the more complex calculation of each users access rights, which used to consume valuable processing time and network bandwidth, is now computed by WILoginServer from the system cache, then copied to disk, where each users WIQT fetches it.
Database and repository location
186
WILoginServer periodically re-contacts the repository to refresh and recalculate the information in its cache to remain as synchronized as possible with any security domain updates. This period is set in the Administration Console:
Figure 6-5 Setting the WILoginServer refresh period
If too many users are logging in at once, however, this mechanism in itself cannot prevent login bottlenecks. Repository access for both logging in and sharing resources such as universes and documents remains a potential major bottleneck. The repository should be located as geographically close to the Business Objects server(s) as possible.
Where should your database be located?

The database or data warehouse containing your corporate data should be located near the cluster using it.
187
Centralized or decentralized architecture?

Business Objects system and repository architecture can fall into centralized or decentralized configurations. This section uses a fictional company with a medium-sized Business Objects deployment to illustrate the advantages and disadvantages of using a centralized architecture with a large, centrally-located cluster or clusters, and a decentralized architecture with smaller clusters located at various sites. This section describes a number of scenarios with different solutions for Business Objects architecture and repository deployment: a centralized architecture with (a) large, centrally-located Business Objects cluster(s) a decentralized architecture with smaller Business Objects clusters located at various sites.
Background information about the example company

The companys environment consists of a standard 2-tier environment with BusinessObjects, as well as a 3-tier environment hosting InfoView, WebIntelligence and Broadcast Agent. The total number of Business Objects users is approximately 700, with an estimated: 350 users in corporate headquarters (USA1) 225 in the United Kingdom (UK1) remaining 125 users spread out over Australia (Australia1) and the other two US sites (USA2, and USA3)
The companys goals in designing its architecture

The companys top priorities are: Information delivery to all sites Built-in redundancy Failover 24 x 7 operation
188
Scenario 1: Centralized architecture

Cost Least Performance OK
This section illustrates two centralized solutions: Centralized architecture with a single cluster Centralized architecture with multiple clusters Centralized architecture with a single cluster
USA1
Secondary node Cluster
Primary node/ Web server/Application server
Repository with security, universe and document domains
USA1
Secondary node/BCA
Data warehouse
LAN/WAN
Users
USA
UK
Users Users
Australia
Figure 6-6 Centralized architecture with a single cluster
In this centralized Business Objects architecture, a single cluster is located on the USA1 network. The three repository domains (security, universe and document) and the data warehouse are also located on the USA1 network. To optimize performance, the cluster should always be as geographically close as possible to the repository and data storage. The cluster was therefore deployed on this network as the data source(s) being used are all located on this network. The repository was also placed here for the same reasons.
189
This architecture does not provide failover. For failover, multiple clusters are required (see the next centralized architecture option). Reasons for choosing this scenario If you have only one geographical location, this is probably a good architectural choice. The performance elements that may lead you to choose another deployment strategy only apply if you have a geographically dispersed deployment. A centralized architecture can also work well if you have good network bandwidth and centralized corporate data storage. How this scenario works 1. To access the Business Objects system, users point their browser to the web server in USA1 using a URL assigned by a system administrator. Users in USA1 use the LAN to communicate with the system, whereas remote users use the WAN (we are assuming the WAN network bandwidth is adequate). 2. The web server accepts the request and displays the InfoView login page. 3. The primary node authenticates the user against the security domain in the centralized repository in USA1, but the actual calculation of each users .lsi file containing access rights is carried out within the cluster itself. 4. After users have successfully logged in, they have access to their assigned Business Objects resources in the centralized repository.
190
Advantages and disadvantages Advantages Less total administrative staff translates into less cost. Disadvantages Login can be slower for users who are not in corporate headquarters but how slow really depends on the network bandwidth of your WAN. If the WAN is down, the Business Objects system becomes inaccessible to remote users. Users using BusinessObjects could use off-line mode, however, for the analysis of existing documents. New user setup, and modifications to user privileges, can require additional administrative time and delays for local users. This solution requires 24x7 support.
Centralized security management ensures the implementation of uniform standards and better control over access to information.
There is a local performance gain from placing the repository and data warehouse close to the Business Objects servers.
191
Centralized architecture with multiple clusters

Secondary node
Repository with security, universe and document domains Data warehouse
Secondary node/BCA
ClusterA
Shared storage Secondary node ClusterB Secondary node/BCA IP redirector
General supervisor Designer
USA1
LAN/WAN
Users
USA
UK
Users Users
Australia
Figure 6-7 Centralized architecture with failover
This scenario uses two clusters for failover and an IP redirector for distributing network traffic. The Business Objects clusters A and B are deployed on the USA1 network, because this is where the data source(s) and repository are located.
192
The clusters are connected to an IP redirector such as the Cisco LocalDirector. This provides an extremely stable solution with both failover and load balancing built in. Shared storage has been enabled to allow multiple clusters to share personal documents and system caches. In this scenario each cluster consists of a single primary node and one or more secondary nodes. One node in each cluster hosts an activated Broadcast Agent for scheduling document refresh and distribution even if it is used only during offhours; during the daytime it serves as a standard interactive processing node. How this scenario works 1. To access the Business Objects system, users point their browser to the web server in USA1 using a URL assigned by a system administrator. Users in USA1 use the LAN to communicate with the system, whereas remote users use the WAN. 2. The IP redirector receives requests from the users, then redirects the requests to one of the available web servers based on a predefined loadbalancing rule. 3. The assigned web server accepts the request and displays the InfoView login page. 4. The primary node authenticates the user against the security domain in the centralized repository in USA1, but the actual calculation of each users .lsi file containing access rights is carried out within the cluster itself. 5. Once users have successfully logged in, they have access to the standard corporate documents published to the centralized repository. Deployment alternatives Figure 6-7 shows two clusters with primary and secondary nodes. You could alternatively choose to have multiple primary nodes behind the redirector. This deployment option is often considered in situations in which failover is a critical element of the deployment. In this scenario you must enable shared storage if you want your users to be able to use personal documents. When you configure the Business Objects system, you can choose which server you want to store the system's cache, temporary and personal documents etc. For performance reasons, it is often a good idea to locate this on a separate machine (you may want to replicate this file server to provide true failover).
193
Dealing with limited bandwidth A different company headquartered in the United States has an office in Japan. Its American and Japanese sites are connected on a 128KB line. Before the company deployed Business Objects, this line was already supporting a considerable amount of traffic. The pipe is thinner going to Japan so it takes longer to get things through. It takes longer to render a page, longer to send a query. This is generally when companies start looking at a different architecture to prevent limited bandwidth from lengthening response times. If this is the case there are a number of different options, decentralized architecture being only one of them. The most obvious is improving the WAN speed to your remote locations. Another option is having separate installations at the different locations. We will not go into this option in detail as it is simply replicating the centralized architecture at n locations. This option is applicable if each of the locations has its own data, different information needs (e.g., different universes, etc.) and information does not need to be shared between sites. You could use this architecture and have most users use the local system while still providing access to the 'main' cluster to users who need all the data. While this type of deployment is an option, know that it leverages relatively few of the BI benefits created by an enterprise deployment.
194
Advantages and disadvantages The pros and cons are the same for this variation of the centralized architecture solution with the addition of these points in this scenario: Advantages Complete cluster failover with the use of an IP redirector Disadvantages More administration: you have to administer the router (very low cost in real terms), and you have to administer each cluster separately (launching a separate Administration Console for each cluster) More expensive
Scenario 2: Decentralized architecture with centralized security domain

Cost Moderate Performance Moderate
In this decentralized Business Objects architecture, the clusters are located at different locations in the USA, UK, and Australia. The security domain is centrally located in USA1. Pairs of site-specific universe and document domains are deployed at each of the other company sites. The data warehouse is located in USA1. Users access all their information using InfoView.
195
Secondary node Repository with centralized security domain, plus universe domain and document domain Data warehouse General supervisor Designer IP redirector
Primary node Secondary node/BCA Shared storage Secondary node ClusterB Secondary node/BCA Primary node ClusterA
USA1
LAN/WAN
Secondary node/BCA Secondary node/BCA Primary node ClusterD
UK
ClusterC Primary node
Australia
Secondary node
Local DB Local supervisor and designer
Local DB Local supervisor and designer
Secondary node
Local document and universe domains
Local document and universe domains
Figure 6-8 Decentralized architecture with centralized security domain
196
At each of these locations, two or more clusters are connected to an IP redirector. This provides failover, while having multiple primary nodes also allows you to direct high priority queries to a specific server. At some companies, all executives are sent to one cluster while the rest of the company uses the other cluster to ensure that the executives consistently get high priority service. In this example, each cluster consists of a single primary node, and one or more secondary nodes. One node in each cluster hosts an activated Broadcast Agent for scheduling document refresh and distribution even if it is used only during off-hours; during the daytime it serves as a standard interactive processing node. How this scenario works 1. To access the Business Objects system, users point their browser to a local web server at that location using a URL assigned by a system administrator. In a decentralized architecture, users use the LAN to communicate with the local Business Objects system. 2. The IP redirector receives the request from the user then redirects this request to a web server based on predefined load-balancing rule. 3. The assigned web server accepts the request and displays the InfoView login page. 4. The primary node authenticates the user against the centralized security domain located in USA1. Whether it does this through the LAN or WAN depends upon whether the whether the primary node is located in USA1 or at another site. 5. Once users have successfully logged in, they have access to the shared company-wide corporate documents, as well as the site-specific documents. The site-specific universe and document domain is located at close proximity to the local Business Objects system. Corporate documents are periodically refreshed and published to site-specific document domains using Broadcast Agent during off-peak hours in USA1. Some users are allowed to create documents against the central data warehouse (as well as against their local data marts), publish documents to their site-specific document domains and send documents to other users.
197
Performance notes If most users are simply interactive users or passive readers (just opening or refreshing corporate documents without sending or publishing documents), this would exploit the benefits of the decentralized architecture. However, many of workflows require interaction with the security domain, so there will be traffic across the network to the security domain even with multiple document and universe domains. Remember, the universe domain in the USA contains universes for USA employees and the universes point to local databases. The Australia deployment is the same for Australian employees. In this type of situation, we suggest that in Supervisor you create high level groups on each region so if users publish etc., they only publish to the local document domain. Universes are segregated by region and use local data stores. If you have network bandwidth issues, duplicating your data may be an option if updating the network bandwidth is not. These duplicates would have the same database structure with a subset of the data specifically relevant to the particular site. Another place to maximize your performance is to pre-load the cache with Broadcast Agent. Whenever a user accesses a pre-loaded BusinessObjects document, or opens a document that another user with the same security rights has already opened (therefore is cached), the system is not being stressed. However, if users are going to use the inbox a lot, or you have complex userbased security, then you won't get the same gains as the cache won't be used as much. Using Broadcast Agent and enabling shared storage between the two clusters at each location (failover) is important.
198
Advantages and disadvantages Advantages Corporate documents open quickly because they are stored locally and users don't need to go across the WAN to get the information. Disadvantages Response times, especially for the refresh of document lists, could be adversely effected by WAN speed due to centralized Business Objects security domain
There is easy access to local data and If the WAN is down, the security generation of local documents. domain can be inaccessible to remote users. Users of BusinessObjects in 2tier mode, however, could use off-line mode for the analysis of existing documents. The Business Objects system can be The distribution of standard documents to remote users relies on more easily customized to meet the needs of a targeted user community or the WAN. site (albeit with high maintenance) Centralized security management ensures implementation of uniform standards and better control over access to information. Access to universe and document domains is less reliant on the WAN's performance. Administrative time can be extensive for new user setup, and modifications to user privileges with a centralized management of security domain can cause time delays for remote users. There are potentially increased costs due to additional support resources required at each site.
199
Advantages This scenario provides alternate routes to information. If a Business Objects system at one location is down, users can access information, perhaps at a premium on performance, by pointing to a Business Objects system at another location. Having Broadcast Agent replicated at each site allows you to preload the cache. Broadcast Agent replication means it takes less time to import/ export documents to the document domain for corporate documents intended for local users and less network traffic. If Broadcast Agent is replicated, only the data is sent back, while the .rep file is generated locally. Note: .rep files aren't always very large but if you have a lot of graphs, tabs, and calculations, the .rep file ratio size to the data set is necessarily larger.
Disadvantages If the Business Objects server and Broadcast Agent are not in the same cluster, you can't use the caching mechanism unless you use shared storage.
If you do not share storage across all locations (and this is not suggested due to the additional network traffic it would cause) and a user should then log into a different location, they will not have access to their personal documents. If you centralize Broadcast Agent, you gain time to refresh the document and easier administration, but you dont obtain performance improvements.
200
Global deployment scenario summary

Scenario 1 Architecture Repository Centralized Centralized Scenario 2 Decentralized Data Centralized Decentralized universe and document domains Centralized security domain Decentralized local data Centralized corporate data Decentralized local data Centralized corporate data
Distribution
Publish to central repository
Cost Performance Advantages
Least OK Less administration and deployment cost Centralized security
Moderate Moderate Quick response Access to universe and document domains less reliant on WAN Customized Business Objects system for local sites Login times adversely effected due to WAN If WAN is down, remote users cannot log in Distribution of new documents relies on WAN
Disadvantages
Performance adversely effected by network traffic If WAN is down, remote users cannot access system
chapter
202
Overview
This chapter provides background conceptual information on supported deployment configurations for Business Objects products. Although this chapter describes both 2- and 3-tier deployments, it focuses on the latter.
NOTE
These scenarios are not mutually exclusive. Some of the configurations described in this chapter are often used or even required in other configurations. As examples, DMZ configurations are always used in extranet deployments, and often figure in intranet deployments. And IP redirectors are a classic mechanism for providing load balancing and/or failover in any intranet or extranet solutions. At the end of each scenario description youll find a deployment profile table summarizing the advantages and disadvantages of each configuration. At the very end of the chapter, all of this information is recapitulated in one large table. To jump to this table, see Deployment configuration summary on page 238.
What this chapter does not provide

This chapter neither describes these configurations in detail, nor tells you how to implement them. For more detailed information and concrete implementation instructions, see Chapter 11.
203
Terminology
Certain terms are frequently used throughout this document and you should be aware of these terms before we describe the different supported deployments. If you are already familiar with these terms, just skip this section. Term Business Objects server Distributed system Intranet Description Cluster server on which Business Objects server components are installed. A Business Objects cluster in which processing is distributed over more than one machine. An intranet is a corporations private internal network. The main purpose of this network is to share company information and resources among employees. An extranet is a private network that uses the Internet protocol and the public telecommunication system to securely share part of a business's information or operations with suppliers, vendors, partners, customers, or other businesses. An extranet can be viewed as part of a company's intranet that is extended to users outside the company. Firewall A frequently used security mechanism in most Business Objects deployments. A firewall system can be a router, a personal computer, a host, or a collection of hosts, set up specifically to shield a site or subnet from protocols and services that can be abused from hosts outside the subnet. It implements a network access policy by forcing connections to pass through the firewall, where they can be examined and evaluated. A DMZ (DeMilitarized Zone) is a buffer zone between two firewalls. It creates a neutral zone between a companys private network (intranet) and the outside public network (internet), therefore preventing outside users from direct access to company data. It is the usual location for public web servers.
Extranet
DMZ
Terminology
204
Term IP redirector
Description An IP Redirector is a device that load balances TCP/IP traffic across multiple servers. For example, it receives HTTP requests and redispatches them to different web servers. An example of an IP Redirector is Cisco LocalDirector. A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests on to real servers, and relay answers back to clients. A reverse proxy deals with internal servers on behalf of external clients.
Proxy server
Reverse proxy
205
2-tier deployments
You can deploy the Business Objects solution over a standard client/server environment, which has some advantages over a 3-tier architecture deployment. These include faster response time, more powerful document design capabilities, and the creation of OLAP documents (although users can still access and process these documents through their browsers using InfoView).
Database
(Broadcast Agent) Client machines (BusinessObjects in 2-tier mode) Repository
Business Objects server
Figure 7-1 2-tier configuration
In a small deployment, the 2-tier architecture is more advantageous because it provides the most stable environment and fast and reliable service for your users. An additional benefit of having all components running on a single server is that you have only one server machine to maintain and there is less impact on the network bandwidth. The disadvantage of this kind of deployment, however, is that if your company grows rapidly, you will not be able to expand your network easily. As the number of users increases, performance will diminish and your system will be harder to maintain. If you start off with a small company with the intention of growing within the near future, you should consider a combined 2- and 3-tier architecture.
2-tier deployments
206
Deployment profile
Deployment Type 2-tier Pros Simple maintenance High performance Reliable service Cons Difficult to expand Performance diminishes with network expansion
207

Most enterprises today make use of 3-tier architecture deployments, taking into consideration the growing need to deploy business intelligence to the enterprise (intranet) and corporate customers (extranet). 3-tier architecture deployments allow for much larger deployments because components that are distributed over several servers optimize the use of the different server resources, thereby reducing the workload on the web server, and enhancing performance. In addition, UNIX operating systems are supported for this type of architecture. The following sections will help you understand Business Objects 3-tier deployment configurations. The list is not exhaustive, but it does represent some of the most common scenarios supported by Business Objects today.
REMINDER These scenarios are not all mutually exclusive. Many of them in fact require components discussed in scenarios of their own. All extranet deployments, for example, make use of DMZ configurations, and several scenarios require the use of IP redirectors.
Combined 2- and 3-tier deployments Basic intranet deployments Basic extranet deployments DMZ configurations Reverse proxies IP redirectors Multiple clusters in an intranet Alternative extranet deployment configurations - Single web server pointing to single primary node - Multiple web servers pointing to single primary node Single-cluster intranet/extranet deployment options - Single web server for intranet and extranet users - Multiple web servers within one cluster
208
Combined 2- and 3-tier deployments

In this scenario, you can combine a 2-tier environment with a 3-tier architecture deployment to give you the best of both worlds: client/server network stability and the flexibility of a 3-tier deployment.
Primary node Client machines of 3-tier system Database Web server Cluster
Application server Secondary Secondary node 1 node 2
Repository
Client BusinessObjects admin users machine
Figure 7-2 Combined client/server and n-tier architecture deployment
In a combined environment therefore, your employees benefit from the 2-tier version of BusinessObjects and Broadcast Agent, yet can also take advantage of Business Objects server products, as long as your client machines are connected to the internal network. In a 3-tier architecture deployment, the web server and the Business Objects software are most often installed on two different servers, with the web server hosted in a DMZ between two firewalls, and the Business Objects server behind the second firewall inside the companys corporate network (intranet). Your client/server environment sits within your internal network behind the second firewall and the client machines have direct access to the corporate databases.
209
The main advantages are that your clients can have access to controlled company information via the extranet and that you are fully scalable. So when your company grows in size, your deployment can easily grow as well.
Deployment profile
Deployment Type Combined 2- and 3-tier architecture Pros Network stability Simple maintenance High performance Reliable service Scalability Cons Business Objects system administration more complex
Combined 2- and 3-tier deployments
210
Basic intranet deployments

An intranet is a companys internal network based on TCP. Via an intranet company employees use Business Objects products to create, view, and share Business Objects documents and third-party files. This represents the minimal, no-frills Business Objects 3-tier deployment.
Deployment schema
Repository
Client admin machine
2-tier BusinessObjects users
Figure 7-3 Basic intranet deployment
211
In this case: The web server, application server and Business Objects cluster are installed either on the same machine or on separate machines, all inside the corporate intranet. As in all deployments, the management of users and resources is carried out by the same person managing the repository using Supervisor. Server applications are installed on a single server acting as primary node, or can be deployed over a multiple-machine cluster within the same subnet. Users of desktop products are connected to the repository and the corporate database. There is no firewall, no external failover or load balancing mechanism, no reverse proxy.
Deployment profile
Deployment Type Basic intranet Pros Simple to deploy and administer Cons No extra security, failover or load-balancing mechanisms
For more information

See page 344.
Basic intranet deployments
212
Basic extranet deployments

An extranet is a private network that uses the Internet protocol and the public telecommunication system to securely share part of a companys information or operations with suppliers, vendors, partners, customers, or other businesses. An extranet can be viewed as part of a company's intranet that is extended to users outside the company. With extranets, the Internet can provide a way to do business with other companies (business to business, or B2B) as well as to sell products to customers. Extranets require security and privacy. These require firewall server management, the use of digital certificates or similar means of user authentication, encryption of messages, and the use of virtual private networks (VPN) that tunnel through the public network. Companies can use an extranet to: exchange large volumes of data using Electronic Data Interchange (EDI) share product catalogs exclusively with wholesalers or partners collaborate with other companies on joint development efforts jointly develop and use training programs with other companies provide or access services provided by one company to a group of other companies, such as an online banking application managed by one company on behalf of affiliated banks share news of common interest exclusively with partner companies
213
Deployment schema
Internet users Application server Primary node
Web server Database Intranet
Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
Figure 7-4 Standard extranet deployment
The typical deployment strategy is: The web server and the Business Objects processing layer are hosted on two different servers. The web server(s) are hosted in a DMZ between two firewalls. The Business Objects server is hosted behind the inner firewall inside the companys corporate network (intranet). Users and resources are managed inside the intranet using Supervisor. Business Objects server components are installed on the web server in the DMZ in order to enable communication between the web server and the application server through communication ports on the firewall. All the nodes in a cluster must be deployed on a single network segment.
Basic extranet deployments
214
Deployment profile
Deployment Type Basic extranet Pros Simple to deploy and administer Cons No extra security, failover or load-balancing mechanisms
For concrete deployment instructions

See page 345.
215
DMZ configurations
For security purposes, most 3-tier Business Objects extranet and intranet deployments include a corporate intranet protected by double firewalls.
What is a firewall?
A firewall can be a router, a personal computer, a host, or a collection of hosts, set up specifically to shield a site or subnet from protocols and services that can be abused from hosts outside the subnet. It does this by implementing set rules which can be configured. A firewall rule looks like this: Authorize incoming TCP connections to <Host address> on <port> A firewall can greatly improve network security and reduce risks to hosts on the subnet by filtering inherently insecure services. As a result, the subnet network environment is exposed to fewer risks, since only selected protocols will be able to pass through the firewall. A firewall also provides the ability to control access to site systems. For example, some hosts can be made reachable from outside networks, whereas others can be effectively sealed off from unwanted access. A site can prevent outside access to its hosts except for special cases such as mail servers or information servers. Lastly, but perhaps most importantly, a firewall provides the means for implementing and enforcing a network access policy. In effect, a firewall provides access control to users and services. Thus, a network access policy can be enforced by a firewall, whereas without a firewall, such a policy depends entirely on the cooperation of users. A site may be able to depend on its own users for their cooperation, however it cannot and should not depend on Internet users in general.
NOTE
This section provides an overview of what firewalls are and how they work. For information on how to actually implement this type of configuration, see Implementing a DMZ configuration on page 347.
DMZ configurations
216
What is a DMZ?
A DMZ is the secure buffer zone between two firewalls erected between an organization's intranet and the Internet. It is designed to keep outside users from accessing sensitive company data or to limit access to restricted users. It is closely controlled by administrators so that only trusted processes are allowed to run on machines within the DMZ. These trusted processes are closely monitored, and if any abnormal behavior is observed, an alert is given and the inner firewall is shut. The two firewalls allow limited sets of ports to be open. Not only is each set of ports distinct from the other, but no one communication protocol can traverse both firewalls.
External users Application server Web server Network
Corporate database
Primary node Repository
Figure 7-1 Typical DMZ configuration
Communication through firewalls

All communication through firewalls uses the CORBA communication standard. In CORBA: Servers host objects and expose them through the naming, trading and locator services. Clients access objects through remote method invocation mechanisms, via the IIOP protocol.
217
To be able to talk to a server located behind a firewall: The client must be able to locate and access the object through the firewall. The server and CORBA location services must be started on fixed ports. The port used by the server and CORBA location services must be enabled on the firewall In a Business Objects system, each Orbix 2000 server uses its own TCP port for communication. This port can be either fixed by configuration or chosen dynamically from among free TCP ports (default).
Communication through firewalls

This type of configuration uses two types of communication protocols to traverse the two firewalls: HTTP TCP
Application server
Web server HTTP TCP
Secondary node Intranet
External network or Internet Primary node
Figure 7-2 Communication protocols in a DMZ configuration
The outer firewall, next to the external network or Internet, allows HTTP communication between the clients and the web server (and through it, the Business Objects cluster), by default through port 80. The connector on the application server machines is in charge of tunnelling the communication with the cluster. The inner firewall, next to the intranet, allows TCP traffic in both directions through the ports that the web server(s) and the application server are using to communicate.
DMZ configurations
218
Both firewalls practice filtering. They may also practice IP address translation (most deployments practice network address translation at the inner firewall to protect the intranets).
Deployment schema
Application server
Internet users
Primary node
Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
Figure 7-3 Typical DMZ topology
Client machines on the Internet can be web browsers, applets or standalone applications such as BusinessObjects. All these clients communicate in HTTP with the web server(s) in the DMZ. Web servers are always deployed within the DMZ. You can deploy several web servers if you want. The application servers are always deployed inside the intranet; an appropriate connection module is plugged into the web server(s) in the DMZ with which the application servers are communicating. The application server constructor provides these connection modules. The communication between the web servers and application servers occurs via these connectors, through a restricted number of TCP ports, ideally one per server.
219
Constraints
In this configuration, data exchange between the clients and the database servers is not supported. However, all Business Objects downloads and installations through InfoView, such as the various applets and BusinessObjects in 3-tier mode, are supported.
Deployment profile
Deployment Type DMZ configuration Pros Simple to deploy and administer Cheap Easy to maintain Cons Not very sophisticated on a security level

See page 347.
DMZ configurations
220
Reverse proxies
In extranets in particular, web servers represent one of the systems weakest points. This is not only because they are usually deployed inside the DMZ (and therefore closest to the outside world) but because you need to rely on application security. You can protect sensitive information on your web server by deploying a DMZ between two firewalls and using a reverse proxy to protect your Business Objects server(s) from direct uncontrolled access from extranet clients. You can shield web severs using a reverse proxy. A reverse proxy is a proxy server which appears to be a normal web server to clients, but in fact re-routes user requests to a machine deeper into the network (and with a different name, and IP address). The responses from the web server get routed via the reverse proxy back to the client browser. The word reverse refers to the inverted role of the proxy server. While normal proxy servers act as a proxy for the client (the request is made on behalf of the client by the proxy server), a reverse proxy services requests on behalf of the server, in this case, the Business Objects cluster.
How reverse proxies work with Business Objects

In reverse proxy configurations, extranet user requests to your site go straight to the reverse proxy. The reverse proxy sends this request to the web server, which sends the request on to the Business Objects cluster for processing. The result is then passed back to the web server, which sends it back to the reverse proxy. The reverse proxy sends the information to the extranet user as if it were coming directly from the actual Business Objects server. The real URL address of your site is thus not revealed to outsiders. Since the reverse proxy does not run any scripts, the system is less vulnerable to attack. The hacker may still try to tunnel through to the web server, but it is harder to determine which port the web server listens on, and it will be difficult to get the proxy to route any responses back. Since the reverse proxy itself does not execute anything, and fine-grained routing rules can be set up, the use of a reverse proxy will keep a lot of unwanted guests out from even trying. For more information, see the Business Objects Security Guide.
221
Deployment schema
In this schema: The outer firewall provides access control for users trying to use the system from the Internet. The reverse proxy provides authentication and data control.
Internet users
Application server
Security server
Web server Database Intranet Reverse proxy Outer firewall
DMZ
Inner firewall
Repository
Primary node
Secondary node
Figure 7-4 Reverse proxy configuration
Although technically you can place the reverse proxy outside the outer firewall, compelling reasons to have the reverse proxy within the DMZ include: With the reverse proxy inside the firewall, it benefits from the protection of the outer firewall. The reverse proxy may need to cross the DMZ to access the security server in the intranet. As the outer firewall allows HTTP access only, it would not permit this connection.
Reverse proxies
222
Deployment profile
Deployment Type Reverse proxy Pros Increased security Single point of access Cons Not easy to configure
223
IP redirectors
The IP redirector is a device that load balances TCP traffic across multiple servers by receiving user requests then redispatching them to different web servers. This section describes how you can use an IP redirector to provide load balancing and failover features for Business Objects clusters.
What Business Objects software/tasks can use an IP redirector

The following Business Objects products and tasks make use of the features of an IP redirector: BusinessObjects in 3-tier mode navigating in InfoView viewing and refreshing BusinessObjects documents in InfoView viewing and refreshing WebIntelligence documents in InfoView creating WebIntelligence documents with WebIntelligence
What Business Objects software/tasks cant use an IP redirector

The following Business Objects products and tasks cannot use the features of an IP redirector: Administration Console In order to administer several clusters, the Console needs to connect directly to the web server. Desktop products (BusinessObjects, Designer, Supervisor) These tools query the repository directly, without accessing the web server or the Business Objects cluster. Broadcast Agent This tool does not go against the web server. However, it does have its own load balancing mechanism, and for failover, the same Scheduler can be started on each cluster. Broadcast Agent Console The Broadcast Agent Console queries the repository directly, without going against the web server. It can also connect directly to a single cluster for administration purposes. Audit facility The audit facility may not work properly as the session ID can be the same for two different clusters.
IP redirectors
224
Configuration options
You can use an IP redirector for with Business Objects for many different reasons and configurations: Type of configuration Description
Single virtual web server Users always point to the same virtual web address and multiple physical and their requests are then sent to each of the web servers physical web servers. Multiple virtual web servers and a single physical web server Multiple virtual web servers and multiple physical web servers Maximum connection and weighted configuration Users specify different virtual web addresses on a single port and their requests are then sent to the same physical web server but on a different port. A number of virtual web servers access a number of physical web servers. You configure the IP redirector to load balance to each physical server by specifying the maximum number of connections you want for the server and/ or the weight of each server (according to the servers power). Once a connection is opened to a physical server, any requests coming from a particular client always go to that server, until either the timeout is reached or the user session is terminated. All requests coming from a specific client always go to the same physical server. This is done through recognition of the clients IP address. This solution provides no failover; if the web server or the primary node is down, the client cannot connect to any server machines.
Sticky command enablement
Client-assigned load balancing
225
Deployment schema
The following diagram shows an example of how you can incorporate the IP redirector in the network topology. In this diagram, the IP redirector is depicted graphically in a particular place in the network, even though it is in actual fact only present logically.
Cluster A
Web server 1 Internet users
Application server for cluster A
IP redirector Network 1 Switch or router or hub Network 2
Repository
Corporate database
Web server 2 Outer firewall Inner firewall
Application server for cluster B
Cluster B
Shared storage
Figure 7-5 Deployment schema for an IP redirector
NOTE
Each of the servers in the cluster must be running exactly the same version of the Business Objects server products. The same Business Objects modules must also be installed and enabled. If this is not the case, a user may need a specific module that is present on one server and not the others.
IP redirectors
226
Constraints
The sticky command, which ensures that all the requests from a particular client are directed to the same real server, retaining the statefulness of the client/server connection, does not work well if a proxy is used in the deployment. In this case the IP redirector can see the proxys IP address only. Due to the enablement of the sticky command, it redirects calls systematically to the same cluster. This is mostly the case in extranet deployments.
Web server for cluster A
IP redirector with the sticky command enabled Network 1 Proxy
Network 2 hosting clusters A and B
Outer firewall Web server for cluster B
Inner firewall
Figure 7-6 IP redirector with sticky command enabled
Deployment profile
Deployment Type IP redirector Pros Provides load balancing and failover Cons Does not efficiently redirect calls in deployments with proxy servers

See page 348.
227
Multiple clusters in an intranet

You may want to deploy multiple primary nodes and therefore multiple clusters using shared storage with the help of an IP redirector such as Cisco LocalDirector (see IP redirectors on page 223). In this scenario, each cluster has its own web server and Business Objects server product installation, though this is completely transparent to the user.
Deployment schema
Web server/ Primary node IP : port
34.2.148.10:80
Intranet users
12.10.150.20:80 34.2.148.11:80
incoming IP : port
IP : port
IP redirector
Shared storage server
34.2.148.12:80
IP : port
34.2.148.13:80
IP : port
Figure 7-7 IP redirector with multiple clusters
228
The workflow of the IP redirector is: A request is sent to the IP redirector, acting as a proxy. The IP redirectors IP port listens for HTTP requests and maps these requests to one of the four primary nodes using its IP port. Users log into InfoView using a single URL address and are then redirected to the next available web server. The Business Objects session duration is determined by timeouts, set using the Administration Console. Each time a user logs into InfoView, a session is created and a WIQT instance is allocated to it. By default the WIQT is set to stay in memory for one minute after the last user activity. During this session users are redirected to the same server using a sticky IP set dependency. The sticky command ensures that once a connection is opened to a physical server, requests from this client will always go to the same physical server until the timeout is reached, thus maintaining the stability of the client/server connection. All four primary nodes share the same storage server. Saved and corporate documents are accessed via the shared storage. For instructions on implementing storage on a separate server, see the Installation and Configuration Guides.
229
The following diagram shows how a request from a user is redirected to web server B in the event of a primary node failure on server A:
Web server/ primary node A failure

1. Us ru er na req va ue ila st ble
34.2.148.10:80 Web server/ primary node B

st
IP: port
2.
dir ec ted
re q
12.10.150.20:80
Se rv e
incoming IP: port
ue
IP: port
34.2.148.11:80 Web server/ primary node C
User
IP redirector
Re
3.
34.2.148.12:80 Web server/ primary node D
IP: port
IP: port
34.2.148.13:80
Figure 7-8 User request redirected to next web server/primary node
Note that if a primary node fails and the web server is still working, the clusters application server can send an HTTP error message back through the web server to the IP redirector, which can then redirect the request. When a web server fails, however, the IP redirector is instantly aware of it and automatically redirects the request.
230
Deployment profile
Deployment Type Multiple clusters in an intranet Pros Cons
Provides failover for None primary nodes and Broadcast Agent Schedulers Allows use of multiple repositories Provides a way to have server machines in multiple time zones
231
Alternative extranet deployment configurations

When deploying the Business Objects solution in an extranet environment, you have a number of options: Single web server pointing to single primary node Multiple web servers pointing to single primary node In all of these scenarios, the web servers are installed in the DMZ with an IP redirector to balance the load between them, and therefore between clusters (see IP redirectors on page 223).
Single web server pointing to single primary node

Although this type of deployment can actually support several web servers and several clusters, each server communicates with a single primary node and vice versa (the communicating web server/primary node must be in the same cluster).
232
Deployment schema
Cluster A Web server A Internet users Primary node
Cluster B IP redirector Web server B Primary node
Cluster C Web server C Primary node
Outer firewall
DMZ
Inner firewall
Figure 7-9 One web server pointing to one primary node
Summary of a typical deployment strategy: The web servers are installed in the DMZ with an IP redirector to balance the load. Each web server directs the request to the primary node it communicates with. The Business Objects servers are installed behind the inner firewall. The web servers are in the DMZ, each one communicating with its specific cluster. Configuration requirements If cluster As primary node goes down for any reason, the whole cluster is unavailable. In this case, web server A might still try to contact cluster A, but fail to do so. Since the web server is being accessed through an IP redirector, the web server might still be running, so the failure of the Business Objects server needs to be detected and reported to web server A.
233
You can make sure this happens simply by configuring the IP redirector to recognize the HTTP errors returned by this type of failure. For information, see When the primary node fails on page 352. Deployment profile Deployment Type Single web server pointing to single primary node Pros Cost-effective Simple to implement Cons Single points of failure: web server or primary node
Multiple web servers pointing to single primary node

You can run multiple web servers that point to the same Business Objects primary node. This strategy is useful because it helps balance the server load. To deploy this type of solution use either of the following: one URL for each web server one URL for all of the servers In this case, an IP redirector then redirects the traffic using the one URL.
234
Deployment schema
Web servers Primary node
Extranet users
IP redirector
Intranet
Database
Repository Application server Outer firewall Inner firewall
Figure 7-10 Multiple web servers pointing to one primary node
Here, four web servers are running with an IP redirector to balance the server load amongst them. They all point to the same primary node in the intranet. The only disadvantage here is that there is a single point of failure: the primary node itself. If the primary node goes down for any reason, your entire system goes down with it. Deployment profile Deployment Type Multiple web servers pointing to single primary node Pros Balances server load Balances out network resources Cons Single point of failure: primary node
235
Single-cluster intranet/extranet deployment options

Though you can use multiple Business Objects clusters to differentiate between intranet and extranet usage, you may sometimes need to deploy both types of users on a single cluster. This section describes two different scenarios for this type of deployment.
Single web server for intranet and extranet users

In this scenario, you use a single web server for both your intranet and your extranet users. Deployment schema
Extranet users Application server Web server Database Intranet Primary node
Repository Proxy server Intranet users
Figure 7-11 Running one web server within a single cluster
In this case, you have one server in the DMZ as your web server, much like the standard extranet deployment. All your extranet users come from the exterior firewall and use that web server, whereas your intranet users come into your system either through the inner firewall or through another proxy in your intranet.
236
Deployment profile Deployment Type One web server within one cluster Pros Improves security Simpler network administration Cons Multiple points of failure: primary node and web servers
Multiple web servers within one cluster

You can use multiple web servers to enable both intranet users within your firewall and extranet users outside your firewall to contact the Business Objects server.
Extranet users Database Web servers Primary node
Repository Outer firewall Inner firewall Intranet web server
Intranet users
Figure 7-12 Multiple web servers with a single cluster
This is a good solution for a single-cluster deployment that enables you to customize one web server for your particular needs. The only disadvantage is that it requires more maintenance, as there is another point of access.
237
Deployment profile Deployment Type Multiple web servers within one cluster Pros Good security Cons Primary node is a single point of failure More maintenance, due to more entry points
238
Deployment configuration summary

The following table gives you a concise overview of the advantages and disadvantages of the different configurations described in this chapter. Deployment Type 2-tier Pros Simple maintenance High performance Reliable service Network stability Simple maintenance High performance Reliable service Scalability Cons Difficult to expand Performance diminishes with network expansion
Combined 2- and 3-tier architecture
Business Objects system administration more complex
Basic intranet Basic extranet
Simple to deploy and administer Simple to deploy and administer Cheap Easy to maintain Secure Simple Easy to implement Increased security Single point of access
No extra security, failover or load-balancing mechanisms Not very sophisticated on a security level
DMZ configuration
Can lower performance
Reverse proxy IP redirector
Not easy to configure Does not efficiently redirect calls in deployments with proxy servers
Provides load balancing and failover
239
Deployment Type Multiple clusters in an intranet
Pros
Cons
Provides failover for primary None nodes and Broadcast Agent Schedulers Allows use of multiple repositories Provides a way to have server machines in multiple time zones Cost-effective Simple to implement Balances server load Balances out network resources Multiple points of failure: web server and primary node Single point of failure: primary node
Single web server pointing to single primary node Multiple web servers pointing to single primary node One web server within one cluster Multiple web servers within one cluster
Improves security Multiple points of failure: Simpler network administration primary node and web servers Primary node is a single point of failure More maintenance, due to more entry points
Good security
Deployment configuration summary
240
Installing and Configuring the System
III
part
Installing the Products
chapter
244
Overview
Once you have given adequate consideration to the critical deployment issues discussed in the previous chapters, you are ready to actually get your Business Objects system up and running. This chapter outlines the first concrete steps in the deployment procedure: 1. pre-installation steps 2. installing Business Objects server and desktop products, either for the first time, or upgrading from previous versions Keep in mind that this is just an overview. For concrete and detailed instructions on installing Business Objects products, see the Installation and Configuration guides.
245
Pre-installation steps
Before actually installing the Business Objects products required for your deployment, you must have: installed RDMBS middleware supported by this version of Business Objects During Business Objects installation you can then install the relevant data access driver. installed your deployments web and application servers You can install your web server and application server on any type of node, depending on your deployment plan. They neednt be configured yet. You will do that after installing the Business Objects products using the Configuration Tool. retrieved license files and copied them into the directory from which the products will access them at runtime See the following section.
Pre-installation steps
246
Copying the license file to each machine

When a company buys Business Objects products, Business Objects ensures that the company gets a corresponding license file (for instance, via a download from the Business Objects Manufacturing website). This license file is a readable, signed XML file. It cannot be modified. The license file contains the list of licensed products, the expiration date for each product (in the case of a trial key) and the number of licenses purchased for each product. When a company buys additional products or transforms its trial period to a firm purchase, a new license file is issued. You simply add this file to the license directory of the Business Objects suite (no new installation needed). In case of a conflict between the different license files, the license check mechanism uses the highest level of privileges it finds.
What is checked and when?

Licenses are checked: at installation time, at which point any unlicensed products are not installed at runtime
Where do you store your license files?

At installation time, you specify the directory that will contain all license files for Business Objects products. This is required for both desktop and server installations. This directory must contain at least one valid license file. If you obtain additional licenses, you need to install their files in this directory as well. Business Objects recommends you use a shared folder on the network for this. If this is not possible, make sure that all the nodes in a cluster contain the same set of license files. Keep in mind that if additional license files are procured, they must be deployed in that directory on all nodes. Desktop products implement a mechanism that ensures that there is no license check error when the user is not connected to the network.
247
Fresh installation or upgrade?

If this is the first time youre deploying Business Objects products in your company, you will be making a fresh installation. If youre already using Business Objects, you will need to upgrade your current version to the current version. This process varies depending on the version you are currently running, because you cant necessarily upgrade from your version directly to this one.
How risky is upgrading?

Can you upgrade from one Business Objects major release to the most recent one without risking the considerable investment you made in your original deployment? Absolutely, but only if you follow the procedures described in detail in Migrating from a Previous Version.
Fresh installation or upgrade?
248
System requirements
System requirements may change with different releases and service packs.To make sure you have the latest information on supported platforms and products, always consult the ReadMe delivered with a new release or service pack.
249
What do you install on what machines

Where you install Business Objects products depends on the actual products your users require and therefore the type of deployment you are implementing.
Installing a 2-tier environment

A strictly 2-tier environment includes desktop products only. In this scenario, you must install at least the main desktop products BusinessObjects, Supervisor and Designer on the computer of every user who will be using those products. Typically, you will install many more instances of the end-user product BusinessObjects than the other two, which are required administration products.
Installing a 3-tier environment

A 3-tier deployment relies not only upon the Business Objects server products, but also on the web and application servers through which the processing components in the Business Objects cluster communicate with the systems clients.
What do you install on what machines
250
In a 3-tier configuration, therefore, the following Business Objects components must be installed on the following machines: System component What must be installed Cluster nodes Business Objects server components Administration Console (on primary node) The Configuration Tool Optional: Server products (when any server product is installed, all Administration products except Auditor are automatically installed as well) Web server pages (option under InfoView in the Installer) A third-party application server connector if the application server is on a separate machine than the web server The Configuration Tool (to configure the web server) Application server pages (option under InfoView in the Installer) The Configuration Tool (to configure the application server and the ORB so that it can communicate with the cluster machines)
Web server
Application server
Client machines
Any or all of the following: Desktop products (installed on the machines of their users) Administration products Demonstrations
NOTE
Installing third-party web and application servers
You can install your web server and application server on any type of node, depending on your deployment plan. There are some deployments, however, in which you do not want your web server(s) to be part of the cluster, most commonly where you have implemented a DMZ. You must still, however, install the Configuration Tool on both application and web servers to configure them as client nodes and to define them as entry points.
251
Installing on Windows machines

You can install all Business Objects products on WIndows machines. Within the installer, these are grouped into the following categories: Server products such as InfoView and WebIntelligence Desktop products such as 2-tier BusinessObjects Administration tools such as Supervisor and the Administration Console Data Access packs Demonstrations The principal Business Objects products are described briefly in Chapter 1 of this guide.
What rights are required for installing Business Objects products?

Under Windows, you must have one of the following: Administrator rights for the machines on which you are installing the products special installation rights granted you by the system administrator
The Business Objects Windows installer interface

The Business Objects Windows installer has a graphical interface based on the standard Windows installer service.
Figure 8-1 Welcome screen for the Windows installer
252
Windows installer is the standard Microsoft installation technology on Windows 2000/XP and future releases, ensuring full compatibility with the user rights policy on Windows 2000/XP. This means that standard users with restricted rights (with write permission on their profile directory only) may install the desktop products with no restriction.
NOTE
With the WIndows installer, you cannot install more than one instance of the Business Objects solution on the same machine.
The installation process

When you first launch the Windows installer, it takes you through a set of preinstallation checks and choices including determining if Business Objects products are already installed, checking for a valid license, and setting a default language. Once these preliminaries are over, you must choose what type of installation you want to run. First installation The first installation wizard is simple. After accepting the license agreement and reading the installation notes, you: Type the name of the folder containing the license files. Select the languages to install and the default language for all products. Choose the installation type. This is described in the following section. Installation types Many product components and mechanisms are shared between desktop and server products. The installer manages the inter-relationships between common components at a file level, and also at a Registry level when installing or upgrading products (same entries on the registry, product keys, etc.). We therefore refer not to installing server or desktop products, but to server or desktop installations. The installer proposes three types of installation: Desktop installation Server installation Custom installation
253
Figure 8-2 The Installation Type screen in the Windows installer
A Desktop installation installs all the products that may be useful in a desktop environment, including administration tools. A Desktop installation therefore also installs Supervisor, though it is of course not useful to all users. A Server installation installs all the products that are useful on server machines, i.e. machines that will be used as servers in the 3-tier Business Objects system. This means that an administration product such as Supervisor is installed in a server installation because it is required in a 3-tier system to administer users from the server. A Custom installation installs only the products and features that you select. Products are grouped in desktop products, server products, administration products (e.g. Supervisor, the Configuration Tool, and so forth), Database Access Packs and Demonstrations.
254
Figure 8-3 Custom Setup window in the Windows installer
Administrative installation When installing under Windows, you have the option of performing an administrative installation. This allows you to install an uncompressed image of the Business Objects suite, similar to a CD-ROM image, at a chosen network location. This installation does not enable the administrator to choose what to install all features are potentially available. Users can then launch the setup from the common network location. During the installation, they can choose to install or "run from network" any of the packages.
255
Segregating desktop and server products Desktop products and server products should not be installed on the same server machine. In particular, using 2-tier BusinessObjects on the same server machine as server products can cause unreliable operation of BusinessObjects and is not supported. In addition, any administrative installation of desktop products launched from a machine hosting server products will not install the Setup utility, making subsequent uninstallation on the client machine impossible.
NOTE
Note:
An exception to the rule: Supervisor, Designer and the Administration Console are Desktop products, but you can install them safely on server machines.
Where are the programs installed?

The installer manages the installation of all Business Objects products. All products are installed inside the main Business Objects 6 folder. This is the folder in which all other folders will be created.
256
Installing under UNIX

You can install all Business Objects products except desktop products on UNIX machines. Within the installer, these are grouped into the following categories: server products such as InfoView and WebIntelligence administration products such as the Administration Console or the Diagnostic Tools data access packs demonstrations The principle Business Objects products are described briefly in Chapter 1 of this guide.
What rights are required for installing Business Objects products?

Under UNIX, users can install Business Objects products into any directories to which they have write permissions.
The UNIX installer interface

The Business Objects installer for UNIX comes with an improved look and feel, with a considerably more interactive interface. This interface, as in previous versions, requires you to select items in alphanumeric menus, using the keyboard exclusively.
Figure 8-4 Screen from the Business Objects installer for UNIX
The Business Objects UNIX installer is written with internal proprietary scripts which copy the Business Objects files into authorized directories. The installer does not, however, use other vendors specific installation commands (pkgadd for Solaris, swinstall for HP-UX or installp for AIX).
257
Launching the installer

Although you can install Business Objects products on Solaris, AIX or HP-UX platforms, you launch the UNIX installer using the same command: winstall. This command is on the installation CD.
The installation process

When you first launch the UNIX installer, it takes you through a set of choices including the installation and license directories, language selection, then the products you want to install.
Figure 8-5 Selecting products for installation in the UNIX installer
Where are the programs installed?

All products are installed in the directory specified during installation. By default it is /opt/BOBJ/Enterprise6.
Installing under UNIX
258
Installation update, repair, uninstallation

Installation is never a one-shot operation. In the course of your deployments life cycle you will regularly return to the Business Objects installer to update your installation, restore missing or corrupted files, or even uninstall in order to install a more recent version.
Under Windows
After the first installation, you can use the Windows Add/Remove Programs facility in the Control Panel or rerun the Business Objects installer for maintenance operations. A panel appears with the following choices: Update the installation. You can add/remove features, but also install extra languages or uninstall them. Repair the installation. In case a file was deleted in the installation directory, this standard Windows installer feature allows you to restore the correct installation. Uninstall the software.
Under UNIX
You use the wupdate script to: add/remove components remove the installation entirely This command is located in the $INSTALLDIR/setup directory.
259
Installing Service Pack updates

When you install Service Pack updates on top of an existing installation, the procedure is similar to a new installation, allowing you to read the new installation notes, change the license directory and so forth before actually choosing which products to install.
REMINDER You cannot simply replace BusinessObjects 4.1 with version 6, or WebIntelligence 2.0 with 6.x! You will find a detailed procedure for updating in Migrating from a Previous Version, on the Business Objects ongoing documentation website.
Installing Service Pack updates
260
Installing BusinessObjects from InfoView

As in previous versions, users may choose to view BusinessObjects documents with BusinessObjects in 3-tier mode. The first time they need to launch BusinessObjects from the portal, they have the opportunity to download and install BusinessObjects on their desktop computer. Additionally, users can now install BusinessObjects from a new InfoView page, the Installation page. Administrators can customize the page to propose the download of other products of the suite, or of third-party products. For information, see the Developer Suite documentation on the Business Objects Online Customer Support website. Installing BusinessObjects from InfoView involves the same installer as the one present on the CD-ROM, which ensures global consistency between downloaded products and those installed from the CD-ROM. Of course, only those packages necessary to BusinessObjects are effectively downloaded.
261
Tips for the mass installation of desktop products

You may find yourself faced with the mass installation of the Business Objects desktop products BusinessObjects and BusinessQuery over tens, hundreds, or even thousands of workstations throughout your organization. In this situation, we recommend using the installer in command line mode, which provides important flexibility and usability through the following possibilities: a silent installation, which is a batch installation requiring practically no interaction from the administrator running the installation the installation of any specified subset of Business Objects features Another option is the administrative installation, which allows you to install a decompressed distribution image on a network location. Using this image, users with access to that location can install the Business Objects desktop products themselves. See page 254. For a detailed explanation of what happens when users download 3-tier BusinessObjects from InfoView, see How the Business Objects System Works.
Tips for the mass installation of desktop products
262
How has installation changed?

Installing Business Objects products has never been simpler or more intuitive. This is due in part to overall changes in the installation process, and in part to improvements in the installers on each platform.
Installation no longer includes cluster configuration

One of the biggest differences in this installer compared to previous versions is that the configuration of the Business Objects solutions cluster architecture is no longer part of installation. Therefore, for example, in Server installations, you no longer choose an installation profile to determine whether you are installing a primary node (cluster manager in pre-version 6 terminology) or a secondary node (cluster node). The configuration of the various nodes in the cluster and the ORB, which provides the inter-process and inter-machine communication within the cluster, is now carried out in a post-installation procedure using the new Configuration Tool. For an overview of this process, see Getting the System Up and Running on page 267. For complete information, see the Installation and Configuration guides.
New licensing scheme

The new Business Objects licensing scheme is based on a set of signed (nonmodifiable) XML files. Each of these license files describes the licensed products and includes the name of the company that purchased them. When you purchase new licenses, you obtain an additional license file, which you simply installs in your license folder, as defined at installation time.
263
The new licensing scheme provides the following benefits: Users can now easily obtain information about their licenses by looking at the XML files, or, for an even better view, Windows users can launch the installer and click the Check License button.
Figure 8-6 License check
Adding new licenses simply means adding a file in the license folder and, if necessary, installing the newly licensed product. At the end of a trial period, users just need to add the license file, since the product is already installed.
264
The installer on Windows

Beyond the cross-platform improvements described in the section above, the main features of the new installer on Windows and their benefits are: Full Windows 2000/XP compatibility Besides using Windows installer, a must for being compliant to the Windows 2000 logo, BusinessObjects Enterprise 6 ensures a full compatibility with the user rights policy on Windows 2000/XP. Administrative installation This standard Windows installer feature replaces the former proprietary Master/ Shared feature of the Business Objects 5.x installer. It allows you to install an image of the distribution (CD-ROM) on the network, from which users can subsequently install Business Objects. Command-line mode The Windows command-line mode allows you to install any product and select available options such as the languages to install, in interactive mode. One of the most useful options allows you to perform a silent installation, which makes it possible to call the Business Objects installer in various scripts or during the installation of other products.
265
The installer on UNIX

Beyond the cross-platform improvements, the main new features of this installer are: More specific installation choices The distribution is split into products and languages. You can choose which products and languages you want to install. Depending on your choice, only the mandatory files will be copied. To uninstall one or several marketing products or languages, the corresponding files are removed. Rights required for installation In previous versions, you had to have root privileges in order to install Business Objects products. With this release, you need only a user login on the machine. This user login must have write privileges for the directory in which you want to install Business Objects. Integration of Business Objects within other business applications Business Objects products can be sold in a complete Business solution and be installed with other products. In this case, the Business Objects installation is encapsulated in another installer and must be run by this installer. In order for this operation to be done transparently, the Business Objects installer is available in command-line modes as well as in standard interactive mode. For more information, see the Installation and Configuration guides.
266
chapter
268
Overview
Your web and application servers are installed. The databases you will be using as your deployments centralized repository and as storage for corporate data are installed and configured. The Business Objects products required in your 3-tier system are now installed on the correct server machines. Before you can use the system, however, you must now configure its components to work together as a single Business Intelligence system, and create the reporting environment in which this system will function. This chapter provides an overview of how to: use the Configuration Tool to configure your web and application servers, and set up the cluster(s) which constitute the infrastructure of your Business Objects Business Intelligence solution create the repository at the core of the system, then organize users into groups and individuals with specific access rights create the .key file required for clusters to access the repository set connectivity environment variables on UNIX servers create and export to the repository the universes users will use to create documents start the system use the Administration Console to enable/disable and tune the Business Objects modules on specific cluster nodes set both cluster and user locales create and share Business Objects documents
269
How has configuring and starting the solution changed?

The biggest change in how you get the system up and running once the Business Objects products are installed is that up until now, you configured the clusters in your deployment during the installation process itself. With BusinessObjects Enterprise 6, the installation and the configuration of your system have been separated into two distinct phases.
How has configuring and starting the solution changed?
270
Configuring the server system

During the installation of Business Objects server products on the machines in your deployment, an administrative application called the Configuration Tool was also installed on the machine. The Configuration Tool provides you with the means to configure your 3-tier deployments ORB and third-party components so that the ASF starts a specific set of Business Objects server processes whenever the node is started, and so users can access the Business Objects system through client applets or applications such as web browsers, report editors or viewers, 3-tier BusinessObjects, etc. Using the Configuration Tool, you: configure the servers on which you have installed Business Objects products as elements of a cluster set up a minimal Business Objects configuration so that the server products can run on the clusters nodes deploy the solutions third-party components through which the client components access the solution, including: - web servers - application servers As your deployment evolves, you can use this tool as often as necessary to configure, reconfigure or remove a cluster node, even if the setup is not involved.
271
Typical configurations
There are three typical configurations: separate machines for the web server, application server and the Business Objects cluster itself (1 web server machine, 1 application server machine, 1 primary node, 0-n secondary nodes) a cluster which incorporates the web and application servers (1 machine hosting the web server, application server and primary node, as well as 0-n secondary nodes) a single-machine cluster (1 machine hosting the web server, application server and primary node) In clusters, web applications are not deployed on every cluster node because every cluster node does not have an application server and/or web server.
On what machines do you need to run the Configuration Tool?

The Configuration Tool has been installed and must be run on all the machines you will include in the cluster. If the clusters web and/or application servers are hosted on machines not intended to be cluster nodes, you must run the Configuration Tool on those machines as well.
NOTE
For a summary of precisely what needs to be installed and configured on the clusters web server(s), application server and cluster nodes, see Deployment rules for all configurations on page 339.
Who can use the Configuration Tool?

Anyone with the rights required to administer the deployments web server, application server and Business Objects server machines.
272
In what formats is the Configuration Tool available?

This cross-platform Configuration Tool is available in: a graphical version providing an intuitive workflow that you can display in any of several languages:
Figure 9-1 The English graphical interface for the Configuration Tool
command line mode requiring no human intervention beyond the initial definition of parameters This format is practical for companies using automatic installation tools for mass, multinational deployments from a centralized corporate IT service.
273
How do you launch the Configuration Tool?

You can launch the Configuration Tool under Windows: directly from the Business Objects graphical Windows installer (this is the default with this installer) by choosing Start > Program > Configuration Tool by running config.bat (Windows) You can launch the Configuration Tool under UNIX by running config.sc from the command line.
274
Using the Cluster Configuration Tree

In the Configuration Tool, the point of departure for defining any type of cluster is the Cluster Configuration Tree (in the screen capture below, the clusters name is o2kAuto):
Figure 9-2 The Configuration Tools Cluster Configuration Tree
To define a server machine as a cluster node, you must: name the cluster to which it belongs specify the paths of the clusters principal directories, including the storage data directory ($STORAGEDIR), LocData, Scripts, universes, etc. configure the ORB for all the machines that are running ORB clients or servers
275
deploy the Business Objects web application components to the web and application servers by: - adding the web application - defining the web and application servers on which this application is to be deployed specify the application instances that run on this node (you must also do this for any machine on which a web or application server is running) As a minimum, you must enable an instance of Business Objects server, which represents the server systems backend.
How you define a cluster

You define a Business Objects cluster by giving it a name, creating a primary node (then optionally, secondary nodes), and a set of ports used for Orbix and ASF internal services. (For more information about the ASF, see The Application Server Framework on page 87.) A Business Objects cluster contains four types of nodes: the primary node runs the ASF daemons plus the ORB locator, node daemon, and the naming and trading services daemons It hosts all mono-instance (one instance per cluster) processes and can host multi-instance processes. The primary node is roughly equivalent to what was called the cluster manager in previous releases. one or more optional secondary nodes running ASF daemons, the ORB locator and node daemon It hosts multi-instance cluster processes only. Secondary nodes are equivalent to cluster nodes in previous releases. one or more client nodes, containing the ASF and Orbix libraries If the application server is running on a machine separate from the nodes hosting Business Objects processing server components, you must configure the machine as a client node to enable the application server to communicate with the rest of the cluster through the ORB. Client nodes are silent nodes in that they do not actively participate in the cluster. They do not have services such as the report engine or Business Objects server enabled, but they allow you to use application and web servers outside the cluster. The client contains the ASF and Orbix libraries which enable communication with a cluster.
276
Configuring application and web servers

You must configure your web and application servers to act as entry points for the cluster. In some deployments you may not want your web server to be part of the cluster, most commonly when you have implemented a DMZ. You must nonetheless install the Configuration Tool on both the application and web servers to configure them as client nodes and to define them as entry points. Client nodes, despite the name, only allow communication between themselves and the cluster. A server configured as a client node is not part of the cluster itself. Entry points You need to configure each web server and application server used by the cluster as an entry point for cluster users. There are two types of entry points: InfoView Allows all users of the cluster access to the InfoView HTML pages on the web server and Active Server Pages/Java Server Pages on the application server. Admin Allows administrators using the Administration Console access to the administration HTML pages on the web server and Active Server Pages/Java Server Pages on the application server. Linking the web server to the application server Although web servers do not in themselves require application servers to run, this version of Business Objects requires a web server linked to an application server because it uses ASP and JSP pages. Linking a web server to an application server is usually done by means of an addin produced by either the web server or the application server manufacturer. You must link the two according to the instructions of the third-party software provider before you configure your Business Objects installation.
277
Setting up storage
When you configure the cluster, you can choose which server or servers on which you want to actually store the systems cached, temporary and saved documents and files. This is the directory WIStorageManager will use. For performance reasons, it is often good policy to locate these files on separate disks or machines. You can thus better control where the heavier transaction loads are likely to occur, and avoid bottlenecks before they happen. Ideally, the clusters storage should be placed outside the cluster configuration on a fast file server drive, such as a RAID0 or 0+1 drive. This facilitates sharing if the primary node fails. The same storage can be shared by multiple servers in the same cluster, or by multiple clusters, provided that they use the same repository.
NOTE
If you are using a configuration with an IP redirector, you must use shared storage. For more information, see the Installation and Configuration guides.
Setting up connectivities on UNIX machines

Connectivity layers like SQLNET must be installed and configured outside of Business Objects. As under UNIX every application has its own separate environment, you must set the environment variables in the Business Objects environment in order to enable Business Objects users to use the connectivity layers. If you are running the Configuration Tool on a UNIX machine, the last screen tells you to set the connectivities environment variables in the MyWebiEnv.sh file, which defines cluster-specific environment information. This file is located in the $INSTALLDIR/nodes/<Node Name>/<Cluster name> directory. For instructions, see Installation and Configuration for UNIX.
278
Creating the repository with Supervisor

For users to be able to connect to and use the Business Objects system, users need to be able to access Business Objects resources, the universes which represent the users interface with the corporate database structure, as well as existing documents meant to be shared throughout the enterprise. In the Business Objects solution, users can do all this through the centralized repository. Once you have installed and configured your Business Objects installation, therefore, you must create your deployments repository using Supervisor.
NOTE
Supervisor runs on Windows machines only, but is required for 3-tier deployments under Windows, UNIX, or both. This section is just an overview. For more detailed information, see the Supervisors Guide.
Repository domains
A repository contains three parts: Universe domains store the universes users use to create documents. Document domains contain the structures for storing shared documents and for executing tasks according to a timestamped definition. The most important domain of all is the repositorys single security domain, which contains the characteristics of the other domains as well as user definitions and access rights. Before any user request can be processed, it must first pass through this domain so that the user can be identified and the database query checked against the users access rights.
279
Supervisor lets you purge all Inbox documents older than a given number of days from the repository with a single command. Inbox documents are documents sent from user to user via the repository, either directly or by means of Broadcast Agent, and cached there until their recipients download them. This lets you recover the document domain space taken up by documents which have been sent but not yet collected by users. This feature can be especially useful when regularly scheduled documents are sent using the Refresh according to the profile of each recipient option. You may also find that users are not deleting corporate documents that have been stored in the repository. You should encourage users to delete old or outdated documents on a regular basis. Initial space required for the repository as a whole To calculate the initial required repository disk space in MB, use the following formula: (number of registered users * 0.4) + (number of universes * 0.5) + 150 This corresponds to: (space required for the security domain) + (space required for the universe domain) + (minimal initial space required for the document domain)
280
Using the Administration Setup wizard

To launch the Administration Setup wizard, click the Admin button when you log into Supervisor.
Figure 9-3 The Administration Setup wizard in Supervisor
This wizard guides you through the process of defining a secure connection to the repository database, then the actual building of the repository itself.
281
Creating the .key file

Users machines must recognize the address of the repositorys security domain, as it is through the security domain that they receive the authentication necessary to communicate with the other domains of the repository. In Windows environments, once the repository is built, the Administration Setup wizard prompts you to define a .key file containing the address of the security domain. Key files are binary compatible across both the Windows and UNIX deployments: For Windows Desktop product users, you can either store the resulting .key file in a network folder to which all users have access, or have the users copy the file to a specific folder on their computers. In Windows server environments, the .key file is by default called bomain.key. It is automatically saved in the $LOCDATADIR folder. In UNIX environments, the .key file is called bomain.key. You can procure this file either by retrieving it from a Windows environment, or by generating it yourself using the wmainkey script. It must be stored in the $LOCDATADIR directory.
282
Defining access rights with Supervisor

The Business Objects security model is implemented in the repository as a set of data tables containing information concerning your companys functional structure and its groups and users. Immediately after creating your repository and defining the .key file(s), its time to define these users and user groups. Its essential you do this early, as when you create and export a universe, you must link it to one or more user groups. Similarly, when you set up a Broadcast Agent, you must link it to a specific user group. This is a Business Objects security feature since, by default, any user belonging to a group has access to the associated group resources (universes, documents, scripts, etc.). The supervisor can therefore implement security and allocate resources at a group level rather than at an individual user level. For complete information about creating users and user groups, see the Supervisors Guide.
Creating users and user groups

When you define users and user groups, you define their user identification (user name and password), then a set of access rights encompassing the products and modules they can work with, the universes they can access, the documents they can share, and even during what hours they are allowed to access the repository.
283
Figure 9-4 Assigning user rights with Supervisor
This is a highly strategic process: all the users in each user group share the same access rights, unless these rights are specifically modified for an individual; the users in each subgroup inherit the access rights of the users in the parent group. When setting up your repository hierarchy, dont mimic your organizations hierarchy, as it may result in the creation of levels and user groups which are functionally superfluous and degrade performance. Think carefully about the functions each user will realistically require, not the users hierarchical status in the organization.
Defining access rights with Supervisor
284
Hierarchy within the Business Objects system Each user you create with Supervisor has a particular hierarchy within the system. Here are just a few examples: When you created the repository using Supervisor, you created the systems first user, the senior Business Objects system administrator called the general supervisor. The general supervisor can perform all Business Objects administrative tasks, such as creating repositories, creating any type of user including other general supervisors and so forth. Supervisors are responsible for user management within the system, and can create users with any profile but that of general supervisor. Designers create and manage universes for particular groups of users. Users have the right to use all end-user Business Objects products to query, report and analyze data. Importing/exporting user and group lists Groups of users can also be batch imported in text file format. You can view the format of the text file by performing an export operation from Supervisor. User passwords are encrypted and are also saved in the exported file. To import users in this way, you must first format your data into the same format in a text file, using the import command set (NU = New User, NG = New Group, and so on). Groups of users can also be imported and exported in interactive mode. For more detailed information, see the Supervisors Guide.
285
Creating universes with Designer

Your next step is to create at least one universe based on your corporate database. You do this using Designer.
Creating the first universe

Creating universes which respond to your users requirements in an optimal way takes careful preparation and analysis. Before even beginning to use Designer, you should: review the structure of the corporate database, breaking down the information system into functional areas analyze the information needs of your deployments users design a conceptual schema design the universes specification Once youre ready to begin actually creating the universe, you first create the underlying database structure of your universe. This structure includes the tables and columns of a database and the joins by which they are linked. Next, you enhance the components of your universe. You can create more complex classes, objects, conditions, or joins. You can also prepare certain objects for multidimensional analysis. See the Designers Guide for full instructions.
The Quick Design wizard

For a universe based on a simple relational schema, Designer provides Quick Design, a wizard for creating a basic yet complete universe. You can use the resulting universe immediately, or you can modify the objects and create new ones. In this way, you can gradually refine the quality and structure of your universe. The Quick Design wizard assists you throughout the creation of a universe. It guides you in establishing a connection to the database and then lets you create simple classes and objects. The wizard also provides built-in strategies for the automatic creation of objects, joins, and tables.
286
Creating a universe manually

Alternatively, you may choose to create an entire universe manually. You will then need to build the underlying database structure of a universe. This involves selecting the initial tables and columns which form the classes and objects of your universe. With its graphical and intuitive interface, Designer makes it easy to create and organize a working universe in a short amount of time.
Figure 9-5 Creating a universe in Designer
From the basic model of a universe, you can then refine the classes and objects so as to obtain the degree of complexity or sophistication you desire.
Defining a secured connection to a universe

The final step in making the information in your corporate database available to your specified user groups is to define a secured connection between the universe and the corporate database.
287
Exporting universes to the repository

Finally, you must export the universe to be stored in the repository and made available to specific groups. It can then be imported for use by users.You export and import universes from Designer or Supervisor.
Are universes different for BusinessObjects and WebIntelligence?

No. Both the BusinessObjects and WebIntelligence reporting and analysis products use the same universes to interface with the corporate database.
288
Making sure youre ready to start the system

Heres a checklist of conditions that should be fulfilled before you actually start up the Business Objects system. Being able to check off these conditions does not mean you are ready to start a production system. This means starting it to be able to launch the Administration Console to tune the system to work efficiently. The connectivities to all the databases used in the system, for both the repository and corporate data, are installed and have been checked to make sure they are working correctly. You have checked to make sure the systems web and application servers are running. All Business Objects products are installed and properly configured, according to a supported deployment configuration. For UNIX machines, the connectivity environment variables have been correctly set in the MyWebiEnv.sh file. The repository is installed and functioning. The systems users and user groups have been created using Supervisor, and their profiles assigned. The .key file corresponding the repository youre using is created on every cluster node. At least one functioning universe exists, configured with a valid, secure connection to the corporate database. This universe has been exported to the repository.
289
Starting up the system

You start the Business Objects system by starting first the clusters primary node, then all the other nodes in the cluster. Before you have started the primary node, users cannot connect to the cluster.
Under Windows
The Wiorb service launches the Business Objects system. You can launch this process on any Windows cluster server in several ways: During cluster configuration with the Configuration Tool, you can ensure that the Wiorb process be launched automatically whenever the server machine is started. You can use the Windows Start menu, clicking Start server (6.1) in the Business Objects submenu. You can click the Start server item in the WiNotify icon menu on the left of the machines taskbar. WINotify is a utility that you can use to start and stop a cluster server, launch the Administration Console and more. You can type $INSTALLDIR\nodes\<NodeName>\<ClusterName>\webi.bat start at the command line.
Under UNIX
To start the system manually: 1. First, log into the server machine as the Business Objects administrator. 2. At the command line, change to the $INSTALLDIR/SetUp directory. 3. Type: # wstart You can run the wstart script only if you have the rights of the user who created it.
Starting up the system
290
Tuning the system using the Administration Console

The Administration Console serves as a central control panel for each Business Objects cluster. At any given time it shows you at a glance what servers are running in the cluster, and what modules are enabled on each server. As the Administration Console also allows you to enable, disable and define settings for the modules on each server, thereby tuning the solution to optimize its performance given the hardware configuration at your disposal.
The Administration Console is available as a Java applet or a standalone Windows application. As long as the Business Objects system is started, you can start the Administration Console through a web browser, the WINotify icon or from the Windows Start menu.
291
Enabling modules on cluster nodes

Business Object recommends certain module enablement rules. Several instances of some modules can be enabled either on the same machine or over multiple machines within a cluster, while other modules must be enabled once and only once within the cluster. As a bare minimum, before you can use your system, you must: enable the session stack on each node responsible for processing in the cluster You can then strategically coordinate the enablement/disablement of the other system modules over the clusters machines to spread out transaction loads most efficiently. You do not have to enable the session stack on nodes which do not handle document processing. See When do session stacks not have to be enabled? on page 102. if you plan to use Broadcast Agent, create and assign a Scheduler for each active Broadcast Agent set the process pool size for mono-threaded processes like WIQT and BusObj/bolight See the following sections for more information about all of these steps.
292
Starting the session stack You start the session stack on any cluster node using the Administration Console:
Figure 9-7 Starting the session stack using the Administration Console
Setting the size of process pools A process pool is a set of identical processes which are pre-registered at startup. When a new process is required by a user request, this process is taken from the pool. When the process is no longer required, it is removed from memory and returned to the pool of available processes. When you configure a node using the Configuration Tool, all the systems process pools are limited to a default size. It is important to immediately increase the size of the WIQT pool at least, in order to enable a greater number of concurrent user sessions. For example, when a user logs into InfoView, a WIQT process is required for the user sessions processing. This process is taken from the existing pool of WIQT instances and activated. When the user logs out of the system, the WIQT process associated with the users session is deactivated and returned to the pool to be re-used when required. If you set the size of the WIQT pool to 20, it means you are allowing up to twenty concurrent InfoView sessions.
293
Strategic module enablement in a four-node cluster You may, for example, choose to dedicate separate machines to particular types of processing.
2-tier client machine
Database
Primary Web/application servers
Secondary1
Repository Cluster 3-tier client machines Secondary2
Figure 9-8 Example three-node cluster
In this deployment, each secondary node has a specified processing function: Secondary1 is dedicated to document processing requests coming from InfoView and WebIntelligence. Secondary2 is dedicated to BusinessObjects (3-tier mode) processing, as well as the processing of all scheduled tasks using Broadcast Agent.
294
The following table shows you which modules are enabled on which cluster nodes: Node Module Session stack: Enabled WIReportServer BOManager WIADEServer WIAPIBroker WIQT WIDispatcher WISessionManager WIProcessManager* Enabled Audit Server Enabled (mandatory on primary node Enabled Enabled Enabled Enabled Enabled Enabled Enabled Primary Secondary1 = Report Engine 1 Enabled Secondary2 = Report Engine 2 + Broadcast Agent Enabled
Enabled
Enabled
Broadcast Agent Manager Connection Server WILoginServer WIStorageManager
* This process cannot be enabled/disabled on specific cluster nodes. It is always enabled.
295
Setting node weight

You also use the Administration Console to set how much of the clusters processing load each node handles. This is called the node weight.
Figure 9-9 Setting node weight using the Administration Console
For example, if one machine is much more powerful than the other machines in your cluster, you can make sure the powerful machine receives more transactions to process than the others. Likewise, if one machine is particularly restricted, by giving it a low node weight, you can make sure it does not penalize the entire system. For a more detailed explanation, see the System Administrators Guides.
296
Setting the locale

The locale is the setting that defines your working environment and user interfaces language and cultural conventions such as date and time formats, and decimal separators. Locale/language selection comes into play at three levels in the Business Objects system: At installation At the server/cluster level At the user level
Selecting languages at installation

When you install Business Objects products, you install all the languages in which you want products to be available, then you choose a default language for the products:
Figure 9-10 Setting the default language during Business Objects installation
297
Setting a clusters locale

All the servers in a cluster must use the same locale. You can change a servers locale by re-running the installation procedure or running an update procedure, but it is easier to do it just by using the Site Properties tab in the Administration Console:
Figure 9-11 Setting a clusters language
The Locale list in the Site Properties tab includes all the installed languages and countries. To change the locale of your server, select the new language and
country from the Locale list, then select the new character set from the Character Set list.
You must change the system locale for each machine in the cluster, then reboot each machine before restarting the Business Objects system.
Setting the locale
298
Setting user locales

BusinessObjects Enterprise 5.0.1 allows users to set the locale in which they want to work with Business Objects products. In InfoView, users can choose their desired interface language from among the languages installed on the Business Objects server in the Options pages:
Figure 9-12 Setting the user interface language in InfoView
If a user does not set a locale, the InfoView interface is displayed in the locale used by the cluster. In 2-tier deployments of BusinessObjects, Designer and Supervisor, users set the locale in the applications Options menus.
NOTE
When users download 3-tier deployments of BusinessObjects through InfoView, however, the application is automatically installed in the language corresponding to the current InfoView user locale. The BusinessObjects interface remains in that language even if the user subsequently changes the InfoView user locale. If users want to change the language of the BusinessObjects interface, they must first change the interface language setting in InfoView, then re-download BusinessObjects.
299
Creating and sharing documents

Once you have set up your reporting environment as described in the preceding sections, you are ready to start generating documents. For complete information on document creation, see the BusinessObjects Users Guide and the WebIntelligence Users Guide.
Using BusinessObjects
BusinessObjects in 2-tier mode and BusinessObjects in 3-tier mode are the same reporting product, deployed differently; the documents they create are processed identically within the Business Objects system. To introduce any type of BusinessObjects document into the 3-tier system, you simply export it to the repository. From there, InfoView and BusinessObjects users access them from client machines.
Client machines running InfoView and BusinessObjects in 3-tier mode
Database Web/application server
Client machine running BusinessObjects in 2-tier mode
BusinessObjects documents exported to the repository
Business Objects cluster
Repository
BusinessObjects documents exported to the repository
Figure 9-13 How 3-tier users access BusinessObjects documents
Creating and sharing documents
300
Using WebIntelligence
You can use either the Java or HTML Report Panel to create WebIntelligence documents. While the features of each document editor vary slightly (see Appendix A for more information), all WebIntelligence documents are processed by the system in the same manner. WebIntelligence documents are accessible to InfoView and WebIntelligence users as soon as they are saved to the repository or sent to other 3-tier system users.
Scheduling documents
In addition to basic document generation, you can also schedule the automatic refresh and distribution of WebIntelligence and BusinessObjects documents to specific users and groups. This feature is discussed in greater depth in the InfoView Users Guide.
Adding third-party files from InfoView

You can add files created by applications other than BusinessObjects and WebIntelligence to the repository from InfoView. This can include files such as Microsoft Excel spreadsheets, Adobe PDFs, or .zip files. Once the files are in the repository, you can send them to other users or save them for personal use.
Practical Deployment Specifics
IV
part
From Development to Production
10
chapter
304
Overview
It is unrealistic to think that you can open the boxes from Business Objects, install the software and launch into a full-scale live production situation at once. The Business Objects system is a sophisticated and often complex solution that can be deployed to thousands of users. No matter what the projected size of your deployment, you must plan a realistic and gradual process by which you can deploy a pilot system with universe and document prototypes, then advance through various phases designed to detect problems, find solutions, and adapt the solution as closely as possible to real users reporting needs. By the time your solution goes live, it should be reliable, robust, and usable. This chapter provides guidelines for setting up and using a set of environments for the gradual and controlled implementation of a new Business Objects deployment. This chapter describes: The development lifecycle Planning the pre-production environment Creating the lifecycle environments Migrating between environments Planning and building the production environment
305
The development lifecycle

The development lifecycle is the process by which the Business Objects system is developed, tested and implemented in a real-life professional situation. This lifecycle can be broken down into several broad phases. At the very least, Business Objects recommends implementing two phases, development and production. Most enterprises prefer including more. In a mature technological scenario, a company typically includes the following phases in its Business Objects development lifecycle: 1. Development 2. Testing 3. User acceptance testing 4. Production Each of these phases corresponds to a separate deployment environment with a specific user population and purpose. Although they succeed each other in welldefined order, the lifecycle continually renews itself as the evolution of the enterprise, the user population, its activity, and available technology forces the deployment itself to evolve. And it makes these phases both consecutive and concurrent.
Testing Development
User Acceptance Testing
Repository
Development
Production
Figure 10-1 The development lifecycle
306
The development phase/environment Created and used by development teams, the development environment represents a highly fluid lifecycle phase in which universes and documents are constantly modified. At term, this phase provides universe/document prototypes that can be tested in the testing phase. The testing phase/environment The testing environment is more stable than the development environment. IT professionals use it to test the development universes and documents, making sure the required data appears in the required format in documents. You can implement this environment in one or both of the following scenarios: between the development and production environments, using it to test and experiment with the development environment before actually going live with a production system after your full Business Objects production system is in place, and use it to test new components and configurations of the system without having an impact on the other environments. You an also use this for testing new universes and reports.
NOTE
For testing new service packs, you should use an entirely new repository. The UAT phase/environment The UAT (User Acceptance Testing) environment is generally used by a reduced number of users who will eventually be using the Business Objects system in their everyday working routines. These users inherit the end results of the testing phase. They endeavor to use the system in a realistic manner to determine whether it meets their reporting requirements. During this phase, they suggest often more cosmetic enhancements, such as the addition of objects to universes, or the adaptation of reports to more closely correspond to reporting concerns. or have the chance to implement suggested adaptations of the system. Developers in turn implement these requests. By the end of this phase, system should have the users seal of approval for going live.
307
The production phase/environment The production, or live, environment represents the deployment actually used by a company professionally. By this time, any majors flaws in the systems deployment, configuration, universes and documents should have been detected and resolved. Robust and customized to the companies particular requirements, the system is ready to be deployed to its target user population.
How many repositories?

You can use a single repository for all environments, or separate repositories for specific phases. Using multiple repositories If the development environment for the Business Objects system is on a different subnet than the production environment (development is often carried out on a different site than where the production system is actually used), using multiple repositories is unavoidable. The two systems simply cannot connect to the same repository. The gap between the two systems is often called an air gap. Using multiple repositories makes migrating documents and universes to the production environment a much more complex process than in a singlerepository scenario. This procedure is therefore not documented in this guide. Business Objects instead recommends that you undertake this lifecycle scenario only with the assistance of certified Business Objects consultants.
308
Using a single repository Using a single repository for all lifecycle environments removes much of the risk during migration from one environment to the other. But using multiple universe and document domains allows you to separate the universes and documents which belong to each environment. Use multiple universe domains Using separate universe domains for each environment allows you to use different database accounts and provides more flexibility in terms of the domains location and administration. It also allows you to better control who is accessing what universes. When its time to migrate from one environment to another, you can simply export it to the desired production universe domain. Use multiple document domains For each universe domain, you must then create a corresponding document domain in the same database account to store custom lists of values. If you do not, the universes list of value cannot be exported. You can create as many document domains as you want. As you created at least one universe domain per environment, you must also create at least one document domain per environment, but within each environment you might also want to create separate document domains pertaining to particular projects, roles or tasks. You might, for example, consider creating a separate domain for scheduled documents processed by Broadcast Agent. The more you can separate documents, the more organized they are. Assigning separate default tablespaces to the distinct domains is also a good idea; should one of your domains run out of storage space, you may lose a domain but not the entire repository (this would be the risk in a simple repository).
309
A separate deployment for each environment?

Does each lifecycle environment require a separate deployment of Business Objects? Not necessarily. Although technically you can use the same cluster configuration for the entire lifecycle, Business Objects recommends that the production environment at least have its own dedicated deployment. In other words, the Business Objects servers hosting the production system must not be the same as those used for the other lifecycle environments. Although lifecycle phases are consecutive, they can also function concurrently. Once the production environment is up and running, the test environment generally continues to operate, testing new universes, documents and configurations; the testing draws on the systems hardware and software and lowers performance. Separating the production environment from the other environments is not just a a question of performance, however. It is a question of best practice. You do not mix a finished system with its preparatory phases, period.
310
Planning the pre-production environment

The first environment you implement is the development environment. The other lifecycle phases can, but are not required to, use the same deployment. All the information this section therefore applies to the entire set of pre-production phases. The development environment should be a microcosm of what the production environment needs to be. It should include at least one cluster, and include all the server and desktop products your eventual user population will require.
REMINDER It is also strongly recommended that you plan and implement all your environments in consultation with Business Objects consultants.
Start small
Start with a single cluster, and incorporate a small group of users, either: a couple of users with full functionality In this scenario, monitor how users use the system: are they processing more BusinessObjects or WebIntelligence documents, how often do they create documents, refresh, schedule them, and when? a small set of 10-15 users with restricted functionality, for example the right to view documents but not to create, edit, refresh or schedule them. In this scenario, evaluate the systems response times. Experiment with load balancing, for example dedicating servers to processing either WebIntelligence or BusinessObjects documents, or combining the functionality on the same machines. Use this restricted system to monitor where the bottlenecks are and evaluate what performance means for your organization. Above all, dont enter into the development phase with preconceived notions. Accept it as a time of trial by error, and plan for evolution. In addition, evaluate not only how the system responds to user transactions, but how users react to the system. Make sure you give users the knowledge they need to use the system correctly, and incorporate their ideas in plans for future evolution.
311
Think big
Most systems will necessarily evolve as you discover new ways to optimize performance, and new ways of using the system to work in different ways. Your systems implementation must be scalable, as more users come online with increased functionality. Consider the possible future extranet requirements from the very beginning. If you interface with the Internet, how can you protect the integrity of your corporate data? Can you scale up to cope with a potentially exponentially-increasing user population? How can you prevent bottlenecks before they happen? Most systems will be processing both BusinessObjects and WebIntelligence documents. Later on, however, they may want to migrate entirely to WebIntelligence or a 3-tier deployment of BusinessObjects. In addition, what does WebIntelligences support of other types of files mean for your system? Will users be most likely to process Microsoft Word files, Excel sheets, Adobe PDFs, or others? How much disk space will these files require, and how much will they increase transaction loads? You may be using an exclusively Windows system now. But as the user population and transaction load increase, you may want to switch to a UNIX environment.
Expand, trace, volume test, benchmark

Once youve designed a preliminary system, you must build it then test it to gauge its performance level. Based on the results of the tests, you can modify the systems configuration to ensure acceptable performance levels. Early on in the development phase, you should try to determine exactly what is expected of your deployment from its users, administrators and financiers. Performance can mean any number of things to any number of people. What response times are acceptable to your user population? What are the constraints in terms of overall cost, training and maintenance?
312
Make sure that the entire system functions smoothly before expanding the development environment and moving on to the next lifecycle phase. This includes: testing universes and documents testing the systems processing capabilities, by: - publishing the documents to the repository so that they can be shared with other users - sending the documents directly to other users - saving the documents for personal use testing the Broadcast Agent Schedulers by scheduling a set of documents for automatic refresh and transmission to the repository as corporate documents from InfoView and/or 2-tier BusinessObjects As you run into problems then resolve them, expand your system: Turn on more functionality for power users those who actually create the documents your system is going to be processing then see what they do with it. What types of documents are they likely to process, how complex, how big? Expand the user population. When are they most likely to use the systems resources for accessing data? Up to how many users might use the system concurrently? Force greater workloads through the system. At what point does performance plunge? Where are the bottlenecks? How can the load be better balanced across the cluster? Add more machines to your system if performance requires it. And when youre done, begin the cycle all over again. Use the Audit facility At every stage, trace your system and user activity using the Administration Consoles tracing facility. This feature tracks the activity of your entire distributed system. Among other things, it can tell you what universes users are using, what types of documents theyre processing, how, and how long the system has taken to respond. It allows you to determine how many users were active at any given time, and thus check the number of concurrent users in the system (that is, users who are making the server work as opposed to the users who are merely logged in). All this information is critical for tuning your system to perform optimally. For more information about the Audit facility, see the System Administrators Guides.
313
Use BusinessObjects Auditor Auditor is a critical element in any environment because it allows you to monitor, analyze, and optimize your Business Objects deployment. This information is sorted by predefined indicators that are divided into five analytical categories: User Information Document Management Universe Management Broadcast Agent System Information. You can use Auditor to: examine user activity, access rights, resource information (documents, universes), and system information such as response time, Broadcast Agent details, and server load analyze system trends over daily, weekly, and monthly periods optimize your data warehouse and speed up refresh actions by tracking frequently-used queries Install Auditor on a dedicated Business Objects cluster using the existing repository for users, so that documents can be shared. For more information, see Deploying Auditor on page 409. For complete information, see the BusinessObjects Auditor Guide.
314
Number, type and hierarchy of users

The precise number of users you include in the pre-production environments is relatively unimportant. What is important, especially in the testing and UAT phases, is this: You should construct a simulated user hierarchy with Supervisor. This hierarchy models the real hierarchy of the production environment, containing similar types of users and security commands. However, it is flatter; that is, the simulated hierarchy has fewer subcategories of users. Start with just a few users carrying out simple but typical user transactions, such as creating WebIntelligence and/or BusinessObjects documents, and viewing and refreshing documents and document lists from InfoView. Add users as you go along, slowly building up to a more solid population with more varied activity, such as scheduling documents for automatic refresh and distribution with Broadcast Agent. The proportion of each type of user (see Types of users on page 152) must be consistent with the projected proportion of each type of user in the production environment. What percentage will create documents? What percentage of users will have only access and refresh rights to documents in InfoView? You will also need to create specific users and groups with particular functions within the development lifecycle. For more information, see Creating users and groups on page 318.
What type of universe?

You start by using at least one universe created with Designer. You can use an existing universe, or create a simple universe with no more than ten tables. This development universe contains simple versions of the following elements: Classes Objects (including basic prompts known as filter objects) Hierarchies With time, you can add new tables and complexity to existing universes, and create more.
315
What type of documents?

You will be creating several BusinessObjects documents and/or several WebIntelligence documents for use in the development environment. The types of documents should be as representative as possible of the documents you will be using in the production environment. You may want to begin with the simplest document with any relevance to the type of document used in the production environment, then gradually work up to more complex, and larger documents.
316
Creating the lifecycle environments

Although you are starting with a small-scale, model system, it still represents a complete Business Objects deployment and installation which must be set up properly. You can find help in setting up the lifecycle environments in the following chapters in this guide: Deployment Considerations on page 143 Modeling your System on page 163 Installing the Products on page 243 Getting the System Up and Running on page 267 Implementing Supported Deployment Configurations on page 337 Implementing Supported Deployment Configurations on page 337 Two small documents containing checklists for deploying your solution are also available from the Business Objects Online Customer Support site:
Setting Up your 3-Tier Business Objects Deployment under Windows Setting Up your Business Objects Deployment under UNIX
Installation and configuration

Follow the instructions in the Installation and Configuration Guides.
Creating the repository and its domains

Because you are using a single repository for all the lifecycle environments, you will need to take the requirements of all these environments into account when you create and structure the repository the first time.
317
When you create the repository with Supervisor, consider creating the following additional universe and document domains:
Figure 10-2 Creating repository domains with Supervisor
A universe domain for production, plus one for development A document domain for each universe domain This domain will store the universes LOVs (list of values); its connection settings must match those of the corresponding universe domain. If applicable, a document domain for key projects, roles or tasks, multiplied by the number of environments For example, for an extranet project planned to exchange information with suppliers, a dv_ex document domain for the development environment, as well as a prod_ex document domain for the production environment. You may also have a intranet project for sharing information within a specific site; for this project you might separate dv_in and prod_in document domains. A separate document domain for all documents scheduled with Broadcast Agent, again, multiplied by the number of environments (for example, dv_BCA and prod_BCA) A separate auditing document domain for each cluster to contain the documents generated by Auditor
318
Each domain you include in the deployment is likely to evolve differently; this type of separation allows you to better organize universes and documents, and allows you to optimize each domain using separate database administration and connection settings.
TIP A typical deployment for an environment includes 2 to 6 sets of domains (universe domain and its corresponding document domain). For the sake of manageability, avoid using more than 10.
Creating users and groups

Once you have installed and done the basic configuration of your system, use Supervisor to create or import the systems users and user groups, and then assign them access rights. You need to create two categories of users and groups: those who represent the profiles and proportion of real-life users in the future production environment (see Number, type and hierarchy of users on page 314) those whose role pertains exclusively to the development lifecycle Groups in this category include a separate group for each lifecycle environment; the users in each of these groups can access the domains containing the documents and universes for their particular environment only. In addition, you will need to create the users responsible for migrating the documents and universes from one environment to the next.
319
The following diagram illustrates how these users and groups will interact for universe migration:
Users/ environments Create then export universe to dv_unv
nv dv_u rom rse f e univ port
Designer
Migration users
Im
Using Development only
Export universe to tst_unv

t_un v
Migrate_ dev_to_test
I mp o
rt un
e fr ivers
s om t
Using Testing only
Export universe to uat_unv

u uat_ nv
Migrate_ test_to_UAT
Im
rom rse f nive ort u p
Using UAT only
Export universe to prd_unv
Migrate_ UAT_to_prod
Using Production only
Figure 10-3 Migrating universes from development through production
320
Creating groups for development lifecycle purposes Having created the required document and universe domains in the repository, you now create the users and groups for each environment. In Supervisor, create a separate group at the root level for each lifecycle environment, from development through production:
Figure 10-4 Creating users and groups for lifecycle environments
For example, Development, Testing, UAT and Production. Now add the users to each of these groups. Creating additional users responsible for migration You need to create additional users who are responsible for migrating universes and documents from one environment to the next with each new phase in the lifecycle. These users, known as migration users, are easy to identify if you name them intuitively. For example, you could name the user who migrates documents and universes from the development to the testing environment Migrate_dev_to_test. Unlike other users, who have access to domains in their own lifecycle environment only, these users need to have the rights to access the domains corresponding to both the origin and destination environments. For example, the user Migrate_dev_to_test must be able to access the universe and document domains in both the development and testing environments.
321
In addition, you must make sure these users have the appropriate rights to export and import universes with Designer, and export and import documents to and from their domains in the repository using 2-tier BusinessObjects and/or InfoView. You might, for example, give these users a designer/supervisor profile.
NOTE
Migration users are simply administrative users. They therefore do not require official licenses to use Business Objects products.
Assigning the domains to groups and users

You now assign the domains you have just created to the lifecycle groups, giving each group the right to access only the domains corresponding to their lifecycle environment. 1. Log into Supervisor. 2. In the main window, click the Repository tab. All available domains are listed in the Resource pane.
322
3. For each lifecycle environment group or migration user: - Select the group or user in the User pane. - In the Resource menu, choose Assign > Domain. The Assign Repository Domains dialog box opens. - Select the domains each group/user is allowed to access. Users in the Development group can only access domains with the prefix dv, UAT users only domains beginning with uat, etc. Assign migration users the domains in the environment from which they will import, and to which they will export resources. - When youre done, click OK.
Building universes and making them available

Making a universe available to users entails several different steps: 1. Building the universe 2. Exporting the universe to the repository 3. Configuring a universe Building the universe Using Designer, create at least one functioning universe, configured with a valid, secure connection to the corporate database. The Designers Guide provides full instructions. Universe file naming conventions You simplify the migration of a document from one domain to another by giving the documents universe the same file name in every lifecycle environment (this is not the same name as the long name, which is what BusinessObjects and WebIntelligence users see in their universe lists). For example, the universe called eFashion in a domain in the development environment must be called eFashion in all other environments as well. You now need to use Supervisor to disable the Prevent from Overwriting Universe security command in the Universe family for all migration users (and only migration users). In this way, when an enhanced version of an existing universe is migrated into a domain, it simply replaces the older version. This allows you to avoid having to manually change the name of the data provider for BusinessObjects documents once theyve been migrated to a new domain. When the document is retrieved from the repository after migration, the system will automatically search for a universe with the same file name, and use it if it exists.
323
EXAMPLE Simplifying migration with the right universe file names
Lynn is the user of the production deployment in CompanyA. She can therefore access universes and documents in the production environment only. Lynn is a sales analyst, and the report she uses each day, DailyRevenue, is based on a universe called Sales. As in most companies, the lifecycle of developing, testing and releasing enhanced universes and documents at CompanyA is an ongoing process. One weekend, a migration user migrates an enhanced set of universes and documents from the UAT to the production environment The Sales universe in the UAT environments universe domain overwrites the Sales universe in the production environment. Its file name remains the same, but its universe identifier changes to that of the production universe ID. The DailyRevenue report overwrites the document of the same name in the production environment. Lynn comes to work on Monday. She immediately opens and refreshes the DailyRevenue report. As the report is still linked with the Sales universe in the UAT environment, the system looks for a universe with the ID corresponding to the UAT environment. It cannot find it in the production domain. Before sending an error message, however, it searches for a universe with the same file name. It finds the new universe and seamlessly refreshes the sales report. Because the two universes shared the same file name, neither Lynn nor the migration user has suffered any inconvenience.
324
Exporting the universe to the repository To export universes, you must belong to the group with a General Supervisor, Supervisor, Designer or Supervisor-Designer profile. Export all universes to the development universe domain in the repository so that development users can access them, using the Export Universe dialog box in Designer:
Figure 10-5 Exporting universes to the repository
Development users work with the universe and provide feedback, including: better descriptions for objects objects that should be added or deleted better ways to organize objects For example, moving an object from one class to another, or reclassifying a dimension as a detail. adjusting objects or queries that don't behave as expected Based on this feedback, you modify the universe. You then resubmit the modified universe to the development users for further evaluation. This iterative process is called Rapid Application Development (RAD).
325
In each phase, once the universes are relatively stable, migration users import them from their current universe domain, then export them to the domain corresponding to the next phase in the lifecycle for further testing or use.
NOTE
By default, the users and groups to which a universe domain has been allocated have access to any universes you export to that domain. To disable access to specific universes in the domain for specific users and groups, see Supervisors Guide. Configuring a universe Universe parameters are definitions and restrictions that you define for a universe that identify a universe and its database connections, specify the type of queries that can be run using the universe, and set the controls on the use of system resources. You can define these default parameters when you create a universe in Designer. But as configuration requirements may evolve for the same universe from one lifecycle environment to the next, you may want to modify them before exporting them to the new domain. You can override the default settings set with Designer using Supervisor. Why configure universes? Regional users want access to their local database. Power users want more data returned. Experienced users wish to use sub queries. Different users want different objects to answer their business questions. Within a local database, users only want access to relevant data. This type of customization may be more relevant, however, when you are dealing with the production environment. To override a universes default configuration: 1. In the Supervisor User pane, select the user or group for whom you want to deny access. 2. Click the Universe tab. 3. In the Resources pane, double-click the universe name.
326
The Universe Properties dialog box opens:
For instructions for changing settings, see Supervisors Guide.
Creating documents
Create several simple documents using BusinessObjects and WebIntelligence. This includes a document with an initial microcube. The types of documents should be as representative as possible of the documents you will be using in the production environment. They might, for example, include: multiple graphs or tables on a single page complex variables multiple queries drilling capabilities
327
Migrating between environments

To migrate from one environment to the next, you: migrate universes migrate documents then test them delete unnecessary documents
TIP If you follow the recommended file naming convention for universes, you dont have to migrate universes and documents at the same time. You can migrate them in the order and at the interval you choose, as long as a universe with the same name as a migrated documents original universe exists in the destination environment. If you migrate a document from one environment to another before its universe, the document will automatically be linked with the universe of the same name in the destination environment.
Migrating universes
This stage is carried out by migration users only. To migrate a universe from one environment to another: You import the universe from its universe domain. You then export the universe to the universe domain in the subsequent lifecycle environment. Immediately after the export, you disable the universe for all users to ensure that no one uses it before any universe restrictions have been put in place. Configure the universe with any required restrictions, then re-enable it for its target user groups.
328
Importing the universe from a domain 1. In Designer, choose File > Import. The Import Universe dialog box opens:
2. Select the universe domain containing the universe you want to import from the drop-down list. The universes in the domain appear in the Available Universes list. 3. Click the name of the universe you want to import. 4. In Import Folder, enter the name of the folder on your computer or network to which you want to download the universe. 5. Click OK.
329
Exporting the universe to the destination environment 1. In Designer, choose File > Export. The Export Universe dialog box appears:
2. Select the universe domain to which you want to export the universe. 3. Click a group in the Group list box. This is the group that will be allowed to use the universe. 4. Click the universe in the Universes list box. 5. Click OK.
NOTE
Be extremely careful when you choose the destination domain for each universe, as this procedure can have serious consequences if you export a universe to the wrong domain. There is no rollback.
330
Migrating documents
Migrating documents, like migrating universes, requires importing them from their current domain, then exporting them to the corresponding destination domain in the subsequent lifecycle environment. This stage is implemented by a migration user with access rights to the documents current domains and their destination domains. If you used the naming conventions suggested in Universe file naming conventions on page 322, this is all you need to do. If the name of a documents data provider changes during the migration, however, you will need to change it manually. See BusinessObjects User's Guide: Accessing Data and Data Analysis. Migrating WebIntelligence documents To migrate a WebIntelligence document from one environment/domain to another: 1. Log into InfoView in the new environment as the migration user. 2. From the Corporate Documents list, open the document you want to migrate.
331
3. Save it as a corporate document, to a document domain in the new lifecycle environment, with the Overwrite option selected:
4. Refresh the document if you want it to reflect the data in the new environment. 5. You may want to purge the documents data provider in order to remove all vestiges of results from its former data provider and reduce the size of the document. You do this by clicking the Purge Data button in the Report Panel toolbar. Migrating BusinessObjects documents To migrate BusinessObjects documents from one lifecycle deployment to another: 1. Log into BusinessObjects in the new environment. 2. On the File menu, click Retrieve From Corporate Documents. 3. Select the document from the list of documents in the development domain. Click Retrieve. BusinessObjects downloads the document. 4. Save it to a document domain in the new lifecycle environment.
332
5. Refresh the document if you want it to reflect the data in the new environment. If the name of the universe in the previous environment is the same as its name in the new environment, the system should switch universes transparently and refresh the document without problems. 6. You may want to purge the documents data provider in order to remove all vestiges of results from its former data provider and reduce the size of the document. You do this with the Data Manager (Data > View Data).
Deleting unnecessary documents

This procedure includes two main steps: Delete all unnecessary documents from the repository. Check the repositorys integrity. Deleting documents from the repository 1. Log into Supervisor as a general supervisor. 2. Choose Tools > Delete document. 3. Delete the unnecessary documents. After deletion, the only way to recover the documents is to recover a backup of the repository.
333
Checking the repositorys integrity 1. Log into Supervisor as a general supervisor. 2. Choose Tools > Repository. The Repository Management dialog box appears:
3. For each security domain and document domain, click Scan.
334
The Scan and Repair dialog box appears:
- For the security domain, click Scan, then Repair, and then Compact. - For document domains, just click Scan and then Repair.
335
Planning and building the production environment

Pre-production environments are generally microcosms of your live production system. By the time you get to the production environment, all major problems should have been detected and solved. The Business Objects system with its configuration and resources should be tailored to meet the reporting requirements of your enterprise, and should already have obtained the stamp of approval from the users who have tested it.
Providing failover and load balancing

Business Objects recommends configuring the production environment to include multiple clusters, and therefore, multiple primary nodes. The Business Objects system provides automatic failover if any CORBA component falls over. As the primary node is a single point of failure, however, if you want 100% failover, Business Objects recommends using multiple clusters with an IP redirector balances the load between the web servers used by each cluster, and provides failover if one of the primary nodes fails. In this way, the production system provides a fault-tolerant system, maintaining 24/7, critical-application status. For example, if one of the primary node fails, the subsequent user requests are directed to the other primary node. Configure the primary nodes for shared storage of users personal documents. You can maintain the shared storage on an external disk array that is physically connected and shared by different servers. In addition, the system can remain operational during upgrades and maintenance because you can upgrade or maintain one primary node while the other primary node handles the production load. You can also add secondary nodes to the clusters, which distributes the load and provides scalability.
TIP Because the IP redirector communicates with the web server only, you may want to write a script to shut down the web server when the primary node fails. In this way, no requests are sent to that server while it is being maintained.
Planning and building the production environment
336
Implementing Supported Deployment Configurations
11
chapter
338
Overview
This chapter contains the detailed and practical information corresponding to the supported deployment configurations described in Chapter 7. If you are using this guide in PDF format, you will find a dynamic link at the top of each section which takes you directly to the description of the configuration in that chapter. Although you have many supported configurations available to you, the same fundamental rules concerning what must be installed and configured on each of the components in the solution apply to all deployments. You can find this information at the very beginning of the chapter. This chapter discusses: Deployment rules for all configurations Implementing a basic intranet deployment Implementing a basic extranet deployment Implementing a DMZ configuration Implementing an IP redirector Implementing a single web server for intranet and extranet users
339
Deployment rules for all configurations

No matter what deployment configuration you have chosen for your Business Objects BI solution, the same rules apply for each basic component in the system: the application server the web server the nodes in the Business Objects cluster
Extranet users
Application server
Primary node
Web server Business Objects cluster on intranet Corporate database 2-tier users (BusinessObjects, BusinessQuery)
Internet
Outer firewall
Inner firewall
Repository
Secondary node Administrators (Supervisor, Designer) 3-tier users (InfoView, WebIntelligence, BusinessObjects, Broadcast Agent)
Figure 11-1 Example deployment schema
340
What is installed/configured on the client machines

On the desktop client machines BusinessObjects BusinessQuery On the administration client machine Supervisor Designer The Configuration Tool Broadcast Agent Console Administration Console in standalone mode (or the Administration Console can be accessed through a web browser) On the 3-tier client machines 3-tier BusinessObjects WebIntelligence Java applet or DHTML editor
NOTE
You may not choose to assign Business Objects processing or administrative functions to client machines in this manner. This division reflects however the functional and architectural categories of Business Objects components and products. Business Objects highly recommends that all the servers used in the Business Objects system be dedicated to the system itself. This means no databases or other applications should be installed on the server machines.
341
What is installed/configured on the web and application server machines

On the web server machine The web server package, which consists of the static HTML pages and images required by InfoView This is installed when you choose the Web Server pages option under InfoView in the Business Objects installer. The application server package (see the following section) You need to install this package in order to use the Configuration Tool to add a virtual directory to the web server branch. A third-party application server connector if the web server is on a separate machine than the application server On the application server machine The Application Server package which consists of: ASP or JSP scripts (ASP for IIS configurations, JSP for J2EE configurations) WICOM or WIBean (WICOM for IIS configurations, WIBean for J2EE configurations) RECOM or REBean (RECOM for IIS configurations, REBean for J2EE configurations) HSAL or JHSAL (HSAL for IIS configurations, JHSAL for J2EE configurations) For all of this to be installed, you must choose the Application Server pages option under InfoView in the Business Objects installer. You must also install the Configuration Tool, available as an Administration Product option. If the application server is running on a separate machine from the cluster machines, you must have configured the application server machine as a client node of the cluster using the Configuration Tool. This installs the ASF client application on it, giving it the means to communicate with the rest of the cluster.
NOTE
For important information concerning the configuration of the web and application servers, see page 276.
342
What is installed/configured on cluster node machines

As a minimum, the Business Objects server backend must be installed on all cluster nodes. You do this by choosing the Business Objects server option in the installer. You can in addition install other server packages for specific types of processing to be handled by that machine. You can choose from among: WebIntelligence BusinessObjects Web Installer Broadcast Agent See the table in the following section.
343
Summary of installer options for server machines

This installer option... This sub-option... InfoView Web Server pages Application Server pages WebIntelligence Reporter Explorer BusinessObjects Web Installer Broadcast Agent installs this on the server machine the InfoView portal, gateway to enterprise documents HTML pages and images, to be installed on the machine that hosts your web server Application Server Pages and front-end components, to be installed on the machine that hosts your application server WebIntelligence report engine, for querying, analysis and reporting over the web WebIntelligence module for report creation WebIntelligence module for report analysis mechanism for installing BusinessObjects in 3tier mode on the client machine via the InfoView portal capacity to automatically refresh and distribute documents at specified times and intervals, in a secure manner Scheduler Console the core components of Broadcast Agent Broadcast Agent Console, to monitor and administer Broadcast Agent activity
What modules are enabled on each cluster node

You must enable modules with care on the cluster node machines. Some modules can only be enabled once within the entire cluster, others once per machine, and still others can be generated in pools for processing on a single machine. For a detailed description of module enablement rules for cluster nodes, see the System Administrators Guides.
344
Implementing a basic intranet deployment

Repository
Client BusinessObjects admin users machine
Figure 11-2 Intranet deployment schema
NOTE
For a description of a basic intranet deployment, see page 210. This configuration represents the most simple deployment choice for the Business Objects solution. As such, its implementation requires little explanation beyond the broader deployment advice available throughout this guide.
345
Implementing a basic extranet deployment

Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
Figure 11-3 Standard extranet deployment schema
NOTE
For an overview of extranet configurations, see Basic extranet deployments on page 212.
Clients
Client machines on the Internet can be browsers, applets or standalone applications such as BusinessObjects. All these clients communicate in HTTP with the web servers, with one exception: BusinessObjects must access the databases directly for data exchange.
Routers
The routers and network topology are transparent to the Business Objects products as long as there is no filtering on the routers.
Implementing a basic extranet deployment
346
Cluster node deployment

All the nodes in a cluster must be deployed on a single network segment. This is the only supported configuration, and it guarantees optimal performance. In the most common deployment scenarios, web servers, application servers and cluster nodes are deployed on different machines.
Firewall location
Firewalls are commonly set up between the Internet and the web server(s), and between the web server and the application server/cluster (both on the intranet). For detailed instructions for setting up a double-firewall configuration, see page 347.
347
Implementing a DMZ configuration

Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
Figure 11-4 Typical DMZ deployment schema
NOTE
For a description of a DMZ configuration, see page 215. Setting up a DMZ configuration for your Business Objects deployment has never been easier. To begin with, install the required components on the web server, application server and cluster nodes as described in Installing a 3-tier environment on page 249. The web server communicates with the application server through the third-party connector mentioned in Communication through firewalls on page 216. You still need to configure the ORB on the application server machine, however, so that it can communicate with the cluster nodes. You do this with the Configuration Tool that you installed on the application server machine. You must also configure the connector on the web server. To do this you specify a port through which the application server and the web server can communicate in the inner firewall. You must then make sure to open that port in the inner firewall, according to the instructions in the firewall manufacturers documentation.
Implementing a DMZ configuration
348
Implementing an IP redirector
Web server 1 Internet users Application server for cluster A Cluster A
IP redirector Network 1 Switch or router or hub Network 2
Repository
Corporate database
Web server 2 Outer firewall Inner firewall
Application server for cluster B
Cluster B
Shared storage
Figure 11-5 Example deployment configuration using an IP redirector
NOTE
For an overview of this type of configuration, see IP redirectors on page 223.
Configuring the IP redirector

To deploy a system with multiple primary nodes using an IP redirector: 1. Configure a web server with an IP redirector. 2. In the IP redirector route table, map a single IP to multiple IP addresses with their port numbers. See the example below.
349
EXAMPLE Incoming and redirected IP addresses using an IP redirector
Incoming IP 12.10.150.20 12.10.150.20 12.10.150.20 12.10.150.20
Incoming port 80 80 80 80
Redirected IP 34.2.148.10 34.2.148.11 34.2.148.12 34.2.148.13
Redirected port 80 80 80 80
The IP redirector uses this table to send end user requests to the different web servers. Users send requests to one IP address for their Business Objects products; the IP redirector then redirects the request to one of the four Business Objects web servers (IP addresses).
NOTE
Storage must be shared between the clusters in this type of deployment strategy. This requires that the clusters use the same repository. For more information, see page 355.
Deployment conditions
In order to include an IP redirector in your Business Objects server deployment, the following conditions must be met: All the servers need to host exactly the same version of Business Objects server products at the 4th digit level (i.e. 6.x.y.z should be the same within each cluster). You have not placed the IP redirector between the web server and the application server, or between the application server and the cluster.
350
The servers need to be equivalent in terms of the Business Objects modules that are installed and enabled. This is mandatory for real load balancing and failover, otherwise users might need a module that is on one server and not the others. Note that the execution of the Broadcast Agent tasks is completely independent of the IP redirector, as the Scheduler doesn't use the IP redirector. The sticky command must be used to connect to Business Objects. See the following section.
Requesting the same server for multiple requests

You can ensure that the same client gets the same real server for multiple requests by enabling the sticky command on the IP redirector. This command allows requests to be processed by the same real server and retain the statefulness of the client/server connection. For example, if a client is completing an online form, the sticky command ensures that multiple connections are sent to the same server so that the client can complete the transaction. If this command is not used, each request to a virtual server is routed according to the configuration in effect for that virtual server. The connection may therefore be made with a different server, and prevent the transaction from being completed. Implementing the sticky command There are two ways you can implement the sticky command, one based on the IP address of the client PC, and the other using a cookie sent from the web server to the client PC. When using the IP redirector in a Business Objects cluster, you need to implement the sticky command based on the IP address of the client PC. This ensures that once a connection is opened to a physical server, requests from this client will always go to the same physical server until the timeout is reached, thus maintaining the stability of the client/server connection. How you implement the sticky command, and even what the command is called, may vary depending on the IP redirector youre using. See the manufacturers documentation for information.
351
Using a non-transparent proxy policy If your network is set up so that the connections go through a proxy server, the IP redirector may see the proxy IP address and redirect all requests to the same primary node if the sticky command has been enabled. To prevent this, you need to use a non-transparent proxy policy. A non-transparent proxy performs IP translation so that calls to the IP redirector are made as if they came from the client PC itself. The IP redirector can then redirect each call to a different web server and the different Business Objects clusters as appropriate. The sticky command does not time the length of a client connection; it times periods of inactivity. For example, if the sticky command is set to 5, and the client is active, new requests from the client are not sent to another server through load balancing, even if more than five minutes have elapsed. However, if five minutes of connection inactivity have elapsed, the requests from the client can be sent to another real server.
Configuring for a maximum connection and weighted configuration

This type of configuration means using the IP redirector to load balance to the real server according to either or both of the following: a defined maximum number of connections to each particular server the weight of each server (depending on the power of the servers), as determined by the servers Node Weight parameter in the Administration Console To configure the IP redirector to take these factors into account: 1. Determine the maximum number of concurrent active users for each of the clusters connected to the IP redirector (i.e. the corresponding web server). For example, the deployment includes three clusters: - Cluster 1 has three machines and 300 active users. - Cluster 2 has two machines and 200 active users. - Cluster 3 has one machine and 500 active users. 2. Add up the total number of maximum concurrent active users for all the clusters. This determines the Maximum Number of Connections for the IP redirector. In our example, the Maximum Number of Connections is 1000.
352
3. Determine the ratio between the clusters in order to determine the weighted configuration of the IP redirector. For example: - Cluster 1: Weight=300/1000=30% - Cluster 2: Weight=200/1000=20% - Cluster 3: Weight=500/1000=50% How you configure the IP redirector to do this depends on the IP redirector you are using. For information, see the manufacturers documentation. When the maximum number of connections defined for any particular server is reached, the IP redirector should automatically direct new connections to another server.
When the web server fails

What happens when the web server fails? For new connections If the IP redirector can detect that no data is sent, it redirects the request to one of the other web servers. For existing connections If the IP redirector can detect that no data is sent, it redirects the request to one of the other web servers. If users are working with InfoView, the session context is lost and all work that has not been saved will be lost. This is not the case if users are working with 3-tier BusinessObjects.
When the primary node fails

What happens when the primary node fails and the web server is still running? If the request goes to the same web server, the connection fails because the primary node is down. To avoid this, the IP redirector needs to know when the primary node has failed. With this release, Business Objects components (ASP/JSP server pages, servlets and ISAPI components) on the clusters dedicated application server return HTTP error messages to the IP redirector when they detect cluster failure. The exact message sent depends on the invalid response the application server gets to an API call to the cluster, such as CORBA exception or CORBA timeout. You must configure the IP redirector so that the branch on which the errors occur is forbidden for all subsequent requests. How you do this depends on the IP redirector you are using. See its documentation.
353
HTTP errors the application server can send to the IP redirector Here are the possible HTTP errors, what they mean, and in what circumstances they are returned to the application server for transmission to the IP redirector:
354
Error
Description
When it is sent If a CORBA exception is raised within a call to the Business Objects cluster API
500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request. 502 Bad Gateway While acting as a gateway or proxy, the server received an invalid response from the upstream server it accessed in attempting to fulfill the request.
503 Service Unavailable The server is currently unable to handle the request due to the temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be terminated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If there is no Retry-After header, the client should handle the response as it would for a response to error 500 (see above).
If the function isAlive(), returns false when the client tries to connect to the cluster
355
Error 504 Gateway Timeout
Description While acting as a gateway or proxy, the server did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in order to complete the request.
When it is sent If a CORBA timeout is returned in response to a Business Objects API call
You must configure the IP redirector to recognize these HTTP errors.
IP redirectors and shared storage

When you install Business Objects server products, you can choose which server or servers on which you want to actually store the systems cached, temporary and personal documents and files. For performance reasons, it is often a good policy to locate application files, temporary files and personal documents on separate disks or machines. You can therefore better control where the heavier transaction loads are likely to occur, and avoid bottlenecks before they happen. In cluster configurations, the WIStorageManager drive should be placed outside the cluster configuration on a fast file server drive, such as a RAID drive. This facilitates sharing if the primary node fails. The same storage can be shared by multiple servers in the same cluster, or by multiple clusters, provided that they use the same repository. When you are using an IP redirector with a shared storage configuration, however, you must plan for effective synchronization of the storage area. If you are using a Cisco LocalDirector, you will need to configure a disk mirroring system for your storage area in order not to lose users personal documents saved in system storage.
356
Implementing a single web server for intranet and extranet users

Extranet users Application server Web server Database Intranet Primary node
Repository Proxy server Intranet users
Figure 11-6 Single web server for intranet and extranet users
NOTE
For a description of this scenario, see page 356. To implement this scenario: In your DMZ, install a web server and make sure a correctly configured application server connector is installed. In your intranet, have a proxy that allows users to get to the web server in the DMZ. Using WebIntelligence SDK, you can customize the pages that log your users in and out of the application. Since intranet users will have to come to an internal page, and for security reasons you don't want your extranet users to access the same page, you can use simple ASP / JSP code to segregate the logins and logouts for these users.
12
chapter
358
Overview
This chapter describes: Choosing a repository database How much space should you allot for the repository? The location of repository domains Moving the location of resources within or between repositories Optimizing the security domain Deploying and using multiple repositories Choosing the repository for a BusinessObjects session
359
Choosing a repository database

Administrators who have the opportunity to choose a database platform for their repository are advised to consider the following issues: databases which support row-level locking databases which support binary strings the maximum allowed number of open connections
Row-level locking
As the repository is based upon one or more RDBMSs, any application accessing it uses SQL. Many of the day-to-day activities of your users, designers, and supervisors involve database transactions (updates for changed passwords, inserts for exported documents, deletes for removing obsolete documents, etc.). As with any database transaction, these activities invoke the locking mechanisms of the RDBMS to ensure that only one user can update a given value at a given time. Some database versions have more advanced features than others for handling concurrent user access to the same data. In general, for the repository it is best to select a database system that features row-level locking. This mechanism allows for the highest degree of concurrency and minimum conflicts between multiple users accessing and updating data in the same repository domain(s). The following list gives some examples of databases that feature row-level locking: IBM DB2 Universal Database 6 Informix Dynamic Server 7 Microsoft SQL Server 7 Oracle 7 or 8 Sybase Adaptive Server 11.9 Often, row-level locking is not implemented by default and must be activated at either the database or table level. If such a configuration is necessary, you should activate row-level locking for the database prior to creating your repository tables with Supervisor. See your database documentation for more information on configuring row-level locking.
360
Binary data type support

Binaries are a common data type on many relational database systems. They include BLOBs (Binary Large Objects), BYTE, IMAGE and other types. When users exchange documents via the repository, the documents are stored in the document domain. The binary content of a document is sliced into units of a defined length and stored in slices in the OBJ_X_DOCUMENTS table of the document domain. Depending on its size and the length of each slice, a single document might be stored in one or more rows in that table. For each database version, this data is stored in a column of the OBJ_X_DOCUMENTS table that is defined either as a binary string or a (VAR)CHAR string column. If the database supports binary types, the driver will use this type. If not, the driver will convert the binary data to character data and use a VARCHAR type. With Business Objects, you can vary the length of the binary slice to take advantage of the optimal size for each database system. The larger the binary slice, the fewer rows will have to be inserted for each document stored in the repository. This factor can have an enormous positive impact on performance and network traffic. Business Objects therefore recommends that you select a repository that supports long binary columns. Automatic binary slice management in BusinessObjects Because of the differences in the various RDBMS that may be used, the default binary size used is optimized for each RDBMS, and will therefore differ from one to another. Which RDBMSs support binary strings? Not all RDBMSs support binary types. Where binary strings are not supported, (VAR)CHARs are used instead to store your documents. For more information, see your database documentation.
Maximum number of open connections

The performance of the database engine can play a significant role in overall system performance. A large data warehouse need not limit Business Objects functionality or performance. Users in some deployments can access tables with over 5 million rows with a response time of a couple of seconds. However, performance can be affected by the associated indices, the size of the query, and the physical distance between the Business Objects server and the data warehouse.
361
One important factor is the number of open middleware connections possible for a given database. This should be verified with database vendors. For maximum performance you should have as large a number of open connections as possible.
362
How much space should you allot for the repository?

When initially installed, the Business Objects repository takes up roughly one megabyte and its size increases as data is added. The security and universe domains expand relatively little per user, group or universe. It is the document domain that typically takes up the most space, and even that is probably insignificant in comparison to the size of your database. Its size is simply equal to the sum of the documents it contains, rounded off to the highest 10 KB.
The security domain

The security domain is the core of the repository and is used to store all information about users, the groups they belong to, the applications and features they can use, the universes they have access to, the documents they can share, and the list of tasks submitted to Broadcast Agent. Space requirements per user The disk space required for each Business Objects user in the security domain varies widely according to your security structure, the users activity and access rights. Here are just some of the factors you can take into account (the numbers are approximate): Each user created by the supervisor requires some 200 octets of disk space in the security domain. For each group to which a user belongs, you must count an additional 50 octets. Each document or file sent to the user, as well as each attachment to documents distributed by Broadcast Agent requires another 10 octets. Each security restriction for the user (access to documents, security commands, timestamps and so forth) counts for 50 octets. Each time you assign a universe to a user, it costs 550 octets. Broadcast Agent jobs submitted by users require 1.5 KB apiece. After that you need to take into account the indexing of universes and documents used by the user, the users connections, domains and categories. To be safe, we consider that you can calculate the initial required disk space for the security domain using this formula:
363
number of registered users * 0.4 MB Security complexity as a performance factor Because of the quantity and complexity of information in the security domain, it may grow and become large in a way that may not necessarily be linked to the number of users. The complexity of the security being used becomes another important performance factor, as the system must check these security measures during login or while processing documents. For instance, assigning a user to more than one user group has an impact on performance, since the system must check the users rights by executing SQL to compare and compile the rights for the user in each group.
The universe domain

The universe domain is used to store the contents of each shared universe. This is the area to which designers can export the universes that they create. Each universe is a meta-model of the related corporate database. In general, universe files (*.unv) take up about 0.5 MB each. These files are not, however, stored as is in the universe domain; each universes structure is stored in different tables and it therefore takes up more space than its .unv file alone.
NOTE
The 0.5 MB figure is twice the size of the average .unv file, but it is advisable to include a sizable margin for safety.
The document domain

The document domain is used to store the contents of each shared document and file. This is the area to which users can publish Business Objects documents, or upload other types of files, to be shared by all users. This is also where documents such as templates, scheduled documents, and documents or files sent from users to other users are stored. Broadcast Agent accesses the document domain to run automated Business Objects document-processing tasks. The size of documents can vary greatly depending on the application with which they were created, their complexity and their content. For example, we estimate that the .rep files representing BusinessObjects documents generally run from 500 ko for a small document, to 8 Mo for a large document.
How much space should you allot for the repository?
364
To begin with, you should allow 150 MB for the document domain. Be sure, however, to monitor how fast the content grows, and add more space if necessary! As InfoView can process other types of files, you will need to be especially vigilant about allowing enough space for those files as well.
NOTE
In many deployments, administrators choose to create multiple repository domains to support the requirements of their organizations. For instance, it is possible to create a deployment that features a single security domain, two universe domains and five document domains. How can you reduce the size of the document domain? Start Supervisor, and run a Scan and Repair on the document domain.
Figure 12-1 Scan and Repair dialog box
Deletions in the repository are logical deletes, i.e. the records are still in the database. If you click the Compress button in the Scan and Repair dialog box, the deleted records will be cleaned out entirely.
365
The location of repository domains

Do all the domains in a repository have to be on the same server? No. By default, when you first create a repository, you create the security domain plus one document and one universe domain on the same server. As general supervisor, however, you can subsequently create additional document or universe domains on any server on which you have the appropriate rights. You can even create these additional domains using other data accounts or other RDBMSs. Be aware, however, that if you use another RDBMS, users will require the installation of the drivers and connectivities needed to access the various databases.
NOTE
Within a single repository on a single server, you cannot create more than one document or universe domain using the same data account (for DB2, this extends even to the same owner). Creating multiple document and universe domains and distributing them over several servers can be particularly practical if deployment conditions (size of active user population, transaction load, available memory) no longer allow maximum performance. This distribution also relieves the transaction load on the initial server machine and frees up memory for processing.
Geographically dispersed deployments

This type of distribution can be a good solution for geographically dispersed deployments as well. Having one centralized security domain, for example, with decentralized, site-specific universe and document domains, can minimize processing request response times (the corporate data is physically closer to the machines doing the processing). It also makes universe and document access less reliant on the WAN. Shared, single security domain vs. multiple repositories By sharing the security domain among multiple, geographically distributed document and/or universe domains, you facilitate both the management and maintenance of users, and the migration of documents and universes.
The location of repository domains
366
If you deploy a separate repository for each of the physical environments, the migration of WebIntelligence documents becomes more difficult, as an extra procedural step is necessary to copy the WebIntelligence files from one server's storage to the other. Also the migration of universes and BusinessObjects documents between repositories requires the user to retrieve / import the documents and universes from the one repository and log out and then log into the other repository and save / export the documents and universes. For more information on the physical location of the repository and its domains, see Modeling your System on page 163.
367
Deploying and using multiple repositories

You can create additional repositories from Supervisor, by clicking the Admin button to start the wizard. The procedure is the same as for creating your first repository. For instructions, see the Supervisors Guide.
Choosing a repository for a session

In multiple repository configurations, how users choose the repository they want to work with varies according to the product they are using. Choosing the repository for a BusinessObjects session If the supervisor sets up multiple repositories and grants users access to more than one of them, when users attempt to log into BusinessObjects, they can select the security domain to which they want to connect for the current session. As there is only one security domain per repository, this designates the repository itself.
Figure 12-2 Selecting the security domain/repository in 3-tier BusinessObjects
Each item in the list corresponds to a security key file, which points to the security domain controlling access to the associated repository. By default, the .key files name is bomain.key, but for BusinessObjects you can define any name you want.
368
Choosing a repository for an InfoView session The web has a different paradigm than a 2-tier application. A different approach to repository selection is therefore required for the web-based InfoView. When InfoView users log in using their web browsers, the system refers to the .key file stored on the primary node. The users are unaware of the .key file, and in effect select the repository by selecting the URL of the system using the desired repository. Instead of defining .key files with different names, administrators can set up multiple clusters, each of which points to a different repository. Users can select which one to go to by picking the appropriate URL. As bookmarks are available in every browser, it is even easier to let users choose the right repository. This approach preserves the single .key file for each Business Objects site, a more efficient approach for the administrator and for the end user.
Synchronizing data between multiple repositories

Although BusinessObjects users can select the security domain (and therefore, the repository) with which they want to work at login, no allowance is made for transparently sharing secured resources such as universes, connections and documents between repositories. Suppose you start out with a single repository and security domain, and a very large number of users. To improve network performance, you duplicate your configuration and allocate half your users to the new repository. As time passes, your repositories and database information will change, and the two configurations will slip out of synchronization.
369
If it is important that users of all repositories have access to exactly the same data, then you have two options: You can periodically log into the remote repository or repositories as a general supervisor, import the documents you require, then log into your local repository and export them there. Users of the local repository will be able to read the documents but not refresh them. You can develop code to automate this procedure. You can periodically copy the entire corporate database and repository tables from one location to the other. This means that only the repository used as the source of this copy (Repository1) can evolve safely any changes to the other repository, (Repository2) to which the copy is made, will be lost with the copy. The security domain in any repository contains connections to the universe and document domains. When you copy Repository1 over Repository2, you are also copying these connection definitions. The result is that Repository2 will still contain the connections to the original universes and document domains in Repository1. Before being able to use Repository2, then, you'll need to log into Supervisor as General Supervisor, choose Tools > Repository, then change all the connections to re-point to the copied locations. When implementing either of these solutions, make sure you prohibit all user access until the operation is completed.
Moving the location of resources within or between repositories

You can move documents and universes between domains within the same repository, or to another repository entirely. Moving documents from one document domain to another To move documents from one document domain to another within the repository, simply save them to the new document domain from InfoView, then delete the original documents from the original document domain.
370
Moving universes from one domain to another You may want to move a universe from one domain to another, either because you have created a new universe domain within your repository, or because you want to migrate a universe from a development domain to a production domain. To do so, export the universe to the production domain. The first time you export the universe the operation is successful. However, the second time you attempt to do this a conflict arises; Designer detects that there is an existing universe with the same file name but different ID. A general supervisor can help you overcome this restriction by setting the Work with Universe Overrides option in Supervisor. Thereafter, when you export the universe, Designer prompts you to replace the existing universe. For information, see the Designers Guide. Moving universes and documents between repositories Whenever you need to exchange universes and documents between two different repositories, you must first save them in workgroup mode in Designer. To do so, click the Save for all users check box in the Save universe (document) as dialog box.
371
Optimizing the security domain

You create the structure and complexity of the security domain when you create users, user groups and their rights using Supervisor. The design of the security domain, the number of users, number of levels, and the complexity (number of times users repeat in different groups) will affect login time for your deployment. For this reason Business Objects recommends a broad, flat security structure with as few hierarchical levels and as little replication of users in different groups as possible.
NOTE
Because of the introduction of the new module WILoginServer, a multi-level security structure decreases performance significantly less drastically than with previous releases. The speed of the database engine containing the repository can also play a significant role in overall system performance. You can also optimize the Business Objects security domain by running it on a dedicated machine.
Optimizing the security domain
372
Making documents available to users of other repositories

If you also check the Save for all users option in BusinessObjects when saving your documents locally, users to whom you send the documents (and this applies to sending documents by email as well as through the system) will be able to access them even if they do not have access to the repository in which the document was stored. How does this work? Normally, for security reasons, a document that is stored in the repository also contains the repository ID. This means that the document is only accessible to users who have access to this particular repository. The Save for all users option clears the repository ID from the document. The document is then available to all users to whom it is sent, no matter what repository they work with.
373
Changing a clusters repository

The repository used by a cluster is defined by the clusters bomain.key file. To change the repository you therefore have to replace one key file with another. When users log into a clusters repository, all their identification and access data is retrieved from the repository and cached in an .lsi (for Local Security Information) file. This file serves as the cluster's repository security cache concerning that user. The Business Objects system also dynamically caches documents and universes that have been accessed by users in its storage areas. When the system processes subsequent requests for these items, instead of requesting the users security information from the repository again, it simply uses its .lsi file to determine the users identity, and whether the user has the appropriate access rights. When you change a clusters repository, the information in the clusters new .lsi file no longer corresponds to the repository associated with the documents and universes in the storage folders. To avoid incorrect results, you must either flush the clusters storage folders or archive their contents in a different location.
Changing a clusters repository
374
Deploying Specific Products
13
chapter
376
Overview
This chapter provides practical information on deploying specific Business Objects products. It does not cover basic installation and the deployment structure of the entire Business Objects system, or include information on deploying web and application servers. You can find this type of information in Implementing Supported Deployment Configurations on page 337. This chapter contains the following sections: Overall product deployment guidelines Choosing your applications and how they are deployed Deploying InfoView/WebIntelligence Deploying BusinessObjects in 2-tier mode Deploying BusinessObjects in 3-tier mode Deploying Broadcast Agent Deploying Auditor
377
Overall product deployment guidelines

This section provides solution-wide deployment guidelines which can impact how you deploy specific products.
Running desktop and server products on the same machines

Running BusinessObjects in 2-tier mode on the same machine as a Business Objects server used in a 3-tier configuration is not supported for this reason: When Broadcast Agent or InfoView are running, they automatically launch and stop BusinessObjects instances. On the same machine, these system sessions could interfere with the 2-tier BusinessObjects user session.
ASP or JSP?
The Business Objects system supports both IIS (ASP) and J2EE (JSP) application server technologies, although Business Objects does not support the use of both technologies on the same server. The type of application server being used dictates the technology of Business Objects presentation layer components that are used: ASP pages and COM components (WICOM, RECOM) run on Windows IIS web/application servers JSP pages and Bean components (WIBean, REBean) run on J2EE application servers Each of these configurations is described in more detail in How the Business Objects System Works. If you use IIS as your web server, you generally use ASP, but you can use JSP if IIS is used together with a separate application server.
Overall product deployment guidelines
378
Your choice of an ASP or JSP environment limits/enables the use of different Business Objects features: Use... For this feature or platform... UNIX platforms WebIntelligence for OLAP data sources WebIntelligence HTML Report Panel WebIntelligence Java Report Panel Interactive viewing of WebIntelligence documents in InfoView ASP JSP
379
Choosing your applications and how they are deployed

The following sections provide an overview of the architectural differences between deployments of BusinessObjects in 2- or 3-tier mode, and InfoView. The sections focus on the differences in communication protocols and in the distribution of application processes between the three deployment types.
TIP For a detailed functional comparison of WebIntelligence, InfoView, and BusinessObjects in 2- and 3-tier modes, see How Products Compare Functionally on page 441.
Deployment comparisons
This section describes three different deployments: BusinessObjects in 2-tier mode BusinessObjects documents viewed in InfoView BusinessObjects in 3-tier mode Each section focuses on the architectural and functional differences between the different deployments. 2-tier, 3-tier BusinessObjects, or InfoView? on page 384 uses this information to present recommendations on choosing a deployment scenario. BusinessObjects in 2-tier mode In 2-tier mode, the database connectivity required to contact the repository and corporate databases is installed on the client. The client communicates directly with the repository and the corporate database through proprietary database middleware protocols. The 2-tier client must be installed from the installation CD. The middleware connectivity for the appropriate database type must be installed on every 2-tier client. SQL queries are generated on the client, then sent to and retrieved from the repository via the middleware connectivity. The client and the repository must be on the same network to allow this connection. This connection cannot pass through a firewall or intermediary server.
380
This diagram shows the relationship between the client and the server in 2-tier mode:
Client with database connectivity and BusinessObjects installed
User interface Application interface Report engine Calculator Query technique Cube Database connectivity RDBMS connectivity Repository
BusinessObjects document (.rep) busobj.exe
Corporate database
Figure 13-1 2-tier BusinessObjects deployment
381
BusinessObjects documents viewed in InfoView Users can view BusinessObjects documents in InfoView without launching 3-tier BusinessObjects in HTML format, PDF format or enhanced document format. The following diagram shows the relationship between the client and the system components in this deployment scenario:
Web browser only: no installation on client
Business Objects middle tier
User interface HTTP layer (client)
HTTP communication Query HTTP layer (server) Display Application interface Report engine
Read-only versions of .rep files
Calculator Query Cube Database connectivity

SQL SQL
Repository
BusinessObjects document (.rep) busobj/ bolight WIQT Corporate database
Figure 13-2 BusinessObjects document viewed in InfoView
382
When BusinessObjects documents are opened, refreshed and published in InfoView, the document (*.rep) is generated on the server, and a read-only version is transferred to the client browser via HTTP. In an InfoView deployment, all resources are hosted on the server, as opposed to the BusinessObjects client which hosts a Windows application (BusObj.exe). In InfoView, the client connects to the server via the client browser and the web server: no application elements are installed on the client. A server version of the busobj.exe is hosted on the server (BusObj/bolight in Figure 13-2). As a result, although InfoView is a heavier application in terms of server load, it transfers less data via HTTP from client to server than 3-tier deployments of BusinessObjects. BusinessObjects in 3-tier mode BusinessObjects in 3-tier mode is a Windows application that can be launched: from the Windows Start menu from an active InfoView session In 3-tier deployments of BusinessObjects, the middleware is installed on the server, and the client can only connect to the repository through the Business Objects server. All client-server communication is over HTTP. The 3-tier BusinessObjects client can be downloaded and installed from the server during an active InfoView session, or installed directly from the Business Objects installation CD.
383
The following diagram shows the relationship between the client and the server in 3-tier mode:
Client hosting busobj.exe with no connectivity
User interface Application interface Report engine Calculator Business Objects middle tier Query technique Cube HTTP translation HTTP layer (client) HTTP communication, binary content
HTTP Layer (server) Repository
BusinessObjects document (.rep) busobj.exe
WIQT
Database connectivity
SQL SQL
Corporate database
Figure 13-3 3-tier deployment of BusinessObjects
Unlike the 2-tier client, the 3-tier BusinessObjects client cannot directly access the Business Objects repository or the data warehouse. The data resulting from the query is transferred through the server to the 3-tier client via HTTP. For detailed information about this type of deployment, see How the Business Objects System Works.
384
2-tier, 3-tier BusinessObjects, or InfoView?

The following sections provide information on the factors involved in choosing the appropriate application(s) for your deployment. The performance of any system, and of any application, depends on a large number of interrelated factors. Based on the performance bottlenecks you perceive in your deployment, one or several of the factors may take precedence over the others. No two deployments are alike; there are therefore no absolute recommendations. For this reason, the impact of each factor is analyzed separately. It is up to you to decide which factor(s) are most relevant to your deployment. Functionality available only in 2-tier BusinessObjects 2-tier deployments offer functionality not available with InfoView or 3-tier deployments of BusinessObjects, including: document creation using OLAP data sources (note that you can refresh OLAP documents in 3-tier mode) document creation using stored procedures document creation using freehand SQL System resources 3-tier deployments of BusinessObjects leverage more resources on the client machine than InfoView, whose deployment requires only a browser on the client side. In 3-tier BusinessObjects, both the microcube and the report engine are located on the client. When a user requests a BusinessObjects document in InfoView, only the HTML or *.pdf resulting from the query is transferred to the client. In 3-tier BusinessObjects, both the query and the data fetched from the database are transferred to the client. The following table displays the different considerations in terms of system resources for each deployment type.
385
Criteria
Deployment type/usage BusinessObjects deployment type 2-tier 3-tier InfoView (Read, refresh only)
Interactive use of *.rep files (create, edit) Your network is a LAN Your network is complex or slow (WAN, extranet, firewalls, proxies) All load on server Least server overhead All load on client No server between client and repository Load shared between client and server
386
User profiles Determining the specific user profiles in your deployment can help you choose the product and deployment type best suited to users needs. The following diagram shows an example of the distribution of user profiles in a typical deployment:
Power users
Analysts
Readers and Interactive users combined
Distribution of user types in a typical deployment
This diagram is a general example. The actual proportion of each type of user depends on the specific deployment.
NOTE
For definitions of these user types, see Types of users on page 152. Different actions, and therefore different workflows, are associated with each user type. To select the appropriate application for each user type, define the typical actions of users within your deployment, then match them to the appropriate application, as demonstrated in the following example.
387
EXAMPLE Defining user population needs
Based on the user descriptions for the model deployment listed above, the following table lists the user types and the application they require: User type Percentage of total user population 70%-80% 15%-25% 5% Deployment type/usage
Readers and Interactive users Analyst Power user
InfoView is generally the most efficient solution for this user type 3-tier BusinessObjects, InfoView 2-tier BusinessObjects, WebIntelligence, Designer, Supervisor
Network issues The following sections describe network issues that may affect your choice of deployment type. Wide Area Networks This section applies if you deploy over a slow network, such as a Wide Area Network (WAN). If users do not require BusinessObjects functionality, use InfoView. If users require BusinessObjects functionality, choose 3-tier BusinessObjects. This deployment of BusinessObjects has been optimized to reduce network traffic and to improve performance over slow and saturated networks, including Wide Area Networks. Firewalls and proxies This section applies to you if your deployment includes a firewall or proxy on the network. For BusinessObjects functionality in configurations including firewalls and proxies, choose 3-tier BusinessObjects. 3-tier BusinessObjects enables the client and the server to communicate via HTTP, and can therefore be deployed across firewalls, extranets, subnets, proxies, gateways, intermediary servers. However, if users only need to view and refresh BusinessObjects and WebIntelligence documents, InfoView may be a more efficient choice.
388
Deploying InfoView/WebIntelligence
Business Objects recommends that the server hosting the WIADEServer module be a Windows machine if: InfoView users in your deployment want to use the enhanced document viewer for BusinessObjects documents the deployment is using a web server in CGI mode In this case, Basic Authentication must be set on both the web server and the node hosting the WIADEServer module.
The WebIntelligence Java Report Panel

Technology required To run the WebIntelligence Java Report Panel, you must have the required versions of Internet Explorer and Java Virtual Machine (JVM). To find out which versions you need, check the latest Product Availability Report (PAR). As of this writing, the PAR can be accessed from the following URL: http://www.techsupport.businessobjects.com To access this site, you must be registered for Business Objects online customer support. You can run the Java Report Panel with either ASP or JSP. Rights required to download the Report Panel The security command Use WebIntelligence Java Report Panel must be enabled in Supervisor. In Windows 2000, you must be logged onto the PC as a Windows user with an Administrator or Power User security profile, and you must have the right to write in the following registry key and sub-keys: HKEY_LOCAL_MACHINE\Software\Microsoft\Code Storage Database The size of the Java Report Panel Once the Java Report Panel is installed on the client computer, it takes up 3 MB. The CAB file which is actually downloaded, however, contains a compressed version of the applet whose size is only 840 KB. This speeds up the time required for the download, and is especially critical if the panel is being downloaded through a modem or over a low bandwidth network. After the file is downloaded, it is then uncompressed locally. Installing the panel after the download is done takes some time but it requires only client computer processing.
389
The WebIntelligence HTML Report Panel

You can run the WebIntelligence HTML Report Panel only with JSP. In order to use the HTML Report Panel, the Use WebIntelligence HTML Report Panel security command must be enabled for the user or group in Supervisor.
Deploying InfoView/WebIntelligence
390
Deploying BusinessObjects
This section contains: Deploying BusinessObjects in 2-tier mode Deploying BusinessObjects in 3-tier mode
Deploying BusinessObjects in 2-tier mode

The installation of BusinessObjects in 2-tier mode on the same machine as the Business Objects server is not supported.
Deploying BusinessObjects in 3-tier mode

To deploy BusinessObjects in 3-tier mode, you must respect a set of conditions both on the server and on the client side. Installation BusinessObjects in 3-tier mode can be installed on a client machine either through the standard Business Objects installation CD, or by downloading it from InfoView. If the Business Objects server is upgraded, users are automatically prompted to upgrade their version of BusinessObjects on their desktop.
NOTE
If a previous version of BusinessObjects in 3-tier mode was already installed on the machine before you installed version 6.x, you must manually delete the ZaboCheckAndRunControlClass file from within Internet Explorer. This is because the previous version of ActiveX is not compatible with the current version of BusinessObjects. When you delete the file and rerun BusinessObjects, the new version of the ActiveX is automatically downloaded to your machine.
391
To delete the ZaboCheckAndRunControlClass file: 1. Open Internet Explorer. 2. On the Tools menu, choose Internet Options. The Internet Options dialog box appears. 3. Click the Settings button. The Settings dialog box appears. 4. Click the View Objects button. You see your downloaded program files. 5. Delete the ZaboCheckAndRunControlClass file. 6. Rerun BusinessObjects. The new version of ActiveX is downloaded to your machine. Pre-installation requirements on the client machine Before you or any user tries to install BusinessObjects in 3-tier mode either from the CD or through InfoView, you must verify the following on the client machine: It must be a Windows machine. The clients web browser security settings required to download signed ActiveX controls are enabled. If users do not have these rights, they will not be able to view and edit BusinessObjects documents from InfoView, and they will be able to launch 3tier deployments of BusinessObjects from the Windows Start menu only. The directory where the CAB files are copied to must not be protected; that is, it must be readable, with no password protection. WinInet must be installed. Windows installer uses WinInet to execute the download of the installation packages. However, WinInet is included in Internet Explorer and therefore installed in standard Windows configurations. If there is a proxy, it must be correctly configured using the Windows Internet settings. To install BusinessObjects via a browser, you must have the same rights as when installing via the CD. In particular, you must have administrative rights by default. In the users InfoView Options pages, the BusinessObjects option is selected either as the default document editor, or the default application for viewing BusinessObjects documents.
392
Server configuration requirement BusinessObjects in 3-tier mode uses WIQT connectivity features to process BusinessObjects documents. It does this by channeling all transactions through WIADEServer. This module must be enabled on the server on which the component allowing the download of BusinessObjects from InfoView is installed. This component is called BusinessObjects Web Installer in the Business Objects installer. Version compatibility check When you launch BusinessObjects in 3-tier mode or use it to try to access a BusinessObjects document, the system checks compatibility between: the version of InfoView the version of BusinessObjects on the users computer If any of the components are not compatible, the system prompts you for the necessary upgrade. What happens if version 5.x and version 6.x are both installed on the users computer? If you launch BusinessObjects from version 5.x of InfoView, the system uses the most recent version of BusinessObjects used on that machine, even if it was 6.x. If you launch BusinessObjects via InfoView version 6.x, the system always uses version 6.x BusinessObjects. User rights for use of BusinessObjects For optimal use of BusinessObjects version 6.x from InfoView, users must have the following access rights: the right to use the BusinessObjects product (in the Configuration tab of the Resource pane in Supervisor) If the user needs to run macros and add-ins in BusinessObjects documents, the supervisor must also grant the right to download Visual Basic for Applications from the Business Objects system. The installation settings must also be changed for the InfoView page: use the setup command line mode (INSTALLVBA = 1). For more information, see the Installation and Configuration Guides. the right to download BusinessObjects in 3-tier mode (in the WebIntelligence Administration security command family: Download 3-Tier BusinessObjects)
393
the right to access the InfoView document lists (in the WebIntelligence InfoView security command family: Read Corporate Documents and Read Inbox Documents) By default, these rights are enabled. the right to create documents (in the BusinessObjects Documents security command family: Create Documents) By default, this right is enabled.
Universes Universes must be accessible to Business Objects users: The supervisor must grant users the right to access universes, and the proper database connections must be set, using Supervisor. The users can use universes stored locally on the client, as well as universes exported to the repository. On the client, these universes must be in: $PROFILEDIR\Application Data\Business Objects\Suite 6.0\universes The default $PROFILEDIR is c:\Documents and Settings\<user login name>. Visual Basic for Applications When you install BusinessObjects from InfoView, Visual Basic for Applications (VBA) is not installed, to reduce the download size. If you need to create macros or view documents that use them, you must have VBA installed. An administrator may change this default behavior by editing the InfoView page that serves to download BusinessObjects. This page is called ZABOInstallPopup.asp or ZABOInstallPopup.jsp, depending on your deployment. In this page, look for the line starting with <param name="strParams" value="THREETIERBUSOBJ=1...">. In it, replace VBAINSTALL=0 with VBAINSTALL=1 to force the installation of VBA if needed. For more information, see the command-line chapter in the Installation and Configuration for Windows Guide.
394
Obtaining an .rkey file for BusinessObjects The .rkey file contains the information BusinessObjects needs to connect to the repository. It is the equivalent to the .key file for BusinessObjects in 2-tier mode. Unless a valid .rkey file exists on the client machine, you cannot view documents with BusinessObjects. If you install BusinessObjects from the CD, then start BusinessObjects from the Start menu, you may not be able to view documents right away, because the installation of BusinessObjects does not automatically copy an .rkey file onto the client. To procure this file, you must do one of the following: copy an existing .rkey file to the $PROFILEDIR\Application Data\Business Objects\BusinessObjects Enterprise 6\lsi directory on the client machine first launch BusinessObjects from InfoView by opening a BusinessObjects document This triggers the generation of the .rkey file on the client. BusinessObjects and authentication Authentication modes required for offline use of BusinessObjects Off-line BusinessObjects users cannot log in offline using NT Challenge/ Response or Basic Authentication. BusinessObjects and SSL Like InfoView, BusinessObjects works with web security standards such as the Secure Socket Layer (SSL), which uses advanced encryption algorithms to protect data transferred over the network from unauthorized access.
395
Managing network elements Firewalls In 3-tier deployments of BusinessObjects, traffic is pure HTTP traffic. Firewalls therefore must allow communication through the port that you use for HTTP, which is generally port 80. If the firewall checks HTTP headers, it must allow packets labeled by BusinessObjects. If the firewall checks that any HTTP packet contains only HTML (prohibiting binary content), 3-tier deployments of BusinessObjects cannot function. Proxies: content caching Content caching generally does not improve traffic for 3-tier deployments of BusinessObjects because each transaction is unique. There is no benefit in caching data that is not reusable. As a result, Business Objects recommends that outgoing BusinessObjects traffic have an HTTP header for NO-CACHE. Security domain selection Users can choose from multiple security domains only if they launch BusinessObjects in 3-tier mode from the Windows Start menu. This allows you to choose a remote key file (with an .rkey extension) which points to different portals. If you installed BusinessObjects from the CD, you can choose either an .rkey or a local .key file found on the client machine when you launch the product using the Start menu. Multiple .key file selection for InfoView or BusinessObjects launched by InfoView is not supported.
396
Deploying Broadcast Agent

This section covers: Installation Sizing guidelines The factors that impact the size and number of machines you need for Broadcast Agent How many Broadcast Agents and Schedulers? How many Schedulers should you create for each installation of Broadcast Agent? Matching components with machines Which Broadcast Agent component should you run on which machine? UNIX or Windows? You can deploy Broadcast Agent in a Windows or UNIX cluster. A number of limitations and performance considerations are reviewed. Server optimization using caches Server filenames, pathnames, and permissions What pathnames must you use when scheduling documents? Configuring database connections For more detailed information, see the Broadcast Agent Administrators Guide.
NOTE
With BusinessObjects Enterprise 6.1, Broadcast Agent encompasses two different products: Broadcast Agent Scheduler and Broadcast Agent Publisher. Do not confuse the product name Broadcast Agent Scheduler with the Scheduler, the Broadcast Agent component which periodically queries the repository to determine which documents are due for processing. When a scheduled task is due, the Scheduler sends the task to the appropriate Business Objects server component for processing.
Installation
To install Broadcast Agent Scheduler, choose the Broadcast Agent option in the standard Business Objects installer. Broadcast Agent Publisher uses a separate installation process. See the Broadcast Agent Publisher Installation and Deployment Guide.
397
Sizing guidelines
The size and number of machines you need for Broadcast Agent depends on a number of factors, including: quantity of documents to be scheduled complexity of the documents how often documents are refreshed speed of the connection between the repository and the Broadcast Agent server speed of the underlying database number of users simultaneously accessing the data Memory requirements by document type In general, a document being processed by Broadcast Agent requires the same amount of RAM and CPU time as if it were processed in the same way by an interactive user. 100 documents scheduled for refresh at the same time is the equivalent of 100 concurrent usersall logged in and running simultaneous queries. If your system is unable to cope with the level of activity requested, then some tasks may fail or be delayed until the system is less busy. Take this into account when making decisions about server sizing, as well as when scheduling your documents. If you use report bursting (see the Broadcast Agent Administrators Guide) with options set to refresh each users copy of a report according to that users profile, a separate refresh is carried out for each recipient. In other words, if you burst a document according to the profile of 100 recipients, it carries the same load as refreshing the document 100 times. The amount of RAM required for each document to be processed depends on its length and complexity. Business Objects recommends that you create a set of typical documents upon which your users are apt to rely. The document size is the same whether the server is UNIX- or Windows-based. The best way to ensure the memory requirements for your deployment is to build the reports on a test system and find out how large they actually are. You can then size your servers accordingly.
How many Broadcast Agents and Schedulers?

You can configure multiple Broadcast Agents in your configuration, and multiple Schedulers for each Broadcast Agent. The advantage of having several Broadcast Agents is that you can have one for each user group (Sales, Finance, and so on) defined in each repository.
398
One advantage of having two or more Schedulers for each Broadcast Agent is for failover. Without a working Scheduler, no jobs are processed. Because an additional Scheduler does not use significant resources, many configurations include two Schedulers on different machines for each Broadcast Agent. In this way, even if one node fails, the tasks are still processed. Business Objects recommends that you not exceed 3 Schedulers for each Broadcast Agent. A typical cluster configuration has one or more Schedulers, plus either a BOManager or WIQT on every secondary node.
Matching components with machines

This section explains which Broadcast Agent components should be run on which machines. (For more information on components, see the Broadcast Agent Administrators Guide.) You do not have to set up your Broadcast Agent cluster over multiple servers. If you decide to install all components on one machine, you must declare the machine as the primary node when you install Broadcast Agent. The machine running the Scheduler does not need exceptional processing power or disk space. However, machines running BOManager and WIQT require much more processing power.
NOTE
You can limit the number of processes which are run concurrently on each machine by using the parameter settings in the BOManager, WIQT, and Scheduler modules. It is good to configure sufficient swapping space to allow for peak conditions. Keep in mind that: If a job cannot be handled with the available RAM, swapping occurs and processing slows down. If swapping occurs and the swapping space is exceeded, performance will be greatly affected, and eventually the system may become unstable. Installing multiple BOManager and WIQT modules, one on each machine in a cluster, provides load balancing and failover. A Scheduler on a machine can process documents (using WIQT or BOManager) on any machine in the same cluster, if the WIQT or BOManager is enabled and its Enable batch processing parameter is set to On. The Scheduler itself uses very little CPU time or RAM, and can easily reside on the same machine as a BOManager or WIQT process without significantly impacting performance.
399
The Broadcast Agent Console and the Administration Console are relatively lightweight user interfaces, and do not consume significant resources. They can be installed on any machine on the subnet, not necessarily a cluster node machine. If your system is processing both WebIntelligence 2.x and 6.x documents, you can set the Max. no. WebIntelligence 2.x jobs running and Max. no. WebIntelligence 6.x jobs running parameters to proportionally balance the load between the two types. For example, if you have 80% of your scheduled documents in WebIntelligence 2.x format, and only 20% in 6.x, then set the Max. no. WebIntelligence 2.x jobs running to four times the Max. no. WebIntelligence 6.x jobs running.
UNIX or Windows?
You can deploy Broadcast Agent on a UNIX or a Windows cluster. In general, UNIX nodes can be used to process the majority of tasks, while Windows nodes provide some additional connectivities and functionalities, such as access to OLAP data sources and custom macros written in VBA. The following Broadcast Agent functionality is available on Windows only: Direct access to some OLAP data sources Contact Business Objects customer support for the current list of supported OLAP servers. Visual Basic procedures used as data providers Personal data files Custom macros in VBA These macros depend on Microsoft proprietary technologies that are not currently supported under UNIX. Some RDBMS data sources Contact Business Objects customer support for the most current information.
Server optimization using caches

The Business Objects product line includes several cache mechanisms to improve server performance, especially in large deployments. Login cache After users execute a task via Broadcast Agent, they do not have to log in again when submitting subsequent tasks. BOManager caches their login information for each Broadcast Agent task. If users have the appropriate access rights, the session context for the task is restored directly from the cache.
400
The life span of cache entries is controlled by the Scheduler login cache duration parameter in BOManager. Presentation cache To help prevent overloads at peak transaction periods, you can preload the cache when you process a task. When you schedule a corporate document with Broadcast Agent from BusinessObjects, you can cache the documents presentation by using one of the following options: Enhanced Document Viewing Generates the document in metafile format, which is recognized by the ActiveX viewer in InfoView. The metafile is then stored in the server cache. Standard HTML Generates the HTML for scheduled corporate documents, suitable for the standard HTML document viewer in InfoView. PDF Available for other users without any need to regenerate the PDF, unless a change has occurred in the document. The first time an InfoView user asks to view the document in a certain format, BOManager retrieves the presentation and stores it in a cache managed by the WIStorageManager. When other users then access the document in InfoView, they access a pregenerated file. This means that: InfoView requests for BusinessObjects documents do not require logging into BOManager there are fewer demands on available processes in your cluster the documents presentation doesnt have to be generated. The document is displayed faster and more efficiently response time remains constant and doesnt depend on the documents size or complexity CPU power and BusObj processes are made available for refreshing documents (ad hoc queries) In large organizations, where important documents are viewed regularly by thousands of users, caching can prevent critical system congestion and overload.
401
Caching tips Encourage users to preprocess all corporate documents that they expect will be viewed by multiple usersparticularly PDF documents, which may require substantial processor time to generate. Users should schedule the documents to be refreshed often. If the cached presentation is always up-to-date, recipients wont need to refresh them. Cached documents take up only about 5 KB of disk space per document, plus 20 KB per metafile page. PDF and HTML documents, by contrast, often reach several megabytes.
Server filenames, pathnames, and permissions

InfoView or BusinessObjects (2-tier) users who schedule Broadcast Agent tasks specify a pathname and filename when using: the File Watcher option to schedule tasks to run only when a specific file is present the Distribute via File System option to copy a scheduled document to a specific location Save as RTF Save as TXT Save as PDF Save as XLS The pathname relates to the server on which the process (BOManager) is running, not to the users machine. For example, if the user selects Save as RTF with the filename C:\MyFile, Broadcast Agent attempts to save the file to that location on the server, not on the client.
NOTE
To specify a pathname or filename on a machine other than the server on which the Broadcast Agent is running, you must specify a full UNC (Universal Naming Convention) name; for example: \\MyMachine\SharedFolder\MyFile.txt The BOManager executing the scheduled task must have the required permissions: to write to the file itself and its parent folder to access every folder in the path
402
For example, if a user specifies Save as TXT with the filename: \\MyMachine\MyFolder1\MyFolder2\MyFile then the BOManager must have permission to access MyMachine, MyFolder1, MyFolder2, and MyFile, and permission to write to MyFolder2 and MyFile. Instead of specifying a filename, you can send a job through Broadcast Agent on a UNIX machine using the default location. The default location for all scheduled jobs in the $BO_FILE_PATH environment variable is defined in the MyWebiEnv.sh file. To use a default directory, enter a dot (.) in the dialog box when asked for the directory location. UNIX and Windows pathname conversion Broadcast Agent automatically converts Windows pathnames (with back-slash delimiters, \) to UNIX pathnames (with forward slash delimiters, /) when needed. This conversion is transparent to the user. For example, if you specify the path: \usr\current It is interpreted by a Scheduler on a Windows server as c:\etc\usr\current (where c: is the default drive), or on a UNIX Scheduler as /usr/current.
TIP Encourage users to follow the Windows convention (with a backslash) as this is interpreted correctly on either system. UNIX format pathnames (with a /) will be interpreted correctly only on UNIX servers.
You can mount directories on UNIX servers to map to file systems on another networked UNIX machine, so that users have the functionality they require without needing to know the physical location of the files. See your UNIX documentation for further information. Ensure that directories are mounted appropriately on UNIX machines so that any Windows files that users need to access from UNIX systems are in accessible folders. Also, inform users that Windows filenames are not case-sensitive. UNIX filenames, however, are case-sensitive.
403
NOTE
When you use a printer other than the default printer, you must enter its path in the Select the Printer box under Print Properties. Because the printer name entered here is converted to lower case before it reaches the UNIX Broadcast Agent server, the printer name specified on the server must also be in lower case. Setting the $BO_FILE_PATH variable On a UNIX server, you can define the variable $BO_FILE_PATH to enable Windows filenames to map to UNIX file names correctly. For example, you can add the following line to the WebIEnv.sh file:
BO_FILE_PATH=/opt/webidoc/ ; export BO_FILE_PATH
This causes the pathnames specified to be mapped, as shown in the following table.
NOTE
The conversion results in lower-case UNIX pathnames, regardless of the case used in Windows. Windows path MyFile \\Server\MyFile D:\MyFolder\MyFile UNIX path on server /opt/webidoc/myfile /opt/webidoc/server/myfile /opt/webidoc/d/myfolder/myfile
404
Path naming conventions You can name paths in any of the following formats: UNC, which expresses the location on the network by giving a machine name as well as a path: \\<machinename>\<pathname>\<filename> Business Objects recommends using UNC. This avoids any confusion, and enables the process to succeed even if the Scheduler is running on a different machine. Mapped network drive, on the server running the Scheduler: <mapped drive letter>:\<pathname>\<filename> Local, relative Windows filename: \<pathname>\<filename> Local, absolute Windows filename (local to the server, not the client): C:\<pathname>\<filename> Local UNIX filename: /<pathname>/<filename> The table below summarizes the various formats. Path format UNC Mapped network drive UNIX Finds locally or remotely Fails Windows Finds locally or remotely Finds if mapped drive is set up on server Finds locally Finds locally Fails
Local relative Windows filename Local UNIX filename
Finds locally Finds locally
Local absolute Windows filename Fails
You should shield users from these issues by mapping and mounting structures appropriately, and informing users what the best practice is.
405
EXAMPLE Pathnames
A user wants to use File Watcher to schedule a report called MyReport, to be refreshed whenever the file Update_Completed is present. The Update_Completed file is automatically created by a weekly update process, whenever the data warehouse is updated with new data. The file is stored on a UNIX server called Orion, located in /datawarehouse/Update_Completed If the Scheduler and BOManager are running on a UNIX server called Pluto, and the user specifies /datawarehouse/Update_Completed then the task will never be executed because the file cannot be found. However, if the Scheduler is running on the same server machine (Orion), the user can specify the path in File Watcher as: \etc\datawarehouse\Update_Completed or /datawarehouse/Update_Completed To be safe, wherever the Scheduler is running (Windows or UNIX), the user would specify: \\orion\etc\datawarehouse\Update_Completed HTML and web server file names When Broadcast Agent saves a file in HTML format, or sends it to a web server using the Distribute via Web server action, it automatically converts the following characters in the file name so that they conform to standard web usage: ampersand (&) empty space These characters are converted to an underscore. For example, a file named Alpha & Beta.rep becomes Alpha_Beta.rep when it is saved in HTML.
406
Configuring database connections

Broadcast Agent may establish hundreds of database connections per day. The configuration of these connections is therefore critical to the efficiency of your deployment. Configuration guidelines When configuring your connections, you can choose from the following options in the Advanced tab of the Connections dialog box: Keep the connection active during the whole session Keep the connection active for X minutes Disconnect after each transaction Business Objects recommends using either Keep the connection active for X minutes or Disconnect after each transaction. The reason is that an internal module called SQLBO handles a pool of connections to the different domains involved. The connection can be physically closed (Disconnect after each transaction) or only logically closed (Keep the connection active during the whole session). Using shared and personal connections Most BusinessObjects documents access data through a secured connection stored in the repository. However, BusinessObjects users can also create documents that access data through personal connections or shared connections, which are not defined in the repository. These types of connection are defined in two locations: in the document itself in .lsi (Local Security Information) files stored in the LocData folder on the users machine When users send documents based on shared connections to Broadcast Agent, the connection information is obtained from within the document itself. However, if the document contains a VBA macro which directly accesses the shared connection, the sdac.lsi file on the server must contain the shared connection data. The LocData directory All Broadcast Agent servers and BusinessObjects client machines use a LocData directory, whose location is determined during the installation process.
407
In many deployments, a single LocData directory on the primary node is referenced by all the other machines over the network, in order to simplify administration. This directory contains files which define the database connections: the bomain.key file defines the default connection to the repository. additional .key files define connections to alternative repositories that the user can reference at logon. the sdac.lsi file defines shared connections the pdac.lsi file defines personal connections Recommended configuration If you want shared connections to be available to all users (rather than just to the user who created the connection), set all the cluster machines and client machines to use the LocData directory on the primary node. When the installer on each machine asks for the path of the LocData directory, give the network path of the LocData directory on the primary node. This directory must be under a mapped network drive on each Windows machine, or a mounted network path on each UNIX machine in the deployment. All machines then access the same .lsi and .key files. Synchronizing sdac.lsi files If you do not set all the cluster machines and client machines to use the LocData directory on the primary node, you need to verify that all Business Objects client machines and Broadcast Agent servers have a copy of the same sdac.lsi file in their local LocData folder. When you install the secondary nodes, their sdac.lsi files are automatically replaced with a copy of the sdac.lsi file from the primary node. When a user adds a new shared connection, the new sdac.lsi file must be copied to all other clients and to the servers. To update all the secondary nodes, copy the new sdac.lsi file to the primary node and click the .key file synchronization button in the Administration Console. This copies the .key files and the sdac.lsi file from the primary node to the secondary nodes. Enabling VBA custom macros to access shared connections If a user sends a document based on a shared connection to Broadcast Agent, and the document includes a VBA custom macro that directly accesses the shared connection, the sdac.lsi file in the LocData folder on the machine where the VBA code is running must contain the connection information for the shared connection.
408
If the sdac.lsi file on the server does not include the shared connection, then the task will fail with the error: (303) Error with no ErrorHandler with BreakOnVBAError =FALSE. If all machines in the deployment share the same LocData folder on the primary node, the task will be processed correctly because there is only one sdac.lsi file in the cluster and it includes all shared connections.
409
Deploying Auditor
When deciding on a deployment strategy for Auditor, you need to consider your system architecture in light of Auditor requirements. Keep in mind that Auditor is built on top of Business Objects, and therefore needs a Business Objects server installation on which it can run. Auditor must be installed on a dedicated Auditor server in a dedicated cluster.
Setting up Auditor
To set up Auditor, you need to: 1. Complete the file installation by installing Auditor as part of administration products in the Business Objects installation wizard. For complete instructions, see the Installation and Configuration Guides. 2. Set up the Audit database and make sure the Business Objects system is configured to store its audit information in it. You will find instructions for doing this in the System Administrators Guide. 3. Use Designer to export the universes you will be using with Auditor to the repository. 4. Create the database views. 5. Export the predefined indicators to the corporate repository.
NOTE
Although Business Objects recommends performing these steps in this order, you can carry them out in a different order, at different times, and from different machines. For more detailed information, see Part I in the BusinessObjects Auditor Guide.
Do you need to install Java SDK?

In order to use Auditor, the Java SDK must be part of your deployment configuration. Because the Java SDK is included as part of all application servers except Tomcat, you need to install it only if your Business Objects deployment is using a Tomcat application server.
Deploying Auditor
410
Monitoring multiple clusters

Version 6.x of the Business Objects system supports multi-cluster auditing. Each cluster, however, must have a different name in order for this type of auditing to work (you name clusters using the Configuration Tool). In addition, to ensure that Auditor can retrieve coherent information, all the clusters must point to the same repository.
Deployment scenarios
You must also choose the type of repository configuration. You can use either of the following configurations: Double repository The main Auditor repository of the monitored Business Objects system, along with an Auditor-dedicated repository. Single repository Only the main Auditor repository of the monitored Business Objects system. These scenarios are described below.
411
Scenario 1 Dedicated cluster / double repository The following diagram shows how Auditor can be deployed in a Business Objects system with an Auditor-dedicated server/cluster, and an Auditor-dedicated repository.
Production database
Business Objects server
Intranet Extranet
Clients Write Business Objects repository
Audit database
Read Auditor-dedicated server
Intranet Extranet Auditor-dedicated repository
Auditor client
Figure 13-4 Dedicated server/double repository for Auditor
Deploying Auditor
412
Because full separation of the Business Objects cluster being monitored and Auditor applications optimizes system performance and security, Business Objects recommends this scenario if you have no hardware constraints.
NOTE
In this scenario, we recommend turning off the User Activity Log in the Administration Console for the cluster dedicated to Auditor.
413
Scenario 2 Dedicated cluster / single repository The following diagram shows how Auditor can be deployed with an Auditordedicated server/cluster, but without an Auditor-dedicated repository.
Business Objects server Production database
Intranet Extranet
Clients Write Business Objects repository
Audit database
Read Auditor-dedicated server
Intranet Extranet
Auditor client
Figure 13-5 Dedicated server/single repository for Auditor
This deployment, with its shared repository, is ideal if you want to make Auditor indicators available to other users of the repository.
Deploying Auditor
414
Deploying WebIntelligence for OLAP Data Sources
14
chapter
416
Overview
OLAP (Online Analytical Processing) is a set of tools for analyzing data stored in a database. A relational database and an OLAP database both contain information about your business: Relational databases are generally optimized so that you can quickly insert and update records. OLAP databases are generally used to analyze data, and are therefore optimized so that you can quickly retrieve that data. Typically, an OLAP database is created from the information you have put in a relational database. WebIntelligence for OLAP data sources provides a single interface and common terminology for accessing your OLAP data from several different types of OLAP servers. This chapter covers: WebIntelligence OLAP server as part of the cluster Setting up the dedicated OLAP node The caching service The Universal Drill-through Service (UDS) Installing the OLAP caching and UDS services on cluster nodes Configuring the OLAP caching and UDS services on cluster nodes Defining the OLAP connection in WebIntelligence
NOTE
To find out how to create WebIntelligence documents using OLAP data sources, see the WebIntelligence for OLAP Users Guide.
417
WebIntelligence OLAP server as part of the cluster

With BusinessObjects Enterprise 6.1, the WebIntelligence OLAP server is fully integrated into the Business Objects cluster. WebIntelligence OLAP transactions are handled by a single CORBA service called WIOLAPGenerator. This service behaves in the same manner as the other Business Objects processes in the cluster, with one exception: it does not use the CORBA logging service to trace execution. WIOLAPGenerator works with either ASP or JSP deployments of InfoView. Although you can enable WIOLAPGenerator on as many nodes as you want, for performance reasons Business Objects recommends dedicating a single server in the cluster to WebIntelligence OLAP processing. Through CORBA, this server is available (using the same OLAP database) to all the nodes in the cluster, which can therefore use it to handle transactions for any OLAP connection defined in WebIntelligence.
Primary node Client machines of 3-tier system
Web server
Cluster
Install Java, Application JavaScript, and server image files
Dedicated WebIntelligence OLAP secondary node running WIOLAPGenerator Enable all other OLAP components
Figure 14-1 Recommended cluster deployment for OLAP processing
As complements to your WebIntelligence OLAP deployment, you can also install and configure: The OLAP caching service (see page 425) The Universal Drill-through Service, or UDS (see page 426)
WebIntelligence OLAP server as part of the cluster
418
Web server requirements

For BusinessObjects Enterprise 6.1, WebIntelligence OLAP can use either an IIS or an Apache web server. The web server can be located on either a UNIX or Windows platform. WebIntelligence OLAP Java, JavaScript, and image files must be installed on the machine where the web server is housed.
Dedicated WebIntelligence OLAP node

In this release, the dedicated WebIntelligence OLAP server must be running on Windows. A web server on this machine is not recommended. WIOLAPGenerator is the only module enabled on the WebIntelligence OLAP server. All other modules must be disabled (they run on other nodes).
Security
With this release, you no longer need to set specific security restrictions for the folder used by WebIntelligence for OLAP data sources. When administrators change the security for the 3-tier deployments wiasp directory, the WebIntelligence OLAP folder automatically inherits those changes.
Constraints
You cannot restrict connection lists for users or groups with WebIntelligence for OLAP data sources. All connections are visible to all users, even if a user does not have permission to use a certain connection.
419
Setting up the dedicated OLAP node

This section provides just an overview of this procedure. For more detailed installation and configuration information, see the Installation and Configuration Guide for Windows.
Installing the dedicated WebIntelligence OLAP node

Install the middleware for the OLAP server you will be accessing before you begin the Business Objects installation. The date format for the OLAP connection is defined by regional setting of the computer. So before you install WebIntelligence OLAP on a cluster node, make sure that the regional settings are identical on all the nodes in the cluster, and that they remain synchronized. To install WebIntelligence OLAP and the additional components it requires on the machine that will become the dedicated OLAP node: 1. Run the Business Objects setup on the server machine. 2. Under Access Packs > OLAP Access Packs, check at least one option:
420
3. Under Server Products, check the Business Objects server option (required for all cluster nodes), as well as the Explorer option under WebIntelligence:
The Explorer option automatically installs WebIntelligence OLAP, as well as the OLAP caching and UDS services. 4. Run the install process.
421
Configuring the dedicated WebIntelligence OLAP node

You configure the server on which you have just installed the required OLAP and Business Objects server components as a WebIntelligence OLAP node using the Configuration Tool: 1. Define the node as a secondary node:
Make sure that IIS is disabled on the node and that no other web server is installed on it.
422
2. Go to the Configuration Tools Cluster management screen:
3. Click the Service Parameters option beneath ORB, select Update service parameters from the list at the bottom of the screen, then click Next.
423
The Service screen appears:
4. Unless you have some reason to do otherwise, Business Objects recommends that you check the Define node as a service option. If you are planning to use the OLAP cache and/or Universal drill-through (UDS) services, you must check this option. If you do not check this option, however, see If you do not define the node as a service below. 5. If you want the node to be started automatically whenever the server is booted or re-booted, check the Start automatically option. 6. If you are planning to use the OLAP cache and/or UDS services, you will need to set the port used for each of these services. For more detailed information, see Configuring the OLAP caching and UDS services on cluster nodes on page 429.
424
7. In the screens bottom pane, specify the account that will be used to start the server. The user you specify must have the following rights: - Act as part of the operating system - Log on as a service 8. Restart the server when prompted. 9. Make sure that both the clusters primary node and the dedicated secondary node are started and functioning normally. If you do not define the node as a service If you choose not to define the WebIntelligence OLAP node as a Windows service, and you are using MSOLAP (SSAS), the user that starts the Business Objects server must have permission to Act as part of the operating system.
Disabling/enabling the modules for OLAP use

After installing WebIntelligence OLAP, run the Administration Console for the cluster: Disable WIOLAPGenerator on all nodes but the dedicated WebIntelligence OLAP node. On the WebIntelligence OLAP node, disable all modules except WIOLAPGenerator:
Figure 14-2 Module enablement for the clusters OLAP node
425
The caching service

As some levels in OLAP databases may have large numbers of members, retrieving the members for every OLAP transaction can be time-consuming. This optional service speeds up OLAP metadata retrieval from OLAP databases by retrieving the metadata the first time it is accessed, then storing it. For subsequent transactions, the metadata will be retrieved directly from the cache instead of having to return to the OLAP database. The caching service can also automatically organize the members of a level into groups and subgroups to minimize the number of items through which users have to navigate, and to provide a familiar hierarchical tree navigation metaphor for finding and selecting members.
The caching service
426
The Universal Drill-through Service (UDS)

The UDS service is used to perform the drill-through from an OLAP document (source document) to another OLAP document or to a WebIntelligence 6.x document (target documents). This service ensures the translation of the selected context in the source document into the context of the target document. UDS is an optional, independent service with which WebIntelligence OLAP is compatible, and which is automatically installed along with WebIntelligence OLAP. For detailed information about this service, see the WebIntelligence OLAP UDS Guide. A translation map is an XML file (with the extension UDM) that tells the Drill Through Service how to translate the context from the source cube to the target WebIntelligence document when the user drills on a cell. It describes how the values in the cube relate to the values in the report. Administrators build translation maps using UDS Designer. Once maps are created, they are loaded by the UDS.
Multiple or single instances?

Although you can configure single or multiple instances of the UDS service in a cluster, Business Objects recommends the single-instance configuration. In this case, all the nodes in the cluster reference this instance. See Configuring the OLAP caching and UDS services on cluster nodes on page 429 for configuring the nodes to do this. Multiple instances With multiple instances, an instance of UDS is installed and runs on each Windows node; all of them reference the same shared network location to access the map (UDM) files. The UDS service must use an account that has access to the network, so that it can access the shared location of the map files. If the drill-through maps are updated, you must first either update all running instances using UDS Designer, or manually restart in order to incorporate the modified maps.
427
Installing the OLAP caching and UDS services on cluster nodes

Both of these services and any necessary administration tools are automatically installed on any machines on which you have installed WebIntelligence OLAP. You can run these optional OLAP services on the dedicated WebIntelligence OLAP node if you want:
Dedicated WebIntelligence OLAP node WIOLAPGenerator is activated. The OLAP caching and UDS services also run on this node. Primary node WIOLAPGenerator is disactivated. Business Objects cluster Web server Secondary node WIOLAPGenerator is disactivated.
Application server
Figure 14-3 OLAP services running on the WebIntelligence OLAP node
You can also, however, run these services on other cluster nodes, then configuring the services on their host nodes and the dedicated OLAP processing node to work together. Therefore, although you do not need to run these services on dedicated WebIntelligence OLAP processing nodes, you must follow the same installation procedures for any node on which you plan to run them (see Installing the dedicated WebIntelligence OLAP node on page 419).
Installing the OLAP caching and UDS services on cluster nodes
428
When these services are run on non-dedicated OLAP nodes, they act as servers for WebIntelligence OLAP clients on the dedicated nodes:
Dedicated WebIntelligence OLAP node WIOLAPGenerator is activated and is a client of the caching and UDS services on Node2 Primary node WIOLAPGenerator is disactivated. Business Objects cluster Web server Node2 hosting the OLAP caching and UDS services WIOLAPGenerator is disactivated. These services act as servers for the dedicated WebIntelligence OLAP processing node
Application server
Figure 14-4 OLAP services on a different node from WebIntelligence OLAP
429
Configuring the OLAP caching and UDS services on cluster nodes

All the configuration information for both optional OLAP services is contained in a file on each cluster node called olapreg.ini, located in the $INSTALLDIR\bin directory. The values you set using the Configuration Tool, for example, are written to this file. You can also modify this file manually using a standard text editor. You need to configure these services both on any nodes hosting these services, and on any dedicated WebIntelligence OLAP node (although the services may also run on the dedicated OLAP node). This involves specifying the port number used for each service, and if the services are running on another node, specifying the name or IP address of the remote node. Business Objects recommends that you configure each service first on the node hosting it, then on any other node using it. For complete instructions, see below.
430
EXAMPLE Configuring nodes to locate the OLAP caching/UDS services
In the diagram below, WebIntelligence OLAP is running on a dedicated node called OLAPNode; the OLAP caching and UDS services are running on a different cluster node called OLAPServiceNode.
Dedicated WebIntelligence OLAP node called OLAPNode Application server Business Objects cluster Web server Node called OLAPServiceNode Primary node
In order for the WebIntelligence OLAP processing components on OLAPNode and the additional OLAP services on OLAPServiceNode to work together, you must define the following settings:
431
For the OLAP caching service:

For the OLAP caching service olapreg.ini file: Cache_Port_ID=1202 Cache_HostName=OLAPServiceNode Dedicated WebIntelligence OLAP node called OLAPNode Application server Business Objects cluster Web server Node called OLAPServiceNode olapreg.ini file: Cache_Port_ID=1202 Primary node
- The Cache_Port_ID value in the olapreg.ini file on OLAPNode and on OLAPServiceNode is the same. - The Cache_HostName parameter in the olapreg.ini file on OLAPNode is set to OLAPServiceNode.
432
For the UDS service:

For the UDS service olapreg.ini file: DTS_HOSTNAME=OLAPServiceNode DTS_PORT_ID=25347 Dedicated WebIntelligence OLAP node called OLAPNode Application server Business Objects cluster Web server Node called OLAPServiceNode olapreg.ini file: DTS_PORT_ID=25347
Primary node
- The DTS_PORT_ID value in the olapreg.ini file on OLAPNode and OLAPServiceNode is the same. - The DTS_HOSTNAME parameter in the olapreg.ini file on OLAPNode is set to OLAPServiceNode. Note that you need not configure anything for the primary node, which hosts neither the WebIntelligence OLAP processing components, nor the caching service.
433
Configuring an OLAP service on the node hosting it

Whenever you change any type of setting for the OLAP caching or UDS service, you must manually stop then restart the service in order for the changes to be applied. You do this in the Windows Services dialog box (Start > Settings > Control Panel > Administrative Tools > Services). To set the port used by the caching/UDS service: 1. Go to the Services screen in the Configuration Tool (by clicking Service Parameters in the Cluster management screen):
2. With the Define node as a service option checked, set the port number(s) to be used for the OLAP caching and/or UDS service. 3. Click the Test port button. If the port is free, a message appears telling you so. 4. Close the message by clicking OK. 5. Click Next. After a brief delay, you return to the Cluster management screen.
434
Modifying the folders used by the OLAP caching and UDS services When WebIntelligence OLAP is installed on a machine, Business Objects creates default folders for the OLAP cache and the storage of maps used by the UDS service, respectively: $INSTALLDIR\nodes\<machine_name>\<cluster_name>\OLAPData \OLAPCache $INSTALLDIR\nodes\<machine_name>\<cluster_name>\OLAPData \UDSMaps To change these default folders: 1. In the Configuration Tools Cluster management screen, click the Cluster Preferences option under ORB:
2. Select Update cluster preferences from the drop-down list, then click Next.
435
The Cluster Preferences screen opens:
3. Do one or both of the following: - To modify the clusters OLAP caching directory, enter the new directory path in the OLAP cache directory field. - To modify the clusters UDS directory, enter the new directory path in the UDS map directory field. 4. When youre done, click Next.
Configuring an OLAP service on external nodes

If you have installed the optional OLAP services on nodes which do not host WebIntelligence OLAP, you must configure the dedicated WebIntelligence OLAP node with: the name or IP address of the server hosting the service the services port number on that machine the path to the folders used for each service on the remote server
436
NOTE
WebIntelligence OLAP and UDS Designer must have been granted the appropriate permissions to access and write to the specified paths. UDS Designer is run using the context of the interactive user, while WebIntelligence OLAP is run using the signon credentials for the OLAP session. Although you can use the Configuration Tool to set the second of these parameters, as in the section above, it is probably easier enter all the settings manually in the nodes olapreg.ini file. Whenever you change any type of setting for the OLAP caching or UDS service, you must manually stop then restart the service in order for the changes to be applied. You do this in the Windows Services dialog box (Start > Settings > Control Panel > Administrative Tools > Services). To set the OLAP service parameters: 1. Open the nodes $INSTALLDIR\bin\olapreg.ini file in a standard text editor. 2. For the caching service: - Scroll to the [CACHE] section. - For Cache_HostName, enter the name or IP address of the node hosting the caching service. - For Cache_Path, enter the path to the folder to be used for hte OLAP cache. For example, Cache_HostName=\\OLAPService\OLAPData\Cache - For Cache_Port_ID, enter the same port number you entered for the port on the node hosting the caching service. 3. For the UDS service: - Scroll to the [OM] section: For DTS_HOSTNAME, enter the name or IP address of the node hosting the UDS service. For example, DTS_HOSTNAME=\\OLAPServiceNode For DTS_PORT_ID, enter the same port number you entered for the port on the node hosting the UDS service. - Scroll down to the [UDS] section: For the data parameter, enter the path to the folder containing the UDS maps. For example, data=\\OLAPServiceNode\OLAPData\UDSMaps For the port parameter, enter the same port number as that defined for DTS_PORT_ID in the [OM] section of this file. If the number is not the same, the drill-through service will not work correctly. 4. Save your changes and close the editor.
437
Making sure the node can access the remote caching and UDS services When you enter an external host for the OLAP caching or UDS service, your Windows username and password are only good for accessing local services. To access these services on another server, you must therefore change the username and password for these services on your own machine. To do this: 1. Click Start > Settings > Control Panel > Administrative Tools > Services. The Services dialog box opens:
- The caching service is displayed as OLAP Cache Manager. - The UDS service is displayed as WebIntelligence UTS Manager.
438
2. For each service, do the following: - Right-click service, then choose Properties. - Click the Logon tab. Note that the Local System account option is selected. - Click This account, then enter the credentials for an account meeting the following requirements: If the data provider is MSOLAP and security restrictions are set on the cube, the account must have the appropriate permissions for the cube. Business Objects recommends setting Administrator rights for the cube. The account must have access to everything in the OLAP cube that any WebIntelligence user will need to access. Users will still be able build queries using members corresponding to data for which they dont have access rights; when the query is run, however, WebIntelligence will the restrictions into account and will not display unauthorized data in the generated report. 3. Click OK.
439
Defining the OLAP connection in WebIntelligence

Once the server side of WebIntelligence for OLAP data sources and the OLAP middleware are installed and configured, you must create a connection to each OLAP data source within WebIntelligence. To do this: 1. Click the OLAP link under New document on the InfoView home page:
The WebIntelligence OLAP Report Panel page opens (displayed below with four existing OLAP connections):
2. Click the New button.
Defining the OLAP connection in WebIntelligence
440
The following page appears:
3. Enter the name of the OLAP data source as you will want it displayed in the WebIntelligence data source list. 4. Enter the name of the OLAP server data provider:
5. Enter the name of the server, then in the description field below it, enter a description if you want. 6. When youre done, click Save.
How Products Compare Functionally
appendix
442
Deploying the Business Objects Solution
Overview
This appendix contains a comparison of the basic features and uses of the core products used by Business Objects end users for reporting, sharing and analyzing information: InfoView WebIntelligence BusinessObjects (in 2- and 3-tier deployments) This appendix includes: InfoView vs. WebIntelligence BusinessObjects: 2-tier vs. 3-tier mode BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence Processing different types of documents in InfoView Version 2.x/5.x vs. 6.x
443
InfoView vs. WebIntelligence

This section is designed to dispel any confusion about where InfoView stops and WebIntelligence begins. The two products cannot be dissociated: you access WebIntelligence through InfoView only. Furthermore, the two products use the same graphical framework and customization options, meaning that you pass transparently from one product to the other. As long as you use certain functions, you remain within the domain of the InfoView product. As soon as you use a specific set of other functions, however, you are using the WebIntelligence product. Here are their differences in a nutshell: InfoView is the 3-tier mechanism for accessing and sharing Business Objects documents (created using BusinessObjects and WebIntelligence) and third-party files from a web browser without having to install any product or middleware on the client machine. WebIntelligence is a report engine used to create and modify documents from a web browser without having to install any product or middleware on the client machine. The following table lists the specific functions pertaining to each of these products: Feature View Business Objects documents (.rep, .wqy and .wid) and third-party files Refresh Business Objects documents (.rep, .wqy and .wid) Save Business Objects documents (.rep, .wqy and .wid) to the repository Save Business Objects documents (.rep, .wqy and .wid) for personal use Send Business Objects documents (.rep, .wqy and .wid) to other Business Objects users Schedule Business Objects documents (.rep, .wqy and .wid) for automatic refresh and distribution through Broadcast Agent Create WebIntelligence documents InfoView WebIntelligence
InfoView vs. WebIntelligence
444
Feature Edit WebIntelligence documents Drilling
InfoView WebIntelligence
(users drill into WebIntelligence documents in InfoView) Interactive reporting: sort and filter report values
NOTE
You can also launch BusinessObjects in 3-tier mode from an InfoView session. This transition, however, is graphically explicit: you are clearly in another application. See the following sections in this chapter for detailed information about BusinessObjects functions.
445
BusinessObjects: 2-tier vs. 3-tier mode

The following table compares what you can do with BusinessObjects in a 2-tier and what you can do with BusinessObjects in a 3-tier deployment.
Feature Access data from personal data files (such as Microsoft Excel) Access data from queries built on universes Link data from different data sources in one document Display multiple blocks on a document page (for example, a mixture of tables, crosstabs, and charts) Use VBA macros and add-ins contained in BusinessObjects documents Send documents to Broadcast Agent for automatic scheduling and processing Automatically detect and install a new version of the software over the web Access data using free-hand SQL Access data using OLAP multidimensional servers Access data using Visual Basic for Applications (VBA) procedures Use data from SAP BAPI applications Installation from a CD
BusinessObjects BusinessObjects in 2-tier mode in 3-tier mode
BusinessObjects: 2-tier vs. 3-tier mode
446
BusinessObjects in 3-tier mode vs. InfoView/ WebIntelligence

The table below compares what you can do with the thin-client appications InfoView/WebIntelligence versus BusinessObjects in 3-tier mode.
Feature Automatically detect and install a new version of the software over the web Access data using free-hand SQL Access data using OLAP multidimensional servers Access data using Visual Basic for Applications (VBA) procedures Access data from personal data files (such as Microsoft Excel) Access data from queries built on universes Link data from different data sources in one document Create reports from data stored as XML Use VBA macros and add-ins Dynamically switch languages Send documents to Broadcast Agent for automatic scheduling and processing Save as PDF Save as Excel Documents with multiple reports
InfoView/ BusinessObjects WebIntelligence in 3-tier mode
447
Feature Choice of two client report editors: Java Report Panel: intuitive interface, including drag-and-drop editing and right-click menus HTML Report Panel Find in Report search tool Find in Query Panel tool Adjust the look and feel of the interface (skins) Display multiple blocks on a document page (for example, a mixture of tables, crosstabs, and charts) Scope of analysis Enhanced category management; subcategories; expandable hierarchical tree Advanced query filters: define subqueries and complex conditions Reports with multiple blocks: tables and charts in the same report Custom calculations: reuse formulas as variables in different reports within the same document
InfoView/ BusinessObjects WebIntelligence in 3-tier mode
HTML interactive report viewing: filter and sort report values without launching with .wid a document editor documents only Advanced drilling: for example, drill on duplicate report without modifying original, and option to synchronize drilling across all blocks in a document
BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence
448
Processing different types of documents in InfoView

The following table compares what InfoView users can do with WebIntelligence (thin-client) documents, BusinessObjects (full-client) documents, and other types of files. Users must have the necessary access rights assigned to them in Supervisor.
NOTE
In the following table, N/A means Not Applicable.
BusinessObjects documents
Webintelligence documents
InfoView users can do this with... View documents/files
Download third-party files
N/A
N/A (even if associated application is not installed on the client machine)
Create documents Upload third-party files Refresh documents/files N/A N/A
other types of files
(if associated application is installed on the client machine)
449
BusinessObjects documents
Webintelligence documents
InfoView users can do this with... Modify documents/files Publish documents to the repository Send documents/files to other users Save personal copies of documents/ files Print documents/files Schedule documents for automated distribution with Broadcast Agent Drill in documents
Processing different types of documents in InfoView
other types of files
450
Version 2.x/5.x vs. 6.x

The following sections compare what you can do with the previous and current versions of: InfoView/WebIntelligence BusinessObjects in 2-tier mode BusinessObjects in 3-tier mode
InfoView/WebIntelligence
Feature
InfoView/ InfoView/ WebIntelligence WebIntelligence 5.x 6.x
Two client document editors: Java Report Panel: advanced query and reporting features an intuitive interface for drag-anddrop editing HTML Report Panel: simplified interface for building basic reports step-by-step Three client document editors: light Java Web Panel applet full Java Web Panel applet Activex Web Panel DHTML technology for total ease of deployment (HTML Report Panel) Drag-and-drop report editing (Java Report Panel) View reports in page layout view or draft view Make edits to documents in structure view without sending each incremental change to the server (Java Report Panel)
451
Feature
Enhanced custom formatting options, including alternative table row colors, displaying object names on crosstabs, and chart and page layout options Use objects tagged as HTML to link documents. Skins for adjusting the look and feel of the interface Create and distribute OLAP documents Integration of OLAP viewer Save as PDF Save as Excel and retain orginal data definition and formatting (including charts) Interactive report viewing: filter and sort report data without launching a document editor (Report Panel) Hierarchical categories Documents with multiple reports Basic query filters Advanced query filters: define subqueries and complex conditions Advanced options for prompts, including the option to re-use the value(s) last selected Reports with multiple blocks (tables, forms, charts, and freestanding cells) in the same report
452
Feature
Report filters on specific sections or blocks, as well as on entire reports (Java Report Panel) Predefined business calculations Formula language to build custom calculations: reuse formulas as variables in different reports within the same document HTML drilling Advanced drilling: for example, drill on duplicate report without modifying original; multi-block drilling, hide/show the drill toolbar Predefined special cells to display document information, including page numbering, refresh date, and drill filters. Scope of analysis Apply filters to dimensions selected to extend the scope of analysis during drill Custom RGB value for color (Java Report Panel only)
453
BusinessObjects in 2-tier mode
Feature Access data using stored procedures Access data using FreeHand SQL Access data using OLAP multidimensional servers Access data using Visual Basic for Applications (VBA) procedures Use data from SAP BAPI applications Access data from personal data files (such as Excel) Access data from queries built on universes Link data from different data sources in one document Create reports from data stored as XML Use VBA macros and add-ins contained in BusinessObjects documents Dynamically switch languages Send documents to Broadcast Agent for automatic scheduling and processing Display multiple blocks on a document page (such as a mixture of tables, crosstabs, and charts)
BusinessObjects BusinessObjects in in 2-tier mode (5.x) 2-tier mode (6.x)
454
Feature Find in Report search tool Find in Query Panel tool Installation from a CD
BusinessObjects in 3-tier mode
Feature Automatically detect and install a new version of the software over the web Access data using Visual Basic for Applications (VBA) procedures Access data from personal data files (such as Excel) Access data from queries built on universes Link data from different data sources in one document Display multiple blocks on a document page (such as a mixture of tables, crosstabs, and charts) Use VBA macros and add-ins contained in BusinessObjects documents Send documents to Broadcast Agent for automatic scheduling and processing Access data using stored procedures
455
456
457
Index
$BO_FILE_PATH environment variable 402 setting 403 . 260 .key files creating 281 defined 367 location 126 where they must be copied during deployment 123 .lsi file 125, 373 location 126 .rep files migrating between lifecycle environments 331 purging data providers 332 viewing with web server in CGI mode 172 .rkey file 395 copying an existing 394 location of 126 obtaining 394 .wid files automatically overwriting 331 creating 300 JSP for interactive viewing 378 .wqy files automatically overwriting 331 .xml files license information 263 2-tier deployments associated platforms 81 associated products 78 pros and cons 205 what to install where 249 3-tier architecture 68-77 administration on Windows machines 172 client tier 70 middle tier 71 overview 66 see also 3-tier deployments 3-tier client machines what is installed on 340 3-tier deployments alternative extranet configurations 231 and BusinessObjects in 2-tier mode 79 associated platforms 81 associated products 79 basic extranet configurations 212 basic intranet configurations 210 Business Objects processing layer 73 clusters 82 DMZ configurations 215-219 extranets 212 implementing basic extranets 345 implementing basic intranets 344 list of scenarios 207 multiple clusters in intranet 227 single-cluster intranet/extranet 235 using IP redirectors 223 using reverse proxies 220 what to install where 249 when do you need a Windows node in your cluster? 171
Symbols
2-/3-tier deployments 208 2-tier architecture and BusinessObjects 70 overview 65, 149 see also 2-tier deployments
Index
458
A
access rights defining with Supervisor 282 see also authorization active users 154 ActiveX version compatibility with BusinessObjects 6.x 390 Admin Tool see Administration Console administration Administration Console 101-104 administrative components 99 and Windows machines 172 how it has changed 110 of Audit facility 108 of Auditor 109 of Broadcast Agent 105 of the Business Objects system 97-116 when you need a Windows machine 172 administration client machine what is installed on 340 Administration Console 101-104 activating the Audit facility 108 administering Broadcast Agent 105 and UNIX 172 and WIProcessManager 89 configuring access to 276 enabling modules 291 interface 103 setting size of process pools 292 size 399 tuning the system 290-295 types 104 what you can do with it 104 who can use it? 104 administration products Administration Console 53 Auditor 49 Configuration Tool 52 Designer 48 diagnostics tools 54 Supervisor 47 Administration Server role in administration layer 74 Administration Setup wizard 280
administrative installation 254 administrator.exe 104 Advanced user type 153 air gap 307 Analyst user type and deployment type 387 defined 153 Application Foundation 102 application server connector 250 Application Server Framework see ASF Application Server pages option (installer) 341, 343 application servers associating with cluster nodes 275 configuring 276 deployment rules 339-343 how their role in the system has changed 96 IIS or J2EE? 72 in DMZ configurations 218 installing 245 linking to clusters web server(s) 276 role in systems web layer 71 selecting software 169 what is installed/configured on them 341 what you install on 250 where you install 250 architecture associated platforms 81 centralized or decentralized? 187 designing 165 of clusters 177 of repository 183
Index
459
ASF 87-93 and failover 90 and fault tolerance 90 and load balancing 91 as new element in BusinessObjects Enterprise 6 95 callback interface 88 client interface 88 configuration 92 configuration file 92 configuration using Configuration Tool 92 daemons 89 external interface 88 how it works 88 internal interface 88 ASF client installing 341 ASF Guard defined 89 how it ensures failover 90 ASP (Active Server Pages) see ASP configurations ASP configurations overview 72 splitting web and application servers 177 supported Business Objects features 377 ASP pages advantage of Developer Suite 46 Audit facility 108 and Auditor 109 in development lifecycle 312 Auditor administering 109 and Java SDK 409 and the Auditor facility 109 deploying 409 in development environments 313 in development lifecycle 313 monitoring multiple clusters 410 overview 49
authentication and BusinessObjects in 3-tier mode 394 and LDAP 55 Business Objects standard 136 defined 135, 151 external 136 via the .key file 281 authentication mode setting 135 authorization and LDAP 55 defined 135, 151
B
B2B 212 bandwidth dealing with limited 193 Basic authentication and web servers in CGI mode 388 binary data type support 360 BLOBs 360 BOL_batch role in processing layer 76 bomain.key file 281 BOManager Enable batch processing parameter 398 required permissions for Broadcast Agent jobs 401 role in processing layer 75 Scheduler login cache duration parameter 400 server sizing 398 BreakOnVBAError 408
Index
460
Broadcast Agent administering 105 administering using Administration Console 105 administering using Broadcast Agent Console 106 and offline mode 132 and the LocData directory 406 and UNC paths 404 and VBA 43 custom macros and UNIX 171 failure recovery 180 File Watcher option 401 how many Schedulers 397 login cache 399 minimum required configuration 291 path and filenames 401 report bursting 397 required permissions for BOManager 401 Scanning Repository Delay parameter 106 sizing guidelines 397 swapping space 398 tasks 105 time and dates 182 using shared and personal connections 406 using the cache 401 Windows or UNIX 399 Broadcast Agent Console 106 and the repository 128 and UNIX 173 size 399 what you can do with 107 Broadcast Agent Manager Max. no. WebIntelligence 2.x jobs running parameter 399 Max. no. WebIntelligence 6.x jobs running parameter 399 Schedulers 76 Broadcast Agent option (installer) 343 Broadcast Agent Publisher description 43 Broadcast Agent Scheduler overview 42 vs. the Scheduler 396
Business Intelligence defined 28 Business Objects consulting services 17, 19, 161 customer support 161 desktop products 31-34 documentation 16 Documentation Supply Store 15 secure configuration 27 support services 17 training services 17, 19 Business Objects processes defined 75-76 see also modules Business Objects processing layer 73 Business Objects products 30-57 Auditor 49 BusinessObjects 31 BusinessObjects in 3-tier mode 33 BusinessQuery 34, 48 choosing which products and how they are deployed 379 Data Access Packs 55 demonstrations 56 deploying 376-413 deploying Auditor 409 deploying Broadcast Agent 396-408 deploying BusinessObjects 390-395 deploying InfoView 388 deploying WebIntelligence 388 deployment rules 339-343 Developer Suite 45 InfoView 35 installing 243-265 pre-install checklist 245 Supervisor 47 UNIX support 171 v5/v6 comparison 442 WebIntelligence 37 what you can install under UNIX 256 what you can install under Windows 251 what you install where 249 which can benefit from IP redirectors 223 which connect to the repository 128 which products with which architectures? 78
Index
461
Business Objects server and installation of BusinessObjects in 2-tier mode 390 and reverse proxies 220 defined 203 in extranet configurations 213 in multiple-cluster intranet configurations 227 Business Objects server option (installer) 342 Business Objects system administration 97-116 administrative layer components 99 analyzing activity 51 before starting (checklist) 288 clusters 82 configuring 269-277 defining access rights for 282 development lifecycle 305 hierarchy 284 how administration has changed 110 how it communicates 85 monitoring and analyzing activity 108 portals in 70 setting up storage 277 starting 289 system requirements 248 tuning using the Administration Console 290-295 typical user types in 152 BusinessObjects and offline mode 133 automatic binary slice management 360 choosing a repository 367 creating documents with 299 customizing 45 deploying 390-395 in 3-tier deployments 79 overview 31 Save for all users option 372 scheduling documents 105 see also BusinessObjects in 2-tier mode and BusinessObjects in 3-tier mode BusinessObjects Auditor see Auditor
BusinessObjects in 2-tier mode as client 70 compared with 3-tier mode 384 exclusive functionality 384 overview 31 see also BusinessObjects segregating from server products 255 setting locale 298 BusinessObjects in 3-tier mode and content caching 395 and firewalls 395 and security domain selection 395 and SSL 394 and system resources 384 and WIADEServer 392 authentication modes 394 automatic updating 390 compared with 2-tier mode and InfoView 384 creating documents with 299 deploying 390 firewalls and proxies 387 installing 390 installing from InfoView 260 language selection 298 obtaining the .rkey file 394 overview 33 required user rights 392 see also BusinessObjects version compatibility check with InfoView 392 BusinessObjects OLAP Connect 55 BusinessObjects processes defined 75, 76 BusinessObjects Web Installer option (installer) 343, 392 BusinessQuery overview 34
C
CAB files for BusinessObjects in 3-tier mode 391 for WebIntelligence Java Report Panel 388 caches and Broadcast Agent 401 pre-loading 400
Index
462
caching Broadcast Agent login information 399 scheduled documents 400 capacity planning 148 CGI mode and Basic authentication 388 Check License button (installer) 263 Cisco LocalDirector see IP redirectors client machines in basic extranet configurations 345 what is installed/configured on 340 what you install on 250 client nodes defined 275 reason for adding to a cluster 177 client tier 70 client-server see 2-tier architecture cluster setting locale 296 cluster architecture 177 Cluster Configuration tree 274 cluster manager see primary node cluster nodes and networks in extranets 346 creating 274 defined 82 enabling modules on 291 module enablement 343 reasons for adding 177 what is installed/configured on 342 what you install on 250 cluster terminology 61
clusters administration 104 auditing multiple 410 changing repositories 373 configuring 52, 270-276 creating 275 defined 82 deployment rules 339-343 entry points 276 geographically distributed 180 heterogeneous 174 how many servers under Windows 179 linking web and application servers 276 multiple clusters in an intranet 227 processing power vs number of machines 178 reason for adding client node 177 setting node weight 295 starting 289 typical configurations 271 using Cluster Configuration tree 274 using multiple 179 using multiple web servers in a single cluster 233 version 5.1/2.6 171 what is installed/configured in 340 when do you need a Windows node? 171 with multiple web servers 236 concurrent users 154 config.bat command 273 config.sc script 273 configuration of Business Objects system 269-277 of cluster nodes 274 of servers 270-277 of storage 277 options for IP redirectors 224
Index
463
Configuration Tool 52, 270-276 Admin entry point 276 Cluster Configuration tree 274 defining automatic launch of WIOrb 289 formats 272 installing 341 launching 273 naming clusters 410 ORB configuration 92 where do you run it? 271 who can use it 271 configurations see deployment configurations connection defining OLAP connection 439 Connection Server and the repository 127 connections defining secured connections to universes 286 shared and personal 406 connectivities configuration guidelines 406 setting up on UNIX machines 277 Console option (installer) 343 consultants Business Objects 17, 161 content caching and BusinessObjects in 3-tier mode 395 cookies implementing the Sticky command with 350 CORBA container/component model 87 how communication has changed 94 overview 85 persistent objects in 90 Corporate Documents list 36 CPU time required for scheduled documents 397
creating BusinessObjects documents 299 clusters 275 the .key file 281 the repository 278 universes 285 users and groups for development lifecycle 318 users and user groups 282 Custom installation 253 customer support 17, 161 customizing BusinessObjects and Designer 45
D
daemons ASF 89 Dashboard Manager 102 data access drivers 245 data management as a deployment consideration 150 data providers purging 331 Database Access Packs 55 BusinessObjects OLAP Connect 55 databases location 185 Demilitarized Zone see DMZ configurations demo materials 15 demonstrations 56 deploying Auditor 409 Broadcast Agent 396-408 BusinessObjects 390-395 InfoView 388 specific products 376-413 WebIntelligence 388 WIStorageManager 388
Index
464
deployment choosing products and how they are deployed 379 development lifecycle 305 geographically distributed 180 modeling 164-200 rules for all configurations 339-356 supported configurations 201-239 deployment architectures overview 65 which products with which architectures? 78 deployment configurations 3-tier 68 alternative extranet configurations 231 basic extranet scenarios 212 basic intranet 210 centralized 188 decentralized 194 deployment rules for all configurations 339-356 how many portals? 70 implementing supported configurations 337-356 modeling 164-200 multiple-clusters in an intranet 227 single-cluster intranet/extranet 235 supported configurations 201-239 terminology 203 typical configurations 271 using IP redirectors 223 using reverse proxies 220 Deployment Guide how it has changed 58 deployment lifecycle 305 deployment models 175 deployment process and geographical distribution 150 creating a pilot project 160 definition 24 planning for disaster recovery 159 pre-deployment checklist 145 deployments geographically dispersed 365 typical configurations 271
Designer and UNIX 172 configuring universes 325 creating universes 285 creating universes manually 286 customizing 45 exporting universes 324, 329 importing universes 328 importing/exporting universes 287 overview 48 Quick Design wizard 285 Save for all users option 370 setting language 298 the security it provides 120 designers defined 284 Desktop installation 253 desktop products 31 and the repository 128 BusinessObjects 31 BusinessQuery 34 deployment guidelines 377 Developer Suite 16, 18 and VBA 46 overview 45 programming languages 57 development environment defined 306 planning 310 development lifecycle 305 and Auditor 313 and the Audit facility 312 creating environments 316 creating the repository 316 how many deployments? 308, 309 migrating between environments 327 naming universes 322 role of development users 324 types of users 314 using single repository 308 what types of documents? 315 what types of users? 314 development users their role 324 diagnostic tools 54
Index
465
digital certificates 139 disaster recovery 159 Disconnect after each transaction parameter 406 disk mirroring and shared storage 355 Distribute via Web server option 405 distributed configuration defined 203 distributed configurations advantages 84 DMZ defined 203, 216 in typical extranet configurations 213 DMZ configurations 215-219 implementing 347 where to place reverse proxy 221 document domains 278 and development lifecycle 308 assigning 321 creating for development lifecycle 316 defined 122 moving documents from one to another 369 OBJ_X_DOCUMENTS table 360 reducing size of 364 size of 362 using multiple 184 documentation CD 15 feedback on 16 on the web 15 printed, ordering 15 roadmap 15 search 15 Documentation Supply Store 15
documents and development lifecycle 315 and the document domain 122 creating 299 deleting 332 distributing 37 exporting to repository 330 importing from repository 330 making available to users of other repositories 372 migrating between lifecycle environments 330 moving between repositories 370 moving from one domain to another 369 organizing in different domains 317 scheduling 300 WebIntelligence OLAP 42 domains see repository domains dynamic server pages processing by web layer 71
E
education see training Electronic Data Interchange 212 enterprise mode defined 132 Explorer option (installer) 343 exporting documents to the repository 330 universes to the repository 287, 324 user and group lists 284 external authentication 136 extranets 28 advanced deployment configurations 231 and routers 345 basic deployment configurations 212 defined 203, 212 implementing basic configurations 345 sharing information over 37 single web server for intranet and extranet users 235 single-cluster configurations 235
Index
466
F
failover and the ASF 90 ensuring 179 for primary node 180 in production environment 335 using IP redirectors 223 failure recovery for Broadcast Agent 180 fault tolerance and the ASF 90 feedback on documentation 16 File Watcher and pathnames 405 File Watcher option (InfoView) 401 filter objects 314 filtering 218 firewall rule defined 215 firewalls 215-218 and BusinessObjects (3-tier) 387 and BusinessObjects in 3-tier mode 395 and SQL 379 communication between double firewalls 217 defined 203 in DMZ configurations 215-219 inner and outer 217 location in basic extranets 346 see also DMZ configurations Free Hand SQL and UNIX 171 full client see BusinessObjects full-client documents see .rep files
HTTP client-server communication 382 communication through firewalls 217, 395
I
IIOP protocol 86 and CORBA 216 IIS application server configurations 72 importing documents from the repository 330 universes from the repository 328 user and group lists 284 Inbox Documents list 36 InfoView adding third-party files to the portal 300 and system resources 384 as entry point to the cluster 276 as portal 70 compared with BusinessObjects in 2- and 3tier modes 384 deploying 388 distributing documents with 37 document lists 36 Enhanced Document Viewing option 400 File Watcher option 401 Installation page 260 installing BusinessObjects in 3-tier mode 260 interface 36 overview 35 Overwrite option 331 repository selection 368 Standard HTML option 400 using enhanced document viewers with web servers in CGI mode 172 version compatibility check with BusinessObjects 392 InfoView option (installer) 343 inner firewall 217
G
General Supervisor defined 284 GIOP 86
H
heterogeneous clusters 174 HTML Report Panel 39, 300
Index
467
installation 243-265 and VBA 393 Application Server pages option 341 Business Objects server option 342 BusinessObjects in 3-tier mode 390 Check License button 263 default UNIX installation directory 257 default Windows installation folder 255 fresh installation or update? 247 from a network location 254 how it has changed 262 of BusinessObjects from InfoView 260 of Configuration Tool 341 of service packs 259 on UNIX machines 256-257 on Windows machines 251-255 rights required to install under UNIX 256 rights required to install under Windows 251 silent 261 summary of installer options 343 system requirements 248 types of 252 UNIX interface 256 updating 258 Web Server pages option 341 whats new under UNIX 265 whats new under Windows 264 which products on what machines 249 Windows interface 251 Interactive user type 152 intranets 28 basic intranet deployment configurations 210 defined 203 implementing basic intranet deployments 344 multiple-cluster configurations 227 single web server for intranet and extranet users 235 single-cluster configurations 235 IP address translation 218
IP redirectors and shared storage 355 client-assigned load balancing 224 configuration options 224 configuring for maximum connection configuration 351 configuring for weighted configuration 351 defined 204 description 223 implementing 348-355 in production environment 335 software/tasks that can use them 223 Sticky command 224 weighted configuration 224 when primary node fails 352 when web server fails 352 with a single cluster and multiple web servers 233
J
J2EE application server configurations 72 Java applets Administration Console 104 and 3-tier deployments 67 Java Report Panel 41, 300 Java SDK and Auditor 409 Java Virtual Machine required for Java Report Panel 388 JavaServer Pages see JSP pages or JSP configurations 46 JHSAL see HSAL 64 JSP configurations and UNIX 377 interactive viewing of WebIntelligence documents 378 overview 72 splitting web and application servers 177 supported Business Objects features 377 JSP pages and Developer Suite 46
Index
468
K
Keep the connection active during the whole session parameter 406 Keep the connection active for X minutes parameter 406 Knowledge Base 18
L
LAN 385 language setting 296 LDAP use of corporate directory 55 LDAP authentication 136 license files copying to deployment machines 246 where they are stored 246 licenses adding 263 and migration users 321 live environment 307 load balancing and the ASF 91 in production environment 335 using IP redirectors 223 LocalDirector see IP redirectors locale defined 296 setting 296 LocData directory 406 recommended configuration 407 LOVs in universe 317
M
map files (UDM) 426 maximum connection configuration configuring IP redirector for 351 Microsoft proprietary technologies 399 Microsoft Excel and BusinessQuery 34 middle tier 71
middleware and CORBA communication 85 and universes 48 number of open connections 361 where its installed with 3-tier BusinessObjects 33 migrating between environments 327 BusinessObjects documents between lifecycle environments 331 documents between lifecycle environments 330 WebIntelligence documents between lifecycle environments 330 migration users and licenses 321 defined 320 migrating universes 327 modeling your deployment 164-200 modules administration of 104 defined 73 enabling on cluster nodes 291 see also Business Objects processes which are enabled on what nodes? 343 monitoring system activity 108 MS OLAP Services (Microsoft SQL Server OLAP Services) 55 multimedia quick tours 16 multiple clusters 179 auditing 410 in production environment 335 multiple repositories 183 and multiple clusters 182
N
networks access and firewalls 215 and cluster nodes 346 and performance 387 installing from 254 overhead 384 Node Load Factor 115 see node weight
Index
469
Node Load Factor see node weight node weight and load balancing 91 setting 295
O
oad 111 Object Request Broker see ORB objects defined 85 filter objects 314 persistent 90 objects.lsi file 125 objects.ssi file 125 offline mode and Broadcast Agent 132 and BusinessObjects 133 defined 132 OLAP 384 defined 416 defining connection in WebIntelligence 439 see WebIntelligence for OLAP Data Sources 42 OLAP Cache Manager 437 OLAP data sources and UNIX 171 olapreg.ini file 429 OLE 2 objects 170, 174 OLE Automation under Windows 75 Online Customer Support 17 online mode defined 132 operating system selecting 169 optimizing security domain 371 ORB 111 configuration using Configuration Tool 92 configuring 52, 270-276 defined 85 Orbix 2000 95 Orbix how it is configured and its environment set 92 Orbix 2000 111 osagent 111
OSAgent Port 111 outer firewall 217 overhead network 384 server 384 Overwrite option (InfoView) 331
P
PAR 169 pathnames Windows/UNIX conversion 402 pdac.lsi file defined 407 PDF documents generation time 401 performance and network issues 387 and WANs 387 personal documents storage space for 388 Personal Documents list 36 pilot project 160 platforms and programming languages 57 support 169 supported with deployment architectures 81 portal in a 3-tier deployment 70 see also InfoView portals 70 power users (user profile) and choice of product or deployment 387 proportion of 146 presentation cache 400 presentation layer 71 Prevent from Overwriting Universe security command 322 primary node and WILoginServer 177 defined 82, 275 failover capacities 180 what it does 83 why add another primary node? 177
Index
470
process pools defined 292 setting size of 292 processing layer 73-76 components 75 Product Availability Report see PAR product line see Business Objects products production environment defined 307 planning and building 335 profiles user 152 programming languages used to access Developer Suite 57 proxy servers and BusinessObjects (3-tier) 387 defined 204 Public Key Infrastructure 139 publications 43 purging data providers for BusinessObjects documents 332 data providers for WebIntelligence documents 331 Inbox documents from repository 279
Q
Quick Design wizard 285
R
RAID drives 277 RAM required for scheduled documents 397 Rapid Application Development (RAD) 324 RDBMS location 185 selecting 169 RDBMS security 136 Readers (user profile) 152 and InfoView 387 registered users 154 remote key file see .rkey file report bursting 397 Reporter option (installer) 343
reports see also documents repositories 117-134 adding third-party files to 300 and development lifecycle 308 and your data warehouse 130 Auditor-dedicated 411 changing a clusters repository 373 checking integrity 333 choosing a repository from BusinessObjects 367 compatibility issues 134 creating 278 creating for development lifecycle 316 deleting documents from 332 designing architecture 183 domains 121 exporting documents to 330 how much space? 362 importing documents from 330 importing universes from 328 location 185 moving documents and universes from 370 purging Inbox documents from 279 selecting from InfoView 368 setting up multiple repositories 367 synchronizing between multiple repositories 369 using multiple 129, 182, 183 using separate for development and production 307 which components access them 127 working with or without 132 repository domains exporting universe to 287, 324 setting up multiple repositories 367 working with or without 132 repository database binary data type support 360 binary slice 360 choosing 359 maximum number of open connections 360 row-level locking 359
Index
471
repository domains 278 distribution over multiple servers 365 moving universes among 370 multiple 122 overview 121 reverse proxies 220 defined 204, 220 overview 220 where to place them in DMZ configurations 221 routers in basic extranet configurations 345 row-level security 359
S
SAP BW (SAP Business Information Warehouse) 55 scalability 148 Scan and Repair utility 334, 364 Scheduler defined 396 Scheduler option (installer) 343 Schedulers and login cache 400 and the repository 128 Delay between retry parameter 106 deploying 398 how many 397 minimum requirements 291 overview 76 server sizing 398 tuning 106 what jobs they can process 398 scheduling documents 300 using shared and personal connections 406 using UNC paths 404 sdac.lsi files defined 407 synchronizing 407 search documentation 15 secondary nodes defined 82, 275 what they do 83 why add another? 177
security API for managing Business Objects web security 74 defining access rights 282 digital certificates 139 DMZ configurations 215-219 firewalls 215-218 for WebIntelligence OLAP folder 418 multiple security domains 365 provided by Designer 120 provided by Supervisor 120 Public Key Infrastructure 139 RDBMS 136 web servers as security risks 220 security commands Create Documents (BusinessObjects Documents family) 393 Download 3-Tier BusinessObjects (WebIntelligence Administration family) 392 Read Corporate Documents (InfoView family) 393 Read Inbox Documents (InfoView family) 393 Use WebIntelligence HTML Report Panel 389 Use WebIntelligence Java Report Panel 388 security domain centralized within decentralized architecture 194 defined 121, 278 optimizing 371 selecting from BusinessObjects 367, 395 selecting from InfoView 368 single or multiple? 365 using multiple 129 Server installation 253 server products deployment guidelines 377 InfoView 35 WebIntelligence 37
Index
472
servers Business Objects server 203 configuring 270-277 defining as cluster nodes 274 enabling modules on 291 how many in a Windows cluster 179 overhead 384 processing power under UNIX 179 setting node weight 295 summary of installer options for 343 what is installed/configured on 340 when do you need a Windows node? 171 where do you run Configuration Tool? 271 why use UNIX servers? 170 service packs installing 259 testing 306 session context when it is released 89 session stack enabling/disabling 115 session stacks 101 when they do not have to be enabled 102 sessions administration 104 shared connections enabling VBA macros to access 407 shared storage and IP redirectors 355 in production environment 335 setting up 277 software selecting system software 169 SQL and firewalls 379 query 379 standard reporting configuration 26 SQLBO and connection pools 406 SSL and BusinessObjects in 3-tier mode 394 stacks 169 see also session stacks 101
starting pre-start checklist 288 the system 289 Sticky command constraints 226 defined 224 storage license files 246 setting up 277 shared storage and IP redirectors 355 stored procedures and UNIX 171 Supervisor 318 Administration Setup wizard 280 and UNIX 172 assigning domains 321 checking repository integrity 333 compatibility between versions 134 creating the .key file 281 creating the repository 278 defining access rights 282 defining users and user groups 282 deleting documents from repository 332 exporting universes 370 overriding default universe configuration 325 overview 47 Prevent from Overwriting Universe 322 Refresh according to the profile of each recipient option 279 security measures overview 120 setting language 298 setting up multiple repositories 367 Work with Universe Overrides option 370 supervisors defined 284 support customer 17 synchronizing repositories 369 sdac.lsi files 407 system requirements 248
Index
473
T
TCP balancing TCP traffic with IP redirectors 223 communication through firewalls 217 TCP/IP and intranets 28 terminology cluster 61 concerning deployment configurations 203 how it has changed 61 testing environment defined 306 thin client see WebIntelligence 299 thin-client documents see .wid files and .wqy files tiers middle tier 71 the client 70 time zones and clusters 180 Tips & Tricks 16 Tomcat and Java SDK 409 training on Business Objects products 17 troubleshooting diagnostic tools 54
universes access from BusinessObjects in 3-tier mode 393 configuring 325 creating manually 286 defined 48, 77 defining secured connections 286 enabling the overwriting of 322 exporting to repository 324, 370 exporting to the repository 287 file name 322 filter objects 314 importing from repository 328 in development lifecycle 314 migrating between lifecycle environments 327 moving between repositories 370 moving from one domain to another 370 naming file names 322 overriding default configuration 325 using Quick Design wizard 285
U
UAT environment defined 306 UDS Designer 426 UDS service 426 UNC 401 defined 404 uninstallation 258 universe domains 278 and development lifecycle 308 assigning 321 creating for development lifecycle 316 defined 122 using multiple 184
Index
474
UNIX and Broadcast Agent 399 and Business Objects products 171 and case-sensitivity 402 and custom macros for Broadcast Agent 171 and Free-Hand SQL 171 and OLAP data sources 171 and OLE 2 objects 174 and processing power 179 and stored procedures 171 and Supervisor and Designer 172 and the Administration Console 172 and the Broadcast Agent Console 173 and VBA procedures 171 and XML data providers 171 creating the bomain.key file 281 default installation directory 257 diagnostic tools 54 installer interface 256 installing under 256-257 JSP configurations 377 mounting directories to map to other machines 402 multiple nodes on single servers 82 pathnames in this guide 60 setting $BO_FILE_PATH environment variable 403 setting up connectivities 277 starting system 289 supported software 169 updating, repairing or uninstalling 258 using alongside Windows 174 whats new in installation 265 why use UNIX servers? 170 winstall command 257 updating an installation 258 upgrading from a previous version 247 Use WebIntelligence Java Report Panel security command 388 user acceptance testing 306 user activity peak 148
user groups creating 282 creating for development lifecycle 318 defining 282 importing 284 user hierarchy in development environments 314 user locales setting 298 user profiles 152 as factor in choosing product or deployment 386 user types defined 152 proportions in typical deployment 153 user.log file 108 users concurrent/active users ratio 155 coping with too many 179 creating 282 creating for development lifecycle 318 defined 284 defining 282 importing lists of 284 power 146 registered/active users ratio 154 selecting a language 296
V
VBA 43 and Business Objects installation 393 and Developer Suite 46 enabling macros to access shared connections 407 VBA procedures and UNIX 171 virtual private networks 212 Visibroker 111 see Orbix Visual Basic for Applications see VBA
W
WANs and choice of product deployment 387
Index
475
web customer support 17 getting documentation via 15 useful addresses 18 Web Server pages option (installer) 341, 343 web servers as security risk 220 associating with cluster nodes 275 CGI mode and authentication 388 configuring 276 deployment rules 339-343 implementing a single web server for intranet/ extranet users 356 in DMZ configurations 218 installing 245 linking to clusters application server 276 multiple 233 multiple within one cluster 236 number used with IP redirector configuration 224 pathnames 405 role in systems web layer 71 selecting software 169 single web server for intranet and extranet users 235 what is installed/configured on them 341 what you install on 250 where you install 250 WebIntelligence creating documents 300 customizing ASP pages deploying 388 deploying the Java Report Panel 388 filters 39 HTML Report Panel 39 Java Report Panel 41 overview 37 prompts 39 WebIntelligence documents migrating 330 migrating between lifecycle environments 330 purging data providers 331
WebIntelligence for OLAP data sources 42 and ASP 378 and session stacks 102 defining connection 439 map files (UDM) 426 security settings 418 WebIntelligence HTML Report Panel and JSP configurations 378 deploying 389 WebIntelligence Java Report Panel ASP or JSP? 378 deploying 388 rights required to download 388 size 388 WebIntelligence option (installer) 343 WebIntelligence UTS Manager 437 weighted configuration configuring IP redirector for 351 WIADEServer and installing 3-tier BusinessObjects 392 and Windows 388 role in processing layer 76 WIAdminBOTools defined 99 WIAdmToolStop 113 defined 100 WIAPIBroker role in processing layer 76 WIDispatcher role in processing layer 75 WIGenerator 89, 115 WIHSALManager 115 WIKill 113 WILoginServer and authentication mode 135 and primary node 177 and the repository 127
Index
476
Windows and Broadcast Agent 399 and Business Objects administration tasks 172 and case-sensitivity 402 and WIADEServer 388 default installation folder 255 generating the .key file 281 how many cluster servers 179 installation in command-line mode 264 installer interface 251 installing under 251-255 pathnames 402 pathnames in this guide 60 starting the system 289 supported software 169 updating, repairing or uninstalling 258 using alongside UNIX 174 whats new in installation 264 when do you need a Windows node in your cluster? 171 why choose Windows? 171 Windows 2000 required profile for downloading Java Report Panel 388 Windows 2000/XP 264 WinInet and download of BusinessObjects installer 391 WINotify defined 100 WiNotify using to start the system 289 winstall command 257 WIOLAPGenerator 417 WIOrb 99 defining automatic launch 289 WIProcessManager defined 89
WIQT and BusinessObjects processing 392 and session management 89 and the repository 127 Enable batch processing parameter 398 role in processing layer 75 setting size of process pool 292 WIProcessManager and WIQT process pool 89 WIQT Report Engine 75 WIQT Repository Access 75 WIQT SQLBO 75 WIQT_batch role in processing layer 76 WIReportServer role in processing layer 75 WIReportServer_batch role in processing layer 76 WISessionManager 74 number of instances 101, 112 role in administration layer 74 WISiteLog defined 100 WIStorageManager and primary node 177 deployment advice 388 role in administration layer 74 wizards Administration Setup 280 Quick Design wizard for creating universes 285 Windows installation 252 wmainkey script 123, 281 workgroup mode defined 132 wstart script 289 wupdate script 258
X
XML data providers and UNIX 171
Z
ZABO see BusinessObjects in 3-tier mode ZaboCheckAndRunControlClass file 390
Index
477
ZABOInstallPopup.asp file 393 ZABOInstallPopup.jsp file 393
Index
478
Index

Deployment

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Deployment

Enviado por

Direitos autorais:

Formatos disponíveis

Deploying the Business Objects System

BusinessObjects Enterprise 6 Business Intelligence Windows and UNIX

Deploying the Business Objects System

Patents Part Number

Deploying the Business Objects System

Deploying the Business Objects System

System Architecture and Communication

Deploying the Business Objects System

Part II Planning your Deployment Chapter 5 Deployment Considerations 143

Deploying the Business Objects System

Supported Deployment Configurations

Deploying the Business Objects System

Getting the System Up and Running

Deploying the Business Objects System

Deploying and Managing the Repository

Deploying the Business Objects System

Deploying the Business Objects System

Deploying the Business Objects System

Deploying the Business Objects System

383 411 413 417 424 427 428

Maximizing Your Information Resources

Deploying the Business Objects System

Maximizing Your Information Resources

Deploying the Business Objects System

Deploying the Business Objects System

How can I get the most recent documentation?

Send us your feedback

Maximizing Your Information Resources

Deploying the Business Objects System

How we can support you?

Having an issue with the product?

Looking for the best deployment solution for your company?

Looking for training options?

Deploying the Business Objects System

Useful addresses at a glance

Business Objects Documentation mailbox documentation@businessobjects.com Product documentation www.businessobjects.com/services/ support.htm

Feedback or questions about documentation.

The latest Business Objects product documentation, to download or view online.

Tips & Tricks www.businessobjects.com/forms/ tipsandtricks_login.asp

Maximizing Your Information Resources

Deploying the Business Objects System

Address Online Customer Support www.techsupport.businessobjects.com

www.businessobjects.com/services Business Objects Education Services www.businessobjects.com/services/ education.htm

Useful addresses at a glance

Deploying the Business Objects System

About this guide

Conventions used in this guide

Some code more code

Maximizing Your Information Resources

Deploying the Business Objects System

Figure 1-1 Example of a Business Objects product deployment

Deploying the Business Objects System

Deploying the Business Objects System

Standard SQL reporting configurations

Figure 1-2 A standard SQL reporting configuration

Deploying the Business Objects System

The secure Business Objects configuration

Business Objects servers

Figure 1-3 Secure Business Objects reporting configuration

The secure Business Objects configuration

Deploying the Business Objects System

What can you do with the Business Objects solution?

Intranets and extranets