deploying the business objects system

Deploying the Business Objects System

BusinessObjects 6.5

Windows and UNIX

2 Deploying the Business Objects System

Copyright Copyright © 2004 Business Objects. All rights reserved.

Trademarks Business Objects, the Business Objects logo, Crystal Reports, and Crystal Enterprise are trademarks or registered trademarks of Business Objects SA or its affiliated companies in the United States and other countries. All other names mentioned herein may be trademarks of their respective owners.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.

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.227-7013.

Patents Business Objects owns the following U.S. patents, which may cover products that are offered and sold by Business Objects: 5,555,403, 6,247,008 B1, 6,578,027 B2, 6,490,593 and 6,289,352.

Part Number 375-50-650-01

Deploying the Business Objects System 3

Contents

ContentsContents 3

Preface Maximizing Your Information Resources 9

Information resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Useful addresses at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figures 17

Part I Conceptual Overview

Chapter 1 Introducing BusinessObjects 6.5 23

Standard SQL reporting configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

The secure Business Objects configuration . . . . . . . . . . . . . . . . . . . . . . . . . 27

What can you do with the Business Objects solution? . . . . . . . . . . . . . . . . . 28

BusinessObjects 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Desktop products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Server products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Administration products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Database Access Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Demonstrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Developer Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Organization of this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

How terminology has changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61


Contents

Chapter 2 System Architecture and Communication 63

Deployment architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3-tier architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

The client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

The middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Database components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

What products are associated with each architecture? . . . . . . . . . . . . . . . . 76

What platforms are associated with each architecture? . . . . . . . . . . . . . . . 79

What is a cluster? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Why use distributed configurations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

What is CORBA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

The Application Server Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

How the system accesses data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 3 How the System Is Administered 93

The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Administering Broadcast Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Monitoring and analyzing system activity . . . . . . . . . . . . . . . . . . . . . . . . . 101

Command-line administration tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 4 The Repository and Security 105

Data security through the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Repository domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

How clients access the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Which components access the repository? . . . . . . . . . . . . . . . . . . . . . . . . 113

Using multiple repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

The repository and your data warehouse . . . . . . . . . . . . . . . . . . . . . . . . . 116

How do users access the repository? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Working with or without a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Repository compatibility issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


Contents

Part II Planning your Deployment

Chapter 5 Deployment Considerations 127

Pre-deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Education: providing the tools to be successful . . . . . . . . . . . . . . . . . . . . . 130

Performance: what is acceptable and how can you attain it? . . . . . . . . . . 131

Server sizing: efficiently supporting peak user activity . . . . . . . . . . . . . . . . 132

Deployment configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Data management: making data accessible . . . . . . . . . . . . . . . . . . . . . . . 134

Protecting your system and your resources . . . . . . . . . . . . . . . . . . . . . . . . 135

Users: know their numbers, profiles, groups and rights . . . . . . . . . . . . . . . 136

Documents: what type, how complex? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Load balancing: matching system processes and server resources . . . . . 141

Disaster recovery: what can you do about it? . . . . . . . . . . . . . . . . . . . . . . 142

Deployment procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Chapter 6 Modeling your System 147

Designing your architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Selecting your system’s software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Selecting your system’s operating system . . . . . . . . . . . . . . . . . . . . . . . . . 154

Deployment models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Cluster architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Repository architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Database and repository location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Centralized or decentralized architecture? . . . . . . . . . . . . . . . . . . . . . . . . . 170

Global deployment scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182


Contents

Chapter 7 Supported Deployment Configurations 183

Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Basic 2-tier deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Citrix configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

3-tier architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Combined 2- and 3-tier deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Basic intranet deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

DMZ configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Extranet deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Deported application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

IP redirectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Multiple clusters in an intranet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Single-cluster intranet/extranet deployment options . . . . . . . . . . . . . . . . . 222

Multiple-instance servers under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Multihomed configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Multilingual configurations using Unicode . . . . . . . . . . . . . . . . . . . . . . . . . 230

Heterogeneous clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Deployment configuration summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Part III Practical Deployment Specifics

Chapter 8 From Development to Production 239

The development lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Planning the pre-production environment . . . . . . . . . . . . . . . . . . . . . . . . . 246

Creating the lifecycle environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Migrating between environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Planning and building the production environment . . . . . . . . . . . . . . . . . . 265

Chapter 9 Overall Deployment Checklist 267

Setting up a Windows deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Setting up a UNIX deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Setting up a heterogeneous deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 280


Contents

Chapter 10 Implementing Supported Deployment Configurations 287

Installation and configuration for all 3-tier deployments . . . . . . . . . . . . . . . 289

Implementing a Citrix configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Implementing a basic intranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . 298

Implementing a DMZ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Implementing an extranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Implementing a deported application server . . . . . . . . . . . . . . . . . . . . . . . 307

Implementing an IP redirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Implementing a multihomed configuration . . . . . . . . . . . . . . . . . . . . . . . . . 319

Implementing a multiple-instance UNIX configuration . . . . . . . . . . . . . . . . 321

Implementing heterogeneous clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Implementing a single web server for intranet and extranet users . . . . . . . 325

Implementing Unicode corporate databases . . . . . . . . . . . . . . . . . . . . . . . 326

Chapter 11 Deploying and Managing the Repository 339

Choosing a repository database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

How much space should you allot for the repository? . . . . . . . . . . . . . . . . 344

The location of repository domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Deploying and using multiple repositories . . . . . . . . . . . . . . . . . . . . . . . . . 349

Optimizing the security domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Making documents available to users of other repositories . . . . . . . . . . . . 353

Changing a cluster’s repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Chapter 12 Deploying Specific Components and Products 355

Overall 3-tier deployment guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Choosing your applications and how they are deployed . . . . . . . . . . . . . . 362

Deploying Connection Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Deploying InfoView/WebIntelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Deploying BusinessObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Deploying Broadcast Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Deploying Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411


Contents

Chapter 13 Deploying WebIntelligence for OLAP Data Sources 417

WebIntelligence OLAP server as part of the cluster . . . . . . . . . . . . . . . . . 419

Setting up the dedicated OLAP node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

The WebIntelligence cache service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

The Universal Drill Through Service (UDS) . . . . . . . . . . . . . . . . . . . . . . . . 424

Installing the OLAP services on cluster nodes . . . . . . . . . . . . . . . . . . . . . 425

Configuring the OLAP services on cluster nodes . . . . . . . . . . . . . . . . . . . 427

Defining the OLAP connection in WebIntelligence . . . . . . . . . . . . . . . . . . 437

Part IV Securing the Solution

Chapter 14 Data Security 441

Security at the product feature level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Data security at the universe level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Section and block security at the report level . . . . . . . . . . . . . . . . . . . . . . 462

Chapter 15 Network Security 465

Common protection techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Appendix A How Products Compare Functionally 475

InfoView vs. WebIntelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

BusinessObjects: 2-tier vs. 3-tier mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence . . . . . . . . . 480

Processing different types of documents in InfoView . . . . . . . . . . . . . . . . 482

Version 2.x/5.x vs. 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Index 491

pre

face

Maximizing Your Information Resources



Overview

Information, services, and solutionsThe 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.


Information resources

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 14.

��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.

www.businessobjects.com/services/documentation

http://www.businessobjects.com/services/documentation

http://www.businessobjects.com/services/documentation

http://www.businessobjects.com/services/documentation.htm

http://www.businessobjects.com/services/support.htm

http://businessobjects.com/services/documentation.htm



��Multimedia

Are you new to Business Objects? Are you upgrading from a previous release or expanding, for example, from our desktop to our web solution? Try one of our multimedia quick tours or Getting Started tutorials. All are available via the Online Customer Support (OCS) website or on the Documentation CD.

How can I get the most recent documentation?You can get our most up-to-date documentation via the web. Regularly check the sites listed below for the latest documentation, samples, and tips.

��Tips & Tricks

Open to everyone, this is a regularly updated source of creative solutions to any number of business questions. You can even contribute by sending us your own tips.

www.businessobjects.com/forms/tipsandtricks_login.asp

��Product documentation

We regularly update and expand our documentation and multimedia offerings. With a valid maintenance agreement, you can get the latest documentation – in seven languages – on the Online Customer Support (OCS) website.

��Developer Suite Online

Developer Suite Online provides documentation, samples, and tips to those customers with a valid maintenance agreement and a Developer Suite license via the Online Customer Support (OCS) website.

Send us your feedbackDo you have a suggestion on how we can improve our documentation? Is there something you particularly like or have found useful? Drop us a line, and we will do our best to ensure that your suggestion is included in the next release of our documentation: [email protected]

NOTE

If your issue concerns a Business Objects product and not the documentation, please contact our Customer Support experts. For information about Customer Support visit: www.businessobjects.com/services/support.htm

http://www.businessobjects.com

http://businessobjects.com/forms/tipsandtricks_login.asp

mailto:[email protected]

http://businessobjects.com/services/support.htm


Services

Services

A global network of Business Objects technology experts provides customer support, education, and consulting to ensure maximum business intelligence benefit to your business.

How we can support you?Business Objects offers customer support plans to best suit the size and requirements of your deployment. We operate three global customer support centers:• Americas: San Jose, California and Atlanta, Georgia• Europe: Maidenhead, United Kingdom• Asia: Tokyo, Japan and Sydney, Australia

��Online Customer Support

Our Customer Support website is open to all direct customers with a current maintenance agreement, and provides the most up-to-date Business Objects product and technical information. You can log, update, and track cases from this site using the Business Objects Knowledge Base.

Having an issue with the product?Have you exhausted the troubleshooting resources at your disposal and still not found a solution to a specific issue?

For support in deploying Business Objects products, contact Worldwide Customer Support at: www.businessobjects.com/services/support.htm

Looking for the best deployment solution for your company?Business Objects consultants can accompany you from the initial analysis stage to the delivery of your deployment project. Expertise is available in relational and multidimensional databases, in connectivities, database design tools, customized embedding technology, and more.

For more information, contact your local sales office, or contact us at: www. businessobjects.com/services/consulting.htm

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

http://www.businessobjects.com/services/education.htm


http://businessobjects.com/services/consulting.htm



Useful addresses at a glance

Address Content

Business Objects Documentation

www.businessobjects.com/services/documentation.htm

Overview of Business Objects documentation. Links to Online Customer Support, Documentation Supply Store, Documentation Roadmap, Tips & Tricks, Documentation mailbox.

Business Objects Documentation mailbox

[email protected]

Feedback or questions about documentation.

Product documentation

www.businessobjects.com/services/support.htm

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

Business Objects product information

www.businessobjects.com

Information about the full range of Business Objects products.

Developer Suite Online

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.

Knowledge Base (KB)


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.

Tips & Tricks

www.businessobjects.com/forms/tipsandtricks_login.asp

Practical business-focused examples.

http://www.businessobjects.com/services/documentation.htm

mailto:[email protected]


http://www.businessobjects.com

http://www.techsupport.businessobjects.com/


http://www.businessobjects.com/forms/tipsandtricks_login.asp


Useful addresses at a glance

Online Customer Support


www.businessobjects.com/services

Starting point for answering questions, resolving issues.

Information about registering with Worldwide Customer Support.

Business Objects Education Services

www.businessobjects.com/services/education.htm

The range of Business Objects training options and modules.

Business Objects Consulting Services

www.businessobjects.com/services/consulting.htm

Information on how Business Objects can help maximize your business intelligence investment.

Address Content


http://www.businessobjects.com/services/

http://www.businessobjects.com/services/education.htm

http://businessobjects.com/services/consulting.htm



About this guide

This guide describes the overall Business Objects solution and how you can deploy it.

AudienceThis guide is intended particularly for the IT specialists and administrators responsible for installing and deploying the Business Objects system.

The first chapter in this guide provides a summary of what the system can do, and each of the products in the Business Objects line. This chapter is intended for a much broader audience, including users of the products.

Conventions used in this guideThe conventions used in this guide are described in the table below.

Convention Indicates

This font Code, SQL syntax, computer programs. For example: @Select(Country\Country Id). This font is also used for all paths, directories, scripts, commands and files for UNIX.

Some code ��more code

Placed at the end of a line of code, the symbol (�) indicates that the next line should be entered continuously with no carriage return.

$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.


Figures

Figures1-1 Example of a Business Objects deployment . . . . . . . . . . . . . . . . . . . . . 241-2 A standard SQL reporting configuration . . . . . . . . . . . . . . . . . . . . . . . . . 261-3 Secure Business Objects reporting configuration . . . . . . . . . . . . . . . . . 271-4 BusinessObjects document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321-5 Sending a BusinessQuery file to other users . . . . . . . . . . . . . . . . . . . . . 341-6 InfoView home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361-7 InfoView document list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371-8 WebIntelligence report viewed in InfoView . . . . . . . . . . . . . . . . . . . . . . 391-9 A WebIntelligence HTML Report Panel . . . . . . . . . . . . . . . . . . . . . . . . . 411-10 A WebIntelligence Java Report Panel . . . . . . . . . . . . . . . . . . . . . . . . . 421-11 Creating user groups in Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 471-12 SUPERVISOR OVER THE WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481-13 Universes: from the document editor to the database . . . . . . . . . . . . . 491-14 Auditor in the Business Objects system . . . . . . . . . . . . . . . . . . . . . . . . 491-15 Analyzing user activity using Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . 501-16 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521-17 Entrance point to Business Objects multimedia Quick Tours . . . . . . . 551-18 Developer Suite Welcome screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562-1 2-tier deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652-2 Simple 3-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662-3 Business Objects system 3-tier architecture . . . . . . . . . . . . . . . . . . . . . 682-4 Example InfoView home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692-5 The web and application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712-6 A Business Objects cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802-7 How the ORB works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832-8 The CORBA container/component model . . . . . . . . . . . . . . . . . . . . . . . 852-9 How the ASF works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862-10 Connection components in a 2-tier system . . . . . . . . . . . . . . . . . . . . . 902-11 Connectivity components in a 3-tier system . . . . . . . . . . . . . . . . . . . . 913-1 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96


Figures

3-2 The Broadcast Agent Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993-3 Administering the Audit facility in the Administration Console . . . . . . 1013-4 Auditor web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024-1 The repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084-2 Security through the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114-3 Both corporate database and repository in Oracle . . . . . . . . . . . . . . . 1164-4 Corporate database in DB2 but repository in Sybase . . . . . . . . . . . . . 1174-5 Repository in DB2, with different corporate databases . . . . . . . . . . . . 1174-6 Different parts of the repository on different databases . . . . . . . . . . . 1174-7 Setting the authentication mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185-1 Typical proportions of user types in a Business Objects deployment . 1376-1 Administration products on Windows machines outside cluster . . . . . 1576-2 Processing power vs. number of nodes in a Windows cluster . . . . . . 1626-3 Choosing the security domain from BusinessObjects (3-tier) . . . . . . . 1666-4 Setting the WILoginServer refresh period . . . . . . . . . . . . . . . . . . . . . . 1696-5 Centralized architecture with a single cluster . . . . . . . . . . . . . . . . . . . 1716-6 Centralized architecture with failover . . . . . . . . . . . . . . . . . . . . . . . . . 1746-7 Decentralized architecture with centralized security domain . . . . . . . 1777-1 2-tier configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887-2 Citrix configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917-3 Combined client/server and n-tier architecture deployment . . . . . . . . 1937-4 Basic intranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957-5 Typical DMZ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987-6 Communication protocols in a DMZ configuration . . . . . . . . . . . . . . . 1997-7 Typical DMZ topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2007-8 Basic extranet deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037-9 One web server pointing to one primary node within multiple clusters 2047-10 Multiple web servers pointing to one primary node . . . . . . . . . . . . . . 2067-11 ASF and Business Objects processes passing through firewall . . . . 2087-12 Example deported application server configuration . . . . . . . . . . . . . 2097-13 Reverse proxy and web server within DMZ (JSP) . . . . . . . . . . . . . . 2127-14 Reverse proxy alone within DMZ (ASP) . . . . . . . . . . . . . . . . . . . . . . 2137-15 Deployment schema for an IP redirector . . . . . . . . . . . . . . . . . . . . . . 2167-16 IP redirector with sticky command enabled . . . . . . . . . . . . . . . . . . . . 2177-17 IP redirector with multiple clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 218


Figures

7-18 User request redirected to next web server/primary node . . . . . . . . . 2207-19 Running one web server within a single cluster . . . . . . . . . . . . . . . . . 2227-20 Multiple web servers with a single cluster . . . . . . . . . . . . . . . . . . . . . 2237-21 Multi-instance configuration on a UNIX server . . . . . . . . . . . . . . . . . . 2257-22 Example multihomed configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 2287-23 Example international configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 2317-24 Example heterogeneous cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2328-1 The development lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2418-2 Migrating universes from development through production . . . . . . . . . 25410-1 Example deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28910-2 Citrix deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29410-3 Security Policy tab in the Options dialog box in Supervisor . . . . . . . . 29610-4 Intranet deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29810-5 Typical DMZ deployment schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 29910-6 Standard extranet deployment schema . . . . . . . . . . . . . . . . . . . . . . . 30210-7 ASP extranet configuration with IIS web/application server . . . . . . . . 30410-8 First extranet deployment option in a JSP environment . . . . . . . . . . 30510-9 Second extranet deployment option in a JSP environment . . . . . . . . 30610-10 Example deported application server ASP deployment . . . . . . . . . . 30710-11 Example deported application server JSP deployment . . . . . . . . . . 30710-12 List of exposed ports in the Administration Console . . . . . . . . . . . . 31010-13 Example deployment configuration using an IP redirector . . . . . . . . 31110-14 Multihomed deployment configuration schema . . . . . . . . . . . . . . . . 31910-15 Simple multiple-instance deployment under UNIX . . . . . . . . . . . . . . 32110-16 Multi-instance configuration with an IP redirector . . . . . . . . . . . . . . 32210-17 Example heterogeneous cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 32310-18 Single web server for intranet and extranet users . . . . . . . . . . . . . . 32510-19 Example international configuration . . . . . . . . . . . . . . . . . . . . . . . . . 32610-20 Setting the SUN JVM as the default in Internet Explorer . . . . . . . . . 32910-21 Definition for the Arial Unicode MS font in an XML editor . . . . . . . . 33110-22 Definition for the Arial Unicode MS font in a text editor . . . . . . . . . . 33110-23 Font configuration in XML editor (defaultConfig.xml) . . . . . . . . . . . . 33310-24 Font configuration (defaultconfig.xml) in text display . . . . . . . . . . . . 33310-25 Deployment schema 1 for international configurations . . . . . . . . . . 33510-26 Deployment schema 2 for international configurations . . . . . . . . . . 336


Figures

10-27 Deployment schema 3 for international configurations . . . . . . . . . . 33710-28 Deployment schema 4 for international configurations . . . . . . . . . . 33812-1 2-tier BusinessObjects deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 36312-2 BusinessObjects document viewed in InfoView . . . . . . . . . . . . . . . . 36412-3 3-tier deployment of BusinessObjects . . . . . . . . . . . . . . . . . . . . . . . . 36612-1 Accessing a Windows RDBMS from a UNIX server . . . . . . . . . . . . . 37412-2 Cluster with Connection Server in library mode only . . . . . . . . . . . . 37512-3 Cluster with Connection Server in server mode only . . . . . . . . . . . . 37612-4 Connection Server deployed in both library and CORBA forms . . . . 37712-5 Multiple processing nodes and a dedicated Connection Server node 37812-6 Cluster with two dedicated Connection Server nodes . . . . . . . . . . . . 37912-7 Part of a fontalias.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38312-8 A key-value section in defaultConfig.xml . . . . . . . . . . . . . . . . . . . . . 38812-9 A function in the config.js file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38912-10 Dedicated server/double repository for Auditor . . . . . . . . . . . . . . . . 41312-11 Dedicated server/single repository for Auditor . . . . . . . . . . . . . . . . 41513-1 Recommended cluster deployment for OLAP processing . . . . . . . . 41913-2 OLAP services running on the WebIntelligence OLAP node . . . . . . 42513-3 OLAP services on a different node from WebIntelligence OLAP . . . 42614-1 Command Restriction dialog box in Supervisor . . . . . . . . . . . . . . . . 44414-2 Assigning a universe and connection string to a user . . . . . . . . . . . . 44614-3 Restricting access to universe objects in Supervisor . . . . . . . . . . . . 44714-4 Applying Object Security Access Level in Designer . . . . . . . . . . . . . 45014-5 Table mapping in Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45714-6 Hiding report blocks in BusinessObjects . . . . . . . . . . . . . . . . . . . . . . 462

part

Conceptual Overview

ch

ap

ter

Introducing BusinessObjects 6.5



OverviewWhat do we mean by deployment?

Deployment is the distribution and arrangement of Business Objects query, reporting and analysis tools within a network infrastructure:

Figure 1-1 Example of a Business Objects deployment

Initially offered for use in a standard client-server environment, Business Objects products can now be deployed and used over intranets, extranets, and the World Wide Web.

This means that users can access documents from wherever they are, using a standard web browser. Additionally, documents can be automatically broadcast to users at scheduled intervals. These documents can be set up so that the information made available to recipients is determined by their particular user profile.

Outer firewall Inner firewall

Web server

Internet

Secondary node

Application server

3-tier users

Administrators (Supervisor, Designer)

2-tier users (Business-Objects, Business Query)

Corporate database

Repository

Primary node

Intranet


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 you’re 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.



Standard SQL reporting configurations

Before the introduction of applications such as the Business Objects suite, companies relied on database analysts and SQL specialists to directly access their databases and produce meaningful documents.

This type of information access provides a direct link to the corporate database, and allows a large amount of functionality and customization by building unique combinations of SQL statements. However, it is not particularly flexible or easy to modify, since it requires a sufficient level of expertise to build the SQL statements into a coherent reporting environment. Also, data security is limited to the security mechanisms which are built into the corporate database.

Figure 1-2 A standard SQL reporting configuration

Corporate database

SQL

Client


The secure Business Objects configuration

The secure Business Objects configuration

As companies expand and diversify, it becomes more and more important that these functions be made accessible to non-specialized users within the company.

A simplified interface is required; one that allows users to run in-depth database queries, and generate comprehensive and professional documents, without needing to understand the underlying processes. This is the interface that Business Objects delivers with its Business Intelligence software products.

Figure 1-3 Secure Business Objects reporting configuration

The BusinessObjects 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.

Corporate databases

Repository

Business Objects servers

Client

Client

Network



What can you do with the Business Objects solution?

Enterprises are inundated with data about their businesses from multiple sources, and need tools to gain more insight and control over complex business operations. Business Objects technology enables decision-makers in an organization to access, analyze, report and share corporate information — without requiring any technical knowledge. This domain is called business intelligence, or BI. What can you get out of it? Reduced cost, greater efficiency, faster transactions and increased revenue.

With BI, organizations around the world can link their customers, suppliers, partners and internal services to share information and work together in new ways. Based on its web-based thin-client product, WebIntelligence, and its web-enabled full-client product, BusinessObjects, the Business Objects solution provides a robust and secure way to access, analyze and share information, either within an enterprise via an intranet, or beyond an enterprise via an extranet.

Intranets and extranetsAn intranet is a network that reaches across all the different entities of an organization. TCP/IP has become a popular protocol since it allows network administrators to easily split heavy network traffic into smaller domains using subnets, which provides links between them using routers. It takes advantage of existing Internet standards such as the standard client-server model. You can picture the Internet as a massive TCP/IP network, where intranets are just smaller, organization-wide TCP/IP networks that provide company-related information to employees.

When a company opens its intranet to selected business partners, the intranet becomes an extranet. Suppliers, distributors, and other authorized users can connect to the company's intranet over the web to view the selected subset of data the company makes available.

Business Intelligence represents the move of organizations around the world to link their customers, suppliers, partners and internal organizations, to share information, work together in new ways, and to generate greater revenues.


What can you do with the Business Objects solution?

How does Business Objects fit into business intelligence?As organizations establish their business offerings on the web, several implications have emerged surrounding the role of business intelligence. If you take a look at any e-business application framework, there are more aspects to it than just placing a sales order on the web. Once the sales order is placed companies need to take a look at previous transactions, they need to search on a particular product based on certain criteria, they probably need to define their profile and from time to time get alerted on promotions on a product based on their profile.

The Business Objects distributed architecture perfectly fits these various aspects of customer interaction, enabling customers to communicate and share data over the web with their customers, partners, and suppliers.



BusinessObjects 6.5

BusinessObjects 6.5 can be broken down into:• Desktop products• Server products• Administration products• Database Access Packs• Demonstrations


Desktop products

Desktop products

BusinessObjects Desktop products include: • BusinessObjects• BusinessQuery

BusinessObjectsBusinessObjects 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 don’t need any knowledge of the database structure or technology.

Once you’ve 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.



Figure 1-4 BusinessObjects document

You can then save those documents for your own personal use, send them to other users, save them to the corporate repository, or send them to Broadcast Agent for automatic refresh and distribution.

This Windows product allows users to:• build and run queries with different types of data providers, including DBMSs,

OLAP, XML, Microsoft Excel or the web, or combine multiple data providers in one report

• save the BusinessObjects documents in any of several formats including HTML, Excel, PDF or RTF, and print them

• view, refresh, schedule, send, and drill BusinessObjects documents

The BusinessObjects application can be deployed in 2- and 3-tier architectures.


Desktop products

��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.• The server system processing BusinessObjects requests can run either

Windows or UNIX.

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 remain on the server, and security and access is handled through the Business Objects server. This means no client-side administration is required.



BusinessQueryBusinessQuery for Excel is an add-in tool that provides Microsoft Excel with fully functional database access.

Figure 1-5 Sending a BusinessQuery file to other users

With BusinessQuery, you can access your corporate databases from Excel using familiar business terms. All BusinessQuery commands are available through the BusinessQuery menu and toolbar that appear in Excel. The result is easy and intuitive information access with guaranteed, reliable results.

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. 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.


Desktop products

��BusinessQuery for multidimensional data access

A separate addin called BusinessQuery MD allows you to access OLAP data sources such as Microsoft® SQL Server OLAP/Analysis Services Access from Microsoft Excel. Unlike the standard BusinessQuery application, however, you install BusinessQuery MD separately from the other products in the BusinessObjects suite.



Server products

Server products include:• InfoView• WebIntelligence• Broadcast Agent

InfoViewAt the core of the Business Objects BI solution is InfoView, the portal to your organization’s information capital.

Figure 1-6 InfoView home page

InfoView is the web-based entry point for accessing WebIntelligence and BusinessObjects documents, as well as any type of third-party document. It collects and consolidates a company’s 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 from your office, home, or around the world, using the corporate intranet, an extranet, or the World Wide Web.


Server products

��The InfoView document catalog

At the heart of InfoView are the document lists which can be customized to suit your needs.

Figure 1-7 InfoView document list

Whether you are looking for a sales report, a financial statement, or an inventory spreadsheet sheet, the InfoView portal provides an instant overview of all the documents to which users have access rights. You can also search for particular documents by using the Search facility.

The Home page can contain up to three document lists:• The Corporate Documents list contains files that have been saved or added

to a document domain in the corporate repository and made accessible to workgroups within the corporation or organization.

• The Personal Documents list contains documents users have saved for their own personal use.

• The Inbox Documents list contains documents sent by other users.



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 applications, 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, while their customers enjoy self-service access to information tailored to their specific needs.

Using the powerful broadcasting services of Broadcast Agent, you can schedule the automatic refresh and distribution of documents to colleagues or partners via the repository, the web, an intranet, or an extranet.

��InfoView with Application Foundation deployment

You can now deploy InfoView with Application Foundation, which is now only available in this deployment.

Application Foundation allows you to manage dashboards in the same way that InfoView lets you manage documents.

WebIntelligenceWebIntelligence 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, edit and/or analyze WebIntelligence reports. Using InfoView, you can save WebIntelligence reports to the corporate repository or share documents with other users.


Server products

Figure 1-8 WebIntelligence report viewed in InfoView

If your deployment includes Broadcast Agent, you can also schedule WebIntelligence reports 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



��WebIntelligence

WebIntelligence provides the ability to create reports based on relational databases. It allows you to:• create or edit WebIntelligence reports• include multiple queries in a single report• interact with WebIntelligence reports, by using filters, sorts, calculations, and

formatting options, or by selecting different report data for display on reports• analyze report data using drill• use alerters to dynamically highlight high or low results• download WebIntelligence reports to Acrobat PDF format or Microsoft Excel

format files with the original data definition and formatting, or to CSV format for exporting to other applications

The ability to include filters and prompts at the query level enables you to restrict the information in reports 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 that generates a WebIntelligence report:• The WebIntelligence HTML Report Panel, designed for users with basic

reporting needs, provides a tab-by-tab workflow to define queries and report formats. Its pure HTML 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 query interfaces and workflows for their unique environment using the WebIntelligence SDK.


Server products

Figure 1-9 A WebIntelligence HTML Report Panel

The reporting features in the HTML Report Panel include the ability to customize chart and table formats, insert breaks and calculations, apply sorts, and add multiple report filters. reports created with the HTML Report Panel contain multiple reports, each with a single table or chart.



• The WebIntelligence Java Report Panel, designed for power users, provides a drag-and-drop interface similar to BusinessObjects. Users download the Java Report Panel to their local PC via their Internet browser.

Figure 1-10 A WebIntelligence Java Report Panel

The advanced feature set of the Java Report Panel includes all the features provided by the WebIntelligence HTML Report Panel plus: the ability to include multiple queries, create multiple table, charts, and reports in a single report, 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 report creation options on the InfoView Options pages.


Server products

��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 reports across your organization.

Broadcast AgentWith 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 run every working day at 7 AM, 4 PM, and 11 PM.



• 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. Broadcast Agent Scheduler can run BusinessObjects, WebIntelligence and even WebIntelligence for OLAP reports in batch mode.

NOTE

Broadcast Agent Scheduler corresponds to the Broadcast Agent option in the BusinessObjects 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 e-mail.

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 BusinessObjects installer used for the other server products.


Server products

Email publications

You can notify a list of recipients that key information is available, via email. Recipients can subscribe to the publications that are the most useful to them, and how often they want to receive them.

As with web publications, 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.

Web publications

You can process, publish and manage enterprise reports on the server using a web publication. Using Broadcast Agent Publisher’s 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 Publisher’s 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.



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

For a full overview of how the system is administered, see “How the System Is Administered” on page 93.

SupervisorSupervisor 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.



Figure 1-11 Creating user groups in Supervisor

Supervisor lets administrators fine-tune user permissions through the use of security commands, which control with great flexibility what product functionality is available, both in the user interface and through programmability.

Supervisor controls access of users and groups to resources such as documents, universes, stored procedures and repository domains, and also sets inheritance chains, so that permissions can be handed down to subgroups and users by default or set specifically per resource for any user or group.

��Supervisor over the Web

BusinessObjects 6.5 includes a streamlined, web deployment of Supervisor called Supervisor over the Web. Based on the Business Objects system component Administration Server and the Administration SDK, this application allows supervisors to create and manage users and groups in a zero-admin solution.



Figure 1-12 Supervisor over the Web

DesignerDesigner 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.



Figure 1-13 Universes: from the document editor to the database

Designers distribute universes to users by exporting them to the repository, or distributing universes through a file system. BusinessObjects and WebIntelligence users can then access the universe in the repository, or from a directory on a file system, to create documents.

BusinessObjects AuditorBusinessObjects 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, 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.

Figure 1-14 Auditor in the Business Objects system

Query Panel in BusinessObjects

Report Panel in WebIntelligence

objects database schema database

Auditor

clients

Auditor on

Business

Objects server

Corporate

database

Business Objects

server

Business Objects users

Repository

Audit database



Auditor allows you to determine who is using a particular Business Objects system, how often they are using it, and what data they are accessing:

Figure 1-15 Analyzing user activity using Auditor

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 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



Impact analysisWith this version, Auditor comes with a new Impact Analysis feature, enabled and disabled in the Audit panel. Impact analysis allows you to determine the impact that modifying a document will have on the repository.

Metadata gathered about documents can be analyzed using objects in the Impact Analysis universes.



The Configuration ToolThe Configuration Tool provides you with the means to configure your 3-tier deployment’s ORB and third-party components so that a specific set of Business Objects server processes is started by the ASF whenever the node is started.

It also ensure that users can access the Business Objects system through client applets or applications such as web browsers, report editors or viewers, 3-tier deployments of BusinessObjects, etc.

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.

Administration ConsoleThe Administration Console serves as a central control panel for each Business Objects cluster. At any given time it shows you at a glance what servers are running in the cluster, and what modules are enabled on each server.

The Administration Console also allows you to enable, disable and define settings for the modules on each server, thereby tuning the solution to optimize its performance.

Figure 1-16 The Administration Console



Diagnostics toolsUnder 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.



Database Access Packs

Business Objects products allow users to retrieve and analyze data from relational databases. Users access data through pre-defined connections to the database middleware. A connection consists of a Business Objects Data Access driver that is configured to access database middleware for a target database. Each Data Access driver can be optimized for your data access and network needs. You need to ensure that you have installed the correct Data Access driver for your middleware.

Connections are usually defined in a universe. Once a BusinessObjects or WebIntelligence user is connected to the universe, the connection allows the user to retrieve data from the target RDBMS.

For more information about RDBMS connections, see the Data Access Guide.

BusinessObjects OLAP ConnectBusinessObjects OLAP Connect is a data provider that lets Business Objects users access Microsoft SQL Server OLAP Services (MS OLAP Services) and SAP Business Information Warehouse (SAP BW) servers.


Demonstrations

Demonstrations

This category contains a set of demonstrations and multimedia tours:• The Demo Kit installs sample universes, databases and reports• A set of multimedia quick tours of some of the Business Objects products

Figure 1-17 Entrance point to Business Objects multimedia Quick Tours



Developer Suite

Developer Suite is a set of programming tools for customizing, extending, and integrating Business Objects products.

Figure 1-18 Developer Suite Welcome screen

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


Developer Suite

Programming languagesThe 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…

Use… And this scripting language…

BusinessObjects Windows only VB/VBA –

Designer Windows only VB –

WebIntelligence Server Windows only ASP JScript

JavaScript

VBScript

Windows and UNIX JSP Java

Report Engine Server

Administration Server

Windows and UNIX JSP Java



Organization of this guide

Some of the new topics included in this guide since version 5.x/2.x are:• How to model your system—advice 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 Type of information

Description

I Conceptual Overview Conceptual Overview of the Business Objects product line, basic deployment architectures and their CORBA infrastructure, how the system is administrated, and the system’s central repository


Organization of this guide

II Planning your Deployment

Conceptual 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

III Installing and Configuring the System

Conceptual Overview of everything you need to do to get the system installed and up and running

IV Practical Deployment Specifics

Practical 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

Part number and title Type of information

Description



Windows and UNIX pathnamesFor reasons of simplicity, if the same directory path is valid for both Windows and UNIX platforms, the path is written in Windows notation.

This means, for example, that the following Windows path:$INSTALLDIR\nodes\<hostname>\<clustername>\temp

is equivalent to this UNIX path:$INSTALLDIR/nodes/<hostname>/<clustername>/temp


How terminology has changed

How terminology has changed

Since the 5.x/2.x releases, some of the deployment terminology used in the Business Objects documentation has changed:

Term as used in 5.x/2.x releases New term or definition

Business Objects Services Administrator

Administration Console

Client-server 2-tier

Cluster terminology:• Cluster manager• Cluster node

Cluster terminology:• Primary node• Secondary node

All nodes in the cluster, including the primary node, are called cluster nodes.

Distributed system/solution/architecture

3-tier system/solution/architecture

The term “distributed” now refers exclusively to deployments in which processing is distributed over more than one server in the cluster.

Enterprise Server Products Server products

WebIntelligence system Business Objects system

WebIntelligence server Business Objects server

Zero Admin BusinessObjects, the zero-administration deployment of BusinessObjects, or ZABO

3-tier deployments of BusinessObjects, or BusinessObjects in 3-tier mode

InfoView terminology:• Publishing a document• Uploading a third-party file

InfoView terminology:• Saving a document to the

repository• Adding a third-party file

ch

ap

ter

System Architecture and Communication



OverviewThis 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 system’s CORBA-related components and how the system uses them.


Deployment architectures

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 environmentIn 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.

Figure 2-1 2-tier deployment

Corporate database

Repository

Client machines

(full client)



3-tier environmentIn 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.

Figure 2-2 Simple 3-tier architecture

Using a 3-tier architecture allows for much larger deployments than a traditional architecture can handle. It also reduces the total cost of ownership for large-scale deployments.• Any tier can be updated or modified independently of the other tiers. The tiers

can also run on different operating system platforms.• It provides self-service data access for end users, and high availability and

performance. • It cuts maintenance and deployment costs by using zero-administration

