Professional Documents
Culture Documents
Deployment
Deployment
Deployment
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
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
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
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
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
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
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 . . .
Figures
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.
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.
Services
18
Content
Overview of Business Objects documentation. Links to Online Customer Support, Documentation Supply Store, Documentation Roadmap, Tips & Tricks, Documentation mailbox.
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.
19
Content
Starting point for answering questions, resolving issues. Information about registering with Worldwide Customer Support. The range of Business Objects training options and modules.
Business Objects Consulting Services Information on how Business Objects can help maximize your business intelligence investment. www.businessobjects.com/services/ consulting.htm
20
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.
$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)
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
Client
Introduction
27
Network
Client
Repository
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.
28
Introduction
29
30
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
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.
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.
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.
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
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
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.
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.
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.
Administration products
48
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
objects
database schema
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.
Administration products
50
Auditor clients
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:
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
Administration products
52
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.
Administration products
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
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
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
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
Conceptual
Conceptual
Practical
60
Introduction
61
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
Deployment architectures
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
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.
Deployment architectures
68
69
Client tier
Presentation layer
Middle tier
API proxy
IIOP
Processing layer
Database tier
Data server Repository
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:
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
72
Web server
Static files Static HTML pages and bitmaps
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
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.
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
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
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
79
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.
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
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
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
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 a cluster?
84
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.
2. The ORB locates the object on one of the servers connected to it, and implements the request.
Servers
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
Application server 1. The client invokes the required components container. Container Component
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
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:
91
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.
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
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.
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.
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
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
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
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
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 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
For complete information concerning Broadcast Agent administration, see the Broadcast Agent Administrators Guide.
106
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.
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
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.
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.
110
111
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.
112
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 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
$INSTALLDIR\server\system2.5\ bin\administrator.exe
114
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 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.
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 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.
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
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.
120
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
Document domain
Security domain
Supervisor (creates and manages users and groups, granting access to universes, documents, applications, connections and all other resources)
Repository
Users
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
124
Document domain
Security domain
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
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
127
WIQT
Handles the viewing and refreshing of BusinessObjects documents in the repository from the InfoView ActiveX viewer
128
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
130
Repository
Oracle
Corporate database
131
Repository
Sybase
DB2
Corporate database
Repository domains Database1 Security domain Database2 Document & universe domains Database3 Document domain Informix Informix Informix Corporate databases
132
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.
134
135
136
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.
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.
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
Repository
Users
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
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.
140
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.
Deployment Considerations
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?
Pre-deployment checklist
146
Deployment Considerations
147
148
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.
Deployment Considerations
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.
Deployment configuration
150
Deployment Considerations
151
152
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.
Deployment Considerations
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
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.
Deployment Considerations
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
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.
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.
Deployment Considerations
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.
158
Deployment Considerations
159
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.
Deployment Considerations
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.
Deployment Considerations
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
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?
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
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.
170
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
172
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
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.
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
% 15 15 10
% 50 35 25
% 25 45 60
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.
Cluster architecture
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
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.
Cluster architecture
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.
Cluster architecture
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.
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.
185
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:
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.
187
188
This section illustrates two centralized solutions: Centralized architecture with a single cluster Centralized architecture with multiple clusters Centralized architecture with a single cluster
USA1
USA1
Secondary node/BCA
Data warehouse
LAN/WAN
Users
USA
UK
Users Users
Australia
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
Secondary node/BCA
ClusterA
USA1
LAN/WAN
Users
USA
UK
Users Users
Australia
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
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
Secondary node
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
Distribution
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.
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
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
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
Repository
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
210
Deployment schema
Client machines of 3-tier system Web server Cluster Primary node Database
Repository
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
212
213
Deployment schema
Internet users Application server Primary node
Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
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.
214
Deployment profile
Deployment Type Basic extranet Pros Simple to deploy and administer Cons No extra security, failover or load-balancing mechanisms
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
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).
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
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
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.
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
DMZ
Inner firewall
Repository
Primary node
Secondary node
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.
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.
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
Repository
Corporate database
Cluster B
Shared storage
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
Inner firewall
Deployment profile
Deployment Type IP redirector Pros Provides load balancing and failover Cons Does not efficiently redirect calls in deployments with proxy servers
227
Deployment schema
34.2.148.10:80
Intranet users
12.10.150.20:80 34.2.148.11:80
incoming IP : port
IP : port
IP redirector
34.2.148.12:80
IP : port
34.2.148.13:80
IP : port
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:
IP: port
2.
dir ec ted
re q
12.10.150.20:80
Se rv e
ue
IP: port
34.2.148.11:80 Web server/ primary node C
User
IP redirector
Re
3.
IP: port
IP: port
34.2.148.13:80
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
232
Deployment schema
Cluster A Web server A Internet users Primary node
Outer firewall
DMZ
Inner firewall
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
234
Deployment schema
Web servers Primary node
Extranet users
IP redirector
Intranet
Database
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
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
Intranet users
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
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
Not easy to configure Does not efficiently redirect calls in deployments with proxy servers
239
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
240
III
part
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
247
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
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
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.
253
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
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.
256
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
258
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
260
261
262
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.
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
265
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
270
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.
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.
272
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
274
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.
276
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.
278
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
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
282
283
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.
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
286
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.
287
288
289
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.
290
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
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.
Database
Secondary1
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
295
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
Figure 9-10 Setting the default language during Business Objects installation
297
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.
298
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
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
Repository
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.
IV
part
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
Testing Development
Repository
Development
Production
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.
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
310
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.
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
315
316
317
When you create the repository with Supervisor, consider creating the following additional universe and document domains:
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.
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
Migrate_ dev_to_test
I mp o
rt un
e fr ivers
s om t
Migrate_ test_to_UAT
Im
Migrate_ UAT_to_prod
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:
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.
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.
323
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:
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
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 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).
333
Checking the repositorys integrity 1. Log into Supervisor as a general supervisor. 2. Choose Tools > Repository. The Repository Management dialog box appears:
334
- For the security domain, click Scan, then Repair, and then Compact. - For document domains, just click Scan and then Repair.
335
336
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
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)
340
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
For important information concerning the configuration of the web and application servers, see page 276.
342
343
344
Repository
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
Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
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.
346
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
Outer firewall
Inner firewall
Repository
Secondary node
Secondary node
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.
348
Implementing an IP redirector
Web server 1 Internet users Application server for cluster A Cluster A
Repository
Corporate database
Cluster B
Shared storage
NOTE
349
Incoming port 80 80 80 80
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.
Implementing an IP redirector
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.
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.
Implementing an IP redirector
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.
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:
Implementing an 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
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
Implementing an IP redirector
356
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
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
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
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 0.5 MB figure is twice the size of the average .unv file, but it is advisable to include a sizable margin for safety.
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.
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
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.
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
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.
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.
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
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.
372
373
374
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
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.
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
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
Corporate database
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
HTTP communication Query HTTP layer (server) Display Application interface Report engine
Repository
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
WIQT
Database connectivity
SQL SQL
Corporate database
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
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
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
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
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.
389
Deploying InfoView/WebIntelligence
390
Deploying BusinessObjects
This section contains: Deploying BusinessObjects in 2-tier mode Deploying BusinessObjects in 3-tier mode
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.
Deploying BusinessObjects
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.
Deploying BusinessObjects
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.
Deploying BusinessObjects
396
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.
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.
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.
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.
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
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
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.
Deploying Auditor
410
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
Intranet Extranet
Audit database
Auditor client
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
Audit database
Intranet Extranet
Auditor client
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
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
Web server
Cluster
Dedicated WebIntelligence OLAP secondary node running WIOLAPGenerator Enable all other OLAP components
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)
418
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
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
Make sure that IIS is disabled on the node and that no other web server is installed on it.
422
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
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.
425
426
427
Application server
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).
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
429
430
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
- 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
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
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
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.
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
The WebIntelligence OLAP Report Panel page opens (displayed below with four existing OLAP connections):
440
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.
appendix
442
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
444
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
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
446
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
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
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
448
BusinessObjects documents
Webintelligence documents
N/A
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
450
InfoView/WebIntelligence
Feature
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
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)
454
Feature Find in Report search tool Find in Query Panel tool Installation from a CD
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
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
Index
478
Index