Bursting a WebI document with

personalized data based on universe

overloads
Skip to end of metadata
Created by Patrice Le Bihan, last modified on Nov 09, 2010
Go to start of metadata
Product versions:
SAP BusinessObjects Enterprise XI R2 and XI 3.1
SAP BusinessObjects Universe Designer XI R2 and XI 3.1
SAP BusinessObjects Web Intelligence XI R2 and XI 3.1

Table of contents

Introduction
Detailed Steps
Servers Configuration
Publication Creation
User Security
Publication Scheduling
Recipient experience once the publication completed
References and links

This article is part of a series

1. How to burst a 'dashboard like' WebI document for offline consumption

2. Example of how to map an organisation chart with the BOE security model and universe overloads
3. Bursting a WebI document with personalized data based on universe overloads
4. Use Extension Points to transform the WebI Rich Client into a Viewer only

Introduction
This article presents the steps to burst (publish) a Web Intelligence document to multiple users with
personalized data based on their security profile. We will use the security model set up in the
previous article that maps the management hierarchy of an organization. Each recipient will receive
an email with a Webi document instance as an attachment that he can then open with the WebI Rich
Client. It is important to note we rely, here, on universe overloads for data secutiry, hence will
perform a multi-pass bursting publication, as opposed to a one-pass bursting when using BOE
Profiles for the security.

Detailed Steps
 Servers Configuration
1. As a BOE administrator, ensure that you have at least one Publication Job Server, one Destination
Job Server and one Web Intelligence Processing Server running.
a. the Publication job server will handle the publication / bursting processing,
b. the Destination Job Server the communication with the mail server,
c. the Web Intelligence Processing Server the document and database query refresh.

2. Ensure the Publication Job Server has "Email" defined as a possible Destination and the connection
details to the SMTP server are correctly defined. Only the server parameters are mandatory here.
The email settings (To: , Cc:, email body, etc) can be set at a later time, when creating the
publication or even when scheduling it. You would define them :
from the the destination job server properties if you need all publications to follow the same email
template
from the publication properties if you want all publication recurring jobs to follow the same email
template
from the publication schedule properties if you want each recurring job to follow its own email
template

Publication Creation
1. As a publication author, you have access to the WebI document that will be the publication source.
From the CMC (if you are an administrator) or InfoView, go to the folder the publication will be stored
into. Recipients do not have to have access to that folder.
In the CMC, choose Manage > New >

Publication.

In InfoView, choose New > Publication

2. First, you provide a name to your publication.

3. Then, you select the Source Document(s) : that is the document(s) you will burst with personalized
data to users. We pick our "Sales Analysis Dashboard" WebI document.
4. Enterprise Recipients are recipients with a BOE account. You can select individual user IDs or group
IDs when designing your publication. In our example, all of our recipients have a BOE account and
fall under the top group "Warehouse Addicts", see previous article of this series for more details on
our security model.

5. Dynamic Recipients would be a list of users selected dynamically at runtime from a Crystal Report or
Web Intelligence document. We will not use this feature in our scenario.

6. The Personalization tab lets you specify which BOE Profiles (Global or Local) you will use to
personalize the data for each user. In our example, we will not use any filter because the data
personalization will be handled by Universe Overloads. We will do a multi-pass bursting where each
document instance will be run with the BOE user account and data filtered according to the access
restrictions defined in the universe.
You would typically use BOE Profiles with a one-pass bursting publication where the data is
retrieved once from the database and the data filtering / personalization is done within the
 publication job server.

7. We want our recipients to use the Webi Rich Client to open and view the document instances, hence
we select the Web Intelligence format.

8. Document instances will be sent by email, and recipients will receive them as attachments as .wid
files. They will automatically open in the Webi Rich Client if it is installed on the client machine. Note
that we use the placeholder %SI_STARTDATETIME% (date time the instance was started),
%SI_NAME% (instance title), %SI_USERFULLNAME% (Full Name as defined in the CMC) to
personalize the email.

9. Lastly we specify advanced settings on how the publication will run. No need to merge profile
information because we are not using them (see point above on "Personalization" tab). And Multi-
Pass bursting because we are using Universe Overloads (row-level security at the Universe level).

User Security
1. The general permission requirements are documented in the chapter 26 of the BOE XI 3.1
Administrator Guide, "Rights required for Publishing". Here are more details about user security
requirements in this scenario.
2. Permissions for recipients on...
a. the connections top-level folder: users need the ability to view objects

b. the (universe) connection: users need the ability to view and access data through the connection
object

c. the universes top-level folder: users need the ability to view objects

d. the universe:
i. Universe Security : we use the Public access for our user group

ii. User Security : users need the ability to view and access data through the universe object. Because
we manage the data personalization with universe overloads, users need permissions to edit queries
on the universe object as well. This would not be required if we were using Global Profiles for data
personalization.

e. the webi document: we want to provide users with the ability to view / interact with the document

f. the publication: because we burst the document to a set group of BOE users, we do not require the
ability for users to subscribe/unsubscribe to the publication. Also, in our scenario, the Publication
author does not belong to recipient user group, hence user permissions for the user group can be
very restricted on the publication object itself. Recipients only require the permissions "Add objects
to the folder" and "Delete objects that the user owns" on to the parent folder of the publication object
for temporary files that will be created during the publication process.
 With these settings the user will not see the Publication object when logging on to Infoview

Publication Scheduling
1. As a Publication owner, you will now schedule it from either the CMC (if you happen to also be an
administrator) or Infoview.

2. First, you set a title for your instance which can be different from the Publication name. Keep in
mind, the recipients may not even know of the publication object. Hence the publication can be
named after something only relevant to the publication owner (in my example "Sales Analysis
Dashboard Multi-Pass Bursting"). And the publication instance named after something more
meaningful for the recipients ("Sales Analysis Dashboard"). The instance title will appear in the email
every time you use the %SI_NAME% placeholder.
You also define the recurrence pattern which entirely depends on your users requirements (and
 back-end data load/update frequency).

3. From there we leave all other tabs to the default values as we want to re-use what has been defined
at the publication level (see previous paragraph). And click "Schedule".

Recipient experience once the publication completed

1. As a recipient, you will receive an email with the WebI document instance as an attachment (.wid file
if you used the %EXT% placeholder, see previous paragraph). Double click on it to open it with WebI
Rich Client.

2. WebI Rich Client opens and prompts you for a username / password. You may authenticate against
BOE XI 3.1 or not : because all the personalized data is stored in the document instance (the whole
point of bursting ), you may not need to connect to BOE to get more data. If so, choose
"Standalone more" from the Authentication drop down list.
 Note: You may want to customize WebI Rich Client to bypass the authentication screen. This is
possible by using the Extension Points, please refer to the Next Article of this series and
theExtension Points API and Samples available from the Innovation Center
3. The document is then displayed. In our example, the document has a single "dashboard like" report
with a few filters controlled by input controls and charts that fit on the screen.

Note: You may want to customize WebI Rich Client to only display the document and Input Controls
panel, and remove any other menu, button, option from the UI. This is explained in theNext Article of
this series.