clients (only the deployment’s 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 full client users are used to. The compact Java applets are automatically downloaded to the thin-client web browser.

• All processing is carried out on the middle-tier servers.• If you distribute components over several servers, you can optimize the use

of the server resources, reduce the workload on the web server, and increase performance. This can also provide failure recovery if the components are installed on more than one server, as well as help isolate the processes in case of failure.

Today, the standard Business Objects deployment is a 3-tier one.

Database

Users on client machines

Application server

Business ObjectsserversWeb server

Intranet

Repository


3-tier architecture overview


A 3-tier architecture is one in which applications are broken up into layers (or tiers). It includes:• the client, from which users access the Business Objects system functions• the middle tier includes both the web tier and the Business Objects server

components• the database tier

Each of these tiers is described in more detail below.

In this architecture, server products share common server resources. These products can be installed either on a single physical server, as is often the case in UNIX deployments for example, or distributed over several servers in what we refer to as a distributed deployment. In this case, Business Objects modules, or processes, can run on different machines, and the system automatically recognizes all the machines in the system, as well as the distributed services at runtime.

Whether the 3-tier solution is deployed over a single machine or over several, the set of server nodes hosting Business Objects components is called a cluster. For more information, see page 80.



Here is an illustration of the three tiers in this type of architecture:

Figure 2-3 Business Objects system 3-tier architecture

Application server

Web server

ASP/JSP pages

ASP/JSP engine

API proxy

Business ObjectsProcessing components

API

HTTP

ClientInfoView, WebIntelligence, BusinessObjects

in web browser

Presentation layer

Processing layer

Local storage and system caches

Functional services

Client tier

Middle tier

Database tier

Database server Repository

IIOP


The client

The client

Users access the Business Objects system through a portal which provides them with personalized access to their organization’s information capital. This portal is provided by the InfoView client:

Figure 2-4 Example InfoView home page

Through this portal, accessed through a standard web browser, users can view, refresh and distribute all the documents to which they have access rights. They can also access WebIntelligence and BusinessObjects in 3-tier mode.

A Business Objects deployment can contain several portals, depending on its size, complexity and geographical distribution.

There is no client-side administration of the Business Objects system. No middleware is required on the client, and for InfoView and WebIntelligence client use, no application software is installed. For BusinessObjects in 3-tier mode, client software is installed and used to create and edit documents, but all connectivity is provided by the server components in the middle tier.

By contrast, in a 2-tier deployment, the BusinessObjects client is the Windows application (BusObj.exe) that runs on the user’s desktop. This application gives users the ability to access a repository of universes and BusinessObjects documents, and to retrieve data from databases.



The middle tier

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

The presentation layerThe presentation layer contains the web and application servers used to generate the HTML and DHTML used in InfoView and WebIntelligence. It also contains all the communication and data translation layers that enable lightweight components to communicate with the system using the standard web HTTP protocol. • The web server stores static web pages like document lists, and bitmaps used

in InfoView. It also serves as a router relaying requests from the client to the application server and beyond to the Business Objects cluster.

• The application server processes dynamic pages and hosts the active components which accept requests from clients then route them to the Business Objects processing layer for processing.


The middle tier

s

Figure 2-5 The web and application servers

��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

Web server

WebIntelligence applet

3-tier BusinessObjects

WebIntelligence applet

WebIntelligence JSP pages

InfoView JSP pages Application

server HTTP layer

Business Objects processing components

WIBeanREBean

Application server

Web browserClient computer

HTTP server routingStatic files

Static HTML pages and bitmaps



The Business Objects processing layerThe Business Objects processing components constitute the operational arsenal of the Business Objects server products. Called modules when they can be administered, these processes handle:• user login and authentication, checking with the central repository• the creation and cessation of all Business Objects user sessions, and track

all user activity from the time users log in until they log out• the generation of document lists• the creation, processing, distribution, storage and caching of

BusinessObjects, WebIntelligence and third-party documents

The client applications access these processing components through APIs (WIReportServer and WIAPIBroker) and interface components hosted within the cluster.

Business Objects system components and processes include:

Component Description

Administration Server

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.

Administration Server is now also used by the Administration Console and Supervisor over the Web.

Audit Server Writes records of 3-tier user activity for Auditor and into the Audit database.

BOManager 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 reports, where one session is launched per user.



BusinessObjects processes

Acting as report engines for BusinessObjects documents, these processes are called BusObj.exe in Windows and bolight in UNIX.

Connection Server (CORBA-based component, as opposed to the library component)

Connectivity layer used to control execution of SQL requests. Generated in pools of processes, it is used by WebIntelligence, BusinessObjects and WILoginServer.

Scheduler Working with Broadcast Agent, the Scheduler periodically polls the repository to detect tasks to run. It then calls:• WIQT for processing WebIntelligence 2.x reports• WIReportServer for processing WebIntelligence 6.x

reports• BOManager for processing BusinessObjects documents

WIADEServer WIADEServer (ADE stands for Application Development Environment) provides the server interface for calls from the InfoView client ActiveX viewer and for rendering BusinessObjects documents in HTML and PDF format.

WIAPIBroker The InfoView, WebIntelligence and Broadcast Agent applications all use WIAPIBroker as the interface for to creating, accessing, and terminating sessions.

WIAPIBroker makes possible all client navigation through the portal, for example viewing document and universe lists, categories, etc.

WIAPIBroker is also responsible for reserving the critical WIQT process from the node’s WIQT process pool for all session processing. It does this through WIProcessManager, the WIQT manager.

WIDispatcher Used for displaying WebIntelligence 2.x reports, the WIDispatcher receives a translated request from the HSAL/JHSAL and decides which process the request should be sent to.

WIImpactAnalysis Manages the Impact Analysis feature that you can use through Auditor.




WIQT WIQT serves as a report engine for processing WebIntelligence 2.x reports and manages the processing of BusinessObjects documents via BOManager.

Each WIQT process is dedicated to a single InfoView user session.

WILoginServer Speeds login process by providing a cache for repository security. Works with Connection Server.

WIReportServer Report engine that processes WebIntelligence 6.x reports.

WISession-Manager

Creates and manages InfoView user sessions. This process is part of the Session Stack, and is therefore enabled on each processing node in the cluster.

WISiteLog Provides a server object for auditing features, registered with the ORB. It runs on the primary node machine and, unless disabled, on the secondary nodes.

The audit object lets you log events in text files or in a database.

WIStorage-Manager

Active on the primary node only, is used to set parameters for the system’s common storage areas, such as maximum storage space, the frequency with which documents are deleted from storage, etc. These parameters are set in the Administration Console. WIStorageManager also cleans up the system’s storage areas.



Database components

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 universe’s objects and classes which map to the required data in the corporate database. See the Designer’s 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 105.

• Corporate databases are the source of the actual data used in BusinessObjects and WebIntelligence documents.

You need a Business Objects data access pack to connect your Business Objects application to one or more repositories or corporate databases. There is a data access pack for each supported RDBMS middleware.

A data access pack consists of a Business Objects data access driver and license key. The data access driver allows you to connect to a target RDBMS middleware to access your data.

The Business Objects connectivity layer and data access drivers are described in the Data Access Guide.



What products are associated with each architecture?

Within each environment, you can deploy Business Objects products in different ways and combinations.

The following tables list a variety of deployment types as well as the products needed to create the architecture. Designer and Supervisor are not included in these charts but are needed to deploy all architectures.

Types of 2-tier deployments and associated products

Deployment type Product(s)

Standard BusinessObjects in 2-tier mode BusinessObjects on each workstation

Standard BusinessObjects in 2-tier mode with scheduling support

BusinessObjects on each workstation, Broadcast Agent on the server


What products are associated with each architecture?

Types of 3-tier deployments and associated productsThe following table lists deployment types and their associated products:

NOTE

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.

Deployment type Product(s)

WebIntelligence report display and interactive refresh only

InfoView, WebIntelligence

WebIntelligence report display and interactive refresh, with scheduling support

InfoView, WebIntelligence, Broadcast Agent

BusinessObjects document display and interactive refresh only

InfoView

BusinessObjects document display and interactive refresh with scheduling support

InfoView, Broadcast Agent

BusinessObjects document access, refresh and editing

BusinessObjects in 2- or 3-tier mode, InfoView (to download 3-tier BusinessObjects)

WebIntelligence and BusinessObjects document display and interactive refresh

InfoView, WebIntelligence, BusinessObjects in 2- or 3-tier mode

WebIntelligence and BusinessObjects document display and interactive refresh, with scheduling support

InfoView, WebIntelligence, BusinessObjects in 2- or 3-tier mode, Broadcast Agent

WebIntelligence and BusinessObjects document display and interactive refresh, with scheduling support on a heterogeneous configuration (Windows and UNIX)

InfoView, WebIntelligence, 2- or 3-tier BusinessObjects, Broadcast Agent



��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.


What platforms are associated with each architecture?

What platforms are associated with each architecture?

Business Objects server products can run on Windows as well as a variety of UNIX platforms including Sun Solaris, IBM AIX and HP-UX.

2-tier Business Objects deployments are exclusively Windows-based. The client application BusinessObjects is a Windows process called BusObj.exe that cannot run on any other platform.

A 3-tier architecture, however, allows you to use Windows or UNIX servers, or a combination, which is called a heterogeneous solution.

For a full list of currently supported platforms, see the PAR (Product Availability Report):1. Go to http://www.techsupport.businessobjects.com.2. Log into the site.3. Click Enterprise 6 > PAR > BI Platform 6.

http://www.techsupport.businessobjects.com



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.

Figure 2-6 A Business Objects cluster

Because the application server uses CORBA to communicate with the cluster’s API and interface components, the application server is also considered to be part of the cluster.

Users on client applications Application server

Web server

Business Objects primary node

Network

Secondary node


What is a cluster?

What is the primary node’s role?The primary node performs the following services:• It tracks and manages processes throughout the system using

WIClusterManager.• It records various system and user activities.

The primary node occupies a critical position in the Business Objects system. Should it fail, the entire system needs to be stopped and restarted.

NOTE

Up through version 6.0, the cluster’s single WISessionManager was required to be enabled on the primary node. Now, however, WISessionManager is enabled on each processing node in the cluster, thereby removing it as a single point of failure.

What is the secondary node’s role?Secondary nodes rely on the primary node to provide the infrastructure required to allow multiple servers to work together.

You can configure a secondary node to run only a subset of the full complement of Business Objects modules using the Administration Console. The Console allows you to tailor the structure of your system and more efficiently serve the needs of your users. For example, if you find that the load on a particular type of server process within the system is high, you can dedicate a machine to just that process.



Why use distributed configurations?

The distributed object technology underlying the Business Objects system provides scalability and flexibility because components of the BusinessObjects middle tier can either run on a single machine or be distributed across multiple machines in the cluster.

The system’s distributed component architecture provides three major benefits: • Failover

A distributed system can also provide failure recovery: when system components are installed on more than one server, if a server stops working, the system can continue to use the same required components on other servers.

• ScalabilityUser populations using this type of Internet technology can be much, much larger than we have traditionally seen. As the document processing needs and the user population in your organization grow, you can manage the extra workload simply by adding servers to the system.

• Load balancingWhen you have enabled multiple instances of certain key Business Objects modules over several nodes, the distributed system automatically performs load balancing across component servers. You can also weight the transaction loads to optimize the use of more or less powerful processors, thus optimizing the use of server resources, reducing the workload on the web server, and improving performance.

All of these advantages are made possible by the use of CORBA and the Business Objects Application Server Framework, or ASF.


What is CORBA?

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 doesn’t 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.

Figure 2-7 How the ORB works

2.

3. The ORB returns the results to the client.

The ORB locates the object on one of the servers connected to it, and implements the request.

1. The client requests an object.

Servers

Object Request Broker

Client



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.


The Application Server Framework


The ASF simplifies and standardizes the behavior of CORBA servers, and provides additional benefits such as improved load balancing and failover. This light application server:• encapsulates all calls to the ORB in a single abstraction layer• manages the object life cycle, handling creation, activation, registration and

deactivation• manages the distribution of objects between the nodes in a cluster• improves load balancing and failover• provides an interface for administering cluster nodes and their objects

The ASF is started and stopped when the node on which it resides is started and stopped.

The container/component modelThe ASF is based on a simple CORBA container/component model. In this model, CORBA components run inside containers hosted on the application server.

These containers act as the interface between the components and client requests. To communicate with a component, clients access the container hosting the component, and it is the container which in turn invokes the component’s methods.

Figure 2-8 The CORBA container/component model

1. The client invokes the required

component’s container.

Client2. The container invokes the component’s methods

Application server

Container

Component



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 ORB’s 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 ASF’s 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 object’s IOR to request the object, directly invoking the object’s own methods as exposed through the object’s external interface.

Figure 2-9 How the ASF works

The Business Objects system therefore accesses the ORB through the ASF.

ASF client interfaceASF container

Business Objects server objects treated as ASF

Internal interface

Callback interface

External interface

Client

O R B

APPLICATION SERVER FRAMEWORK



The principal ASF daemon: WIProcessManagerWIProcessManager manages the Business Objects system’s process lifecycle. It:• 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 node’s Node Weight parameter)

• manages all Administration Console workflows (previously routed through WIClusterNode/WIClusterManager)

• creates and manages the process pools for:- WIQT- WIReportServer- Connection Server- WIOLAPGeneratorThe number of processes in each process pool is indicated in the localnode.xml file. You can modify the numbers in the Administration Console.

How the ASF improves fault toleranceCORBA ensures fault tolerance for persistent objects. In CORBA, persistence means that if an object is removed from memory, or if the container hosting the entity dies, the entity is recreated with the same object ID at the first request.

ASF services (nearly all Business Objects processing modules) and entities are persistent objects. This means that if the server hosting these objects crashes, the ASF automatically reactivates the objects with the same object ID and on the same machine, at the first client request. Furthermore, all references to persistent objects stay valid, but the object context is reinitialized if it has not been saved.

How the ASF enhances load balancingIn previous versions of Business Objects, administrators could set a parameter for the WIGenerator module called the Node Load Factor. This allowed you to weight the transaction load of the WIQT processes for a specific server dynamically.



For example, if a particular cluster node machine was much more powerful than other nodes in the cluster, you could make sure it received more WIQT processes by giving it a higher Node Load Factor than the other machines in the cluster. Likewise, if one machine was particularly restricted, by giving it a low Node Load Factor, you could make sure it did not penalize the entire system.

When a new user session started, instead of automatically sending the new transaction to the node running the fewest transactions, the WISessionManager sent it to the machine whose current session count/Node Load Factor ratio was the smallest. This was called the load ratio.

With this release, the ASF extends this load balancing mechanism to the processing load for the entire server. It is now called the node weight.

For more information on setting this parameter, see the System Administrator’s Guide.

ASF configurationYou configure the ASF/ORB when you define your cluster using the Configuration Tool.

You can launch this tool either directly from Business Objects installation, or as an independent application. For complete information, see the Installation and Configuration guide.

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

You can find detailed information on using the Configuration Tool in the Installation and Configuration Guide.


How the system accesses data


Business Objects allows users to retrieve and analyze data from relational or OLAP databases containing corporate data. The system relies upon another database, the repository, for most types of authentication, and for the secure access and distribution of common resources such as universes, lists and documents.

Business Objects applications access data in databases through named set of parameters called connections, which link Business Objects applications, database access drivers, your middleware, and your database.

A Data Access driver or OLAP Access Pack is a Business Objects component which connects Business Objects applications on a client or server machine to your middleware. Middleware is a third-party software component which connects to a network which accesses your database.

Data Access drivers and OLAP Access packs are shipped with Business Objects products. There is a Data Access driver for each supported middleware. The driver you install depends on the type of database you use. For example, if you access an Oracle 8i database, you must install the appropriate middleware (Oracle 8i Client), then the Business Objects Oracle Data Access driver.

Connection ServerIn 3-tier deployments, another component is required for database access: Connection Server. Connection Server is the new Business Objects library used for relational database access; it is automatically installed on machines whenever Data Access drivers are installed. This type of Connection Server is used for local transactions only. Requests come from clients such as BusinessObjects Reporter or WebIntelligence, installed on the same machine as the Business Objects Access Pack used to query the data account.

A CORBA-based Connection Server component is also automatically installed on cluster nodes whenever the Business Objects server option is selected in the Installer. Working with a locally-installed Data Access driver, this type of Connection Server provides database access for transactions coming from any node in the cluster. For more information, see Deploying Connection Server on page 372.



Database connections in a 2-tier systemThe following diagram shows how database connection components are distributed in a 2-tier system:,c,v

Figure 2-10 Connection components in a 2-tier system

The Connection Server in library mode is installed along with the data Access driver.

Database connections in a 3-tier system

Client BusinessObjects (Desktop),BusinessQuery

Database server

Network

RDBMS

Server middlewareClient middleware

Data Access driver



The following diagram shows how connectivity components are distributed in a 3-tier system:

Figure 2-11 Connectivity components in a 3-tier system

Connection Server in library mode is still installed with the local Data Access driver. In addition, a CORBA-based Connection Server is installed with Business Objects server, and allows any server in the cluster to avail itself of its locally installed Data Access drivers.

Where you can find more informationYou can find detailed information about database access in the following guides:• For information about access to relational database management systems,

see the Data Access Guide.• For information about connecting to an OLAP cube, see the Essbase OLAP

Access Pack User’s Guide, Express OLAP Access Pack User’s Guide, or DB2 OLAP Access Pack User’s Guide.

• For information about connecting to data in a Microsoft Excel file, see the BusinessQuery User’s Guide.

RDBMS

Client (web browser)InfoView, WebIntelligence,BusinessObjects (3-tier),Broadcast Agent

Business Objects server

Database server

Connection Server Data Access driver

Network NetworkClient middleware

Server middleware

ch

ap

ter

How the System Is Administered



OverviewAdministering 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 Administration Console• Administering Broadcast Agent• Monitoring and analyzing system activity• Command-line administration tools

NOTE

This chapter provides just an overview. For complete information about administering Business Objects clusters, see the System Administrator’s Guide.

Business Objects administrative applications also include Designer, Supervisor and Supervisor over the Web, described in Chapter 1.


The Administration Console


The Administration Console acts as a control panel for overseeing each Business Objects cluster. It lets you monitor and control all the servers and modules in your system from a single machine, regardless of how many servers are part of your configuration:

Although some administrative tasks are required before you can use the system, you can and certainly will repeat them regularly the system is used. As you discern user habits and performance bottlenecks, you will use the Console to tune your system to perform at its best under every type of circumstance.

Session StacksIn past versions of Business Objects, the processing of client requests in the same InfoView user session was often distributed over several machines in the cluster.

This processing is now speeded up by having all of the requests for a single user session processed by modules on the same cluster node. As the modules communicate using intramachine calls rather than inter-machine CORBA calls, communication is faster and performance improved.

These modules in the Session Stack include:• WISessionManager• WIAPIBroker• WIQT (pool of processes)• WIReportServer (pool of processes)• WIDispatcher• WIADEServer• BOManager (and its pool of BusObj/bolight processes)

Administrators start or stop all the modules in the Session Stack at the same time, simply by clicking a single Disable/Enable button in the Administration Console. This means, however, that you can no longer reserve a node for specific document processing tasks, like having one node process BusinessObjects documents, and another process WebIntelligence reports.

If the Session Stack is not enabled on a node, the node cannot process documents or reporting requests. It can, however, handle other services, such as login and auditing.



The following Business Objects modules do not belong to a node’s Session Stack, and therefore can be started and stopped individually:• Administration Server• Connection Server (pool of processes)• WILoginServer• WIStorageManager• Broadcast Agent Manager• WIOLAPGenerator (Windows only)• WISiteLog

The Console interfaceThe Administration Console looks like this:

Figure 3-1 The Administration Console

In the view above, you can see at a glance which modules are running on the cluster server, as well as the default cluster language. You can also access a list of all the users currently logged into the system. You can enable and disable each cluster node’s 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 can be open concurrently, the maximum number of processes, and so on.

Types of Administrator ConsoleThe Administration Console comes in two forms:• as a Java applet which the Business Objects administrator accesses through

a standard web browser • as a standalone Windows application (administrator.exe) available from the

Windows Start menu This program makes direct calls to a Java virtual machine (Java 2) running the Java Administration Console applet described above. This application is used in deployments containing 2-tier deployments of BusinessObjects and Broadcast Agent only, which do not use a web server.

Who can use the Administration Console?Because administration tasks represent critical server operations, only the Business Objects system’s administrator, with specific rights within the Business Objects system, can use the Console.

With this release, administrators log into the Administration Console through WILoginServer. This provides tighter and more detailed control over the people who use the Console, and what they can do with it.



Administering Broadcast Agent

With this release, the term Broadcast Agent is used to designate two Business Objects server products: Broadcast Agent Scheduler and Broadcast Agent Publisher.

Because Broadcast Agent covers two different functional areas, the Business Objects system provides two tools for administering it:• The product itself relies upon a set of processes within the Business Objects

system. You can administer these processes using the standard Administration Console.

• When BusinessObjects in 2-tier mode and/or InfoView users schedule documents with Broadcast Agent for automatic refresh and distribution, each request is called a task. Administrators can monitor and modify various aspects of these scheduled tasks using the Broadcast Agent Console.

NOTE

For complete information concerning Broadcast Agent administration, see the Broadcast Agent Administrator’s Guide.

Tuning Broadcast Agent components using the Administration ConsoleBroadcast Agent uses the modules in the Session Stack to process documents. In order to process. You can create the critical Schedulers and tune all these processes using the Administration Console.

Note that the Session Stack’s Enable batch processing option must be set to On for the node to perform Broadcast Agent tasks.

EXAMPLE

Using the Administration Console to tune Broadcast Agent components

Schedulers check the repository at regular intervals for documents flagged for scheduled processing. When a document is due to be processed, they signal the local CORBA daemon to signal a BOManager or WIQT on the first available machine to process the document.

You can determine how frequently the Scheduler queries the repository by setting the Scanning Repository Delay parameter for the Broadcast Agent Manager on which the Scheduler runs.


Administering Broadcast Agent

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 system’s default load-balancing algorithm.

If a task fails, the Scheduler automatically tries again after a length of time set using the Delay between retry parameter for each Scheduler.

The Broadcast Agent ConsoleOnce BusinessObjects and/or InfoView users have scheduled documents for automatic distribution with Broadcast Agent, you can monitor this activity with the Broadcast Agent Console.

Figure 3-2 The Broadcast Agent Console

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, such as 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


Monitoring and analyzing system activity

Monitoring and analyzing system activity

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

Administering the Audit facilityThe Audit facility tracks critical information relating to user and system activity and places it in the user.log file, or a relational database where it can be accessed with Business Objects products.

This information includes the duration of a user’s request as well as the time the system takes to respond. In this way, you can determine how many users were active at any given time, and thus check the number of concurrent users in the system (that is, users who are making the server work as opposed to the users who are merely logged in).

You use the Administration Console to enable and disable the Audit facility, and to specify whether the audit information is stored in a database or a flat log file:

Figure 3-3 Administering the Audit facility in the Administration Console



Administering AuditorBusinessObjects Auditor uses the information stored by the Audit facility in a database to monitor and analyze user and system activity for all Business Objects server products, displaying the results in a web interface.

Figure 3-4 Auditor web interface

As the Auditor administrator, you not only have to set up, configure and maintain Auditor to work correctly with the Business Objects 3-tier system, but you also:• manage user access rights through Supervisor• manage the universes Auditor users use, through Designer• manage the set of predefined indicators, or special Auditor documents, and

optionally create new ones for use by other users in the company

It is also recommended that you build a separate repository for Auditor. For more information, see Deploying Auditor on page 411.

For complete information about administering Auditor, see the BusinessObjects Auditor Guide.


Command-line administration tools

Command-line administration tools

BusinessObjects 6.5 comes with two new command-line administration tools:• wasfadm• wresadm

You can find more information on these tools in the System Administrator’s Guide.

Managing the ASF with wasfadmYou can use the wasfadm command line for basic administration tasks concerning the cluster. The information that is returned, or the action that is performed depends on the option you use (-cluster, -node, -module, -stack or-pool).

EXAMPLE

Two example wasfadm command lines1. The command line

wasfadm -cluster

returns global information about the cluster, such as the number of nodes in it, the number of enabled/disabled nodes, the number of enabled/disabled modules, etc.

2. The command line wasfadm -node <nodename> -stop

stops the cluster server called <nodename>.

Managing Business Objects resources with wresadmWresadm is used to administer resources in the repository. Business Objects resources include documents, universes, stored procedures, domains, applications and connections.



Using wresadm, administrators can:• for a given actor (user, instance of a user or group), list the associated

resources and their status (enabled, disabled, inherited) • list the groups, users, and user instances associated with a given resource• associate/dissociate an actor and a resource• change the resource status for a given actor• delete resources

These operations can only be performed for instances, users and groups in the supervisor’s scope.

EXAMPLE

Two example wresadm command lines1. The command line

wresadm -u <username> -p <password> -t d -l

returns a list of all the documents in the repository2. The command line

wresadm -u <username> -p <password> -t d -d Report.rep ��-a Group1

disables access to the Report.rep document for Group1.

ch

ap

ter

The Repository and Security



OverviewThe 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• how you can work with or without a repository• compatibility issues you may encounter with this version of the repository

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.


Data security through the repository

Data security through the repository

Security is an increasingly important issue in today’s organizations. Implementing and maintaining security for a large number of users can be a costly operation, and has implications for long-term deployment requirements and user functionality.

Business Objects has placed equal importance on the ability to protect the security of data and on the empowerment of users to access, analyze and share it.

One of the main strengths of the Business Objects product suite is the range of security options and capabilities provided by the centralized repository. Because security can be applied within universes at the user and group levels, Business Objects can meet the security needs of most types of organizations.

NOTE

You may want to build on these basic security options by incorporating broader security measures such as firewalls, which filter the requests leaving and coming into your system from the outside.



Repository domains

The repository consists of several domains. Each repository includes one security domain, as well as one or more universe and document domains.

Figure 4-1 The repository

Each domain serves a specific purpose:• The security domain is the core of the repository and is used to store

information about users, the groups they belong to, the applications and features they can use, the universes they have access to, and the documents they have shared.

Repository

Corporate database

Designer(creates and manages universes)

Supervisor(creates and manages users and groups, granting access to universes, documents, applications, connections and all other resources)

Universe domain (semantic layer)

Scheduled document processing with Broadcast Agent

Users

Security domain

Document domain


Repository domains

• 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.



How clients access the repository

Business Objects clients make use of the repository’s security and resource-sharing features through two files:• The .key file• The .lsi file

The .key fileThe address of the security domain must be recognized by all clients using Business Objects products in online mode, so that users can communicate with the other domains of the repository in a transparent manner. This address is contained in the .key file, which is created in Windows when you use Supervisor to create the repository, or in UNIX, using the wmainkey script. You must distribute this file to all authorized users:• For BusinessObjects users in 2-tier deployments, administrators must copy

the appropriate .key file(s) to each workstation.• In 3-tier deployments, administrators create the .key file(s) on the Business

Object servers using Supervisor or the wmainkey utility.


How clients access the repository

Figure 4-2 Security through the repository

To access documents, at login users must select a repository to which they have been granted access (via a .key file), and must enter a valid user name and password.

User access to specific universes, objects, documents and data can be further restricted using Supervisor and Designer. For more information, see the Supervisor’s Guide and the Designer’s Guide.

NOTE

You can also use an LDAP directory for authentication. For more information, see the Installation and Configuration Guide.

Universe domain (semantic layer)

Controls access to universes

Controls access to universes

Document domain

Security domain

.key file



The .lsi fileThe .lsi (Local Security Information) file stores security information required to run Business Objects products without connecting to the repository (see page 121).

This information includes precalculated security attributes for a user or user group based on data taken from the repository when the user is working online. It is created the first time a user connects to the repository and is updated with each new session.

Session functional daemons obtain the security data for all but real-time users directly from the .lsi file. Because the .lsi file replaces the system’s need to connect to the repository when users log in, the entire login process is speeded up.

NOTE

In 5.x/2.x releases, this file was called objects.lsi or objects.ssi, depending on its location in the $INSTALLDIR\LocData or $INSTALLDIR\shData directory respectively.

Where are the .key, .rkey and .lsi files located?The supervisor creates the .key files in the $INSTALLDIR\locData (for local connections) for $INSTALLDIR\shData (for shared connections) directory.• For desktop products such as BusinessObjects in 2-tier mode, administrators:

- fetch .key files from these directories ($INSTALLDIR\locData and $INSTALLDIR\shData)- create .lsi (for all products) and .rkey files (for BusinessObjects in 3-tier mode only) in the $PROFILEDIR\Application Data\Business Objects\BusinessObjects Enterprise 6\lsi directory

• Server products use the $INSTALLDIR\nodes\<node name>\<cluster name>\locData directory for .key as well as .lsi files.

Administrators are still in charge of deploying .key files to all Business Objects cluster nodes.


Which components access the repository?

Which components access the repository?

The repository is the processing center of your deployment. It is in the repository domains that user access is secured, and shared universes and documents are stored.

Because of its central role in any deployment, the repository is integral to most of the product components, and is accessed by the following components:

Component Reason for accessing the repository

Administration Server Lets administrators manage users and groups, as well as user properties, such as changing passwords and enabling password modification, all of which is stored in the repository

Connection Server Provides connectivity to the repository for both WILoginServer and WebIntelligence queries

WILoginServer (via Connection Server)

At login, authenticates the user against the repository and creates the .lsi file using the precalculated data stored in its cache

WIQT • Handles many InfoView workflows, including retrieving WebIntelligence 2.x and third-party documents from the repository, and saving them to the repository

• Serves as the report engine for reports in WebIntelligence

• Processes all document exchanges with the repository for 3-tier deployments of BusinessObjects

BusObj.exe (Windows)/bolight (UNIX)

Handles the viewing and refreshing of BusinessObjects documents in the repository from the InfoView ActiveX viewer



Scheduler Scans the repository at regular intervals for scheduled tasks that are due to be executed

The Broadcast Agent Console

Manages and defines scheduled document processing tasks, storing this information in the repository

All desktop products 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.

Component Reason for accessing the repository


Using multiple repositories

Using multiple repositories

The larger your deployment, the more information must be channeled through one repository security domain. The risk of security domain bottlenecks has been considerably reduced with the use of WILoginServer. Nonetheless, the more users you have, the more useful it may be to provide two or more repositories, each with its own security domain, as well as a series of document and universe domains.

The use of multiple repository security domains can speed up network response times for BusinessObjects, since it circumvents the restrictions of a single security domain. If you have a large number of users based in different locations, it may be more efficient to divide them between two or more repositories, each with its own unique security domain. You can also create a series of document and universe domains.

Deploying multiple repositories can be particularly useful in international configurations, where you can considerably speed up your network response times. For example, rather than having a single, centralized repository located in Europe that serves large numbers of users in both Europe and North America, a second repository can be created in North America for those users, reducing network congestion for all.

Before setting up multiple repositories, however, understand that no interaction between repositories is supported, and therefore the domains in one repository can rapidly become desynchronized with those in another repository.

For more information, see Deploying and using multiple repositories on page 349.



The repository and your data warehouse

When you set up your Business Objects reporting environment, you deploy at least two databases:• the repository • your corporate database(s) or data warehouse(s)

When you first run Supervisor, you must select a database on which you will store your repository.

In some deployments, the repository will be created in the same relational database management system used to host the database. In other cases administrators will choose to develop their warehouse in one database while hosting their repository on another system.

For example, you could have:• A company that hosts both its corporate database and its repository in an

Oracle database (see Figure 4-3).• A company that hosts its corporate database in DB2 but chooses to host its

repository in a Sybase database (see Figure 4-4).• A company that hosts its repository in a DB2 database, with connections to

three different corporate databases based on different database types (see Figure 4-5).

• A company that hosts different parts of its repository (the security, document and universe domains) in separate databases, which connect to each other and to the corporate databases as required (see Figure 4-6).

These choices are left to the administrators responsible for the deployment, and are based on the requirements of the organization and the end users.

Figure 4-3 Both corporate database and repository in Oracle

Corporate databaseRepository Oracle


The repository and your data warehouse

Figure 4-4 Corporate database in DB2 but repository in Sybase

Figure 4-5 Repository in DB2, with different corporate databases

Figure 4-6 Different parts of the repository on different databases

Sybase DB2

-Security domain-Universe domain

-Document domain

Corporate database

Repository

DB2

Oracle

Informix

DB2

-Security domain-Universe domain

-Document domain

Corporate databases

Repository

Informix

Informix

Informix

Database1

Database2

Database3

Security domain

Document & universe domains

Document domain

Corporate databases

Repository



How do users access the repository?

Users are idenfitied and given access to the repository and its resources through authentication and authorization.

Authentication is the process of identifying an individual, usually based on a username and password. Authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity.

The Business Objects system administrator can apply authentication security in several ways, using the Security Configuration Tool:

Figure 4-7 Setting the authentication mode


How do users access the repository?

Mode In a 2-tier system In a 3-tier system

Business Objects The Business Objects system performs the entire authentication process. The 2 and 3-tier modes use the same user name and password. Authentication can be carried out:• by Business Objects, based on the repository• with LDAP• through SiteMinder

Windows-NTLM The user is authenticated on the Windows workstation and in the repository.

The user is authenticated by an IIS web server, using authentication information in the repository.

Single Sign-On (SSO) The workstation asks the SSO server to authenticate the user. The SSO system then returns the authentication ticket to the workstation.

The user is authenticated by the SSO server. After authentication, the server sends an authorization ticket to the web server, and the authentication ticket is checked again by Business Objects.

Basic authentication The Business Objects user name and password is required.

User authentication is delegated to the web server, which is trusted without being checked.

Business Objects verifies the user name, but not the password, in the repository.



Sources for authentication and authorizationTo authenticate a user, the system must check the username and password the user enters at login against the pre-registered authentication information required for access to the system.

As a Business Objects administrator, you can manage this type of user information by creating accounts for users in the repository, in an external application and/or directory such as Netegrity SiteMinder® or an LDAP (Lightweight Directory Access Protocol) directory, or a combination of these options. • Managing Business Objects user identities in an external user management

system like an LDAP directory allows you to store user information for all your enterprise applications—including the Business Objects suite—in a single corporate directory. This not only improves scalability and ease of administration of the Business Objects Business Intelligence suite, but it allows you to lighten the amount of information stored in the repository by storing it elsewhere.

• Using SiteMinder with the Business Objects system lets you enable SSO for Business Objects users, which means they need authenticate only once for subsequent access to multiple applications. Depending on how you configure SiteMinder, this can be when users enter the operating system, an enterprise portal, or elsewhere.SiteMinder is often deployed using an LDAP directory to store its authentication information.

A user who is declared by name outside the repository only is referred to as an externalized user.

When deploying the Business Objects system, carefully choose your system’s security mechanisms, bearing in mind the suitability and constraints of each security mechanism in terms of your particular deployment. The Installation and Configuration Guide provides you with this type of information.


Working with or without a repository

Working with or without a repository

You can work with BusinessObjects and Designer in two modes:• workgroup mode, where you work in an environment without a repository• enterprise mode, where you work with a repository

The mode in which you save your files determines whether other users are able to access them. By default, files are saved in the mode in which you are already working. For example, if you launched a session in enterprise mode, any file you save is automatically stored in that mode. However, if you want to make a document accessible to another user working without a repository, then you must check the Save for all users option in the Save as document dialog box.

Within enterprise mode, you can work in either of two modes:• online mode• offline mode

Online modeIn 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 modeIf 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.



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.


Repository compatibility issues

Repository compatibility issues

The version 6.x repository, with all its domains, is basically unchanged compared to 5.x. There are no new columns or tables, only new data (such as document types). This means that 2.x/5.x applications and a 2.x cluster (2.6 or later) can function with a 6.x repository.

The reverse, however, is not true: Version 6.x applications and a 6.x cluster cannot function with a 5.x repository. A version 6.x Supervisor and a 5.x Supervisor can function on the same machine. However, 6.x Supervisor cannot function on a 5.x repository, and versions from 5.1.5 on of Supervisor cannot function on a 6.x repository.

For more information, see Migrating from a Previous Version.

part

Planning your Deployment

ch

ap

ter

Deployment Considerations



OverviewThe 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 you’re 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.


Pre-deployment checklist

Pre-deployment checklist

Before you actually install the Business Objects software and set up your system, you should consider these fundamental deployment issues:❏ Who are your users?❏ What types of documents and other files will be processed?❏ How can you make data accessible to everyone?❏ How can you protect your system from unwanted intrusion, and how can you

confine access to sensitive data to specific users?❏ What types and configurations of servers are needed?❏ How can you distribute transaction loads across the 3-tier system to optimize

performance?❏ How can you plan for disaster recovery?❏ How can you acquire the technical expertise to deploy Business Objects

products?

The bottom lineIn any deployment environment, users will expect that the system:• be reliable, available whenever they need it• be secure• be easy to use

This is partly the responsibility of Business Objects, which with this release has endowed the system’s portal with a new interface designed to make its use simpler and more agreeable than ever. Your responsibility, however, is to keep the entire system as simple as possible (small, targeted universes, cell-named document categories, etc.), and to educate and progressively familiarize your users with the system so that they can get the most out of it as quickly as possible.

• that the system respond rapidly — if the system does not respond rapidly and reliably, users will simply not use it.

These expectations should drive the implementation.



Education: providing the tools to be successful

Any deployment requires particular baseline knowledge to be successful.

The development and IT team requires a collection of skills:• data warehouse expertise• Windows and/or UNIX administration expertise• generic Business Objects product and deployment knowledge• depending on the authentication/authorization schema you have chosen for

your deployment, additional expertize in LDAP and/or SSO

Don’t forget the users, however. No matter how technically fine-tuned a Business Objects deployment is, if the users are ignorant, or even hesitant about using the system, the implementation will take longer and be more costly. Involve user input from the beginning, and give users the knowledge they need to use the system comfortably and efficiently. The more they get out of using the system, the more they’ll use it.

Your deployment will involve two broad categories of users:• The minority will be a small set of power users, who actually create, edit, and

distribute the bulk of the system’s documents. These users will require WebIntelligence and/or BusinessObjects end user skills. To get them up and running most rapidly, training may be required.

• The great majority of users, however, will probably be using the system’s portal, InfoView, or the desktop BusinessObjects to view and refresh existing documents. These users will require less in-depth training. A good start would be having them use the multimedia tutorials BusinessObjects, WebIntelligence and InfoView Quick Tours, as well as the Getting Started manuals.


Performance: what is acceptable and how can you attain it?

Performance: what is acceptable and how can you attain it?

The first step in obtaining acceptable performance is actually defining the response times that are acceptable to your users. Performance requirements and even possibilities differ with each deployment, depending on specific user needs, geographical location and deployment configurations.

Once you have defined the performance goals for your specific deployment, you should identify factors in your particular deployment which may be affecting performance. They can include: • Hardware issues

Hardware issues include limited CPU, the speed and capacity of the disk subsystem, and available physical memory. Business Objects should be installed on dedicated server(s).

• Database issuesThe performance of the database can affect overall Business Objects performance. Factors that affect database performance include the physical distance between the Business Objects server and the data warehouse.

• Repository issuesThe size and complexity of the repository database structure affect performance.

• UsersFar beyond the simple number of registered users your system will support, you must consider the number of users actually consuming system resources at any given time. What are users doing? How, to what extent and when are they stressing the system?

