How The BusinessObjects System Works

How the Business Objects System Works
BusinessObjects Enterprise 6.1 Business Intelligence

Windows and UNIX
Copyright
No part of the computer software or this document may be reproduced or transmitted in any form
or by any means, electronic or mechanical, including photocopying, recording, or by any
information storage and retrieval system, without permission in writing from Business
Objects S.A.
The information in this document is subject to change without notice. If you find any problems
with this documentation, please report them to Business Objects S.A. in writing at
documentation@businessobjects.com.
Business Objects S.A. does not warrant that this document is error free.
Copyright Business Objects S.A. 2003. All rights reserved.
Printed in France.
Trademarks
The Business Objects logo, WebIntelligence, BusinessQuery, the Business Objects tagline,
BusinessObjects, BusinessObjects Broadcast Agent, Rapid Mart, Set Analyzer, Personal
Trainer, and Rapid Deployment Template are trademarks or registered trademarks of Business
Objects S.A. in the United States and/or other countries.
Contains IBM Runtime Environment for AIX(R), Java(TM) 2 Technology Edition Runtime
Modules (c) Copyright IBM Corporation 1999, 2000. All Rights Reserved.
This product includes code licensed from RSA Security, Inc. Some portions licensed from IBM
are available at http://oss.software.ibm.com/icu4j.
All other company, product, or brand names mentioned herein, may be the trademarks of their
respective owners.
Use restrictions
This software and documentation is commercial computer software under Federal Acquisition
regulations, and is provided only under the Restricted Rights of the Federal Acquisition
Regulations applicable to commercial computer software provided at private expense. The use,
duplication, or disclosure by the U.S. Government is subject to restrictions set forth in
subdivision (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at 252.2277013.
Patents
U.S. Patent Numbers 5,555,403, 6,247,008, and 6,578,027.
Part Number
376-50-610-01
Contents
Preface
Contents
Figures
Maximizing Your Information Resources
11
Information resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Useful addresses at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 1
Functional Basics
21
Understanding the workflows in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . 23

The presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
The processing layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Communication protocols between system components . . . . . . . . . . . . . . . 41
How system administration works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
How the system creates audit logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
System storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapter 2
Startup and Shutdown
57
How the system starts under Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

How the system starts under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
WIProcessManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Contents
Chapter 3
Login and Session Management
69
What are sessions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
How WILoginServer works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
How the system handles different authentication methods . . . . . . . . . . . . . 79
Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Starting InfoView user sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3-tier BusinessObjects user sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
WebIntelligence 6.x document sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 4
Documents and their Creation
97
Document types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
How documents are stored and organized . . . . . . . . . . . . . . . . . . . . . . . . 103
Creating WebIntelligence documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 5
Downloading and Using BusinessObjects
115
What is BusinessObjects in 3-tier mode? . . . . . . . . . . . . . . . . . . . . . . . . . 117

The BusinessObjects report engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
BusinessObjects processing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Downloading BusinessObjects from InfoView . . . . . . . . . . . . . . . . . . . . . . 120
Retrieving a corporate document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Displaying a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Refreshing documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Creating BusinessObjects documents using a web connection . . . . . . . . 131
Using BusinessObjects in offline mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Contents
Chapter 6
Document Processing from InfoView
139
Displaying document lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Refreshing document lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Displaying BusinessObjects documents . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Refreshing BusinessObjects documents . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Displaying WebIntelligence 6.x documents . . . . . . . . . . . . . . . . . . . . . . . . 157
Refreshing WebIntelligence 6.x documents . . . . . . . . . . . . . . . . . . . . . . . . 161
Displaying WebIntelligence 2.x documents . . . . . . . . . . . . . . . . . . . . . . . . 163
Refreshing WebIntelligence 2.x documents . . . . . . . . . . . . . . . . . . . . . . . . 167
Saving documents as corporate documents . . . . . . . . . . . . . . . . . . . . . . . 169
Saving documents as personal documents to the portal . . . . . . . . . . . . . . 172
Saving personal documents to a local drive . . . . . . . . . . . . . . . . . . . . . . . . 175
Sending documents to other users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Processing third-party files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Scheduling documents with Broadcast Agent . . . . . . . . . . . . . . . . . . . . . . 185
Appendix A
Logical Components/Physical Files
197
Component/file reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Index
201
Contents
Contents
Figures
1-1 Understanding workflow diagrams in this part of the guide . . . . . . . . . . 23
1-2 Three main application server components . . . . . . . . . . . . . . . . . . . . . . 27
1-3 What an IIS server hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1-4 What a J2EE application server hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1-5 Disabling/enabling session stacks in the Administration Console . . . . . 38
1-6 The Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1-7 Communication protocols used in the system . . . . . . . . . . . . . . . . . . . . 41
1-8 Login dialog box for the Administration Console . . . . . . . . . . . . . . . . . . 42
1-9 Workflow: Administration Console login . . . . . . . . . . . . . . . . . . . . . . . . . 43
1-10 How the Administration Console administers clusters . . . . . . . . . . . . . 45
1-11 Inactivity timeout for Administration Server . . . . . . . . . . . . . . . . . . . . . 46
1-12 Workflow: How an Administration Server session is authenticated . . . 47
1-13 Administration Server parameters in the Administration Console . . . . 48
1-14 Where the system stores resources . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2-1 System startup under Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2-2 How wstart starts multiple clusters under UNIX . . . . . . . . . . . . . . . . . 63
2-3 What the webi.sh script does under UNIX . . . . . . . . . . . . . . . . . . . . . 64
2-4 Setting the number of WIQT processes in the Administration Console . 66
3-1 Sessions in Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3-2 Workflow: Global view of how WILoginServer works . . . . . . . . . . . . . . . 74
3-3 Workflow: Filling or refreshing the login cache . . . . . . . . . . . . . . . . . . . 76
3-4 Manually refreshing the WILoginServer cache . . . . . . . . . . . . . . . . . . . 78
3-5 Authentication methods in the Administration Console . . . . . . . . . . . . . 79
3-6 WIAPIBrokers role in session management . . . . . . . . . . . . . . . . . . . . . 82
3-7 InfoView login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3-8 InfoView login dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3-9 Workflow: Establishing an InfoView session . . . . . . . . . . . . . . . . . . . . . 86
3-10 Workflow: Launching BusinessObjects (3-tier mode) from Start menu 90
3-11 Option for creating/editing documents with BusinessObjects . . . . . . . 91
3-12 New Document section of the InfoView interface . . . . . . . . . . . . . . . . 91
Figures
3-13 Option for viewing BusinessObjects documents in BusinessObjects . 92

3-14 Workflow: Launching BusinessObjects from InfoView . . . . . . . . . . . . 94
4-1 WebIntelligence 6.x document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4-2 BusinessObjects document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4-3 Microsoft PowerPoint file displayed in InfoView . . . . . . . . . . . . . . . . . 101
4-4 An example WebIntelligence HTML Report Panel . . . . . . . . . . . . . . . 104
4-5 An example WebIntelligence Java Report Panel . . . . . . . . . . . . . . . . 105
4-6 WebIntelligence option in the InfoView Create/Edit Options tab (ASP) 106
4-7 Links for creating documents from InfoView (ASP) . . . . . . . . . . . . . . . 106
4-8 Universe list in WebIntelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4-9 Workflow: Loading the WebIntelligence Report Panel applet (Java) . 108
4-10 Workflow: Creating the empty WebIntelligence 6.x document (Java) 108
4-11 Workflow: Opening and displaying the universe (Java) . . . . . . . . . . 109
4-12 Workflow: Running the query and displaying the results (Java) . . . . 110
4-13 Workflow: Loading the HTML Report Panel . . . . . . . . . . . . . . . . . . . 111
4-14 Workflow: Creating the empty .wid document (DHTML) . . . . . . . . . . 111
4-15 Workflow: Importing and opening the selected universe (DHTML) . . 112
4-16 Workflow: Running the query and displaying the results (HTML) . . . 113
5-1 Option for creating/editing documents with BusinessObjects . . . . . . . 120
5-2 Option for viewing BusinessObjects documents in BusinessObjects . 120
5-3 Workflow: Downloading by clicking the Download link . . . . . . . . . . . . 122
5-4 Workflow: Downloading by opening/creating a document . . . . . . . . . 123
5-5 Workflow: Retrieving a corporate document in BusinessObjects . . . . 126
5-6 Workflow: Displaying a report in a BusinessObjects document . . . . . 128
5-7 Workflow: Refreshing a document in BusinessObjects . . . . . . . . . . . . 130
5-8 Workflow: Opening a universe and creating the query . . . . . . . . . . . . 135
5-9 Workflow: Generating and running the query . . . . . . . . . . . . . . . . . . . 137
6-1 Corporate Documents list in InfoView . . . . . . . . . . . . . . . . . . . . . . . . . 141
6-2 Workflow: Displaying the Corporate Documents list . . . . . . . . . . . . . . 141
6-3 Setting automatic refresh options for document lists . . . . . . . . . . . . . 142
6-4 Manually refreshing a document list . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6-5 Workflow: Refreshing the Corporate Documents list . . . . . . . . . . . . . 143
6-6 BusinessObjects document viewing options . . . . . . . . . . . . . . . . . . . . 144
6-7 BusinessObjects document displayed in HTML format . . . . . . . . . . . . 145
6-8 Workflow: Importing and opening a .rep document in HTML . . . . . . . 147
Figures
6-9 Workflow: Generating HTML for .rep document (SDK) . . . . . . . . . . . . 148

6-10 Workflow: Generating HTML for .rep document (tunneling) . . . . . . . 149
6-11 A BusinessObjects document displayed in PDF format . . . . . . . . . . . 150
6-12 Workflow: Displaying a .rep document in PDF format . . . . . . . . . . . . 151
6-13 BusinessObjects document in enhanced document viewer . . . . . . . . 152
6-14 Workflow: Viewing a .rep document in the enhanced viewer . . . . . . . 154
6-15 Workflow: Refreshing a .rep document without prompts . . . . . . . . . . 155
6-16 Workflow: Refreshing a .rep document with prompts . . . . . . . . . . . . 156
6-17 WebIntelligence document viewing options . . . . . . . . . . . . . . . . . . . . 157
6-18 Workflow: Initializing a WebIntelligence 6.x session . . . . . . . . . . . . . 158
6-19 Workflow: Opening and importing a .wid document . . . . . . . . . . . . . . 159
6-20 Workflow: Generating an HTML presentation of a .wid document . . . 160
6-21 Workflow: Generating a PDF presentation of a .wid document . . . . . 160
6-22 Workflow: Refreshing a .wid document without prompts . . . . . . . . . . 161
6-23 Workflow: Refreshing a .wid document with prompts . . . . . . . . . . . . 162
6-24 Workflow: Importing and opening a .wqy document . . . . . . . . . . . . . 164
6-25 Workflow: Generating the HTML for a .wqy document (SDK) . . . . . . 165
6-26 Workflow: Generating the HTML for a .wqy document (tunneling) . . 166
6-27 Workflow: Refreshing a .wqy document without prompts . . . . . . . . . 167
6-28 Workflow: Refreshing a .wqy document with prompts . . . . . . . . . . . . 168
6-29 Save as a Corporate Document option . . . . . . . . . . . . . . . . . . . . . . . 169
6-30 Workflow: Saving a .wid document as a corporate document . . . . . . 170
6-31 Workflow: Saving a .wqy or .rep document as corporate document . 171
6-32 Save as a personal document option (to the portal) in InfoView . . . . 172
6-33 Workflow: Saving a .wid document as a personal document . . . . . . . 173
6-34 Workflow: Saving a personal document on the portal . . . . . . . . . . . . 174
6-35 Save as a personal document option (to local drive) in InfoView . . . 175
6-36 Workflow: Saving a .wid file to a local drive . . . . . . . . . . . . . . . . . . . . 176
6-37 Workflow: Saving a .rep or .wqy document to a local drive . . . . . . . . 177
6-38 Sending vs. saving a document to the repository . . . . . . . . . . . . . . . 178
6-39 A third-party document displayed in InfoView . . . . . . . . . . . . . . . . . . 179
6-40 Workflow: Displaying a third-party document . . . . . . . . . . . . . . . . . . . 181
6-41 Workflow: Adding a third-party file to the portal . . . . . . . . . . . . . . . . . 182
6-42 Workflow: Adding a third-party file to the portal . . . . . . . . . . . . . . . . . 183
6-43 Workflow: Sending third-party file, or saving as corporate document 184
Figures
10
6-44 Workflow: Scheduling a .wid file . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-45 Workflow: Scheduling a .wqy or .rep file . . . . . . . . . . . . . . . . . . . . . .
6-46 Scheduler settings in the Administration Console . . . . . . . . . . . . . . .
6-47 Workflow: How Broadcast Agent processes a .rep file . . . . . . . . . . .
6-48 Workflow: How Broadcast Agent processes a .wid file . . . . . . . . . . .
6-49 Workflow: How Broadcast Agent processes a .wqy file . . . . . . . . . .
Figures
187
188
189
191
193
195
preface
Maximizing Your Information

Resources
12
Overview
Information, services, and solutions
The Business Objects business intelligence solution is supported by thousands
of pages of documentation, available from the products, on the Internet, on CD,
and by extensive online help systems and multimedia.
Packed with in-depth technical information, business examples, and advice on
troubleshooting and best practices, this comprehensive documentation set
provides concrete solutions to your business problems.
Business Objects also offers a complete range of support and services to help
maximize the return on your business intelligence investment. See in the
following sections how Business Objects can help you plan for and successfully
meet your specific technical support, education, and consulting requirements.
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 16.
XDocumentation 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
XDocumentation 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.
XDocumentation 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
XBuy 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
XSearch the Documentation CD
Search across the entire documentation set on the Business Objects
Documentation CD shipped with our products. This CD brings together the full set
of documentation, plus tips, tricks, multimedia tutorials, and demo materials.
Order the Documentation CD online, from the Business Objects Documentation
Supply Store, or from your local sales office.
Information resources
13
14
XMultimedia
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.
XTips & 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
XProduct 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.
XDeveloper Suite Online
Developer Suite Online provides documentation, samples, and tips to those
customers with a valid maintenance agreement and a Developer Suite license
via the Online Customer Support (OCS) website.
Send us your feedback

Do you have a suggestion on how we can improve our documentation? Is there
something you particularly like or have found useful? Drop us a line, and we will
do our best to ensure that your suggestion is included in the next release of our
documentation: documentation@businessobjects.com
NOTE
If your issue concerns a Business Objects product and not the documentation,
please contact our Customer Support experts. For information about Customer
Support visit: www.businessobjects.com/services/support.htm
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
XOnline Customer Support
Our Customer Support website is open to all direct customers with a current
maintenance agreement, and provides the most up-to-date Business Objects
product and technical information. You can log, update, and track cases from this
site using the Business Objects Knowledge Base.
Having an issue with the product?

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

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

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

Address
Content
Business Objects Documentation
Overview of Business Objects documentation. Links

to Online Customer Support, Documentation Supply
Store, Documentation Roadmap, Tips & Tricks,
Documentation mailbox.
www.businessobjects.com/services/
documentation.htm
Business Objects Documentation

mailbox
Feedback or questions about documentation.
documentation@businessobjects.com
Product documentation
The latest Business Objects product

documentation, to download or view online.
support.htm
Business Objects product information Information about the full range of Business
Objects products.
www.businessobjects.com
Developer Suite Online
www.techsupport.businessobjects.com
Knowledge Base (KB)
Tips & Tricks

www.businessobjects.com/forms/
tipsandtricks_login.asp
Available to customers with a valid maintenance

agreement and a Developer Suite license via the
Online Customer Support (OCS) website. Provides
all the documentation, latest samples, kits and tips.
Technical articles, documents, case resolutions.
Also, use the Knowledge Exchange to learn what
challenges other users both customers and
employees face and what strategies they find to
address complex issues. From the Knowledge
Base, click the Knowledge Exchange link.
Practical business-focused examples.
Address
Content
Online Customer Support

Starting point for answering questions, resolving

issues.
www.businessobjects.com/services
Information about registering with Worldwide

Customer Support.
Business Objects Education Services
The range of Business Objects training options and

modules.
education.htm
Business Objects Consulting Services Information on how Business Objects can help
maximize your business intelligence investment.
consulting.htm
Useful addresses at a glance
17
18
About this guide

This guide describes in technical detail how the Business Objects system is
structured, and how it processes requests.
For more background information about the Business Objects system and how
to deploy it, see Deploying the Business Objects System.
Audience
This guide is intended for system administrators and IT professionals who need
to understand exactly how the Business Objects system works in order to
efficiently deploy or troubleshoot it.
Conventions used in this guide

The 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
BusinessObjects installation directory called
locData.
Windows and UNIX pathnames

For reasons of simplicity, if the same directory path is valid for both Windows and
UNIX platforms, the path is written in Windows notation.
This means, for example, that the following Windows path:
$INSTALLDIR\nodes\<Machine Name>\<Cluster Name>\temp
is equivalent to this UNIX path:
$INSTALLDIR/nodes/<Machine Name>/<Cluster Name>/temp
About this guide
19
20
chapter
Functional Basics
22
Overview
This guide includes dozens of detailed workflow diagrams illustrating how the
system processes most types of transactions, from login and startup to
administration and document processing. Before continuing, take the time to
read a short section called Understanding the workflows in this guide. It is your
key to getting the most out of these diagrams.
The 3-tier Business Objects system can be broken down into different layers:
The presentation layer, which includes a web server and the critical
application server
The processing layer, which includes the Business Objects functional
components required for processing user requests and creating and
displaying documents
a connectivity layer
an administration layer, which allows administrators to enable and disable
system components and administer the systems audit functions (page 42)
This chapter describes all these components and functions, as well as how the
system stores resources and uses caches to enhance performance.
Functional Basics
Understanding the workflows in this guide

The workflows in this guide are UML diagrams. In them:
the Business Objects systems components are represented by colored
rectangles or icons at the top of the diagram
system transactions are represented by horizontal arrows connecting one
component with another
Here is an example:
WIBean
WICOM
Browser
Portal
pages
BusObj
bolight
WIQT
Portal
WIAPIBroker
User asks to view a

document from a document list
RequestDocId
OpenDoc(DocId)
Repository
WIStorageManager
BOManager
ImportDoc(DocId)
(SessionFolder)
IsDocInCache
(DocId)
Red italic text
NotInCache
ImportDoc(DocId)
(SessionFolder)
Figure 1-1 Understanding workflow diagrams in this part of the guide
23
24
Identifying components with architecture layers

To make it easier to visualize how the system communicates, the components
represented by rectangles in these workflows have been color-coded to indicate
the layer of the 3-tier architecture to which they belong:
A component of this color...
Belongs to this architecture layer...

Client layer
For example, the BusinessObjects
product
Presentation layer
For example, ASP/JSP pages on the
application server, or HSAL/JHSAL on
the web server
Processing layer
For example, WIQT or BOManager
Application services layer
For example, WIStorageManager
Other visual conventions

This convention...
Indicates...
Commentary
A transaction label which applies to
the entire blue-shaded area of the
diagram
Breaking up long workflows

Where workflows are too long, they are broken up into broad phases. In these
cases, the position of each smaller segment within the larger workflow is
indicated (for example, with a 2/3, meaning the second out of three steps).
Functional Basics
Checking the cache

Many of the workflows in this guide require checking the cache for a particular
document presentation or list. If a required presentation is not in the cache, the
system retrieves it from the repository, then stores a copy in the cache.
For simplicitys sake, all these workflows illustrate the scenario in which the
cache does not contain the required document or presentation.
25
26
The presentation layer

The presentation layer of the Business Objects 3-tier system generates the
HTML and DHTML pages users see in InfoView.
This layer communicates with the systems processing layer through interface
components that expose processing APIs to the systems dynamic Active Server
Pages (ASP) and JavaServer Pages (JSP) pages.
The role of the web server

The system no longer uses the web server as the main channel for receiving and
servicing client requests.
Now the web server hosts static web pages only, and represents a link in the
communication between the client and the Business Objects cluster(s). It is the
means by which users access WebIntelligence and the InfoView portal through
the web.
The role of the application server

In previous releases, the application server was necessary for use with custom
applications only. This release of the 3-tier Business Objects system, however,
requires an application server in order to process the systems dynamic pages.
The application server hosts three critical components in the clients
communication with the system:
Dynamic server pages (see page 28)
The API components allowing the functions coded in the dynamic pages to
link to the systems processing layer (see page 28)
Web components allowing various servlets and plug-ins to connect to the
systems processing layer (see page 29)
Servlets are Java-based applications that run on the application server,
responding to HTTP requests with HTTP responses. Web server plug-ins are
C++ applications that run on the web server to extend its possibilities.
Functional Basics
InfoView/
WebIntelligence
client
Plug-ins installed in
the web browser on the
client
ASP/JSP dynamic pages
Application server
API components
Web components
WebIntelligence servlet
HSAL/JHSAL
ISAPI
WICOM/RECOM
Wibean/Rebean
Business Objects
processing layer
Cluster
Figure 1-2 Three main application server components
XASP 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
27
28
Each of these configurations is described in more detail later on in this chapter.

See:
IIS, or ASP, configurations on page 29
J2EE, or JSP, configurations on page 31
XThe role of ASP and JSP pages
Viewed through the web browser on the client, the systems ASP and JSP pages
generate InfoView and WebIntelligence HTML and DHTML pages with dynamic
content. Both types of page allow embedding programming logic in HTML pages,
then executing that logic at the server level when a client accesses a page. ASP
programs are typically written in VBScript and JavaScript, while JSPs support
code written in Java.
ASP/JSP pages use WICOM/WIBean components installed inside the
application server to access WIAPIBroker functions and make the link between
application server pages and the clusters processing layer.
These pages provide WIAPIBroker with data and generate the HTML pages
which appear in users browsers.
XAPI components hosted by the application server
The API components WICOM and WIBean extend the application server by
exposing Business Objects cluster functions at the application server level.
Although these functions can be called from ASP and JSP pages, they are
executed by the Business Objects processing layer.
Functional Basics
XWeb components hosted by the application server

The application server hosts these web applications:
The new WebIntelligence servlet or WebIntelligence ISAPI
The HSAL/JHSAL and exterior ISAPI used by lightweight client components
communicate with the cluster using the web protocol:
- The HSAL/JHSAL acts as a proxy, translating HTTP requests coming from
the client into CORBA calls which it then sends to WIDispatcher. HSAL/
JHSAL implements no intelligence and has no functional role other than
protocol conversion.
- The WebIntelligence servlet or WebIntelligence ISAPI extensions transform
HTTP dialogs coming from the WebIntelligence Java Report Panel into
CORBA calls. It then sends these calls on to WIReportServer. It also can be
considered a proxy because it has no functional role other than protocol
translation.
IIS, or ASP, configurations

In Business Objects solutions, IIS acts as both a web server and an application
server because it can host both static pages and dynamic pages, invoking
dynamic objects executed on the server side.
This section provides a detailed description of what the IIS server hosts.
29
30
XWhat an IIS server hosts

Web browser
Client layer
WebIntelligence
Java editor
3-tier BusObj/
ActiveX viewer
InfoView
pages
InfoView
ASP pages
Presentation
layer (IIS
web/application
server)
Processing
layer
WebIntelligence InfoView
WebIntelligence
ISAPI
ReCOM
WICOM
WIReportServer
WIAPIBroker
HSAL
WIDispatcher
Processing layer functions
Figure 1-3 What an IIS server hosts
Functional Basics
An IIS server in the Business Objects system hosts:

Web server plug-ins
The WebIntelligence 6.x ISAPI extension and HSAL are installed as web
server plug-ins. They are invoked by any request for a URL located in the web
server virtual directories they are installed in. They receive incoming HTTP
requests and generate HTTP responses.
Dynamic pages
WebIntelligence and Infoview ASP pages are installed in the web server file
tree.
COM components
WICOM and RECOM are installed as Windows COM shared objects.
Whereas CORBA objects can be used by any program, even on remote
machines, COM objects are exposed through the Windows registry and can
be used only by programs running on the same Windows machine.
WICOM and RECOM act as proxies for, respectively, WIAPIBroker and
WIReportServer, the WebIntelligence 6.x report engine.
Static files (static HTML web pages and bitmaps) are also stored on the Web
Server tree and displayed when their URL is invoked.
J2EE, or JSP, configurations

In J2EE Business Objects configurations, the web and application servers are
separate, even if they run on the same machine.
The web server is an HTTP server which hosts static files, static HTML pages
and bitmaps. Depending on the URL of the HTTP request coming from the client,
it is configured to do one of the following:
send an HTTP response containing a file present on the file system
forward the HTTP request to the application server
The application server is made of two layers:
A presentation layer, built around servlets or JSP pages
A business layer is able to process the application business logic through
JavaBean components.
Because in Business Objects the actual processing is handled within the cluster,
this layer is reduced to API components only.
31
32
XWhat the application server hosts

Web browser
Client layer
WebIntelligence
Java editor
Presentation
layer (J2EE
application
server + a
web server)
Processing
layer
WebIntelligence
servlet
WebIntelligence
HTML editor
InfoView
pages
WebIntelligence
JSP pages
InfoView
JSP pages
ReBean
WIBean
WIReportServer
WIAPIBroker
3-tier BusObj/
ActiveX viewer
JHSAL
WIDispatcher
Processing layer functions
Figure 1-4 What a J2EE application server hosts
Functional Basics
The application server hosts:

JSP pages:
- InfoView JSP pages, which generate the HTML pages users view in the
InfoView portal
- WebIntelligence JSP pages, which generate the WebIntelligence DHTML
client used for creating and editing WebIntelligence 6.x documents
the WIBean and ReBean API components, which expose WIAPIBroker and
WIReportServer functions at the application server level and enable the JSP
pages to call these functions
web components:
- JHSAL, which like HSAL is a proxy which forwards HTTP requests from the
client to WIDispatcher using the CORBA protocol
- the WebIntelligence servlet, which like the WebIntelligence ISAPI acts as a
proxy between the HTTP communication used by the WebIntelligence Java
Report Panel and WIReportServer, which must be called using the CORBA
IOP protocol.
33
34
The processing layer

The systems processing layer includes both the components that allow the
creation and publication of documents and the processing of user requests, and
the application services components which provide the essential framework and
services to the processing layer.
Functional Basics
Business Objects processing components

The Business Objects 3-tier system includes many of the same system
components in previous versions of the Business Objects system. They include:
Component
Description
WIDispatcher
Used in 3-tier deployments of BusinessObjects and for

displaying WebIntelligence 2.x documents, the
WIDispatcher receives a translated request from the HSAL/
JHSAL and decides which process the request should be
sent to.
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 documents, where one session is launched
per user.
WIReportServer
Report engine that processes WebIntelligence 6.x

documents.
WIQT
This process has several functions, each of which has been

given its own name:
It handles all document exchange with the repository and
the system caches. This set of functions is known as
WIQT Repository Access.
It serves as a report engine for processing
WebIntelligence 2.x documents and manages the
processing of BusinessObjects documents via
BOManager. This is called WIQT Report Engine.
It serves as an SQLBO proxy for BusinessObjects in 3tier mode, running SQL requests sent by the HTTP
protocol. This is called WIQT SQLBO.
In the 3-tier system, a single WIQT process handles
processing for a single InfoView or BusinessObjects user
session; each user session therefore has its own dedicated
WIQT.
35
36
Component
Description
Scheduler
Working with Broadcast Agent, the Scheduler periodically

polls the repository to detect tasks to run. It then
communicates with BOManager (for BusinessObjects
documents) and invokes a WIQT or the WIReport Server for
document processing.
WIADEServer
Provides the server interface for calls from the InfoView

ActiveX viewer and BusinessObjects in 3-tier mode. It
receives calls from the client via WIDispatcher, which are
then passed to
BOManager to process full client documents for ActiveX
viewer
WIQT to process document exchange and SQL orders
WIAPIBroker
Used at the application server level, acts as the interface

between the client and the business processing (middle tier)
layer. It acts as the gateway for InfoView and
WebIntelligence 2.x document processing, called each time
an ASP/JSP page invokes the WICOM/WIBean component.
WIAPIBroker interacts with:
WISessionManager for session creation
WIQT for document and list processing
WIStorageManager for cache data
Functional Basics
BusinessObjects
processes
Acting as report engines for BusinessObjects documents,

these processes are called BusObj.exe in Windows and
bolight in UNIX.
WIQT_batch
A WIQT that permits batch WebIntelligence 2.x document

processing by Broadcast Agent.
BOL_batch
A UNIX process used for batch processing with Broadcast

Agent.
WIReport
Server_batch
A report engine for processing InfoView documents in

Broadcast Agent.
Application services components

Application services components include the following processes:
Component
Description
Connection Server A connectivity layer used to control execution of SQL

requests. It is used by WebIntelligence and WILoginServer.
WILoginServer
Speeds login process by providing a cache for repository

security. Works with Connection Server.
Audit Server
Writes records of 3-tier user activity for Auditor and into the
Audit database.
WISessionManager
Creates and manages InfoView user sessions. With

BusinessObjects Enterprise version 6.1, this process is part
of the session stack, and therefore is enabled on each node
in the cluster.
WIStorageManager
Manages the systems cache and personal document

storage areas. Business Objects systems must have at least
one, but may have several WIStorageManagers.
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.
37
38
Session stacks
In past versions of Business Objects, the processing of client requests in the
same InfoView user session could be distributed over several machines in the
cluster, using the CORBA communication protocol.
With BusinessObjects Enterprise 6.1, this processing is speeded up by having all
of the requests for a single user session processed by modules on the same
cluster node. These modules include:
WISessionManager
This breaks with previous enablement rules, in which only one
WISessionManager could be enabled per cluster.
WIAPIBroker
WIQT (there is a pool of these processes)
WIReportServer
WIDispatcher
WIADEServer
BOManager (and its pool of BusObj/bolight processes)
This set of modules is called the session stack. Administrators start or stop all
these modules on the node at the same time, simply by clicking a single Disable/
Enable button in the Administration Console.
Figure 1-5 Disabling/enabling session stacks in the Administration Console
Functional Basics
If the session stack is not enabled on a node, the node cannot process user
requests.
The following Business Objects modules do not belong to a nodes session stack,
and therefore can be started and stopped individually:
WILoginServer
WIStorageManager
Broadcast Agent Manager
Administration Server
WIOLAPGenerator
39
40
The Console interface

The Administration Console looks like this:
Figure 1-6 The Administration Console
Functional Basics
Communication protocols between system

components
The type of communication used to process requests in the Business Objects
system depends upon the components doing the communicating, and the
architectural layer to which they belong.
The following diagram illustrates this:
Client layer
HTTP
Presentation layer
HTTP
ASP/JSP pages
Java/COM
WICOM/WIBean
RECOM/REBean
HTTP
Processing layer
CORBA
CORBA
SQL
SQL
Repository
Database
Figure 1-7 Communication protocols used in the system
NOTE
Occ
Occasionally, calls between certain components in the processing layer can be

in C++.
Communication protocols between system components
41
42
How system administration works

Once the 3-tier solution is set up, with the repository created and stocked with
universes and users security information, the Administration Console represents
the control panel for the systems administration.
The Administration Console allows administrators to manage:
clusters, by stopping and starting them and by changing their parameters
modules, by stopping and starting them and by changing their parameters
Broadcast Agent, by stopping and starting it and by changing its parameters
the Audit facility, by initializing or migrating audit tables in a database and by
stopping and starting it and changing its parameters
sessions, by ending InfoView user sessions
This section describes how the system processes various administrator
workflows.
How administrators log into the Administration Console

With this version, both access to the Administration Console and what
administrators can do with the Console are more rigorously controlled, due to the
new WILoginServer module.
Administrators log in from an applet in a web browser or through a standalone
Windows application:
Figure 1-8 Login dialog box for the Administration Console
Functional Basics
When they click the Login button, this is what happens:

Administration
Console applet
Administration
servlet/ISAPI
WIProcessManager
WILoginServer
WILoginServer cache Repository
Login HTTP
Login CORBA
login (ProductId,UserName,
LsiFilePath,Password)
AuthenticateUser in OBJ M ACTOR table
Get user instances,

groups and pre-calculated group security
attributes
Aggregate users security
attritubutes
Compute .lsi
file content
Return login result
(OK or error) and
a BLOB containing
.lsi file
Write .lsi file to
temporary directory
Check that user has
Administrative privileges
OK
Display Administration Console
Figure 1-9 Workflow: Administration Console login
43
44
When administrators log in, the Administration Console authenticates

administrators through WILoginServer, which checks information stored in the
repository to process the authentication. A .key file located in the $LOCDATA
directory is required for WILoginServer to operate, as it defines where the
repositorys security domain is located. If the username and password entered
match those stored in the file, and the user has the required rights as defined in
Supervisor, the user is allowed access to the Administration Console.
WILoginServers transactions with the Administration Console are in CORBA
mode. If WILoginServer is not started before login, the user cannot access the
Console.
How the Administration Console administers the cluster

The Administration Console allows administrators to change settings for a
module, usually through a generic mechanism.
Broadcast Agent works slightly differently from other modules in the
Administration Console. For more information on managing Broadcast Agent,
consult the Broadcast Agent Administrators Guide.
The Administration Console itself does not read and write the modules
parameters. Each module implements an interface for the Administration
Console, through which the Console sets and retrieves parameter information.
Each module reads its parameters and sends them to the Administration Console
for display. If an administrator changes a parameter, the Administration Console
sends it to the module, which saves the change.
Functional Basics
Windows application
Java applet in a
web browser
Administration
ISAPI extension
Primary node
Administration
servlet
WIProcessManager
Admin. Console
interface
Node configuration
file, Localnode.xml
Server process
Servers private
configuration
file
Secondary node
WIProcessManager
Admin. Console
interface
Node configuration
file, Localnode.xml
Server process
Servers private
configuration
file
Figure 1-10 How the Administration Console administers clusters
45
46
Administration Server is the server component of the Business Objects
Administration SDK. Used to administer users through the SDKs Java
technology, Administration Server provides a subset of the features available in
Supervisor, including the management of users and group, including changing
passwords and enabling password modification.
Only a user with a general supervisor or supervisor profile can administer users
through Administration Server.
Administration Server remains active as long as a client session is open. When
the last session is closed, an internal Administration Server timeout begins.
Administrators can change this setting, known as Inactivity timeout, in the
Administration Console. The default value is 3600 seconds:
Figure 1-11 Inactivity timeout for Administration Server
Functional Basics
XAdministration Server session startup

Administration Server does not use WISessionManager to manage its client user
session. Its user sessions cannot therefore be viewed in the Administration Console.
Heres how it works:
Administration
Server
WISessionManager
GetProperty (authentication method)
WILoginServer
Initialize session
environment
Return (authentication method)
Login (username, password, method)
Return user_id and .lsi file as a BLOB
Authenticate
against repository
Compute .lsi file
from cache
WILoginServer proxy writes

the .lsi file
It then reads and uses the
.lsi file to check user
permissions
Figure 1-12 Workflow: How an Administration Server session is authenticated
Administration Server is activated at the first client request from the

Administration SDK. This means that a com.bo.adminbean.Server object is
launched in JSP script from the Administration SDK. Administration Server then
retrieves the authentication method from WISessionManager, then passes it on
to WILoginServer, requesting authentication. This parameter is retrieved each
time a new session is opened. Any change to the authentication method is
therefore taken into account dynamically.
The session actually starts when the adminbean method Server.openSession is
called successfully (the user is authenticated as supervisor or a general
supervisor).
When the session is opened, Administration Server reads the Administration
security commands that have been applied to the administrator (using
Supervisor) and calculates administrator management scope.
47
48
XAdministration Server session termination

Sessions are terminated in either of the following situations:
when the adminbean method Session.close is called successfully
When no client request associated with a specific session has been received
during a timeout period. You can set the Administration Servers client
session timeout parameter using the Administration Console.
Whenever a session ends, any hanging sessions must be purged by the
system. You can determine how often this is done by setting the
Administration Servers Clean up period parameter in the Administration
Console.
Figure 1-13 Administration Server parameters in the Administration Console
XWhen multiple administrators use Administration Server

Several administrators can work on the Administration Server concurrently; all of
their input is centralized in the repositorys security domain.
For more information on the Administration Server, see the Customizing
Administration Guide.
Functional Basics
How the system creates audit logs

Most modules record events about Business Objects activity that an
administrator can later analyze using the Audit facility or Auditor.
Using the Administration Console, administrators can:
create audit or migrate audit tables
activate or deactivate server audit logs
determine whether to save logs in files or in a database
Each component sends the events and details of each user action to the Audit
Server, which logs events and details in a log file or database.
For more information about the Audit facility, see the System Administrators
Guides.
Audit Server
Audit Server writes records of user activity in 3-tier applications into the Audit
database or a flat log file, which are saved to a directory of your choice. These text
files can be viewed in the Administration Console or in a simple text editor, such as
Notepad.
In database mode, the system stores the user or system information to the Audit
database. Because of its complexity, information in Database mode is normally
viewed and analyzed via the use of indicators in Auditor. However, this can also
be performed in SQL if no other solution is available.
How the system creates audit logs
49
50
System storage
The 3-tier Business Objects system stores the following resources:
documents, such as Business Objects reports or third-party files from other
applications
report data generated in viewable and printable formats, such as HTML, PDF
or CSV files
universes
connections to enterprise databases
Where the system stores resources

The system stores resources in one or more of several locations:
in the repository
in temporary session folders
in users personal folders
in cluster storage
Shared
drive
Primary node running
WIStorageManager
Temporary storage
Temporary storage
User settings
Personal documents
Read Inbox documents
System caches
Cluster
Repository
Security data
Shared documents
Unread Inbox documents
Universes
Secondary node
Temporary storage
Secondary node
Temporary storage
2-tier workstation
Personal BusinessObjects
documents
Figure 1-14 Where the system stores resources
Functional Basics
Repository storage
Users share resources stored in the repository. User and group access
permissions provide security for those resources. The repository contains:
corporate documents, which are stored in the repository but cached in cluster
storage
unread documents from a users Inbox
resources, such as universes and reports
security data, such as lists of users and groups, and user and group
permissions to use applications and resources
Temporary session storage

Each node in the cluster uses temporary files for storing:
session data
documents while they are being edited or processed by a report engine
Broadcast Agent temporary data
The system stores these temporary files in a local directory on the cluster node
handling the InfoView processing session while report engines are processing
documents. The $INSTALLDIR\nodes\<MachineName>\<ClusterName>\temp
directory contains the following subdirectories:
Directory name
Description
sessions
caches InfoView session data and document status
cache
used for Broadcast Agent storage
bomanager
contains BusinessObjects documents that the

system is processing
Users personal folders

The system stores personal documents for InfoView users in each users private
folder, located in:
$INSTALLDIR\nodes\<MachineName>\<ClusterName>\storage\
Report engines like WIQT, WebIntelligence and 3-tier deployments of
BusinessObjects can all access this storage area.
For 2-tier deployments of BusinessObjects, however, only files stored on the
users local workstation can be retrieved.
System storage
51
52
Cluster storage
Cluster storage relies on a directory shared through WIStorageManager. The
WIStorageManager server, often running on the primary node, shares this
directory, $INSTALLDIR\nodes\<Machine Name>\<Cluster Name>\storage, with
the entire system. This directory can be a private directory located on the primary
node or a shared directory placed on a file server and shared between several
clusters.
Cluster storage contains:
users personal documents and attributes
read documents from users InfoView Inboxes
caches for corporate documents and system data
XPersonal document storage
The system stores personal documents in the users folder in the clusters
storage. The user folder includes one subdirectory per user, which contains:
the users settings stored in the profile.txt file
the catalog of personal documents stored in the Attribut.txt file
personal document categories
Each personal category has a file named <Category Name>.ctg, which
contains a list of documents contained in the category.
XInbox document storage
The repository stores unread Inbox documents. The mail subdirectory in cluster
storage stores inbox documents that have been read using InfoView. This folder
contains the subdirectory <user name> per user. The subdirectory includes:
a text file, read.txt, which contains a catalog of all read documents from a
users inbox
all read documents themselves, with each document stored in a separate file
The filename used for storing documents in the mail folder is a string containing
the document domain, the sender, an incremental number, the document name,
and the InfoView document type. This combination enables a user to receive
several versions of the same document created on different dates.
Functional Basics
XCorporate document cache

The corporate document cache contains different directories and mechanisms
for caching WebIntelligence and BusinessObjects documents, extracted from the
repository.
To prevent potential overloads at peak transaction periods, you can pre-load the
cache whenever BusinessObjects users schedule a corporate document with
Broadcast Agent. This automatically generates the document in enhanced
document, standard HTML, or Adobe Acrobat PDF format, then stores it in the
server cache. These formats correspond to three options for viewing
BusinessObjects documents within InfoView.
The first time a InfoView user asks to view the document in a certain format,
BOManager retrieves the presentation and stores it in a cache on a machine
controlled by the systems WIStorageManager. When other users subsequently
access the document in InfoView, the system immediately retrieves a pregenerated file from the cache instead of having BOManager regenerate the file
all over again.
This means that:
Each InfoView request for a BusinessObjects document doesnt require
logging into BOManager.
There are fewer demands on available processes in your cluster.
The documents presentation doesnt have to be generated the document
is displayed faster, and has used fewer system resources.
The response time remains constant and doesnt depend on the documents
size or complexity.
CPU power and BusinessObjects processes are therefore made available for
refreshing documents (ad-hoc queries).
The cache purges itself at regular intervals if it meets a size limit or is not used
for a specified amount of time. Administrators can define size and usage-time
limits by changing settings in the Administration Console.
WebIntelligence documents
The docs directory in system storage's caches all WebIntelligence corporate
documents in InfoView. The docs folder is organized by document domains.
When the user opens a corporate document using InfoView, if the document is
not already cached, the application downloads the document to the cache folder
(docs\<Document Domain Name>) as a file named: <Document
Name>.<Document Type>.
System storage
53
54
When the user modifies or refreshes a corporate document, a local copy of the
document appears in the temporary user session directory. The user can then
modify only the local copy of the document.
When the user saves the same document to the repository again, InfoView writes
the document directly into the repository. InfoView also makes a local copy in the
temporary user session directory, and updates the users corporate documents
list to contain the new date.
BusinessObjects documents
When users request a refresh of a BusinessObjects document, the
BusinessObjects report engine generates a PDF, HTML, or .rep file view of the
document.
Business Objects stores the view in the
<document domain>\<Document name>.<document type>_
directory.
Functional Basics
XInfoView portal list cache

In InfoView, users can see lists of the documents and universes they can access.
The InfoView list cache includes:
List
Description
Universes
The list of universes is stored in the file: list\<user

name>\unv.txt.
Corporate Documents
The Corporate Documents, Corporate Categories

and Document Categories lists are stored in the file:
user\<user name>\BOMain.lsi. This file is updated:
when the user logs in and a WIQT invokes
WILoginServer. WILoginServer repository cache
then generates the file.
when the user clicks the Refresh List button for a
corporate document in InfoView. The WIQT then
re-calculates the list of documents from the
repository.
when the user saves a document to the
repository, the WIQT adds the document to the
.lsi file.
Corporate Categories
Document Categories
Inbox Documents
This list of read and unread documents from a users

Inbox is stored in the file list/<user name>/Mail.txt
and is updated:
when the user reads an unread document from
the repository
from the repository when the user clicks the
Refresh List button in InfoView
by deleting an element when the user deletes a
document
XUsers personal data cache

The user folder contains one subdirectory called <user name> per user, which
contains a users settings stored in the profile.txt file.
Login caches
Security information is cached in the .lsi file for the sessions lifetime. This file is
created in the sessions temporary directory when the user authenticates, and is
used for caching all security data concerning access rights.
System storage
55
56
Functional Basics
chapter
58
Overview
The Business Objects system startup mechanism:
sets the environment
starts the CORBA communication layer
starts the Business Objects server
starts the web server (if installed on the Windows node and configured for
autostart)
starts the application server and all dependent web applications (if installed
on the server youre starting and configured for autostart)
This startup mechanism is nearly identical on Windows and UNIX servers:
The Windows webi.bat file is equivalent to the webi.sh file under UNIX.
Under Windows, you call webi.bat from WINotify; under UNIX, you call
webi.sh from wstop or wstart.
You must start up each machine in a Business Objects cluster separately, either
from the command line or using the user interface.
For a cluster composed of several nodes, you must start the primary nodes
before the secondary nodes and clients. You can schedule the startup on the
various machines either manually or with an external product (such as a script
using a remote shell on UNIX, or Tivoli Workload Scheduler).
The installation directory

Most of the files discussed in this chapter are located in $INSTALLDIR, the root
installation directory. Its default values are:
Windows: C:\Program Files\Business Objects\BusinessObjects Enterprise 6
UNIX: /opt/BOBJ/Enterprise6
More specifically, important cluster-related files are located in
$INSTALLDIR\nodes\<NodeName>\<ClusterName>. The Configuration Tool
creates this directorys subdirectories when the node is configured.
NOTE
The Configuration Tool configures the different components of the Business

Objects system; for example, it executes the ASF configuration script for each
cluster.
The $INSTALLDIR\nodes\<NodeName>\<ClusterName> directory contains

information that is important for the functioning of the cluster. It stores:
configuration files
user documents
cluster log files
key files
session information
templates
universes
59
60
How the system starts under Windows

You can start the system in any of the following ways:
Using the WINotify icon in the status bar of your Windows desktop
Using the Windows Start menu
During the boot phase of the system
All of these methods call the webi.bat file.
ASF and the webi.bat script

All the machines in the cluster communicate by means of the ASF (Application
Server Framework). The ASF is an inter-node communication layer, based on
the CORBA Orbix ORB, that enables query and reporting functions.
When invoked with the start parameter, the webi.bat script:
sets the environment for the ASF
launches the web server, if the start sequence of the web server is manually
uncommented
launches the application server, if the start sequence of the application server
is manually uncommented
starts the ASF then WIProcessManager, which in turn starts the components
defined in the localnode.xml file (located in
$INSTALLDIR\nodes\<NodeName>\<ClusterName>\config\servers)
The localnode.xml file describes the processes to be started on a given node.
You can modify the settings in this file using the Administration Console.
Windows startup workflow

WINotify icon
Windows
Start menu
Boot
$INSTALLDIR\...\
<cluster>\webi.bat
System
environment
variables
System
registry key
Setenv_asf
<clustername>
Start_orbix
Start_asf
Start_ASF
Start web
server
Start application
server
Start_
WIProcess
Manager
$INSTALLDIR\...\
<cluster>\localnode.xml
containing the
description of the
functional servers
Start
Business Objects
server
Figure 2-1 System startup under Windows
How the system starts under Windows
61
62
How the system starts under UNIX

The node is started by the $INSTALLDIR/SetUp/wstart script.
Who can launch wstart

The wstart script can be launched by either:
the root, which can start any cluster
a normal user, who can start only the cluster that this user has installed
The script can be launched with or without arguments. The arguments contain
the list of clusters to start. If they are not used, all enabled clusters are launched.
Heres more detailed information:
Root
With
arguments
Without
arguments
Normal user
wstart:
reads all installed clusters from
clusterlist.dat
launches all clusters in the file
for which clustername is
passed as an argument
wstart:
clusterlist.dat
launches all clusters in the file for
which clustername is passed as an
argument
Clusters are launched by issuing

the webi.sh start command
under the user specified in the
username column of the
clusterlist.dat file.
Clusters are launched by issuing the

webi.sh start command if the
username matches the user who installed
the cluster.
wstart:
clusterlist.dat
launches all enabled clusters in
the file
wstart:
clusterlist.dat
launches all enabled clusters in the file
Clusters are launched by issuing

the webi.sh start command
under the user specified in the
username column of the
clusterlist.dat file.
Clusters are launched by issuing the

the cluster.
How wstart is launched

wstart (and wstop) are launched by one of the following:
manually, directly from the command line
during the UNIX boot, by a S99WebIntelligence_<cluster name>
script
The script is created in $INSTALLDIR/nodes/<node name>/<cluster
name> by the Configuration Tool. A link to this script has been created
manually in /etc/rc0.d, /etc/rc2.d, and /etc/rc3.d.
The following diagram illustrates how several clusters are started with wstart:
For each enabled cluster

(clustername, username)
in clusterlist.dat
Launch the cluster-specific start

script webi.sh as username
If root
If normal user
wstart
(command line)
For each enabled cluster

(clustername,username)
in clusterlist.dat having
username=current user
Launch cluster-specific
start script webi.sh
Figure 2-2 How wstart starts multiple clusters under UNIX
What the webi.sh script does

When invoked with the start parameter, the webi.sh script:
sets the environment:
- for Business Objects components and the web and application servers, by
executing the WebiEnv.sh and MyWebiEnv.sh scripts
- for the ASF, by calling setenv_asf.cmd<clustername>
tests whether the cluster is started or starting by issuing an itadmin
command.
It then exits if the cluster is already started or starting.
starts the ASF by calling the start_asf.cmd
launches the web server if its start sequence was manually uncommented
launches the application server if its start sequence was manually
uncommented
How the system starts under UNIX
63
64
The following diagram illustrates the process that is set in motion by the
webi.sh script:
Node env file
WebiEnv.sh
$INSTALLDIR/.../
<cluster>/webi.bat
Cluster env file

MyWebiEnv.sh
Setenv_asf
<clustername>
Start_orbix
Start_asf
Start_ASF
Start web
server
Start_
WIProcess
Manager
Start application
server
$INSTALLDIR/nodes/
<host>/<cluster>/
config/localnode.xml
containing the
description of the
functional servers
Start
Business Objects
server
Figure 2-3 What the webi.sh script does under UNIX
What the start_asf.cmd script does

The start_asf.cmd script starts:
Orbix (the systems CORBA ORB)
the ASF
The ASF starts the Business Objects components defined in the
localnode.xml file.
WIProcessManager
WIProcessManager is the ASF daemon which actually manages the Business
Objects systems process lifecycle.
WIProcessManager:
manages cluster activity (active/inactive nodes, previously handled by
WIClusterNode/WIClusterManager)
starts and stops Business Objects processes and monitors their activity by
restarting them if they fail
handles load balancing (previously handled by WIGenerator and restricted to
WIQT, now extended to all processes through the whole nodes Node Weight
parameter)
manages all Administration Console workflows (previously routed through
WIClusterNode/WIClusterManager)
creates and manages the WIQT process pool. This pool contains a set of
preregistered WIQT processes, which are allocated to a unique WIQT
session.
Whenever an InfoView session is created, a WIQT process is reserved in the
pool and declared in the ORB. When the WIQT process terminates, the
context is released, put back into the pool, and reallocated to another
process.
WIProcessManager
65
66
The number of processes in the WIQT pool is indicated in the localnode.xml

file. You can modify this number in the Administration Console:
Figure 2-4 Setting the number of WIQT processes in the Administration Console
WIProcessManager also manages bolight registration/activation/shutdown

under UNIX.
Shutdown
The shutdown mechanism stops the components in the reverse order of startup.
It:
1. stops the application server and all dependent web applications
2. stops the web server
3. stops the ASF communication layer
4. unsets the environment
There is one shutdown mechanism per machine, which can be called either by
the command line or from the user interface.
Under Windows
WIProcessManager manages the stopping of the node, launching the script
contained in the webi.bat stop file. This file contains the script used to stop the
cluster.
Under UNIX
All UNIX nodes are shut down through the wstop command. You can also use
wstop-sos to force the termination of all remaining processes.
XWho can launch wstop
The wstop script can be launched by either:
root, which can stop any cluster
a normal user, which can stop only the cluster that this user has installed
The script can be launched with or without arguments. The arguments contain
the list of clusters to stop. If they are not used, all enabled clusters are stopped.
Shutdown
67
68
The following table provides further information:

Root
With
arguments
Without
arguments
Normal user
wstop:
clusterlist.dat
stops all clusters in the file for
which clustername is passed
as an argument
wstop:
clusterlist.dat
stops all clusters in the file for which
clustername is passed as an
argument
Clusters are stopped by issuing the

webi.sh stop command under
the user specified in the username
column of the clusterlist.dat
file.

the cluster.
wstop:
clusterlist.dat
stops all enabled clusters in the
file
wstop:
clusterlist.dat
stops all enabled clusters in the file

Clusters are stopped by issuing the webi.sh start command if the
webi.sh stop command under
the user specified in the username the cluster.
column of the clusterlist.dat
file.
XWhat the webi.sh script does
When invoked with the stop parameter, the webi.sh script:
unsets the environment
- for Business Objects components and the web and application servers, by
executing the WebiEnv.sh and MyWebiEnv.sh scripts
- for the ASF, by calling setenv_asf.cmd<cluster name>
tests whether the cluster is stopped, by issuing an itadmin command
It exits if the cluster is already stopped.
stops the ASF and all Business Objects functional daemons
chapter
70
Overview
In the Business Objects system, each session represents a user who has logged
in. The session stores user information such as preferences and security profiles,
as well as temporary information needed to process documents.
Sessions are used to:
authenticate InfoView users
enable other components to access user and security information when
processing user requests
track and record user actions
enable administrators to manage user access to the system
The login process therefore is the genesis of each user session. With
BusinessObjects Enterprise 6.1, this process is initiated by the
WISessionManager in the session stack on the node used for all the processing
required during the user session. The login is then managed by an ASF
component called WILoginServer which speeds up and optimizes the login
process.
This chapter describes how WILoginServer works, what happens during the login
process, and how the system manages sessions:
What are sessions?
Authentication and authorization
How WILoginServer works
How the system handles different authentication methods
Session management
Starting InfoView user sessions
3-tier BusinessObjects user sessions
WebIntelligence 6.x document sessions
What are sessions?

A session is a series of interactions that occur during the span of a single
connection. In Business Objects, user sessions begin when a user logs in and
end when the user logs out or remains inactive for more than a set timeout
duration. Sessions can also be terminated by the administrator or by a problem
causing the entire system or server to fail.
In a standard HTTP transaction, the browser requests a web page from the web
server. The web server responds to the request, and then forgets the browser.
Information about the request exists only for the duration of a single request/
response interaction.
With sessions, the web server retains the session ID by means of a header
cookie, an additional line of information entered in the pages HTTP header.
Types of sessions
In Business Objects, there are three types of sessions:
InfoView user sessions
3-tier BusinessObjects sessions
sessions used by Broadcast Agent for the processing of scheduled tasks
What are sessions?
71
72
A session is therefore created when one of the following occurs:
BusinessObjects
login in 3-tier mode
InfoView login
Session creation
Broadcast
Agent
Figure 3-1 Sessions in Business Objects
a user clicks the Login button on the InfoView Login page

a user logs into a 3-tier deployment of BusinessObjects
Broadcast Agent schedules a request in batch mode
A session remains active until one of the following occurs:

the user logs out
the use has remained inactive until a predefined timeout is reached
an administrator terminates the users session
the entire system is shut down

The login process which initiates Business Objects sessions involves both:
authentication, through which a user is identified, usually based on a
username and password
authorization, which is the process of giving individuals access to system
resources based on their identity
With BusinessObjects Enterprise 6, the authentication/authorization process has
been speeded up for InfoView, BusinessObjects (3-tier) and the Administration
Console users through the use of a module called WILoginServer.
At system startup, WILoginServer connects to the repository, calculates the
security attributes for all the users and groups in the security domain, then stores
this information in a login cache on the server.
As each user subsequently logs in, the server only needs to connect to the
repository to check the users credentials. The system can then use the local
login cache to generate a file containing the users authorization information. This
is called the .lsi file.
Because of the login cache and the .lsi file generated from its contents, the
system no longer needs to access the repository again to calculate the
authenticated users privileges.
NOTE
The only exception to this is when the Enable real-time user rights update option
is set for a user in Supervisor. In this case, the system re-connects to the security
domain at login to check the users universe access rights.
The following sections describe this process in more detail.
73
74

Here is an overall picture of how WILoginServer speeds up the login process:
At system startup...
WILoginServer
Business
Objects
primary node
starts
Connection Server
1. WILoginServer reads all users security information
from the repository security domain, then writes it Repository
to a memory cache.
2. WILoginServer precalculates the

security model then stores the information
in the cache.
3. Each time a user logs in, the server

authenticates the user in the
repository, then requests authorization
information for the user from the cache.
Login
cache
LSI factory
4. The LSI factory uses the security information
in the cache to build the users .lsi file,
then stores it in turn in the cache.
Figure 3-2 Workflow: Global view of how WILoginServer works
What WILoginServer does at system startup

This is what WILoginServer does each time the system is started, as well as
every time it refreshes its cache (see page 77):
1. At system startup, WILoginServer uses Connection Server to access the
repository.
WILoginServer reads the security information for all users in the security
domain, then stores several tables from the security domain in a cache. This
information includes:
- the hierarchy of groups and user instances
- users functional rights (security commands, product access)
- users document access rights
- users data access rights
2. WILoginServer uses the information in the cache to build a set of more
appropriate data structures which together form the security model. The core
of this model is its hierarchy of groups; for each group, the permissions for
each type of resource are recorded. For customized users, additional objects
are used.
Once the security model is complete, the original security information
imported from the repository is released from memory.
3. WILoginServer now pre-calculates the security information, applying the
inheritance rules across the entire hierarchy, starting from the root group.
All useless information, such as empty user groups, is cleared so as to free
as much memory as possible. The Business Objects server can now process
incoming login requests.
75
76
XWorkflow
WILoginServer
Login cache
WILoginServer
Connection Server
Repository
At system startup or at every

refresh period
Read OBJ_M_ACTOR, OBJ_M_ACTORLINK, OBJ_M_RESLINK,
OBJ_M_UNIVCST, OBJ_M_UNIDBCST tables
Return tables contents
Store tables content
Build groups and
users tree
Compute precalculated
security model
Store precalculated
security model
Repository tables contents are now
freed from memory
Figure 3-3 Workflow: Filling or refreshing the login cache
What WILoginServer does at login

1. When a user makes a login request, the request is sent through
WISessionManager to WILoginServer.
2. WILoginServer connects to the security domain in the repository to
authenticate the user.
The precise workflow for authentication depends on the authentication mode
the Business Objects administrator has chosen for the cluster. For more
information, see How the system handles different authentication methods on
page 79.
3. If the user is authenticated, WILoginServer uses the LSI factory to build the
.lsi file for the specific user from the data stored in the login cache. From the
cache information, the system builds a list of the resources that the user is
authorized to access. These resources include:
- document and universe domains in the repository
- documents
- universes
- the stored procedures associated with specific connections
- Business Objects applications and their features
- security commands
- universe overloads
For detailed workflow information, see Starting InfoView user sessions on
page 83.
Refreshing the login cache

WILoginServer takes a snapshot of specific repository tables at regular intervals
and precalculates the security model. This means that a user logging into
InfoView sees an image of the security model dating from WILoginServers last
refresh.
If a user tries to log into the system while the cache is being refreshed, the system
holds all login requests until the refresh is completed.
When an administrator makes a change to a users security rights, the user must
log out and log back in (establish a new session) and the login cache must also
be refreshed. Unless both of these things happen, the user security changes are
not immediately taken into effect.
77
78
You can manually refresh the cache by clicking the Refresh button on the
properties page for WILoginServer in the Administration Console:
Figure 3-4 Manually refreshing the WILoginServer cache
The cache is also automatically refreshed at regular intervals. You set this
interval using the WILoginServer modules Refresh Period parameter on the
same page in the Administration Console.
By default the refresh period is set to ten minutes (600 seconds).
How the system handles different

authentication methods
The Business Objects system administrator defines the authentication method as
a parameter of WILoginServer in the Administration Console:
Figure 3-5 Authentication methods in the Administration Console
The precise workflow for authentication is determined by the method the

administrator has chosen.
79
80
XBusinessObjects standard
When BusinessObjects standard authentication is selected:
1. The user requests the InfoView portal page in a web browser.
2. The user clicks the Login button, then enters a valid username and password.
3. The password is encoded and sent with the username to WILoginServer.
4. WILoginServer verifies the existence of the username and the validity of the
password entered for this user against the repository.
5. If the username and password are valid, WILoginServer builds:
- the list of applications the user is allowed to use
- the list of documents the user is allowed to use
- the list of security metadata (such as connection or universe overloads),
which is kept with the session as long as it is valid
XWindows authentication
When Windows authentication is selected:
2. The Microsoft IIS web server (set to Windows Authentication or NT Challenge
Response, depending on the version) transparently asks the web browser for
the users credentials.
3. The web browser responds.
4. The web server verifies these credentials against its authentication source.
5. If the credentials are accepted, the web server returns the InfoView portal
page.
6. The user clicks the Login button.
7. The users identity is retrieved from the web server and used by
WILoginServer to calculate the user's security rights.
XBasic authentication
When Basic authentication is selected:
3. The web server (set to basic authentication) requests the users credentials.
4. The user enters the credentials (username and password, LDAP username
and password, or certificate).
5. The web server verifies these credentials against its authentication source.
6. If the credentials are accepted, the web server returns the users identity,
which WILoginServer uses to calculate the user' security rights.
XNo authentication
When No authentication is selected:
2. The web server returns the InfoView portal page.
4. The user enters InfoView with a generic account (information is not checked
against a repository as there is no repository in this solution).
XExternal authentication
When External authentication is selected:
2. The user clicks the Login button, then enters a valid username and password.
3. The password is encoded and sent with the username to WILoginServer.
4. WILoginServer then:
- connects to the Business Objects repository
- reads the authentication method, then looks in the connection table for the
LDAP connection
- extracts the connection configuration file from the connection data
- initializes a security connector
The security connector is then ready to execute the LDAP request and
authenticate the incoming user.
NOTE
For more detailed workflow diagrams, see the LDAP Access Pack Guide.
81
82
Session management
The InfoView, WebIntelligence and Broadcast Agent applications all use
WIAPIBroker as the interface for to creating, accessing, and terminating
sessions.
Through WIAPIBroker, the username and password are provided for session
creation, so that the session is created and authenticated at the same time.
Application
server
HTTP
request
WISessionManager
ASP
WICOM
JSP
WIBean
WIAPIBroker
Applications
running in a
web browser
WIProcessManager
WIQT
Applications
Broadcast Agent
developed with
the SDKs
Figure 3-6 WIAPIBrokers role in session management
With this release, WIAPIBroker also takes over the responsibility of reserving the
critical WIQT process from the nodes WIQT process pool for all session
processing. It does this through WIProcessManager, the WIQT manager.
When the session is terminated, the WIQT process is released back into the pool.
NOTE
The only product that does not use WIAPIBroker for session management in a
3-tier deployment is BusinessObjects. See page 87.

Accessed through WIAPIBroker, WISessionManager creates and manages the
sessions in the Business Objects system. With BusinessObjects Enterprise 6.1,
WISessionManager is enabled as part of the session stack on each node in the
cluster. It creates and keeps track of all user sessions handled by that node.
WISessionManager also acquires many of the functions previously attributed to
WIQT in the login process. WISessionManager now:
creates the session directory at session creation, then sets the sessions
environment
This Session directory, created under
$INSTALLDIR\temp\sessions\<Session ID>, stores all temporary session
information.
copies the .key file, calls WILoginServer then copies the .lsi file
contains the sessions timeout mechanism
deletes the session when the user logs out
cleans up the session directory and removes it once the session is terminated
Logging into InfoView

Users log into the Business Objects system by clicking the blue Login button in
the InfoView login page in their web browsers:
Figure 3-7 InfoView login page
83
84
The InfoView login dialog box appears:
Figure 3-8 InfoView login dialog box
The user enters a user name and password, then clicks OK. If the system can
authenticate the user and finds that the user has the correct privileges, InfoView
opens.
XHow it works
1. When the user enters the authentication information and clicks OK, it sends
a request to a specific ASP/JSP page on the application server, passing the
username and password as parameters.
2. The ASP/JSP page asks WICOM/WIBean to authenticate the username/
password information and create a new InfoView session if authentication
succeeds.
3. WICOM/WIBean passes the request to the WIAPIBroker running on the least
loaded cluster node. This node will be responsible for all the processing
required during the user session.
4. WIAPIBroker then calls the WISessionManager running on the same node.
WISessionManager creates a new session, which is considered anonymous
and granted minimal privileges until the user fully authenticates.
5. WISessionManager asks WILoginServer to authenticate the username/
password, then compute the users access rights if authentication succeeds.
6. WILoginServer uses Connection Server to send an SQL SELECT statement
to the repository database which authenticates the information. It returns a
row of data which allows WILoginServer to validate the login policy.
7. When the username/password information has passed the authentication

checks, WILoginServer computes the users access rights by combining data
from the in-memory pre-computed security data model.
8. WILoginServer returns the UserID and .lsi file data to WISessionManager.
The .lsi file contains the complete access rights information for the user.
9. WISessionManager interacts with WIStorageManager to merge information
from the new .lsi file with the contents of the .lsi cache for the current user.
10. WISessionManager creates the users temporary session directory on the
current cluster node, then saves the final, merged .lsi file in this directory.
11. WISessionManager generates a session ID containing a reference to the
machine used for session processing. It then returns the session ID to
WIAPIBroker, which sends it back through WICOM/WIBean to the ASP/JSP
pages on the portal.
The session ID is incorporated in a cookie inside the HTTP header.
12. WIAPIBroker uses WIProcessManager to reserve a WIQT from the pool of
WIQT processes on the machine for the sessions processing.
WIProcessManager keeps track of which WIQT process is being used with
this particular session, the complete Session ID serving as a key.
If later on in the session the WIQT times out, WIProcessManager activates
another WIQT process from the process pool.
NOTE
The creation of an additional subsession is required for the calling of

WebIntelligence 6.x documents (.wid) from InfoView. For more information, see
page 95.
85
86
ASP/JSP Pages
WICOM/WIBean
WIAPIBroker
WISessionManager
WILoginServer
Repository
Browser
OpenSession
(User,Password)()
WICOM/WIBean
sends request to
WIAPIBroker running
on least loaded node
CreateSession (User,Password)()
Create session()
Initialize
SessionEnv()
Connection
Server
Login()
Authenticate and
check login policy() SQL
Return OK()
Return UserId &

.lsi file data as BLOB()
Write .lsi file to users

local session directory
Return Session()
Calculate .lsi content

fromcache()
WIStorageManager
Start session
Fast login with
.lsi file
Return Session()
SessionID incorporated
in cookie inside HTTP
WIProcessheader
Manager
ReserveWIQT()
WIQT
WIQT instance
reserved from
pool
Return InfoView Home Page()

InfoView home page
appears in browser
Figure 3-9 Workflow: Establishing an InfoView session

The manner in which BusinessObjects in 3-tier mode is launched determines
how sessions are managed.
You can launch the application from the Start menu under Windows, or from an
InfoView session through an ActiveX plug-in:
When you launch BusinessObjects from the Start menu, the system creates
a new InfoView session.
For detailed information, see page 88.
When you launch BusinessObjects from InfoView, the system creates a new
session by cloning the InfoView session and activating a dedicated WIQT
process for it. InfoView runs under the original session and BusinessObjects
runs under the cloned session.
For detailed information, see page 91.
.rkey file management

The .rkey file contains the base URL that the client machine uses to reach its
server.
When an InfoView user downloads BusinessObjects, the server downloads .rkey
file data to the 3-tier client; the client then generates the .rkey file and stores it
locally with any .key files from any 2-tier deployment of BusinessObjects.
Whenever the user subsequently logs into BusinessObjects in 3-tier mode
from the Windows Start menu, the .rkey file stored on the client is displayed
in the Security Domain list in the login dialog box, along with any 2-tier .key
files.
Whenever the user starts BusinessObjects from InfoView, the .rkey
information is once again downloaded from the server; for each cluster to
which the client connects, the corresponding .rkey file is written to the client
and displayed at subsequent logins.
87
88
Starting BusinessObjects from the Start menu

1. When you choose Start > Programs > Business Objects >
BusinessObjects 6.x, the login dialog box appears:
2. When you are authenticated, the BusObj process is launched on your

machine.
BusinessObjects opens:
XHow it works
When BusinessObjects is started from Start menu:
1. The client sends a connection request with no session cookie.
2. Since there is no session ID, HSAL/JHSAL chooses the least loaded cluster
node and binds to the WIDispatcher running on it.
3. WIDispatcher calls WISessionManager on the same machine.
4. WISessionManager reserves a WIQT from the process pool for the session,
then generates a session ID containing a reference both to the machine and
to the WIQT used for the sessions processing.
5. WISessionManager returns the sessionID through the HSAL/JHSAL to the
web server.
6. The web server sends the session ID back to the client, encapsulated in the
HTTP header.
7. The Login dialog box opens in the BusinessObjects client. When the user
enters a username and password and clicks OK, BusinessObjects submits a
login request.
8. The request is forwarded to the HSAL/JHSAL on the application server.
9. HSAL/JHSAL sends the request back through WIDispatcher and
WIADEServer, then to WISessionManager, all on the same cluster node as
used before.
10. WISessionManager asks WILoginServer to authenticate the username/
password.
11. When the username/password information has passed the authentication
check in the repositorys security domain, WILoginServer computes the
users access rights from the pre-computed security information already in the
systems login cache.
12. WILoginServer returns the UserID and .lsi file to WISessionManager. The .lsi
file contains the complete access right information for the user.
13. WISessionManager returns the result of the authentication, along with the .lsi
file, through the sessions dedicated WIQT, through the HSAL/JHSAL and on
to the BusinessObjects client.
14. The client reads the users rights from the .lsi file. If the user has the right to
use the application, BusinessObjects generates the .rkey file, which provides
the URL needed to connect to the correct repository. Any previously existing
.rkey file is overwritten.
15. The user can now use BusinessObjects.
89
90
WISessionManager
WIDispatcher
BusinessObjects
Repository
WIProcessManager
HSAL/JHSAL
WILoginServer
Reserve
WIQTInstance
SendURL()
WIQT
WIQT instance
reserved from
pool
ReturnSessionID()
Login dialog box opens
User enters credentials then
clicks OK
RequestLogin(User,Password)()
Generate
SessionID
SessionID incorporated
in cookie inside HTTP
WIADEheader
Connection
Server
Server
Authenticate(User,Password)
ReturnSecurity
Info()
Calculate rights
ReturnCalculated
SecurityInfo()
Write .lsi file
to users sessions temporary
directory
WIStorageManager
Read
.lsi file
Return authentication result
Session temporary directory
Transfer .lsi fle through HTTP

Write .lsi file to
BusinessObjects
Authorize user
from .lsi file
Generate .rkey file
The user can now use
BusinessObjects
Figure 3-10 Workflow: Launching BusinessObjects (3-tier mode) from Start menu
Starting BusinessObjects from InfoView

When a user launches BusinessObjects from InfoView, an existing InfoView
session is cloned. The user is therefore not reauthenticated.
Unlike Business Objects server products, BusinessObjects in 3-tier mode does
not use WIAPIBroker to create, access, and delete a session. Instead, it uses
HSAL/JHSAL-WIDispatcher-WISessionManager.
All interactions with the corporate database or the repository are handled by the
middle-tier server. Calculation and display, however, are handled on the client
machine.
XTo launch BusinessObjects from InfoView
To launch BusinessObjects from InfoView, you must have chosen one of the
following options in the InfoView Options pages.
The BusinessObjects option in the Create/Edit Option page:
Figure 3-11 Option for creating/editing documents with BusinessObjects
In this case, BusinessObjects is launched automatically when you click the

BusinessObjects link in the New Document section of the InfoView interface:
Figure 3-12 New Document section of the InfoView interface
91
92
The BusinessObjects (Windows only) option in the View Option page:
Figure 3-13 Option for viewing BusinessObjects documents in BusinessObjects
In this case, BusinessObjects is launched automatically whenever you open

a BusinessObjects document for viewing from InfoView.
XHow it works
When BusinessObjects is started from InfoView, an InfoView session and
session ID are already established, and the .lsi file resulting from the InfoView
login already exists for the user in the 3-tier environment.
1. The user does one of the following:
- selects a BusinessObjects document in a document list, then clicks the Edit
button
- asks to view a BusinessObjects document included in an InfoView
document list in BusinessObjects
- asks to create a BusinessObjects document from InfoView
InfoView sends a request for the creation of a session derived from the
InfoView session ID through the ASP/JSP pages then on to WICOM/WIBean
on the application server.
2. WICOM/WIBean binds to the WIAPIBroker running on the cluster node
hosting the current InfoView session.
3. WIAPIBroker calls the WISessionManager on the same node to clone the
session.
4. WISessionManager reserves a WIQT for the BusinessObjects session,

generates a new session ID, then clones the session environment so that the
new WIQT can process the BusinessObjects session requests.
5. The new session ID is sent back through WIAPIBroker, WICOM/WIBean and
the ASP/JSP pages to the client browser.
6. An ActiveX launcher starts BusObj.exe and passes it the new session ID.
7. The BusinessObjects login dialog box appears in the client. The user enters
a name and password and clicks OK. BusinessObjects sends an
authorization request to HSAL/JHSAL, which uses the session ID to route the
request to the WIDispatcher running on the cluster node handling the session.
8. WIDispatcher routes the request to the WISessionManager running on the
same node.
9. WISessionManager returns the .lsi file to the BusinessObjects client.
10. The client reads the users rights from the .lsi file. If the user has the right to
use the application, BusinessObjects generates the .rkey file, which provides
the URL needed to connect to the correct repository. Any previously existing
.rkey file is overwritten.
11. The client uses BusinessObjects.
93
94
WIBean/WICOM
InfoView
User creates, edits or
opens BO document
ASP/JSP
WISessionManager
WIProcessManager
WIAPIBroker
CreateNew
WIQTInstance
CloneSession(InfoViewSessionID)
WIQT
ReturnNewSessionID()
ActiveX Launch
(AXL)
This new instance

will be dedicated to
all BusinessObjects requests
CloneInfoView
SessionEnv
Check if BusinessObjects installed, version()

The correct version of BusinessObjects is installed
LaunchBusinessObjects(NewSessionID)()
HSAL/JHSAL
BusinessObjects
User enters credentials
then clicks OK
WIDispatcher
WISessionManager
FastAuthorization()=GetLSI()
Transfer .lsi file through HTTP
Write .lsi file to
BusinessObjects
Read users rights from
.lsi file
Generate .rkey file
Edit or View BusinessObjectsDocument()
Figure 3-14 Workflow: Launching BusinessObjects from InfoView
Repository

Before users can access WebIntelligence, they must already be logged into
InfoView. When they open or create a WebIntelligence 6.x .wid document, a
WebIntelligence 6.x document session is started to handle the new document as
a subsession of the current InfoView session. The document session therefore
accesses security and user information via the InfoView user session.
Implemented as ASF entities on the same machine as the user session, these
document sessions are technically contexts created inside WIReportServer.
The document session ends either when the user closes the document, or when
the user session ends.
95
96
chapter
98
Overview
The 3-tier Business Objects system creates documents using new modules and
workflows but also includes a facility for displaying and refreshing legacy
WebIntelligence documents.
The system now provides two options for the creation of WebIntelligence
documents, each of which offers distinct advantages:
A Java Report Panel offers speedy processing and drag-and-drop capability
An HTML Report Panel provides less functionality but greater security
This chapter briefly describes the types of documents the Business Objects
system processes and what you can do with them. It then describes how
WebIntelligence documents are created.
For detailed information about how BusinessObjects documents are created
using a 3-tier deployment of BusinessObjects, see Creating BusinessObjects
documents using a web connection on page 131.
This chapter covers:
Document types
How documents are stored and organized
Creating WebIntelligence documents
Document types
Business Objects recognizes four types of documents:
WebIntelligence 6.x documents
WebIntelligence 2.x documents
BusinessObjects documents
Third-party documents
WebIntelligence 6.x documents (.wid)

WebIntelligence documents, or .wid files, are created from within the
WebIntelligence 6.x application:
Figure 4-1 WebIntelligence 6.x document
These documents are generated and handled by the WIReportServer process.

WIReportServer uses a WIQT to exchange documents and universes with the
repository.
Document types
99
100
WebIntelligence 2.x documents (.wqy)

The system allows users to view and refresh documents created using
WebIntelligence 2.x.
These documents are processed, as in previous versions of the product, using
the WIQT process associated with the users InfoView session.
If users decide to edit and save a WebIntelligence 2.x document, however,
InfoView automatically migrates the document to the new WebIntelligence 6.x
format.
BusinessObjects documents (.rep)

BusinessObjects documents are created from within the BusinessObjects
application (in either 2- or 3-tier mode):
Figure 4-2 BusinessObjects document
In the 3-tier system, users can access BusinessObjects documents either

through InfoView, or through a 3-tier deployment of BusinessObjects:
When users view or refresh a BusinessObjects document through the
InfoView portal, the system generates the document view using a Business
Objects server process (BusObj under Windows, bolight under UNIX).
When users access and process BusinessObjects documents using
BusinessObjects in 3-tier mode, the BusinessObjects report engine still does
its own processing of the document and its data, but the communication with
the corporate databases and repository is provided by the processes in the
Business Objects server infrastructure.
Third-party documents (.*)

Business Objects allows you to distribute and access all kinds of third-party
documents within the secure environment provided by the repositorys security
domain. A third-party document is any type of file other than a BusinessObjects
or WebIntelligence file. Typically, this can be a Microsoft Office file (.doc, .xls,
.ppt, etc.), or any other type of file supported by your operating system (.zip file,
.pdf file, etc.):
Figure 4-3 Microsoft PowerPoint file displayed in InfoView
Document types
101
102
The basic differences in how third-party files are processed by Business Objects
are these:
You cannot create, edit, update, or schedule third-party files from within
InfoView.
When you view a BusinessObjects/WebIntelligence document, you can see
the document in your browser, but the document itself is generated on the
server, from which an HTML representation is created and sent to your
browser. The actual document remains on the server, and is not downloaded
to the client system.
When you view a third-party file, on the other hand, no HTML code is
generated. Instead, the binary data is downloaded to the client system, from
where it is automatically opened using the application in which it was originally
created (e.g., Word, Excel, Acrobat, etc.). When it is distributed, it is stored on
the server as is, without actually being processed by the server.
InfoView ensures the secure distribution of third-party documents, allowing
the addition of the documents to the portal, their download to the client, and
their distribution.
Users can view a third-party document added to the repository through InfoView
using the application in which the document was originally created if that
application is installed on the users workstation.

After you have created a document, you can save it to the corporate document
database, save it for your own personal use, or send it to one or more users or
groups. Your choice will determine where the document is stored and how the
document is categorized in your InfoView document lists (for more information,
see Chapter 1):
If you choose Save as a Corporate Document, the document is stored in the
repository document domain of your choice as a corporate document. At the
same time, you can also schedule the document for automated refresh and
publication by Broadcast Agent.
If you choose Save as a personal document, the document is stored in your
designated storage area as a personal document.
If you choose Send, the document is stored in the repository and appears in
the inboxes of the users to whom it is sent. You can also schedule the
document for automated distribution to specified recipients by Broadcast
Agent.
You can also choose to save documents on your own file system in any of a
selection of formats.
How the system processes each of these actions is described in detail in the next
chapter.
103
104

WebIntelligence 6x comes with two Report Panels for the creation and
modification of .wid documents:
An HTML Report Panel
The client is a set of web pages and requires a standard Javascript-enabled
web browser. This HTML client displays, edits and refreshes WebIntelligence
documents.
While the HTML Report Panel does not provide functionality such as dragand-drop capability, it is simpler to use and provides an enhanced level of
security.
Figure 4-4 An example WebIntelligence HTML Report Panel
The HTML Report Panel requires no applet download from the server. The
client exchanges standard HTTP requests and accesses web pages; the web
server can log those activities.
A Java Report Panel

The system uses a Java applet to edit complex documents that require
advanced editing and page layout functionality. This applet requires a Javaenabled web browser. The system downloads the applet from the web server
the first time the system uses the applet.
The Java Report Panel allows users to create or modify documents through
a user-friendly interface that implements advanced drag-and-drop and pagelayout capabilities.
Figure 4-5 An example WebIntelligence Java Report Panel
A Java application executes the WebIntelligence applet in the browsers Java

Virtual Machine and downloads the applet from the server each time the
system uses it.
105
106
Required InfoView option settings

To create a document using WebIntelligence, you must have selected the
WebIntelligence option in the Create/Edit tab of the InfoView Options pages:
Figure 4-6 WebIntelligence option in the InfoView Create/Edit Options tab (ASP)
You then click the Universes link.
Figure 4-7 Links for creating documents from InfoView (ASP)
The universe list appears in the users browser:
Figure 4-8 Universe list in WebIntelligence
Once the user chooses a universe in the list, the system triggers the loading of
the selected Report Panel.
Creating .wid documents with the Java Report Panel

This workflow involves:
1. Loading the WebIntelligence applet in the users browser.
2. Initializing the WebIntelligence session and creating the new (empty)
document.
3. Importing and opening the selected universe. Note that for WebIntelligence
6.x, universe files have the extension .unw.
4. Once the user has built the query, running the query and displaying the
results.
107
108
XLoading the applet in the browser (1/4)
ASP/JSP pages
Browser
CreateDoc(UnivID) with cookie
GetSessionFromCookie
Return HTML page containing <applet>

tag with parameters SessionId,UnivID
Load applet in browser with

parameters SessionId,UnivID
WebIntelligence applet is
loaded in the users browser
Figure 4-9 Workflow: Loading the WebIntelligence Report Panel applet (Java)
XCreating the empty document (2/4)

WIReportServer
WebIntelligence applet
InitSession(IVSessionID)
Create WebIntelligence session
from IVSessionID
Return WebI6SessionID
CreateDoc(WebI6SessionID,UnivID)
Create WebIntelligence document
(UnivID)
ReturnDocID
Figure 4-10 Workflow: Creating the empty WebIntelligence 6.x document (Java)
XOpening and displaying the universe (3/4)

WebIntelligence
applet
WIQT Repository
Access
WIReportServer
WebIintelligence
servlet/
ISAPI
GetDataSource(WebI6
SessionID,DocID)
Repository
WIStorageManager
WIQT Portal
ImportUniverse
(UnivID)
IsUniverseInCache(UnivID)
Return NotInCache
ImportUniverse(UnivID)
Return UniverseBytes
WIQT Portal stores universe (.unw)
in users temporary session folder
Store .unw file in cache
OpenUniverse
WIReportServer opens
.unw file in users temporary
session folder and loads its
contents in memory
Return universe contents
Universe classes and
objects appear in WebIntelligence
Report Panel
Figure 4-11 Workflow: Opening and displaying the universe (Java)
109
110
XRunning the query and displaying the results (4/4)

WebIntelligence
applet
WebIintelligence
servlet/
ISAPI
WIReportServer
Connection Server
Database
The user selects objects

from the WebIntelligence Report Panel,
builds the query, then clicks the
Run Query button
UpdateQuery(WebI6SessionID,
DocID,QuerySpec), sent as XML stream
Generate SQL based
on universe and query specification
Run SQL query against corporate database
Return query results
GetView(WebI6Session
ID,DocID,ReportSpec)
Return query results (xml)
Compute cube
and render view
The applet interprets the XML

stream and displays the view
Figure 4-12 Workflow: Running the query and displaying the results (Java)
Creating .wid documents using the HTML Report Panel

This workflow involves:
1. Loading the DHTML page in the users browser
2. Initializing the WebIntelligence session and creating the new (empty)
document
In this step, all calls from the DHTML client to WIReportServer use specific
JSP pages that rely on the REBean SDK. The REBean SDK in turn executes
CORBA calls that are connected to the correct WIReportServer.
3. Importing and opening the selected universe. Note that for WebIntelligence
6.x, universe files have the extension .unw.
4. Once the user has built the query, running the query and displaying the
results. The results are displayed by the WebIntelligence HTML viewer.
XLoading the HTML Report Panel (1/4)
HTML client
Portal pages
Browser
Browser calls a
specific ASP/JSP page
Request CreateDoc on UniverseID with Cookie

Return HTML page containing javascript DHTML code with parameters SessionID.UniverseID
Load DHTML
page in memory
Figure 4-13 Workflow: Loading the HTML Report Panel
XInitializing the session and creating the .wid document (2/4)

DHTML client
REBean/RECOM
SDK
WIReportServer
InitNewWebI6Session(IVSessionID)
Create WebIntelligence 6.x
session based on InfoView
SessionID
Return WebI6SessionID
CreateDoc(WebI6SessionID,UnivID)
Create WebIntelligence 6.x
document (UnivID)
ReturnDocID
Figure 4-14 Workflow: Creating the empty .wid document (DHTML)
111
112
XImporting and opening the selected universe (3/4)

Note how closely this workflow resembles the same step in the Java applet
workflow:
DHTML
client
WIQT Repository
Access
WIReportServer
WIQT Portal
REBean/RECOM
SDK
GetDataSource(WebI6
SessionID,DocID)
ImportUnivere
(UnivID)
Repository
WIStorageManager
IsUnivInCache(UnivID)
Return NotInCache
ImportUniv(UnivID)
SQL
Return UnivBytes
WIQT Portal stores universe (.unw)
Store .unw file in cache
OpenUniv
WIReportServer opens
.unw file in users temporary
session folder and loads its
contents in memory
Return univ contents
Universe classes and
objects appear in WebIntelligence
Report Panel
Figure 4-15 Workflow: Importing and opening the selected universe (DHTML)
XRunning the query and displaying the results

DHTMLclient
REBean/RECOM
SDK
WIReportServer
Connection Server
Database
servlet/
ISAPI
The user selects objects
from the WebIntelligence Report Panel,
builds the query, then clicks the
Run Query button
UpdateQuery&Report(WebI6SessionID,
DocID,QuerySpec,ReportSpec)
Generate SQL based
on query specification
Run SQL query against corporate database
Return doc token
Return query results
ASP/JSP pages
Call WebIntelligence HTML doc viewer
with doc token
The HTML document viewer

opens in Report Panel with
the new document displayed in it
Figure 4-16 Workflow: Running the query and displaying the results (HTML)
113
114
chapter
Downloading and Using

BusinessObjects
116
Overview
BusinessObjects can be deployed within either a 2- or 3-tier architecture.
These modes differ in the following respects:
In 2-tier mode, the connectivity is installed on the client, which communicates
directly with the repository and the database via proprietary database
middleware protocols. The middleware connectivity for the appropriate
database type must be installed on every client machine.
In 3-tier deployments of BusinessObjects, however, although the report
engine itself remains on the client machine, the connectivity with the
repository and corporate databases is housed on the Business Objects
server. Here the client-side application is much lighter than the 2-tier
application. It is launched on the client desktop, either from InfoView, or from
the Windows Start menu.
This chapter provides you with detailed information about how the following
workflows work:
Downloading BusinessObjects from InfoView
Retrieving a corporate document
Displaying a report
Refreshing documents
Creating BusinessObjects documents using a web connection
Using BusinessObjects in offline mode
For information about BusinessObjects session management and login
workflows, see 3-tier BusinessObjects user sessions on page 87.
What is BusinessObjects in 3-tier mode?

BusinessObjects in 3-tier mode is composed of two parts:
the client side
the server side
Communicating through HTTP, these two parts exchange:
the .lsi file
lists of users and groups, categories and documents
document content
SQL queries and their responses
The client side

The client side is composed of standard BusinessObjects Reporter components,
including the user interface, the API & workflow layer, report engine, calculator,
Document data and metadata, query technique. These components are identical
to the those in 2-tier deployments of BusinessObjects.
In order to communicate with the server, BusinessObjects in 3-tier mode also
includes a set of HTTP components:
The workflows to HTTP layer translates processing requests like login, user
and document lists, and so forth into HTTP calls destined for WIADEServer.
The SQLBO/HTTP layer translates SQL requests from the client into HTTP
requests routed through the server components to WIQT Z-SQLBO, which
then queries the corporate database.
The HTTP protocol layer implements the HTTP protocol.
The server side

3-tier deployments of BusinessObjects use the server infrastructure for:
connectivity with the repository and corporate database

SQL querying of the repository and corporate database, and the retrieval of query
results
authentication and security
the exchange of documents, universes and lists
Because BusinessObjects uses the servers connectivity, it requires no
configuration.
What is BusinessObjects in 3-tier mode?
117
118
The BusinessObjects report engine

Hosted on the client exclusively, the report engine has four main functions:
Rendering a report in a readable format
Refreshing a report by retrieving data from the corporate database and
populating the microcube
Report analysis, which means enabling users to change their view of report
data, or to extend their view of enterprise data
Editing a report by modifying the query and the report structure
Report engine components interact with documents and universes stored as files
in their local environment. They use the Business Objects server components
WIQT Portal and WIQT Repository Access to upload and download documents
from the repository.
The report engine is made of the following parts:
Component
Description
User interface layer
Represents the user interface used for displaying

and interacting with the report
API & workflow layer
Provides the API interface with the report and

implements processing workflows for the report
engine
Report engine
Generates the report layout, using the calculator

to calculate cell values
Calculator
Calculates the cell values of the report using the

report specification (report metadata, to get the
formulas) and cube data
Query technique
Generates the SQL query using the report query

and the semantic layer objects
Connectivity layer
Acts as the interface between the report engine

and the database middleware; manages the
execution of the query
BusinessObjects processing overview

3-tier deployments of BusinessObjects communicate using the HTTP protocol.
HTTP requests sent by BusinessObjects are captured in CORBA calls to
WIDispatcher by the HSAL or JHSAL. WIDispatcher then routes the request to
WIADEServer, which processes the request by calling one of the following:
a WIQT process for repository interactions such as importing and exporting
documents
WIStorageManager for cache interactions
WISessionManager to retrieve user information
BusinessObjects processing overview
119
120

To download and install BusinessObjects from InfoView, you must be using a
Windows machine and you must choose at least one of the following options in
the InfoView Options pages.
The BusinessObjects option in the Create/Edit Option page:
Figure 5-1 Option for creating/editing documents with BusinessObjects
The BusinessObjects (Windows only) option in the View Option page:
Figure 5-2 Option for viewing BusinessObjects documents in BusinessObjects
Once you have chosen either of these options, you can install BusinessObjects
in two ways:
Immediately by clicking the Download BusinessObjects link next to the option
The first time you require BusinessObjects to view, create or edit a document
The workflow for each type of download and installation is different.
Downloading BusinessObjects from the InfoView Download link

1. When you click the Download BusinessObjects or Download and Install
BusinessObjects link in the InfoView Options pages, the BusinessObjects
Setup dialog box opens:
2. You click the Install BusinessObjects button to start installation.

The Installation Wizard guides you through the installation.
3. When installation is complete, the following dialog box appears:
121
122
XHow it works
Portal
Browser
User clicks
Download BusinessObjects
link
Cluster node
SendUrlEdit()
ReturnInstallationBootstrapPage()
Installation bootstrap page

contains the
ActiveXSetup (AXS)
reference
ActiveX Setup (AXS)

GetInstallShield()
LaunchAXS()
RetrieveFiles()
LaunchRunSetup.exe
Portal page contains the

Microsoft InstallShields
setup.exe file, resource
files and the Business
Objects runsetup.exe file
LaunchSetup.exe(MSIDBPath)()
DownloadFiles()
Windows Installer is
downloaded to client machine
and installed if required
Setup.exe launches
LaunchInstaller(MSIPath)()
Windows Installer, passing it
the URL of the page containing
the Installer DB (MSI file)
GetMSIFile()

Microsoft InstallShields
database file
DownloadMSIFile()
User clicks
Install button in Installation Wizard
LaunchInstallWizard()
GetBOFiles()
DownloadBOFiles()
InstallationFinished()
CheckInstallation()
InstallationSuccessful()
InstallationStatus()
InstallationNotSuccessful()
Portal sends client Installation Wizard Complete

screen
Portal sends client
error message
Figure 5-3 Workflow: Downloading by clicking the Download link
Downloading BusinessObjects when opening or creating a document

In this scenario, you download BusinessObjects the first time you open or create
a BusinessObjects document:
Portal
Client
machine
SendUrlEdit()
Cluster node
ActiveXLaunch (AXL)
reference
GetAXL()
ActiveX Launch (AXL)
Check if BO installed, BO version ()
BO not installed

ActiveXSetup (AXS)
reference
GetAXS()
ActiveX Setup (AXS)
LaunchSetup.exe(MSIDBPath)()
GetUsefulFiles()

Microsoft Installer DB (MSI)
Figure 5-4 Workflow: Downloading by opening/creating a document
.rkey file generation

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.
123
124
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
before launching launch BusinessObjects from the Start menu, launch it from
InfoView by opening a BusinessObjects document
This triggers the generation of the .rkey file on the client.
XHow is the .rkey file generated?
1. The ActiveX launches BusinessObjects in command line mode, using the
settings for the ASP or JSP page hosting the ActiveX. It also transmits a file
called ZABOparaminfo.ini, which contains all the information required for
launching BusinessObjects.
2. The BusinessObjects session reads the .ini file, uses it to create the .rkey file
and then deletes the .ini file.

To retrieve a corporate document from BusinessObjects:
1. You click File > Retrieve from > Corporate Documents in BusinessObjects.
A dialog box displaying the list of corporate documents available to you
opens:
2. You double-click on a document in the list to view it.

The list of corporate documents is contained in the .lsi file on the client.
BusinessObjects recalculates this list only if the user clicks the Refresh button.
How it works
1. The user asks to view a document in the document list.
2. The API & workflow layer calls the Import Document function.
3. The workflow to HTTP layer forwards the call to WIADEServer. The call is
translated into an HTTP request, which is forwarded to WIADEServer through
the BusinessObjects HTTP layer, HSAL/JHSAL and WIDispatcher chain.
4. WIADEServer calls WIQT Portal to read the document file. WIQT Portal uses
WIQT Repository Access to read the database rows associated with the
document.
125
126
5. The .rep file is extracted from the repository and placed in the cache. WIQT
Portal takes the .rep file from the cache and sends it back as an HTTP
response through HSAL/JHSAL and the web server to the BusinessObjects
client.
6. The workflows to HTTP layer decodes the HTTP response and writes the .rep
file to the client machine.
7. The API & workflow layer loads the .rep file into the user interface where the
user can view it.
BusinessObjects on
client machine
BusinessObjects reads the .lsi file on the client
machine and displays the Corporate Documents list
The user asks to view a document in the list
User
Interface
API &
Workflow
Workflows
to HTTP
HSAL/JHSAL
WIDispatcher
WIQT
Portal
WIADEServer
HTTP
WIQT
Repository Repository
Access
layer
ImportDoc()
ReadDocFile()
Return .rep()
.Rep file stored in
cache
Return .rep
Decode HTTP and
write .rep file to
client file system
LoadDoc in BO
Document is
displayed in
users browser
Figure 5-5 Workflow: Retrieving a corporate document in BusinessObjects
Displaying a report
This workflow describes the display of a specific report, or page, in a
BusinessObjects document.
The BusinessObjects report engine and calculator process reports block by
block. Once the information for all the documents blocks has been returned, the
report engine generates the page content and sends it to the user interface.
1. The user asks to view a report page. A query telling the report engine what
part of document the user wants to see is transmitted.
2. The report engine reads the document metadata then creates an internal
image of the report structure.
3. For each block and cell contained in the report structure, the report engine
asks the calculator to calculate the values.
4. The calculator reads the formulas and dependencies from the document
metadata, then builds an internal image of report data.
5. The calculator evaluates the requested cell by reading data from the cube and
applying calculations.
6. The calculator returns the cell values to the report engine.
7. Steps 4-6 are repeated for each cell of the block.
8. The report engine lays out the report cells then returns the page content to the
user interface.
9. The user interface displays the report page.
Displaying a report
127
128
BusinessObjects on
client machine
The document is open in the users browser
The user asks to view a specific report page
User
Interface
Report
Engine
Calculator
Report
Specification
Cube
Send query specifying

requested report page
Read document metadata
then create internal image of report structure
Calculate values for
each block and cell
in report structure
Read formulas and
dependencies from
document metadata
These steps repeated
for each cell of block
then build internal image

of report data
Evaluate required cell by reading data from cube

then applying calculations
Return cell values
Return page content
Generate report
cell layout
The report is displayed

in user interface
Figure 5-6 Workflow: Displaying a report in a BusinessObjects document
You refresh an open document in 3-tier deployments of BusinessObjects by
clicking the Refresh Data button in the toolbar.
Because the document in this workflow has already been retrieved from the
repository, both the document and the universe on which it was built are already
loaded inside the BusinessObjects report engine.
129
130
BusinessObjects on
client machine
HSAL/JHSAL
WIDispatcher
WIQT
Z-SQLBO
Database
The BusinessObjects document is open in the

users browser
User
Interface
API &
Workflow
Query
Technique
Connectivity
SQL to HTTP
HTTP
layer
RefreshDoc
Generate
request
Generate SQL query

by combining document
query and semantic layer
data
Return reference
to generated
query
SQL is generated if:

- the universe has changed
- the universe is more recent than the SQL
- SQL generation is required by a security
command
Execute query
The response is
returned in parcels of
n lines, according to
how the connection
was configured
This loop is repeated
until the entire
document is
refreshed
Return raw data
Query result
Return HTTP response
Encapsulate
result in HTTP
response
Decode response and

retrieve raw data
Read raw data and

store it in cube
Return
status of
request
The document data

is refreshed
Figure 5-7 Workflow: Refreshing a document in BusinessObjects
This workflow ends with the reports data refreshed but not displayed in the users
browser. To display the report, the system then launches the workflow described
in Figure 5-6.
Creating BusinessObjects documents using a

web connection
BusinessObjects users can use universes exported to the repository only.
This is what happens when you create then run a query from BusinessObjects:
1. Having selected BusinessObjects as your document editor in the InfoView
Options pages, you click a new document link in InfoView or
BusinessObjects.
The New Report Wizard Welcome page appears:
131
132
2. You choose a report layout then click Begin. The Specify Data Access page
appears:
3. You choose the Universe option as your data source then click Next.
The list of universes you have stored locally plus the universes to which you
have access in the repository appears:
4. You select the universe then click Finish. The Query Panel opens:
133
134
5. You build the query in the Query Panel.

6. When you are done, you click Run.
You can now use the data to build and format a BusinessObjects document.
How it works
Creating a BusinessObjects document with a web connection can be divided into
two broad steps:
1. Opening the universe and creating the query (1/2)
2. Generating the query then running it (2/2)
XOpening the universe and creating the query (1/2)
In this part of the workflow:
1. When the user clicks Create document, BusinessObjects creates an empty
document, then reads the list of universes in the .lsi file.
The list of universes opens in BusinessObjects.
2. The user selects a universe from the list.
3. BusinessObjects downloads the universe and reads its tables. This allows it
to display the universes classes and objects in the Query Panel.
4. The user uses the objects to create the query.
BusinessObjects on
client machine
HSAL/JHSAL
WIDispatcher
WIQT
Z-SQLBO
Repository
The user clicks the Run button in the Query Panel

User
Interface
API &
Workflow
Report
Engine
Connectivity
SQL to HTTP
HTTP
layer
CreateDocument
Create empty
document
Return universe list
Read universe
list from .lsi
Universe list is
displayed in
browser
User selects a
universe
GetUniverse()
DownloadUniverse()
Copy universe
to client machine
Download universe
classes & objects
Read tables
in universe
Query Panel appears

in BO with universe
objects displayed
User places objects in
Query Panel to create
query
Figure 5-8 Workflow: Opening a universe and creating the query
135
136
XGenerating the query then running it (2/2)

In this part of the workflow:
1. The user clicks the Run button in the Query Panel.
2. The query technique on the client generates the SQL query by combining the
document query and the semantic layer data.
3. The query technique returns the reference to the generated query to the API
& workflow layer.
4. The API & workflow layer executes the query. The query is sent through the
client components, then through the HSAL/JHSAL/WIDispatcher and WIQT
Z-SQLBO to the corporate database.
5. WIQT sends the query results back in an HTTP response to the Connectivity
SQL to HTTP component on the client.
6. This component decodes the response to retrieve the raw data, which it sends
to the API & workflow layer.
7. The API & workflow layer reads the data then stores it in the cube on the
client; it then returns the status of the request to the user interface.
8. If the status is OK, the user interface then submits a request to display the
document. For this workflow, see Figure 5-6.
BusinessObjects on
client machine
HSAL/JHSAL
WIDispatcher
WIQT
Z-SQLBO
Database
The user clicks the Run button in the Query Panel

User
Interface
API &
Workflow
Query
Technique
Connectivity
SQL to HTTP
HTTP
layer
Run query
Generate SQL query
Generation
of the SQL
request
Return ref to
generated
query
Execute query
Query result
Execution
of the
request
Return HTTP response

Return raw data
Encapsulate
result in HTTP
response
Decode response and

retrieve raw data
Read raw data and

store it in cube
Return
status of
request
The documents first page (default)

is displayed in BusinessObjects
See Figure 9-12 for the following sequence
Figure 5-9 Workflow: Generating and running the query
137
138
Using BusinessObjects in offline mode

If users choose to work in BusinessObjects in offline mode they work without a
connection to the Business Objects server. Users can log in offline only if they
have connected at least once to BusinessObjects online. BusinessObjects reuses the information cached in the local .lsi file to allow the user to log on offline.
Logged on offline, users can access documents stored locally. They cannot
however edit, refresh, send, retrieve or publish documents.
chapter
Document Processing from

InfoView
140
Overview
The InfoView portal allows you to view and process BusinessObects,
WebIntelligence 6.x and 2.x documents, as well as third-party documents.
This chapter explains how the 3-tier Business Objects system processes these
documents from InfoView. It illustrates with detailed workflow diagrams the
processes of displaying, refreshing, saving and publishing documents. These
workflows include:
Displaying document lists
Refreshing document lists
Displaying BusinessObjects documents
Refreshing BusinessObjects documents
Displaying WebIntelligence 6.x documents
Refreshing WebIntelligence 6.x documents
Saving documents as corporate documents
Saving documents as personal documents to the portal
Saving personal documents to a local drive
Sending documents to other users
Processing third-party files
Scheduling documents with Broadcast Agent

This section describes the workflow for displaying the Corporate Documents list
in InfoView.
Figure 6-1 Corporate Documents list in InfoView
If there is no request to refresh the list, the system simply retrieves the list of the
corporate documents the user is allowed to see from the information stored in the
users existing .lsi file.
This is how it works:
ASP/JSP
pages
WIBean
WICOM
WIQT
Portal
WIAPIBroker
WIStorageManager
Browser
Request CorpDoc list
with Cookie
GetCorpDocsList
Read Corp
Docs list from
.lsi file
Return CorpDocsList
The Corporate Documents list

is displayed in InfoVIew
Figure 6-2 Workflow: Displaying the Corporate Documents list
141
142

When you refresh a document list in InfoView, the system must re-connect to the
repositorys security domain to obtain the most up-to-date information for the
documents you are allowed to access.
You can refresh InfoView document lists either automatically (at login to
InfoView, or whenever you visit the list), or manually. You set automatic refresh
options in the Lists tab of the Options pages:
Figure 6-3 Setting automatic refresh options for document lists
To manually refresh a document list, with the list open in InfoView, you click the
refresh button:
Figure 6-4 Manually refreshing a document list
Regardless of how the document list is refreshed, this is how it works:

WIBean
WICOM
Browser
ASP/JSP
pages
WIQT
Portal
WIAPIBroker
Repository
WIQT Repository
Access
RequestCorpDocList
with cookie()
GetSessionFrom
Cookie
GetCorpDocList()
ReturnCorpDocList()
Update users
.lsi file
ReturnCorpDocList()
The Corporate Documents list

is refreshed in InfoVIew
Figure 6-5 Workflow: Refreshing the Corporate Documents list
143
144

In InfoView, you can choose to display BusinessObjects documents in HTML
format, PDF format or enhanced document format.
Figure 6-6 BusinessObjects document viewing options
The option to view and refresh BusinessObjects documents from 3-tier

BusinessObjects is covered in Downloading and Using BusinessObjects on
page 115.
NOTE
All the workflows in this section refer to BusinessObjects documents which have
been stored as corporate documents in the repository.
Displaying BusinessObjects documents in HTML format

When you select the HTML format option for BusinessObjects document viewing,
.rep documents are regenerated in HTML and displayed in an HTML viewer:
Figure 6-7 BusinessObjects document displayed in HTML format
Displaying a BusinessObjects document in HTML involves two sequences.

XImport and open the requested document
1. Check whether the requested document already exists and is up-to-date in
the WIStorageManager cache. If it is not, import the document from the
repository.
2. Store the imported document in the users temporary session folder. This
becomes the working document that will be modified when the user refreshes
or modifies it.
3. Open the working document in the BusObj (Windows) or bolight (UNIX)
report engine.
145
146
This workflow is described in Importing and opening a BusinessObjects

document in HTML on page 147.
XGenerate the HTML view and send it back to the users browser
This can be done in either of two ways:
Using the SDK
This method allows you to customize output and workflows using standard
ASP/JSP pages that call the WebIntelligence SDK. Developer Suite provides
samples that demonstrate how to view and refresh .rep documents using the
WIBean/WICOM SDK.
This workflow is described in Generating the HTML for a BusinessObjects
document using the SDK on page 147.
Using tunneling
This method directly generates HTML output from the BusObj/bolight
report engine and sends it back to the users browser. Very similar to how
these documents were processed in version 5.1/2.7, InfoView uses this
method when viewing and refreshing .rep documents.
This workflow is described in Generating the HTML for a BusinessObjects
document using tunneling on page 149.
XImporting and opening a BusinessObjects document in HTML

WIBean
WICOM
Browser
ASP/JSP
pages
WIQT
Portal
WIAPIBroker
Repository
BusObj
bolight
WIStorageManager
BOManager
User has asked to view

a BusinessObjects document
listed in an InfoView document
list
RequestDocId
OpenDoc(DocId)
ImportDoc(DocId)
(SessionFolder)
IsDocInCache
(DocId)
NotInCache
ImportDoc(DocId)
(SessionFolder)
SQL
ReturnDoc()
OpenDoc
ReturnDocObject()
ReturnStorageToken()
OK()
BusObj/BOL stores doc in

users temporary session
folder
Figure 6-8 Workflow: Importing and opening a .rep document in HTML
XGenerating the HTML for a BusinessObjects document using the SDK

As this workflow begins, the BusinessObjects document has already been
retrieved from the cache or repository and opened by BusObj or bolight but is
not yet displayed in the client browser.
147
148
WIBean
WICOM
Browser
ASP/JSP
pages
WIQT
Portal
WIAPIBroker
GetHTMLView
(DocObject)
BusObj
bolight
WIStorageManager
BOManager
GetHTMLElement
(StorageToken,ElemPath)
IsPresInCache
(DocIdElemPath)
Return NotInCache
GetHTMLElement
(ElemPath)
BusObj/BOL computes
the document and genrates the requested
HTML view
Return HTML
StorePresInCache
(DocId,ElemPath)
Return HTML
The InfoView
ASP/JSP page formats
the HTML appropriately and
sends it back to the users
browser
ReturnHTML()
The BusinessObjects
document appears in
the users InfoView.
Figure 6-9 Workflow: Generating HTML for .rep document (SDK)
XGenerating the HTML for a BusinessObjects document using tunneling

As this workflow begins, the BusinessObjects document has already been
retrieved from the cache or repository and opened by BusObj or bolight but is
not yet displayed in the client browser.
HSAL/JSAL
WIDispatcher
Browser
WIQT
Portal
ASP/JSP
pages
WIStorageManager
BOManager
BusObj
bolight
ReturnHTMLPage
containing callback URL
with storage token
RequestHTML using callback
URL with storage token
GetHTMLElement(Storage
Token,ElemPath,
HTMLFrame)
IsPresInCache
ReturnNotInCache
GetHTML
Element()
ReturnHTML
StorePresInCache(DocID,ElemPath)
Return HTML
The BusinessObjects
document appears in
the users InfoView.
Figure 6-10 Workflow: Generating HTML for .rep document (tunneling)
149
150
Displaying BusinessObjects documents in PDF format

When you open BusinessObjects documents in InfoView in PDF format, the
system launches the Adobe Acrobat Reader in your browser:
Figure 6-11 A BusinessObjects document displayed in PDF format
In order to display the document in PDF format, the system first checks the
presentation cache for a PDF presentation of the document.
If it doesnt find one, it retrieves one from the repository, stores a copy in the
cache, then uses the ASP/JSP pages on the application server to launch the
Adobe Acrobat Reader on the client.
HSAL/JHSAL
WIDispatcher
Browser
ASP/JSP
pages
WIStorageManager
BOManager
BusObj
bolight
WIQT Portal
User asks to view a

BusinessObjects document
from an InfoView document list
GetPDFView
(StorageToken)()
GetPDFView()
Check
Format()
GetPDFView()
IsViewInCache()
NotInCache
GetPDFElement(ElemPath)
BusObj/Bolight computes the document
and generates the requested PDF view
Return PDF()
StorePresInCache()
ReturnPDF()
Run()
LoadAcrobat
Reader()
DisplayPDF()
The BusinessObjects
document opens in
PDF viewer within
InfoView
Acrobat Reader
Figure 6-12 Workflow: Displaying a .rep document in PDF format
151
152
Displaying Business Objects documents in the enhanced document viewer

If you selected Enhanced document format in your options for viewing
BusinessObjects documents, the document is opened in the ActiveX enhanced
document viewer:
Figure 6-13 BusinessObjects document in enhanced document viewer
This workflow uses the following chain of communication: Browser > ASP/JSP
pages > HSAL/JHSAL/WIDispatcher > WIQT Portal > BOManager >
BusObj/bolight > repository:
1. The user requests to view a BusinessObjects document in the enhanced
viewer.
2. BusObj/bolight checks the cache for the file.
3. If the file is not in the cache, BusObj/bolight retrieves it from the repository
document domain, stores a copy in the cache, and stores another in a
temporary session folder.
4. BusObj/bolight opens the document in the temporary session folder, then
sends it back to the ASP/JSP pages.
5. The ASP/JSP pages create a page that will launch the ActiveX viewer in the
browser.
6. The ActiveX is downloaded to the browser.
7. The ActiveX sends a request to the BusObj/bolight for the documents
report tree.
8. BusObj/bolight returns the report tree and the documents first page, or
report, to the ActiveX viewer.
Whenever the user asks to view another report in the document, the page is
retrieved from the corporate cache.
153
154
HSAL/JHSAL
WIDispatcher
Browser
WIQT
Portal
ASP/JSP
pages
WIStorage- Repository
Manager
BOManager
OpenDoc(DocId)
BusObj
bolight
IsDocInCache
(DocId)
NotInCache
ImportDoc(DocId)
ReturnDoc()
StoreDoc
InCache()
BusObj/bolight stores document
in temporary session folder
OK()
Download
ActiveX
OpenDoc
Create page that will

launch ActiveX viewer
in browser
ActiveX
viewer
Get report tree
Load first page by default, plus report tree
The BusinessObjects
document appears in
the users InfoView.
For each report in the document that the user wants to view,
the system carries out the following two transactions:
ViewPage()
LoadPage()
Figure 6-14 Workflow: Viewing a .rep document in the enhanced viewer
Each page is
retrieved from
corporate cache,
then sent back to
ActiveX viewer

You can refresh and save .rep documents in InfoView:
in HTML format
in PDF format
This section describes the first of these options.
The workflow for refreshing documents varies depending on whether the
document contains prompts or not.
If a document has no prompts, the system can go straight to the corporate
database to refresh the documents data.
If the document has prompts, however, the system must first retrieve the set
of prompts from the repository, then display the prompts in the InfoView client.
Only once the user has filled in the prompts can the system go to the
corporate databases to refresh the document data itself.
Refreshing a document without prompts

HSAL/JHSAL
WIDispatcher
WIBean
WICOM
Browser
ASP/JSP
pages
BOManager
WIQT
WIAPIBroker
BusObj
bolight Database
The BusinessObjects
document is already
displayed in InfoView
GetDocFromStorageToken()
ReturnDocObject()
Refresh .rep()
Refresh()
Return HTML()
The BusinessObjects
document is refreshed
in InfoView
Figure 6-15 Workflow: Refreshing a .rep document without prompts
155
156
Refreshing a document with prompts

WIBean
WICOM
Browser
ASP/JSP
pages
HSAL/JHSAL
WIDispatcher
WIAPIBroker
BOManager
BusObj
bolight Repository
WIQT
The BusinessObjects
document is already
ReturnDocObject()
GetPromptList()
ReturnPromptList()
If not empty, set
prompt values...()
GetPromptList()
ReturnPromptList()
SetPrompt()
Database
Refresh()
ReturnHTML()
The BusinessObjects
in InfoView
Figure 6-16 Workflow: Refreshing a .rep document with prompts

You can view WebIntelligence documents in HTML format or PDF format by
choosing from the Options page menu below:
Figure 6-17 WebIntelligence document viewing options
To display a WebIntelligence 6.x document in InfoView, the system does the

following:
1. Initialize the WebIntelligence session. See the following section for a detailed
workflow.
2. Import and open the requested document:
- Check whether the document already exists and is up-to-date in the system
cache. If it is not, import the document from the repository.
- Store the imported document in the users temporary session folder. This
it.
- Open the working document in WIReportServer.
See Opening and importing the document (2/3) on page 159.
3. Generate the requested view (standard HTML, interactive HTML or PDF)
then send it back to the users browser. See Generating the requested view
(3/3) on page 159.
For all presentations, the first two steps are the same.
157
158
Initializing the WebIntelligence 6.x session (1/3)
ASP/JSP
page
Browser
REBean
RECom
WIReportServer
Request DocID
with cookie
OpenDoc(DocID)
InitSession(SessionID)
Create WebI6.x session
from portal SessionID
ReturnWebI6SessionID
Figure 6-18 Workflow: Initializing a WebIntelligence 6.x session
Opening and importing the document (2/3)

REBean
RECOM
Browser
ASP/JSP
pages
WIStorageManager
WIQT
Portal
WIReportServer
Repository
WIQT Repository
Access
OpenDoc(WebI6
SessionID,DocID)
ImportDoc
(WebI6SessionID,DocID)
IsDocInCache(DocID)
Return DocNotInCache
ImportDoc(DocID)
SQL
ReturnDocBytes
WIQT Portal stores doc in
folder, then copies imported
doc to cache
StoreDocInCache()
OpenDoc
Return
DocObject
Return
DocToken
Figure 6-19 Workflow: Opening and importing a .wid document
Generating the requested view (3/3)

WebIntelligence 6.x documents (.wid) can be displayed:
In HTML format
In PDF format
The following subsections describe these workflows.
159
160
XIn HTML format

REBean
RECOM
ASP/JSP
pages
WIReportServer
Browser
GetView(DocObject,
HTML)
GetPages(WebI6SessionID,
DocToken)
Compute cube and
render view
Return view (XML data)
Transform XML
into HTML
Return view (HTML)
WebIntelligence 6.x
document opened in
HTML viewer
Figure 6-20 Workflow: Generating an HTML presentation of a .wid document
XIn PDF format

ASP/JSP
page
REBean/RECom
SDK
WIReportServer
Browser
DocInstance.GetView
(PDF)()
GetPages(WebI6SessionId,
DocId,DocMediaPDF...)()
ReturnPDF()
Launch Adobe
Acrobat Reader
WebIntelligence 6.x
document opened in
PDF viewer within
InfoView
Generate
PDF()
Report Engine Repeng
generates PDF in
memory;
WIReportServer
allows then returns
a BlobID
Acrobat Reader
Figure 6-21 Workflow: Generating a PDF presentation of a .wid document

You can refresh .wid documents from any of the viewers in which you can display
them in InfoView:
in the HTML viewer
in the PDF viewer
This section describes the first of these options.
The workflow for refreshing documents varies depending on whether the
document contains prompts or not.
If a document has no prompts, the system can go straight to the corporate
database to refresh the documents data.
If the document has prompts, however, the system must first retrieve the set
of prompts from the repository, then display the prompts in the InfoView client.
Only once the user has filled in the prompts can the system go to the
corporate databases to refresh the document data itself.
Refreshing a document without prompts

ASP/JSP
pages
REBean
RECOM
WIReportServer
WIQT
Browser
Database
The WebIntelligence document

is already displayed in InfoView
OK()
ReturnDocObject()
Refresh .wid
Refresh()
ReturnHTML()
The WebIntelligence 6.x

document is refreshed in
HTML viewer
Figure 6-22 Workflow: Refreshing a .wid document without prompts
161
162
Refreshing a document with prompts

REBean
RECOM
ASP/JSP
pages
WIReportServer
Repository
WIQT
Browser
The WebIntelligence document
is already displayed in InfoView
ReturnDocObject()
GetPromptList()
ReturnPromptList()
If not empty, set
prompt values...()
GetPromptList()
ReturnPromptList()
SetPrompt()
The user sets the prompt
and clicks OK
Database
Refresh()
ReturnHTML()
document is refreshed in
HTML viewer
Figure 6-23 Workflow: Refreshing a .wid document with prompts

The Business Objects system allows you to display and refresh WebIntelligence
2.x documents (.wqy) but does not allow you to edit them. If you edit the
document, the system will convert it into WebIntelligence 6.x (.wid) format.
The workflow for displaying a WebIntelligence 2.x (.wqy) consists of two
sequences.
XImport and open the requested document
1. Check whether the requested document already exists and is up-to-date in
the WIStorageManager cache. If it is not, import the document from the
repository.
2. Store the imported document in the users temporary session folder. This
it.
3. Open the working document in the WIQT report engine.
This workflow is described in Importing and opening a BusinessObjects
document in HTML on page 147.
XGenerate the HTML view and send it back to the users browser
This can be done in either of two ways:
Using the SDK
This method allows you to customize output and workflows using standard
ASP/JSP pages that call the WebIntelligence SDK. Developer Suite provides
samples that demonstrate how to view and refresh .rep documents using the
WIBean/WICOM SDK.
This workflow is described in Using the SDK on page 165.
Using tunneling
This method generates HTML output from the WIQT report engine and sends
it back to the users browser.
This workflow is described in Using tunneling on page 166.
163
164
Importing and opening a WebIntelligence 2.x document (1/2)

WIQT
Portal
WIBean
WICOM
Browser
ASP/JSP
pages
WIStorageManager
WIQT Repository
Access
WIAPIBroker
User asks to view .wqy

document from a document
list in InfoView
RequestDocID
with cookie()
OpenDoc(DocId)
GetSessionFrom
Cookie
Repository
ImportDoc
(DocID,SessionFolder)
IsDocInCache(DocId)
ReturnNotInCache
ImportDoc(DocId)
ReturnDocBytes
WIQT Portal stores doc
OpenDoc()
Return
ReturnDocObject() StorageToken()
Figure 6-24 Workflow: Importing and opening a .wqy document
SQL
Generating the HTML for a WebIntelligence 2.x document (2/2)

As this workflow begins, the WebIntelligence 2.x document has already been
retrieved from the cache or repository and opened by WIQT Portal, but is not yet
displayed in the client browser.
XUsing the SDK
ASP/JSP
pages
WIBean
WICOM
WIAPIBroker
WIQT
Portal
WIQT
Report Engine
Browser
GetHTMLView(DocObject)
GetHTML
(StorageToken)
GetHTML()
ReturnHTML
ASP/JSP page
formats the HTML
appropriately and
sends it to the browser
Return HTML()

document is displayed in
the users InfoView
Figure 6-25 Workflow: Generating the HTML for a .wqy document (SDK)
165
166
XUsing tunneling
ASP/JSP
pages
HSAL/JHSAL
WIDispatcher
WIQT
Portal
WIQT
Report Engine
Browser
Return HTML page
containing callback URL
with storage token
Request HTML using callback
URL with storage token (HTTP)
Request HTML using
callback URL with
storage token (CORBA)
GetHTML
ReturnHTML
document is displayed in
the users InfoView
Figure 6-26 Workflow: Generating the HTML for a .wqy document (tunneling)

WebIntelligence 2.x documents are refreshed differently depending on whether
or not the documents contain prompts. The communication channel used by the
system is:
browser > ASP/JSP pages > WIBean/WICOM > HSAL/JHSAL/WIDispatcher >
WIAPIBroker > WIQT > database.
Refreshing documents without prompts

This is how the system refreshes WebIntelligence 2.x documents without
prompts:
WIBean
WICOM
Browser
ASP/JSP
pages
WIAPIBroker
HSAL/JHSAL
WIDispatcher
WIQT
Database
The WebIntelligence
document is already
ReturnDocObject()
Refresh .wqy()
Refresh()
Return HTML()

in InfoView
Figure 6-27 Workflow: Refreshing a .wqy document without prompts
Refreshing documents with prompts

When the system refreshes a WebIntelligence 2.x document with prompts, the
workflow includes an additional set of transactions for refreshing the documents
list of prompts.
167
168
Browser
ASP/JSP
pages
WIBean
WICOM
WIAPIBroker
WIQT
Repository
The WebIntelligence
document is already
ReturnDocObject()
GetPromptList()
Return
PromptList()
If not empty, set
prompt
values...()
HSAL/JHSAL
WIDispatcher
GetPromptList()
ReturnPromptList()
Database
SetPrompt()
Refresh()
ReturnHTML()

in InfoView
Figure 6-28 Workflow: Refreshing a .wqy document with prompts

When you save a document as a Corporate Document, you save it to the
repository for viewing by all qualified users. You can save a document to the
Corporate Documents area by selecting the Save as a Corporate Document
option from the list below.
Figure 6-29 Save as a Corporate Document option
169
170
Saving WebIntelligence 6.x documents

In this workflow, the .wid document is saved from the WebIntelligence Java
Report Panel.
The workflow for a document saved from the HTML Report Panel is similar,
except that communication between the Report Panel and WIReportServer
passes through the REBean/RECOM SDK components instead of the
WebIntelligence servlet/ISAPI.
WebIntelligence
applet
WebIintelligence
servlet/
ISAPI
WIReportServer
WIQT Repository
Access
Repository
WIStorageManager
The user clicks Save as

a Corporate Document in
the InfoView Save page
Get groups & category info
Return groups & category info
Read groups & category

info from .lsi file
Dialog box opens in users

browser
User enters document
attributes and clicks OK
SaveCorpDoc(WebI6SessionID,
DocID,DocAttributes)
Save document in
temporary directory
Publish(DocAttributes)
SQL
WIQT Repo Access executes

the SQL required to store the
document bytes in the tables in
the document domain and update
the tables in the security domain
(destination user groups and
associated categories)
Figure 6-30 Workflow: Saving a .wid document as a corporate document
Saving WebIntelligence 2.x and BusinessObjects documents

The system saves these two types of documents to the repository as corporate
documents in the same way:
ASP/JSP
pages
HSAL/JHSAL
WIDispatcher
Browser
WICOM
WIBean
WIQT Portal
WIAPIBroker
Repository
WIQT Repository
Access
The user clicks Save as

a Corporate Document in
the InfoView Save page
Get groups & categories info
Return groups & categories info
Read category
info from .lsi file

browser
SaveCorpDoc(IVSessionID,DocID,DocAttributes)
Publish(DocAttributes)
SQL
WIQT Repo Access executes

the necessary SQL to store the
document bytes in the tables in
the document domain and update
the tables in the security domain
(destination user groups and
associated categories)
Figure 6-31 Workflow: Saving a .wqy or .rep document as corporate document
171
172
Saving documents as personal documents to

the portal
In InfoView, you can save documents as personal documents in your own
personal storage space on the server by choosing the Save as a personal
document option.
Figure 6-32 Save as a personal document option (to the portal) in InfoView

Report Panel.
WebIntelligence
applet
WebIintelligence
servlet/
ISAPI
WIReportServer
WIQT
WIStorageManager
The user clicks Save

as Personal Document in
InfoView Save page
Get personal categories info
Read category
info from personal
storage
Return personal categories info

browser
SavePerso(WebI6SessionID,
DocID,DocAttribs)
Save document until

now held in memory
to .wid file
Save(DocAttribs)
WIStorageManager
saves .wid file in
users personal
storage area on server
Figure 6-33 Workflow: Saving a .wid document as a personal document
Saving documents as personal documents to the portal
173
174
Saving BusinessObjects and WebIntelligence 2.x documents

As usual, .rep and .wqy file processing uses the same workflow, involving the
following channel of communication:
Browser > ASP/JSP pages > HSAL/JHSAL/WIDispatcher > WIAPIBroker >
WIQT Portal > WIStorageManager
ASP/JSP
pages
Browser
HSAL/JHSAL
WIDispatcher
WICOM
WIBean
WIQT Portal
WIStorageManager
WIAPIBroker

InfoView Save page
Read category info from

personal storage

browser
SavePerso(IVSessionID,DocID,DocAttribs)
WIStorageManager
saves .wqy or .rep file
in users personal
Figure 6-34 Workflow: Saving a personal document on the portal

You can save personal documents to a local drive on your computer in either
Excel or PDF format. You can do that by choosing the second Save as a personal
document option in the menu below.
Figure 6-35 Save as a personal document option (to local drive) in InfoView
175
176

Report Panel.
WebIntelligence
applet
WebIintelligence
servlet/
ISAPI
WIReportServer
WIQT Portal
WIStorageManager

InfoView Save page
Read category
info from personal
storage

browser
SavePerso(WebI6SessionID,
DocID,DocAttribs)
Save document until

now held in memory
to .wid file
Save(DocAttribs)
WIStorageManager
saves .wid file in
users personal
Figure 6-36 Workflow: Saving a .wid file to a local drive
Saving BusinessObjects and WebIntelligence 2.x documents

BusinessObjects and WebIntelligence 2.x documents are both saved to a local
drive from InfoView using the same chain of communication: ASP/JSP pages >
WICOM/WIBean > HSAL/JHSAL/WIDispatcher > WIAPIBroker > WIQT Portal >
WIStorageManager:
1. First, the personal categories information displayed in InfoView is refreshed
with the latest information from the users personal storage on the server.
2. When the user clicks OK, the document is stored in the designated place on
the users local drive by WIStorageManager.
ASP/JSP
pages
Browser
HSAL/JHSAL
WIDispatcher
WICOM
WIBean
WIQT Portal
WIStorageManager
WIAPIBroker

InfoView Save page
Read category info from

personal storage

browser
SavePerso(IVSessionID,DocID,DocAttribs)
WIStorageManager
saves .wqy or .rep file
to users local drive
Figure 6-37 Workflow: Saving a .rep or .wqy document to a local drive
177
178
Sending documents to other users

The system sends documents in the same way as it saves them. The only
difference is where the document or file is sent in the repository:
When you save a document to the repository from InfoView, the document is
stored in the corporate storage area of the repository document domain,
where other users with the appropriate rights can access it.
When you send a document to another user, the document is also sent to the
repository document domain. In this case, however, the document is stored
in the Inbox of the selected recipient(s).
Corporate
document
domain
Repository
Save to
repository (publish)
Inbox
document
domain
Repository
Send to
other users
Figure 6-38 Sending vs. saving a document to the repository

You can add third-party files to the portal through InfoView, then display them or
download them for private use. Here is an example of a Microsoft PowerPoint
presentation displayed in InfoView:
Figure 6-39 A third-party document displayed in InfoView
This section contains:

Displaying third-party files
Adding a third-party file to the portal
179
180
Displaying third-party files

You display a third-party file in InfoView simply by double-clicking its name in a
document list. If the files native application is installed on your computer, the
document is opened in the application, within the InfoView window.
Heres how it works:
1. When the user asks to view a third-party document, the request is
communicated through ASP/JSP pages > WIBean/WICOM > WIAPIBroker >
WIQT and to WIStorageManager, which checks the cache for the document.
2. If the document isnt in the cache, WIQT retrieves it from the document
domain in the repository, then stores it in the cache and in a temporary
session folder.
3. WIQT opens the document then sends it back through the chain to the ASP/
JSP pages.
4. The ASP/JSP pages send a request for the files binary content back to
WIStorageManager, which retrieves the content from the cache.
5. The files extracted contents are sent back to the browser, with the name of
the file written in the header of the response.
6. The browser uses its list of MIME types to match the file name with an
application.
- If an application matching the MIME type is installed on the client machine,
the browser launches it with the file open in it.
- If no such application is installed on the client machine, the user may be
prompted to install it.
ASP/JSP
pages
WIBean
WICOM
WIAPIBroker
WIQT
WIStorage
Manager
Repository
Browser
User asks to view a third-party
file from an InfoView document
list
RequestDoc(DocID,DocName)
IsInCache()
Return
NotInCache
ImportDoc
(DocName,DocID)
ReturnDoc()
StoreDocIn
Cache()
WIQT stores doc in
folder
OpenDoc()
Open OK
GetBinaryContent()
ExtractContent()
Name of file name is written in
HTTP header
Browser uses MIME type registry
to recognize type of file and
launch file in its native application
if installed on client machine
Figure 6-40 Workflow: Displaying a third-party document
181
182
Adding a third-party file to the portal

You can add a non-Business Objects document to the InfoView portal by clicking
the Add document link under New Document on the InfoView home page:
You then designate a path to the document using the dialog box below.
Figure 6-41 Workflow: Adding a third-party file to the portal
ASP/JSP
pages
WIBean
WICOM
WIAPIBroker
WIStorage
Manager
WIQT
Repository
Browser
User enters name of file to be
added to the portal, then
clicks OK
BinaryFile()
NewDoc()
FillNewDoc(FileName...)
UploadDoc(FileName,StorageToken)
WIQT stores doc in
in temporary session folder
OK()
UploadDoc(FileName,...)
OpenDoc()
Open OK
GetBinaryContent()
ExtractContent()
Name of doc written to
HTTP header and mime.type
file on web browser
Browser uses mime.type file
to recognize type of file and
launch file in its native application
if installed on client machine
User is given choice to

Save or Send the document
Figure 6-42 Workflow: Adding a third-party file to the portal
Once the file has been uploaded to the repository, InfoView displays the
document in its native application and gives the user a choice of sending or
saving it. See the following section for these workflows.
183
184
Sending and saving third-party files as corporate documents

The 3-tier system saves third-party files to the repository as corporate
documents, and sends them to other Business Objects users in much the same
way.
The communication for both these workflows passes from the client through the
ASP/JSP pages on the application server, WIBean/WICOM, WIAPIBroker, WIQT
and finally, the repository.
The actual destination of the file in the repository depends on whether it was
saved as a corporate document, or sent to other users:
If it was saved, it is stored in the document domain specified by the user.
If it was sent, it is stored in each recipients inbox in the document domain.
ASP/JSP
pages
WIBean
WICOM
WIAPIBroker
WIQT
WIStorage
Manager
Repository
Browser
User chooses to send or save a
third-party file as a corporate
document
Get group (for Send only) & category info
Return group & category info
Read groups
& category
info
Group/category info
is updated in Save as
corporate document or
Send dialog box
attributes then clicks OK
SaveCorpDoc()/SendDoc
(IVSessionID,DocAttributes)
PublishDoc/SendDoc(DocAttributes)
WIQT executes the necessary SQL
to store the document bytes in the
tables in the document domain and
update the tables in the security
domain (destination user groups/
categories)
Figure 6-43 Workflow: Sending third-party file, or saving as corporate document

To schedule Business Objects documents for automatic refresh and distribution
via Broadcast Agent from InfoView:
1. You click the Scheduled Refresh option in the Send or Save page:
185
186
The dialog box with scheduling options opens:
2. You click Apply.
How Broadcast Agent processes jobs

The scheduling of documents for automatic refresh and distribution with
Broadcast Agent involves two broad steps:
1. The user sets the documents attributes and scheduling options in InfoView,
then sends the task to the repository to await processing. See Scheduling
documents from InfoView on page 186.
2. The actual processing of the task by Broadcast Agent, at the time or intervals
specified by the user. See Running the scheduled tasks on page 189.
Scheduling documents from InfoView

Scheduling WebIntelligence 6.x documents and scheduling WebIntelligence 2.x
and BusinessObjects documents involve different workflows.
XScheduling WebIntelligence 6.x documents

WebIntelligence
servlet/ISAPI
WIReportServer
WIQT
Browser
Repository
User clicks Scheduled
Refresh option in InfoView
Get Groups/Users/BCA server list
Check
.lsi for group
and/or user info
Retrieve BCA server info
Return Groups/Users/BCA server info
Send or Save dialog box
is updated with current information
If user modifies
prompts:
GetPromptList()
ReturnPromptList()
If not empty, set
prompt values...()
GetPromptList()
ReturnPromptList()
User sets prompt value
SetPromptValue()
OK()
User sets scheduling options

and clicks OK
ScheduleCorpDoc
(IVSessionIS,DocID,DocAttribs,SchedulingInfo)
PublishDoc
(DocAttribs)
OK(DocID)
ScheduleDoc(DocAttribs,
SchedulingOptions)
Task is added to
DSPending table in
repository
Figure 6-44 Workflow: Scheduling a .wid file
187
188
XScheduling BusinessObjects and WebIntelligence 2.x files

ASP/JSP
pages
HSAL/JHSAL
WIDispatcher
WICOM
WIBean
Browser
WIQT Portal
WIQT Repository
Access
WIAPIBroker
Repository
User clicks Scheduled

Refresh option in InfoView
Get Groups/Users/BCA server list
Check
.lsi for group
and/or user info
Retrieve BCA server info
Return Groups/Users/BCA server info
Send or Save dialog box
is updated with current information
If user modifies
prompts:
GetPromptList()
ReturnPromptList()
If not empty, set
prompt values...()
GetPromptList()
ReturnPromptList()
User sets prompt value
SetPromptValue()
OK()
User sets scheduling options

and clicks OK
ScheduleCorpDoc
(IVSessionIS,DocID,DocAttribs,SchedulingInfo)
PublishDoc(DocAttribs)
SQL
OK(DocID)
ScheduleDoc(DocAttribs,
SchedulingOptions)
Task is added to
DSPending table in
repository
Figure 6-45 Workflow: Scheduling a .wqy or .rep file
Running the scheduled tasks

The main agent in Broadcast Agent processing is the Scheduler. The Scheduler
scans the DSPending table in the repositorys security domain at defined
intervals for the list of jobs that are ready to be run. The interval is defined by the
Scanning repository delay setting in the Administration Console below.
Figure 6-46 Scheduler settings in the Administration Console
This list is limited to the number of tasks that the Scheduler can process (Max.
no. of running jobs) for each type of document.
If the task involves report bursting, in which the document sent is tailored to each
recipients access rights, a separate child task is created for each recipient.
189
190
XProcessing BusinessObjects files

Processing scheduled BusinessObjects files involves the Scheduler,
BOManager, and BusObj/bolight processes only:
1. The Scheduler asks BOManager to create a session and a context for the
document to be processed.
2. BOManager creates the session.
3. The Scheduler sends a request to import the document through BOManager
to a BusObj/bolight process, which checks in the .lsi file for the proper
rights.
4. If sufficient rights are accorded, BusObj/bolight imports the document from
the repository and sends it back through BOManager to the Scheduler.
5. The Scheduler sends the order to execute a macro which extracts the .rep file,
through BOManager to BusObj/bolight.
6. The extracted .rep file is sent back through the chain to the Scheduler.
7. The Scheduler transmits the document to be sent or saved, back through the
chain to the repository.
Repository
Scheduler
BOManager
BusObj/bolight
CreateSession()
OK()
CreateDocContext()
OK()
ReceiveDocFromDAS()
ImportDoc()
Check rights
ImportDoc()
OK()
ExecuteMacro()
Execute()
Macro extracts the .rep file
VisualBasic module is created from
this code and executed
OK()
SendDocToUsers/SaveDoc()
SendToDAS()
OK()
Figure 6-47 Workflow: How Broadcast Agent processes a .rep file
191
192
XProcessing WebIntelligence 6.x files

To process WebIntelligence .wid files, the system relies on a communication
chain involving the Scheduler, WIReportServer and WIQT:
1. The Scheduler asks WISessionManager to create a a new Broadcast Agent
session.
2. The Scheduler uses the communication chain to check with
WIStorageManager to see if the document context is in the cache. If it isnt, it
imports the document from the repository, then stores it in the cache.
3. The Scheduler asks WIQT via WIReportServer to check the .lsi file for the
proper permissions to update the document. If it finds those permissions,
WIReportServer refreshes the document.
4. The Scheduler sends the document through the communication chain to the
repository, to be saved as a corporate document or sent to other users.
5. WIQT removes the existing copy of the document from the cache and
replaces it with an updated version.
6. WIReportServer closes the tasks session.
Scheduler
WIReportServer
WISessionManager
WIQT
WIStorageManager
Repository
GetBatchSession()
SessionID()
OpenDoc(DocCtxt)()
GetDoc(DocCtxt)()
Doesnt exist()
ImportDoc()
CheckRights()
ImportDoc()
DocumentBlob()
SetDocInCache()
OK()
UpdateQuery
(RefreshBatch)()
CheckRights()
OK()
OK()
Publish/Send()
RefreshDoc()
Publish()
CheckRights()
SendDocsToUsersFromDS()
DocID()
RemoveDocFromCache(old)()
OK()
SetDocInCache()
DocID()
OK()
CloseSession()
OK()
Figure 6-48 Workflow: How Broadcast Agent processes a .wid file
193
194
Processing WebIntelligence 2.x files

The system uses a simple Scheduler/WIQT channel for most of this workflow:
1. Scheduler asks WISessionManager to create a new session.
2. Once the new session is created, Scheduler asks WIQT to check in the .lsi file
for the required rights to access and refresh the document .
3. If it finds them, WIQT checks with WIStorageManager to see if the document
exists in the cache.
4. If the document is not in the cache, WIQT imports it from the repository and
returns it as a BLOB to the Scheduler.
5. The Scheduler requests WIQT to refresh the document.
6. The Scheduler sends the document to the repository via WIQT, to be sent or
saved as a corporate document.
7. If the operation is successful, the Scheduler asks WISessionManager to close
the session.
Scheduler
WIQT
WISessionManager
WIStorageManager
Repository
GetBatchSession()
SessionID()
ImportDocWithError(DocCtxt)()
CheckDocRights()
GetDoc(DocCtxt)()
Doesnt exist()
ImportDoc()
DocumentBlob()
OK()
ExecuteMacroWithError()
RefreshDoc()
OK()
SendDocToUsers()
SendDocsToUsersFromDS()
DocID()
DocID()
CloseSession()
OK()
Figure 6-49 Workflow: How Broadcast Agent processes a .wqy file
195
196
appendix
Logical Components/Physical
Files
198
Overview
This appendix provides a list of logical components in the Business Objects 3-tier
system, and the names of the files corresponding to each of them.
Component/file reference
Layers to which the
components belong
Names of logical
components
Names of physical files
Client
Administration Console
applet
admin.war
WebIntelligence Java
applet
ThinCadenza.jar
InfoView ActiveX viewer
RptVieweren.cab
Thin Cadenza.cab
(en=language variable)
Presentation
BusinessObjects in 3-tier
mode
ZaboIEen.cab
Administration servlet
wijadmin.jar
(for Internat Explorer in

English)
admisapi.dll
Administration SDK
cdzlet.jar
BODocGenISAPI.dll
WebIntelligence servlet
cdzsdk.jar
RECOM100.dll
ReBean/ReCom
wibean.jar/wicom250.dll
HSAL/JHSAL
iswi.dll/jhsal.jar
WIDispatcher
WIDispatcher.exe
Component/file reference
199
200
Layers to which the

components belong
Names of logical
components
Names of physical files
Functional servers
WIAdminServer.exe
WIAPIBroker
wiapibroker.exe
WIQT
wiqt.exe
WIADEServer
wiade.exe
BOManager
BOMgr.exe
BusinessObjects processes busobj.exe/bolight

(BusObj/bolight)
WIReportServer
WICDZServer.exe
WebIntelligence OLAP
engine
oaw*.ocx
oaw*.dll
Broadcast Agent Scheduler BcaScdul.exe

Application Services WISiteLog
WISiteLog.exe
WIProcessManager
WIProcessManager.exe
+ asfManager.jar
WIClusterManager
WIClusterManager.exe
WILoginServer
WILoginServer.exe
WISessionManager
WISessionManager.exe
WIStorageManager
WIStorageManager.exe
ASF Manager
asf.dll
asf_java.jar
Connectivity
Connection Server
cs_*.dll
SQLBO
dataAccess\RDBMS\leg
acy\*.dll
Index
.ctg file 52
.lsi file 73
how it is generated 77
.rep files
creating in 3-tier mode (workflow) 131
described 100
displaying in enhanced format (workflow) 152
displaying in InfoView (workflow) 144
displaying in PDF format (workflow) 150
processing scheduled (workflow) 190
refreshing in BusinessObjects (workflow) 129
refreshing in InfoView (workflow) 155
refreshing with prompts (workflow) 156
refreshing without prompts (workflow) 155
saving as corporate documents (workflow) 171
saving as personal documents (workflow) 174
saving to a local drive (workflow) 177
scheduling (workflow) 188, 189
.rkey file
generation of 89, 93
how it is generated 124
how it is managed 87
obtaining 123
.unw files 107, 110
.wid files
creating (workflow) 104
creating using HTML Report Panel (workflow)
110
creating using Java Report Panel (workflow)
107
described 99
displaying in HTML format (workflow) 160
displaying in PDF format (workflow) 160
required InfoView settings for their creation
106
.wqy files
described 100
displaying (workflow) 163
refreshing (workflow) 167
Symbols
3-tier architecture
presentation layer 26
processing layer 34
3-tier deployments
new role of web servers 26
Index
201
202
A
ActiveX
downloading BusinessObjects (3-tier) 87
enhanced viewer in InfoView 152
how it launches BusinessObjects from
InfoView (workflow) 93
administration
how it works 42
Administration Console
and Administration Server 46
and WILoginServer 73
how module modifications are implemented 44
interface 40
login (workflow) 42
Administration SDK
and Administration Server 46
Administration Server 46
Clean up period parameter 48
Inactivity timeout parameter 46
role in administration layer 37
session startup (workflow) 47
Adobe Portable Document Format see PDF
documents
application servers
how they are launched 60
IIS or J2EE? 27
new role with this release 26
ASF
and the webi.bat script 60
how it is launched 60
ASP configurations
hosted components 29
overview 27
ASP pages
role of 28
Attribut.txt file 52
audit
how audit logs are created 49
Audit Server 49
authentication
defined 73
of Administration Server session (workflow) 47
see also security
Index
authorization
defined 73
B
BOL_batch
role in processing layer 36
BOMain.lsi file 55
BOManager
BOMGR directory 51
Broadcast Agent
corporate documents cache 53
how it processes jobs (workflows) 189
how the system schedules documents
(workflow) 186
scheduling documents with (workflows) 185
Broadcast Agent Manager
Schedulers 36
Business Objects
consulting services 15, 17
documentation 14
Documentation Supply Store 13
support services 15
training services 15, 17
Business Objects processes
defined 35-36
see also modules
Business Objects system

communication protocols 41
corporate documents cache 53
how administration works 42
how it creates audit logs 49
login 70
login (workflow) 83
new role of web servers 26
presentation layer 26
processing layer 34
processing third-party files (workflows) 179
saving documents as corporate documents
(workflows) 169
saving documents as personal documents
(workflows) 172
saving documents to a local drive (workflows)
175
scheduling documents for automatic refresh
(workflows) 185
sending documents to other users (workflows)
178
session management 70-87
setting the environment 63
shutdown 67
starting 58
startup under UNIX (workflow) 62
startup under Windows (workflow) 61
what happens at startup and shutdown 57-68
BusinessObjects
connectivity differences between 2-tier and 3tier 116
documents see .rep files 100
BusinessObjects 5i see BusinessObjects in 3-tier
mode
BusinessObjects documents see .rep files
BusinessObjects in 3-tier mode

client side 117
components 117
creating documents (workflow) 131
creating the query (workflow) 134
displaying a report (workflow) 127
downloading from InfoView (workflow) 120
downloading when creating a document
(workflow) 123
executing query (workflow) 136
how it is launched from InfoView (workflow) 93
how sessions work 87
obtaining the .rkey file 123
opening universes (workflow) 134
report engine architecture 118
report engine components 118
retrieving a corporate document (workflow)
125
server side 117
starting from InfoView 91
starting from InfoView (workflow) 91
starting from Start menu (workflow) 88
using offline 138
which universes can it access? 131
BusinessObjects processes
defined 35, 36
C
cache directory 51
caches
how WILoginServer uses cache at system
startup (workflow) 74
InfoView portal list 55
login 55
of corporate documents 53
of InfoView corporate categories list 55
of InfoView corporate documents list 55
of InfoView document categories list
of InfoView Inbox Documents list 55
of InfoView universe list 55
of users personal data 55
calculator 118
Index
203
204
clusters
how multiple clusters are started 63
starting 58
storage 52
where they store what 50
com.bo.adminbean.Server object 47
Connection Server
how its used by Login Server 75
connectivities
2-tier vs. 3-tier deployments of
BusinessObjects 116
consultants
Business Objects 15
cookies
header 71
CORBA
when it is used as communication protocol 41
corporate categories
where InfoView list is stored 55
corporate documents
cache for 53
how they are stored 103
retrieving from 3-tier BusinessObjects
(workflow) 125
saving documents as (workflows) 169
Corporate Documents list
creating
WebIntelligence 6.x documents (workflow) 104
WebIntelligence documents (workflow) 104
customer support 15
D
demo
materials 13
Developer Suite 14, 16
Docs directory 53
document categories
see also corporate categories
document lists
Index
documentation
CD 13
feedback on 14
on the web 13
printed, ordering 13
roadmap 13
search 13
Documentation Supply Store 13
documents
corporate 103
creating .rep files with 3-tier BusinessObjects
(workflow) 131
creating .wid files (workflows) 104
displaying .rep files in InfoView (workflows)
144
displaying .wid files (workflows) 157
displaying .wqy files (workflows) 163
how they are stored and organized 103
inbox 103
personal 103
refreshing .rep files in 3-tier BusinessObjects
(workflow) 129
refreshing .rep files in InfoView (workflow) 155
refreshing .wid files (workflows) 161
refreshing .wqy files (workflows) 167
retrieving from 3-tier BusinessObjects
(workflow) 125
saving as corporate documents (workflows)
169
saving personal documents to local drive
(workflows) 175
saving personal documents to the portal
(workflows) 172
scheduling (workflows) 185
types processed by the system 99
Download BusinessObjects link (InfoView) 121
downloading
BusinessObjects from InfoView (workflow) 120
BusinessObjects when opening or creating a
document (workflow) 123
DSPending table 189
E
education see training
Enable real-time user rights update option 73
enhanced document viewer

displaying BusinessObjects documents
(workflow) 152
F
feedback
on documentation 14
H
HSAL
defined 29
processing role in 3-tier deployments of
BusinessObjects 119
role in ASP configurations 31
role in displaying .rep files in InfoView 153
role in displaying .wqy files in InfoView 167
role in refreshing .rep and .wqy files in InfoView
155
role in saving .rep and .wqy files in InfoView
174, 177
HTML format
displaying WebIntelligence 6.x documents in
(workflow) 160
HTML Report Panel 104
creating documents using (workflow) 110
loading (workflow) 111
running the query (workflow) 113
HTTP
I
IIS application server configurations 27
inbox documents
how they are stored 103
storage of 52
Index
205
206
InfoView
adding third-party files to portal (workflow) 182
and BusinessObjects ActiveX launcher 87
BusinessObjects (Windows only) option (View
Option page) 120
BusinessObjects option (Create/Edit Option
page) 120
displaying BusinessObjects documents
(workflow) 144
displaying BusinessObjects documents in
enhanced format (workflow) 152
displaying document lists (workflow) 141
displaying third-party files (workflow) 180
displaying WebIntelligence 2.x documents
(workflow) 163
displaying WebIntelligence 6.x documents
(workflow) 157
downloading BusinessObjects (workflow) 120
how ActiveX launches BusinessObjects
(workflow) 93
how the system schedules documents
(workflow) 186
portal list cache 55
refreshing BusinessObjects documents
(workflow) 155
refreshing WebIntelligence 2.x documents
(workflow) 167
(workflow) 161
required options for creating WebIntelligence
documents 106
Save as a Corporate Document option 103
Save as a personal document option 103
saving BusinessObjects documents as
corporate documents (workflow) 171
saving BusinessObjects documents as
personal documents (workflow) 174
saving BusinessObjects documents to a local
drive (workflow) 177
saving third-party files as corporate documents
(workflow) 184
saving WebIntelligence 2.x documents as
Index

saving WebIntelligence 2.x documents to a
local drive (workflow) 177
saving WebIntelligence 6.x documents to a
local drive (workflow) 176
Send option 103
sending third-party files (workflow) 184
starting BusinessObjects from 87, 91
starting BusinessObjects from (workflow) 91
installation directory
default values 58
itadmin command 63, 68
J
J2EE application server configurations 27
Java
Java Report Panel
creating documents using (workflow) 107
described 105
loading (workflow) 108
running the query (workflow) 110
JHSAL
defined 29
role in JSP configurations 33
JSP configurations
hosted components 31
overview 27
JSP pages
role of 28
K
Knowledge Base 16
L
localnode.xml file
defined 60
log files
Audit Server 49
login
Administration Console (workflow) 42
how it works 70
logging into the system (how it works) 74
workflow 83
login cache 73
login caches 55
refreshing (workflow) 77
LSI factory 77
M
Mail.txt file 55
MIME types 180
modules
how modifications are implemented 44
see also Business Objects processes
multimedia
quick tours 14
multiple clusters
starting under UNIX 63
O
offline users
of BusinessObjects in 3-tier mode 138
OLE Automation under Windows 35
Online Customer Support 15
P
PDF documents
displaying BusinessObjects files in PDF format
(workflow) 150
displaying WebIntelligence 6.x documents in
(workflow) 160
personal documents 103
saving documents as (workflows) 172
storage of 51
plug-in 26
presentation layer
defined 26
new role of application servers 26
role of ASP/JSP pages 28
processing layer 34-36
components 35
profile.txt file 55
prompts
refreshing BusinessObjects files with
(workflow) 156
refreshing BusinessObjects files without
(workflow) 155
refreshing WebIntelligence 2.x documents with
prompts (workflow) 167
without prompts (workflow) 167
refreshing WebIntelligence 6.x documents with
prompts (workflow) 162
without prompts (workflow) 161
Q
queries
creating in 3-tier BusinessObjects (workflow)
134
executing in 3-tier BusinessObjects (workflow)
136
running from HTML Report Panel (workflow)
113
running from Java Report Panel (workflow) 110
R
read.txt file 52
REBean
accessing WIAPIBroker and WIReportServer
functions 33
RECOM
as ASP system component 31
report engine
BusinessObjects (3-tier) 118
reports
displaying in BusinessObjects in 3-tier mode
(workflow) 127
reports see also documents
repositories
DSPending table 189
storage areas 51
S
S99WebIntelligence_ script 63
Save as a Corporate Document option 103
Index
207
208
Save as a personal document option 103

saving documents
as corporate documents (workflows) 169
as personal documents (workflows) 172
to a local drive (workflows) 175
Schedulers
how they process jobs (workflows) 189
overview 36
Scanning repository delay parameter 189
scheduling documents
BusinessObjects documents (workflow) 188
search
documentation 13
security
API for managing Business Objects web
security 37
see also authentication
security model 75
Send option 103
sending documents (workflows) 178
Server.openSession method 47
servlet 26
session context
when it is released 65
Session directory 83
session management 82
session stacks 38
Session.close method 48
sessions
and WIQT 82
and WISessionManager 83
defined 71
for WebIntelligence 6.x documents 95
how temporary session information is stored
51
how they are created (workflow) 83
how they are managed 70-87
termination 72
when BusinessObjects is launched from
InfoView 91
sessions directory 51
shutdown
what happens 67-68
Index
SQL
when it is used 41
stacks
see also session stacks 38
Start menu
launching BusinessObjects in 3-tier mode
(workflow) 88
start_asf.cmd command 63, 64
starting
clusters 58
startup
under UNIX (workflow) 62
under Windows (workflow) 61
what happens 57-68
storage
docs directory 53
for each cluster 52
of inbox documents 52
of personal documents 51
of temporary session information 51
system 50
Supervisor
Enable real-time user rights update option 73
support
customer 15
T
third-party files 101
adding to portal (workflow) 182
displaying (workflow) 180
how the system processes (workflows) 179
sending (workflow) 184
Tips & Tricks 14
training
on Business Objects products 15
tunneling 146, 163
U
universes
displaying in Java Report Panel (workflow) 109
opening in 3-tier BusinessObjects (workflow)
134
opening in HTML Report Panel (workflow) 112
where InfoView list of universes is stored 55
which universes can BusinessObjects use?
131
UNIX
pathnames in this guide 19
shutting system down 67
starting cluster nodes 62
starting multiple clusters 63
system startup (workflow) 62
unv.txt file 55
users
where personal data is stored 51
W
web
customer support 15
getting documentation via 13
useful addresses 16
web servers
and static web pages 26
how they are launched 60
new role 26
webi.bat script 60
webi.bat stop file 67
webi.sh script
its role in system shutdown 68
its role in system startup 63
WebIntelligence
creating documents using the HTML Report
Panel (workflow) 110
creating documents with the Java Report
Panel (workflow) 107
how documents are created (workflow) 104
HTML Report Panel 104
Java Report Panel 105
loading HTML Report Panel (workflow) 111
loading Java Report Panel (workflow) 108
required InfoView options for creating
documents 106
WebIntelligence 2.x documents see .wqy files
WebIntelligence 6.x
document sessions 95
WebIntelligence 6.x documents see .wid files
WebIntelligence HTML Report Panel see HTML
Report Panel
WebIntelligence ISAPI extensions
role of 29
WebIntelligence Java Report Panel see Java
Report Panel
WIADEServer
WIAPIBroker
and session management 82
role in InfoView processing 141-188
role in session management 82
WIBean
accessing WIAPIBroker and WIReportServer
functions 33
accessing WIAPIBroker functions 28
WIClusterManager 65
WIClusterNode 65
WICOM
accessing WIAPIBroker functions 28
as ASP system component 31
WIDispatcher
in JSP configurations 33
WIGenerator 65
Index
209
210
WILoginServer
and authentication 79
and authentication mode 79
and the Administration Console 44
and the Enable real-time user rights update
option 73
caches 55
how it works 73, 74
Windows
pathnames in this guide 19
shutting system down 67
system startup (workflow) 61
WIProcessManager
description 65
WIQT
activated for each user session 87
and InfoView processing 140-195
and sessions 82
and WebIntelligence 2.x document processing
100
and WIReportServer in .wid creation 99
interaction with BusinessObjects report engine
118
role in BusinessObjects processing 119
role in displaying .rep files in InfoView 153
role in displaying .wqy files 163
role in displaying third-party files 180
role in refreshing .wqy files 167
role in saving .rep and .wqy files 174
role in saving .rep and .wqy files to local drive
177
role in sending and saving third-party files 184
when BusinessObjects is started from Start
menu 89
WIQT Report Engine 35
WIQT Repository Access 35
WIQT SQLBO 35
WIQT Z-SQLBO 117
WIQT_batch
Index
WIReportServer
and .wid file processing 99
and WICOM/RECOM 31
in JSP configurations 33
role in creating .wid files (HTML) 110
role in creating .wid files (Java) 109
role in processing scheduled .wid files 192
WIReportServer_batch
WISessionManager 37
number of instances 38
role in session creation 83
WIStorageManager
and cluster storage 52
workflows
understanding workflow diagrams 23
wstart script
starting multiple clusters 63
who can launch it 62
wstop script
who can launch it 67
wstop-sos script 67
Z
ZABO see BusinessObjects in 3-tier mode
ZABOparaminfo.ini file 124
Zero Admin BusinessObjects see BusinessObjects
in 3-tier mode

How The BusinessObjects System Works

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

How The BusinessObjects System Works

Загружено:

Авторское право:

Доступные форматы

How the Business Objects System Works

BusinessObjects Enterprise 6.1 Business Intelligence