• Network issuesThe network’s capacity (bandwidth, latency, delays and geography (LANs vs. WANs), as well as the tools it supports (routers, gateways and proxies) all impact the response times you can expect from your Business Objects system.

In short, every major parameter in your deployment has some impact on performance. These parameters are described in the following sections.



Server sizing: efficiently supporting peak user activity

How many server machines do you need for your deployment? You need to support not the average concurrent use, but the peak concurrent use. This can be up to 40% higher than average!• In a typical system, approximately 15% of the users are logged in at any one

time• 15% of these users are actually using the system’s resources

You need to identify how the users are using the system:• What percentage of processed documents will be WebIntelligence reports?• What percentage will be BusinessObjects documents?• What percentage will be other types of files?• What percentage will have interactive refresh capabilities for WebIntelligence

and BusinessObjects documents?

There are so many variables in this type of system fine-tuning that you can determine what server configuration best supports your end-user population only by trial and error.

Capacity planningCapacity 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 system’s 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 configuration

Deployment configuration

Which deployment configuration is best suited to your organization’s needs? What types of deployment configurations are possible given your organization’s 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 deployment’s 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 full- client 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 183.

Cluster and repository architectureDo your goals require single or multiple clusters? More than one repository? Where should they be located? These concerns are addressed in Modeling your System on page 147.



Data management: making data accessible

Typically, a common goal with a 3-tier deployment is for everyone in the organization to gain access to data, from top to bottom. In order to meet all your organization’s data access needs with one system, the system must be easy to use:• Universe design must be simple. Each universe object must justify its place

in the universe relative to the other objects, so each object must be ultimately linked logically, or in some sense understandable to the user, to all the other objects.

• In general, a universe built against a data warehouse/data mart is easier to use than a universe built against an On-Line Transaction Processing (OLTP) database.

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

You should verify the maximum number of open connections with your database vendors.

What is your company’s geographical distribution?Are you deploying on a worldwide basis, or locally within a geographically confined area? “Universal” data access also means lots of data movement and data being distributed around the organization.

In geographically distributed deployments, you also need to strategically locate data warehouses, system clusters, and the repository so that they’re closest to the heaviest transaction loads. You will also need to decide whether you need more than one of each.

For more information, see Modeling your System on page 147.


Protecting your system and your resources

Protecting your system and your resources

It is important to be able to share valuable information. It is just as important, however, to keep this information safe from unwanted access and intrusion.

You will need to develop a solid security strategy to protect your system and the resources within it.

Allowing users accessUser authentication is the process of identifying an individual, usually based on a username and password.

Authorization represents the subsequent process of giving individuals access to system resources based on their identity.

Within the Business Objects solution, Supervisor manages the major part of this type of security. It allows you to control when and how users can access, analyze and share data through object- and row-level security, table mapping, and block- and section-level security.

You can also restrict user rights on the corporate database.

Protecting against attackNetwork security involves the TCP/IP protocol layer, communication with the web and application servers, and the transmission of data packets between clients and servers. Application security, or secure communication between application modules, involves applications protocol and communication between servers.

Measures you should consider for this type of security include:• Network security options• SSL• Firewalls and DMZ configurations• Reverse proxies



Users: know their numbers, profiles, groups and rights

You need to know how many users you will be supporting, as well as the type of users, and their particular requirements.

You also need to identify which users will have access to which services (document creation, document viewing, data analysis, web access), as well as the users’ hierarchical levels (general supervisors, supervisors, designers, users, etc.).

Types of usersThe 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.

• InteractiveThe 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.



• AnalystThe 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.

• AdvancedThe 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

Here’s 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.

Figure 5-1 Typical proportions of user types in a Business Objects deployment

Power users

Analysts

Readers and Interactive users combined



User activityThe 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 system’s 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.



��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.

Business Objects 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.



Documents: what type, how complex?

The Business Objects system provides full processing of two types of documents:• BusinessObjects documents• WebIntelligence reports

There are different advantages in using each type of document within each environment. After reviewing the differences between the two types of documents, you can decide what deployment is best suited to your users’ needs.

REMINDER

The Business Objects system can provide access to all types of files, and allow users to upload, download, send and save them. These files cannot, however, be edited or scheduled.

Business Objects documents vs. WebIntelligence reportsThe most significant difference between BusinessObjects and WebIntelligence documents is that BusinessObjects documents can be much more complex than WebIntelligence reports due to additional reporting features in the BusinessObjects application. WebIntelligence reports, however, can allow for much larger deployments.

Size of documentsThe 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.

Number of documentsThe 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.


Load balancing: matching system processes and server resources

Load balancing: matching system processes and server resources

One of the greatest advantages of a distributed architecture is the capacity to distribute system transactions over several — and indeed, increasing numbers of — servers. When you’re setting up your system, you need to decide exactly how you are going to share the transaction load.

You can balance loads over servers by strategically distributing high-traffic system modules (or processes) across several machines, or in some cases, by directing a greater proportion of transactions to higher-capacity servers.

You can dedicate certain servers to a single type of process, or provide for several types of processing on several servers.

For more detailed information, see the System Administrator’s Guide.



Disaster recovery: what can you do about it?

Throughout your pilot project and your production deployment, you must be able to identify potential critical points of failure:• the repository• the data warehouse• the cluster’s primary node

You also need to have a plan for failure recovery. For example, you might use a multiple cluster deployment, so that if one cluster goes down, the other cluster can take over.

IP redirectors are often used to load-balance TCP traffic across multiple servers by receiving user requests then redispatching them to different web servers. They can also provide failover in the event that one server goes down. For more information, see page 214.


Deployment procedure

Deployment procedure

All business intelligence solutions need careful planning, execution and management. 3-tier solutions are especially complex, but as they typically service must larger user populations, they require less deployment and maintenance time per user.

Launching your pilot projectIf you are planning a large deployment, set up a pilot project first. The pilot project should be as representative as possible of your entire project, and should be tested before investing time and resources in an actual production project.

A pilot project will allow you to test and tune your deployment, and to iron out any configuration and operational problems that arise from your particular setup and chosen tools. Based on this feedback, you can then realistically plan your actual deployment.

Use BusinessObjects Auditor for tracking and analyzing how users are using your system, what the server load is at peak times etc., as it will help you monitor and analyze your Business Objects deployment.

For more information on development lifecycle environments and the migration to a full-scale production environment, see From Development to Production on page 239.

Bring in Business Objects expertiseWeb-based delivery is still a relatively new approach. Business Objects offers a complete range of support and services to ensure you the maximum business benefit from your business intelligence deployment. A global network of Business Objects and business intelligence technology experts provides customer support, education, and consulting that can be tailored to fit the needs of any organization.



��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.


Conclusion

Conclusion

Virtually no organization’s needs remain frozen. User populations expand, evolve, or relocate. Technology continues its steady advance, and just as steadily, users demand more out of a system’s performance. Your organization may decide to port to UNIX, or extend its reach across the web via an extranet.

No matter how carefully you’ve 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 don’t hesitate to bring in the expertise you need, when you need it.

ch

ap

ter

Modeling your System



OverviewDeploying 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 population’s requirements. What is your company’s 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 system’s operating system• Selecting your system’s 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.


Designing your architecture


What do you want the architecture you choose for your Business Objects solution to deliver? Some of the principal goals on which you might focus include:• Ease of management and ongoing maintenance• Acceptable performance• Failover and redundancy• Round-the-clock operation

In small deployments, architecture concerns are relatively simple. In these deployments, a small user population often works out of a single physical site, and a simple, centralized deployment architecture may be the optimal solution, with a single repository and corporate data source deployed on a single network.

Bigger deployments, however, can serve thousands of users scattered over multiple sites around the globe. Geographically-distributed deployments have a host of constraints of their own. These configurations often span time zones and languages, involve multiple networks and can serve thousands of users scattered over several physical sites.

In these situations, designing your system’s architecture for optimal use will require juggling a host of parameters, unique to each situation and ever-evolving.

Key factors in architecture designHere are some key questions you’ll need to answer before making any architecture decisions:• Where are your users physically located?• What are the usage profile(s) that represent the key user “service level”

response time?• How do you envision the users will use the system? Ad hoc, report

consumers, extranet, intranet?• Where is the data that is required to support the queries in this profile(s)? Do

you have a single data warehouse and/or do all sites have their own data? Do you replicate data to local areas?



• What is the bandwidth of the network connecting the users to the Business Objects server, and the Business Objects server to the data source? Given this bandwidth, what is the optimal configuration for moving required data?

• Will Broadcast Agent be used as a way to pre-generate documents, and thereby leverage off-peak CPU time?

• Are you delivering cross-corporate information to all sites, or to some sites only?

Information you must have before determining your architectureYou should have the following information on hand in order to define the scope of your global Business Objects deployment strategy:

Database or data warehouse

Database engine and version

Network location

Repository database (network locations)

Security domain

Universe domains

Document domains

Redundancy and failover?

Business Objects products

InfoView/WebIntelligence?

BusinessObjects?

Broadcast Agent Publisher?

Server location (network)

Network access

Bandwidth of each network •••

Web server load balancing? Ifso, what hardware is being

used?

WAN vs. Dialup access



Server hardware on each server

Memory

CPU

Disk access:

--Speed

--Failover RAID?

Shared storage device? (Will itcope with the load?)

Network Interface Cards (NICs)

Security and authentication

Firewalls

Is Single Sign On arequirement?

BusinessObjects documents

% of all documents beingprocessed

Number

Average size

Average number of rows

Average number of tabs

WebIntelligence reports

% of all reports being processed

Number

Average size

Average number of rows

Users

Total user population(registered users)

Number of users on Network1





% 2-tier BusinessObjects users

% InfoView users

Maximum % active users

Maximum % concurrent users

Document scheduling

Number of scheduleddocuments

How often?

What time of day should tasksbe run?

Refresh-time window thedatabase is available for batch

processing (How long doeseach job take on average? If you

are priming the cache withHTML, this will increase the

duration of the job.)


Selecting your system’s software

Selecting your system’s software

The functional infrastructure of the operating environment in which you run your Business Objects system is determined by the software of which it is composed.

To help you to use Business Objects products in optimal conditions, Business Objects has defined a set of stacks, or sets of third-party software with which the Business Objects system will interact optimally, in specific sets and combinations. Each stack includes the server’s operating system, the database and the language being used, along with other components like supported web and application servers and middleware.

Particular combinations and versions of all the other components that make up the solution’s operating environment are supported to run with each of these operating systems.

You can find up-to-date, more detailed information about each of these stacks (such as exact version and Service Pack numbers) in the PAR.

The PARThe 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

http://www.techsupport.businessobjects.com/Platforms/BusinessIntelligence65_RTM.asp

It contains the most up-to-date information concerning:• language support• platform support• third-party support (third-party applications that can be used with Business

Objects, like web and application servers)• web browser support

Before making any decisions about the software you will use as the infrastructure for your Business Objects system, check with the PAR or your local Business Office sales office.




Selecting your system’s operating system

Business Objects supports Windows or UNIX platforms for its server products. The operating system you choose depends on the size and complexity of your deployment and the characteristics of the operating systems themselves.

UNIXOrganizations need robust, dependable servers — servers that crash rarely, and that don’t 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 easy-to-use interface that are the hallmarks of Business Objects software.

UNIX machines running Business Objects server products can be configured as part of a cluster that includes Windows machines. This type of cluster is called a heterogeneous cluster.

You can perform almost all tasks on UNIX clusters. There are, however, some restrictions. See page 155.

NOTE

Users may encounter problems when viewing, editing or sharing documents containing OLE 2 objects, using a Business Objects server on UNIX.



Here’s a summary of some of the advantages and disadvantages of using a UNIX system:

WindowsParticularly adapted for smaller deployments, Windows systems have the advantage of supporting the full set of Business Objects products and functionality.

Here’s a summary of some of the advantages and disadvantages of using a Windows system:

When do you need a Windows cluster?Some tasks or task aspects must still be run on Windows servers:• All processing involving OLAP data sources• Visual Basic procedures• Personal data files, including XML data providers• Custom macros for Broadcast Agent tasks• All processing requiring stored procedures• All processing requiring Free Hand SQL

Also, some connectivities are not available on UNIX, such as all OLAP, Microsoft SQL Server and others.

Pros Cons

More scalable, better security No VBA macros in Broadcast Agent

Supported to install databases and all Business Objects components on one big UNIX server

Pros Cons

Local Java Administrator Console applet

You need good understanding of COM/DCOM

Lower hardware and software costs than UNIX

Security issues, hackers target Windows IIS servers

Windows ease-of-use



What administrative functions require a Windows machine?Administrative functions belong to two broad categories:• those pertaining to the overall Business Objects solution• those pertaining to the 3-tier architecture in itself, such as running Broadcast

Agent and/or InfoView

��Business Objects system administration

Under UNIX, the Administration Console is a web application displayed using a browser. Even if the application server hosting the Administration Console is located on UNIX, you need a Windows machine to run the browser.

Business Objects does not support UNIX for Supervisor or Designer. Therefore, you need a Windows machine to:• create and manage the Business Objects repository• create and manage users and user groups (although you can also create a

customized application using the Administration SDK to handle this)• define database connections• create, manage, import and export universes• define fundamental Broadcast Agent criteria, such as the Broadcast Agent’s

user name and password, the groups to which each Broadcast Agent is assigned, and the document domain and channels it uses



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:

Figure 6-1 Administration products on Windows machines outside cluster

Some of these administrative definitions are stored in the repository, where the nodes in your cluster(s) can access them. Others, such as settings defined using the Administration Console and the Configuration Tool are stored on the server.

��Monitoring Broadcast Agent and the Business Objects system

Broadcast Agent administrators and users use the Broadcast Agent Console to track and modify the scheduled processing of documents.

If you are running Broadcast Agent under Windows, you can run the Broadcast Agent Console on the Broadcast Agent server itself, in addition to running it remotely from a client machine.

If you are using UNIX for your Broadcast Agent server, then you cannot run the Broadcast Agent Console on the UNIX machine but must instead run it remotely.

Client machines of 3-tier system

Application server

Clientadministration

machines(Supervisor,

Designer)

Business-Objects,

Business-Query users

Web server

Primary nodeDatabase

Repository

Cluster



��OLE 2 objects and UNIX

OLE 2 objects are specific Microsoft objects. Consequently, users may encounter problems when viewing, editing or sharing documents containing OLE 2 objects, using a Business Objects server on UNIX.

To insert a logo or other image in a document, then share that document via server products installed on UNIX, users can save the image as a bitmap (.bmp). You can do this in Microsoft Paint or a similar application.

Are mixed Windows/UNIX clusters supported?BusinessObjects 6.5 supports mixed-platform clusters, known as heterogeneous clusters. This means that the cluster contains both UNIX and Windows servers.

A UNIX cluster which uses Windows machines for administrative purposes (the use of Supervisor and Designer, for example) is not considered a heterogeneous cluster.


Deployment models

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:

In these deployment models, the proportion of each of the four user profiles (see page 136) typically evolves as the deployment grows:

Deployment model

Registered users

Documents accessible for each user

Size/complexity of documents

Small 500 100 Small/simple

Medium/fairly complex

Medium 5000 500 Medium/fairly

Large/highly complex

Large Over 5000 500 Medium/fairly

Large/highly complex



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.

Deployment model

% Power users

%

Analysts

%

Interactive users

%

Passive readers

Small 10 15 50 25

Medium 5 15 35 45

Large 5 10 25 60


Cluster architecture


Cluster architecture has to do with the number of servers you include in each cluster, and the number of clusters you use in your overall Business Objects system.

The servers belonging to any cluster must always be at the same physical site, sharing the same network segment.

Additional secondary or additional primary node?Each cluster you deploy must have one (and only one) primary node. When the demand on the system requires extra processing power, you can add as many servers as you require. You can add additional nodes to your system in two different ways, however:• by adding a secondary node to an existing cluster• by creating an additional primary node, thereby creating a new cluster• by adding a client node to the existing cluster

This is only applicable for JSP deployments, as with ASP you cannot split the web and application servers. If, for example, you were running the application server on the same machine as a Business Objects server, you could move the application server onto a dedicated machine.In JSP configurations, you could also separate the web server from the application server.

When should you do what?Certain obligatory processes must be running in any active cluster. These include the CORBA and ASF processes required for communication between the cluster servers, and with the other components in the Business Objects system.

WIStorageManager, WISiteLog and WILoginServer must be enabled on the primary node.

The Session Stack must be enabled on any node which will be processing documents or document lists.

If you add another primary node to your system (and thereby create a new cluster), you will be duplicating these processes; as these processes are already running in the initial cluster, you may not actually need them for handling transactions. In this instance, you may therefore be consuming system resources needlessly.



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 server’s 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:

Figure 6-2 Processing power vs. number of nodes in a Windows cluster

The additional processing power added by each new machine decreases as the number of nodes in the cluster increases. Why?• Some processes exist only once in the cluster.• A certain amount of communication, such as CORBA, needs to occur within

the cluster under any circumstances, and this takes up processing/resources.

Number of machines in a cluster

Processing power Theoretical results

Experienced results



The combination of these factors means that there is a point at which it is better to have multiple clusters than one.

Generally speaking, a Windows cluster should not contain more than four or five servers. After the addition of two or three secondary nodes, you should use benchmarking tests to determine whether the amount of extra processing power a new node will procure is still greater than the power brought by the addition of an entire new cluster. You can measure processing power through a comparison of response times.

NOTE

When using powerful machines like UNIX servers, you will probably gain more processing power per machine by adding additional primary nodes.

When should you use multiple clusters?In general, having multiple clusters increases:• failover capability• scalability (multiple WISessionManager processes, and so forth)

Here are some specific circumstances in which this may be particularly appropriate:• When too many users spoil a cluster’s performance• When you want failover capacities for a primary node• When you want Broadcast Agent failure recovery• When your deployment is geographically distributed• When you are using multiple repositories

Although a server in one cluster cannot interact directly with a server from a different cluster, it can exchange information through:• the repository, which can be linked to all of the configured clusters• shared storage (personal documents, MyInfoView settings, corporate

document caches, etc.)

��When too many users spoil a cluster’s performance

You should deploy multiple clusters if you have a large number of users that you want to break down into smaller groups, each with an individual primary node to improve performance.

Each of these clusters will then be sized as though it were a standalone cluster, with its own user group. All users can still access the same repository, and can exchange documents in the usual way.



��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 cluster’s clients is theoretically irrelevant, response times are better when clients are geographically close to the servers processing their requests.

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 node’s default language during the node installation. You can change these settings from the Site Properties page in the Administration Console.

NOTE

Users can now 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 application’s Options dialog box.

The language selected by the user therefore overrides the cluster language.



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.



Repository architecture

Each repository contains a single security domain, as well as one or more document and universe domains.

Repository architecture concerns how many of each type of domain are deployed and where they are located, as well as how many repositories you are using in the overall deployment.

When should you use multiple repositories?A multi-cluster configuration allows a given user population to access a different cluster to speed up login time or better manage network traffic. Users are divided into sub-groups and a cluster is dedicated to each of these sub-groups. To select the security domain they want to use, users simply point their browsers to the cluster connected to the appropriate repository. This is the equivalent of what is called security domain selection in BusinessObjects.

Figure 6-3 Choosing the security domain from BusinessObjects (3-tier)

This is particularly useful in international configurations. For example, rather than having a single, centralized repository located in New York serving large numbers of users in the United States and Europe, you can create a second repository and cluster in Europe for European users. This not only speeds up response times dramatically for European users, but reduces the network congestion experienced by all users.


Repository architecture

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 349.

For more information, see Deploying and using multiple repositories on page 349.

When should you use multiple document/universe domains?It makes sense to use multiple document and/or universe domains in the following situations:• To manage different versions of your documents and universes. Almost every

deployment involves creating different sets of domains: one set for development, one for testing, one for user acceptance testing, one for production. This enables you to migrate universes and documents from one set of domains to another in a controlled and mature way.

• When the sheer quantity of documents being processed by the deployment demands their organization into separate domains

• When you have a medium or large deployment in which users at multiple physical sites share the same repositoryFor example, a company whose headquarters is located in San Jose, California, has two subsidiaries, one in Paris, and one in London.



Database and repository location

Business Objects server products are very network-dependent. If they are run on poor networks, their performance will be poor as well, whereas good networking can result in excellent response times.

The two major processing/data interactions in Business Objects are: • The login process and repository access for shared resources• Querying the corporate databases to generate document lists or refresh the

data in existing documents

The location of the various repository domains and corporate databases or data warehouses is a strategic factor in any deployment’s performance, especially in geographically-distributed deployments. The golden rule? The closer the repository domain/database is to the Business Objects processing layer, the less traffic in the cluster, and the faster the response time.

Where should the repository be locatedNetwork traffic related to the security domain is reduced by the WILoginServer process, which handles authentication/authorization for the Administration Console, Administration Server, InfoView and 3-tier deployments of BusinessObjects.

At system startup, WILoginServer retrieves the authorization information for all users from the security domain, precalculates a security model, then stores it in a system cache. When users log in, the more complex calculation of each user’s access rights, which used to consume valuable processing time and network bandwidth, is now computed by WILoginServer from the system cache, then copied to disk, where each user’s WIQT fetches it.


Database and repository location

WILoginServer periodically re-contacts the repository to refresh and recalculate the information in its cache to remain as synchronized as possible with any security domain updates. This period is set in the Administration Console:

Figure 6-4 Setting the WILoginServer refresh period

If too many users are logging in at once, however, this mechanism in itself cannot prevent login bottlenecks. Repository access for both logging in and sharing resources such as universes and documents remains a potential major bottleneck.

The repository should be located as geographically close to the Business Objects server(s) as possible.

Where should your database be located? The database or data warehouse containing your corporate data should be located near the cluster using it.



Centralized or decentralized architecture?

Business Objects system and repository architecture can fall into centralized or decentralized configurations.

This section uses a fictional company with a medium-sized Business Objects deployment to illustrate the advantages and disadvantages of using a centralized architecture with a large, centrally-located cluster or clusters, and a decentralized architecture with smaller clusters located at various sites.

Background information about the example company The company’s environment consists of a standard 2-tier environment with BusinessObjects, as well as a 3-tier environment hosting InfoView, WebIntelligence and Broadcast Agent.

The total number of Business Objects users is approximately 700, with an estimated:• 350 users in corporate headquarters (USA1)• 225 in the United Kingdom (UK1)• remaining 125 users spread out over Australia (Australia1) and the other two

US sites (USA2, and USA3)

The company’s goals in designing its architectureThe company’s top priorities are:• Information delivery to all sites• Built-in redundancy• Failover• 24 x 7 operation

Scenario 1: Centralized architecture

This section illustrates two centralized solutions:• Centralized architecture with a single cluster• Centralized architecture with multiple clusters

Cost Performance

Least OK



��Centralized architecture with a single cluster

Figure 6-5 Centralized architecture with a single cluster

In this centralized Business Objects architecture, a single cluster is located on the USA1 network. The three repository domains (security, universe and document) and the data warehouse are also located on the USA1 network.

To optimize performance, the cluster should always be as geographically close as possible to the repository and data storage. The cluster was therefore deployed on this network as the data source(s) being used are all located on this network. The repository was also placed here for the same reasons.

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.

LAN/WAN

USA1

Secondary node

Secondary node/BCA

Primary node/Web server/Application server

Repository with security, universe and document domains

Data warehouse

USA

USA1

UK

Australia

Users

Users

Users

Cluster



How this scenario works1. 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 user’s .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.



Advantages and disadvantages

Advantages Disadvantages

Less total administrative staff translates into less cost.

Login can be slower for users who are not in corporate headquarters but how slow really depends on the network bandwidth of your WAN.

Centralized security management ensures the implementation of uniform standards and better control over access to information.

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.

There is a local performance gain from placing the repository and data warehouse close to the Business Objects servers.

New user setup, and modifications to user privileges, can require additional administrative time and delays for local users.

This solution requires 24x7 support.



��Centralized architecture with multiple clusters

Figure 6-6 Centralized architecture with failover

This scenario uses two clusters for failover and an IP redirector for distributing network traffic.

The Business Objects clusters A and B are deployed on the USA1 network, because this is where the data source(s) and repository are located.

Secondary node

Secondary node/BCA

Secondary node/BCA

Secondary node/BCA



IP redirector

Shared storage

Repository with security, universe and document domains

Data warehouse

General supervisor Designer

USA1

USA

UK

Australia

Users

Users

Users

LAN/WAN

ClusterA

ClusterB



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.

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 off-hours; during the daytime it serves as a standard interactive processing node.

How this scenario works1. 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 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 security domain in the centralized repository in USA1, but the actual calculation of each user’s .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-6 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.

For performance reasons, you may want to store the system's cache, temporary and personal documents etc. on a separate machine (you may want to replicate this file server to provide true failover).

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.

��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:

Scenario 2: Decentralized architecture with centralized security domain

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.


Complete cluster failover with the use of an IP redirector

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

Cost Performance

Moderate Moderate



Figure 6-7 Decentralized architecture with centralized security domain

LAN/WAN

ClusterB

ClusterC ClusterD

Secondary node

Secondary node/BCA

Primary node

IP redirector

Shared storage

Secondary node/BCA

Secondary node

Primary node

Repository with centralized security domain, plus universe domain and document domain

Data warehouse

Secondary node/BCA

Secondary node/BCA

Secondary node

Primary node

Primarynode

Secondary node

Local supervisorand designer

Local document and universe domains

Local supervisor and designer

Local document anduniverse domains

Local DB

Local DB

Local supervisorDesigner

USA1

UK Australia

ClusterA



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 works1. 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.



��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 user-based 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.





Corporate documents open quickly because they are stored locally and users don’t need to go across the WAN to get the information.

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 generation of local documents.

If the WAN is down, the security domain can be inaccessible to remote users. Users of BusinessObjects in 2-tier mode, however, could use off-line mode for the analysis of existing documents.

The Business Objects system can be more easily customized to meet the needs of a targeted user community or site (albeit with high maintenance)

The distribution of standard documents to remote users relies on the WAN.

Centralized security management ensures implementation of uniform standards and better control over access to information.

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.

Access to universe and document domains is less reliant on the WAN’s performance.

There are potentially increased costs due to additional support resources required at each site.



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.

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.

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 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 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.

If you centralize Broadcast Agent, you gain time to refresh the document and easier administration, but you don’t obtain performance improvements.




Global deployment scenario summary

Scenario 1 Scenario 2

Architecture Centralized Decentralized

Repository Centralized • Decentralized universe and document domains

• Centralized security domain

Data Centralized • Decentralized local data• Centralized corporate

data

Distribution Publish to central repository • Decentralized local data• Centralized corporate

data

Cost Least Moderate

Performance OK Moderate

Advantages • Less administration and deployment cost

• Centralized security

• Quick response• Access to universe and

document domains less reliant on WAN

• Customized Business Objects system for local sites

Disadvantages • Performance adversely effected by network traffic

• If WAN is down, remote users cannot access system

• Login times adversely effected due to WAN

• If WAN is down, remote users cannot log in

• Distribution of new documents relies on WAN

ch

ap

ter

Supported Deployment Configurations



OverviewThis 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:• Basic 2-tier deployments• Citrix configurations• 3-tier architecture overview• Combined 2- and 3-tier deployments• Basic intranet deployments• DMZ configurations• Extranet deployments• Deported application servers• Reverse proxies• IP redirectors• Multiple clusters in an intranet• Single-cluster intranet/extranet deployment options• Multiple-instance servers under UNIX• Multilingual configurations using Unicode• Heterogeneous clusters

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 you’ll 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 234.


What this chapter does not provideThis chapter neither describes these configurations in detail, nor tells you how to implement them. For more detailed information and concrete implementation instructions, see Chapter 10.



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 Description


Cluster server on which Business Objects server components are installed.

Distributed system A Business Objects cluster in which processing is distributed over more than one machine.

Intranet An intranet is a corporation’s private internal network. The main purpose of this network is to share company information and resources among employees.

Extranet 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.

DMZ A DMZ (DeMilitarized Zone) is a buffer zone between two firewalls. It creates a neutral zone between a company’s 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.


Terminology

IP redirector 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 CCS (Content Services Switch).

Proxy server 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.

Reverse proxy A reverse proxy deals with internal servers on behalf of external clients.

Term Description



Basic 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 and more powerful document design capabilities.

Figure 7-1 2-tier configuration

In a small deployment, the 2-tier architecture is more advantageous because it provides the most stable environment and fast and reliable service for your users. An additional benefit of having all components running on a single server is that you have only one server machine to maintain and there is less impact on the network bandwidth.

The disadvantage of this kind of deployment, however, is that if your company grows rapidly, you will not be able to expand your network easily. As the number of users increases, performance will diminish and your system will be harder to maintain.

If you start off with a small company with the intention of growing within the near future, you should consider a combined 2- and 3-tier architecture.

Database

Repository

Client machines BusinessObjects in 2-tier mode)


(Broadcast Agent)


Basic 2-tier deployments

Deployment profile

Deployment Type

Pros Cons

2-tier • Simple maintenance• High performance• Reliable service

• Difficult to expand• Performance diminishes

with network expansion



Citrix configurations

Citrix provides companies with a way to securely deploy, manage and access business-critical applications throughout the enterprise — regardless of the client’s device or network connection. It brings server-based computing to heterogeneous computing environments, and allows company IT professionals to scale, deploy, and support applications from a single location. For more information, see www.citrix.com.

You can use Citrix in Windows operating systems to deploy the following 2-tier products from Business Objects: • Supervisor• Designer• BusinessObjects• BusinessQuery

In this deployment configuration, the Business Objects software’s interface is on the client PC, but the processes actually run on the Citrix Metaframe Server. You need to install the applications only once, and they will run on all the client machines you require.

This configuration allows for:• the redirection of serial ports and printers• easy maintenance for your user population

Deployment schemaThe clients can run on any Citrix-supported operating system. All client requests are directed to the Citrix Metaframe server, which access the repository and corporate database(s) and processes requests.

www.citrix.com

www.citrix.com


Citrix configurations

Figure 7-2 Citrix configuration

For concrete deployment instructionsSee page 294.

Deployment profile

Clients using Supervisor Designer BusinessObjects BusinessQuery

Citrix Metaframe Server

Corporate database

Windows

Repository

UNIX

Macintosh

Deployment Type Pros Cons

Citrix • Easy deployment and maintenance (you only install on one machine)

• Redirection of serial ports and printers

Requires a powerful server, depending on the number of clients




Most enterprises today make use of 3-tier architecture deployments, taking into consideration the growing need to deploy business intelligence to the enterprise (intranet) and corporate customers (extranet).

3-tier architecture deployments allow for much larger deployments because components that are distributed over several servers optimize the use of the different server resources, thereby reducing the workload on the web server, and enhancing performance.

In addition, UNIX operating systems are supported for this type of architecture.

The following sections will help you understand Business Objects 3-tier deployment configurations. The list is not exhaustive, but it does represent some of the most common scenarios supported by Business Objects today.

REMINDER

These scenarios are not all mutually exclusive. Many of them in fact require components discussed in scenarios of their own. All extranet deployments, for example, make use of DMZ configurations, and several scenarios require the use of IP redirectors.

• Combined 2- and 3-tier deployments• Basic intranet deployments• Extranet deployments• DMZ configurations• Reverse proxies• IP redirectors• Multiple clusters in an intranet• Single-cluster intranet/extranet deployment options

- Single web server for intranet and extranet users- Multiple web servers within one cluster

• Multiple-instance servers under UNIX• Multihomed configurations• Multilingual configurations using Unicode• Heterogeneous clusters


Combined 2- and 3-tier deployments

Combined 2- and 3-tier deployments

In this scenario, you can combine a 2-tier environment with a 3-tier architecture deployment to give you the best of both worlds: client/server network stability and the flexibility of a 3-tier deployment.

Figure 7-3 Combined client/server and n-tier architecture deployment

In a combined environment therefore, your employees benefit from the 2-tier version of BusinessObjects and Broadcast Agent, yet can also take advantage of Business Objects server products, as long as your client machines are connected to the internal network.

In a 3-tier architecture deployment, the web server and the Business Objects software are most often installed on two different servers, with the web server hosted in a DMZ between two firewalls, and the Business Objects server behind the second firewall inside the company’s 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.

External users

Application server

Secondary node 1

Secondary node 2

BusinessObjects users

Client admin

machine

Primary node Database

Repository

Cluster

Web server



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


Combined 2- and 3-tier architecture

• Network stability• Simple maintenance• High performance• Reliable service• Scalability

Business Objects system administration more complex


Basic intranet deployments

Basic intranet deployments

An intranet is a company’s internal network based on TCP. Via an intranet company employees use Business Objects products to create, view, and share Business Objects documents and third-party files.

This represents the minimal, no-frills Business Objects 3-tier deployment.

Deployment schema

Figure 7-4 Basic intranet deployment


Application server

Secondary node 2Secondary

node 1

Client admin

machine

2-tier BusinessObjects users

Web server

Primary node

Database

Repository

Intranet



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

For more informationSee page 298.


Basic intranet Simple to deploy and administer

No extra security, failover or load-balancing mechanisms


DMZ configurations

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 299.



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.

Figure 7-5 Typical DMZ configuration

Communication through firewallsAll communication through firewalls uses the CORBA communication standard. In CORBA:• Servers host objects and expose them through the naming, trading and

locator services.• Clients access objects through remote method invocation mechanisms, via

the IIOP protocol.

Client users

Application server

Primary node

Corporate database

Repository

Network

Web server


DMZ configurations

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).

This type of configuration uses two types of communication protocols to traverse the two firewalls:• HTTP• TCP

Figure 7-6 Communication protocols in a DMZ configuration

The outer firewall, next to the external network or Internet, allows HTTP communication between the clients and the web server (and through it, the Business Objects cluster), by default through port 80. The connector on the application server machines is in charge of tunnelling the communication with the cluster.

The inner firewall, next to the intranet, allows TCP traffic in both directions through the ports that the web server(s) and the application server are using to communicate.

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).

External network or Internet

Outer firewall

Inner firewall

Primary node

Secondary nodeApplication server

HTTP TCP

Intranet



Deployment schema

Figure 7-7 Typical DMZ topology

• Client machines on the Internet can be the clients for Business Objects server products. 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.

ConstraintsIn 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.


Database

Client users

Application server

Secondary node

Secondary node

Primary node

Repository

Intranet

Web server


DMZ configurations

Deployment profile



DMZ configuration • Simple to deploy and administer

• Cheap• Easy to maintain



Extranet deployments

An extranet is a private network that uses the Internet protocol and the public telecommunication system to securely share part of a company’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.

With extranets, the Internet can provide a way to do business with other companies (business to business, or B2B) as well as to sell products to customers.

Extranets require security and privacy. These require firewall server management, the use of digital certificates or similar means of user authentication, encryption of messages, and the use of virtual private networks (VPN) that tunnel through the public network.

Companies can use an extranet to: • exchange large volumes of data using Electronic Data Interchange (EDI) • share product catalogs exclusively with wholesalers or partners • collaborate with other companies on joint development efforts • jointly develop and use training programs with other companies • provide or access services provided by one company to a group of other

companies, such as an online banking application managed by one company on behalf of affiliated banks

• share news of common interest exclusively with partner companies



Deployment schema

Figure 7-8 Basic extranet deployment

The typical deployment strategy is:• The web server and the Business Objects processing layer are hosted on two

different servers.• The web server(s) are hosted in a DMZ between two firewalls.• If you are not using Microsoft IIS, you need a third-party connector linking the

web and application servers.• The Business Objects server is hosted behind the inner firewall inside the

company’s 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.

Using the same principles, you can also use the following types of configurations:• Single web server pointing to single primary node, often used for multiple-

cluster deployments• Multiple web servers pointing to single primary node


Database

Client users

Application server

Secondary node

Secondary node

Primary node

Repository

Intranet

Web server



In both of these scenarios, the web servers are installed in the DMZ with an IP redirector to balance the load between them, and therefore between clusters (see IP redirectors on page 214).

You can also provide additional security for your extranet deployment by placing a firewall between the application server and the cluster in what is called a deported application server configuration. For more information, see Deported application servers on page 208.

Single web server pointing to single primary nodeAlthough this type of deployment can support several web servers and several clusters, each server communicates with a single primary node and vice versa (the communicating web server/primary node must be in the same cluster).

��Deployment schema

Figure 7-9 One web server pointing to one primary node within multiple clusters

Client users

Shared storage server

IP redirector

Outer firewall

DMZ

Web server A

Web server B

Web server C

Primary node

Primary node

Primary node

Inner firewall

Cluster A

Cluster B

Cluster C



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 A’s 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.

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 315.

��Deployment profile

Multiple web servers pointing to single primary nodeYou can run multiple web servers that point to the same Business Objects primary node. This strategy is useful because it helps balance the server load. To deploy this type of solution use either of the following:• one URL for each web server• one URL for all of the servers

In this case, an IP redirector then redirects the traffic using the one URL.


Single web server pointing to single primary node

• Cost-effective• Simple to implement

Single points of failure: web server or primary node




Figure 7-10 Multiple web servers pointing to one primary node

Here, four web servers are running with an IP redirector to balance the server load amongst them. They all point to the same primary node in the intranet.

The only disadvantage here is that there is a single point of failure: the primary node itself. If the primary node goes down for any reason, your entire system goes down with it.


Client users


Application server

IP redirector

Web servers Primary node

Database

Repository

Intranet


Multiple web servers pointing to single primary node

• Balances server load• Balances out network

resources

Single point of failure: primary node



Deployment profile



Basic extranet Simple to deploy and administer

No extra security, failover or load-balancing mechanisms



Deported application servers

A deported application server is one which is separated from the Business Objects cluster by a firewall.

This type of configuration provides an additional layer of security by shielding the web and application servers and the cluster from unauthorized access. It also allows you to have an Internet Service Provider (ISP) host and maintain your application server, while you keep the web server and the cluster on-site.

Communication between the application server and the clusterSeveral processes on the application server communicate directly with processes on the Business Objects server. The Business Objects server listens on TCP ports displayed in the Administration Console.

In this example, the TCP port numbers are just examples:

Figure 7-11 ASF and Business Objects processes passing through firewall

Communication is established by the application server calling the Business Objects server on the appropriate port. Replies are across TCP ports that are dynamically allocated; your firewall must let all reply calls pass.

This is acceptable because the firewall controls the initial communication from the outside (application server) to the inside (Business Objects server). This initial communication must go across the TCP allocated port, from application server to Business Objects server. The reply is trusted, and can therefore go across any port.

TCP port numbers

100001000110002100031003410035100401004110042

ASF andBusiness Objectsprocesses


Application server

itconfig_rep.exeitconfig_rep.exeitnode_daemon.exeitnaming.exeWIProcessManagerWIDispatcherWIAPIBrokerWIReportServerConnectionServer


Deported application servers

The Administration Console tells you what ports to open. If you add a process on a Business Objects server, you must open another port (again, specified in the Administration Console).

NOTE

TCP port allocation is not necessarily contiguous. Other internal ports may be used by the Business Obejcts server, and other ports that may be busy when you start the Business Objects server.

Once started, however, the ports do not change. For example, if you add a WIReportServer instance (in addition to the one using port 10041), you must also open an additional listening port, which you specify using the Administration Console).

If you have multiple Business Objects servers, you must open sets of ports for each of these servers.

Deployment schema

Figure 7-12 Example deported application server configuration

Database

Application server

WAN WAN

Client users

Single firewall protecting cluster

Secondary node

Double firewalls Double firewalls

Primary node

Repository

Intranet

Web server Application server



Deployment profile


Deployment Type

Pros Cons

Deported application server

• Provides added security• Allows the application server to

be hosted by an Internet Service Provider


Reverse proxies

Reverse proxies

In extranets in particular, web servers represent one of the system’s 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.

A reverse proxy is a proxy server which appears to be a normal web server to clients, but in fact re-routes user requests to a machine deeper into the network (and with a different name, and IP address). The responses from the web server get routed via the reverse proxy back to the client browser.

The word “reverse” refers to the inverted role of the proxy server. While normal proxy servers act as a proxy for the client (the request is made on behalf of the client by the proxy server), a reverse proxy services requests on behalf of the server, in this case, the Business Objects cluster.

How reverse proxies work with Business ObjectsIn reverse proxy configurations, extranet user requests to your site go straight to the reverse proxy. The reverse proxy sends this request to the web server, generally on another subnet, which sends the request on to the cluster for processing. The result is then passed back to the web server, which sends it back to the reverse proxy. The reverse proxy sends the information to the extranet user as if it were coming directly from the actual Business Objects server. The real URL address of your site is thus not revealed to outsiders.

Since the reverse proxy does not run any scripts, the system is less vulnerable to attack. The hacker may still try to tunnel through to the web server, but it is harder to determine which port the web server listens on, and it will be difficult to get the proxy to route any responses back. Since the reverse proxy itself executes nothing, and fine-grained routing rules can be set up, the use of a reverse proxy will keep many unwanted guests from even trying.



Deployment schemasAlthough 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.

When you deploy a reverse proxy within a DMZ, you must use one of the following configurations, depending on whether you have an ASP or a JSP deployment.

��JSP deployments

In this schema:• The reverse proxy and the web server are positioned within the DMZ.• The outer firewall provides access control for users trying to use the system

from the Internet.• The reverse proxy provides authentication and data control.

Figure 7-13 Reverse proxy and web server within DMZ (JSP)


Database

Client users

Application server

Primary node

Secondary node

Reverse proxy

Web server

RepositoryDMZ

Intranet


Reverse proxies

��ASP deployments

In this schema:• The reverse proxy is situated within the DMZ.• The outer firewall provides access control for users trying to use the system

from the Internet.• The web server provides authentication and data control.

Figure 7-14 Reverse proxy alone within DMZ (ASP)

Deployment profile


Database

Client users

Primary node

Secondary node

Reverse proxy

Application/web server

RepositoryDMZ

Intranet


Reverse proxy • Provides increased security

• Provides single point of access

Not easy to configure



IP redirectors

The IP redirector is a device that load balances TCP traffic across multiple servers by receiving user requests then redispatching them to different web servers. This section describes how you can use an IP redirector to provide load balancing and failover features for Business Objects clusters.

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

What Business Objects software/tasks can’t use an IP redirectorThe following Business Objects products and tasks cannot use the features of an IP redirector:• Administration Console

In order to administer several clusters, the Console needs to connect directly to the web server.

• Desktop products (BusinessObjects, Designer, Supervisor)These tools query the repository directly, without accessing the web server or the Business Objects cluster.

• Broadcast AgentThis tool does not go against the web server. However, it does have its own load balancing mechanism, and for failover, the same Scheduler can be started on each cluster.

• Broadcast Agent ConsoleThe Broadcast Agent Console queries the repository directly, without going against the web server. It can also connect directly to a single cluster for administration purposes.

• Audit facilityThe audit facility may not work properly as the session ID can be the same for two different clusters.


IP redirectors

Configuration optionsYou can use an IP redirector for with Business Objects for many different reasons and configurations:

Type of configuration Description

Single virtual web server and multiple physical web servers

Users always point to the same virtual web address and their requests are then sent to each of the physical web servers.

Multiple virtual web servers and a single physical web server

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.

Multiple virtual web servers and multiple physical web servers

A number of virtual web servers access a number of physical web servers.

Maximum connection and weighted configuration

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 server’s power).

Sticky command enablement

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.

Client-assigned load balancing

All requests coming from a specific client always go to the same physical server. This is done through recognition of the client’s 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.



Deployment schemaThe 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.

Figure 7-15 Deployment schema for an IP redirector

NOTE

Each of the servers in the cluster must be running exactly the same version of the Business Objects server products. The same Business Objects modules must also be installed and enabled. If this is not the case, a user may need a specific module that is present on one server and not the others.

Client users

Network 1

Outer firewall

Switch or router or hub

IP redirector

Applicationserver forcluster A

Applicationserver forcluster B

Corporate database

Shared storage

Inner firewall

Web server 1

Web server 2

Cluster A

Cluster B

Network 2

Repository


IP redirectors

ConstraintsThe 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 proxy’s 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.

Figure 7-16 IP redirector with sticky command enabled

Deployment profile



Network 2 hosting clusters A and B

IP redirector with the sticky command enabled

Web server for cluster A

Web server for cluster B

Proxy

Network 1


IP redirector Provides load balancing and failover

Does not efficiently redirect calls in deployments with proxy servers



Multiple clusters in an intranet

You may want to deploy multiple primary nodes and therefore multiple clusters using shared storage with the help of an IP redirector (see IP redirectors on page 214).

In this scenario, each cluster has its own web server and Business Objects server product installation, though this is completely transparent to the user.

Deployment schema

Figure 7-17 IP redirector with multiple clusters

Client users incoming IP :

port 12.10.150.20:80

IP redirector

Web server/application server Primary node

IP : port 34.2.148.10:80

IP : port 34.2.148.11:80

IP : port 34.2.148.12:80

IP : port 34.2.148.13:80




The workflow of the IP redirector is:• A request is sent to the IP redirector, acting as a proxy.• The IP redirector’s 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.

NOTE

With this configuration, you can use multiple repositories. For more information about using this type of scenario, see Deploying and using multiple repositories on page 349.



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:

Figure 7-18 User request redirected to next web server/primary node

Note that if a primary node fails and the web server is still working, the cluster’s 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.

User

1. U

ser r

eque

st

3. R

edire

cted

requ

est

IP redirector

incoming IP : port

12.10.150.20:80

Web server/application server Primary node B

IP : port 34.2.148.10:80

2. S

erve

r una

vaila

ble

Web server/application server Primary node A failure

Web server/application server Primary node C

Web server/application server Primary node D

IP : port 34.2.148.11:80

IP : port 34.2.148.12:80

IP : port 34.2.148.13:80




Deployment profile



• Provides failover for primary nodes and Broadcast Agent Schedulers

• Allows use of multiple repositories

• Provides a way to have server machines in multiple time zones

If multiple repositories are used, failover is provided only if the repositories are synchronized.



Single-cluster intranet/extranet deployment options

Though you can use multiple Business Objects clusters to differentiate between intranet and extranet usage, you may sometimes need to deploy both types of users on a single cluster.

This section describes two different scenarios for this type of deployment.

Single web server for intranet and extranet usersIn this scenario, you use a single web server for both your intranet and your extranet users.


Figure 7-19 Running one web server within a single cluster

In this case, you have one server in the DMZ as your web server, much like the standard extranet deployment.

All your extranet users come from the exterior firewall and use that web server, whereas your intranet users come into your system either through the inner firewall or through another proxy in your intranet.

Client users

Web server

Outer firewall

Inner firewall

Application server

Primary node

RepositoryProxy server

Intranet users

DatabaseIntranet


Single-cluster intranet/extranet deployment options


Multiple web servers within one clusterYou can use multiple web servers to enable both intranet users within your firewall and extranet users outside your firewall to contact the Business Objects server.

Figure 7-20 Multiple web servers with a single cluster

This is a good solution for a single-cluster deployment that enables you to customize one web server for your particular needs. The only disadvantage is that it requires more maintenance, as there is another point of access.


One web server within one cluster

• Improves security• Simpler network

administration

Multiple points of failure: primary node and web servers

Web servers

Outer firewall

Inner firewall

Extranet users

Intranet web server

Database

Repository

Primary node

Intranet users





Multiple web servers within one cluster

Good security • Primary node is a single point of failure

• More maintenance, due to more entry points


Multiple-instance servers under UNIX

Multiple-instance servers under UNIX

In large-scale deployments, Business Objects often runs on a single, powerful server, usually a UNIX box, for reasons of scalability, stability and cost.

To provide additional scalability and fault tolerance for Business Objects, you can configure multiple instances of the Business Objects server to run on the same box.

In these cases, each instance constitutes a separate primary node, and therefore a separate cluster:• Each instance uses a distinct and separate set of ports to communicate with

the ASF, and uses a different context, or environment in which the server is running.

• These instances can use the same repository and system storage. If this is the case, they can also belong to the same portal (users use the same URL to access both clusters). If they do belong to the same portal, you must use an IP redirector to dispatch the user requests coming from the portal among the clusters running on the UNIX machine. For information on IP directors, see page 214.

Deployment schemaHere is an illustration of the simplest multi-instance configuration:

Figure 7-21 Multi-instance configuration on a UNIX server

UNIX box

Network

Context 1 Context 2

Port 1 Port 2

PrimaryNode 1

PrimaryNode 2






Multiple-instance configuration on a UNIX server

Uses the full capacity of UNIX boxes

Web and application servers must be duplicated for each instance


Multihomed configurations


Cluster servers can use multiple Network Interface Cards (NICs), allowing them to connect to more than one distinct network segment through multiple physical IP addresses. These segments are usually isolated one from the others. This is known as a multihomed configuration.

This configuration is useful for many reasons:• Security

This type of configuration can restrict access to trusted machines only. Critical operations such as maintenance and administration can be kept on a separate network to which limited people have access. Multihomed networks are often used, for example, in intranet configurations in which there are no firewalls. Multiple NICs are used instead, to restrict access to parts of the network used for confidential transactions and data.

• PerformanceMachines performing transactional operations need the full bandwidth of their servicing network, thus other network will be used for other purposes such as administration and maintenance.For example, one high-speed network may be highly secured and subject to rigid rules on a firewall, allowing only traffic between the server and an RDBMS. Another network could then be used for other Business Objects transactions. This not only lightens the transaction load on any particular network or NIC, but allows greater flexibility in adapting networks to specific tasks.In some cases, one network is used to back up records of the transactions on another network.

• Fault toleranceIn case of defect in one of the networks the other(s) could still been used to route the packets and serves the clients. This is the case when companies buy Internet access to their servers from different providers.

With Business Objects, multihomed configurations are most useful for the first two reasons.



Deployment schema

Figure 7-22 Example multihomed configuration

Usually there is no routing between the different networks. Thanks to the ASF, the applications running on each machine know where to look for the required services.

The Configuration Tool points the nodes to use the network where the application servers are for ORB usage and the connectivity is set to use the network where the databases are.

Client users

Web server

Secondary node

Secondary node

Application server

Primary node

Corporate database Repository

Network 1: web servers and application servers

Network 2: data access, administration, authentication...



Deployment profile


Deployment Type

Pros Cons

Multihomed configuration

• Network adapted to specific tasks

• Flexibility in adapting the network to specific tasks

• Communication through more than one NIC

• Backup features

• More than one physical network required

• Single point of failure: if primary node goes down, both networks are unavailable

• More complex administration of Business Objects solution



Multilingual configurations using Unicode

International deployments are deployments spanning more than one country and/or language. Beyond the physical considerations inherent in these configurations (see Modeling your System on page 147), you may need to address the complications inherent in a multilingual user population creating and sharing documents in multiple languages and databases.

Multilingual considerations fall into two categories:• The availibility of multilingual user interfaces for users of different languages

sharing the same server installationThis depends upon the languages you have installed at Business Objects installation, the language you choose for the cluster in the Administration Console, and the language chosen by individual users for their copies of InfoView.

• The storage of multilingual data in a single or several corporate databases, and how you allow users to create and access documents using that data.Business Objects now supports the use of Unicode databases, which can store information in different languages and centralize all the information in a company. Within Business Objects, this type of database allows WebIntelligence users to create reports in a number of different languages using the data in a single database. (You cannot create documents using Unicode databases with BusinessObjects.)Likewise, once the system is properly configured, InfoView users can access documents in a variety of languages, regardless of the language used in their InfoView interface.

Deployment schemaThis deployment schema uses a centralized repository and corporate database storing data in multiple languages.

NOTE

Business Objects does not support the use of Unicode databases for the repository database.


Multilingual configurations using Unicode

Figure 7-23 Example international configuration


Deployment profile

Usersusing French UI,

viewing documentsin French, Japanese

and English

Users using Japanese UI, viewing documents in French, Japanese and English

Users using English UI, viewing documents in French, Japanese and English

Corporate Unicode database storing data in multiple languages

Repository (not Unicode)

USA

France

Japan

Cluster

LAN/WAN


International • Centralized administration of databases and server

• Allows creation and sharing of documents in multiple languages

No Unicode support for BusinessObjects documents



Heterogeneous clusters

Business Objects supports clusters that contain both Windows and UNIX servers. This is called a heterogeneous cluster.

This option is especially important for UNIX-based clusters. Although UNIX-based clusters do not need Windows server machines to carry out most tasks, a Windows server is required for processing documents with OLAP data sources, or containing Visual Basic scripts.

You may also need to add a Windows node to a UNIX-based cluster if your deployment needs to access an RDBMS hosted on Windows machines only. For more information, see page 372.

Deployment schemaIn this configuration, the primary node, application server and web server are always hosted on UNIX boxes.

Figure 7-24 Example heterogeneous cluster


Internet users UNIX

primary node

Windows secondary node

Application server (UNIX)

Corporate database

Repository

Intranet

Web server (UNIX)


Heterogeneous clusters

Deployment profile


Heterogeneous Provides UNIX-based clusters with processing features and connectivities supported only on Windows servers



Deployment configuration summary

The following table gives you a concise overview of the advantages and disadvantages of the different configurations described in this chapter.


2-tier • Is easy to maintain• Provides good performance• Provides reliable service

• Difficult to expand• Performance diminishes

with network expansion

Citrix • Allows for redirection of serial ports and printers

• Enhances load balancing and failover

• Provides easy maintenance for your user population

Is supported for 2-tier products only

Combined 2- and 3-tier architecture

• Network stability• Simple maintenance• High performance• Reliable service• Scalability

Business Objects system administration more complex

Basic intranet Simple to deploy and administer No extra security, failover or load-balancing mechanisms

Basic extranet • Simple to deploy and administer

• Cheap• Easy to maintain

DMZ configuration • Secure• Simple• Easy to implement


Deployment configuration summary





• Backup features


• Greater workload on server• Single point of failure: if

primary node goes down, both networks are unavailable


Reverse proxy • Increased security• Single point of access

Not easy to configure

IP redirector Provides load balancing and failover

Does not efficiently redirect calls in deployments with proxy servers


• Provides failover for primary nodes and Broadcast Agent Schedulers

• Allows use of multiple repositories

• Provides a way to have server machines in multiple time zones

Single web server pointing to single primary node

• Is cost-effective• Is easy to implement

Multiple points of failure: web server and primary node

Multiple web servers pointing to single primary node

• Balances server load• Balances out network

resources

Single point of failure: primary node

One web server within one cluster

• Improves security• Simpler network administration

Multiple points of failure: primary node and web servers




Multiple web servers within one cluster

Provides good security • Primary node is a single point of failure

• More maintenance, due to more entry points

Multiple instances under UNIX

Uses the full capacity of UNIX boxes

Web and application servers must be duplicated for each instance

Deported application server

• Provides added security• Allows the application server to

be hosted by an Internet Service Provider





• Backup features


• Single point of failure: if primary node goes down, both networks are unavailable


Multilingual with Unicode • Allows for centralized administration of databases and server

• Allows creation and sharing of documents in multiple languages

No Unicode support for BusinessObjects documents

Heterogeneous cluster Provides UNIX-based clusters with processing features and connectivities supported only on Windows servers


part

Practical Deployment Specifics

ch

ap

ter

From Development to Production



OverviewIt 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


The development lifecycle


The development lifecycle is the process by which the Business Objects system is developed, tested and implemented in a real-life professional situation. This lifecycle can be broken down into several broad phases.

At the very least, Business Objects recommends implementing two phases, development and production. Most enterprises prefer including more. In a mature technological scenario, a company typically includes the following phases in its Business Objects development lifecycle:1. Development2. Testing3. User acceptance testing4. Production

Each of these phases corresponds to a separate deployment environment with a specific user population and purpose. Although they succeed each other in well-defined order, the lifecycle continually renews itself as the evolution of the enterprise, the user population, its activity, and available technology forces the deployment itself to evolve. And it makes these phases both consecutive and concurrent.

Figure 8-1 The development lifecycle

Development

DevelopmentTesting

User AcceptanceTesting

Production

Repository



��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.



��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 system’s deployment, configuration, universes and documents should have been detected and resolved. Robust and customized to the companies particular requirements, the system is ready to be deployed to its target user population.

How many repositories?You can use a single repository for all environments, or separate repositories for specific phases.

��Using multiple repositories

If the development environment for the Business Objects system is on a different subnet than the production environment (development is often carried out on a different site than where the production system is actually used), using multiple repositories is unavoidable. The two systems simply cannot connect to the same repository. The gap between the two systems is often called an air gap.

Using multiple repositories makes migrating documents and universes to the production environment a much more complex process than in a single-repository scenario.

This procedure is therefore not documented in this guide. Business Objects instead recommends that you undertake this lifecycle scenario only with the assistance of certified Business Objects consultants.



��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 domain’s location and administration. It also allows you to better control who is accessing what universes.

When it’s 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 universe’s 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).



A separate deployment for each environment?Does each lifecycle environment require a separate deployment of Business Objects? Not necessarily.

Although technically you can use the same cluster configuration for the entire lifecycle, Business Objects recommends that the production environment at least have its own dedicated deployment. In other words, the Business Objects servers hosting the production system must not be the same as those used for the other lifecycle environments. Although lifecycle phases are consecutive, they can also function concurrently. Once the production environment is up and running, the test environment generally continues to operate, testing new universes, documents and configurations; the testing draws on the system’s hardware and software and lowers performance.

Separating the production environment from the other environments is not just a a question of performance, however. It is a question of best practice. You do not mix a finished system with its preparatory phases, period.



Planning the pre-production environment

The first environment you implement is the development environment. The other lifecycle phases can, but are not required to, use the same deployment. All the information this section therefore applies to the entire set of pre-production phases.

The development environment should be a microcosm of what the production environment needs to be. It should include at least one cluster, and include all the server and desktop products your eventual user population will require.

REMINDER

It is also strongly recommended that you plan and implement all your environments in consultation with Business Objects consultants.

Start smallStart 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 system’s 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, don’t 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.



Think bigMost 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 system’s 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 WebIntelligence’s support of other types of files mean for your system? Will users be most likely to process Microsoft Word files, Excel sheets, Adobe PDFs, or others? How much disk space will these files require, and how much will they increase transaction loads?

You may be using an exclusively Windows system now. But as the user population and transaction load increase, you may want to switch to a UNIX environment.

Expand, trace, volume test, benchmarkOnce you’ve designed a preliminary system, you must build it then test it to gauge its performance level. Based on the results of the tests, you can modify the system’s configuration to ensure acceptable performance levels.

Early on in the development phase, you should try to determine exactly what is expected of your deployment from its users, administrators and financiers. Performance can mean any number of things to any number of people. What response times are acceptable to your user population? What are the constraints in terms of overall cost, training and maintenance?



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 system’s 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 system’s 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 you’re done, begin the cycle all over again.

��Use the Audit facility

At every stage, trace your system and user activity using the Administration Console’s 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 they’re 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 Administrator’s Guide.



��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 411.

For complete information, see the BusinessObjects Auditor Guide.



Number, type and hierarchy of usersThe precise number of users you include in the pre-production environments is relatively unimportant. What is important, especially in the testing and UAT phases, is this:• You should construct a simulated user hierarchy with Supervisor.

This hierarchy models the real hierarchy of the production environment, containing similar types of users and security commands. However, it is “flatter”; that is, the simulated hierarchy has fewer subcategories of users.

• Start with just a few users carrying out simple but typical user transactions, such as creating WebIntelligence and/or BusinessObjects documents, and viewing and refreshing documents and document lists from InfoView.Add users as you go along, slowly building up to a more solid population with more varied activity, such as scheduling documents for automatic refresh and distribution with Broadcast Agent.

• The proportion of each type of user (see Types of users on page 136) must be consistent with the projected proportion of each type of user in the production environment.What percentage will create documents? What percentage of users will have only access and refresh rights to documents in InfoView?

You will also need to create specific users and groups with particular functions within the development lifecycle. For more information, see Creating users and groups on page 253.

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

With time, you can add new tables and complexity to existing universes, and create more.



What type of documents?You will be creating several BusinessObjects documents and/or several WebIntelligence reports for use in the development environment.

The types of documents should be as representative as possible of the documents you will be using in the production environment.

You may want to begin with the simplest document with any relevance to the type of document used in the production environment, then gradually work up to more complex, and larger documents.



Creating the lifecycle environments

Although you are starting with a small-scale, model system, it still represents a complete Business Objects deployment and installation which must be set up properly.

You can find help in setting up the lifecycle environments in the following chapters in this guide:• Deployment Considerations on page 127• Modeling your System on page 147• Supported Deployment Configurations on page 183• Implementing Supported Deployment Configurations on page 287• Overall Deployment Checklist on page 267

Installation and configurationFollow the instructions in the Installation and Configuration Guide.

Creating the repository and its domainsBecause you are using a single repository for all the lifecycle environments, you will need to take the requirements of all these environments into account when you create and structure the repository the first time.

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 universe’s 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 environmentsFor 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

Each domain you include in the deployment is likely to evolve differently; this type of separation allows you to better organize universes and documents, and allows you to optimize each domain using separate database administration and connection settings.

TIP

A typical deployment for an environment includes 2 to 6 sets of domains (universe domain and its corresponding document domain). For the sake of manageability, avoid using more than 10.

Creating users and groupsOnce you have installed and done the basic configuration of your system, use Supervisor to create or import the system’s users and user groups, and then assign them access rights.

You need to create two categories of users and groups:• those who represent the profiles and proportion of real-life users in the future

production environment (see Number, type and hierarchy of users on page 250)

• those whose role pertains exclusively to the development lifecycleGroups in this category include a separate group for each lifecycle environment; the users in each of these groups can access the domains containing the documents and universes for their particular environment only. In addition, you will need to create the users responsible for migrating the documents and universes from one environment to the next.



The following diagram illustrates how these users and groups will interact for universe migration:

Figure 8-2 Migrating universes from development through production

Create then export universe to dv_unv

Import universe from dv_unv

Import universe from tst_unv

Import universe from uat_unv

Export universe to tst_unv

Export universe to uat_unv

Export universe to prd_unv

Users/environments

Migrate_test_to_UAT

Migrate_UAT_to_prod

Migrate_dev_to_test

Using Development only

Using Production only

Using Testing only

Designer

Migration users

Using UAT only



��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.

In addition, you must make sure these users have the appropriate rights to export and import universes with Designer, and export and import documents to and from their domains in the repository using 2-tier BusinessObjects and/or InfoView. You might, for example, give these users a designer/supervisor profile.

NOTE

Migration users are simply administrative users. They therefore do not require official licenses to use Business Objects products.



Assigning the domains to groups and usersYou now assign the domains you have just created to the lifecycle groups, giving each group the right to access only the domains corresponding to their lifecycle environment.1. Log into Supervisor.2. In the main window, click the Repository tab.

All available domains are listed in the Resource pane.

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 you’re done, click OK.



Building universes and making them availableMaking a universe available to users entails several different steps:1. Building the universe2. Exporting the universe to the repository3. Configuring a universe

��Building the universe

Using Designer, create at least one functioning universe, configured with a valid, secure connection to the corporate database. The Designer’s Guide provides full instructions.

Universe file naming conventions

You simplify the migration of a document from one domain to another by giving the document’s universe the same file name in every lifecycle environment (this is not the same name as the long name, which is what BusinessObjects and WebIntelligence users see in their universe lists). For example, the universe called eFashion in a domain in the development environment must be called eFashion in all other environments as well.

You now need to use Supervisor to disable the Prevent from Overwriting Universe security command in the Universe family for all migration users (and only migration users). In this way, when an enhanced version of an existing universe is migrated into a domain, it simply replaces the older version.

This allows you to avoid having to manually change the name of the data provider for BusinessObjects documents once they’ve been migrated to a new domain. When the document is retrieved from the repository after migration, the system will automatically search for a universe with the same file name, and use it if it exists.

EXAMPLE

Simplifying migration with the right universe file names

Lynn is the user of the production deployment in CompanyA. She can therefore access universes and documents in the production environment only.

Lynn is a sales analyst, and the report she uses each day, DailyRevenue, is based on a universe called Sales.



As in most companies, the lifecycle of developing, testing and releasing enhanced universes and documents at CompanyA is an ongoing process. One weekend, a migration user migrates an enhanced set of universes and documents from the UAT to the production environment• The Sales universe in the UAT environment’s 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.

��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).

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 Supervisor”s 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 universe’s 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.

The Universe Properties dialog box opens.For instructions on changing settings, see Supervisor’s Guide.

Creating documentsCreate 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


Migrating between environments


To migrate from one environment to the next, you:• migrate universes• migrate documents then test them• delete unnecessary documents

TIP

If you follow the recommended file naming convention for universes, you don’t have to migrate universes and documents at the same time. You can migrate them in the order and at the interval you choose, as long as a universe with the same name as a migrated document’s original universe exists in the destination environment. If you migrate a document from one environment to another before its universe, the document will automatically be linked with the universe of the same name in the destination environment.

Migrating universesThis 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.



��Importing the universe from a domain1. 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.

��Exporting the universe to the destination environment1. 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.

Migrating documentsMigrating 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 257, this is all you need to do. If the name of a document’s 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 reports

To migrate a WebIntelligence report 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 report you want to migrate.3. Save it as a corporate document, to a document domain in the new lifecycle

environment, with the Overwrite option selected.4. Refresh the report if you want it to reflect the data in the new environment.5. You may want to purge the report’s data provider in order to remove all

vestiges of results from its former data provider and reduce the size of the report. 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.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 document’s data provider in order to remove all vestiges of results from its former data provider and reduce the size of the document. You do this with the Data Manager (Data > View Data).



Deleting unnecessary documentsThis procedure includes two main steps:• Delete all unnecessary documents from the repository.• Check the repository’s integrity.

��Deleting documents from the repository1. Log into Supervisor as a general supervisor. 2. Choose Tools > Delete document. 3. Delete the unnecessary documents.

After deletion, the only way to recover the documents is to recover a backup of the repository.

��Checking the repository’s integrity1. Log into Supervisor as a general supervisor. 2. Choose Tools > Repository.

The Repository Management dialog box appears.3. For each security domain and document domain, click Scan.

The Scan and Repair dialog box appears:- For the security domain, click Scan, then Repair, and then Compact.- For document domains, just click Scan and then Repair.


Planning and building the production environment

Planning and building the production environment

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

Providing failover and load balancingBusiness Objects recommends configuring the production environment to include multiple clusters, and therefore, multiple primary nodes. The Business Objects system provides automatic failover if any CORBA component falls over. As the primary node is a single point of failure, however, if you want 100% failover, Business Objects recommends using multiple clusters with an IP redirector balances the load between the web servers used by each cluster, and provides failover if one of the primary nodes fails.

In this way, the production system provides a fault-tolerant system, maintaining 24/7, critical-application status. For example, if one of the primary node fails, the subsequent user requests are directed to the other primary node.

Configure the primary nodes for shared storage of users’ personal documents. You can maintain the shared storage on an external disk array that is physically connected and shared by different servers.

In addition, the system can remain operational during upgrades and maintenance because you can upgrade or maintain one primary node while the other primary node handles the production load. You can also add secondary nodes to the clusters, which distributes the load and provides scalability.

TIP

Because the IP redirector communicates with the web server only, you may want to write a script to shut down the web server when the primary node fails. In this way, no requests are sent to that server while it is being maintained.

ch

ap

ter

Overall Deployment Checklist



OverviewThis chapter provides a step-by-step overview of how to deploy your Business Objects solution in checklist format, designed to be as brief as possible. It assumes that you are deploying a 3-tier solution using all the Business Objects server products.

How to use this checklistThis skeletal view of the overall deployment procedure is designed as a checklist in order to be used as one. Business Objects recommends that you print out the checklist pertaining to your deployment environment, then check off each step as you complete it:• Setting up a Windows deployment• Setting up a UNIX deployment• Setting up a heterogeneous deployment

This will allow you to keep track of what you’ve done so far, and what remains to be done.

The checklist also tells you where you can go for more detailed information within the Business Objects documentation set.


Setting up a Windows deployment


Before installing Business Objects

Basic software installation and configuration

Steps Where you can find information

❏ Check that your system’s web and application servers are running correctly (if the application server is running in standalone mode it will also serve as a web server).

❏ If you’re using both a web and application server, make sure a third-party application server connector is installed on the web server.

❏ Make sure the connectivities to all the databases used in the system, for both the repository and corporate data, are installed and are working correctly.

Data Access Guide

❏ Check that connectivity environment variables are correctly set.

Data Access Guide

❏ Ensure the proper read/write permissions are set for the user/schema that will own the repository tables.

Steps For more information, see:

❏ Make sure the correct license files have been copied to each machine in the system (you will specify this license directory during installation), or that all machines have access to a shared directory storing the licenses.

Installation and Configuration Guide

❏ Install the Business Objects Server products, access packs and/or demos required for your deployment on the proper server machines, according to a supported deployment configuration.

• Installation: Installation and Configuration Guide

• Supported configurations: page 183 in this guide

❏ Install the other required Business Objects Desktop and Administration products on client machines.




Basic setup of the Business Objects reporting environment

❏ Use the Configuration Tool to create the nodes in your deployment’s cluster, configure the ORB so that these components can work properly together.


❏ Deploy web applications on the web and application servers used by the cluster, using one of the following:- the Configuration Tool- wdeploy- manual proceduresYou must deploy at least the InfoView application.

• Configuration Tool and wdeploy: Installation and Configuration Guide

• Manual procedures: Manual Web and Application Server Configuration Guide

❏ If you’re using Auditor, create a separate, Auditor-dedicated cluster.

BusinessObjects Auditor Guide

❏ Using Supervisor, create the repository(ies) used by the cluster(s). This also creates the repository’s .key file.

Supervisor’s Guide

❏ Using the Security Configuration Tool, select and configure the type of authentication and authorization you want your system to use.






❏ Create the cluster’s users and groups and assign them access rights. Depending on the type of authentication/authorization you chose in the previous deployment step, you can do this using one or a combination of the following options:- using Supervisor on a Windows machine outside the cluster then export the definitions to the repository. - using an external user management system such as an LDAP corporate directory, or Netegrity SiteMinder®.

• For creating users and groups using Supervisor:Supervisor’s Guide

• For information on authentication/authorization choices:Installation and Configuration Guide

❏ Make sure the .key file corresponding the repository you’re using exists on every cluster node. You can use an existing 5.1/2.7 .key file if you want.


❏ Make sure all clients who will be using the cluster also have access to the same .key file, either installed on the client machines or in a shared directory.


❏ Make sure all users of Business Objects Desktop products have the appropriate .key file installed on their machine, or have access to one in a shared network directory.


❏ In Supervisor, define at least one Broadcast Agent for one or more user groups.

Broadcast Agent Administrator’s Guide

❏ Using Designer, create at least one functioning universe, configured with a valid, secure connection to the corporate database. Export this or these universe(s) to the repository.

Designer’s Guide

❏ Set each server’s time zone information to be consistent across the cluster (Regional Settings in the Control Panel).

System Administrator’s Guide

❏ Make sure the fonts you need to create documents are installed on client machines, and that the fonts required to properly generate and display them are installed on the server machines.Also, make sure that all the characters defined by the cluster locale are included in the repository charset.

page 381 in this guide

❏ Set up the cluster’s storage directory, preferably on a separate server.




System startup and basic administration


❏ Make sure the web and application servers are running.

❏ Start the system, primary node first, then secondary nodes. System Administrator’s Guide

❏ Test the cluster’s connection with the client by having several users log into InfoView from different machines.

InfoView User’s Guide

❏ Open the Administration Console and tune the system. This includes both the required and strategic enablement of Business Objects processes on each node, as well as setting the ratio of system processing that each node will handle (Node Weight). Make sure you enable the session stack on each node you want to handle document processing in the cluster.

• System Administrator’s Guide

• Recommended Settings for Business Objects Deployments

❏ With the Administration Console, set the pool size for WIQT at least, making sure the total number for the cluster is equal to your deployment’s maximum number of concurrent users. Also, if you’re using Connection Server as a server component, set the number of its instances with care.


❏ Using the Administration Console, configure and monitor at least one Scheduler for the Broadcast Agent you created in Supervisor.


❏ If you’re using Auditor, use the Administration Console to make sure system Audit information is stored in a database.


❏ Have users requiring 3-tier deployments of BusinessObjects download the product through InfoView. After the download, they must select BusinessObjects as their default report editor and/or viewer in the InfoView Options pages.




Test and population of system for use


❏ Create Business Objects documents using BusinessObjects and WebIntelligence.

• BusinessObjects User’s Guides

• WebIntelligence User’s Guides

❏ Test the system’s processing capabilities by publishing these reports to the repository to share them with other users, sending them directly to other users and saving them for personal use.



❏ If users are planning to use third-party files in InfoView, make sure the third-party applications are installed on the client machines. Upload any desired third-party files for sharing through the repository.


❏ Test Broadcast Agent by scheduling a set of documents for automatic refresh and distribution from InfoView.


• InfoView User’s Guide



Setting up a UNIX deployment

REMINDER

Even if your cluster contains UNIX servers only, all Business Objects deployments require the use of Windows workstation for administrative tasks involving Designer and Supervisor, as well as for any other desktop products.



❏ Check that your system’s web and application servers are running correctly (if the application server is running in standalone mode it will also serve as a web server).



Data Access Guide

❏ Check that connectivity environment variables are correctly set.

Data Access Guide

❏ Ensure that the proper read/write permissions are set for the user/schema that will own the repository tables.

❏ Make sure the user that will install the Business Objects products has write permissions for all installation directories.












❏ Use the Configuration Tool to create the nodes in your deployment’s cluster, then configure the ORB so that these components can work properly together.


❏ Deploy web applications on the web and application servers used by the cluster, using one of the following:- the Configuration Tool-wdeploy

- manual proceduresYou must deploy at least the InfoView and the Admin web applications.





❏ Set the environment variables in the Business Objects environment in the MyWebiEnv.sh file to enable users to use the connectivity layers.


❏ Using Supervisor (running on a Windows machine outside the cluster), create the repository(ies) used by the cluster(s).





❏ Run the wmainkey script to create the bomain.key file for the repository on each UNIX node in the cluster, or copy an existing 5.1/2.7 or 6.x Windows bomain.key file to each node.




❏ Make sure all users of Business Objects Desktop products from Windows machines outside the cluster have the appropriate .key file installed on their machine, or have access to one in a shared network directory.


❏ Using the Security Configuration tool, select and configure the type of authentication and authorization you want your system to use. You cannot use Windows authentication.










Designer’s Guide



❏ Set the time zone information in MyWebiEnv.sh and/or boconfig.cfg to be consistent on each node in the cluster.


❏ Make sure the fonts you need to create documents are installed both on client machines, and that the fonts required to properly generate and display them are installed on the server machines.Also, make sure that all the characters defined by the cluster locale are included in the repository charset.


❏ Set the cluster’s storage directory.Tell your users that as UNIX is case-sensitive, if they don’t take capitalization into account when naming categories and documents, files may be inadvertently overwritten.








❏ Log into the system as the Business Objects administrator, then start the system (primary node first, then any secondary nodes).




❏ Open the Administration Console and tune the system. This includes both the required and strategic enablement of Business Objects processes on each node, as well as setting the ratio of system processing that each node will handle (Node Weight). Make sure you enable the session stack on each node you want to handle document processing in the cluster.



❏ With the Administration Console, set the pool size for WIQT at least, making sure the total number for the cluster is equal to your deployment’s maximum number of concurrent users. If you’re using Connection Server as a server component, set the number of its instances with care.




❏ If you are using Auditor, use the Administration Console to make sure system Audit information is stored in a database.






Setting up a heterogeneous deployment

For more information on heterogeneous configurations, see page 232.



❏ Check that your system’s web and application servers are hosted on UNIX boxes and are running correctly (if the application server is running in standalone mode it will also serve as a web server).



Data Access Guide

❏ Check that connectivity environment variables are correctly set on all the servers to be part of the cluster.

Data Access Guide

❏ Ensure that the proper read/write permissions are set for the user/schema that will own the repository tables.

❏ Make sure the user that will install the Business Objects products has write permissions for all installation directories.












❏ Run the Configuration Tool on each machine in the cluster to configure them as cluster nodes so that these components can work properly together. The server you configure as the primary node must be a UNIX box.


❏ Deploy web applications on the web and application servers used by the cluster, using one of the following:- the Configuration Tool-wdeploy

- manual proceduresYou must deploy at least the InfoView and the Admin web applications.





❏ Set the environment variables in the Business Objects environment in the MyWebiEnv.sh file on all UNIX nodes to enable users to use the connectivity layers.


❏ Using Supervisor (running on a Windows machine outside the cluster), create the repository(ies) used by the cluster(s).





❏ Copy an existing 5.1/2.7 or 6.x UNIX or Windows bomain.key file to each node in the cluster.




❏ Make sure all users of Business Objects Desktop products from Windows machines outside the cluster have the appropriate .key file installed on their machine, or have access to one in a shared network directory.


❏ Using the Security Configuration tool, select and configure the type of authentication and authorization you want your system to use. You cannot choose Windows authentication.










Designer’s Guide



❏ Set the time zone information consistently on each node in the cluster:- On UNIX machines, do this in MyWebiEnv.sh and/or boconfig.cfg.- On Windows machines, do this in Control Panel > Regional Settings.


❏ Make sure the fonts you need to create documents are installed both on client machines, and that the fonts required to properly generate and display them are installed on the server machines.Also, make sure that all the characters defined by the cluster locale are included in the repository charset.


❏ Set the cluster’s storage directory.Tell your users that as UNIX is case-sensitive, if they don’t take capitalization into account when naming categories and documents, files may be inadvertently overwritten.








❏ Log into the system as the Business Objects administrator, then start the system (primary node first, then any secondary nodes).




❏ Open the Administration Console and tune the system. This includes both the required and strategic enablement of Business Objects processes on each node, as well as setting the ratio of system processing that each node will handle (Node Weight). Make sure you enable the Session Stack on each node you want to handle document processing in the cluster.



❏ With the Administration Console, set the pool size for WIQT at least, making sure the total number for the cluster is equal to your deployment’s maximum number of concurrent users. If you’re using Connection Server as a server component, set the number of its instances with care.




❏ If you’re using Auditor, use the Administration Console to make sure system Audit information is stored in a database.




ch

ap

ter

Implementing Supported Deployment Configurations



OverviewThis 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:• Installation and configuration for all 3-tier deployments• Implementing a Citrix configuration• Implementing a basic intranet deployment• Implementing a DMZ configuration• Implementing an extranet deployment• Implementing a deported application server• Implementing an IP redirector• Implementing a multihomed configuration• Implementing a multiple-instance UNIX configuration• Implementing heterogeneous clusters• Implementing a single web server for intranet and extranet users• Implementing Unicode corporate databases


Installation and configuration for all 3-tier deployments


No matter what deployment configuration you have chosen for your BusinessObjects 6.5 solution, the same rules apply for each basic component in the system:• the application server• the web server• the nodes in the Business Objects cluster

Figure 10-1 Example deployment schema


Extranet

users

Application

serverPrimary node

Secondarynode

Administrators

(Supervisor,

Designer)

Business Objects

cluster on intranet

Corporate

database

Repository

3-tier users

(InfoView, WebIntelligence,

BusinessObjects,

Broadcast Agent)

2-tier users

(Business-

Objects, Business-

Query)

Web server



What is installed/configured on the client machines

��On the desktop client machines• BusinessObjects• BusinessQuery

��On the administration client machine• Supervisor• Designer• The Configuration Tool• Broadcast Agent Console• Administration Console in standalone mode (or the Administration Console

can be accessed through a web browser)

��On the 3-tier client machines• 3-tier BusinessObjects• WebIntelligence Java applet or DHTML editor

NOTE

You may not choose to assign Business Objects processing or administrative functions to client machines in this manner. This division reflects however the functional and architectural categories of Business Objects components and products.

Business Objects highly recommends that all the servers used in the Business Objects system be dedicated to the system itself. This means no databases or other applications should be installed on the server machines.



What is installed/configured on the web and application server machines

��On the web server machine• The web server package, which consists of the static HTML pages and

images required by InfoViewThis is installed when you choose the Web Server pages option under InfoView in the Business Objects installer.

• The application server package (see the following section)You need to install this package in order to use the Configuration Tool to add a virtual directory to the web server branch.

• A third-party application server connector

��On the application server machine

The Application Server package which consists of:• ASP or JSP scripts (ASP for IIS configurations, JSP for J2EE configurations)• WICOM or WIBean (WICOM for IIS configurations, WIBean for J2EE

configurations)• RECOM or REBean (RECOM for IIS configurations, REBean for J2EE

configurations)• HSAL or JHSAL (HSAL for IIS configurations, JHSAL for J2EE

configurations)

For all of this to be installed, you must choose the Application Server pages option under InfoView in the Business Objects installer.

You must also install the Configuration Tool, available as an Administration Product option.

If the application server is running on a separate machine from the cluster machines, you must have configured the application server machine as a client node of the cluster using the Configuration Tool. This installs the ASF client application on it, giving it the means to communicate with the rest of the cluster.



What is installed/configured on cluster node machinesBusiness Objects recommends that Business Objects server products be installed on a dedicated server. Their installation on a server housing any products other than the operating system itself, appropriate middleware, and a web server, is not supported.

As a minimum, the Business Objects server backend must be installed on all cluster nodes. You do this by choosing the Business Objects server option in the installer.

You can in addition install other server packages for specific types of processing to be handled by that machine. You can choose from among:• WebIntelligence• BusinessObjects Web Installer• Broadcast Agent

See the table in the following section.



Summary of installer options for server machines

This installer option... This sub-option... installs this on the server machine

InfoView the InfoView portal, gateway to enterprise documents

Web Server pages HTML pages and images, to be installed on the machine that hosts your web server

Application Server pages

Application Server Pages and front-end components, to be installed on the machine that hosts your application server

WebIntelligence WebIntelligence report engine, for querying, analysis and reporting over the web

Reporter WebIntelligence module for report creation

Explorer WebIntelligence module for report analysis

BusinessObjects Web Installer

mechanism for installing BusinessObjects in 3-tier mode on the client machine via the InfoView portal

Broadcast Agent capacity to automatically refresh and distribute documents at specified times and intervals, in a secure manner

Scheduler the core components of Broadcast Agent

Console Broadcast Agent Console, to monitor and administer Broadcast Agent activity



Implementing a Citrix configuration

Figure 10-2 Citrix deployment schema

NOTE

For an overview of Citrix configurations, see page 190.

Operating systemBusiness Objects supports Citrix Metaframe Server running on a Windows operating system only.

Client machinesThe client machines in this scenario can host:• Windows 2000 or XP clients with or without Internet Explorer• Sun Solaris clients with Netscape Internet browsers• Macintosh clients with Netscape Internet browsers• Windows 98 Web clients with Internet Explorer

Citrix ICA Client Metaframe 6.0.1 must be installed.

No middleware or Business Objects software is required on the clients.

Clients using

Supervisor

Designer

BusinessObjects

BusinessQuery

Citrix Metaframe Server

Corporate

database

Repository

UNIX

Macintosh

Windows



Server machineThe following software is required on the server machine:• Windows 2000 Server• Terminal services• Terminal services license• Citrix Metaframe XP 1.0

This enables communication with the ICA client.• Citrix ICA Client 6.01• IIS web server• Business Objects client software on the server

You install the Business Objects Desktop applications through the Add/Remove Programs facility in the Windows Control Panel. Only standalone installations are supported.You will use the same facility to update these applications with Business Objects service packs.

• The connectivities required to access the repository and corporate databases

No application server is needed in this configuration.

NOTE

As the Business Objects products treat the Citrix Metaframe Server as a client, Business Objects server products must not be installed on the Citrix machine.

For the same reasons, Business Objects does not support the installation of the Broadcast Agent Console and Administration Console in standalone mode on the Citrix server.

SecurityOn the Citrix server you can use either an Anonymous or an NT Domain connection. You must use an NT Domain connection if you want to use Windows NT authentication for Business Objects.



��Setting the Business Objects authentication mode

You can use either Windows NT or Business Objects authentication for BusinessObjects (see the Installation and Configuration Guide for information on setting the authentication mode for your deployment). You must also set the authentication mode using Supervisor, in the Security Policy tab of the Options dialog box:

Figure 10-3 Security Policy tab in the Options dialog box in Supervisor

• To choose Windows authentication, check the Enable WinNT authentication option.

• To choose standard Business Objects identification, just leave the Enable WinNT authentication option unchecked.



PrintersBusiness Objects users can print reports using both local printers and printers connected to the Citrix server.

Depending on the type of security used for the Citrix login, users see a different list of printers:• When Citrix uses an Anonymous connection, the list of printers that the user

is authorized to use is set locally on the client machine. These printers have the prefix <client\client machine name\name of the printer>.

• When Citrix uses an NT domain connection, the list of printers includes both the list of authorized local printers (with the prefix mentioned above), as well as the printers the user is authorized to use through the Citrix server (without prefix).



Implementing a basic intranet deployment

Figure 10-4 Intranet deployment schema

NOTE

For a description of a basic intranet deployment, see page 211.

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.

For an illustration of an intranet deployment with firewalls, see Figure 10-5.


Primary node

Web server

Application server

Secondary node 1

Secondary node 2

Client admin

machine

BusinessObjectsusers

Repository

Database

Intranet


Implementing a DMZ configuration


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 the Installation and Configuration Guide.

Figure 10-5 Typical DMZ deployment schema

NOTE

For a description of a DMZ configuration and vital background information, see page 197.

Firewall restrictionsAs explained in Chapter 7, this release supports neither Business Objects server components (such as a “dead” secondary node) nor a firewall between primary and secondary nodes in the cluster.

With this release, however, you can have the application server in its own DMZ, separated from the cluster by one or more firewalls. For information, see Implementing a deported application server on page 307.


Database

Internet users

Primary node

Application

server

Repository

Secondary

nodeSecondary

node

Intranet

Web server



Setting the TCP ports used by cluster processesWhen you use the Configuration Tool to configure the cluster’s ORB, you set the range of ports to be used by the processes on each primary or secondary node. At server startup, each of the processes on the primary or secondary node is allocated a fixed port within the range you specified, through which it listens for incoming requests coming from other nodes, or the application or web server. Allocated ports remain the same throughout the server session.

For more information, see the Installation and Configuration Guide.

Depending on your deployment scenario, you may need to open specific ports in the firewall to allow communication through the firewall.

Allowing the web server(s) to communicate with the clusterWhen the web server is situated in the DMZ as in Figure 10-5, the outer firewall must allow HTTP communication. Traditionally port 80 is used for this, so in the outer firewall rules, any client port must be able to talk with port 80 on the cluster’s primary node (or a different port specified during ORB configuration with the Configuration Tool). You can see which ports are allocated to which processes in the Administration Console.

The inner firewall must allow TCP traffic in both directions through the TCP ports that the web server(s), the cluster’s primary node and the application server are using to communicate. The web and application server ports are set when these servers are set up. See the web and application server documentation for instructions on how to do this.

Allowing application server/cluster communication through a firewallFor complete instructions, see Implementing a deported application server on page 307.

Enabling the web and application servers to communicateRegardless of where the web and application servers are hosted, the web server communicates with the application server through the third-party connector discussed in Communication through firewalls on page 198. You still need to configure the ORB on the application server machine, however, so that it can communicate as a client node with the cluster’s primary node. 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 manufacturer’s documentation.

NOTE

If you are using Microsoft IIS for both web and application servers, the IIS server should remain inside the firewalls on the intranet, along with the Business Objects cluster. For more information on this type of configuration, as well as JSP deployment options, see page 303 in the section on extranets in this chapter.



Implementing an extranet deployment

Figure 10-6 Standard extranet deployment schema

NOTE

For an overview of extranet configurations, see Extranet deployments on page 202.

ClientsClient machines on the Internet can be browsers, applets or Business Objects applications such as InfoView, WebIntelligence and BusinessObjects in 3-tier mode. All these clients communicate in HTTP with the web servers, with one exception: BusinessObjects must access the corporate and repository databases directly for data exchange.

RoutersThe routers and network topology are transparent to the Business Objects products as long as there is no filtering on the routers.


Database

Internet users

Secondary node

Secondary

node

Repository

Primary nodeApplication

server

Intranet



Cluster node deploymentAll the nodes in a cluster must be deployed on a single network segment. This is the only supported configuration, and it guarantees optimal performance.

In the most common Windows deployment scenarios, web servers, application servers and cluster nodes are deployed on different machines. Under UNIX, the application server as well as different nodes can be configured on the same machine (see Multiple-instance servers under UNIX on page 225); the web server, however, is generally on a separate machine within the DMZ.

ASP and JSP extranet deployment configurationsFirewalls 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).

If you are using Microsoft IIS as both web and application server in an ASP deployment, however, you need to position the IIS server inside the firewalls, on the same side as the cluster, and instead place a reverse proxy inside the DMZ for extra protection against outside users. JSP configurations give you a choice between the two scenarios.

��ASP extranet configurations

In ASP deployments, Microsoft’s IIS often acts as both web and application server. In these configurations, the IIS server must remain in the intranet, behind both firewalls, with a reverse proxy to provide extra protection from outside users in the DMZ:



Figure 10-7 ASP extranet configuration with IIS web/application server

The reverse proxy redirects the client calls sent to the \wiasp directory on the server, to the IIS server in the intranet. The IIS server and the reverse proxy communicate through one fixed TCP port, which you must make sure is open in the inner firewall.

For more information about reverse proxies, see Reverse proxies on page 211.

��JSP extranet configurations

You have two deployment choices for an extranet in a JSP environment:• The first is the standard deployment scenario of the web server in the DMZ

and the application server in the cluster on the intranet:


Database

Internet users

Repository

Secondary

node

Primary node

IIS

Intranet

Web server



Figure 10-8 First extranet deployment option in a JSP environment

The web server/application server connector (for example, mod_jk for Apache-TomCat) crosses through a single port in the inner firewall to the application server running inside the intranet. The application server then provides the communication with the Business Objects server(s) in the cluster.


Database

Internet users

Primary node

Repository

Secondary node

Application server

Intranet

Web server



• The second has a reverse proxy in the DMZ, with the web server inside the inner firewall, on the same side as the application and Business Objects servers:

Figure 10-9 Second extranet deployment option in a JSP environment

The reverse proxy receives client requests as if it were a normal web server, but in fact sends the requests through a fixed TCP port in the inner firewall to the web server on the other side of the inner firewall for processing. Again, you must make sure this port is open.The web server transmits the requests to the cluster, and when the transaction is completed, sends the results back through the firewall to the reverse proxy and back to the client.The reverse proxy therefore protects the Business Objects servers from direct uncontrolled access from extranet clients.


Database

Internet users

Repository

Primary

node

Secondary node

Application server

Web server

Intranet

Reverse proxy


Implementing a deported application server


For this type of configuration, your deployment depends on whether you’re using ASP or JSP technology:• This is a typical ASP configuration with a deported application server:

Figure 10-10 Example deported application server ASP deployment

• This is a typical JSP configuration with a deported application server:

Figure 10-11 Example deported application server JSP deployment

DatabaseWAN

Internet users


Secondary node

Primary node

Intranet

Double firewallsRepository

IIS

Database

Application server

WAN WAN

Internet users


Secondary node

Primary node

Intranet

Double firewallsDouble firewallsRepository

Web server Application server



NOTE

For an overview of deported application server configurations, see IP redirectors on page 214.

Several processes on the application server communicate directly with processes on the Business Objects server.

As the Business Objects server listens for requests from these processes on TCP ports, and each process is assigned a specific port for the duration of the server session, you must open a set of ports in the firewall to allow thes. If you have multiple Business Objects servers, you must open sets of ports for each of these servers.

Before configuring the firewallsBefore configuring the firewalls in your configuration to allow communication between the cluster and the deported application server, you must:1. Install the Business Objects server products on the machine that will host the

Business Objects server.2. Configure that machine as the cluster’s primary node.3. Start the server.4. Install the required Business Objects components on the web and application

servers (see What is installed/configured on the web and application server machines on page 291).

5. On the web and application server machine(s), check whether the following directory exists: $INSTALLDIR\BusinessObjects Enterprise 6\http_server_binIt should contain the following DLLs:- BODocGenISAPI.dll - iswi.dllIf this directory does not exist, copy it from the $INSTALLDIR\BusinessObjects Enterprise 6 directory on the cluster’s primary node machine.



6. Run the Configuration Tool on the application server machine, configuring the machine as a client node. If you’re using NAT (Network Address Translation) between the application server client node and the other cluster nodes, when you run the Configuration Tool on the application server node, you must configure the ORB using the node’s hostname, not IP address.If you start the primary node, you should be able to ping the client node hostname from the primary node.

7. Deploy the Business Objects web applications (InfoView and the Administration Console at least) on the web and application servers, using either the Configuration Tool, the wdeploy script, or manual configuration procedures.

8. Test the configuration by running an Internet browser on a client machine and typing the URL pointing to the primary node (for example, http://server1/wijsp).

Opening the firewall for cluster/application server communicationTo use a firewall between the application server and the cluster, you must open certain ports in the firewall to permit the cluster’s primary node and the application server to communicate through the firewall.

��For application server / cluster communication

To permit application server -> cluster communication, you must open the ports allocated to the following processes on the cluster’s primary and secondary nodes:• all it* processes, such as itconfig_rep.exe, itlocator.exe and itnaming.exe• WIProcessManager• WIDispatcher• WIAPIBroker• WIReportServer (you must open a separate port for each WIReportServer

instance)• ConnectionServer (if you’re using BusinessObjects in 3-tier mode)



The list of the ports you must open is displayed in the Administration Console:

Figure 10-12 List of exposed ports in the Administration Console

You can also retrieve this list using the wasfadm utility, by typing for example:% wasfadm -port

The result looks something like this:NODE PORT PROCESS

server1 100010 it_naming.exe

server1 100011 it_locator.exe

...

��For cluster/application server communication

As ports for communication running from the cluster’s primary node to the application server on the client node are allocated dynamically, you must open all the ports on the cluster’s primary and secondary nodes in this direction.


Implementing an IP redirector


Figure 10-13 Example deployment configuration using an IP redirector

NOTE

For an overview of this type of configuration, see IP redirectors on page 214.

Configuring the IP redirectorTo deploy a system with multiple primary nodes using an IP redirector:1. Configure a web server with an IP redirector.2. In the IP redirector route table, map a single IP to multiple IP addresses with

their port numbers. See the example below.

Internet users

Outer firewall

Inner firewall

Switch or router or hub

IP redirector

Applicationserver forcluster B

Applicationserver forcluster A

Shared storage

Corporate database

Cluster A

Repository

Web server 1

Web server 2

Network 2Network 1

Cluster B



EXAMPLE

Incoming and redirected IP addresses using an IP redirector

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 318.

Deployment conditionsIn order to include an IP redirector in your Business Objects deployment:• All the servers must 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).

• The IP redirector must NOT be located between the application server and the cluster.

Incoming IP Incoming port Redirected IP Redirected port

12.10.150.20 80 34.2.148.10 80

12.10.150.20 80 34.2.148.11 80

12.10.150.20 80 34.2.148.12 80

12.10.150.20 80 34.2.148.13 80



• The servers need to be equivalent in terms of the Business Objects modules that are installed and enabled. This is mandatory for real load balancing and failover, otherwise users might need a module that is on one server and not the others.Note that the execution of the Broadcast Agent tasks is completely independent of the IP redirector, as the Scheduler doesn't use the IP redirector.

• The sticky command must be used to connect to Business Objects. See the following section.

Requesting the same server for multiple requestsYou can ensure that the same client gets the same real server for multiple requests by enabling the sticky command on the IP redirector. This command allows requests to be processed by the same real server and retain the statefulness of the client/server connection. For example, if a client is completing an online form, the sticky command ensures that multiple connections are sent to the same server so that the client can complete the transaction.

If this command is not used, each request to a virtual server is routed according to the configuration in effect for that virtual server. The connection may therefore be made with a different server, and prevent the transaction from being completed.

��Implementing the sticky command

There are two ways you can implement the sticky command, one based on the IP address of the client PC, and the other using a cookie sent from the web server to the client PC.

When using the IP redirector in a cluster, you need to implement the sticky command based on the IP address of the client PC. This ensures that once a connection is opened to a physical server, requests from this client will always go to the same physical server until the timeout is reached, thus maintaining the stability of the client/server connection.

How you implement the sticky command, and even what the command is called, may vary depending on the IP redirector you’re using. See the manufacturer’s documentation for information.



��Using a non-transparent proxy policy

If your network is set up so that the connections go through a proxy server, the IP redirector may see the proxy IP address and redirect all requests to the same primary node if the sticky command has been enabled. To prevent this, you need to use a non-transparent proxy policy.

A non-transparent proxy performs IP translation so that calls to the IP redirector are made as if they came from the client PC itself. The IP redirector can then redirect each call to a different web server and the different Business Objects clusters as appropriate.

The sticky command does not time the length of a client connection; it times periods of inactivity. For example, if the sticky command is set to 5, and the client is active, new requests from the client are not sent to another server through load balancing, even if more than five minutes have elapsed. However, if five minutes of connection inactivity have elapsed, the requests from the client can be sent to another real server.

Configuring for a maximum connection and weighted configurationThis type of configuration means using the IP redirector to load balance to the real server according to either or both of the following:• a defined maximum number of connections to each particular server• the weight of each server (depending on the power of the servers), as

determined by the server’s Node Weight parameter in the Administration Console

To configure the IP redirector to take these factors into account:1. Determine the maximum number of concurrent active users for each of the

clusters connected to the IP redirector (i.e. the corresponding web server).For example, the deployment includes three clusters:- Cluster 1 has three machines and 300 active users.- Cluster 2 has two machines and 200 active users.- Cluster 3 has one machine and 500 active users.

2. Add up the total number of maximum concurrent active users for all the clusters. This determines the Maximum Number of Connections for the IP redirector.In our example, the Maximum Number of Connections is 1000.



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 manufacturer’s documentation.

When the maximum number of connections defined for any particular server is reached, the IP redirector should automatically direct new connections to another server.

When the web server failsWhat happens when the web server fails?

��For new connections

If the IP redirector can detect that no data is sent, it redirects the request to one of the other web servers.

��For existing connections

If the IP redirector can detect that no data is sent, it redirects the request to one of the other web servers. If users are working with InfoView, the session context is lost and all work that has not been saved will be lost.

This is not the case if users are working with 3-tier BusinessObjects.

When the primary node failsWhat happens when the primary node fails and the web server is still running?

If the request goes to the same web server, the connection fails because the primary node is down. To avoid this, the IP redirector needs to know when the primary node has failed.

With this release, Business Objects components (ASP/JSP server pages, servlets and ISAPI components) on the cluster’s dedicated application server return HTTP error messages to the IP redirector when they detect cluster failure. The exact message sent depends on the invalid response the application server gets to an API call to the cluster, such as CORBA exception or CORBA timeout.

You must configure the IP redirector so that the branch on which the errors occur is forbidden for all subsequent requests. How you do this depends on the IP redirector you are using. See its documentation.



��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:



Error Description When it is sent

500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.

If a CORBA exception is raised within a call to the Business Objects cluster API

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



You must configure the IP redirector to recognize these HTTP errors.

IP redirectors and cluster storageWhen you install Business Objects server products, you can choose which server or servers on which you want to actually store the system’s cached, temporary and personal documents and files. For performance reasons, it is often a good policy to locate application files, temporary files and personal documents on separate disks or machines. You can therefore better control where the heavier transaction loads are likely to occur, and avoid bottlenecks before they happen.

In cluster configurations, the cluster storage drive should be placed outside the cluster configuration on a fast file server drive, such as a RAID drive. This facilitates sharing if the primary node fails.

The same storage can be shared by multiple servers in the same cluster, or by multiple clusters, provided that they use the same repository.

When you are using an IP redirector with a shared storage configuration, however, you must plan for effective synchronization of the storage area. If you are using a Cisco CCS (Content Services Switch), you will need to configure a disk mirroring system for your storage area in order not to lose users’ personal documents saved in system storage.

504 Gateway Timeout 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.

If a CORBA timeout is returned in response to a Business Objects API call

Error Description When it is sent


Implementing a multihomed configuration

Implementing a multihomed configuration

Figure 10-14 Multihomed deployment configuration schema

NOTE

For a description of this configuration, see page 227.

Implementing a multihomed configuration for Business Objects is simple.

During the configuration of your system, the Configuration Tool detects the IP addresses currently assigned to the machine, and asks you to specify the address you want to use for the Business Objects server. You then simply select one or specify a new address.

Web server

Secondary node

Application server

Secondary node

Internet users

Primary node

RepositoryCorporate database

Network 1: web servers and application servers

Network 2: data access, administration, authentication...



Client machinesClient machines should access the server from a network that can be routed to the web servers. Usually at least one of the networks is not routed to the others, and therefore special attention should be given to where the clients are connected.

Server machinesThe only server machines affected by this configuration are the cluster nodes. Using the Configuration Tool, you can set the ASF on this node to use the right network (the one where the application servers are). Set the connectivity on each nodes to use the network where the databases are.

Servers can be UNIX or Windows machines, with at least two network cards each (not just virtual IP addresses).

ConfigurationWhile configuring the nodes, the Configuration Tool sets which network interface card the ORB will be using on each node.


Implementing a multiple-instance UNIX configuration

Implementing a multiple-instance UNIX configuration

Figure 10-15 Simple multiple-instance deployment under UNIX

NOTE

For a description of this scenario, see page 225.

The server sideThe server machine must have at least 0.5 Gb of RAM per context (per instance).

��Setup

Use the standard Business Objects Installer to create a separate installation directory for each server instance you want to run on the box. You must also run separate installations for each instance’s web and application servers, preferably in the same locations as the Business Objects server instances.

��Configuration

Using the Configuration Tool, you set the port range that will be used by each Business Objects instance, for the ORB and the web server for the Administration Console applets. Business Objects strongly recommends that the person performing the installation/configuration take note of the ports used by each instance and store that information in a central location (for example in a shared file); if the installation of another instance is required, you will therefore know which ports are still available.

Including web and application servers

Context 1 Port 1

Primary Node 1

Context 2 Port 2

Primary Node 2

Network

UNIX box



Run the Configuration Tool from inside the directory where Business Objects is installed to make sure you are configuring the right server instance.

��IP redirector

If the clusters co-existing on the same box use the same repository and storage, clients for both contexts submit requests to the same entry point. In this case you must use an IP redirector to dispatch the request to an available server instance. The instances can be distinguished by a different web server port.

Figure 10-16 Multi-instance configuration with an IP redirector

The client sideThere are no restrictions for client machines beyond what Business Objects supports for clients in any other configuration.

UNIX box

Internet users

1.

2.

All user requests sent to http://server1:8000/wijsp

The IP redirector routes users’ initial requests to the least loaded server instance; this instance then handles all the transactions for that user session.

Primary Node 1

Primary Node 2

IP redirector

Network


Implementing heterogeneous clusters

Implementing heterogeneous clusters

Implementing heterogeneous clusters is little different than implementing a single-platform cluster. You use the Configuration Tool to create and configure the cluster in exactly the same way.

Figure 10-17 Example heterogeneous cluster

In this configuration:• The web and application servers must reside on a UNIX machine.• The primary node must be a UNIX server.• You cannot use Windows authentication.• The cluster can include as many UNIX secondary nodes as required, along

with at least one Windows node.

NOTE

Heterogeneous clusters are often used when a UNIX-based cluster uses an additional Windows node to access Windows-dependent databases. This type of deployment typically uses the Connection Server CORBA-based component for connectivity. For more information, see Deploying Connection Server on page 372.

Internet users

Repository

Application server (UNIX)

Windowssecondary

node

Corporate database

UNIX primary node

Intranet

Web server (UNIX)



Heterogeneous cluster storage considerationsUNIX is case-sensitive, Windows is not. If both Windows and UNIX servers are sharing the same storage, make sure that there are no case-insensitive duplicates in file names.


Implementing a single web server for intranet and extranet users

Implementing a single web server for intranet and extranet users

Figure 10-18 Single web server for intranet and extranet users

NOTE


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.

Extranet users Application

server

Primary node

Intranet

Proxy server

Intranet users

Repository

Database

Web server



Implementing Unicode corporate databases

Figure 10-19 Example international configuration

NOTE


Usersusing French UI,

viewing documentsin French, Japanese

and English

Users using Japanese UI, viewing documents in French, Japanese and English

Users using English UI, viewing documents in French, Japanese and English

Corporate Unicode database storing data in multiple languages

Cluster

Repository (not Unicode)

LAN/WAN USA

France

Japan



Here’s a summary of how to implement the use of a Unicode corporate database:

This section also covers recommended deployment scenarios for Unicode implementations, on page 334.

PrerequisitesIn order to use a Unicode corporate database, before using Business Objects, the following must be installed in your system:

Steps See:

❏ Make sure the requisite fonts and software are installed in the sysem

page 327

❏ Set the correct default JVM in the client web browsers page 329

❏ Update the WebIntelligence Java Report Panel’s mapping on client machines

page 329

❏ Make sure that your Business Objects system’s locales are properly set.

page 334

❏ Configure your universes for Unicode. page 334



NOTE

The URLs in this table are valid at the time of this manual’s publication. Business Objects cannot guarantee their validity after that date.

Requirement Clients and/or Server

Available from...

SUN JVM • Netscape:

version 1.4.1 or later

Clients

http://java.sun.com/j2se/1.4.1/download.html

• Internet Explorer:Version 1.4.2 or later


The fonts required for displaying the languages you are going to use

Note: For documents containing multilingual data, you must use a single font capable of displaying all of of the data in the document.

Clients and server

For Asian fonts:

http://www.adobe.com/products/acrobat/acrrasianfontpack.html

Adobe Acrobat Reader version 5.5 or later

Clients http://www.adobe.com/products/acrobat/arupdate.html



http://www.adobe.com/products/acrobat/acrrasianfontpack.html

http://www.adobe.com/products/acrobat/arupdate.html



Setting the SUN JVM as the default JVM for Internet ExplorerIf your users are using Microsoft Internet Explorer, once you have downloaded and installed the SUN JVM mentioned in the table above, you must set it to be the default JVM in the client Internet browsers:

Figure 10-20 Setting the SUN JVM as the default in Internet Explorer

Updating the Report Panel applet’s font mapping on the clientUsing a Unicode-compliant editor, you must update the system’s font mapping files to map to the fonts you have installed to display multi-lingual data. Located on the Business Objects server and used on the client by the WebIntelligence Report Panels, these files are called fontalias.xml and defaultConfig.xml.

In these files:• font name refers to the name of the font as it appears in format/font lists in

user interfaces.• font file name refers to the full or partial name of the font, with its extension

(such as .ttf or .ttc). You must use a Unicode-compliant editor if you want to modify these files.

To update these files, you must have administrator rights.



��Modifying fontalias.xml

You must modify the fontalias.xml file if users using the Java applet report data content display area need to use additional fonts than those included in the original fontalias.xml file.

The fontalias.xml file is installed on the Business Objects server.• In Windows, this file is located in WINNT\fonts.• Under UNIX, it is in $INSTALLDIR/fonts.

In it:

NOTE

Business Objects recommends that the values for FONT FAMILY /=NAME and FONT ATTRIBUTE /=LOGICAL be identical. For TTC fonts such as MS Gothic, they must be identical; furthermore, the FONT ATTRIBUTE /=PHYSICAL value must be the same, followed by its file extension, a comma, then 1. For example, MS Gothic becomes “msgothic.ttc,1".

If the physical font name contains blanks, such as Courier New, you must enclose the name in single quotes, for example ‘Courier New’.

All fonts used for the TTF platform must be embeddable fonts.

Business Objects does not support Open Type fonts.

fontalias.xml component Value

FONT NAME= Logical name as displayed in WebIntelligence

FONT FAMILY / =NAME Logical name as displayed in WebIntelligence

FONT ATTRIBUTE / =LOGICAL Font name you want to use as installed in your system, such as Arial

FONT ATTRIBUTE / =PHYSICAL Font’s file name, such as arial.ttf

The physical font is what you must install on both client and server machines.



Figure 10-21 Definition for the Arial Unicode MS font in an XML editor

Here is the same definition in the .xml file in a text editor:

Figure 10-22 Definition for the Arial Unicode MS font in a text editor



��Modifying defaultConfig.xml

If users require additional fonts in the Java Report Panel for displaying elements such as filters, lists of values, object names and drill-down lists, you can define them using the physical font name as the VALUE in the CUSTOM_GUI_FONTS section of the defaultConfig.xml file.

The defaultConfig.xml file is located in the $INSTALLDIR\node\<clustername>\$WEBSERVERDIR\<wijsp or wiasp>\scripts\AppletConfig directory on the Business Objects server.

You can define one or more fonts, such as Arial, Arial Unicode MS, etc. Any fonts you define must already be installed on the server and the clients.



Here is what the CUSTOM_GUI_FONTS section looks like in an XML editor (highlighting has been added):

Figure 10-23 Font configuration in XML editor (defaultConfig.xml)

Here is the same section of the file open in standard text display:

Figure 10-24 Font configuration (defaultconfig.xml) in text display



NOTE

For more information on changing the default font used in WebIntelligence, see Font mapping with the fontalias.xml file on page 382.

Setting the system’s localesTo make sure that WebIntelligence documents based on data in Unicode databases display properly in InfoView, Business Objects recommends that the charset and locale be identical for:• the operating system on the Business Objects server• the BusinessObjects 6.5 cluster (set in the Administration Console)• the document domain in the repository

When the repository is created, the document domain is given a name that is used in the paths used to display documents in InfoView. This name is entered using a charset, identified as the document domain charset.

Configuring universes for Unicode supportWhen you create a universe against a Unicode database, you must configure it to support Unicode. For instructions, see the Designer’s Guide.

Recommended basic InfoView deployment schemasThis section contains four recommended basic deployment schemas for international configurations:• Western European language Business Objects server with legacy charset

database• Japanese language Business Objects server with legacy charset database• Western European language Business Objects server with Unicode data

access feature• Japanese language Business Objects server with Unicode data access

feature



��Western European language Business Objects server with legacy charset database

Figure 10-25 Deployment schema 1 for international configurations

• The server’s operating system locale and the cluster’s locale must be the same.

• Documents use Western European languages only.

Corporate databaseLegacy charset

RepositoryLegacy charset


Installed languages: EN/FR/JA

Client 1OS locale: EnglishInfoView user locale: English

Client 2OS locale: FrenchInfoView user locale: French Cluster

Client 3OS locale: EnglishInfoView user locale: French

Client 4OS locale: JapaneseInfoView user locale: Japanese

OS locale: English

Cluster locale: English

Client machines



��Japanese language Business Objects server with legacy charset database


In this configuration, documents are in Japanese and English only.

Corporate databaseLegacy Japanese charset

RepositoryLegacy Japanese charset




Client 2OS locale: FrenchInfoView user locale: French



Cluster

OS locale: Japanese

Cluster locale: Japanese

Client machines



��Western European language Business Objects server with Unicode data access feature


In this configuration:• Operating system and cluster locales must be the same, but can be any

supported Western European language.• Documents can be in any language.

Corporate databaseUnicode

RepositoryLegacy Western

European charset(ISO 5589-1)







OS locale: EnglishCluster locale: English

Client machines

Cluster



��Japanese language Business Objects server with Unicode data access feature


In this configuration, documents can be in any language.

Corporate databaseUnicode

RepositoryLegacy Japanese

charset (SJIS)







OS locale: Japanese

Cluster locale: Japanese

Client machines

Cluster

ch

ap

ter

Deploying and Managing the Repository



OverviewThis 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 Business Objects session


Choosing a repository database


Administrators who have the opportunity to choose a database platform for their repository are advised to consider the following issues:• databases which support row-level locking• databases which support binary strings• the maximum allowed number of open connections

Row-level lockingAs 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.



Binary data type supportBinaries are a common data type on many relational database systems. They include BLOBs (Binary Large Objects), BYTE, IMAGE and other types.

When users exchange documents via the repository, the documents are stored in the document domain. The binary content of a document is sliced into units of a defined length and stored in slices in the OBJ_X_DOCUMENTS table of the document domain. Depending on its size and the length of each slice, a single document might be stored in one or more rows in that table.

For each database version, this data is stored in a column of the OBJ_X_DOCUMENTS table that is defined either as a binary string or a (VAR)CHAR string column. If the database supports binary types, the driver will use this type. If not, the driver will convert the binary data to character data and use a VARCHAR type.

With BusinessObjects, you can vary the length of the binary slice to take advantage of the optimal size for each database system. The larger the binary slice, the fewer rows will have to be inserted for each document stored in the repository. This factor can have an enormous positive impact on performance and network traffic.

Business Objects therefore recommends that you select a repository that supports long binary columns.

��Automatic binary slice management in BusinessObjects

Because of the differences in the various RDBMS that may be used, the default binary size used is optimized for each RDBMS, and will therefore differ from one to another.

��Which RDBMSs support binary strings?

Not all RDBMSs support binary types. Where binary strings are not supported, (VAR)CHARs are used instead to store your documents. For more information, see your database documentation.



Maximum number of open connectionsThe performance of the database engine can play a significant role in overall system performance.

A large data warehouse need not limit BusinessObjects functionality or performance. Users in some deployments can access tables with over 5 million rows with a response time of a couple of seconds. However, performance can be affected by the associated indices, the size of the query, and the physical distance between the Business Objects server and the data warehouse.

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.



How much space should you allot for the repository?

When initially installed, the Business Objects repository takes up roughly one megabyte and its size increases as data is added.

The security and universe domains expand relatively little per user, group or universe.

It is the document domain that typically takes up the most space, and even that is probably insignificant in comparison to the size of your database. Its size is simply equal to the sum of the documents it contains, rounded off to the highest 10 KB.

The security domainThe security domain is the core of the repository and is used to store all information about users, the groups they belong to, the applications and features they can use, the universes they have access to, the documents they can share, and the list of tasks submitted to Broadcast Agent.

��Space requirements per user

The disk space required for each Business Objects user in the security domain varies widely according to your security structure, the user’s activity and access rights. Here are just some of the factors you can take into account (the numbers are approximate):• Each user created by the supervisor requires some 200 bytes of disk space

in the security domain.• For each group to which a user belongs, you must count an additional 50

bytes.• Each document or file sent to the user, as well as each attachment to

documents distributed by Broadcast Agent requires another 10 bytes.• Each security restriction for the user (access to documents, security

commands, timestamps and so forth) counts for 50 bytes.• Each time you assign a universe to a user, it costs 550 bytes.• Broadcast Agent jobs submitted by users require 1.5 KB apiece.

After that you need to take into account the indexing of universes and documents used by the user, the user’s connections, domains and categories.


How much space should you allot for the repository?

To be safe, we consider that you can calculate the initial required disk space for the security domain using this formula:

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 user’s rights by executing SQL to compare and compile the rights for the user in each group.

The universe domainThe universe domain is used to store the contents of each shared universe. This is the area to which designers can export the universes that they create. Each universe is a meta-model of the related corporate database.

In general, universe files (*.unv) take up about 0.5 MB each. These files are not, however, stored as is in the universe domain; each universe’s structure is stored in different tables and it therefore takes up more space than its .unv file alone.

NOTE

The 0.5 MB figure is twice the size of the average .unv file, but it is advisable to include a sizable margin for safety.

The document domainThe document domain is used to store the contents of each shared document and file. This is the area to which users can publish Business Objects documents, or upload other types of files, to be shared by all users. This is also where documents such as templates, scheduled documents, and documents or files sent from users to other users are stored. Broadcast Agent accesses the document domain to run automated Business Objects document-processing tasks.

The size of documents can vary greatly depending on the application with which they were created, their complexity and their content. For example, we estimate that the .rep files representing BusinessObjects documents generally run from 500 KB for a small document, to 8 MB for a large document.



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

Before any type of file or document other than those with add-ins (BusinessObjects, WebIntelligence or third-party) is sent to the repository, it is compressed. BusinessObjects also has extended support for BLOBs, yielding better performance (results also depend on the BLOB-handling capabilities of your database).

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.


The location of repository domains

The location of repository domains

Do all the domains in a repository have to be on the same server?

No. By default, when you first create a repository, you create the security domain plus one document and one universe domain on the same server.

As general supervisor, however, you can subsequently create additional document or universe domains on any server on which you have the appropriate rights. You can even create these additional domains using other data accounts or other RDBMSs. Be aware, however, that if you use another RDBMS, users will require the installation of the drivers and connectivities needed to access the various databases.

NOTE

Within a single repository on a single server, you cannot create more than one document or universe domain using the same data account (for DB2, this extends even to the same owner).

Creating multiple document and universe domains and distributing them over several servers can be particularly practical if deployment conditions (size of active user population, transaction load, available memory) no longer allow maximum performance.

This distribution also relieves the transaction load on the initial server machine and frees up memory for processing.

Geographically dispersed deploymentsThis type of distribution can be a good solution for geographically dispersed deployments as well. Having one centralized security domain, for example, with decentralized, site-specific universe and document domains, can minimize processing request response times (the corporate data is physically closer to the machines doing the processing). It also makes universe and document access less reliant on the WAN.



��Shared, single security domain vs. multiple repositories

By sharing the security domain among multiple, geographically distributed document and/or universe domains, you facilitate both the management and maintenance of users, and the migration of documents and universes.

If you deploy a separate repository for each of the physical environments, the migration of WebIntelligence reports 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 147.


Deploying and using multiple repositories


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

Choosing a repository for a sessionIn multiple repository configurations, how users choose the repository they want to work with varies according to the product they are using.

��Choosing the repository for a Business Objects session

If the supervisor sets up multiple repositories and grants users access to more than one of them, when users attempt to log into BusinessObjects, they can select the security domain to which they want to connect for the current session. As there is only one security domain per repository, this designates the repository itself.

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 file’s name is bomain.key, but for BusinessObjects you can define any name you want.

��Choosing a repository for an InfoView session

The web has a different paradigm than a 2-tier application. A different approach to repository selection is therefore required for the web-based InfoView.

When InfoView users log in using their web browsers, the system refers to the .key file stored on the primary node. The users are unaware of the .key file, and in effect select the repository by selecting the URL of the system using the desired repository.

Instead of defining .key files with different names, administrators can set up multiple clusters, each of which points to a different repository. Users can select which one to go to by picking the appropriate URL. As bookmarks are available in every browser, it is even easier to let users choose the right repository. This approach preserves the single .key file for each Business Objects site, a more efficient approach for the administrator and for the end user.

Synchronizing data between multiple repositoriesAlthough BusinessObjects users can select the security domain (and therefore, the repository) with which they want to work at login, no allowance is made for transparently sharing secured resources such as universes, connections and documents between repositories.



Suppose you start out with a single repository and security domain, and a very large number of users. To improve network performance, you duplicate your configuration and allocate half your users to the new repository. As time passes, your repositories and database information will change, and the two configurations will slip out of synchronization.

If it is important that users of all repositories have access to exactly the same data, then you have two options:• You can periodically log into the remote repository or repositories as a general

supervisor, import the documents you require, then log into your local repository and export them there. Users of the local repository will be able to read the documents but not refresh them.You can develop code to automate this procedure.

• You can periodically copy the entire corporate database and repository tables from one location to the other. This means that only the repository used as the source of this copy (Repository1) can evolve safely — any changes to the other repository, (Repository2) to which the copy is made, will be lost with the copy.The security domain in any repository contains connections to the universe and document domains. When you copy Repository1 over Repository2, you are also copying these connection definitions. The result is that Repository2 will still contain the connections to the original universes and document domains in Repository1. Before being able to use Repository2, then, you'll need to log into Supervisor as General Supervisor, choose Tools > Repository, then change all the connections to re-point to the copied locations.

When implementing either of these solutions, make sure you prohibit all user access until the operation is completed.

Moving the location of resources within or between repositoriesYou can move documents and universes between domains within the same repository, or to another repository entirely.

��Moving documents from one document domain to another

To move documents from one document domain to another within the repository, simply save them to the new document domain from InfoView, then delete the original documents from the original document domain.



��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 Designer’s 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.



Optimizing the security domain

You create the structure and complexity of the security domain when you create users, user groups and their rights using Supervisor.

The design of the security domain, the number of users, number of levels, and the complexity (number of times users repeat in different groups) will affect login time for your deployment. For this reason Business Objects recommends a broad, flat security structure with as few hierarchical levels and as little replication of users in different groups as possible.

NOTE

Because of the introduction of the new module WILoginServer, a multi-level security structure decreases performance significantly less drastically than with previous releases.

The speed of the database engine containing the repository can also play a significant role in overall system performance.

You can also optimize the Business Objects security domain by running it on a dedicated machine.


Making documents available to users of other repositories

Making documents available to users of other repositories

If you also check the Save for all users option in BusinessObjects when saving your documents locally, users to whom you send the documents (and this applies to sending documents by email as well as through the system) will be able to access them even if they do not have access to the repository in which the document was stored.

How does this work? Normally, for security reasons, a document that is stored in the repository also contains the repository ID. This means that the document is only accessible to users who have access to this particular repository. The Save for all users option clears the repository ID from the document. The document is then available to all users to whom it is sent, no matter what repository they work with.



Changing a cluster’s repository

The repository used by a cluster is defined by the cluster’s bomain.key file. To change the repository you therefore have to replace one key file with another.

When users log into a cluster’s repository, all their identification and access data is retrieved from the repository and cached in an .lsi (for Local Security Information) file. This file serves as the cluster's repository security cache concerning that user.

The Business Objects system also dynamically caches documents and universes that have been accessed by users in its storage areas.

When the system processes subsequent requests for these items, instead of requesting the user’s security information from the repository again, it simply uses its .lsi file to determine the user’s identity, and whether the user has the appropriate access rights.

When you change a cluster’s repository, the information in the cluster’s new .lsi file no longer corresponds to the repository associated with the documents and universes in the storage folders.

To avoid incorrect results, you must either flush the cluster’s storage folders or archive their contents in a different location.

ch

ap

ter

Deploying Specific Components and Products



OverviewThis 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 287.

This chapter contains the following sections:• Overall 3-tier deployment guidelines• Choosing your applications and how they are deployed• Deploying Connection Server• Deploying InfoView/WebIntelligence• Deploying BusinessObjects in 2-tier mode• Deploying BusinessObjects in 3-tier mode• Deploying Broadcast Agent• Deploying Auditor


Overall 3-tier deployment guidelines


This section provides solution-wide deployment guidelines which can impact how you deploy specific products.

Running desktop and server products on the same machinesRunning BusinessObjects in 2-tier mode on the same machine as a Business Objects server used in a 3-tier configuration is not supported for this reason: When Broadcast Agent or InfoView are running, they automatically launch and stop BusinessObjects instances. On the same machine, these system sessions could interfere with the 2-tier BusinessObjects user session.

ASP or JSP?The 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

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. For example, you can use IIS as your web server and WebLogic as your application server in a JSP environment.

You choose your environment based on the following types of considerations:• Platforms• Available features or products• Performance• Security in general• Error handling• Ease of migration to Application Foundation

For one last consideration to be taken into account, see If you’re using Windows.

��Platforms

If you’re using Windows, you can choose between ASP and JSP.

If you’re using a UNIX operating system, you must use JSP technology.



��Available features or products

Your choice of an ASP or JSP environment limits/enables the use of different Business Objects features. For the following features or attributes, you must have a JSP configuration:• WebIntelligence HTML Report Panel• Interactive viewing of WebIntelligence documents in InfoView• BusinessObjects Auditor• the Administration SDK• Supervisor over the Web

��Performance

Although no official benchmarks comparing the two technologies have been run, Business Objects surmises that the performance obtained with either type of deployment is similar.

Why? Beyond the actual transport of data within the system (i.e. COM/DCOM for ASP, or Java CORBA for JSP), the processing of requests is carried out by the same Business Objects system components — and it is precisely these processes that consume the most system resources.

��Security in general

The use of IIS has raised some troublesome security issues. Although IIS can be part of an ASP or JSP deployment, you must use it if you have an ASP environment.

Using a servlet engine with a Java application server is a step more secure.

��Error handling

Java comes with built-in exception handling, which means that it is easier for the application to recover from errors, or at least present a meaningful error message without crashing the server.

��Ease of migration to Application Foundation

If you are currently using BusinessObjects Enterprise 6.1 and are planning to additionally deploy BusinessObjects Application Foundation, migration will be easier if you are using JSP.

Version 6.1 of Application Foundation supports IIS, but only with a WebLogic application server, and this in a JSP environment.



��If you’re using Windows

Last but not least is the often overlooked consideration of your own knowledge and experience in deploying ASP/JSP.

f you plan on deploying BusinessObjects 6.5 in a Windows environment, you can choose either ASP or JSP technology. In the end, despite the concrete advantages and disadvantages inherent in each type of deployment, you may also choose simply to use the type of technology with which you are most familiar.

For example, if you are familiar with IIS as a web/application server but not with WebSphere, you may be saving yourself considerable time and trouble by choosing an ASP deployment. And vice versa.

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

��Selecting languages at installation

When you install Business Objects products, you install all the languages in which you want products to be available, then you choose a default language for the products.

��Setting a cluster’s locale

All the servers in a cluster must use the same locale.

You can change a server’s locale by re-running the installation procedure or running an update procedure, but it’s easier to do it just by using the Site Properties tab in the Administration Console, then rebooting the cluster servers.



��Setting user locales

Users can also set the locale in which they want to work with Business Objects products. • In InfoView, users can choose their desired interface language from among

the languages installed on the Business Objects server in the Options pages.If a user doesn’t set a locale, the InfoView/WebIntelligence 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.

��Reconciling locales and charsets

When deploying InfoView/WebIntelligence, you must manage a series of locales and charset requirements:• Every operating system has a locale.• Business Objects clusters also have not only a default locale, set in the

Administration Console, but the various user locales required by multilingual deployments, which allow users to display the InfoView/WebIntelligence interfaces in the language of their choice.

• The repository is also implemented on a relational database which is developed using a specific charset, or set of supported characters.



What do you need to know to make all these locales work together? 1. All the servers in a cluster must have the same default locale.2. The operating system locale on Business Objects server machines must be

the same as the cluster’s default locale.3. The charset defined by the cluster’s default locale must be included in the

repository’s charset to ensure that users will not enter characters that the repository database will not be able to store.

NOTE

For more information on locales and multilingual deployments, see Implementing Unicode corporate databases on page 326.

For more information on font requirements, see BusinessObjects and fonts on page 391.



Choosing your applications and how they are deployed

The following sections provide an overview of the architectural differences between deployments of BusinessObjects in 2- or 3-tier mode, and InfoView. The sections focus on the differences in communication protocols and in the distribution of application processes between the three deployment types.

TIP

For a detailed functional comparison of WebIntelligence, InfoView, and BusinessObjects in 2- and 3-tier modes, see How Products Compare Functionally on page 475.

Deployment comparisonsThis 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 367 uses this information to present recommendations on choosing a deployment scenario.


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.



This diagram shows the relationship between the client and the server in 2-tier mode:

Figure 12-1 2-tier BusinessObjects deployment

busobj.exe

Repository

Corporate database

RDBMS connectivity

BusinessObjects

document (.rep)

User interface

Client with database connectivity and BusinessObjects installed

Application interface

Report engine

Calculator

Query technique

Cube

Database connectivity



��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:

Figure 12-2 BusinessObjects document viewed in InfoView

SQL

SQL

Query

Display

Business Objects middle tier

Web browser only:

no installation on

client

Read-only versions of .rep files

User interface

HTTP layer (client)

HTTP

communication

HTTP layer (server)


Report engine

Calculator

Query

Cube


Repository

Corporate database

BusinessObjects

document (.rep)

busobj

bolight

WIQT



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 12-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 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.



The following diagram shows the relationship between the client and the server in 3-tier mode:

Figure 12-3 3-tier deployment of BusinessObjects

Unlike the 2-tier client, the 3-tier BusinessObjects client cannot directly access the Business Objects repository or the data warehouse. The data resulting from the query is transferred through the server to the 3-tier client via HTTP.

busobj.exe

HTTP communication, binary content

SQL

HTTP Layer (server)


SQL

Client hosting busobj.exe with no connectivity

Business Objects middle tier

Repository

User interface


Report engine

Calculator

Query technique

Cube

HTTP layer (client)

HTTP translation

BusinessObjects document (.rep)

Corporate database

WIQT



2-tier, 3-tier BusinessObjects, or InfoView?The following sections provide information on the factors involved in choosing the appropriate application(s) for your deployment.

The performance of any system, and of any application, depends on a large number of interrelated factors. Based on the performance bottlenecks you perceive in your deployment, one or several of the factors may take precedence over the others.

No two deployments are alike; there are therefore no absolute recommendations. For this reason, the impact of each factor is analyzed separately. It is up to you to decide which factor(s) are most relevant to your deployment.

��Functionality available only in 2-tier BusinessObjects

2-tier deployments offer functionality not available with InfoView or 3-tier deployments of BusinessObjects, including:• document creation using OLAP data sources (note that you can refresh OLAP

documents in 3-tier mode)• document creation using stored procedures• document creation using freehand SQL

��System resources

3-tier deployments of BusinessObjects leverage more resources on the client machine than InfoView, whose deployment requires only a browser on the client side. In 3-tier BusinessObjects, both the microcube and the report engine are located on the client.

When a user requests a BusinessObjects document in InfoView, only the HTML or PDF resulting from the query is transferred to the client. In 3-tier BusinessObjects, both the query and the data fetched from the database are transferred to the client.

The following table displays the different considerations in terms of system resources for each deployment type.



Criteria Deployment type/usage

BusinessObjects deployment type

InfoView (Read, refresh only)

2-tier 3-tier

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

�



��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:

Distribution of user types in a typical deployment

This diagram is a general example. The actual proportion of each type of user depends on the specific deployment.

NOTE

For definitions of these user types, see Types of users on page 136.

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.

Power users

Analysts

Readers and Interactive users combined



EXAMPLE

Defining user population needs

Based on the user descriptions for the model deployment listed above, the following table lists the user types and the application they require:

��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.

User type Percentage of total user population

Deployment type/usage

Readers and Interactive users

70%-80% InfoView is generally the most efficient solution for this user type

Analyst 15%-25% 3-tier BusinessObjects, InfoView

Power user 5% 2-tier BusinessObjects, WebIntelligence, Designer, Supervisor



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, and intermediary servers.

If users only need to view and refresh BusinessObjects and WebIntelligence documents, however, InfoView may be a more efficient choice.



Deploying Connection Server

Connection Server is the software layer that allows BusinessObjects, InfoView and WebIntelligence users to connect to and/or run queries against a relational data source, whether it is a corporate database or a repository.

Connection Server is available in two modes:• Library mode• As a CORBA-based server component

These two modes can work separately, or alongside each other in the same cluster, depending on your needs. To understand your Connection Server deployment possibilities, you must understand what each type of Connection Server is, and how it works.

Connection Server and data access driver installationBusiness Objects recommends that on a given cluster node you install only those Data Access drivers for which the database clients are also installed on the node.

For example, do not install a Business Objects access pack for Oracle on a node if the Oracle Net client isn’t installed on the same node. If the client is not installed, when the node receives a processing request with an Oracle target, Connection Server will try to load the Oracle library, and an error will be generated.

Connection Server in library modeConnection Server in library mode is automatically installed on client machines whenever a Business Objects data access driver is installed with Designer, Supervisor, or BusinessObjects. In this case, the Connection Server library layer is available only to the products on that machine.

Connection Server in library mode is also automatically installed on servers whenever a data access driver is installed on the machine.

Connection Server as a CORBA-based server componentIn a server environment, Connection Server is also available as a server component, automatically installed on the server whenever Business Objects server is installed. This server component uses CORBA to communicate with the other nodes in the cluster, and uses the middleware installed on the server machine to create connections to the repository and/or corporate databases.

3-tier deployments of BusinessObjects require this type of Connection Server in order to interact with the repository or corporate data sources.



In this mode, Connection Server uses two different protocols to communicate:• It uses CORBA to communicate with the InfoView and WebIntelligence

clients, with the help of a CORBA proxy on the client.By default, however, requests requiring access to the repository or corporate databases are run through library mode, if the appropriate driver is installed on the node servicing the request. For although this type of Connection Server allows for greater deployment flexibility, processing is faster when it is carried out locally on the same server machine.

• For all communication with the client in 3-tier deployments of BusinessObjects, Connection Server uses the HTTP protocol, along with a .dll functioning as an HTTP proxy, automatically installed on the client along with BusinessObjects.

How Connection Server works in a clusterThe availability of Connection Server in these different modes not only provides for more flexible deployment possibilities (you can, for example, configure a cluster node as a dedicated connectivity server), but it also allows UNIX-based clusters to access RDBMSs hosted only on Windows machines. All you have to do is add a Windows secondary node with the correct driver installed on it, then enable the CORBA-based Connection Server component on it. This makes the cluster a heterogeneous cluster (see page 232 for more information).

Here is an example of how Connection Server works within a cluster:

You have a heterogeneous cluster with a UNIX primary node and a Windows secondary node. On the Windows node, Microsoft SQL Server ODBC middleware is installed, and Connection Server is enabled as a CORBA-based server component.

A client request to refresh a BusinessObjects document whose data source is an SQL Server database on a Windows database server.

To process the request, the bolight process on the UNIX node first contacts the Connection Server installed locally in library mode. When it does not find an SQL Server data access driver, it then sends a CORBA call to the other node in the cluster. This call is received by the Connection Server component on the Windows node. As the correct middleware is installed on the machine, the request is processed.



Figure 12-1 Accessing a Windows RDBMS from a UNIX server

Administering Connection ServerYou administer Connection Server using the Administration Console, where it is independent of the Session Stack.

Using the Administration Console, you can enable/disable the Connection Server, as well as define the number of instances in the Connection Server pool on any particular node.

Deployment architectures for Connection ServerThis section describes some of the most common deployment scenarios for Connection Server in a 3-tier environment:• Using library mode only• Using server mode only• Using library and CORBA modes for connecting to different RDBMSs• Using a dedicated Connection Server cluster node• Using multiple dedicated Connection Server nodes

NOTE

In this section, cluster nodes labelled Business Objects server indicate nodes on which the Business Objects server option in the Installer has been installed, and on which the Session Stack has been activated for document processing. Remember that the Connection Server server component is automatically installed on a node whenever Business Objects server is installed.

Users on clients

Intranet

Windows databaseserver

UNIX cluster nodeBusiness Objects server

Connection Server (library) Windows cluster node Connection Server (CORBA)

SQL Server middleware

SQL Server



��Using library mode only

Figure 12-2 Cluster with Connection Server in library mode only

This is the most basic Connection Server deployment.

The data access driver is installed on a cluster node, so Connection Server is also installed on the node in library form. The node’s Connection Server server component is disabled.

NOTE

3-tier deployments of BusinessObjects cannot function in this scenario, as this application requires the Connection Server server component to connect to RDBMSs.

RDBMS

Users on

clients

Intranet

Business Objects server Connection Server (CORBA) is disabled

Connection Server (library) RDBMS middleware



��Using server mode only

Figure 12-3 Cluster with Connection Server in server mode only

In this scenario, no data access driver has been installed on Cluster Node 1, so it doesn’t host a Connection Server in library mode. The Connection Server server component installed automatically with Business Objects server has been disabled.

Cluster Node 2 hosts an enabled Connection Server CORBA component. All the cluster’s RDBMS requests are therefore directly or indirectly (via Cluster Node 1) routed through this node.

This configuration can be useful in heterogeneous clusters which use a UNIX primary node for its power, but in which all cluster’s RDBMSs are hosted on Windows machines.

Users on clients

Intranet

Cluster Node 1


Connection Server (CORBA)

is disabled

RDBMS

Cluster Node 2


Connection Server (CORBA) RDBMS middleware



��Using library and CORBA modes for connecting to different RDBMSs

Figure 12-4 Connection Server deployed in both library and CORBA forms

In this scenario, access drivers are available on Cluster Node 1 with Business Objects server running on them; Cluster Node 2 is a dedicated remote Connection Server node running with both Connection Server in library mode (automatic with the installation of middleware on the server machine) and the CORBA-based server component activated.

When the client sends a request, the system uses the local access driver if it exists. If it is not installed on the local machine, the request is routed to a remote Connection Server that’s on a machine hosting the correct middleware.

This type of scenario might be useful for load balancing among the cluster nodes. For example, you might use Cluster Node 1 exclusively for logins (the middleware installed on this machine provides access to the repository only, and you disable WILoginServer on Cluster Node 2), and Cluster Node 2 for all processing requiring access to corporate data sources.

RDBMS AUsers on

clients

Cluster Node 1

Cluster Node 2RDBMS BBusiness Objects server

Connection Server (CORBA) optionalConnection Server (library)

RDBMS middleware A

Business Objects server with

Session Stack disactivated


Connection Server (library)

RDBMS middleware B

Intranet



��Using a dedicated Connection Server cluster node

This scenario involves a cluster containing multiple Business Objects servers, with a single, dedicated Connection Server node:

Figure 12-5 Multiple processing nodes and a dedicated Connection Server node

You can configure a cluster node to act as a dedicated Connection Server node by disactivating all the other Business Processes processes running on the node. This can be a useful solution when you have a repository on Windows, and your data account on a UNIX server.

For example, you have a Teradata data account. The cluster contains three nodes running BusinessObjects server on UNIX. The repository has limited performance on Teradata, and you need a solution that is not too costly but effecient, so you install your repository on Microsoft SQL Server that runs on Windows.

To resolve the Windows/UNIX compatiblity, you need to either install ODBC Data Direct on each node to access the Windows repository, or have all access to the repository pass by one node using the standard ODBC driver to access the SQL Server repository. The second option using a dedicated Connection Server node is the cheapest solution, as the ODBC standard is free.

��Using multiple dedicated Connection Server nodes

In this architecture, the use of multiple dedicated Connection Server nodes provides load balancing and failover.


Intranet

Users on clients

Business Objects serverRDBMS


RDBMS middleware



Figure 12-6 Cluster with two dedicated Connection Server nodes

This scenario can be useful in deployments with large numbers of concurrent accesses to corporate databases, and returning small quantities of data for each query.

Users on

clientsIntranet

Business Objects server Connection Server (CORBA)

disabled

RDBMS


RDBMS middleware


RDBMS middleware



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 uses 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.

Configuring InfoView to access a Unicode databaseInternational deployments often use Unicode databases, which can store information in a variety of languages.

To access WebIntelligence documents using data in a Unicode database from InfoView, follow the instructions in Implementing Unicode corporate databases on page 326.

For information on font management, particularly important in mulitlingual deployments, see Managing WebIntelligence/InfoView fonts on page 381.

The WebIntelligence Java Report Panel

��Technology required

To run the WebIntelligence Java Report Panel, you must have the required versions of Internet Explorer/Netscape and Java Virtual Machine (JVM). To find out which versions you need, check the latest Product Availability Report (PAR). As of this writing, the PAR can be accessed from the following URL:


To access this site, you must be registered for Business Objects online customer support.

You can run the Java Report Panel with either ASP or JSP.




��Rights required to download the Report Panel• The security command Use WebIntelligence Java Report Panel must be

enabled in Supervisor.• In Windows 2000, you must be logged onto the PC as a Windows user with

an Administrator or Power User security profile, and you must have the right to write in the following registry key and sub-keys: HKEY_LOCAL_MACHINE\Software\Microsoft\Code Storage Database

��The size of the Java Report Panel

Once the Java Report Panel is installed on the client computer, it takes up 3 MB.

The CAB file which is actually downloaded, however, contains a compressed version of the applet whose size is only 840 KB. This speeds up the time required for the download, and is especially critical if the panel is being downloaded through a modem or over a low bandwidth network.

After the file is downloaded, it is then uncompressed locally. Installing the panel after the download is done takes some time but it requires only client computer processing.

The WebIntelligence HTML Report PanelYou can run the WebIntelligence HTML Report Panel only with JSP.

In order to use the HTML Report Panel, the Use WebIntelligence HTML Report Panel security command must be enabled for the user or group in Supervisor.

Managing WebIntelligence/InfoView fontsWebIntelligence uses different fonts for the font choices listed in the Java Report Panel combo boxes, and the three presentation formats you can use for the WebIntelligence reports you create:• charts and PDF formats• HTML• Microsoft Excel

In font management terms, these examples of font use are called platforms. The Business Objects system maps the fonts it finds in report definitions to physical fonts using a file on the server called fontalias.xml.



Where does WebIntelligence find the fonts used in reports? On the machine where the report is rendered:• For reports in HTML or Excel formats, the report is processed on the server

but actually rendered in the client browser, using the physical fonts installed on the client machine.

• Reports in PDF format, as well as the charts used in PDF or HTML reports, are rendered on the Business Objects server, where the fonts are actually embedded in the report file. To do this, the server uses physical fonts installed on the server machine.

��Font mapping with the fontalias.xml file

The fontalias.xml file is a customizable font mapping file installed on cluster nodes along with the Business Objects server software:• In Windows, this file is located in WINNT\fonts.• Under UNIX, it is in $INSTALLDIR/fonts.

This file is a series of font descriptions; for each font, such as Arial, the description contains definitions for each of the font platforms associated with the font and used with Business Objects.



Here is the first part of an example fontalias.xml file, which describes two fonts, Arial and Courier New:

Figure 12-7 Part of a fontalias.xml file

Let’s take the definition for Arial as an example. Note that a <FONTFAMILY PLATFORM> tag is used for each of the four Arial platforms used in WebIntelligence: • ttf, used for generating reports in PDF format, as well as for charts

Note: TTF fonts are TrueType fonts. You must have a license to insert them in PDF files.

• win, used for generating reports in Excel format• java, used for the fonts displayed in combo boxes in the WebIntelligence Java

Report Panel• html, used for generating reports in HTML format



TTF font mapping

The description for the Arial font used to generate charts and reports in PDF format (where <FONTFAMILY PLATFORM> = “ttf”) is more complex than the descriptions for the other platforms, because PDF reports are generated on the server, not on the client.

Each font style, such as Bold, Italic, or Bold Italic, is defined separately, using a <FONTATTRIBUTE> tag. A logical name is defined for each style, and its properties are defined using “true” or “false” values for the BOLD and ITALIC parameters.

Each style definition includes the style’s logical name as it appears in the Report Panel’s combo boxes, and its physical name, which is the actual name of the font’s file. This file should be installed on the server machine.

Note that multiple physical font names can be defined for a single font style, as the names of the files may vary from one operating system to another. If the operating system can’t find the first file, it uses the next. If no specified font file exists on the machine, it uses the default font. See the following section.

The default font

At the bottom of the fontalias.xml file is a section defining a default font, which is used if the system cannot find a physical file corresponding to the required logical font.

You must make sure that at the very least, this font is installed on all cluster nodes and all client machines.

How fonts are managed on server machines

The physical fonts installed on Business Objects server machines are listed in the Registry on Windows servers, and under UNIX, the boconfig.cfg file, located in the $INSTALLDIR/nodes/<hostname>/<clustername> directory.



For the Business Objects system, two registry keys are critical to font management:• FontRoot indicates where the fontalias.xml file is located on the server.• SystemFonts points to the directories in which the fonts are installed

physically. - Under Windows, this is usually WINNT\fonts.- On UNIX boxes, multiple directories may be defined; a colon separates multiple paths for this key (with “/” at the end), for example:“/usr/lib/xll/fonts/:/opt/fonts”/

Another key, AltSystemFont, defines directories containing alternate fonts which may not be used under the same circumstances or with the same frequency as those mapped in the SystemFont key. This mechanism allows you the freedom not to install all fonts in the same directory (you could, for example, install Western language fonts in one directory, and Chinese, Japanese, and Korean in another).

The System Font and AltSystemFont keys can point to a shared font directory on another node in the cluster. For example, a UNIX machine can map to a Windows machine.

NOTE

You must have the correct Microsoft license to legally allow a Business Objects server running on a UNIX operating system to share the fonts on a Windows server.



How the system locates physical fonts

When a particular font is called for in a document definition being processed on the Business Objects server, the server checks the fontalias.xml file:• If the requested report presentation is HTML or Excel, the server checks the

html or win font platform definition for the requested font name; the server sends the information back to the client machine, where its operating system checks the SystemFont key in the Registry for the location of the physical fonts. It then looks in the directory defined by that key to locate the physical font file associated with the logical font name. If it doesn’t find the first font, it looks for the next font listed in the NAME parameter. For example, take this definition for the html platform for Arial:<FONTFAMILY PLATFORM="html" NAME="Arial, Helvetica, ��’Courier New’, ’Times New Roman’" />

If the system doesn’t find the Arial physical font (the first value for NAME), it then looks for Helvetica. If it doesn’t find Helvetica, it looks for Courier New, and so forth. If the system can’t find any of the listed fonts, it uses the system’s default font defined at the bottom of the fontalias.xml file.

• If the requested report presentation includes a chart, or is in PDF format, the server checks the ttf font platform definition in fontalias.xml for the requested font name and style, then checks the Registry’s SystemFonts key to locate the physical font file associated with the logical font name. If it doesn’t find the font in one of the directories defined for the key, it looks in the directories defined for the AltSystemFonts key.

��What you need to know about installing fonts

Languages and fonts must be supported on the client machine for correct report display. In addition, all fonts, whether on the client or server machines, must be correctly defined in the fontalias.xml file on the server.

UNIX servers

Some UNIX operating systems, such as AIX, provide relatively few fonts by default. You may want to purchase additional fonts from your operating system vendor for more choice in rendering charts and PDF reports.

Windows machines

On Windows machines, Business Objects recommends that you take advantage of the wealth of fonts provided by the Windows operating system. When you install the Windows operating systems on client machines, Business Objects recommends that you select the Required option for font installation.



Ideally, you should use the same set of fonts on all servers, putting them in a shared directory. If you want, you can make a shared font directory on a Windows machine available to all the servers in the cluster, even to UNIX servers in a heterogeneous cluster. In this case, use the same fontalias.xml file on all the server machines, and make sure that the font names defined in it include the name variants across all the operating systems you’re using.

Adding fonts to the Business Objects system

To add new fonts to any client or server machine in your Business Objects system, you must:1. Install the fonts in a referenced font directory on both client and server

machines, making sure the languages that use the fonts are supported on each machine.

2. In the machine’s SystemFont key in the registry, add a new <Font> key referencing the font.

3. Modify the fontalias.xml file on all cluster servers to include the new fonts, using the correct format.Here are some guidelines for adding fonts to fontalias.xml:- Business Objects recommends that the values for FONT FAMILY /=NAME and FONT ATTRIBUTE /=LOGICAL be identical. For TTC fonts such as MS Gothic, they must be identical; furthermore, the FONT ATTRIBUTE /=PHYSICAL value must be the same, followed by its file extension, a comma, then 1. For example, MS Gothic becomes “msgothic.ttc,1". - If the physical font name contains blanks, such as Courier New, you must enclose the name in single quotes, for example ‘Courier New’.- All fonts used for the ttf platform must be embeddable fonts. Check the font’s properties to make sure. In addition, make sure you have the proper license to embed TTF fonts in PDFs.

NOTE

Business Objects doesn’t support Open Type fonts.

��Modifying default interface fonts for WebIntelligence Report Panels

You can modify the default fonts (and other settings) used in the creation of WebIntelligence reports by modifying the configuration files for the WebIntelligence Java Report Panel and the HTML Report Panel. These settings determine the appearance of charts, PDFs, and other elements of reports in the Report Panels.



If you are actually adding a new font to WebIntelligence, you must also add the font to the fontalias.xml file, as described in the section above.

Changing the default interface fonts for the Java Report Panel

You modify the default fonts for reports created in the WebIntelligence Java Report Panel by modifying the defaultConfig.xml file on the Business Objects server:• For ASP deployments using IIS, this file is located in

$INSTALLDIR\<hostname>\<clustername>\IIS\1\wiasp\scripts\AppletConfig\

• For JSP deployments using Apache, this file is located in $INSTALLDIR\nodes\<hostname>\<clustername>\APACHE\MasterWebServer-<port>\wijsp\scripts\AppletConfig\

To customize the default font for the Java Report Panel:1. Make a backup of the defaultConfig.xml file.2. Open the defaultConfig.xml file.3. Find the “key value” section that corresponds to the element you want to

change.For example, here is the key-value section for body cells in a table:

Figure 12-8 A key-value section in defaultConfig.xml

4. To change the default font for specified languages, enter the font name after FACE=.For the example in Figure 12-8, to change only Japanese to a font named “SpecialFont,” you would enter:<FONT xml:lang="ja" FACE="SpecialFont" ...

5. To change the overall default font for all non-specified languages, enter the new font name after FONT FACE=.



REMINDER

You must modify the default font values separately for each element you want to change.

6. Modify any other attributes you want, such as font size.7. Save and close defaultConfig.xml.

Changing the default interface fonts for the HTML Report Panel

You can change the default fonts used in the WebIntelligence HTML Report Panel by modifying the config.js file.

In Tomcat JSP deployments, the file is located in the following directory:

$INSTALLDIR\nodes\<hostname>\<clustername>\TOMCAT\webapps\wijsp\querywizard\config

To customize the default font for the HTML Report Panel:1. Make a backup of the config.js file.2. Open the config.js file.3. Find the function that corresponds to the element you want to modify.

For example, here is the function for the titles in a cell:

Figure 12-9 A function in the config.js file

4. Modify the attributes you want to change.For example, in Figure 12-9, to change Arial font to Courier, you would enter:cell.font =findFontByName(‘courier’,‘helvetica’,‘default’);

5. Save and close the config.js file.



Problems with third-party applets after installing the Java Report PanelIf third-party Java applets are installed on your machine, you may have trouble launching these applications in an Internet Explorer browser once you’ve installed the WebIntelligence Java Report Panel. Here are solutions for each of two problem situations:• If the application is running using Basic authentication, you are prompted to

login again.Solution: Click Tools > Internet Options > Advanced. Uncheck Use Java 2 v1.4.2 for <applet> (requires restart).

• Your previous application may crash or not work properlySolution: In the Internet Explorer browser, click Tools > Internet Options. Click the Advanced tab, then uncheck Use Java 2 v1.4.2 for <applet> (requires restart). Close then restart the browser.


Deploying BusinessObjects


BusinessObjects is the same application, whether it is deployed in a 2-tier or 3-tier environment.

Unlike Desktop deployments of BusinessObjects, however, 3-tier deployments of BusinessObjects can access universes in the repository’s universe domain only; they cannot access universes saved on users’ machines.

This section contains:• BusinessObjects and fonts• Deploying BusinessObjects in 2-tier mode• Deploying BusinessObjects in 3-tier mode

BusinessObjects and fontsFor reports in anything but PDF format, BusinessObjects uses the Windows fonts installed on the client machine. For reports in PDF format, it uses the Adobe AFM fonts on the client machine.

Both 2- and 3-tier deployments of the application manage fonts in the same way.

BusinessObjects and Unicode supportBusinessObjects does not support Unicode query databases.

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

Deploying BusinessObjects in 3-tier modeTo deploy BusinessObjects in 3-tier mode, you must respect a set of conditions both on the server and on the client side. Before installing the application, Business Objects recommends that you read this entire section for complete information.



��Installation

BusinessObjects in 3-tier mode can be installed on a client machine either through the standard Business Objects installation CD, or by downloading it from InfoView.• To install it from the CD, select Custom Installation > Desktop Products >

BusinessObjects > 3-tier BusinessObjects, then click Next and follow instructions until the installation is complete.

• For a description of how to download it from InfoView, see the InfoView User’s Guide.

If the Business Objects server is upgraded, users are automatically prompted to upgrade their version of BusinessObjects on their desktop.

NOTE

If a previous version of BusinessObjects in 3-tier mode was already installed on the machine before you installed BusinessObjects, 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.

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 client’s 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 3-tier deployments of BusinessObjects from the Windows Start menu only.Using deployment tools such as IntelliMirror or SMS, you can deploy ActiveX to the users’ desktops so that they do not have to download them.

• 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 user’s InfoView Options pages, the BusinessObjects option is selected either as the default document editor, or the default application for viewing BusinessObjects documents.

��Server configuration requirements

BusinessObjects in 3-tier mode uses WIQT and Connection Server 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.

The Connection Server module must be activated in the Administration Console on at least one node in the cluster.



��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 user’s 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 user’s 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 Guide.

• the right to download BusinessObjects in 3-tier mode (in the WebIntelligence Administration security command family: Download 3-Tier BusinessObjects)

• 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 BusinessObjects 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, in order 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.

��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

documentThis triggers the generation of the .rkey file on the client.



��Using BusinessObjects in 3-tier mode with SSL

If your deployment uses SSL (see SSL on page 467), you must configure BusinessObjects in 3-tier to work correctly with it. If you don’t, when you log into InfoView for the first time, you will see a Security Alert message indicating that there is a problem with the site's security certificate. If you click Yes, InfoView opens and you can use it, but you cannot download BusinessObjects.

In order to use BusinessObjects in 3-tier mode using SSL, you must have the correct SSL certificate installed on the client machine.

To install the correct SSL:1. Download the root certificate used by your company onto your computer. Ask

you systems administrator for help if you need it.2. Click Install Certificate. The Certificate Import Wizard opens.3. Click Next. The Certificate Store dialog box opens.4. Select Place all certificates in the following store.5. Click Browse.6. In the Select Certificate Store browser, check Show physical stores, expand

the Trusted Root Certification Authorities level, select Local Computer, then click OK.Another symptom of the same problem arises when you already have BusinessObjects Reporter installed on your machine, then try to launch BusinessObjects in 3-tier mode. BusinessObjects does not open, and you get an Unexpected response message from the server. The problem is that you are trying to log into a server using SSL (the root URL in your .rkey begins with https://, and not http://), without having the correct security certificate installed on your machine.To solve this problem, log into InfoView, then follow the instructions above.

��Using BusinessObjects in 3-tier mode with Windows-NTLM authentication and Basic authentication under IIS

If you are using Windows-NTLM or Basic authentication under IIS, you may be unable to download 3-tier BusinessObjects from InfoView, getting instead a Windows Installer error message stating that the installation package could not be opened.



To resolve the problem, you must configure IIS in the following way:1. Click Start > Administration Tools > Internet Services Manager. The

Internet Services Manager opens.2. In the Tree tab to the left, expand the Default Web Site list.3. Right-click the wiasp directory, then choose Properties. 4. Click the Directory Security tab, then click the Edit button under Anonymous

access and authentication control.5. Under Authentication Methods, check your authentication mode—Windows

or Basic (password sent in clear text)—then click OK. The Inheritance Overrides dialog box opens.

6. Select scripts, viewers, bin and classes, then click OK.

You can now restart the IIS server.

��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 Broadcast Agent


This section covers:• Installation• Sizing guidelines

The factors that impact the size and number of machines you need for Broadcast Agent

• How many Broadcast Agents and Schedulers?How many Schedulers should you create for each installation of Broadcast Agent?

• Matching components with machinesWhich Broadcast Agent component should you run on which machine?

• UNIX, Windows or heterogeneous?• Server optimization using caches• Server filenames, pathnames, and permissions

What pathnames must you use when scheduling documents?• Configuring database connections

For more detailed information, see the Broadcast Agent Administrator’s Guide.

NOTE

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.

InstallationTo 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.



Sizing guidelinesThe 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 users—all 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 Administrator’s Guide) with options set to refresh each user’s copy of a report according to that user’s profile, a separate refresh is carried out for each recipient. In other words, if you burst a document according to the profile of 100 recipients, it carries the same load as refreshing the document 100 times.

The amount of RAM required for each document to be processed depends on its length and complexity. Business Objects recommends that you create a set of typical documents upon which your users are apt to rely. The document size is the same whether the server is UNIX- or Windows-based.

The best way to ensure the memory requirements for your deployment is to build the reports on a test system and find out how large they actually are. You can then size your servers accordingly.

How many Broadcast Agents and Schedulers?You can configure multiple Broadcast Agents in your configuration, and multiple Schedulers for each Broadcast Agent. The advantage of having several Broadcast Agents is that you can have one for each user group (Sales, Finance, and so on).



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 on every secondary node.

Matching components with machinesYou do not have to set up your Broadcast Agent cluster over multiple servers. If you decide to install all components on one machine, you must declare the machine as the primary node when you install Broadcast Agent.

The machine running the Scheduler does not need exceptional processing power or disk space. However, machines running BOManager and WIQT require much more processing power.

NOTE

You can limit the number of processes which are run concurrently on each machine by using the parameter settings in the BOManager, WIQT, and Scheduler modules.

It is good to configure sufficient swapping space to allow for peak conditions. Keep in mind that:• If a job cannot be handled with the available RAM, swapping occurs and

processing slows down.• If swapping occurs and the swapping space is exceeded, performance will be

greatly affected, and eventually the system may become unstable.

Installing multiple BOManager and WIQT modules, one on each machine in a cluster, provides load balancing and failover.

A Scheduler on a machine can process documents (using WIQT or BOManager) on any machine in the same cluster, if the Session Stack is enabled and its Enable batch processing parameter is set to On.

The Broadcast Agent Console is a relatively lightweight user interface, and does not consume significant resources. It 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 reports, 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 reports 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, Windows or heterogeneous?You can deploy Broadcast Agent on a UNIX, Windows or heterogeneous cluster.

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.

Server optimization using cachesBusinessObjects 6.5 includes several cache mechanisms to improve server performance, especially in large deployments.

��Login cache

After users execute a task via Broadcast Agent, they do not have to log in again when submitting subsequent tasks. BOManager caches their login information for each Broadcast Agent task. If users have the appropriate access rights, the session context for the task is restored directly from the cache.

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 document’s 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 HTMLGenerates 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. 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 document’s presentation doesn’t have to be generated. The document is

displayed faster and more efficiently• response time remains constant and doesn’t depend on the document’s 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.

��Caching tips

Encourage users to preprocess all corporate documents that they expect will be viewed by multiple users—particularly 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 won’t need to refresh them.



Server filenames, pathnames, and permissionsInfoView or BusinessObjects (2-tier) users who schedule Broadcast Agent tasks specify a pathname and filename when using:• the File Watcher option to schedule tasks to run only when a specific file is

present• the Distribute via File System option to copy a scheduled document to a

specific location• Save as RTF• Save as TXT• Save as PDF• Save as XLS• Save as XML

The pathname relates to the server on which the process (BOManager) is running, not to the user’s machine.

For example, if the user selects Save as RTF with the filename C:\MyFile, Broadcast Agent attempts to save the file to that location on the server, not on the client.

NOTE

To specify a pathname or filename on a machine other than the server on which the Broadcast Agent is running, you must specify a full UNC (Universal Naming Convention) name; for example: \\MyMachine\SharedFolder\MyFile.txt

The BOManager executing the scheduled task must have the required permissions:• to write to the file itself and its parent folder• to access every folder in the path

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 theMyWebiEnv.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.

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.

��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>

Windows path UNIX path on server

MyFile /opt/webidoc/myfile

\\Server\MyFile /opt/webidoc/server/myfile

D:\MyFolder\MyFile /opt/webidoc/d/myfolder/myfile



The table below summarizes the various formats.

You can shield users from these issues by mapping and mounting structures appropriately, and informing users what the best practice is.

EXAMPLE

Pathnames

A user wants to use File Watcher to schedule a document 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 either of the following:• \etc\datawarehouse\Update_Completed• /datawarehouse/Update_Completed

To be safe, wherever the Scheduler is running (Windows or UNIX), the user would specify:

\\orion\etc\datawarehouse\Update_Completed

Path format UNIX Windows

UNC Finds locally or remotely

Finds locally or remotely

Mapped network drive Fails Finds if mapped drive is set up on server

Local relative Windows filename Finds locally Finds locally

Local absolute Windows filename Fails Finds locally

Local UNIX filename Finds locally Fails



��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.

Configuring database connectionsBroadcast Agent may establish hundreds of database connections per day. The configuration of these connections is therefore critical to the efficiency of your deployment.

��Configuration guidelines

When configuring your connections, you can choose from the following options in the Advanced tab of the Connections dialog box:• Keep the connection active during the whole session• Keep the connection active for X minutes• Disconnect after each transaction

Business Objects recommends using either Keep the connection active for X minutes or Disconnect after each transaction.

The reason is that the Connection Server module handles a pool of connections to the different domains involved. The connection can be physically closed (Disconnect after each transaction) or only logically closed (Keep the connection active during the whole session).

��Using shared and personal connections

Most BusinessObjects documents access data through a secured connection stored in the repository. However, BusinessObjects users can also create documents that access data through personal connections or shared connections, which are not defined in the repository. These types of connections are defined in two locations: • in the document itself• in .lsi (Local Security Information) files stored in the LocData folder on the

user’s machine



When users send documents based on shared connections to Broadcast Agent, the connection information is obtained from within the document itself. However, if the document contains a VBA macro which directly accesses the shared connection, the sdac.lsi file on the server must contain the shared connection data.

��The LocData directory

All Broadcast Agent servers and BusinessObjects client machines use a LocData directory, whose location is determined during the installation process.

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• 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.

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.


Deploying Auditor

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 BusinessObjects, 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 AuditorTo 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 Guide.

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 Administrator’s Guide.

3. Use Designer to export the universes you will be using with Auditor to the repository.

4. Create the database views.5. Export the predefined indicators to the corporate repository.

NOTE

Although Business Objects recommends performing these steps in this order, you can carry them out in a different order, at different times, and from different machines.

For more detailed information, see Part I in the BusinessObjects Auditor Guide.

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



Monitoring multiple clustersBusiness Objects supports multi-cluster auditing. Each cluster, however, must have a different name in order for this type of auditing to work (you name clusters using the Configuration Tool).

In addition, to ensure that Auditor can retrieve coherent information, all the clusters must point to the same repository.

Deployment scenariosYou 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 repositoryOnly the main Auditor repository of the monitored Business Objects system.

These scenarios are described below.


Deploying Auditor

��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.

Figure 12-10 Dedicated server/double repository for Auditor

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.

Clients


IntranetExtranet

Production database

Business Objects repository

Audit database

Write

Read

Auditor-dedicated

Auditor-dedicated repository

IntranetExtranet

Auditor client

server



NOTE

In this scenario, we recommend turning off the User Activity Log in the Administration Console for the cluster dedicated to Auditor.


Deploying Auditor

��Scenario 2 – Dedicated cluster / single repository

The following diagram shows how Auditor can be deployed with an Auditor-dedicated server/cluster, but without an Auditor-dedicated repository.

Figure 12-11 Dedicated server/single repository for Auditor

This deployment, with its shared repository, is ideal if you want to make Auditor indicators available to other users of the repository.

Clients


IntranetExtranet

Production database

Business Objects repository

Audit database

Write

Read

Auditor-dedicated

IntranetExtranet

Auditor client

server

ch

ap

ter

Deploying WebIntelligence for OLAP Data Sources



OverviewOLAP (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 WebIntelligence cache service• The Universal Drill Through Service (UDS)• Installing the OLAP services on cluster nodes• Configuring the OLAP services on cluster nodes• Defining the OLAP connection in WebIntelligence

NOTE

To find out how to create WebIntelligence reports using OLAP data sources, see the WebIntelligence for OLAP User’s Guide.


WebIntelligence OLAP server as part of the cluster

WebIntelligence OLAP server as part of the cluster

The WebIntelligence OLAP server is fully integrated into the Business Objects cluster.

WebIntelligence OLAP transactions are handled by a single CORBA service called WIOLAPGenerator. This service behaves in the same manner as the other Business Objects processes in the cluster, with one exception: it does not use the CORBA logging service to trace execution. WIOLAPGenerator works with either ASP or JSP deployments of InfoView.

Although you can enable WIOLAPGenerator on as many nodes as you want, for performance reasons Business Objects recommends dedicating a single server in the cluster to WebIntelligence OLAP processing. Through CORBA, this server is available (using the same OLAP database) to all the nodes in the cluster, which can therefore use it to handle transactions for any OLAP connection defined in WebIntelligence.

Figure 13-1 Recommended cluster deployment for OLAP processing

Install Java, JavaScript, and image files

Enable all other OLAP components

Client machines of 3-tier system Web server

Applicationserver

Primary node

Cluster

DedicatedWebIntelligence

OLAP secondary noderunning WIOLAPGenerator



As complements to your WebIntelligence OLAP deployment, you can also install and configure:• The WebIntelligence OLAP Cache Service (see page 423)• The WebIntelligence Universal Drill Through Service, or UDS (see page 424)

Web server requirementsWebIntelligence OLAP can use either an IIS or an Apache web server.

The web server can be located on either a UNIX or Windows platform.

WebIntelligence OLAP Java, JavaScript, and image files must be installed on the machine on which the web server is hosted.

Dedicated WebIntelligence OLAP nodeIn this release, the dedicated WebIntelligence OLAP server must be running on Windows.• A web server on this machine is not recommended.• WIOLAPGenerator is the only module enabled on the WebIntelligence OLAP

server. All other modules must be disabled (they run on other nodes).

SecurityWith 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 deployment’s wiasp directory, the WebIntelligence OLAP folder automatically inherits those changes.

ConstraintsYou 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.


Setting up the dedicated OLAP node

Setting up the dedicated OLAP node

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

Installing the dedicated WebIntelligence OLAP nodeInstall the middleware for the OLAP server you will be accessing before you begin the Business Objects installation.

The date format for the OLAP connection is defined by regional setting of the computer. So before you install WebIntelligence OLAP on a cluster node, make sure that the regional settings are identical on all the nodes in the cluster, and that they remain synchronized.

To install WebIntelligence OLAP and the additional components it requires on the machine that will become the dedicated OLAP node:1. Run the Business Objects setup on the server machine.2. Under Access Packs > OLAP Access Packs, check at least one option.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 WebIntelligence OLAP cache and UDS services.

4. Run the install process.

Configuring the dedicated WebIntelligence OLAP nodeYou configure the server on which you have just installed the required OLAP and Business Objects server components as a WebIntelligence OLAP node using the Configuration Tool:1. Define the node as a secondary node.

Make sure that IIS is disabled on the node and that no other web server is installed on it.Go to the Configuration Tool’s Cluster management screen.

2. Click the Service Parameters option beneath ORB, select Update service parameters from the list at the bottom of the screen, then click Next.The Service screen appears.



3. 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 WebIntelligence OLAP Cache and/or WebIntelligence 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.

4. If you want the node to be started automatically whenever the server is booted or re-booted, check the Start automatically option.

5. If you are planning to use the WebIntelligence 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 services on cluster nodes on page 427.

6. In the screen’s 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

7. Restart the server when prompted.8. Make sure that both the cluster’s primary node and the dedicated secondary

node are started and functioning normally.

��If you do not define the node as a service

If you choose not to define the WebIntelligence OLAP node as a Windows service, and you are using MSOLAP (SSAS), the user that starts the Business Objects server must have permission to “Act as part of the operating system”.

Disabling/enabling the modules for OLAP useAfter installing WebIntelligence OLAP, run the Administration Console for the cluster:• Disable WIOLAPGenerator on all nodes but the dedicated WebIntelligence

OLAP node.• On the WebIntelligence OLAP node, disable all modules except

WIOLAPGenerator.


The WebIntelligence cache service

The WebIntelligence cache service

As some levels in OLAP databases may have large numbers of members, retrieving the members for every OLAP transaction can be time-consuming.

This optional service speeds up OLAP metadata retrieval from OLAP databases by retrieving the metadata the first time it is accessed, then storing it. For subsequent transactions, the metadata will be retrieved directly from the cache instead of having to return to the OLAP database.

The cache service can also automatically organize the members of a level into groups and subgroups to minimize the number of items through which users have to navigate, and to provide a familiar hierarchical tree navigation metaphor for finding and selecting members.



The Universal Drill Through Service (UDS)

The UDS service is used to perform the drill-through from an OLAP report (source report) to another OLAP report or to a WebIntelligence 6.x report (target reports). This service ensures the translation of the selected context in the source report into the context of the target report.

UDS is an optional, independent service with which WebIntelligence OLAP is compatible, and which is automatically installed along with WebIntelligence OLAP. For detailed information about this service, see the Universal Drill Through Service Guide.

A translation map is an XML file (with the extension UDM) that tells the Drill Through Service how to translate the context from the source cube to the target WebIntelligence report when the user drills on a cell. It describes how the values in the cube relate to the values in the report.

Administrators build translation maps using UDS Designer. Once maps are created, they are loaded by the UDS.

Multiple or single instances?Although you can configure single or multiple instances of the UDS service in a cluster, Business Objects recommends the single-instance configuration. In this case, all the nodes in the cluster reference this instance.

See Configuring the OLAP services on cluster nodes on page 427 for configuring the nodes to do this.

��Multiple instances

With multiple instances, an instance of UDS is installed and runs on each Windows node; all of them reference the same shared network location to access the map (UDM) files.

The UDS service must use an account that has access to the network, so that it can access the shared location of the map files.

If the drill-through maps are updated, you must first either update all running instances using UDS Designer, or manually restart in order to incorporate the modified maps.


Installing the OLAP services on cluster nodes

Installing the OLAP services on cluster nodes

Both of these services and any necessary administration tools are automatically installed on any machines on which you have installed WebIntelligence OLAP.

You can run these optional OLAP services on the dedicated WebIntelligence OLAP node if you want:

Figure 13-2 OLAP services running on the WebIntelligence OLAP node

You can also, however, run these services on other cluster nodes, then configuring the services on their host nodes and the dedicated OLAP processing node to work together.

Therefore, although you do not need to run these services on dedicated WebIntelligence OLAP processing nodes, you must follow the same installation procedures for any node on which you plan to run them (see Installing the dedicated WebIntelligence OLAP node on page 421).

Web

server

Applicationserver

Dedicated WebIntelligence OLAP node

Cluster

Primary nodeWIOLAPGeneratoris disactivated

Secondary nodeWIOLAPGeneratoris disactivated

WIOLAPGenerator is activated.The Webintelligence OLAP cache and UDS services also run on this node;



When these services are run on non-dedicated OLAP nodes, they act as servers for WebIntelligence OLAP clients on the dedicated nodes:

Figure 13-3 OLAP services on a different node from WebIntelligence OLAP

Application

server

Web

server

Cluster

Dedicated WebIntelligence OLAP node

Primary nodeWIOLAPGeneratoris disactivated

WIOLAPGenerator is activated and is a client of the cache and UDS services on Node2.

WIOLAPGenerator is disactivated.These services act as servers for the dedicated WebIntelligence OLAP processing node.

Node2 hosting the OLAP cache and UDS services


Configuring the OLAP services on cluster nodes


All the configuration information for both optional OLAP services is contained in a file on each cluster node called olapreg.ini, located in the $INSTALLDIR\bin directory. The values you set using the Configuration Tool, for example, are written to this file. You can also modify this file manually using a standard text editor.

You need to configure these services both on any nodes hosting these services, and on any dedicated WebIntelligence OLAP node (although the services may also run on the dedicated OLAP node). This involves specifying the port number used for each service, and if the services are running on another node, specifying the name or IP address of the remote node.

Business Objects recommends that you configure each service first on the node hosting it, then on any other node using it.

For complete instructions on configuring the services, see the following section.

For information on configuring, building, enabling and managing the cache, see the System Administrator’s Guide for Windows.



EXAMPLE

Configuring nodes to locate the WebIntelligence OLAP cache/UDS services

In the diagram below, WebIntelligence OLAP is running on a dedicated node called OLAPNode; the WebIntelligence OLAP cache and UDS services are running on a different cluster node called OLAPServiceNode.

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:

Cluster

Application

server

Web

server

Node called OLAPServiceNode

Primary node

Dedicated WebIntelligence OLAP node called OLAPNode



• For the WebIntelligence OLAP Cache service:

- 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.

For the WebIntelligence OLAP Cache service

olapreg.ini file:Cache_Port_ID=1202Cache_HostName=OLAPServiceNode

Cluster

Primary node

Application

server

Web

server


Node called OLAPServiceNodeolapreg.ini file:Cache_Port_ID=1202



• For the WebIntelligence UDS service:

- 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 cache service.

Cluster

For the WebIntelligence UDS service

Application

server

Web

server

Primary node


Node called OLAPServiceNodeolapreg.ini file:DTS_PORT_ID=25347

olapreg.ini file:DTS_HOSTNAME=OLAPServiceNodeDTS_PORT_ID=25347



Configuring an OLAP service on the node hosting itWhenever you change any type of setting for the WebIntelligence OLAP cache or UDS service, you must manually stop then restart the service in order for the changes to be applied. You do this in the Windows Services dialog box (Start > Settings > Control Panel > Administrative Tools > Services).

To set the port used by the cache/UDS service:1. Go to the Service screen in the Configuration Tool (by clicking Service

Parameters in the Cluster management screen):

2. To define WebIntelligence OLAP cache and/or UDS service as a Windows service, check the box next to the name of the service(s).Optionally, select Start automatically for the service(s) to start automatically when the server is started.



3. Set the port number(s) to be used for the service(s).4. Click the Test port button. If the port is free, a message appears telling you

so.5. Close the message by clicking OK.6. Click Next. After a brief delay, you return to the Cluster management screen.

��Modifying the folders used by the WebIntelligence OLAP cache and UDS services

When WebIntelligence OLAP is installed on a machine, Business Objects creates default folders for the WebIntelligence 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 Tool’s Cluster management screen, click the Cluster

Preferences option under ORB.2. Select Update cluster preferences from the drop-down list, then click Next.



The Cluster Preferences screen opens:

3. Do one or both of the following:- To modify the cluster’s WebIntelligence OLAP cache directory, enter the new directory path in the OLAP cache directory field.- To modify the cluster’s UDS directory, enter the new directory path in the UDS map directory field.

4. Click Next.



Configuring an OLAP service on external nodesIf you have installed the optional OLAP services on nodes which do not host WebIntelligence OLAP, you must configure the dedicated WebIntelligence OLAP node with:• the name or IP address of the server hosting the service• the service’s port number on that machine• the path to the folders used for each service on the remote server

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, you can also enter these settings manually in the node’s olapreg.ini file.

Whenever you change any type of setting for the WebIntelligence OLAP cache 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 node’s $INSTALLDIR\bin\olapreg.ini file in a standard text editor.2. For the cache service:

- Scroll to the [CACHE] section.- For Cache_HostName, enter the name or IP address of the node hosting the cache service.- For Cache_Path, enter the path to the folder to be used for the WebIntelligence 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 cache 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=\\OLAPServiceNodeFor 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\UDSMapsFor 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.

��Making sure the node can access the remote cache and UDS services

When you enter an external host for the WebIntelligence OLAP cache 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, click Start > Settings > Control Panel > Administrative Tools > Services. In the Services window:• the cache service is displayed as WebIntelligence OLAP Cache Service.• the UDS service is displayed as WebIntelligence Universal Drill Through

Service (UDS).



5. 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 don’t have access rights; when the query is run, however, WebIntelligence will take the restrictions into account and will not display unauthorized data in the generated report.

6. Click OK.


Defining the OLAP connection in WebIntelligence

Defining the OLAP connection in WebIntelligence

Once the server side of WebIntelligence for OLAP data sources and the OLAP middleware are installed and configured, you must create a connection to each OLAP data source within WebIntelligence.

To do this:1. Click the OLAP link under New document on the InfoView home page.

The WebIntelligence OLAP Report Panel page opens (displayed below with four existing OLAP connections).

2. Click the New button.3. Enter the name of the OLAP data source as you will want it displayed in the

WebIntelligence data source list.The WebIntelligence OLAP Report Panel dialog opens.

4. Select the name of the data provider in the OLAP Server list.5. Enter the name of the server, then in the description field below it, enter a

description if you want.6. When you’re done, click Save.

part

Securing the Solution

ch

ap

ter

Data Security


Data Security

OverviewSecurity is an increasingly important issue in today’s organizations. Implementing and maintaining security for a large number of users can be a costly operation, and has implications for long-term deployment requirements and user functionality.

Business Objects has placed equal importance on the ability to protect the security of data and on the empowerment of users to access, analyze and share it. One of the main strengths of the Business Objects product suite is the range of security options and capabilities provided by the centralized repository. Because security can be applied within universes at the user and group levels, Business Objects can meet the security needs of most types of organizations.

The Supervisor product manages the major part of Business Objects security, allowing you to set up and maintain a secure environment for users by creating the repository and control user access to the universes and documents it contains, as well as to the Business Objects products themselves.

The supporting role in Business Objects security is played by Designer. It allows you to:• restrict a universe object so that only end users with the appropriate security

access level can use it — and thereby prohibit specific users from viewing sensitive or critical information

• impose joins on tables for security reasons


RDBMS securityBusiness Objects allows users to connect to their database using their own data account for queries and refreshes. Supervisors can choose whether users of a given universe access the database through the universe’s data account, or through their own individual accounts.

When using their own data account to access a universe’s data, users log into Business Objects products with their database user name and password. In this way, they benefit from the database security mechanisms, and have only one password to remember.

You can enable this type of security by checking the Use BusinessObjects username and password option on the Login tab of the connectivity dialog box. When this option is selected, the User name and Password fields are disabled, and the name and password of the currently-connected user are used instead.

TIP

If you select the Use BusinessObjects user name and password option, make sure you also select the Disconnect after each transaction option on the Advanced tab.

For more information, see the Supervisor’s Guide or the Data Access Guide.


Data Security

Security at the product feature level

You can restrict the use of any product by disabling user or group access to certain menu commands or interface elements such as toolbar buttons. Because some users in your organization may still be using the previous release while migrating to the current release, the current release lets you manage command restrictions for both releases.

You can restrict access to areas of functionality by using security commands, grouped thematically into families. A security command corresponds to a set of one or more menu items and other interface elements such as toolbar buttons or shortcut menu commands.

For example you could revoke the Finance Class’s rights to create new documents or you could disable the HR Group’s ability to work in drill mode. Additionally you can fully restrict access to the different products. For example you can restrict the HR group from using WebIntelligence and Supervisor.

For convenience you can also add to the pre-defined settings provided by Supervisor. You can, for example, create a setting giving users access to a specific set of InfoView privileges.

Figure 14-1 Command Restriction dialog box in Supervisor


Security at the product feature level

Extended security commandsSupervisor version 6.x features a remodeled and enhanced way of working with security commands, allowing a finer degree of control than earlier versions. Compatibility between version 5.x and version 6.x security commands is provided.

Time restrictionsYou can use Supervisor to place time restrictions on individual users or whole user groups. This allows you to control the specific times and dates at which users can access Business Objects products.


Data Security

Data security at the universe level

Most applications deployed for accessing or transmitting information over the web are compliant with the network and application communication layer security mentioned in this guide. For a product to be successfully deployed for an extranet, however, database security is also required. The ability to restrict the viewing of rows based on a user profile, or limit access to database columns are some of the very important security requirements for companies deploying an extranet.

Data security mechanisms you can employ include:• Connection strings• Object-level security• Row-level security• Table mapping

Connection stringsYou can use connection strings to protect the data in specific databases from specific users.

Connection strings specify the database to which a user can connect. They are independent of the universe and are stored within the repository (in secured mode).

Figure 14-2 Assigning a universe and connection string to a user



You can attach a connection string to a universe by user or group of users. For example:• You can have a single universe with development, test and production

connections. • If you implement a single data-mart that is physically duplicated in each

region, you will only have to create one universe with multiple connections (by region).

Object-level securityYou can choose to hide or restrict certain objects that only a few users can view (information like "SALARY" or "Date of Birth").

Figure 14-3 Restricting access to universe objects in Supervisor

Object-level security is based on restricting a user from viewing and selecting a specific object in the query panel. In Supervisor, the object is restricted for the user or group. Hence, when this user selects the universe with the object restriction and proceeds to the Query Panel, the restricted object will not show up.


Data Security

You can restrict objects in a universe in two ways:• in a more global fashion, by restricting objects at the user or group level. This

is best when you want to hide a group of objects from a good-sized group of users, and involves using Supervisor alone.

• at a much more reduced level, such as when you want to hide just a couple of objects from a few users. This involves using both Supervisor and Designer.

��From Supervisor alone1. Click on the group/user to which you want to apply the restrictions.2. Open the properties for the universe to which you want to apply restrictions.3. Click the Objects tab and add "Object Restriction" for any of the objects in

any of the classes.



��From Supervisor and Designer

First, in Supervisor:1. Open the properties for the user to whom you want to apply the object

restriction.2. Select any of the options other than Public under Objects Security Level.

3. Click OK.


Data Security

Then in Designer:1. Open the Properties for the object you want to restrict.2. In the Advanced tab, select the same choice you chose for the user.

Figure 14-4 Applying Object Security Access Level in Designer

3. Click Apply then OK.

All users with the Controlled level will see all objects whose access level is equal to or less than Controlled.

NOTE

In this release, object-level restrictions are not taken into account in WebIntelligence.




Row-level securityTo make sure users or groups of users see only particular data while creating a report or refreshing existing reports, create a restriction on a particular universe and user group using Supervisor.

This is done by means of an SQL statement in Supervisor. For more complex scenarios, you can write an SQL script that will automatically insert or update the WHERE clause to the relevant table in the repository, as follows:1. Click on the group/user to which you want to apply security.2. Open the properties for the universe to which you want to apply restrictions.3. In the Rows tab, add New Row Restriction for a column in the desired table.

Advantage Disadvantage

Restricted objects allow the same universe to be shared among various types of users.

This is very helpful in database models which contain different groups with different database connections on the same universe. Some objects can be hidden for some groups and remain available for others.

Documents built with these universes must be distributed with either the Refreshed When Opened or report bursting option, otherwise the object restriction will not apply.


Data Security

EXAMPLE

Hard coded condition

For a given user, you create a restriction such as “Where Manager = ‘John Smith’.” This particular user can only see information related to his group. The restriction applies even if the user tries to include other groups in a query.


Every user that accesses a report from a restricted group sees only the rows that they are allowed to see

This type of setup has to be implemented for all groups and users on which you want to apply the restriction. It has to be done individually for each universe.

A report can be created once, and published as “refresh on open.”

The restrictions only apply when the table referenced in the Where clause is used.

When users retrieve this type of report, they see only the rows to which they have access.

Every canned report has to be refreshed for the row level security to take effect, unless it is pre-run (run under the profile of each user) and published to the user’s inbox.



Data-based security using the BOUSER variable in a universeYou can use Designer to restrict data access for a specific user. To do so, create backend tables, then use the @Variable function with the BOUSER system variable to restrict data according to the identity of the currently logged in Business Objects user. BOUSER corresponds to the user name with which the user logged into the Business Objects system.

Use the @Variable function in the Where clause for an object in order to restrict data access to a user’s database profile when that object is used in a query.

For example, if you want each user to have access to information concerning his/her customers only:1. Create a table in the universe’s database to store user names and customer

IDs2. Use Designer to incorporate that table in the universe, then join it to specific

universe tables3. Create or import users in the repository


Data Security

��Creating a table for user information in the universe database

Create a security table (called Security_Header) in the universe database. In this example, the table has 2 columns, each of which corresponds to an object (BOUSER_Name and Customer_Id):

It is the first step in defining the specific customers for which individual users can access information.

BOUSER_Name Customer_Id

gap1 9015

gap1 9016

gap2 9017

k1 1497

k1 1498

K2 1499

K2 1490

K2 1493

K3 1496

Wal1 2010

Wal1 2020

Wal1 2030

Wal2 2040

Wal2 2050



��Inserting the table in the universe and inserting a join

Using Designer:1. Include the Security_Header table in your universe (Insert > Tables > Insert

button).This creates BOUSER_Name and Customer_ID objects in the universe.

2. Create the following self restricting join on the Security_Header table (Insert > Join), making sure you select Security_Header for both Table1 and Table2 in the Edit Join dialog box:Security_Header.BOUSER_Name=@Variable(’BOUSER’)

A self restricting join is used to set a restriction on a particular table only. In this example, the join is placed on the BOUSER_Name column in the Security_Header table This allows you to control what customer information each user is allowed to see. This information is defined by their database profile.

3. Join the Security_Header.Customer_Id column to the Customer_Details table or any other tables that require security restrictions in the universe.

As is, this will work only if the query includes the Security_Header table in it. For example, if you use the Orders table, you are not restricted.

To avoid this situation, each of the objects that you want to restrict must use the security table.


Data Security

In this example, the Total Payment Due and Customer_Name objects are restricted in this way, so that the query is forced to use the Security_Header table every time the user selects these two objects.

To do this:1. Open the properties of the object you want to restrict [Total Payment Due].2. Click Tables.

A list of tables used in the schema appears. From this list you can select other columns in other tables to be included in the object definition. This allows an object to infer columns from other tables in the Select statement.

3. Select the Security_Header table (in addition to any previously selected tables) of the object.

4. Apply the change, then click OK.



You don’t have to maintain row level security on each group/ user per universe.

You have to create the security table in every schema in which you want to maintain this type of security.

Automated procedures help ease of deployment for large deployments.

You have to import the security table into every universe in which you want this restriction. You can use linked universes for this.

Everything is maintained within a database.

You have to maintain forced table joins to the security table in objects that you want to restrict.

All users that access the database will get their own view of the data.

You have to make the security table the driver table for the universe, since all the security is going to be derived from this table.



Table mappingTable mapping allows you to switch the tables that are referenced by a universe. You can use this feature for security purposes.

For example, you want to restrict a designer from working with tables with critical data. With table mapping, you can replace these tables with others. Alternatively, some users or groups may wish to re-use the same universe with a different set of tables, views, or synonyms.

EXAMPLE

Replacing the Region table with the RegionWest table using table mapping

You have a data warehouse roll out by region. You can duplicate the data warehouse in each region using ETL tools. In each region, you might have a regions table (RegionWest for the Western Region, RegionNorth for the Northern Region).

If you have defined users by region, you can replace the Region table with RegionWest for the Western Region using the table-mapping feature:

Figure 14-5 Table mapping in Supervisor


Data Security

��Using table mapping for row-based restrictions

When row-based restrictions are applied in Supervisor, Business Objects does not add new tables included in the row-based security definition to the current query. The tables mentioned in row-based security must already exist in the query’s FROM clause.

Workarounds to this include:1. Manually setting the objects’ TABLES list to include the security table2. Including the row restriction in the objects’ WHERE clauses

Unfortunately, these workarounds make security on objects mandatory — every time the object is used, the security table must be consulted.

To restrict a user or group with row restrictions, you would have to populate the security table with all possible rows for each unrestricted user. This is unfeasible if the transaction table and user population are large. In addition, the SQL for unsecured users becomes much more complex than necessary. The security table does not need to be consulted for these users, but each query is nonetheless forced to consult it.

Supervisor’s table mapping feature provides a solution to this problem. It maps any reference to the original transaction table to a view joining the transaction table to the security table. This reduces unnecessary SQL and gives the impression that the security table is joined to the transaction table only when Supervisor security requires it.

The database

The example database contains two tables and one view:• The transaction_table table contains two columns, one uniquely identifying

the transaction, and the other providing the dollar amount of the transaction.• The security_table table contains two columns, one listing the Business

Objects user names to which row restrictions will be applied, and the other listing the specific transaction_id in the transaction_table table that each user is allowed to see.



• The transaction_secured_view view exposes all non-duplicate columns from both of the above tables.The SQL required to generate this view is:

SELECT

transaction_table.transaction_id transaction_id,

transaction_table;transaction_amount,

security_table.bouser bouser

FROM

transaction_table,

security_table

WHERE

security_table.transaction_id =

transaction_table.transaction_id

note

Although the SQL of this view looks like it generates a many-to-many (N,N) cardinality, when the final BOUSER restriction is applied at runtime, this cardinality is reduced to a one-to-many (1,N).

The universe

The example universe is set up normally, with both the tables and the view inserted but with no joins. The transaction_table table can be joined to any other tables in the universe although none exist in this sample universe.

NOTE

There is no technical reason for security_table or transaction_secured_view to be inserted in the universe. This is however recommended to allow Business Objects to include them in its various integrity checks (Do the tables/views exist? Do the connection parameters have permission to see them?). In addition, since the table mapping feature maps table names but not column names, their presence permits a visual check of matching column names and types.


Data Security

In Supervisor

You use Supervisor in two stages:1. Apply row-based restrictions to the transaction_table table in the BOUSER

column. Although this column does not currently exist in that table, it will be created in the transaction_secured_view view when the row restriction SQL is mapped.



2. Map the transaction_table table to the transaction_secured_view view.

Security is only applied to the groups or users for whom you want to restrict access to rows in the transaction_table table.


Data Security

Section and block security at the report level

The following sections describe ways of restricting data access at the report level.

Block-level securityBlock-level security allows you to hide a block (a crosstab, table or a chart) within a report based on the conditions you impose. Conditions can be based on:• the data in the designated blocks (example: hide the block if the margin is

greater than $10,000)• the user accessing the report (example: hide the block if anybody in the

Finance group opens the report)

EXAMPLE

Hiding a block in a table according to set conditions

In the following example the block will be hidden if the current user’s login name is U2, Jack or Jill:

Figure 14-6 Hiding report blocks in BusinessObjects


Section and block security at the report level

Section-level securitySection-level security is similar to block level security except that you hide or show sections instead of blocks.

A major advantage of section-level security is in report bursting. Suppose you have a scenario in which a report contains thousands of customers. If you section this report by customer, you can impose a condition that will hide the section if the customer name is different from the current user. The end result is that even though this report could contain the information for thousands of customers, customers will only be able to access their own individual section.

The resulting response time in InfoView for each customer is fast, since the report is opened once and cached on the server for all users.

Maintaining security in a relational databaseYou use an in-house application to maintain security in a relational database. You use a form for inputting users and their restrictions into the database, and you would like to automate the process of creating the users in the Business Objects repository and updating the Security_Header table.

To automate this process:1. Create the file (ImportUsers.txt):

[Trigger (on Insert/Update) within a PL/SQL procedure on security database table to create the delimited file]

2. Run Supervisor in blind mode, and import this file to create the users in the repository:[PL/SQL procedure to call a runtime lib to run a command line]

3. Create a trigger that inserts/updates the Security_Header table:[Trigger (on Insert/Update) within a PL/SQL procedure on security database table to Insert/Update the Security_Header table]


Data Security

ch

ap

ter

Network Security


Network Security

OverviewThe rapid growth of networks and networking technology, both within and between organizations, has greatly increased users’ access to information. However, putting information within the reach of those who you want to have it also puts that information within the reach of those who you don’t want to have it. Open network communication is vulnerable to:• Electronic wiretapping, where anyone can monitor a data exchange and

decipher the conversation, including stealing financial and other data• Sabotage, which can be as simple as disrupting the data flow or as complex

as modifying purchase orders or database queries• False identification, where a site claims to be a company or entity that it’s not

or a client claims to be another person

The vulnerability of network data means you must make sure that information transactions between computers are secure. There are a number of ways to do this:• Isolate the Business Objects network from all means of access, such as

modem lines and outside network connections. This is the most secure way to protect a network, but also prevents the network’s users from easily contacting other networks and external resources.

• Secure transactions to and from the local network by encrypting or encoding the data between the sending and receiving computers. Other security measures are effective at keeping intruders out of a private network, but have the unfortunate side effect of also keeping out the people you want to have access.

• Place a firewall around the network. A firewall limits or prevents outside access to the network, while allowing internal users access to outside networks. Some firewalls prevent any access to the network from outside, others require user authentication before allowing access inside, and some even require authentication before allowing internal users to go outside the firewall.For detailed information about firewalls, see DMZ configurations on page 197.


Common protection techniques


Three common strategies for maintaining network security are:• Public Key Infrastructure

Public Key Infrastructure is a way to authenticate users securely over a network. Companies like Digital Signature, E-Lock, SHYM and Chrysalis are a few commonly known providers of PKI solutions. PKI uses public-key cryptography which generates key pairs -- one public, the other private (asymmetric). Owners of key pairs use private keys to encrypt/decrypt. Others use public keys to encrypt/decrypt.

• Digital certificatesAnother way to secure network protocols is to use digital certificates. Applications use client-/server- side certificates to deploy web applications, where only the client with the client certificate on its machine can successfully view and use information.

• SSLSSL’s allow the encryption of data between interacting entities by setting an encryption key for all the clients requiring HTTPS access. The only way to decrypt the data is to have a valid key that is issued by the server and has been accepted by the client. By contrast, HTTP does not encrypt data; it is a connectionless protocol, and is therefore easy to hack.SSL incorporates the use of both encryption keys and digital certificates, and is therefore highly recommended.

SSLSSL is a means of encrypting or encoding data as it passes between a web server and a browser. Most popular free and commercial web servers provide SSL encryption. SSL provides three major benefits over most other encryption or data protection schemes:• Public-key encryption provides a means of exchanging data without

transmitting unsecured data or data that would permit snoopers to decrypt the transmissions.

• Authentication certificates permit positive identification of the server and optionally of the client through the exchange of certificates that have been validated by a certificate authority.

• Transaction validation prevents data from being modified between the sender and the receiver. Changes in the data invalidate the authentication code, and the receiver is alerted to the fact that the data has been modified.


Network Security

There are two primary methods of encrypting data:• Symmetric-key cryptography• Public-key cryptography

��Symmetric-key cryptography

Symmetric-key cryptography is the simpler of the two methods. It uses the same key both to encrypt and decrypt the data. The sender gives the data and the key to the encryption engine, which encrypts the data and sends it to the receiver. The receiver passes the encrypted data and key to the decryption engine, which runs the process in reverse. The problem with doing this over the network is that, at some point, the key used to encrypt and decrypt the data has to be exchanged. Since the person receiving the key doesn’t already have the key, transmission of the key can’t be encrypted. A third party could theoretically intercept the unencrypted key and use it to decrypt (and listen in on or disrupt) any later communications that use that key.

��Public-key cryptography

Public-key cryptography solves this problem through the use of two keys, one public and one private:• The public key is available to anyone who wants to send encrypted messages

or data to you.• The private key stays private and is used to decrypt data encrypted with the

public key.

Data encrypted with the public key can not be decrypted with it and can only be decrypted through the use of your private key. The process of public-key encryption works like this:1. To begin a secure session with a server, a browser requests the server’s

public key.2. The server sends its public key to the browser.3. The browser receives the server’s public key, encrypts a message using the

key, and sends the message to the server.4. The server receives the encrypted message and decrypts it using its private

key.

Note that in Step 2, the communication is not yet secure, just like in symmetric-key cryptography. Someone could intercept B’s unencrypted public key as it makes its way to A. The difference is that the symmetric key can be used to decrypt the encoded data. But a public key can only be used to encrypt data. Someone who intercepted B’s public key would only be able to send secure messages to B, not decrypt A’s subsequent messages to B.



Most encryption schemes, including SSL, are actually a combination of symmetric-key and public-key encryption. While more secure, public-key encryption uses a complex encryption algorithm. Symmetric-key encryption is much faster and cheaper. Public-key encryption is used to establish the secure connection where a randomly generated symmetric key can be exchanged, and the rest of the transaction is encrypted by the quicker symmetric-key encryption.

��Client and server certification

Another benefit of SSL is positive identification of servers and clients using digital certificates. Digital certificates provide a means of positive identification over the Internet. The certificates used by SSL are defined in the X.509 standard issued by the International Telecommunications Union (ITU). Among the items contained in an X.509-compliant digital certificate are:• Certificate owner’s name• Certificate issuer’s name• Owner’s public key• Issuer’s signature• Valid dates

If your company has its own internal certificate authority (CA), you should request your certificate from them. To purchase a certificate from a commercial CA, you must submit a Certificate Signing Request (CSR) to one of the various CAs. With most servers, the SSL configuration tool asks you for the required information and automatically sends a CSR.

A CSR is an encrypted file containing information about your company. The CA will use the CSR to verify that your organization is legitimate and to issue you a certificate. You must then install the certificate on your web server.

VeriSign and Thawte are examples of CA’s. For more information, refer to:

http://www.verisign.com or http://www.thawte.com.

To access your web server, users must have a root certificate from the same authority. A VeriSign root certificate is installed with most browsers.

http://www.verisign.com

http://www.thawte.com


Network Security

��SSL security levels

SSL provides three different levels of security based on certificates.

Whenever a client or server certificate is used in a secured transaction, the certification chain is verified to make sure that no certificate in the chain has been compromised.

Level Requirements

No security No certificate is required and transactions are not encrypted.

Server certification The server passes a certificate to the client. The client checks that the certificate is still valid and that it was issued by a trusted certificate authority.

If the certificate is valid and from a trusted issuer, the client uses the public key contained in the server certificate to begin the encrypted session.

Client certification Both server and client exchange certificates. Both must check the validity of the issuing authority of the certificate they receive.

If both server and client accept each other’s certificates, the session begins just like with server certification.

You cannot use client certification to manage the users to whom you want to grant access to your site (you can do this, however, using a web server’s certificate mapping feature). Although client certificates do contain the user’s distinct name, this is verified but not used to decide whether the user is granted access to the site. Access is based solely on whether the certificate is valid and whether the issuer of the certificate is trusted by the server.



��Making a secure connection

Creating and using a secure SSL connection is a simple process, especially from the client standpoint. The process, similar to that of a public-key encrypted session, is as follows:1. The browser sends an HTTP request to the server. The difference between

this request and a standard non-secure request is that the request uses the secure HTTP protocol. A secure HTTP URL begins with https instead of the standard http.

2. The server passes its certificate to the browser.3. The browser checks the certificate for validity. If the certificate has expired or

its authority is not trusted, the browser prompts the user to decide whether or not to accept the certificate.

4. If the certificate is valid and from a trusted authority, the browser generates a set of random numbers, encrypts them using the server’s public key, and passes them to the server. These numbers are used to encrypt all further communications.

5. If the server requires browser certificates, it then requests one. If the browser cannot produce a trusted certificate, the connection is terminated. If it can, the transaction continues normally.

SSL is convenient and easy to use, since the entire transaction is handled by the software. Assuming that the client is attempting a valid transaction, with a valid certificate recognized by the server, the connection hardly appears different from an ordinary one.

There is generally an indication in the browser that a secure transaction is taking place. For example, in Netscape Navigator, the key in the lower-left-hand corner is whole, while for non-secure transactions, the key appears “broken.”

With https, applet communications are also secure since they use the same path as HTML pages.


Network Security

��Implementing SSL

To implement SSL, set up the web server to receive requests only on a https port. This can be done by enabling the secure website on your web server:1. Create a new key and a CSR (Certificate Signing Request) file.2. Request a certificate from your Certification Authority: the key you have

generated is not valid for use on the Internet until you obtain a valid certificate for it from a Certificate Authority, such as VeriSign. Send the certificate request file to the Certificate Authority to obtain a valid certificate. Until you do so, the key will exist on its host computer, but cannot be used.

3. Install the certificate on the server.4. Activate SSL security on the web server.5. Test the SSL security with Business Objects by trying to log into InfoView from

a client browser using https://<Business Objects Host Name>/wiasp (or wijsp). If you can log in correctly, the SSL security is working.

Once the web server is set up to work with SSL’s, Business Objects will use exclusively the same https for sending and receiving information to and from the client.

NOTE

You can also find online information about configuring your web server by searching for SSL or security at:• http://msdn.microsoft.com for Microsoft Internet Information Server• http://docs.iplanet.com for Netscape and iPlanet servers.

For Apache you must compile your web server with an SSL module. For more information, see the Installation and Configuration Guide for UNIX or to www.modssl.org.

http://msdn.microsoft.com

http://docs.iplanet.com

http://www.modssl.org



��Advantages and disadvantages of SSL

NOTE

If your deployment is international, know that some countries have rules regarding the use and export of encryption systems.


All communication between the client and the server is secure.

Network performance may decrease slightly.

Only a valid key on the client can decrypt the data.

SSL’s must be renewed and updated from public authorities.


Network Security

ap

pen

dix

How Products Compare Functionally



OverviewThis 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.5

NOTE

The features described in the tables in this chapter represent potential features users may be able to access, depending on the rights granted them. For example, although saving documents to the repository is an InfoView feature, you cannot do so if Save to corporate documents in the InfoView family of the WebIntelligence security command set is not enabled for you or your user group in Supervisor.


InfoView vs. WebIntelligence

InfoView vs. WebIntelligence

This section is designed to dispel any confusion about where InfoView stops and WebIntelligence begins. The two products cannot be dissociated: you access WebIntelligence through InfoView only. Furthermore, the two products use the same graphical framework and customization options, meaning that you pass transparently from one product to the other.

As long as you use certain functions, you remain within the domain of the InfoView product. As soon as you use a specific set of other functions, however, you are using the WebIntelligence product.

Here are their differences in a nutshell:• InfoView is the web-based portal used for accessing and sharing Business

Objects documents (created using BusinessObjects and WebIntelligence) and third-party files from a web browser without having to install any product or middleware on the client machine.

• WebIntelligence is a report engine used to create and modify reports from a web browser.

The following table lists the specific functions pertaining to each of these products:

Feature InfoView WebIntelligence

View Business Objects documents (.rep, .wqy and .wid) and third-party files

� �(.wid only in applet)

View Business Objects documents (.rep, .wqy and .wid) as .pdf files

�

Refresh Business Objects documents (.rep, .wqy and .wid)

�

Save Business Objects documents (.rep, .wqy and .wid) and third-party files to the repository

�

Save Business Objects documents (.rep, .wqy and .wid) and third-party files for personal use

�

Send Business Objects documents (.rep, .wqy and .wid) and third-party files to other Business Objects users

�



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.

Schedule Business Objects documents (.rep, .wqy and .wid) for automatic refresh and distribution through Broadcast Agent

�

Download document data from WebIntelligence reports (.wid and .wqy) to .csv files

�

Download WebIntelligence reports to Microsoft Excel (.wid and .wqy)

� ��(.wid in applet)

Create WebIntelligence 6.x reports (.wid) �

Edit WebIntelligence 6.x reports (.wid) �

Drill into WebIntelligence 6.x reports (.wid) �(users drill into

WebIntelligence reports in InfoView)

Interactive report viewing: sort and filter report values, pre-defined calculations, Set as section, add/replace/move objects, Turn to, Swap axis, and cell format

�

Feature InfoView WebIntelligence


BusinessObjects: 2-tier vs. 3-tier mode

BusinessObjects: 2-tier vs. 3-tier mode

The following table compares what you can do with BusinessObjects in a 2-tier and what you can do with BusinessObjects in a 3-tier deployment.

Feature BusinessObjects in 2-tier mode

BusinessObjects in 3-tier mode

Access data from personal data files (such as Microsoft Excel)

� �

Access data from queries built on universes

� �

Link data from different data sources in one document

� �

Display multiple blocks on a document page (for example, a mixture of tables, crosstabs, and charts)

� �

Use VBA macros and add-ins contained in BusinessObjects documents

�

Send documents to Broadcast Agent for automatic scheduling and processing

� �

Automatically detect and install a new version of the software over the web

�

Access data using free-hand SQL �

Access data using OLAP multidimensional servers

�

Access data using Visual Basic for Applications (VBA) procedures

�

Use data from SAP BAPI applications �

Installation from a CD � �



BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence

The table below compares what you can do with the thin-client applications InfoView/WebIntelligence versus BusinessObjects in 3-tier mode.

Feature InfoView/WebIntelligence



�


�

Access data from personal data files (such as Microsoft Excel)

�


� �


�

Create reports from data stored as XML �

Create documents with multiple reports � �

Choice of two client report editors:• HTML Report Panel for basic

reporting• Java Report Panel for advanced

users

�

Advanced query filters: define subqueries and complex conditions

� �

Create query on query results �

Reports with multiple blocks: tables and charts in the same report

� �


BusinessObjects in 3-tier mode vs. InfoView/WebIntelligence

Custom calculations: reuse formulas as variables in different reports within the same document

� �

Scope of analysis � �

Advanced drilling: for example, drill on duplicate report without modifying original

�(.wid reports only)

�

Option to synchronize drilling across all blocks in a report

�(.wid reports only)

Interactive viewing (modifying sorts and filters, adding and removing objects, adding calculations) without launching a document editor

� (.wid files in JSP

deployments only)

�

Adjust the look and feel of the interface (“skins”)

�

Dynamically switch interface languages � �


� �

Save as PDF � �

Save as Excel � �

Enhanced category management; subcategories; expandable hierarchical tree

� �

Find in Report search tool �

Find in Query Panel tool �





Processing different types of documents in InfoView

The following table compares what users can do from within InfoView alone with WebIntelligence reports, BusinessObjects documents, and other types of files. This table does not refer to features available from WebIntelligence or 3-tier deployments of BusinessObjects.

Users must have the necessary access rights assigned to them in Supervisor in order to access all of these features.

NOTE

In the following table, N/A means Not Applicable.


Processing different types of documents in InfoView

Users with InfoView licenses only can do this with... W

ebin

telli

gen

ce r

epo

rts

Bu

sin

essO

bje

cts

do

cum

ents

oth

er t

ypes

of

file

s

View documents/files � � �(if associated application is installed on the client machine)

Download third-party files from the repository

N/A N/A �(even if associated application is not installed on the client machine)

Download documents to Microsoft Excel

��(.wid only)

Save in .pdf format ��(.wid only)

� �

Download document data to a .csv file �

Upload third-party files N/A N/A �

Refresh documents/files � �

Modify documents interactively �

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 �

Users with InfoView licenses only can do this with... W

ebin

telli

gen

ce r

epo

rts

Bu

sin

essO

bje

cts

do

cum

ents

oth

er t

ypes

of

file

s


Version 2.x/5.x vs. 6.5


The following sections compare what you can do with the previous and current versions of:• InfoView/WebIntelligence• BusinessObjects in 2-tier mode• BusinessObjects in 3-tier mode

InfoView/WebIntelligence


5.x


6.5

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

�

Predefined special cells to display document information, including page numbering, refresh date, and drill filters.

�

Reports with multiple blocks (tables, forms, charts, and freestanding cells) in the same report

�

Report filters on specific sections or blocks (Java)

� �

Predefined business calculations � �

Formula language to build custom calculations: reuse formulas as variables in different reports within the same document

�



Make edits to documents in structure view without sending each incremental change to the server (Java Report Panel)

� �

Enhanced custom formatting options, including alternative table row colors, displaying object names on crosstabs, and chart and page layout options

�

Custom RGB value for color � �

(Java Report Panel only)

Use objects tagged as HTML to link documents.

� �

Interactive viewing (modifying sorts and filters, adding and removing objects, adding calculations) without launching a document editor

�

Create and distribute OLAP documents � �

Integration of OLAP viewer � �

Skins for adjusting the look and feel of the interface

�

View reports in page layout view or draft view

�

Save as PDF �

Save as Excel and retain orginal data definition and formatting (including charts)

�

Hierarchical categories �

HTML drilling � �


5.x


6.5



Advanced drilling: for example, drill on duplicate report without modifying original; multi-block drilling, hide/show the drill toolbar

�

Scope of analysis � �

Apply filters to dimensions selected to extend the scope of analysis during drill

�


5.x


6.5




Feature BusinessObjects in 2-tier mode (5.x)

BusinessObjects in 2-tier mode (6.5)

Access data using stored procedures

� �

Access data using FreeHand SQL � �


� �


� �

Use data from SAP BAPI applications

� �

Access data from personal data files (such as Excel)

� �


� �


� �

Create reports from data stored as XML

�


� �

Dynamically switch languages �


� �

Display multiple blocks on a document page (such as a mixture of tables, crosstabs, and charts)

� �




Find in Report search tool �

Find in Query Panel tool �

Installation from a CD � �






� �


� �

Access data from personal data files (such as Excel)

� �


� �


� �

Display multiple blocks on a document page (such as a mixture of tables, crosstabs, and charts)

� �


� �


� �

Access data using stored procedures

� �


Index

Index$BO_FILE_PATH environment variable 405

setting 406.key files

defined 349location 112where they must be copied 110

.lsi file 112, 354location 112

.rep filesmigrating between lifecycle environments 263purging data providers 263viewing with web server in CGI mode 156

.rkey file 398copying an existing 395location of 112obtaining 395

.wid filesautomatically overwriting 263JSP for interactive viewing 358

.wqy filesautomatically overwriting 263

@Variable function 453

Symbols2-/3-tier deployments 1932-tier architecture

and BusinessObjects 69and database connections 90overview 65, 133

2-tier deploymentsassociated platforms 79associated products 76pros and cons 188

3-tier architecture 67-75administration on Windows machines 156and database connections 90client tier 69middle tier 70overview 66

3-tier deploymentsand BusinessObjects in 2-tier mode 77associated platforms 79associated products 77basic extranet configurations 202basic intranet configurations 195Business Objects processing layer 72clusters 80DMZ configurations 197-201extranets 202implementing basic extranets 302implementing basic intranets 298list of scenarios 192multiple clusters in intranet 218single-cluster

intranet/extranet 222using IP redirectors 214using reverse proxies 211when do you need a Windows node in your

cluster? 155

Aactive users 138ActiveX

version compatibility with BusinessObjects 6.x 392

Admin Tool see Administration Console


Index

administrationAdministration Console 95-97and Windows machines 156of Audit facility 101of Auditor 102of Broadcast Agent 98of the Business Objects system 93-104when you need a Windows machine 156

administration client machinewhat is installed on 290

Administration Console 95-97activating the Audit facility 101administering Broadcast Agent 98and UNIX 156and WIProcessManager 87interface 96size 401types 97who can use it? 97

administration productsAdministration Console 52Auditor 49Configuration Tool 52Designer 48diagnostics tools 53Supervisor 46

Administration SDKrequired environment 358

Administration Serverand the repository 113role in administration layer 72

administrator.exe 97Advanced

user type 137air gap 243AltSystemFont key 385Analyst user type

and deployment type 370defined 137

Application Foundation 38Application Server pages option (installer) 291, 293

application serversdeployment rules 289-293deported 208IIS or J2EE? 71in DMZ configurations 200role in system’s web layer 70selecting software 153what is installed/configured on them 291

architectureassociated platforms 79centralized or decentralized? 170designing 149of clusters 161of repository 166

ASF 85-88administering using wasfadm 103and fault tolerance 87and load balancing 87callback interface 86client interface 86configuration 88configuration file 88configuration using Configuration Tool 88daemons 87external interface 86how it works 86internal interface 86

ASF clientinstalling 291

ASP configurationsand DMZ 303extranets 303overview 71splitting web and application servers 161vs JSP 357

Audit facility 101and Auditor 102in development lifecycle 248


Index

Auditoradministering 102and Java SDK 411and the Auditor facility 102deploying 411in development environments 249in development lifecycle 249monitoring multiple clusters 412overview 49required environment 358

authentication 442-463defined 118, 135

authentication modesdelegated to the web server 119

authorization 442-463defined 118, 135

BB2B 202bandwidth

dealing with limited 175Basic authentication 119

and BusinessObjects in 3-tier mode 396and web servers in CGI mode 380

binary data type support 342BLOBs 342block-level security 462boconfig.cfg file

and fonts 384BODocGenISAPI.dll file 308BOManager

Enable batch processing parameter 401required permissions for Broadcast Agent jobs

404role in processing layer 72Scheduler login cache duration parameter 402server sizing 401

BOUSER variableusing to restrict data access 453

BreakOnVBAError 410

Broadcast Agentadministering 98administering using Administration Console 98administering using Broadcast Agent Console

99and offline mode 121and the LocData directory 409and UNC paths 406and VBA 44custom macros and UNIX 155failure recovery 164File Watcher option 404how many Schedulers 400login cache 402path and filenames 404report bursting 400required permissions for BOManager 404Scanning Repository Delay parameter 98sizing guidelines 400swapping space 401tasks 98time and dates 165using shared and personal connections 408using the cache 403Windows or UNIX 402

Broadcast Agent Console 99and the repository 114and UNIX 157size 401what you can do with 100

Broadcast Agent ManagerMax. no. WebIntelligence 2.x jobs running

parameter 402Max. no. WebIntelligence 6.x jobs running

parameter 402Schedulers 73

Broadcast Agent option (installer) 293Broadcast Agent Publisher

description 44Broadcast Agent Scheduler

defined 399overview 43vs. the Scheduler 399

Business Intelligencedefined 28


Index

Business Objectsconsulting services 13, 15, 144customer support 144desktop products 31-35documentation 12Documentation Supply Store 11secure configuration 27support services 13training services 13, 15

Business Objects processing layer 72Business Objects products 30-57

Auditor 49BusinessObjects 31BusinessObjects in 3-tier mode 33BusinessQuery 34, 48choosing which products and how they are

deployed 362Data Access acks 54demonstrations 55deploying 356-415deploying Auditor 411deploying Broadcast Agent 399-410deploying BusinessObjects 391-398deploying InfoView 380deploying WebIntelligence 380deployment rules 289-293InfoView 36Supervisor 46UNIX support 155v5/v6 comparison 476WebIntelligence 38which can benefit from IP redirectors 214which connect to the repository 114which products with which architectures? 76

Business Objects serverand installation of BusinessObjects in 2-tier

mode 391and reverse proxies 211defined 186in extranet configurations 203in multiple-cluster intranet configurations 218

Business Objects server option (installer) 292

Business Objects systemadministration 93-104analyzing activity 50clusters 80development lifecycle 241how it communicates 83monitoring and analyzing activity 101typical user types in 136

BusinessObjects2-tier vs 3-tier mode 479and fonts 391and offline mode 122automatic binary slice management 342choosing a repository 349deploying 391-398deploying using Citrix 190in 3-tier deployments 77overview 31Save for all users option 353scheduling documents 98see also BusinessObjects in 2-tier modesee also BusinessObjects in 3-tier mode

BusinessObjects 6.5 30-57BusinessObjects Auditor see AuditorBusinessObjects documents

see .rep filesBusinessObjects in 2-tier mode

as client 69compared with 3-tier mode 367exclusive functionality 367overview 31see also BusinessObjectssetting locale 360


Index

BusinessObjects in 3-tier modeand Basic authentication 396and firewalls 397and security domain selection 398and SSL 396and system resources 367and WIADEServer 393and Windows authentication 396automatic updating 392compared with 2-tier mode and InfoView 367deploying 391firewalls and proxies 371installing 392language selection 360obtaining the .rkey file 395overview 33required user rights 394see also BusinessObjectsversion compatibility check with InfoView 394

BusinessObjects OLAP Connect 54BusinessObjects processes

defined 72, 73BusinessObjects Web Installer option (installer)

293, 393BusinessQuery

deploying using Citrix 190overview 34

BusinessQuery MD 35

CCAB files

for BusinessObjects in 3-tier mode 393for WebIntelligence Java Report Panel 381

cachesand Broadcast Agent 403pre-loading 402

cachingBroadcast Agent login information 402scheduled documents 402

capacity planning 132CGI mode

and Basic authentication 380charsets

deployment requirements 360ensuring proper Unicode report display 334

Cisco CCS 318Cisco LocalDirector see IP redirectorsclient certification (SSL) 470client machines

in basic extranet configurations 302in multihomed configurations 320what is installed/configured on 290

client nodesreason for adding to a cluster 161

client tier 69client-server see 2-tier architecturecluster 218cluster architecture 161cluster nodes

and networks in extranets 303defined 80reasons for adding 161what is installed/configured on 292

cluster storageand IP redirector configurations 219and IP redirectors 318and multiple-instance servers 225and WIStorageManager 74for heterogeneous clusters 324in heterogeneous clusters 277in multiple-cluster configurations 218shared storage in production environment 265sharing between clusters 163

cluster terminology 61


Index

clustersauditing multiple 412changing repositories 354configuring 52defined 80deployment rules 289-293geographically distributed 164heterogeneous 154, 158how many servers under Windows 163multiple clusters in an intranet 218processing power vs number of machines 162reason for adding client node 161setting locales 359using multiple 163using multiple web servers in a single cluster

205version 5.1/2.6 155what is installed/configured in 290when do you need a Windows node? 155with multiple web servers 223

concurrent users 138configuration

of multihomed deployments 320options for IP redirectors 215

Configuration Tool 52installing 291naming clusters 412ORB configuration 88

configurations see deployment configurationsConnection Server 89

and Broadcast Agent 408and the repository 113deploying 372

connection strings 446connections

and 2-tier systems 90and 3-tier systems 90defined 89defining OLAP connections 437shared and personal 408

connectivitiesconfiguration guidelines 408

Console option (installer) 293consultants

Business Objects 13, 144

cookiesimplementing the Sticky command with 313

CORBAcontainer/component model 85overview 83persistent objects in 87

Corporate Documents list 37creating

users and groups for development lifecycle 253

customer support 13, 144

Ddaemons

ASF 87Data Access drivers 75data access drivers 89Data Access packs 75data management

as a deployment consideration 134data protection

at universe level 446-461connection strings 446object-level 447row-level 451using BOUSER variable 453using table mapping 457

data providerspurging 263

Database Access acks 54Database Access Packs

BusinessObjects OLAP Connect 54database connections

see connections 90databases

components in Business Objects system 75location 168maintaining security 463

defaultConfig.xml filemodifying for Unicode support 332

delegated to the web server mode 119Demilitarized Zone see DMZ configurationsdemo

materials 11demonstrations 55


Index

deployingAuditor 411Broadcast Agent 399-410BusinessObjects 391-398Connection Server 372InfoView 380specific products 356-415WebIntelligence 380WIStorageManager 380

deploymentchoosing products and how they are deployed

362development lifecycle 241geographically distributed 164modeling 148-182rules for all configurations 289-293supported configurations 183-236

deployment architecturesoverview 65which products with which architectures? 76

deployment configurations3-tier 67basic extranet scenarios 202basic intranet 195centralized 170decentralized 176geographically dispersed 347heterogeneous 154implementing supported configurations

287-325installation rules 289-293modeling 148-182multilingual 230multiple-clusters in an intranet 218single-cluster intranet/extranet 222supported configurations 183-236terminology 186using IP redirectors 214using reverse proxies 211

deployment lifecycle 241deployment models 159

deployment process 267-285and geographical distribution 134creating a pilot project 143definition 24planning for disaster recovery 142pre-deployment checklist 129

Designerand object-level security 447and UNIX 156configuring universes 259deploying using Citrix 190exporting universes 258, 262importing universes 262overview 48Save for all users option 351setting language 360the security it provides 442using BOUSER variable 453using the @Variable function 453

desktop products 31and the repository 114BusinessObjects 31BusinessQuery 34deployment guidelines 357

Developer Suite 12, 14, 56programming languages 57

development environmentdefined 242planning 246

development lifecycle 241and Auditor 249and the Audit facility 248creating environments 252creating the repository 252how many deployments? 244, 245migrating between environments 261naming universes 257role of development users 258types of users 250using single repository 244what types of documents? 251what types of users? 250

development userstheir role 258

diagnostic tools 53


Index

digital certificates 467, 469disaster recovery 142Disconnect after each transaction parameter 408disk mirroring

and shared storage 318Distribute via Web server option 408distributed configurations

advantages 82defined 186

DMZand ASP configurations 303defined 186, 198in typical extranet configurations 203

DMZ configurations 197-201implementing 299where to place reverse proxy 212

document domaincharset 334

document domainsand development lifecycle 244assigning 256creating for development lifecycle 252defined 109moving documents from one to another 350OBJ_X_DOCUMENTS table 342reducing size of 346size of 344using multiple 167

documentationCD 11feedback on 12on the web 11printed, ordering 11roadmap 11search 11

Documentation Supply Store 11

documentsand development lifecycle 251and the document domain 109deleting 264distributing 38exporting to repository 263importing from repository 262making available to users of other repositories

353migrating between lifecycle environments 262moving between repositories 351moving from one domain to another 350organizing in different domains 252WebIntelligence OLAP 43

documents see BusinessObjects documentsdomains see repository domainsdynamic server pages

processing by web layer 70

Eeducation see trainingElectronic Data Interchange 202enterprise mode

defined 121Explorer option (installer) 293exporting

documents to the repository 263universes to the repository 258

external authentication modesSSO authentication 119Windows 119

external users 120Business Objects authentication 119

extranets 28and reverse proxies 211and routers 302basic deployment configurations 202defined 186, 202implementing basic configurations 302sharing information over 38single web server for intranet and extranet

users 222single-cluster configurations 222


Index

Ffailover

ensuring 163for primary node 164in production environment 265using IP redirectors 214

failure recoveryfor Broadcast Agent 164

fault toleranceand the ASF 87

feedbackon documentation 12

File Watcherand pathnames 407

File Watcher option (InfoView) 404filter objects 250filtering 199firewall rule

defined 197firewalls 197-199

and BusinessObjects (3-tier) 371and BusinessObjects in 3-tier mode 397and SQL 362between cluster and application server 208defined 186in DMZ configurations 197-201inner and outer 199location in basic extranets 303

font platforms 381fontalias.xml file 382, 386

modifying for Unicode support 330FontRoot key 385fonts

adding 387and BusinessObjects 391defining default WebIntelligence fonts 332managing for WebIntelligence 381required for using a Unicode database 328TrueType 383updating font mapping for Unicode support 329

Free Hand SQLand UNIX 155

GGIOP 84

Hheterogeneous clusters 154, 158

and storage 277directing logins to UNIX or Windows servers

323HTML documents

and WIADEServer 73how fonts are used 381viewing in InfoView 364

HTML Report Panel 40HTTP

client-server communication 365communication through firewalls 199, 397

https 471

IIIOP protocol 84

and CORBA 198IIS

and DMZ configurations 303IIS application server configurations 71importing

documents from the repository 262universes from the repository 262

Inbox Documents list 37


Index

InfoViewand Application Foundation 38and system resources 367compared with BusinessObjects in 2- and 3-

tier modes 367deploying 380distributing documents with 38document lists 37Enhanced Document Viewing option 402File Watcher option 404interface 37overview 36Overwrite option 263repository selection 349Standard HTML option 402using enhanced document viewers with web

servers in CGI mode 156version compatibility check with

BusinessObjects 394InfoView option (installer) 293inner firewall 199installation

and VBA 395Application Server pages option 291Business Objects server option 292BusinessObjects in 3-tier mode 392of Configuration Tool 291summary of installer options 293Web Server pages option 291

Interactive user type 136intranets 28

basic intranet deployment configurations 195defined 186implementing basic intranet deployments 298multiple-cluster configurations 218single web server for intranet and extranet

users 222single-cluster configurations 222

IP address translation 199

IP redirectorsand multiple-instance configurations 322client-assigned load balancing 215configuration options 215configuring for maximum connections 314configuring for weighted configuration 314defined 187description 214implementing 311-318in production environment 265software/tasks that can use them 214Sticky command 215weighted configuration 215when primary node fails 315when web server fails 315with a single cluster and multiple web servers

205iswi.dll file 308

JJ2EE application server configurations 71Java applets

Administration Console 97and 3-tier deployments 66

Java Report Panel 42post-installation problems 390

Java SDKand Auditor 411

Java Virtual Machinerequired for Java Report Panel 380

JHSAL see HSAL 64JSP configurations

extranets 304interactive viewing of WebIntelligence reports

358overview 71splitting web and application servers 161vs ASP 357

KKeep the connection active during the whole

session parameter 408Keep the connection active for X minutes

parameter 408


Index

Knowledge Base 14

LLAN 368language

setting 359LDAP

how Business Objects uses it 120licenses

and migration users 255live environment 243load balancing

and the ASF 87in production environment 265using IP redirectors 214

LocalDirector see IP redirectorslocales

and geographically-dispersed deployments 164

and Unicode databases 334constraints 360defined 359setting 359

localnode.xml file 87LocData directory 409

recommended configuration 409login

preventing users from logging in from previous releases 443

LOVsin universe 252

Mmap files (UDM) 424maximum connection configuration

configuring IP redirector for 314Microsoft Excel

and BusinessQuery 34middle tier 70

middleware 89and CORBA communication 83and universes 48number of open connections 343where it’s installed with 3-tier BusinessObjects

33migrating

between environments 261BusinessObjects documents between lifecycle

environments 263documents between lifecycle environments

262WebIntelligence reports between lifecycle

environments 263migration users

and licenses 255defined 255migrating universes 261

modeling your deployment 148-182modules

defined 72monitoring system activity 101MS OLAP Services (Microsoft SQL Server OLAP

Services) 54multihomed configurations 227

client machines in 320how server machines are affected 320implementing 319

multimediaquick tours 12

multiple clusters 163auditing 412in production environment 265

multiple repositories 166and multiple clusters 165

NNetwork Interface Cards 227networks

access and firewalls 197and cluster nodes 303and performance 370overhead 367

Node Load Factor see node weight


Index

node weightand load balancing 88

OObject Request Broker see ORBobject-level security 447objects

defined 83filter objects 250persistent 87

objects.lsi file 112objects.ssi file 112offline mode

and Broadcast Agent 121and BusinessObjects 122defined 121

OLAP 367defined 418defining connection in WebIntelligence 437see WebIntelligence for OLAP Data Sources

43OLAP Access Pack 89OLAP data sources

and platform requirements 232and UNIX 155

olapreg.ini file 427OLE 2 objects 154, 158OLE Automation under Windows 72Online Customer Support 13online mode

defined 121Open Type fonts 330, 387operating system

selecting 153optimizing

Broadcast Agent with caches 402performance by distributing workload 192performance through database location 171performance with the Administration Console

52security domain 352

ORBconfiguration using Configuration Tool 88configuring 52defined 83

Orbixhow it is configured and its environment set 88

outer firewall 199overhead

network 367server 367

Overwrite option (InfoView) 263

PPAR 153pathnames

Windows/UNIX conversion 405pdac.lsi file

defined 409PDF documents

and WIADEServer 73generation time 403how fonts are mapped 384how fonts are used 381viewing in InfoView 364

performanceand network issues 370and WANs 370

personal documentsstorage space for 380

Personal Documents list 37pilot project 143platforms

and programming languages 57constraints 232font platforms 381support 153supported with deployment architectures 79

portalin a 3-tier deployment 69

power users (user profile)and choice of product or deployment 370proportion of 130

presentation cache 402presentation layer 70Prevent from Overwriting Universe security

command 257


Index

primary nodeand WILoginServer 161defined 80failover capacities 164what it does 81why add another primary node? 161

processing layer 72-73Product Availability Report see PARproduct line see Business Objects productsproduction environment

defined 243planning and building 265

profilesuser 136

programming languagesused to access Developer Suite 57

proxy serversand BusinessObjects (3-tier) 371defined 187

public key encryption 468-469Public Key Infrastructure 467publications 44purging

data providers for BusinessObjects documents 263

data providers for WebIntelligence reports 263

RRAM

required for scheduled documents 400Rapid Application Development (RAD) 258RDBMS

location 168security 443selecting 153

Readers (user profile) 136and InfoView 370

registered users 138remote key file see .rkey filereport bursting 400

and section-level security 463Reporter option (installer) 293reports see WebIntelligence reports

repositories 105-123and development lifecycle 244and your data warehouse 116Auditor-dedicated 413changing a cluster’s repository 354checking integrity 264choosing a repository from BusinessObjects

349compatibility issues 123creating for development lifecycle 252deleting documents from 264designing architecture 166domains 108exporting documents to 263exporting universe to 258how much space? 344importing documents from 262importing universes from 262location 168moving documents and universes from 351selecting from InfoView 349setting up multiple 349setting up multiple repositories 349synchronizing between multiple repositories

350using multiple 115, 165, 166using separate for development and

production 243which components access them 113working with or without 121

repository databasebinary data type support 342binary slice 342choosing 341maximum number of open connections 343row-level locking 341

repository domainsdistribution over multiple servers 347moving universes among 351multiple 109overview 108

resourcesadministering using wresadm 103defined 103


Index

reverse proxies 211and ASP configurations 303defined 187, 211overview 211where to place them in DMZ configurations 212

routersin basic extranet configurations 302

row-level security 341, 451

SSAP BW (SAP Business Information Warehouse)

54scalability 132Scan and Repair utility 264, 346Scheduler option (installer) 293Schedulers

and login cache 402and the repository 114Delay between retry parameter 99deploying 401how many 400overview 73server sizing 401tuning 98what jobs they can process 401

scheduling documentsusing shared and personal connections 408using UNC paths 406

sdac.lsi filesdefined 409synchronizing 409

searchdocumentation 11

secondary nodesdefined 80what they do 81why add another? 161

section-level security 463secure HTTP transactions 467-472Secure Socket Layers see SSL

securityand multihomed configurations 227API for managing Business Objects web

security 72at the product feature level 444at universe level 446-461authentication and authorization 442-463automating relational database security 463block-level security 462digital certificates 467DMZ configurations 197-201extended security commands 445firewalls 197-199for WebIntelligence OLAP folder 420multiple security domains 348object-level security 447Public Key Infrastructure 467RDBMS 443row-level security 451section-level 463using BOUSER variable 453using connection strings 446using table mapping 457web servers as security risks 211

security commandsCreate Documents (BusinessObjects

Documents family) 394defined 444Download 3-Tier BusinessObjects

(WebIntelligence Administration family) 394

Read Corporate Documents (InfoView family) 394

Read Inbox Documents (InfoView family) 394Use WebIntelligence HTML Report Panel 381Use WebIntelligence Java Report Panel 381

Security Configuration Tool 118


Index

security domaincentralized within decentralized architecture

176defined 108optimizing 352selecting from BusinessObjects 349, 398selecting from InfoView 349single or multiple? 348using multiple 115

security table 454self restricting join 455server certification (SSL) 470server products

deployment guidelines 357InfoView 36WebIntelligence 38

serversBusiness Objects server 186how many in a Windows cluster 163in multihomed configurations 320multiple-instance under UNIX 225overhead 367processing power under UNIX 163summary of installer options for 293what is installed/configured on 290when do you need a Windows node? 155why use UNIX servers? 154

service packstesting 242

session management 73Session Stacks 95session stacks 95sessions

and WIQT 73shared connections

enabling VBA macros to access 410software

selecting system software 153SQL

and firewalls 362query 362standard reporting configuration 26

SSL 467-472and BusinessObjects in 3-tier mode 396implementing 472levels of security 470

SSO authentication mode 119stacks 153

see also Session Stacks 95Sticky command

constraints 217defined 215

storagesee cluster storage 74

storage see cluster storage 324stored procedures

and UNIX 155Supervisor 253

and object-level security 447and row-level security 451and time restrictions 445and UNIX 156assigning domains 256checking repository integrity 264compatibility between versions 123deleting documents from repository 264deploying using Citrix 190exporting universes 351overriding default universe configuration 259overview 46Prevent from Overwriting Universe 257security commands 444security measures overview 442setting language 360setting up multiple repositories 349Use BusinessObjects Username and

Password option 443using table mapping 457Work with Universe Overrides option 351

Supervisor over the Weband Administration Server 72required environment 358

supportcustomer 13

symmetric-key cryptography 468


Index

synchronizingrepositories 350sdac.lsi files 409

SystemFonts key 385

Ttable mapping 457

using for row-based restrictions 458TCP

balancing TCP traffic with IP redirectors 214communication through firewalls 199

TCP/IPand intranets 28

terminologycluster 61concerning deployment configurations 186how it has changed 61

testing environmentdefined 242

tiersdatabase tier 75middle tier 70the client 69

time restrictions 445time zones

and clusters 164Tips & Tricks 12Tomcat

and Java SDK 411training

on Business Objects products 13troubleshooting

diagnostic tools 53TrueType fonts 383

UUAT environment

defined 242UDS Designer 424UDS service 424UNC 404

defined 406

Unicodeand BusinessObjects 391and use of fonts 328updating font mapping 329

Unicode databases 230universe domains

and development lifecycle 244assigning 256creating for development lifecycle 252defined 109using multiple 167

universesaccess from BusinessObjects in 3-tier mode

395and Unicode support 334configuring 259defined 48, 75enabling the overwriting of 257exporting to repository 258, 351file name 257filter objects 250importing from repository 262in development lifecycle 250migrating between lifecycle environments 261moving between repositories 351moving from one domain to another 351naming file names 257overriding default configuration 259restricting 446-461restricting objects using BOUSER variable 453


Index

UNIXand Broadcast Agent 402and Business Objects products 155and BusinessObjects (3-tier) 33and case-sensitivity 405and custom macros for Broadcast Agent 155and Free-Hand SQL 155and OLAP data sources 155and OLE 2 objects 158and processing power 163and stored procedures 155and Supervisor and Designer 156and the Administration Console 156and the Broadcast Agent Console 157and XML data providers 155diagnostic tools 53implementing multiple-instance configurations

321mounting directories to map to other machines

405multiple nodes on single servers 80multiple-instance servers 225pathnames in this guide 60setting $BO_FILE_PATH environment variable

406supported software 153using alongside Windows 158why use UNIX servers? 154

Use BusinessObjects Username and Password option 443

Use WebIntelligence Java Report Panel security command 381

user acceptance testing 242user activity

peak 132user groups

creating for development lifecycle 253user hierarchy

in development environments 250user locales

setting 360user profiles 136

as factor in choosing product or deployment 369

user typesdefined 136proportions in typical deployment 137

user.log file 101users

concurrent/active users ratio 139coping with too many 163creating for development lifecycle 253power 130registered/active users ratio 138selecting a language 359

VVBA 44

and Business Objects installation 395enabling macros to access shared connections

410virtual private networks 202Visual Basic scripts

and UNIX 155, 232

WWANs

and choice of product deployment 370wasfadm tool 103

retrieving list of processes/ports 310wdeploy tool

UNIX 275, 281Windows 270

webcustomer support 13getting documentation via 11useful addresses 14

Web Server pages option (installer) 291, 293


Index

web serversas security risk 211CGI mode and authentication 380deployment rules 289-293implementing a single web server for intranet/

extranet users 325in DMZ configurations 200multiple 205multiple within one cluster 223number used with IP redirector configuration

215pathnames 408role in system’s web layer 70selecting software 153single web server for intranet and extranet

users 222what is installed/configured on them 291

WebIntelligencedefining default fonts 332deploying 380deploying the Java Report Panel 380filters 40font management 381HTML Report Panel 40Java Report Panel 42modifying default interface fonts 387overview 38problems after installing Java Report Panel

390prompts 40updating font mapping 329use of fonts for multilingual documents 328

WebIntelligence for OLAP data sources 43defining connection 437deploying 417-437map files (UDM) 424security settings 420

WebIntelligence HTML Report Paneland JSP configurations 358deploying 381

WebIntelligence Java Report Paneldeploying 380rights required to download 381size 381

WebIntelligence OLAP Cache Service 435

WebIntelligence option (installer) 293WebIntelligence reports

managing fonts 381migrating 263migrating between lifecycle environments 263multilingual 328purging data providers 263see also .wid files and .wqy files

WebIntelligence Universal Drill Through Service (UDS) 435

weighted configurationconfiguring IP redirector for 314

WIADEServerand installing 3-tier BusinessObjects 393and Windows 380role in processing layer 73

WIAPIBrokerand session management 73role in processing layer 73

WIDispatcherrole in processing layer 73

WIGenerator 87WIImpactAnalysis 73WILoginServer

and primary node 161and the repository 113

Windowsand Broadcast Agent 402and Business Objects administration tasks 156and case-sensitivity 405and WIADEServer 380how many cluster servers 163pathnames 405pathnames in this guide 60supported software 153using alongside UNIX 158when do you need a Windows node in your

cluster? 155why choose Windows? 155

Windows 2000required profile for downloading Java Report

Panel 381Windows authentication

and BusinessObjects in 3-tier mode 396Windows authentication mode 119


Index

Windows Registryand fonts 384

WinInetand download of BusinessObjects installer 393

WIOLAPGenerator 419WIQT

and BusinessObjects processing 393and sessions 73and the repository 113Enable batch processing parameter 401role in processing layer 74

WIReportServerrole in processing layer 74

WISessionManager 74number of instances 95role in administration layer 74

WIStorageManagerand primary node 161deployment advice 380role in administration layer 74

wmainkey script 110workgroup mode

defined 121wresadm tool 103

XXML data providers

and UNIX 155

ZZABO see BusinessObjects in 3-tier modeZaboCheckAndRunControlClass file 392ZABOInstallPopup.asp file 395ZABOInstallPopup.jsp file 395


Index