BusinessObjects 6.x to XI Release 2 Migration Guide

Transcription

1 BusinessObjects 6.x to XI Release 2 Migration Guide BusinessObjects XI Release 2 SP2 Windows and UNIX

2 Patents Trademarks Copyright Business Objects owns the following U.S. patents, which may cover products that are offered and sold by Business Objects: 5,555,403, 6,247,008 B1, 6,578,027 B2, 6,490,593 and 6,289,352. Business Objects, the Business Objects logo, Crystal Reports, and Crystal Enterprise are trademarks or registered trademarks of Business Objects SA or its affiliated companies in the United States and other countries. All other names mentioned herein may be trademarks of their respective owners. Copyright 2006 Business Objects. All rights reserved. Last update: March BusinessObjects 6.x to XI Release 2 Migration Guide

3 Contents Chapter 1 Introduction 9 About this guide Part I Migration fundamentals Chapter 2 Migration essentials 13 What this guide covers What this chapter covers Tools to help you migrate Migration methods Basic XI R2 concepts you need to know Top challenges as you migrate What migrates (and what doesn t) Migration phases Chapter 3 How XI R2 compares with version 6.x 35 Where you are now Product offering Architecture Basic terminology Installation, configuration, and deployment Security model Authentication/authorization Administration Reporting, analysis, information sharing SDK BusinessObjects 6.x to XI Release 2 Migration Guide 3

4 Contents Part II Understanding what migration entails Chapter 4 Understanding user and group migration 65 Where you are now Users, groups, and their organization User/group access rights How users and groups migrate Consequences of importing users and groups Delegated Administration Migrating external groups (LDAP/Active Directory) Chapter 5 Understanding object migration 81 Where you are now What kinds of objects can be imported? Broadcast Agent Scheduler Universes and universe connections Stored procedures Folders, domains, and categories Documents Chapter 6 Understanding Application Foundation object migration 103 Where you are now Migrating to Performance Management XI R Migrating the Application Foundation repository and its contents Migrating dashboards Migrating analytics Migrating schedules Migrating rules and named events Migrating security commands What you cannot migrate Chapter 7 Understanding rights migration 121 Where you are now Security overview BusinessObjects 6.x to XI Release 2 Migration Guide

5 Comparison of the security models Standard migration paths Special import scenarios Rights by product/component Chapter 8 Understanding Import Wizard options 169 Where you are now Overview Security migration options The Merge and Update import scenarios Chapter 9 Understanding deployment configuration migration 187 Where you are now XI R2 deployment rules Migrating deployment configurations Part III Migration planning and assessment Chapter 10 Assessing migration by product and functionality 195 Where you are now BusinessObjects/Desktop Intelligence Web Intelligence Designer and universes Auditing and Auditor Scheduling and publishing SDKs Application Foundation/performance management Web Intelligence OLAP Chapter 11 Recreating security in XI R2 213 Where you are now Designing your security model Group security by functionality Content security: access to reports and universes BusinessObjects 6.x to XI Release 2 Migration Guide 5

6 Contents Security model for functionality and content combined Administrators group Chapter 12 Planning the migration 225 Where you are now Formulating your migration strategy High-level migration strategy scenarios Repository migration options Migrating to XI R2-supported versions and platforms Capturing scheduling information What users/groups should you migrate? What objects should you migrate? Setting up a new folder/group structure International considerations Cleaning up your source environment Part IV Importing to the destination environment Chapter 13 Before using the Import Wizard 255 Where you are now Before installing XI R Installing XI R Before importing Chapter 14 Using the Import Wizard 267 Where you are now Overview Launching the Import Wizard Setting the source and destination environments Selecting the types of objects to import Selecting an import scenario Importing specific objects Finalizing the import BusinessObjects 6.x to XI Release 2 Migration Guide

7 If you re migrating Application Foundation Selecting the types of objects to import Selecting an import scenario Importing specific objects Finalizing the import Part V Verifying and completing the new environment Chapter 15 Checking and adapting the new environment 297 Where you are now Overview Verifying overall import success Checking user/group and object import Checking imported documents Checking universe access restrictions Checking and adjusting security Recreating scheduling jobs Verifying the performance management environment Chapter 16 Checking for calculation updates 309 Where you are now Document conversion during import BusinessObjects document migration Part VI Appendices Appendix A Migration checklist for single pass migrations 331 Overview Preparing the source environment Preparing the destination environment Importing from the source to destination environment Post-import checking and tuning Transferring or recreating other functions and tasks BusinessObjects 6.x to XI Release 2 Migration Guide 7

8 Contents Appendix B Business Objects Information Resources 337 Documentation and information services Documentation Customer support, consulting and training Useful addresses at a glance Index BusinessObjects 6.x to XI Release 2 Migration Guide

9 BusinessObjects 6.x to XI Release 2 Migration Guide Introduction chapter

10 1 Introduction About this guide About this guide This guide describes how to migrate the BusinessObjects Business Intelligence suite from a version 6.x source environment to BusinessObjects Enterprise XI Release 2. This guide includes improvements to migration that you receive when you install the BusinessObjects Enterprise XI R2 Migration Pack. For more information and instructions on installing XI R2, see the BusinessObjects Enterprise XI R2 Installation Guide. For information and instructions on installing the BusinessObjects Enterprise XI R2 Migration Pack, see the Business Objects XI R2 Migration Pack Installation Notes. Who should read this guide This guide is intended for system administrators and IT personnel who are responsible for the migration. Business Objects information resources For more information and assistance, see Appendix B: Business Objects Information Resources. This appendix describes the Business Objects documentation, customer support, training, and consulting services, with links to online resources. 10 BusinessObjects 6.x to XI Release 2 Migration Guide

11 Migration fundamentals part

12

13 BusinessObjects 6.x to XI Release 2 Migration Guide Migration essentials chapter

14 3 Migration essentials What this guide covers What this guide covers This guide describes how to migrate from BusinessObjects version 6.x to BusinessObjects XI Release 2. This includes the migration of: the Business Objects Business Intelligence suite Application Foundation (from version 6.1b) If you have BusinessObjects Analytics and you want to migrate to Performance Management XI R2, see Understanding Application Foundation object migration on page 103 and the Recommendations for Migrating to BusinessObjects Performance Management XI R2 guide. Note: Unless more specific version numbering is required, the source version of the Business Objects suite is referred to as version 6.x throughout this guide, and the destination environment is referred to as version XI R2. Depending on the precise source version you are using, certain options and features listed in this guide may not be available. What this guide does not cover This guide does not cover: migrating from versions of Business Objects previous to version 6.0 migrating Application Foundation versions previous to version 6.x Updating or upgrading to version XI R2 from Crystal Enterprise 8 or 9, or from BusinessObjects XI, is explained in the BusinessObjects Enterprise XI R2 Installation Guide. What this chapter covers Tools to help you migrate Migration methods Basic XI R2 concepts you need to know Top challenges as you migrate What migrates (and what doesn t) Migration phases 14 BusinessObjects 6.x to XI Release 2 Migration Guide

15 Migration essentials Tools to help you migrate 3 Tools to help you migrate Import Wizard You import most of your source environment to BusinessObjects Enterprise XI R2 using a single tool called the Import Wizard. The Import Wizard is a locally installed Windows application that allows you to import most objects in the repository, including user accounts, groups, folders, universes, and documents, as well as objects stored in Inbox and personal folders on cluster servers, to your new BusinessObjects Enterprise system. The Import Wizard acts as a bridge between the source repository and the target CMS repository (InfoStore). The Import Wizard: imports content from the source repository updates content (for example, universe IDs), and converts document format where necessary (for example, version Web Intelligence 2.x.wqy documents to version XI R2 Web Intelligence.wid files, as well as version 6.x BusinessObjects.rep files into version XI R2.rep files) exports content into the target repository and physical storage area At the end of the import, the Import Wizard creates a log file you can check for information about successful operations and issues. Exactly how the Import Wizard manipulates each object, as well as how to use this wizard is fully described later on in this manual. Note: The Import Wizard imports Application Foundation objects from version 6.1b and later only. Import Wizard requirements The Import Wizard requires that you configure the following connections/ paths before import: appropriate middleware installed and correctly configured so that the Import Wizard, like Supervisor or BusinessObjects, can connect to the source repository domains ID and password to connect to the target repository database a path to Storage\Mail on the source server (optional) a path to Storage\Users on the source server (optional) BusinessObjects 6.x to XI Release 2 Migration Guide 15

16 3 Migration essentials Tools to help you migrate The Import Wizard requires: a fast hard disk (import may require a series of report Open/Save operations) extensive available disk space for temporary files created during import Because for any given import session, all documents are copied to a temporary disk space, free disk space equivalent to the size of your source repository is required, at a minimum. fast connections to both the 6.x and XI R2 systems When migrating from version 6.x, you must have: a BOMain.key file and a General Supervisor profile to be able to connect with the source repository an ID and password to connect to the destination CMS Backing up your source repository Business Objects strongly recommends backing up your 6.x source repository before beginning the migration. In addition, it is good practice to run the Import Wizard on a copy of the source repository, and not on the production version. If you follow this practice, make sure that you point all the domains to the copied repository, so that the domains are no longer associated with the original (production) repository. BIAR files The Import Wizard can also package BI content into Business Intelligence Application Resource (BIAR) format for backup or change management once you ve already imported into the new environment. For information on BIAR files, see the Import Wizard online help. The Report conversion tool Another tool, called the Report conversion tool, is also available to convert BusinessObjects documents in version 6.x to Web Intelligence documents after you import them to the destination environment. As version XI R2 supports these documents, however, this type of conversion is a deployment choice, and not an integral part of the migration process. For complete information on this tool and how to use it, see the Report Conversion Tool Guide. 16 BusinessObjects 6.x to XI Release 2 Migration Guide

17 Migration essentials Migration methods 3 For more information on how to decide what BusinessObjects documents to migrate or convert, see What objects should you migrate? on page 243. Migration methods You can migrate to version XI R2 either in a very short time frame, or in a series of incremental imports over a period of time. Whatever method you use, you will need to keep both source and destination environments deployed long enough to be able to compare and ensure that all BI content has been migrated safely and reliably. The single pass method involves migrating to version XI R2 in a single pass with the Import Wizard. This method may be more suitable for smaller, less complex deployments. The larger your deployment, the more likely you will want to migrate gradually. The incremental method allows you to migrate application by application, domain by domain, or even locale by locale, validating the import s success after each sweep with the Import Wizard; if there are issues, you don t have to begin the entire migration all over again. For more information on migration strategies, see Formulating your migration strategy on page 226. Migrating optimally using consulting Each migration has its own challenges, whether they concern a high degree of customization, the use of unusual server/web server/application server/ database configurations, or sheer size. Regardless of the size or complexity of your deployment, Business Objects recommends that you take advantage of Business Objects Global Services to assist you in determining the ideal requirements for your organization and how best to shape your initial deployment. Global Services is a team of BI experts with all the planning, delivery and standardization skills you need to drive a successful migration to the XI R2 platform. You can contact Global Services either through your Business Objects representative, or at consulting/default.asp. BusinessObjects 6.x to XI Release 2 Migration Guide 17

18 3 Migration essentials Basic XI R2 concepts you need to know Basic XI R2 concepts you need to know Chapter 2 in this guide gives you a much more detailed comparison of version 6.x and XI R2. Before going any further, however, you should understand the following key differences. The Central Management Server (CMS) The CMS is the central process in the XI R2 BusinessObjects Enterprise intelligence layer. A single service, it provides framework services, security management, administers scheduling tasks, and also is responsible for maintaining databases containing system information, the repository and the audit database. Because it maintains the repository database, all connections to the repository must pass through the CMS, including login from the full client (renamed Desktop Intelligence in XI R2). This in turn means that all XI R2 deployments include a computer hosting what in version 6.x is called Business Objects server components. The main functions of the CMS are: Coordinating communication between servers Servers use the CMS to locate the services exposed by other servers. Coordinating communication between the SDK and the backend The SDK uses the CMS to locate the services exposed by servers. Maintaining the CMS repository (InfoStore) The CMS repository is a database that stores information essential to system operation. For example, the repository keeps track of available documents, maintains security information about users and documents, and know what servers are currently available. Information is stored in the repository as InfoObjects. The main core services the CMS exposes include: InfoStore service (the repository) security and logon service deployment service, which controls plugins name server, which provides a directory of available servers The XI R2 deployment must have at least one CMS running at all times. 18 BusinessObjects 6.x to XI Release 2 Migration Guide

19 Migration essentials Basic XI R2 concepts you need to know 3 Repositories Version 6.x deployments are based upon a central repository, which is a database stored in a relational database management system. The repository is used to secure access to your data warehouse and provide an infrastructure for distributing information to be shared by users. This repository database contains the data associated with the security, universe and document domains (universes, documents, etc.). InfoObjects in the CMS In version XI R2, the repository is one of several system databases maintained by the CMS. The CMS repository stores information about the system s operation and administration, but does not store content data such as.wid files. For example, when a document is published to the repository, the meta-data about the document is stored in the CMS repository as an InfoObject, while the document itself (the.wid file) is physically stored, along with its data, in separate storage associated with the File Repository Server (FRS). InfoObjects store information like ID number, InfoObject type, and scheduling information that allows BusinessObjects Enterprise to manage each component. InfoObjects that do not have associated FRS files (that is, InfoObjects that do not represent documents, such as users or groups) contain all the information required to make the managed object functional within the system. BusinessObjects 6.x to XI Release 2 Migration Guide 19

20 3 Migration essentials Top challenges as you migrate The Central Management Console (CMC) Version 6.x relies upon a set of tools that allow you to set up and administer your BI solution, including: Supervisor/Supervisor over the Web for creating the repository and creating users and groups and their access rights the Administration Console for administering and monitoring the cluster and its components the Auditor application for auditing and analyzing system usage Broadcast Agent for the scheduled processing and distribution of documents In XI R2, a centralized web-based administration tool called the Central Management Console (CMC) provides you with a single interface through which you can perform almost every administrative task. Through the CMC, you perform user management tasks such as setting up authentication and adding users and groups. It allows you to publish, organize, and set security levels for all BusinessObjects Enterprise content, manage server processes and create process groups, and audit activity throughout the system. For more information, see the BusinessObjects Enterprise XI Release 2 Administrator s Guide. Top challenges as you migrate The security model is different The licensing model is different Domains are migrated to a single database Supported deployment configurations are different The Application Foundation repository is upgraded Post-import verification is required 20 BusinessObjects 6.x to XI Release 2 Migration Guide

21 Migration essentials Top challenges as you migrate 3 The security model is different The security model is fundamentally different in function and organization. In version 6.x The security model is user/groupcentric. For example, you select your user/ group and apply a right, such as access to a document. Aggregate and inheritance rights depend on the type of objects. Domains serve as context mechanisms. Documents are published to/stored in domains; you then assign which groups will have access to them. The same is true of universes. In version XI R2 Security is object-centric, based on ACLs. For example, you select an object such as a document or folder, and then grant access to it. Aggregate and inheritance rights are the same for all objects and are more secured than in 6.x. Each domain becomes a folder. Migrated document/universe relationships are still preserved. Documents are also stored in a container (a folder), but you no longer specify security at the time of publishing. You create a folder structure to reflect user/group access: whoever has access to the folder has access to the contents of that folder (inheritance) just like in Windows. The same is true of universes. ACLs Right values The security rules that existed in version 6.x (such as product access, objects rights, and security commands) are enforced in XI R2 by the ACL (Access Control List) mechanism. An ACL is set on an object to define what rights users and groups have on that object, and is composed of a list of ACEs (Access Control Entities), which specify the state of a single right for a single user/group. Rights can only have three values: Unspecified Denied Granted BusinessObjects 6.x to XI Release 2 Migration Guide 21

22 3 Migration essentials Top challenges as you migrate The version 6.x security command value Hidden does not exist and is mapped to the Denied value. Migrated rights If you migrate security along with users/groups and objects, migration is designed to maintain the same level of security between the 6.x and the XI R2 CMS repository. Nonetheless, rights after import may be unexpected, especially after any modification in the CMS, and if you import rights, you will need to check them carefully in the destination environment. Version 6.x Supervisor accessed both query databases and the repository using database middleware. In XI R2, Supervisor is replaced by two different tools: Designer, which allows you to manage connections and access restrictions, or universe overrides. A restriction can consist of connections, query limit controls, SQL options, object and row restrictions, and/or table mappings. The Central Management Console (CMC), which allows you to manage security on users, groups, folders, connections, universes and documents. For more detailed information on XI R2 rights and migration, see Understanding rights migration on page 121. Aggregation Aggregation is very different in the new environment. During aggregation, the more restrictive value of an instance is applied. As a result: If you set a right to Denied for a group, even if you set it to Granted for one of its members, the member won't have the right. The only way to get around this restriction is to break inheritance in the CMC. If users belongs to several groups, and if for one group they inherit a Denied value for a right, they will have a Denied value, even if they inherit the Granted value for this right from other groups. For more details, see Rights aggregation on page BusinessObjects 6.x to XI Release 2 Migration Guide

23 Migration essentials Top challenges as you migrate 3 Specific groups The following groups exist by default in XI R2: Everyone, which contains all users Administrators Universe Designers Users Report conversion tool Users The following users exist by default in XI R2: Administrator Guest Profile migration User profiles, used in version 6.x to define product access, are no longer used. In XI R2, they are replaced by ACLs for applications, folders, and documents. If you choose not to migrate security, profiles are not migrated, and therefore, General Supervisors and all other types of administrators are no longer Administrators, unless you manually grant them the necessary rights. If you choose to migrate security: General Supervisors are added to the Everyone, Administrators, and Report Conversion Tool Users groups. By default, they have most but not all rights. Users whose profiles allow them to run Supervisor (Supervisor/ Supervisor-Designer/Versatile with Supervisor access): have the View access level for the groups to which they belong in version 6.x have the Full-Control access level for the users and subgroups of the groups to which they belong in version 6.x Users whose profiles allow them to run Designer (General Supervisor/ Designer/Supervisor-Designer/Versatile with Designer access), on the other hand, are not added to the Universe Designer Users group. In the XI R2 user/group model, when users are imported into multiple groups, multiple instances of the user are not created. The user simply belongs to multiple groups. Note: For more detailed information about the implications of the Import Wizard s security migration options, see Security migration options on page 170. BusinessObjects 6.x to XI Release 2 Migration Guide 23

24 3 Migration essentials Top challenges as you migrate The licensing model is different In XI R2 the product is license model-aware. The license keys issued to you specify the type of license you can use. The product enables users access based on the license and the usage or registered number of users within the repository. For organizations migrating to XI R2 from version 6.x, two license models are available: Named user licenses are associated with specific users, and allow users to access the system based on their user name and password. Processor licenses are based on the number of processors running version XI R2. When migrating from 6.x to XI R2 you may have a named user license. In this case, the first x migrated users will be set to Named Users, where: x = (Number of users allowed by the named licenses) - (Number of users already set to Named Users) If x is greater than the number of users that must migrate, then all users will be able to login. If x is less than the number of users to migrate, then the remaining users will not be able to login; these users will not have been set to use a Named User license, and you will not have any other license model to enable these users. You can set the license model explicitly for each user within the CMC. Domains are migrated to a single database In version 6.x, domains serve as context mechanisms. For example, simply moving a document from one domain to another can result in the document being run against a production database rather than a test database. During migration, domains are migrated as folders in the CMS database, with the domain s contents stored in the corresponding folders. Even if the repository is made of several document and universe domains located in different locations, all the domains are migrated as folders in to a single CMS repository database. For more information on what happens to universes when they are migrated, see Universes and universe connections on page BusinessObjects 6.x to XI Release 2 Migration Guide

25 Migration essentials Top challenges as you migrate 3 Supported deployment configurations are different As the version XI R2 architecture differs from version 6.x, the same types of deployment configurations are not necessarily supported in the two environments. Some examples are: In 6.x, 2-tier (Desktop) deployments of BusinessObjects don t require a Business Objects server to access the repository. In XI R2 you must go through the CMS server component. In 6.x, the various repository domains can be geographically distributed over multiple sites. In XI R2, the repository databases and file systems must be in one location. For more information, see Chapter 10: Understanding deployment configuration migration. The Application Foundation repository is upgraded Objects stored in the Application Foundation repository and locally on the Application Foundation server are upgraded in the Application Foundation repository (version 6.1.b and repositories are first upgraded to version 6.5.1, then upgraded to XI R2) before being migrated to the XI R2 repository. The Import Wizard also writes new tables and columns to the Application Foundation repository during migration. Business Objects strongly recommends that you backup the repository before migrating. Post-import verification is required While importing users/groups and objects from the source deployment using the Import Wizard is simple, Business Objects recommends that you carefully check the objects you have imported for changes that may have occurred during import, and if you have chosen to migrate security, for access right levels in the new environment. Certain documents are automatically updated. In general, the older the version of BusinessObjects used to create fullclient documents you are importing, the more extensive the calculation engine changes in the reports in the new environment. For complete information, see BusinessObjects document migration on page 310. BusinessObjects 6.x to XI Release 2 Migration Guide 25

26 3 Migration essentials What migrates (and what doesn t) During import, all Web Intelligence documents in.wqy format from version 2.x are automatically converted to the version 6.x.wid format. There may be minor changes in the converted documents. For complete information, see Web Intelligence documents on page 302. What migrates (and what doesn t) This section provides an overview of: Software migration Resource migration For more details, see Assessing migration by product and functionality on page 195. Software migration Software Supervisor, Supervisor over the Web The following table presents the different products and their equivalent in XI R2 after migration. Requirements Comments Install CMC (Central Management Console), as well as Designer Most Supervisor and Supervisor over the Web tasks are carried out by the web-based CMC. Designer, however, now allows you to set the following universe-based parameters: connection overloads row restrictions size restrictions Designer Update Has incorporated some functionality previously included in Supervisor (see previous row in this table). BusinessObjects Update Renamed Desktop Intelligence. 2-tier (Desktop) mode Install side-byside + CMS (Central Management Server) install Not true for client-server in XI R2. Can install version XI R2 alongside version 6.x. You must install a CMS (Central Management Server) on the network for login, even for offline mode. Workgroup mode becomes Standalone mode, in which there is no repository connection and no repository. 26 BusinessObjects 6.x to XI Release 2 Migration Guide

27 Migration essentials What migrates (and what doesn t) 3 Software Requirements Comments 3-tier mode Update Install from CD required; no downloading from InfoView. Online and offline modes supported. Viewing through InfoView Update + rework Rework required only if InfoView was customized in version 6.x. BusinessQuery for Excel Recreate Recreate Excel worksheets with Live Office. Results may not be identical. Server software (Web Intelligence, InfoView, cluster infrastructure) On Windows Re-install On UNIX Can install side-by-side on same machine WebIntelligence Update Renamed Web Intelligence. InfoView Update Has been redesigned and integrated into the XI R2 framework. Auditor Recreate XI R2 comes with a special auditing universe and two sets of pre-defined reports (one for Web Intelligence, one for Crystal Reports) for reporting off of the Audit database, in order to report user, document, application, and server event monitoring. Broadcast Agent Update + Recreate Application Foundation (Dashboard Manager and Performance Manager) Scheduling capabilities are handled by the CMS. Renamed performance management, which includes these products: Dashboard Manager Performance Manager Set Analysis Predictive Analysis Process Analysis Process Tracker is available on a separate CD. Data Integrator Update You can re-install over the existing version. BusinessObjects 6.x to XI Release 2 Migration Guide 27

28 3 Migration essentials What migrates (and what doesn t) Software Developer Suite Custom applications Requirements Comments No longer available: Web Intelligence SDK (WIBean/WICOM) Admin SDK RECOM (MSFT is replacing COM with.net) Available: BOE SDK (Java and.net) Report viewer SDKs REBean RENET ASP pages need to be rewritten in ASPX to a new.net SDK; JSP pages based on WIBean need to be rewritten; JSP pages based on REBean still work in XI R2. 28 BusinessObjects 6.x to XI Release 2 Migration Guide

29 Migration essentials What migrates (and what doesn t) 3 Resource migration Resources Core repository Security domains Universe domains Document domains Documents BusinessObjects (.rep) VBA add-ins (.rea) Web Intelligence (.wqy) Web Intelligence (.wid) Note: Resources exclusive to Crystal Enterprise and BusinessObjects XI are not included in this table. For information on migrating from these two environments, see the BusinessObjects Enterprise Installation Guide. Migration method Comments Import Wizard Users and groups are migrated as users and groups in the CMS. Import Wizard Universe domains are imported as universe folders in the CMS. Import Wizard Document domains are imported as document folders in the CMS. Import Wizard Check the calculations in migrated documents. VBA add-ins don t work on the server in XI R2. Instead, you can use embedded VBA macros (except for VBA macros that include calls to the platform such as Login or Logout) to extend Broadcast Agent Scheduler functionality. Import Wizard As.wqy format is no longer supported in BusinessObjects Enterprise XI R2, these files are automatically converted to.wid format during import. Check the calculations in migrated documents. Import Wizard Check the calculations in migrated documents. BusinessQuery Recreate Using Live Office. Inbox Import Wizard These documents, for migrated users only, are migrated into the user s Inbox folder in the CMS. You cannot choose which Inbox documents you migrate, but you can choose to import read and/or Inbox documents and filter them by dates. BusinessObjects 6.x to XI Release 2 Migration Guide 29

30 3 Migration essentials What migrates (and what doesn t) Resources Personal Semantic layer Universes Stored procedures Connections Broadcasting Broadcast Agent Scheduler jobs Migration Comments method Import Wizard These documents, for migrated users only, are migrated into the user s Favorites folder in the CMS. You cannot choose which personal documents you migrate, but you can choose to import read and/or Inbox documents and filter them by dates. Import Wizard Restrictions are migrated and stored as InfoObjects in the CMS repository. In XI R2 they are called access restrictions (in version 6.x they were called universe overloads), and are set using Designer. Import Wizard Stored procedures are migrated as connection rights. Import Wizard When migrating, Import Wizard automatically: replaces BOUSER and BOPASS with DBUSER and DBPASS in universes proposes the automatic population of these variables for users to migrate Import Wizard or Recreate A Broadcast Agent job can be migrated from BusinessObjects Enterprise 6.x to XI R2 only if the scheduler associated to the jobs is supported in XI R2. A job can be imported only if its first action is a Refresh. A job cannot be imported if it has any of the following: multiple outputs conditional processing VBA add-ins report bursting ( refresh with the profile of each recipient ) saved in XML format 30 BusinessObjects 6.x to XI Release 2 Migration Guide

31 Migration essentials What migrates (and what doesn t) 3 Resources Broadcast Agent Publisher publications Broadcast Agent Publisher web publications OLAP Web Intelligence OLAP documents BusinessObjects OLAP documents Database migration Recreate Recreate Recreate Recreate Recreate using the CMC (Central Management Console) scheduling capabilities, or using BusinessObjects XI R2 Publisher. Recreate using Voyager. Depending on your need, recreate using Web Intelligence and OLAP universe; Crystal Reports; or Voyager. Application Foundation Application Foundation repository Import Wizard 6.1.b, through 6.5 repositories are updated in place. Analytics (.afd) Import Wizard Dependent universes are imported as well. Sets, metrics, goals, calendars Dashboards, menus, applications Role definitions in Performance Manager Migration method Updated in the Application Foundation repository Import Wizard Dependent analytics, Desktop Intelligence, and Web Intelligence are also imported. Recreate Comments Migrating to a different repository database The databases supported as repository databases in version 6.x may not be supported as CMS databases in version XI R2. Nonetheless, the Import Wizard can import objects from any supported type of source repository database seamlessly into any supported CMS repository database. BusinessObjects 6.x to XI Release 2 Migration Guide 31

32 3 Migration essentials Migration phases Migrating query databases All data access is kept from version 6.x. Connection Server is an integral part of BusinessObjects Enterprise XI R2, and all the databases it supported in version 6.x continue to be supported in the new environment. Check the latest list of supported platforms for supported driver versions. For a constantly updated list of supported platforms and versions, see: Migration phases Migration involves the following broad phases, reflected in the organization of this guide: Understanding what migration entails Assessment and planning Importing to the destination environment Post-import checking and tuning For your convenience, throughout this guide, a table at the beginning of each chapter summarizes the overall migration process in numbered steps, and indicates where you are in it. The rows in blue are the steps described in the current chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Understanding what migration entails Before you install BusinessObjects XI R2, you should understand what the migration process entails, how the new environment differs, what happens during migration, and what you should expect once you get there. Business Objects highly recommends that you read this chapter, as well as the following chapters carefully: 32 BusinessObjects 6.x to XI Release 2 Migration Guide

33 Migration essentials Migration phases 3 For a high-level understanding of how BusinessObjects XI R2 differs from your source environment, read How XI R2 compares with version 6.x on page 35. To understand how different components and characteristics of your Business Intelligence deployment are migrated from one environment to the other, as well as specific migration constraints, read carefully: Understanding user and group migration on page 65 Understanding object migration on page 81 Understanding Application Foundation object migration on page 103 Understanding rights migration on page 121 Understanding Import Wizard options on page 169 Assessment and planning Migration assessment and planning means calculating precisely what is required to migrate to the new environment given your particular source deployment, and the parts of it you want to migrate to XI R2. Familiarize yourself with what migration requires given the version from which you are migrating, and the products/functionality you want to migrate. This chapter also details the differences you can expect in XI R2 for each component you want to migrate. See Assessing migration by product and functionality on page 195 Understand the basic deployment configuration rules for XI R2, and what it takes to migrate from your version 6.x deployment configuration. See Understanding deployment configuration migration on page 187. Understand how your choice of migration method impacts your migration workflow. In addition, assess your source environment to streamline migration, by calculating the platform and version changes you will need to implement and pinpointing obsolete or unused universes and documents to be excluded from migration, and whether some documents would be more appropriate converted into or re-written in another format available in the destination environment. See Planning the migration on page 225. Importing to the destination environment Before you use the Import Wizard to import your BI solution to BusinessObjects XI R2, you must perform certain tasks such as: BusinessObjects 6.x to XI Release 2 Migration Guide 33

34 3 Migration essentials Migration phases backing up source content, whether it be stored in the repository, on cluster servers, or locally setting up the database to be used as a repository in the new environment if it isn t done already, installing version XI R2 on both client and server machines starting the required services to get the new system up and running if you aren t importing for the first time, backing up the destination CMS after each incremental import See Before using the Import Wizard on page 255. Full instructions for using the Import Wizard to import your BI content from version 6.x to XI R2 are included in Using the Import Wizard on page 267. Post-import checking and tuning This phase includes analyzing the Import Wizard log file to verify the import, then manually checking and if necessary, tweaking, the objects imported into the new environment. This is also when you can transfer or recreate functions or tasks not covered by the Import Wizard, such as reconstructing document schedules, replicating customization, and recreating the precise international environment you require. See Checking and adapting the new environment on page 297 and Checking for calculation updates on page BusinessObjects 6.x to XI Release 2 Migration Guide

35 How XI R2 compares with version 6.x chapter

36 4 How XI R2 compares with version 6.x Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails Product offering (6.x vs XI R2) Architecture (6.x vs XI R2) Basic terminology (6.x vs XI R2) Installation, configuration, and deployment (6.x vs XI R2) Security model (6.x vs XI R2) Authentication/authorization (6.x vs XI R2) Architecture (6.x vs XI R2) Reporting, analysis, information sharing (6.x vs XI R2) Administration (6.x vs XI R2) SDK (6.x vs XI R2) 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Product offering Here is a list of the applications in each version s offering. Although the applications in each row belong to the same area of functionality, those in the BusinessObjects 6.x column and those in the BusinessObjects XI R2 column are not necessarily equivalent: In BusinessObjects 6.x Designer Supervisor Supervisor over the Web In BusinessObjects XI R2 Designer Business View Manager Central Management Console 36 BusinessObjects 6.x to XI Release 2 Migration Guide

37 How XI R2 compares with version 6.x Architecture 4 Architecture Administration Console Auditor BusinessObjects 6.x In BusinessObjects 6.x InfoView BusinessObjects BusinessQuery Web Intelligence Web Intelligence for OLAP Data Sources Broadcast Agent Developer Suite Set Analyzer In BusinessObjects XI R2 Central Configuration Manager (CCM) Central Management Console (CMC) Auditing is incorporated in the Central Management Console. It is not strictly equivalent to version 6.x Auditor. InfoView Desktop Intelligence Live Office Web Intelligence OLAP Intelligence OLAP Intelligence Designer You publish from InfoView and administer publishing in the CMC. Developer Suite Part of Performance Management Applications (formerly Application Foundation) In version 6.x, the Application Foundation and Data Integrator applications complemented the Business Intelligence suite. With version XI R2, Application Foundation has been renamed Performance Management and is part of the suite. Data Integrator is also part of the XI R2 offer but is installed separately. The overall architecture of the two server systems is organized in a similar manner. BusinessObjects 6.x is organized into five logical layers: The client tier contains products or features that run on the end-user s computer (either as a standalone application or in the web browser). BusinessObjects 6.x to XI Release 2 Migration Guide 37

38 4 How XI R2 compares with version 6.x Architecture The presentation layer contains the third-party web and application servers, as well as the Business Objects components hosted on them (server SDKs, portal pages, servlets, WIDispatcher, and HSAL). The application services layer provides the essential framework and services to the processing layer, such as WISessionManager, WILoginServer, and WIStorageManager. The processing layer contains report engines, as well as the additional components that implement business logic (portal workflows, repository access, scheduling, etc.). The database tier is made up of the databases containing the data used in documents and reports. BusinessObjects XI R2 BusinessObjects Enterprise XI R2 is organized into five tiers: The client tier contains client applications. The application tier includes the web and application servers, as well as the Business Objects components hosted on them. 38 BusinessObjects 6.x to XI Release 2 Migration Guide

39 How XI R2 compares with version 6.x Architecture 4 The intelligence tier manages the XI R2 system, maintaining security information, routing requests to the appropriate processing layer services, managing audit information, and storing report instances for rapid report viewing. The processing tier accesses the data and generates reports. This layer contains fewer servers, or processes, than the BusinessObjects 6.x processing layer. Transactional workflows are therefore simplified, with each server processing requests for a specific type of object. In a BusinessObjects 6.x context, this corresponds to a dedicated role such as WIReportServer, which processes Web Intelligence 6.x reports only, rather than a provider of shared services such as WIQT, which plays a shared role in several types of processing workflows. The data tier is made up of the databases containing the data used in reports. BusinessObjects 6.x to XI Release 2 Migration Guide 39

40 4 How XI R2 compares with version 6.x Basic terminology Basic terminology The following table shows some of the main differences in terminology between the two releases. In BusinessObjects 6.x In BusinessObjects XI R2 Repository The BusinessObjects 6.x suite uses a The repository exists here as well, as one of the repository a database that is stored in a databases maintained by the Central relational database management system. Management Server (CMS). The CMS is the The repository is used to secure access to central service/process in the XI R2 system (see your data warehouse and to provide an its entry further along in this table). infrastructure for distributing information to be shared by users. The repository database actually contains the data associated with the security, universe and document domains. Making sure the repository database has enough space is therefore critical. Repository domains The repository must have a security domain. It can also contain universe and document domains. Modules Processes used in Business Objects transactions which can be configured through the Administration Console are called modules. Although the repository database stores specific information about the objects published to it, including users, servers, security, groups, folders, categories and parameters, it does not actually store physical copies of the objects; it also contains pointers to the physical objects, such as Desktop Intelligence.rep files, Web Intelligence.wid files, Crystal Reports.rpt files, universe files and third-party documents, stored in a file system associated with the File Repository Servers (FRS). When universe and document domains are imported from a version 6.x deployment, they are made into folders in the CMS database. Although the security domain itself is not imported, you can import its contents (user rights, etc.). Servers Processes in the XI R2 system are called servers. They run as services under Windows, and as processes under UNIX. The CMC s ability to enable/disable and even group servers, for example, concerns processes, not actual Business Objects servers, or server machines. 40 BusinessObjects 6.x to XI Release 2 Migration Guide

41 How XI R2 compares with version 6.x Basic terminology 4 In BusinessObjects 6.x A few examples of modules are: Broadcast Agent Manager (which manages Schedulers) WIStorageManager WIReportServer Business Objects servers At a minimum, the Business Objects server back-end must be installed on the cluster s primary node and all secondary nodes. This installs all the processing layer modules on the server machines. Clusters A cluster is one or more Business Objects servers which provide the functional processing for a given BI portal. Each server hosts the entire set of Business Objects modules, not all of which must necessarily be activated. For versions 6.1 and later, the Session Stack must be activated in order for the server to contribute to cluster processing. When a cluster contains more than one server machine, it is called a distributed deployment. In BusinessObjects XI R2 The main server in BusinessObjects Enterprise XI R2 is the CMS. Some examples of other servers are: Job Server File Repository Servers Desktop Intelligence Report Server Web Intelligence Report Server Central Management Server (CMS) The CMS is a single service which provides framework services, security management, administers scheduling tasks, and also is responsible for maintaining the database (CMS database) containing system information, such as users/groups, security levels, and services. In addition it maintains the repository and audit databases. The CMS is the main process in the BusinessObjects Enterprise intelligence layer. Disabling the CMS is roughly equivalent to disabling the Session Stack (starting with version 6.1, the set of core processing modules enabled or disabled as a group). CMS clusters A Central Management Server cluster (CMS cluster) consists of two or more CMSs working together to maintain the system databases and repository. The CMSs can be on the same machine or on different ones. This means that at a minimum only the CMS component must be installed and activated on the machine. Other processes (servers) can be installed and run on other machines. A CMS cluster is called an expanded deployment. BusinessObjects 6.x to XI Release 2 Migration Guide 41

42 4 How XI R2 compares with version 6.x Basic terminology In BusinessObjects 6.x Clusters can contain the following elements: The primary node serves as the central coordinator among all the nodes in the cluster. There is one and only one primary node in a cluster; if the cluster contains only one node, it is a primary node. Optional secondary nodes run the ORB components required to communicate with the primary node and start Business Objects processes on the secondary node(s), as well as optional services. Both primary and secondary nodes are considered cluster nodes. BusinessObjects WebIntelligence Application servers Broadcast Agent WIReportServer Corporate document domains Personal document domains File Watcher allows the processing of a scheduled task only when a specified file is present in a specified location. In BusinessObjects XI R2 The distinction between primary and secondary nodes does not apply. When you add a new CMS to a deployment containing a previously-installed CMS, you instruct the new CMS to connect to the existing CMS database and to share the processing workload with any existing CMS machines. By default, the new cluster is given the name of the first installed CMS, prefaced Desktop Intelligence Web Intelligence Web application servers Scheduling functions are handled by the CMS, which instructs the Job Server to process the job on a schedule managed by the CMS. Web Intelligence Report Server Public folder Favorites folder The Event Server manages file-based events. Schedule-based and custom events, on the other hand, are managed by the CMS. 42 BusinessObjects 6.x to XI Release 2 Migration Guide

43 How XI R2 compares with version 6.x Basic terminology 4 In BusinessObjects 6.x Profiles Supervisor provides several standard profiles, or roles, for the users of Business Objects products. The user profile determines by default what products a user can use: General Supervisor (all products) Supervisor (all products) Designer (all products but Supervisor and Supervisor over the Web) Supervisor-Designer (all products) User (all products but Designer, Supervisor, and Supervisor over the Web) Versatile (configurable) Universe overloads In BusinessObjects XI R2 Defined in the CMC, profiles let you personalize the scheduled publication of reports for groups of recipients. Users with defined profiles applied to the publication will have the publication personalized for them. In the source environment, this is called report bursting. Universe access restrictions BusinessObjects 6.x to XI Release 2 Migration Guide 43

44 4 How XI R2 compares with version 6.x Installation, configuration, and deployment Installation, configuration, and deployment The following table provides an overview of key differences in installation, configuration, and deployment. In BusinessObjects 6.x Server operating systems Version 6.x supports heterogeneous clusters, in which Business Objects servers are hosted on Windows and UNIX machines. Initial installation options Desktop Server Custom Distributed deployments To distribute processing, you add additional cluster nodes to a cluster. To add a cluster node, you must install Business Objects server on the node machine. This installs the entire set of processes required for system processing on each machine. At a minimum, the Session Stack must be activated on each cluster node to share the transaction load. In BusinessObjects XI R2 The CMS servers in an XI R2 cluster must all be running on machines running the same operating system and version. The other servers in the intelligence layer, however, such as the Job Server, can be hosted on machines running completely different (but supported) operating systems. Client Server The Server option provides three installation options: New Expand Custom You can distribute a single deployment s transactional capabilities on the same machine by creating multiple instances of a server, or you can install on additional machines to distribute the load. This capability offers you the ability to scale your system vertically (more services on the same machine) or horizontally (more machines). The CMS does not need to run on each machine. 44 BusinessObjects 6.x to XI Release 2 Migration Guide

45 How XI R2 compares with version 6.x Installation, configuration, and deployment 4 In BusinessObjects 6.x Installation and the repository Repository creation is completely independent of the installation of Business Objects software. Command-line installation Application servers Application servers communicate with the Business Objects cluster through the ORB. If the application server is hosted on a machine which is neither a primary nor secondary node, you must configure the ORB on it in order to allow it to communicate with the cluster. You configure the ORB on the application server machine either by installing the Configuration Tool on that machine, then using it to configure the server as a client node of the cluster, or by configuring the ORB manually. In BusinessObjects XI R2 Setting up the CMS database, which includes the repository, is an integral part of BusinessObjects Enterprise installation. In a New server installation, if you do not choose to connect the CMS to an existing database, the installation procedure automatically installs and configures MySQL. After installation, you can select or create a new CMS database at any time using the Central Configuration Manager (CCM). Silent installation You must install a Web Component Adapter (WCA) on any machine hosting an application server. The WCA allows your application server to run applications making Crystal Web Requests, and to host the CMC. Not all applications require the WCA. For example, InfoView doesn t need it unless users will be viewing OLAP Intelligence documents. Installing XI R2 on the same machine as the application server is called a server-side installation. When you perform this installation, the client and server components are installed, the default user and group accounts are created, and the sample reports are published to the system. When the installation is complete, the servers are started as services on the local machine. For information on deploying web applications on application servers, see Deploying web applications on page 47 in this table. Web servers To configure the web server to work with a cluster, you must install a third-party connector to the cluster s application server. For information on deploying web applications on application servers, see Deploying web applications on page 47 in this table. If you connect BusinessObjects Enterprise to a web server, the Web Component Adapter (WCA) must be installed on the same machine. BusinessObjects 6.x to XI Release 2 Migration Guide 45

46 4 How XI R2 compares with version 6.x Installation, configuration, and deployment In BusinessObjects 6.x For information on deploying web applications on web servers, see Deploying web applications on page 47 in this table. Licenses Before installation, you copy your license file(s) to a directory to which all nodes or application client machines have access. During installation, you specify where these XML files are located. OLAP You install Web Intelligence for OLAP Data Sources using the standard installation process. Configuring clusters and the ORB You create clusters and configure their ORB on their nodes using the Configuration Tool. You configure the cluster s primary node and then its secondary nodes. In BusinessObjects XI R2 For information on deploying web applications on web servers, see Deploying web applications on page 47 in this table. License key strings, different from version 5.x license strings, are stored in the CMS database. You can view your deployment s current license keys, as well as add or delete them, using the CMC. OLAP Intelligence is installed from the standard installation CD. When you install the first Central Management Server (typically a New install), you don t have to define a cluster. In subsequent installs, you are asked if the CMS is part of the cluster, and at that time, the cluster is created. Available web applications Administration Console InfoView Auditor Supervisor over the Web Custom web applications developed using the SDK Although not part of the BusinessObjects 6.x suite, Application Foundation applications can also be deployed. Central Management Console InfoView Performance Manager applications (formerly Application Foundation), J2EE only Custom web applications developed using the SDK 46 BusinessObjects 6.x to XI Release 2 Migration Guide

47 How XI R2 compares with version 6.x Installation, configuration, and deployment 4 In BusinessObjects 6.x Deploying web applications You can deploy web applications in three ways: If you re using IIS or Tomcat/Apache, the Configuration Tool can deploy the applications automatically on web and application servers. You can use the wdeploy tool, a command-line utility that you can run on all other supported application and/ or web servers. You can manually deploy the application on all other supported web and/or application servers. You can choose to deploy web applications in two modes: Distributed mode means deploying the applications static resources on the web server, and dynamic resources on the application server. Standalone mode means deploying all the applications resources on the application server. Repository creation You create the repository after installation and configuration, using the Supervisor application. After repository creation, you must copy the bomain.key file corresponding to the repository on each node in the cluster. In BusinessObjects XI R2 If you choose a New installation and are using IIS or Apache/Tomcat, the Business Objects web applications are deployed automatically on the application server, unless you are deploying to an existing Java application server. Otherwise, you must deploy web applications manually. For information, see the BusinessObjects XI Release 2 Installation Guide. In XI R2 you deploy all the web applications resources on the web application server. If you do not have a supported database client on the machine, installation can install and configure mysql for use as the CMS database. To use your own database server, you must create a new, empty database on your database server prior to running the installation. This database will be configured during the install. Whenever you add a new CMS to a cluster in an Expand installation, you define the connection to the initial CMS s database. This allows the server to connect to it. BusinessObjects 6.x to XI Release 2 Migration Guide 47

48 4 How XI R2 compares with version 6.x Security model In BusinessObjects 6.x Multiple service instances In BusinessObjects 6.x, certain modules such as WIQT, BusinessObjects.exe (Windows)/bolight (UNIX), Connection Server, and WIReportServer, are designed to be multi-instance on cluster nodes. You use the Administration Console to set the number of instances in each process pool. BusinessObjects 6.5 also supports multiple Business Objects servers on the same UNIX box. Unicode databases The use of Unicode databases, which can store information in different languages and centralize all the information in a company, is supported as a data source for Web Intelligence reports. Unicode databases are not supported for repositories or BusinessObjects documents. Security model In BusinessObjects XI R2 BusinessObjects 6.x applications use a very different security model than that provided with BusinessObjects Enterprise XI R2, and as such, administrators of BusinessObjects 6.x systems are encouraged to read Understanding rights migration on page 121 with attention. Authentication/authorization Multiple instances of the same service can run on the same machine (providing vertical scaling), or on separate machines (for horizontal scaling), in any mixture of supported operating systems. The single exception is the Central Management Server, which must run on the same operating system within a single cluster. All CMS databases must support the Unicode protocol. Desktop Intelligence can use Unicode data sources. Through BusinessObjects 6.5.1, authentication is defined for an entire cluster and/or all desktop users. Implementing an authentication method is broken down into selecting an authentication mode, then its source, which can be Repository, External then Repository, or External. You can choose between Microsoft AD or an LDAP user management system for external authentication sources. 48 BusinessObjects 6.x to XI Release 2 Migration Guide

49 How XI R2 compares with version 6.x Authentication/authorization 4 In version XI R2, security is much more granular. You implement an authentication method for each user, when you create the user s account. When users log into the system, they specify their username and password, but may enter their authentication method as well. In BusinessObjects 6.x In BusinessObjects XI R2 bomain.key The bomain.key file tells Business Objects There is no bomain.key file. At login, the Central applications where to find the repository s management Server (CMS) verifies the user security domain. name and password against the security information stored in the CMS database. Each CMS is configured either at installation or subsequently using the Central Management Console (CMC) to connect to a specific database. Setting the authentication and authorization methods You set authentication/authorization for the entire cluster, using the Administration Console. You set authentication for 2-tier deployments of BusinessObjects in Supervisor. Configuring authentication and authorization You set authentication/authorization for the entire cluster. You select the authentication method for each user at the creation of the user s account, using the CMC. You can assign multiple aliases, or authentication modes, to a single user, or create new aliases then assign them to exiting users in the system. If you import external users via LDAP, Windows NT or Active Directory, users are automatically created. So if you are not using complex scenarios in which users can log on with both NT and LDAP authentications, you don t need to create the settings for each user individually. You configure authentication in the Authentication management area of the CMC. BusinessObjects 6.x to XI Release 2 Migration Guide 49

50 4 How XI R2 compares with version 6.x Authentication/authorization In BusinessObjects 6.x In BusinessObjects XI R2 Available authentication modes These options differ according to the version of your source software. Business Objects, or Business Objects standard Windows NT, Windows authentication, or Windows-NTLM Single Sign-On Basic authentication (user authentication is delegated to the web server) No authentication Single Sign-On (SSO) To enable SSO in version 6.x, you must use Netegrity SiteMinder. Authorization You can use security commands in Supervisor to restrict user and group access to functionalities in Business Objects products. You cannot restrict access at the object level. For example, if you grant a group the right to refresh, but not create documents, the restriction will apply regardless of the documents being used. Enterprise authentication (automatically enabled when you install the system, and similar to Business Objects standard in version 6.x) Windows NT authentication LDAP authentication Windows AD authentication Other authentication modes are available through add-in products, such as SAP authentication. Single Sign-On is not a mode in itself, but is available for certain authentication modes. See below. Single Sign-On to BusinessObjects Enterprise XI R2 can be provided through the use of third-party systems such as Windows AD or Netegrity SiteMinder. End-to-end single sign-on includes SSO to the database at the back-end. Note: If you use SiteMinder, you must use LDAP for external user management. Because of the use of Access Control Lists (ACL), an industry standard method of controlling cascading security access, the imposition of restrictions is much more granular. You can apply user, group, and role level security at the object level, to documents, categories, folders, universes, and connections. This means, for example, that you could allow a group to refresh document A, but not refresh document B. 50 BusinessObjects 6.x to XI Release 2 Migration Guide

51 How XI R2 compares with version 6.x Administration 4 Administration The administrative model applied to BusinessObjects Enterprise XI R2 is very different from the BusinessObjects 6.x model. The Central Management Console (CMC) The CMC allows you to perform user management tasks such as setting up authentication and adding users and groups. It also allows you to publish, organize, and set security levels for all of your BusinessObjects Enterprise Enterprise content. Additionally, the CMC enables you to manage servers and create server groups, whenever the Central Management Server (CMS) is running. The Central Configuration Manager (CCM) The CCM is a server-management tool that allows you to view and configure each of your BusinessObjects Enterprise server components while Business Objects servers are offline. This tool allows you to start, stop, enable, and disable Business Objects servers, as well as view and configure advanced server settings. On Windows, these settings include default port numbers, CMS database and clustering details, SOCKS server connections, and more. In addition, on Windows the CCM allows you to add servers to, or remove servers from your BusinessObjects Enterprise system. The CCM comes in two forms. In a Windows environment, the CCM allows you to manage local and remote servers through its Graphical User Interface (GUI) or from a command line. In a UNIX environment, the CCM shell script (ccm.sh) allows you to manage servers from a command line. At first, the CCM takes into account only the servers running locally. You can then connect to servers on a remote machine. This section covers administrative tasks concerning the repository, users and groups, universes, server and cluster management, and auditing. For more information, see the BusinessObjects Enterprise XI Release 2 Administrator s Guide. BusinessObjects 6.x to XI Release 2 Migration Guide 51

52 4 How XI R2 compares with version 6.x Administration In BusinessObjects 6.x In BusinessObjects XI R2 Repository creation and management You create your cluster s repository after Business Objects installation and configuration, using the Supervisor application. User/group creation and management You use Supervisor or Supervisor over the Web. An initial General Supervisor account is created when you create the repository. A company name group is automatically created at repository creation. License key management Before installation, you copy your license key to a directory to which all nodes or application client machines have access. During installation, you specify where these XML files are located. If you do not have a supported database client on the machine, installation can install and configure mysql for use as the CMS database. To use your own database server, you must create a new, empty database on your database server prior to running the installation. This database will be configured during the install. Whenever you add a new CMS to a cluster in an Expand installation, you define the connection to the initial CMS s database. This allows the server to connect to it. You use the CMC. By default, Administrator and Guest accounts are created at installation. Two default groups are automatically created at installation: Administrators contains users that have administrative rights. Everyone contains all users created in the system. If you re using Windows NT/2000, an additional group called Business Objects NT Users is also created. Two additional groups are also created for user administration: Designer Users, used to administrate Designers Report conversion tool Users License keys are stored in the CMS database. You can view your deployment s current license keys, as well as add or delete them, using the CMC. 52 BusinessObjects 6.x to XI Release 2 Migration Guide

53 How XI R2 compares with version 6.x Administration 4 In BusinessObjects 6.x Using Designer You can use Designer in online or offline mode. Cluster start/stop Under Windows, you can use WINotify or the Start menu; during installation, you can also set the Business Objects server to run automatically as a Windows service. Under UNIX, you start the cluster manually using the wstart command, or use S99WebIntelligence to start it automatically on machine startup. You can use Designer in online or standalone mode, which is equivalent to offline mode in version 6.x. You use the CCM to stop a Central Management Server (CMS), regardless of the operating system. At installation, you can also configure the server to start automatically at machine startup. Note: You cannot use the Central Management Console (CMC) to stop a CMS. Cluster server enable/disable You use the Administration Console. In Windows, you use the Central Configuration Manager (CCM) to disable a Central Management Server (CMS). In UNIX, you use the ccm.sh script. Caution: You can use the CMC to disable/enable and even group servers, but this refers to what BusinessObjects 6.x users refer to as modules, not the actual cluster nodes. Server settings management You use the Administration Console. Audit management You use the Audit facility in the Administration Console. You can also use the Auditor application for enhanced system monitoring and analysis. In BusinessObjects XI R2 You use the Central Management Console or the Central Configuration Manager, depending on the type of setting you want to define, and whether you are online or offline. You use the CMC. You can also use the CMC to view server metrics, including information about the machine that the server is running on its name, operating system, total hard disk space, free hard disk space, total RAM, number of CPUs, and local time. The CMC allows you to configure what information you want each server/service to audit. BusinessObjects 6.x to XI Release 2 Migration Guide 53

54 4 How XI R2 compares with version 6.x Administration In BusinessObjects 6.x Setting up scheduling You create and manage schedulers using the Broadcast Agent Manager s Properties page in the Administration Console. Viewing scheduled tasks You can view the full list of scheduled documents and their status using the Broadcast Agent Console. InfoView appearance and functionality management You can use Supervisor security commands to prevent users from modifying the default settings in the InfoView Options page. Setting locale You set the cluster s language at installation; you can subsequently use the Site Properties tab in the Administration Console to modify it. Users can set the language of their interface in InfoView. In BusinessObjects XI R2 Because the scheduler is incorporated into the CMS, scheduling comes automatically with BusinessObjects Enterprise XI R2 and requires little or no additional configuration beyond setting up access to servers, printers and file servers. You cannot view a global list of scheduled jobs. You can view the status of one scheduled object at a time in the CMC in the object s History page. This list includes all scheduled jobs for the object, as well as existing instances of the object (i.e. reports that have already been run and contain data). In InfoView, you can also view a list of an object s instances by looking at the object s history. A sample application built using the Administration SDK and available from the BusinessObjects Enterprise User s Launchpad also allows you to see all the jobs scheduled by any specific user. You can modify the appearance and some functionality using the BusinessObjects Enterprise Applications management area in the CMC. You don t specifically set the CMS locale. Users set the locale for their own interface in InfoView; if they don t, InfoView uses the locale specified on the web server. 54 BusinessObjects 6.x to XI Release 2 Migration Guide

55 How XI R2 compares with version 6.x Reporting, analysis, information sharing 4 Reporting, analysis, information sharing This section includes information on available reporting tools, as well as enduser tasks such as accessing, distributing and scheduling corporate data. In BusinessObjects 6.x Reporting tools BusinessObjects Web Intelligence Web Intelligence for OLAP Data Sources What reporting tools use universes? BusinessObjects Web Intelligence InfoView InfoView is a web application that must be deployed after Business Objects installation using the Configuration Tool, wdeploy, or manual procedures. It is available in JSP and ASP platforms. In BusinessObjects XI R2 Crystal Reports Desktop Intelligence OLAP Intelligence Web Intelligence Crystal Reports Desktop Intelligence Web Intelligence Crystal Reports can also connect directly to databases using a variety of methods including ODBC and native drivers, as well as XML and text files. It can also use Business Views (the semantic layer from Crystal Enterprise) as a data source. The out-of-the-box portal in BusinessObjects Enterprise XI R2 is also called InfoView. Available for both Java and.net platforms, its interface is somewhat different from the BusinessObjects 6.x application. BusinessObjects 6.x to XI Release 2 Migration Guide 55

56 4 How XI R2 compares with version 6.x Reporting, analysis, information sharing In BusinessObjects 6.x Categories Within InfoView, you can use categories to organize documents on a particular document list page. There are two kinds of categories: Corporate Personal Corporate categories can be created from InfoView, BusinessObjects, or Supervisor. As a general supervisor or supervisor, you can grant specific users or groups the right to create categories, and to rename and delete the categories they create, from BusinessObjects or Web Intelligence. You do this by enabling the security command Manage All Categories or Manage My Categories. You can use security commands to restrict access to corporate categories. In BusinessObjects XI R2 BusinessObjects Enterprise XI R2 uses both categories and folders to organize documents. Folders are used for the storage location of information, while categories are used more for the classifying information regardless of its storage location. BusinessObjects Enterprise XI R2 automatically creates a folder for each user in the system, called Personal Folders. These folders are organized within the CMC as User folders. Within InfoView, these folders are called Favorites folders. Folders are created and managed from the CMC. Categories are equivalent to BusinessObjects 6.x categories. Folders contain actual copies of objects, while categories simply point to objects. There are two types of categories: Corporate Personal Corporate categories can be created either in InfoView (with reduced management capabilities) or from the CMC (full management capabilities). In the CMC you can restrict users and/or groups access to categories and folders. You can set limits on folders, which automate regular clean-ups of old Business Objects content by eliminating excess instances of particular objects, or object instances which have remained more than the specified number of days in the folder. 56 BusinessObjects 6.x to XI Release 2 Migration Guide

57 How XI R2 compares with version 6.x Reporting, analysis, information sharing 4 In BusinessObjects 6.x Scheduling You schedule for refresh documents and files either from 2-tier deployments of BusinessObjects, or from InfoView. You can schedule: BusinessObjects documents Web Intelligence documents Web Intelligence OLAP reports In BusinessObjects XI R2 You schedule for refresh objects using the Publishing Wizard, from the CMC or from InfoView. You can schedule: Crystal reports OLAP Intelligence reports Web Intelligence documents Desktop Intelligence documents You can also schedule program objects, such as executables, Java programs, or scripts (Jscripts and VBscripts) to run at specified times. Note that customized code is not supported by Business Objects Support. BusinessObjects 6.x to XI Release 2 Migration Guide 57

58 4 How XI R2 compares with version 6.x Reporting, analysis, information sharing In BusinessObjects 6.x In BusinessObjects XI R2 Publishing to the repository You add objects to the repository by: Exporting universes from Designer or Supervisor Adding users and groups and managing security settings from Supervisor and/or Supervisor over the Web Saving documents to the repository from InfoView Publishing documents from 2- and 3-tier deployments of BusinessObjects You can publish objects to BusinessObjects Enterprise in several ways. Use the Publishing Wizard when you: Have access to the locally installed application. Are adding multiple objects or an entire directory. The Publishing Wizard is a locally installed Windows application that enables both administrators and end users to add any supported document to BusinessObjects Enterprise. The Publishing Wizard does not take into account legacy Business Objects objects, such as Desktop Intelligence documents, Web Intelligence documents, and universes. Use the CMC when you are: Publishing a single object. Taking care of other administrative tasks. Performing tasks remotely. Save directly to your Enterprise folders when you are: Designing reports with Crystal Reports or Web Intelligence. Using the OLAP Intelligence Application Designer. Creating other objects with BusinessObjects Enterprise plug-in components. Upload documents stored on your local computer when you re using InfoView. Use Designer to export universes to the repository. Use the Import Wizard to migrate objects to an XI R2 repository from BusinessObjects 5/6. 58 BusinessObjects 6.x to XI Release 2 Migration Guide

59 How XI R2 compares with version 6.x SDK 4 SDK In BusinessObjects 6.x SDK or module... BusinessObjects SDK (macros and add-ins) Web Intelligence SDK (scripts) Used to customize/ extend... BusinessObjects, Designer, the Report Viewer component Web Intelligence, InfoView Administrator SDK Users and groups in a strictly controlled environment Web Services Set of web service applications based on the.net and J2EE frameworks and on InfoView Using this language/ platform... Visual Basic for Applications ASP, JSP JSP.NET, Java (REBean) BusinessObjects 6.x to XI Release 2 Migration Guide 59

60 4 How XI R2 compares with version 6.x SDK In BusinessObjects Enterprise XI R2 SDK or module Description Using this language/ platform BusinessObjects Enterprise SDK.NET Server Controls for BusinessObjects Enterprise Report Application Server SDK Viewers SDK Includes libraries for building a web report delivery tool. Lets users log on to the BusinessObjects Enterprise system, create objects (folders and reports), and to view, schedule and export reports Set of libraries that allow you to use visual and nonvisual components to design and implement BusinessObjects Enterprise web applications that use the.net framework. Includes libraries for building a web report design tool. Lets users create new reports or modify existing ones by adding, removing, and modifying objects, such as tables, charts, and fields. Includes libraries for building customized thinclient report viewers that display web-based reports. Also provides an interface to programmatically export Crystal Reports to a variety of other formats. Microsoft Visual Studio.NET, Java, COM Microsoft Visual Studio.NET Microsoft Visual Studio.NET, Java, COM Java, COM 60 BusinessObjects 6.x to XI Release 2 Migration Guide

61 How XI R2 compares with version 6.x SDK 4 SDK or module Description Using this language/ platform Crystal Reports SDK Desktop Intelligence SDK Designer SDK Web Intelligence SDK Unified Web Services Consumer SDK For customizing and extending Crystal Reports. Includes.NET libraries for building customized report viewers that display web and Windows form-based reports. For customizing and extending Desktop Intelligence; almost identical to version 6.x BusinessObjects SDK For customizing and extending Designer; almost identical to version 6.x Designer SDK For customizing and extending Web Intelligence Set of services that allow you to create Business Objects Web Service consumer applications that manage sessions, create custom queries, manage documents, and perform listing and publishing actions. Microsoft Visual Studio.NET Visual Basic for Applications Visual Basic for Applications REBean, RE.NET Microsoft Visual Studio.NET, Java BusinessObjects 6.x to XI Release 2 Migration Guide 61

62 4 How XI R2 compares with version 6.x SDK 62 BusinessObjects 6.x to XI Release 2 Migration Guide

63 Understanding what migration entails part

64

65 BusinessObjects 6.x to XI Release 2 Migration Guide Understanding user and group migration chapter

66 5 Understanding user and group migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails Users, groups, and their organization User/group access rights How users and groups migrate Consequences of importing users and groups Migrating external groups (LDAP/Active Directory) 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning For more detailed information on user rights, see Understanding rights migration on page 121. Users, groups, and their organization Note: Throughout this chapter and the rest of the guide, the term principals is used to generically describe users and groups. Both 6.x and XI R2 use a user and group model. The framework in which they reside, however, is different. 66 BusinessObjects 6.x to XI Release 2 Migration Guide

67 Understanding user and group migration Users, groups, and their organization 5 In version 6.x Created and managed via the Supervisor and/or Supervisor over the Web application, users and groups are organized in a tree structure with one root. A user can be a member of more than one group, and these separate memberships are considered different instances of the user. By default, a single, root group is created, with the company name specified during the Supervisor installation. Supervisor offers several standard profiles for the various types of users of Business Objects products. The user profile determines by default what products a user can use: General Supervisor (all products) The General Supervisor is at the root level. Assigned all rights, this user can administer all groups, as well as their users and sub-groups. Supervisor (all products) Designer (all products but Supervisor and Supervisor over the Web) Supervisor-Designer (all products) User (all products but Designer, Supervisor, and Supervisor over the Web) Versatile (configurable) Administrators with the proper rights can customize these profiles. A user can have a different profile in each group. BusinessObjects 6.x to XI Release 2 Migration Guide 67

68 5 Understanding user and group migration Users, groups, and their organization In version XI R2 In XI R2, users and groups are created and managed using the CMC. Group structure is a directed acyclic graph (DAG); that is, each group can have more than one parent. The DAG does not need to be connected; that is, there may be groups without any relation to other groups. A user can belong to more than one group, but only one user is actually created in the CMS. Instances of a user do not exist. By default, four groups are created at CMS installation: Everyone, which contains all users Administrators Universe Designers Users Report conversion tool Users All imported 6.x users become part of the Everyone group. The following users exist by default: Administrator Guest Profiles in the version 6.x sense do not exist in XI R2. Special migration cases to be aware of User parameter migration Username case-sensitivity Password restrictions 68 BusinessObjects 6.x to XI Release 2 Migration Guide

69 Understanding user and group migration User/group access rights 5 User parameter migration Some user parameters are migrated (Name, Password, Enabled/Disabled). Some are not (timestamps, predefined settings). Username case-sensitivity Version XI R2 is not case-sensitive to usernames, whereas depending on the repository database, version 6.x can be. This means, for example, that if a version 6.x repository contains a user called jsmith and another called JSmith, and you try to import both users, one of the users may not be migrated. Password restrictions In the XI R2 environment, you can use the following CMC options to restrict password format: Enforce mixed-case passwords This option ensures that passwords contain at least two of the following character classes: upper-case letters, lower-case letters, numbers, or punctuation. Must contain at least N characters By enforcing a minimum complexity for passwords, you decrease a malicious user s chances of simply guessing a valid user s password. In addition, passwords must be at least six characters long. The first time you import a user from a version 6.x repository, passwords of any type are accepted. Once users are entered into the CMS, however, their passwords become subject to the password policy defined in the CMC. Before updating a user with subsequent incremental imports, then, make sure that the users in the source repository have all have passwords supported in the destination CMS. If they don t, they will not be re-imported. User/group access rights The security rules that existed in version 6.x (such as product access, objects rights, and security commands) are enforced in XI R2 by the ACL (Access Control List) mechanism, an industry standard method of controlling cascading security access. An ACL is set on an object to define what rights users and groups have on that object, and is composed of a list of ACEs (Access Control Entities), which specify the state of a single right for a single user/group. BusinessObjects 6.x to XI Release 2 Migration Guide 69

70 5 Understanding user and group migration User/group access rights In version 6.x, you use security commands in Supervisor to restrict user and group access to functionalities in Business Objects products.you cannot restrict access at the object level. For example, if you grant a group the right to refresh, but not create documents, the restriction will apply regardless of the documents being used. Because ACLs are used, the imposition of restrictions in XI R2 is much more granular. You can apply user, group, and role-level security at the object level, to documents, categories, folders, universes, and connections. This means, for example, that you can allow a group to refresh document A, but not refresh document B. User/group inheritance The main challenge during migration is the difference in inheritance rules between version 6.x and XI R2. In 6.x, rights inheritance is propagated through groups only. When a right is set on a group it applies to all subgroups, unless it is overridden for a specific subgroup or user. For example, because Tom and Lea belong to the Marketing group, they inherit all the rights established for the Marketing group. Rights set lower down in the group tree take priority -- rights on a user take priority over those on the user s parent, and so on. In XI R2, rights are inherited both through groups and through folders. In this environment, for example, Michael and Lea would still inherit all Marketing group rights. In addition, however, if the rights set for the Sales Results folder allowed Michael to access that folder, if no subfolder or document rights contradicted that right, Michael would automatically have access to all the documents in that folder. 70 BusinessObjects 6.x to XI Release 2 Migration Guide

71 Understanding user and group migration User/group access rights 5 Rights aggregation Aggregation is different in the two environments. In 6.x If the user has a right denied in one group and granted in the other, the user may or may not have the right granted. Aggregation rules for conflicting rights are different for the different types of rights. The value Unspecified defaults to either Granted or Denied depending on the type of right. In XI R2 If a user has a Boolean right denied in one group and granted in the other, then the user has the right denied. If the user has a boolean right unspecified in one group and granted in the other, then the user has the right granted. Unspecified Boolean rights are always considered denied. Inherited rights are equal to explicit rights, and when rights conflict, Denied always takes priority, regardless of the source of the conflicting rights. Because of this model, and because Denied takes priority over Granted, you cannot give child users or groups more rights than their parents without breaking inheritance. You can change a right from unspecified (effectively denied) to Granted, but not from Denied to Granted. Tip: Denied is a very powerful value. During aggregation, it wins over any other values. As a result, it is recommended that you prefer unspecified. By default this means Denied, but it can be overridden by Granted. Overriding inheritance Overriding inheritance therefore works very differently in the two environments: In version 6.x, you can simply grant a user a particular right if that right is denied to the group it belongs to. The rights placed on the user take precedence over the parent group s rights. Given the same situation in XI R2, you will have to turn off inheritance altogether, and this will prevent the user from inheriting any rights from parent groups of inheritance for all the rights for a user or group on an object. You cannot turn off inheritance for some rights but not others. BusinessObjects 6.x to XI Release 2 Migration Guide 71

72 5 Understanding user and group migration How users and groups migrate Troubleshooting overly restrictive rights in XI R2 If you don t understand why migrated users have far more restricted rights than you had anticipated, check the rights on the Everyone group. As the rights applied to the Everyone group apply to all users of the system, if a right is set to Denied for the Everyone group, the right is denied for all users, even migrated ones, regardless of whether they had the right granted in the source environment. How users and groups migrate Users Groups Users are migrated as users to the CMS, where they are stored as InfoObjects. A user can belong to different groups. Every instance is migrated as a user belonging to a corresponding group. Groups are migrated as groups in the CMS. The Import Wizard migrates the same hierarchy as in the 6.x repository. For example, if in 6.x a group called MyCompany contains the groups Group1 and Group2, the same hierarchy is created in the CMS database in XI R2. After import, you can take advantage of the more sophisticated XI R2 security framework to refine this hierarchy: for example, a group can belong to several groups. User profiles In version 6.x, user profiles define the applications user can use in the Business Objects system. In XI R2, user profiles no longer exist. Application rights are set through ACLs and rights on the corresponding applications and documents. During migration, user profiles are imported and reset as appropriate rights on the application. For more information on how rights are set during migration, see Understanding rights migration on page 121. Most version 6.x user profiles map to default groups in the new system. For example, General Supervisors become members of the Administrators group. Supervisors, on the other hand, are not mapped to the Administrators group, but instead simply granted the appropriate rights on all imported objects. Users with the User/Versatile profile are added to an object level security group based on their object security levels. 72 BusinessObjects 6.x to XI Release 2 Migration Guide

73 Understanding user and group migration How users and groups migrate 5 During migration, the following rules apply: General Supervisors are added to the Everyone and Administrators groups. Users whose profiles allow them to run Supervisor (Supervisor/ Supervisor-Designer/Versatile with Supervisor access): have the View access level for the groups to which they belong in version 6.x have the Full-Control access level for the users and subgroups of the groups to which they belong in version 6.x Users whose profiles allow them to run Designer (General Supervisor/ Designer/Supervisor-Designer/Versatile with Designer access) are not by default added to the Universe Designer Users group. This group has full control over the Universes folder. To allow imported universe designers to use the Designer application and manage particular universes, therefore, you must grant them specific rights through the CMC. Note: in version 6.x, a user can have different profiles in different groups. This is not possible in XI R2. User security commands Security commands in 6.x are applied at the application level. In XI R2, they are replaced by ACL and application rights, even if in XI R2, ACLs and rights also cover profiles, document access rights, and delegated administration. In XI R2, rights can be set at application and object levels. During migration, the Import Wizard imports security commands. The tables in Chapter 8: Understanding rights migration describe the equivalence of Web Intelligence, BusinessObjects and Designer security commands with rights in XI R2. BusinessObjects 6.x to XI Release 2 Migration Guide 73

74 5 Understanding user and group migration Consequences of importing users and groups Predefined settings that 6.x administrators can define in the repository to apply a set of security command settings to multiple users do not exist in XI R2. You can efficiently reproduce predefined settings, however, by creating specific groups and then assigning specific rights to these groups. Users added to these groups will inherit the rights set at the group level. User parameters Login Password Enabled/Disabled Timestamp Identification strategy Enable real time user rights update Enable Password Modification flag Password Validity settings Object Security level Specific migration information Migrated, although the CMS does not differentiate upper-case and lower-case The first time the user is imported, passwords are imported as they are. With subsequent imports of the users, however, (for an update for example), password is checked against CMS password policy. If the user is disabled in BOBJ, it is disabled in XI R2 after import Not migrated Not migrated Not migrated Maps to the User cannot change password property, for which the reverse value is accorded. Administrators must reset this manually at the global level. Expressed as limit rights set on the universe folder; object levels in BusinessObjects 6.x map to appropriately-named user groups. Consequences of importing users and groups You import users and groups using the Import Wizard. Importing principals allows you, if you want, to migrate the imported users application rights; if you are concurrently importing other objects as well, you can also import the objects rights. Nonetheless, because of the differences in the 6.x and XI R2 security models (ACL and rights instead of security commands, profiles, as well as a more restrictive framework in general), it isn t possible to have exactly the same security in 6.x and XI R2. 74 BusinessObjects 6.x to XI Release 2 Migration Guide

75 Understanding user and group migration Consequences of importing users and groups 5 The Import Wizard imports a snapshot of the 6.x security from the repository to make security in XI R2 as similar as possible, but once migrated, any change in rights in the CMS may lead to different results than in 6.x, due to differences in aggregation and inheritance rules, in how rights are collapsed at users level during import, and so forth. If you have a large repository with a very detailed security scheme, you may decide to take advantage of the new security framework by not importing your source security, and recreating security directly in XI R2. If you need some help, you can contact Professional Services who can give you insight on best practices to recreate security in CMS after an import. For information on whether to import rights, see Importing security or not on page 229. How Merge/Update options impact user/group import In incremental migrations, users and groups may be treated slightly differently than other objects. Merge Update The comparison between source and As with other objects, the Import destination users/groups is Wizard updates everything if the performed using objects CUIDs CUID is the same; if the CUID does (cluster unique identifiers). not exist in the destination repository, The user/group in the destination it creates a new user. repository is unchanged, except that If the commit fails due to a duplicate the Import Wizard merges the name, however, the user will not be hierarchy, or ownership, for the user/ imported. The Import Wizard never group. makes copies of users and groups. For example: Import 1: Source: Group1 with usera Destination: Group1 with usera In the source repository, usera is now moved into Group2. Import 2: Source: Group1 with usera Destination: Group1 with usera, Group2 with usera BusinessObjects 6.x to XI Release 2 Migration Guide 75

76 5 Understanding user and group migration Delegated Administration Delegated Administration In version 6.x, a supervisor can only modify the rights for the users located in his/her group or subgroup. In particular, this applies to universe access restrictions (also known as universe overloads) defined in Supervisor. With XI R2, universe access restrictions are defined in Designer. Modify Rights right (MRR) and Secured Modify Rights right (SMRR) In XI R2, the Modify Rights right (MRR) allows a user to modify any right for any user on a particular object. MRR is very powerful and effectively dominates all other rights, because once users are granted MRR on a particular object, they can grant themselves or anyone else any rights they want on the object. For example, if Alex has only View rights and MRR on an object, she can give herself or any other user full control over the object by granting all the missing rights. Securely Modify Rights rights (SMRR) area more restrictive kind of MRR. For example, a supervisor called Joe, who has SMRR on an object O, can only grant or deny rights that Joe himself is already granted. So in the example above, Joe has View rights and SMRR on the object O. Joe cannot give himself any more rights; he can only give or take away from other users the View (and SMRR) rights. Additionally, Joe can only change rights for users for whom he has the SMRR right (this allows you to define the set of users to which a delegated administrator has access). How to establish delegated administration in XI R2 To establish delegated administration on a specific object: You must create an administrator, or modify an existing administrator, with SMRR but not MRR on the objects in question. The administrator must have Apply Overload rights granted on the object (that is, a restriction of SMRR). 76 BusinessObjects 6.x to XI Release 2 Migration Guide

77 Understanding user and group migration Migrating external groups (LDAP/Active Directory) 5 This administrator must be granted SMRR on all the users or groups for which he/she is allowed to control rights, but no others. Note that this means that if the administrator is actually in the administrators group, he/she will by default inherit full rights to all users. To prevent this, you must explicitly add him as a principal on the root level user and group folders, and have inheritance turned off there. For this reason, it is probably simpler and less error prone if you start with a user who is not in the administrators group. After this is configured, it should be possible to define the restrictions required for 6.x compatibility. Note: When you migrate to XI R2, delegated administration is not completely accounted for during import, and so some delegated administrators may have fewer rights after import. The SMRR is added to the correct groups for delegated administrators, but is not added on any objects, so only half of the required rights are there. Migrating external groups (LDAP/Active Directory) The Import Wizard performs simple LDAP migration from version 6.x. It maps static LDAP groups. It does not import LDAP attribute variables used in reports. After migration, you need to create dynamic groups using Enterprise authentication. If LDAP has been set in XI R2, and if 6.x is set with LDAP, then you can import all objects owned by LDAP users in the 6.x environment. This includes Inbox, Personal, Corporate, and scheduled documents, along with document ownership. Rights and schedules work the same as for other users imported by the Import Wizard: only selected types of objects are imported for Inbox and Personal ACLs are imported only if the Import Rights option is selected (Corporate document ownerships) Filter on Inbox and Personal documents To import external group mappings or external users, you must configure the destination server with the same LDAP/Active Directory parameters as in your source system. You do this in the CMC. If the destination server is not configured with LDAP or Active Directory, the Import Wizard does not migrate external users. BusinessObjects 6.x to XI Release 2 Migration Guide 77

78 5 Understanding user and group migration Migrating external groups (LDAP/Active Directory) LDAP migration Platform requirements In version 6.x you can use Microsoft Active Directory and a Java application server for LDAP configurations. The application server can also be on UNIX or Windows. With XI R2, Active Directory is only supported with Microsoft IIS web/application server. User/group mapping In version 6.x, the users you create in the repository depend on the type of LDAP mapping you choose: If you choose user-to-user mapping, then you must create a user in the repository for each LDAP user you want to allow to login. If you choose group-to-group mapping, you need only create a group for each LDAP group of users that you want to allow to login. In XI R2, you map in the group(s) from LDAP that you want to allow access to the system. When you map in a group, a group is created in the repository with an LDAP alias (the alias contains the DN of the LDAP group that was mapped so it can be associated with the correct LDAP group). When you map in any third-party group, you can do either of the following: Create users in the repository for each user in the LDAP group. Instead of explicitly creating the users, choose to create a user in the repository for any LDAP user who successfully logs into the BusinessObjects Enterprise system. These users are full users, who can be associated with other, non-ldap groups and have specific rights sets. This option is useful if you want to map in a very large group, but you know that few users will access Enterprise. Any created users are added to the appropriate third-party group in BusinessObjects Enterprise. After your groups are mapped, you can assign rights to the groups or make the group a member of other BusinessObjects Enterprise groups (you can also do this for any users that have been created). The Import wizard maps static LDAP groups. Dynamic groups are mapped automatically if you use Enterprise authentication in the new environment. If mapping cannot be established, groups are imported as non-ldap BusinessObjects Enterprise groups. 78 BusinessObjects 6.x to XI Release 2 Migration Guide

79 Understanding user and group migration Migrating external groups (LDAP/Active Directory) 5 LDAP attribute variables In version 6.5, if LDAP attributes were mapped to Business Objects variables in the Security Configuration Tool, the attributes could be used in reports. in the report would then retrieve the LDAP attribute value. These attributes do not migrate to version XI R2. In version XI R2, if they are used in a report, they are displayed if used as a filter, they fail to match anything. BusinessObjects 6.x to XI Release 2 Migration Guide 79

80 5 Understanding user and group migration Migrating external groups (LDAP/Active Directory) What does migration involve? Before import 1. Connect to your source cluster using an LDAP login. 2. Launch Supervisor to check that all LDAP users are not stored in the repository and are indeed in the LDAP server. 3. In the source repository, delete any third-party aliases for all users/groups that no longer exist in the LDAP system. 4. Make sure BusinessObjects Enterprise XI R2 is installed and launched, including the Import Wizard. 5. Ensure that the connection information to the third-party system is still valid, so that the Import Wizard can get aggregation information for user/ groups during the import. 6. Configure the LDAP plug-in from the CMC (Authentication > LDAP tab). You just have to configure the connection parameters, you don t have to map any groups. See the BusinessObjects Enterprise XI Release 2 Administrator s Guide for detailed instructions. Importing After import Use the Import Wizard to import your content, making sure you check the LDAP Authentication option in the Import Groups Option page. The Import Wizard adds an LDAP alias to every imported group that it can find in the configured LDAP system, by matching the name of the group to the name of a group in the LDAP system. It also updates the LDAP plug-in after the users and groups have been imported. This adds an LDAP alias to every user that belongs (in the LDAP system) to one of the groups with an LDAP alias. Note: If you import user s personal content, only users that actually exist (have user objects) in the repository will have their personal content imported to XI R2. After import, go through the users and groups in the XI R2 system to make sure that the Import Wizard made correct assumptions about the users and groups that were intended to be LDAP users and groups. You should then delete/re-assign/add LDAP aliases as necessary. You can optionally map additional LDAP groups at this point. You can, for example, create dynamic groups if required. 80 BusinessObjects 6.x to XI Release 2 Migration Guide

81 BusinessObjects 6.x to XI Release 2 Migration Guide Understanding object migration chapter

82 6 Understanding object migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Assessment and planning What kinds of objects can be imported? Universes and universe connections Stored procedures Folders, domains, and categories Documents 2. Preparing for import 3. Importing from the source to destination environment 4. Post-import checking and tuning What kinds of objects can be imported? The following types of objects can be imported from BusinessObjects 6.x using the Import Wizard: Users and user groups See Understanding user and group migration on page 65. Universes and connections Stored procedures Inbox, personal, and corporate documents Third-party ( agnostic ) documents (such as.pdf,.ppt,.doc,.xls,.txt,.rtf) Personal and corporate categories Broadcast Agent Scheduler tasks that are supported in XI R2 Application Foundation 6.x objects Third-party documents used by Application Foundation objects (includes.svg,.xml,.swf,.csv,.gif,.jpg,.bmp, and.png) 82 BusinessObjects 6.x to XI Release 2 Migration Guide

83 Understanding object migration What kinds of objects can be imported? 6 Potential limitations Flow of resources In the current version, the Import Wizard does not import: Administration Console settings Web Intelligence OLAP Custom applications and interfaces created using the SDK Broadcast Agent Scheduler tasks that are not supported in XI R2 Broadcast Agent Publisher tasks BusinessObjects Auditor InfoView personal settings Some user settings, such as timestamps individual LDAP users (inbox and personal) BusinessQuery These restrictions, and their solutions, are explained in greater detail in the remainder of the chapter. The Import Wizard can import objects only if they are located in: the repository (users, groups in the security domain, documents in the document domains, universes in the universe domains) personal and inbox folders BusinessObjects 6.x to XI Release 2 Migration Guide 83

84 6 Understanding object migration What kinds of objects can be imported? The picture below shows the flow of resources from the source environment (5.1 in this case) to the destination environment during import. Files in the FRS are controlled by the platform, not the client. Objects controlled by the system (InfoObjects) may contain both metadata (properties, relationships, and so on) and files. The metadata is stored in the CMS database, and the files are stored in the FRS. During import, all objects in the source repository are first copied to a temporary folder on the machine running the Import Wizard. The default location of the folder is defined by the $IMPORTWIZARDTMP system variable. If this variable is not defined, then it is $TMP\ImportWiz_Temp, where TMP is a Windows system variable. If these variables are not defined, then it is $TEMP\ImportWiz_Temp, where TEMP is a Windows system variable. If all these variables are not defined, then it is the default temporary folder created by Windows (normally C:\Document and Settings\%USERNAME%, followed by \ImportWiz_Temp). You can modify the $IMPORTWIZARDTMP system variable in the Windows Control Panel (System > Advanced > Environment Variables > New System Variable). 84 BusinessObjects 6.x to XI Release 2 Migration Guide

85 Understanding object migration What kinds of objects can be imported? 6 After import, the Temp folder and its contents are deleted. Corporate documents Inbox documents Version 6.x corporate storage is mapped to the Public Folders folder in the XI R2 CMS repository. Corporate documents are saved in this folder after the import. Each domain is migrated as a folder in the Public folder of the CMS repository. Note: If your 6.x repository was a distributed one, all the domains are imported into a single place. In version 6.x, Inbox documents are stored in the repository until all recipients have read them. When this occurs, the documents are removed from the repository. When a document has been read by a given user, it is copied to the user s Inbox folder ($STORAGEDIR\mail\<username>). The Import Wizard allows you to import these Inbox documents. You can filter Inbox documents to import them by date received. You can also import unread and/or read Inbox documents to XI R2. For read Inbox documents, you must specify the location of the mail folder. The documents are migrated to XI R2 users Inbox folders in the CMS. Documents inherit the rights of the 6.x Inbox folder. If the Inbox contains duplicate documents, they are also migrated to the FRS, which manages all document instances that have been scheduled or published to the repository. BusinessObjects 6.x to XI Release 2 Migration Guide 85

86 6 Understanding object migration What kinds of objects can be imported? To import 6.x Inbox documents that reside on a UNIX machine, you need to map a drive from the Windows server running the Import Wizard to the directories on the UNIX machine containing the documents. Personal documents On a 6.x server deployment, users can save personal documents. These documents are saved in $STORAGEDIR\users\<username>. The Import Wizard allows you to import these Personal documents. You can filter them to import by their creation or modification date. You will have to specify the location of the personal folder. Personal documents are imported to the user s Favorites folder in the destination CMS. Documents inherit the rights of this folder. The document owner and the Business Objects Administrator have access to these documents. Personal or Corporate categories that referred to these documents in 6.x continue to refer to them in XI R2. To import 6.x personal documents that reside on a UNIX machine, you need to map a drive from the Windows server running the Import Wizard to the directories on the UNIX machine containing the documents. 86 BusinessObjects 6.x to XI Release 2 Migration Guide

87 Understanding object migration Broadcast Agent Scheduler 6 Broadcast Agent Scheduler The Import Wizard can be used to import Broadcast Agent Scheduler jobs from BusinessObjects Enterprise 6.x to XI R2. Nevertheless, a job can be migrated only if the schedule parameters associated to the job are supported in XI R2. In XI R2, the first action for scheduled documents is always a refresh. Therefore, a job can be imported from 6.x only if its first action is a refresh. The following features are not supported in XI R2: multiple outputs conditional processing custom macros You can, however, have embedded VBA macros (those that include calls to the platform, such as Login or Logout, will need to be updated). report bursting ( refresh with the profile of each recipient ) saved in XML format If a job contains non-supported elements or features, you must drop the feature or recreate it in the 5.x/6.x system so that it is consistent with the XI R2 platform. The Import Wizard allows you to select individual jobs for import. Task scheduling options The Time Schedule options in 6.x and XI R2 are slightly different. The following options do not exist with the same customizable parameters: Daily Week periodicity Weekly Week periodicity Monthly interval Business day Weekend day Month periodicity BusinessObjects 6.x to XI Release 2 Migration Guide 87

88 6 Understanding object migration Broadcast Agent Scheduler User-defined Weekday Business day Weekend day When such a job is migrated, the closest periodicity that can be defined in the XI R2 framework is assigned to this job. File Watcher Deletes that you set in File Watcher may not function in XI R2. In Broadcast Agent 6.x, in the Task Properties dialog box/scheduling tab, you can set the File Watcher feature. If you select one of the delete options: Delete the file each time the task starts Delete the file only if the task succeeded Delete the file after execution of the task then after the job is imported to XI R2 by the Import Wizard, the File Watcher details are transferred to the Event Server, but the deletes may not occur. Associated universes When you import scheduled documents from 6.x, the Import Wizard does not automatically import the universe used by these documents. Therefore, if you want your scheduled documents to be refreshed, you must also select universes and corresponding connections for import. How scheduled documents are migrated The procedure is different, depending on whether the Broadcast Agent job schedules a document in Corporate or Inbox. Corporate If the Corporate document is already in the CMS or is imported at the same time, then: the Import Wizard creates a scheduled instance of this document below the document in the CMS schedules parameters are set using the schedule parameters of the original job 88 BusinessObjects 6.x to XI Release 2 Migration Guide

89 Understanding object migration Broadcast Agent Scheduler 6 no ACL is set at this instance level. The instance inherits the ACL set at the document level However, if the schedule contains features that are not supported in XIR2, then no import is performed. If different schedulers of the document must be imported, then the same number of instances of the document is created in the CMS. Note: In InfoView, by default, when you display a report, the object is displayed, and not its last instance. To see the last instance of a document, you must select the View the latest successful instance of the object option for InfoView in the CMC. If the Corporate document has not been imported or is not imported at the same time to the CMS, then the job is migrated in predefined folders. The administrator should review documents imported into these folders and, if needed, correctly reassign them manually. These folders are by default: Public Folders/Migrated Scheduled documents/<name of Broadcast Agent> If the schedule contains features that are not supported in XI R2, then the document is imported into: Public folders/migrated Scheduled documents/< Name of Broadcast Agent >/Unsupported schedules Inbox If the sender of the original schedule already exists in the CMS or if the sender is migrated at the same time, then: The Import Wizard imports the scheduled document into the Favorites folder of this user in the CMS. A folder named Scheduled migrated documents/<bca Name> is created under Favorites. The document is renamed to <doc_name>_<docid>.<ext> An instance is created for the document using the parameters of the original scheduler No ACL is set at this instance level. The instance inherits the ACL set at the folder level. The recipients (user or group) of the schedulers are the recipients of the original schedule, if they already exist in the CMS or if they are migrated at the same time (name is verified). If the sender of the original schedule does not exist in the CMS, then: BusinessObjects 6.x to XI Release 2 Migration Guide 89

90 6 Understanding object migration Broadcast Agent Scheduler The Import Wizard imports the scheduled document into: Public Folders/Scheduled migrated documents/<name of Broadcast Agent>/ <user name> The document is renamed to <doc_name>_<docid>.<ext> An instance is created for this document using the schedule parameters of the original job No ACL is set at this instance level. The instance inherits the ACL set at the folder level The recipients (user or group) of the schedules are the recipients of the original schedule, if they already exist in the CMS or if they are migrated at the same time (name is verified). For schedules that are not supported in XI R2, the following occur. If the sender of the original schedule already exists in the CMS or is migrated at the same time, then the Import Wizard imports the scheduled document into the Favorites folder of this user in the CMS. The folder Scheduled migrated documents/<bca Name>/Unsupported schedulers is created under Favorites. The sender has the option to manually reschedule this document. If the sender of the original schedule does not already exist in the CMS, then the Import Wizard imports the scheduled document without its scheduling parameters into Public Folders/Scheduled migrated documents/ <BCA Name>/Unsupported schedulers/<sender name> The unsupported scheduled document is renamed to <doc_name>_<docid>.<ext> ACLs are not set for these schedules, and schedule parameters are not applied. The administrator should review documents imported into these predefined folders and, if needed, correctly reassign them manually. 90 BusinessObjects 6.x to XI Release 2 Migration Guide

91 Understanding object migration Broadcast Agent Scheduler 6 Summary of job migration The following table summarizes how Broadcast Agent jobs are migrated. Destination Condition Corporate Document in CMS Schedule parameters supported? Yes Result Import a scheduled instance into Public Folders/<folder name>/ <document name> Corporate Document in CMS No No import Corporate Document not in CMS Yes Import a scheduled instance into Public Folders/Migrated Scheduled documents/<bca Name> Corporate Document not in CMS No Document imported without scheduling parameters into Public Folders/Migrated Scheduled documents/<bca Name>/Unsupported schedules Inbox Sender in CMS Yes Import a scheduled instance into <Sender Name>/Favorites/ Migrated Scheduled documents/ <BCA Name> Inbox Sender in CMS No Document imported without scheduling parameters into <Sender Name>/Favorites/ Migrated Scheduled documents/ <BCA Name>/Unsupported schedules Inbox Sender not in CMS Yes Import a scheduled instance in Public Folders/Migrated Scheduled documents/<bca Name>/<Sender Name> Inbox Sender not in CMS No Document imported without scheduling parameters into Public Folders/Migrated Scheduled documents/<bca Name>/Unsupported schedulers/ <Sender Name> BusinessObjects 6.x to XI Release 2 Migration Guide 91

92 6 Understanding object migration Universes and universe connections Renaming of migrated documents Sometimes, when a document with an associated job is migrated, a document with the same name already exists in the destination folder. The renaming of the migrated document occurs differently, depending on whether you are migrating in Merge mode or Update mode. (See The Merge and Update import scenarios on page 173.) Merge mode If a document with the same name as the 6.x document exists in the destination folder, a new folder is created. For example, for the 6.x document Annual.rep being migrated into the folder named Agent, a new folder named Agent(2) is created, and Annual.rep is reposted within Agent(2). The document name and instance name do not change. Update mode The document ID is checked in the CMS. If it exists, the old document is updated with the properties of the newly migrated document. The instances are also replaced by the newly migrated schedules. The schedules and the instances are identified by the ID received in the Scheduled Jobs table of the repository. Universes and universe connections The Import Wizard imports universes from a 6.x deployment into an XI R2 deployment. During this process, the relationship between universes, connections, and Desktop Intelligence/Web Intelligence documents is maintained. IDs of the documents, universes, and connections are converted to cluster unique identifiers (CUIDs). The identifier distinguishes these objects from objects imported later from the source environment. When you import a universe: the Import Wizard imports any associated connection objects the connection is saved in the FRS and an InfoObject is created in the CMS the universe and its linked documents are copied into the FRS 92 BusinessObjects 6.x to XI Release 2 Migration Guide

93 Understanding object migration Universes and universe connections 6 universe overloads defined in 5.1/6.x, if migrated, are mapped to access restrictions in XI R2 (see Access restrictions on page 95). ACEs are created to migrate universe-related security commands the locale is preserved The Import Wizard has three modes for importing universes: Mode Import all universes and all connection objects Import all universes and only connection objects used by these universes Import the universes and connections that the selected Web Intelligence and BusinessObjects documents use directly What it does Imports all universes and all connection objects. You cannot select individual universes or connections. Imports all universes, and only connection objects used by those universes. Imports all universes and connections used by the selected documents. This option also enables you to select additional universes to import, even if they are not used by any document. Connections When you select a Web Intelligence or BusinessObjects document to import, the Import Wizard automatically selects the associated universes for import. Note: The Import Wizard also imports any universes with the same name that exist in other domains. BusinessObjects documents may have been created outside the repository, using a short name ; that is, a reference to a universe stored on a local machine. If the universe has a short name, its linked documents may not be imported if more than one universe is found in the CMS with the same short name. Universe domains are converted into subfolders under the Universe folder. Each universe folder is named after the corresponding version 6.x universe domain. When you import a universe from a domain, it is placed in the corresponding domain folder. If the universe is a derived universe, then all relevant core universes and their connections are also imported. Note: Designer 6.x cannot open universes created with Designer XI R2, due to a file format change. When you import version 6.x universes, the associated connections are imported automatically. They are converted into connection objects. BusinessObjects 6.x to XI Release 2 Migration Guide 93

94 6 Understanding object migration Universes and universe connections Make sure that the Import Wizard can access the 6.x database the same way that version 6.x accesses it. You may need to install database drivers or configure connection settings on the machine. For example, if you import SQL Server connection objects from a 6.x source environment, you must configure the connections on the destination machine via the Control Panel before you import the connection objects. You must use the same name and settings as the connection used on the source machine when you created the domain key. BOUSER/BOPASS In version 6.x, users could in the connection information for the universe. The variables were replaced at runtime with the user s enterprise username and password, and used to log on to the database. For security reasons, however, XI R2 does not permit the retrieval of users passwords. Therefore, universe connections that previously used the BOUSER and BOPASS variables associated with the BusinessObjects user name and password must now use database credentials (DBUSER and DBPASS). Those database credentials can be populated by the Import Wizard and later edited in the CMC, on the Properties tab for each user account. When migrating, the Import Wizard: replaces BOUSER and BOPASS with DBUSER and DBPASS in universes proposes automatically populating these variables for users to migrate You can, however, re-synchronize if users change their passwords. Synchronizing enterprise and database credentials There are three ways to synchronize enterprise and database credentials in the XI R2 system. You can: choose the Import Wizard option that batch imports user names and passwords from version 6.x to auto-populate database credentials in XI R2. run a batch upload of a user s file. User names and passwords are loaded from a file, stored and used as database credentials. create a custom application using Enterprise SDK to set DBUSER and DBPASS information. 94 BusinessObjects 6.x to XI Release 2 Migration Guide

95 Understanding object migration Universes and universe connections 6 Access restrictions In a 6.x system, access restrictions (that is, object restrictions, table mapping, and row restrictions) are defined with the Supervisor application and associated with users and groups. A user who belongs to multiple groups is said to have multiple user instances (one instance per group). Note: Universe overloads in version 6.x are called access restrictions in XI R2. They are managed in Designer. The Import Wizard enables you to import all access restrictions that are associated with the imported universes for any of the selected users and groups being imported. If no principal users or groups are selected for import, no access restrictions are imported and none are created. The imported access restrictions are converted into objects. They remain connected to the universes to which they were connected in the source environment. The Import Wizard may create additional access restrictions in the destination environment in order to preserve the restrictions for all imported users. Connections for access restrictions are not migrated automatically. You must manually migrate these connections. Access restrictions are migrated using both object names and object IDs to identify universe components. Access restriction aggregation In both 6.x and XI R2, there are two types of access restrictions: exclusive and non-exclusive. Row restrictions are combined using the AND operator, while object restrictions and compatible table mappings are aggregated. Exclusive access restrictions require a different mechanism. The Import Wizard deduces a global ordering of groups for each universe, based on the access restrictions prior to migration. For a given user, the Wizard considers the set of parent groups of that user and, in that set, the group with the highest priority determines which restriction set gets applied to that particular user. Access restriction collapsing Sometimes the global group ordering that is deduced during migration cannot account for all of the individual user priority settings in 6.x. In this case, access restrictions will be collapsed, meaning that the effective 6.x access restriction will be copied onto the user, which always has highest priority. This means that there might be more access restrictions in the destination than in the source environment. BusinessObjects 6.x to XI Release 2 Migration Guide 95

96 6 Understanding object migration Stored procedures Stored procedures In version 6.x, you can allocate stored procedures to users. In XI R2, Use Connection for Stored Procedures is introduced as a new right for the connection object. During the import, for all stored procedures accessible to a user, an ACE (Access Control Entry) is created for the user, with a corresponding connection. Stored Procedures Access is enabled and the ACE is set to Granted. Folders, domains, and categories In the 5x/6x repository, it is not possible to set keywords and descriptions for folders. In the XI R2 CMS, this is possible. In XI R2, in upgrade mode, when a domain is re-imported, if the user has set keywords and descriptions for the folder created from the domain, they are removed. Because they do not exist in 6.x, the update removes them in XI R2. If you re-import a domain from 5.x/6.x, the keywords and descriptions are kept. You select the domains and documents you want to import into XI R2. When you select a document, the document's domain is also imported. Documents and universes cannot be imported without importing the domain. Version 6.x document and universe domains are saved as sub-folders in the Public Folder of the CMS of XI R2. Objects corresponding to the universes and documents contained in the domains are imported to these folders. If you have chosen to import security, access rights are preserved. User and group access to the folders are equivalent to the rights they had on the version 6.x domains. XI R2 preserves the hierarchy of subcategories. Corporate (or administrative) categories are imported as categories under the Categories folder. For each imported user, selected personal categories are imported to a new subfolder (named after the user) under the Personal Categories folder. You can select individual Corporate categories and import Web Intelligence documents grouped by Corporate category. Personal categories, however, can be imported only as part of the batch import. 96 BusinessObjects 6.x to XI Release 2 Migration Guide

97 Understanding object migration Documents 6 Documents Importing documents presents a good opportunity to optimize your document management. For more information, see What objects should you migrate? on page 243. When documents contain no locale In the 6.x repository, it is possible that some.wqy and.rep (as well as associated.rea and.ret files) documents do not store their locale. To set the locales in these documents when they are saved in the CMS after their conversion into XI R2 format, the Import Wizard asks for different default locales: the document s locale the locale of the machine used to create the document Once you select these locales, they are stored in the document itself when it is imported to the CMS. The default locales apply to all documents in the current import without locales. Applying wrong locales to a document may cause difficulties; for example, the date or currency may be incorrectly displayed. If the repository contains documents with different locales, it is best practice to run the import step by step (one step for each document language) in order to avoid, for example, setting a default English locale for a Japanese document. BusinessObjects documents When you import a 6.x BusinessObjects (.rep) document to XI R2, the following occur: universe ID pointer is updated so that it references a universe in the CMS. an InfoObject is created in the CMS for this document and for the saving of this document properties are updated and displayed in the CMC BusinessObjects template (.ret) documents do not contain cubes or a connection to a universe. Therefore, all that occurs is: the locale of the document is updated an InfoObject is created in the CMS BusinessObjects 6.x to XI Release 2 Migration Guide 97

98 6 Understanding object migration Documents To convert 6.x.rep documents to.wid format, you can use the Report Conversion Tool, delivered with the XI R2 suite. See the Report Conversion Tool Guide for more information. Alternatively, you can use the Report Conversion Tool to convert.rep documents to.wqy (Web Intelligence 2.x) format. Then, the Import Wizard converts them from.wqy to.wid. Note:.wid documents for which there is no universe (so-called orphan documents) can be imported into XI R2. BusinessObjects document rights If you migrate security during the import of BusinessObjects documents, version 6.x security commands are converted to XI R2 application-level and document-level rights. Some commands have been eliminated and others renamed. The Administrators group in XI R2 has Full-Control access to documents. The Everyone group has View access. For a detailed summary of how BusinessObjects security commands are migrated, see BusinessObjects/Desktop Intelligence rights on page 150. Limitations Keep in mind the following limitations when you import BusinessObjects documents: XI R2 can read BusinessObjects 6.x.rep documents, but after you save these documents in XI R2, they can t be read by a 6.x version of the software. BusinessObjects 6.x cannot open XI R2 Desktop Intelligence documents. OLAP data providers are not supported in XI R2. BusinessObjects 6.x documents based on an OLAP data provider are view-only in XI R2. There is no document password protection, on the server side, in XI R2. XI R2 Desktop Intelligence cannot access a version 6.x repository. BusinessObjects SDK The platform-related portion of the BusinessObjects SDK has evolved, which means that code developed for 5.1/6.x will require updates for platform interactions (authentication, send document, receive document). Send to Users and Send to Broadcast Agent Server are not available in XI R2. Instead, you need to use the Platform COM SDK. 98 BusinessObjects 6.x to XI Release 2 Migration Guide

99 Understanding object migration Documents 6 The server-side report engine is not multi-document. This means that add-ins will not be loaded on the server. For example, for a document based on a custom data provider (DPVBAInterface) implemented in an add-in, refresh will fail. Calculator changes XI R2 uses a different report engine than BusinessObjects 6.x. Therefore, there are differences in the way the calculator is handled. Because of this, there may be issues with BusinessObjects documents after they are imported to XI R2. See Checking for calculation updates on page 309 for more information. Web Intelligence documents Because Web Intelligence 2.x documents (.wqy) are no longer supported in XI R2, the Import Wizard automatically converts them into the.wid format supported in XI R2 before importing them. Web Intelligence 6.x documents (.wid) are supported in XI R2, so the Import Wizard performs no specific conversion when importing them. When you import a Web Intelligence document: universe ID pointer is updated so that it references a universe in the CMS. IDs in the Web Intelligence documents, universes, and connections are converted to cluster unique identifiers (CUIDs), which will distinguish these objects from objects subsequently imported from the source environment. An InfoObject is created in the CMS for this document and for the saving of the document. Properties are updated. If a.wqy and.wid document have the same name, they are both imported, but the.wqy document is renamed to <name of document>_wqy.wid. Web Intelligence rights If you choose to migrate security, all security commands in version 6.x Web Intelligence documents are migrated to XI R2. A number of rights are new in Web Intelligence XI R2. For example: Edit SQL BusinessObjects 6.x to XI Release 2 Migration Guide 99

100 6 Understanding object migration Documents Allow user to merge dimension for synchronization Interactive Editing rights The version 6.x security command Allow use of the WebIntelligence HTML Report Panel has been renamed to Enable Query - HTML. After it is migrated, set it to Denied. Limitations There may be an issue with the migration of certain.wqy features to.wid. Garamond font In the converted document, the Garamond font is replaced by either Arial or Times New Roman, and it is slightly larger. You can add the Garamond font to the destination server so that it will be picked up by the converted documents. To add the Garamond font: 1. On the destination server machine, make sure you have the following fonts in c:\windows\fonts: Gara.ttf Garabd.ttf Garait.ttf If not, copy them from another machine. 2. Open the fontalias.xml file, located in: $INSTALLDIR\BusinessObjects Enterprise 11.5\win32_x86\fonts 3. Add the following lines: <FONT NAME="Garamond"> <FONTFAMILY PLATFORM="ttf" NAME="Garamond"> <FONTATTRIBUTE BOLD="false" ITALIC="false" LOGICAL="Garamond" PHYSICAL="GARA.TTF"/> <FONTATTRIBUTE BOLD="true" ITALIC="false" LOGICAL="Garamond" PHYSICAL="GARABD.TTF"/> <FONTATTRIBUTE BOLD="false" ITALIC="true" LOGICAL="Garamond" PHYSICAL="GARAIT.TTF"/> </FONTFAMILY> <FONTFAMILY PLATFORM="win" NAME="Garamond"/> <FONTFAMILY PLATFORM="java" NAME=" 'Garamond', 'Arial Unicode MS'"/> <FONTFAMILY PLATFORM="html" NAME=" 'Garamond', 'Arial Unicode MS'"/> </FONT> 100 BusinessObjects 6.x to XI Release 2 Migration Guide

101 Understanding object migration Documents 6 4. Restart the destination server. 5. Open the wqyconversionsettings.xml file, located in: $INSTALLDIR\BusinessObjects Enterprise 11.5\win32_x86\config 6. Add the following line: <FONT NAME="Garamond"> 7. Run the Import Wizard and re-import the documents. Locale In some Web Intelligence 2.x versions, locale was not stored in the.wqy file. If no locale is found in the.wqy file, the Import Wizard prompts you for a locale. Application Foundation objects If you have Application Foundation or later, you can use the Import Wizard to import dashboards, analytics, and schedules into the CMS of XI R2. Note: Application Foundation is called performance management in XI R2. The performance management repository structure in XI R2 is similar to that of Application Foundation v There is no significant change in the architecture. You can update the Application Foundation repository with the Application Foundation Repository Update Tool provided with XI R2. For complete information on importing Application Foundation objects, see Chapter 7: Understanding Application Foundation object migration. Third-party documents Other limitations BusinessObjects Enterprise 6.x supports third-party (also known as agnostic ) documents. The Import Wizard imports these documents into XI R2 if the format is supported. Formats supported in XI R2 include Adobe Acrobat PDF; Microsoft Power Point, Word, RTF, and Excel; and *.txt documents. For the most up-to-date list of supported formats for third-party documents, see the list of supported platforms. Legacy Web Connect documents can be opened in XI R2, but not edited or refreshed. BusinessObjects 6.x to XI Release 2 Migration Guide 101

102 6 Understanding object migration Documents When VBA macros from BusinessObjects 6.x are updated in XI R2, they can no longer be used in previous versions. XI R2 can open and use LOV (list of values), UDO (user-defined objects), and.rea files from version 6.x. The Import Wizard does not import UDOs because UDOs are not usually stored in a repository. 102 BusinessObjects 6.x to XI Release 2 Migration Guide

103 Understanding Application Foundation object migration chapter

104 7 Understanding Application Foundation object migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Assessment and planning Migrating to Performance Management XI R2 Migrating the Application Foundation repository and its contents Migrating dashboards Migrating analytics Migrating schedules Migrating rules and named events Migrating security commands What you cannot migrate 2. Preparing for import 3. Importing from the source to destination environment 4. Post-import checking and tuning Migrating to Performance Management XI R2 The Import Wizard migrates Application Foundation objects from your 6.x deployment to performance management XI R BusinessObjects 6.x to XI Release 2 Migration Guide

105 Understanding Application Foundation object migration Migrating to Performance Management XI R2 7 Objects stored in the Application Foundation repository and locally on the Application Foundation server are either: migrated to the performance management XI R2 repository Note: The Import Wizard writes new tables and columns to the Application Foundation repository during the upgrade. Business Objects strongly recommends that you copy the source repository before migrating, and that you run the Import Wizard on the copy of the source. This enables you to keep your source environment intact during and after migration. Refer to Migrating the Application Foundation repository and its contents for details. imported and published by the Import Wizard to the XI R2 CMS (Central Management Server) As in previous versions, performance management relies on its own dedicated repository as well as the Business Objects repository previously, now the CMS. BusinessObjects 6.x to XI Release 2 Migration Guide 105

106 7 Understanding Application Foundation object migration Migrating to Performance Management XI R2 During migration from Application Foundation 6.x to performance management XI R2, certain Application Foundation objects are published to the CMS, and others remain in the Application Foundation repository, which is upgraded to support new features in XI R2: Note: You must install XI R2 and configure and deploy the CMS before running the Import Wizard. This includes configuring the administrator account for managing the performance management repository, and making a copy of the source Application Foundation repository available for the migration process. See Planning the migration on page 225 for information on the migration workflow. 106 BusinessObjects 6.x to XI Release 2 Migration Guide

107 Understanding Application Foundation object migration Migrating to Performance Management XI R2 7 Supported migration paths The following versions are supported for migration to performance management XI R2: Application Foundation 6.1.b, 6.1.3, 6.5.1, performance management XI (see the BusinessObjects Enterprise XI Release 2 Installation Guide for information on migrating from XI) When you migrate the Application Foundation 6.1 or 6.5 repository, the Import Wizard writes new tables and columns to the repository to support the new features in performance management XI R2 (see Migrating the Application Foundation repository and its contents on page 108 for a list of changes made to the repository during migration). Just like the BusinessObjects Enterprise XI R2 repository, the performance management XI R2 repository is integrated into the CMS. Using the Import Wizard See Using the Import Wizard on page 267 for a step-by-step explanation on how to use the Import Wizard to migrate from Application Foundation to performance management XI R2. Before using the Import Wizard Before running the Import Wizard, check the integrity of the source environment. Business Objects recommends that you: copy the source Application Foundation repository before migrating, and run the Import Wizard on the copy of the source run the Scan and Repair utility on the BusinessObjects repository check the integrity of universes referenced by Application Foundation objects (in Setup > System Setup > Tools) check the version and integrity of the source Application Foundation repository check the location of the Application Foundation storage folder check the location of the inbox and personal folders ensure that your database connections are valid ensure that the appropriate middleware is installed BusinessObjects 6.x to XI Release 2 Migration Guide 107

108 7 Understanding Application Foundation object migration Migrating the Application Foundation repository and its contents The Import Wizard assumes that the source environment is clean. The Import Wizard cannot resolve problems present in the source environment during migration. For example, if there are inconsistencies between universe IDs in the Application Foundation repository (in the ci_source table) and the BusinessObjects repository, the source ID will not be correctly mapped to the CUID (the cluster unique ID that is assigned to the universe) assigned by the Import Wizard during import. Double-check that universes referenced in the ci_source table have the same id in the BusinessObjects repository before running the Import Wizard. For information on checking the integrity of the source environment, see Best Practices for Migrating to BusinessObjects Performance Management XI R2. Migrating Application Foundation objects The following types of objects are supported for migration from BusinessObjects Application Foundation 6.x: To find out about this object... The Application Foundation repository, connections, and data stored in the repository tables (including metrics, goals, and sets) Dashboards Analytics Schedules Rules Agnostic documents See this section... Migrating the Application Foundation repository and its contents Migrating dashboards Migrating analytics Migrating schedules Migrating rules and named events Agnostic documents Migrating the Application Foundation repository and its contents The Import Wizard migrates the Application Foundation 6.x repository to version XI R2. You can also migrate other objects to the CMS without migrating the repository, and migrate the repository during a later import. The repository migration is an optional step in the Import Wizard, which enables 108 BusinessObjects 6.x to XI Release 2 Migration Guide

109 Understanding Application Foundation object migration Migrating the Application Foundation repository and its contents 7 you to migrate the repository during a later import. By default, the Application Foundation repository is not selected for migration in the Import Wizard. You must explicitly select this option. Note: You must migrate the Application Foundation repository in the same Import Wizard session during which you import rules, schedules containing rules, and events. If you choose not to upgrade the repository, you cannot import these types of objects. In addition, if you choose not to upgrade the repository, your repository connections will not be active on the migrated environment. Business Objects strongly recommends that you copy the Application Foundation repository before migration and that you run the Import Wizard on the copy, to ensure that your source environment stays intact after migration. The Import Wizard physically changes the Application Foundation repository during migration. The Import Wizard does not make a copy of the repository before migrating it. For information on continuing to deploy the source environment after migrating, see Maintaining the source repository during migration on page 110. When you upgrade the repository in the Import Wizard, it updates the Application Foundation repository into the performance management XI R2 repository. The Application Foundation repository contains: Dashboard Manager tables, which contain metric attributes and values Performance Manager tables, which contain goals, target values, strategies and roles Set Analysis tables, which contain set data The performance management XI R2 repository includes new columns in the repository tables to support new features and the new architecture. For example: a new column is added to the table containing universe information (the ci_source table) to store the newly attributed CUID used to reference the InfoObject that represents the universe in the CMS. In XI R2, all universes are stored as InfoObjects in the CMS. Links to other universes are also automatically updated in the ci_source table. new columns are added to the metric table (ci_probe) to store the new metric attributes supported in XI R2 (metric description, metric owner, last refresh date) new columns are added to the goal table (ci_target) to store new information about goal import BusinessObjects 6.x to XI Release 2 Migration Guide 109

110 7 Understanding Application Foundation object migration Migrating the Application Foundation repository and its contents links to documents are automatically overwritten and upgraded in rule definitions (in the ci_rule table) the following tables become obsolete after the import: ci_task (since scheduled tasks are now handled in the CMS) and ci_connection (since connections are now managed by the Connection Server) During the upgrade process, the Import Wizard detects dependencies between Application Foundation data and BusinessObjects universes and automatically imports those universes on which the data relies but that were not explicitly selected for import. Verifying the repository import To check that your 6.x repository was successfully migrated, look for the following entry in the Import Wizard trace file: updateaf65db If this entry exists, the 6.x repository was upgraded by the Import Wizard. If you do not see this entry in the file, the repository was not upgraded. Note: To activate the trace, launch the Import Wizard with the -trace option in the command line. This generates a trace file in the $INSTALLDIR\logging folder. Maintaining the source repository during migration The Application Foundation repository migration in the Import Wizard is intrusive to the source repository. The source repository (6.x) is not copied to the destination environment (XI R2); the repository itself is transformed when you migrate the Application Foundation repository in the Import Wizard. When the Import Wizard updates a 6.x repository to XI R2, it modifies existing tables and writes new columns and tables to the repository, making it unreadable in version 6.x. If you plan to continue to deploy the previous version while migrating, perform the following steps: 1. Copy the 6.x Application Foundation repository that you want to migrate. 2. Configure the connections (the universe and document domains and the Application Foundation repository connections) on the source environment so that it functions correctly with the copy of the source repository. 110 BusinessObjects 6.x to XI Release 2 Migration Guide

111 Understanding Application Foundation object migration Migrating the Application Foundation repository and its contents 7 3. Point the Import Wizard to the copy of the source repository. This ensures that only the copy of the source repository is affected by changes made by the Import Wizard. The original source repository remains unchanged. 4. Run the Import Wizard to import objects to the CMS and to migrate the Application Foundation repository. Optionally, you can maintain the source system and continue to develop dashboards, analytics and documents on the 6.x version. You can then import these types of objects to the XI R2 version incrementally as you develop them on the source system, as long as none of the changes affect the source repository (refer to Importing objects incrementally on page 111 for details). Importing objects incrementally You can maintain your source and destination environments in parallel and continue to develop objects that do not require changes to the repository (such as dashboards, analytics, and documents) on the source version. You can then migrate only these new objects to the XI R2 CMS using the Import Wizard, without reimporting the repository. Note: The incremental import feature applies to objects whose creation do not impact the Application Foundation source repository. These include dashboards, analytics, and documents that are stored in the BusinessObjects Enterprise repository or the Application Foundation local storage on the source system and are imported into the destination CMS. This feature therefore does not apply to metrics, whose creation and modification change information stored in the Application Foundation source repository. Once you have migrated the Application Foundation repository, you will no longer be able to migrate objects that rely on data stored within. The Application Foundation repository can only be migrated once. To use the incremental migration feature, select individual objects to import from the source environment, and specify in the Import Wizard that you do not want to import the Application Foundation repository. In this case, the selected objects are imported directly to the XI R2 CMS, and the Application Foundation source repository is not affected. Note: You cannot import schedules, rules containing schedules, events, or universes without migrating the repository. Migrating these objects requires writing information to the performance management repository and may affect the source repository. You may need to import certain objects more than once from the source environment to the destination environment. In this case, the Import Wizard allows you to choose between keeping the source copy or the destination copy of the object after import. BusinessObjects 6.x to XI Release 2 Migration Guide 111

112 7 Understanding Application Foundation object migration Migrating dashboards Migrating repository connections Connections to the Application Foundation repository are also migrated by the Import Wizard. In XI R2, connections are managed by the Connection Server. See the Designer online help for more information on the Connection Server. You can import all universes and connections, or only those universes and connections referenced by the performance management objects (such as dashboards and analytics) that you have selected for import. See If you re migrating Application Foundation on page 281 for information. Each connection you import is stored as an InfoObject in the CMS. Performance management XI R2 makes use of the XI R2 standard connection layer. Performance management XI R2 uses the Connection Server to run the SQL generated by the following performance management engines: Sets SPC Metrics Predictive Connections are configured in Designer and stored in the CMS. See the Designer online help for more information. Migrating dashboards The Import Wizard migrates the information that makes up your Corporate and Personal Application Foundation dashboards. During migration, the Import Wizard imports the analytics, Web Intelligence documents, and BusinessObjects documents that compose your dashboards into the CMS and publishes them as InfoObjects. The XML menus and submenus that define the structure of your applications and dashboards are also migrated. In Application Foundation 6.x, XML menus and submenus were stored in the local storage folder: Application Foundation\Server\conf\menu.xml The Import Wizard publishes dashboards as InfoObjects in the CMS. When you select a dashboard in the Import Wizard, corporate documents referenced by the dashboard are automatically imported. In version 6.x, corporate documents are referenced in dashboards by their docid. During migration, the Import Wizard assigns unique CUIDs to corporate documents 112 BusinessObjects 6.x to XI Release 2 Migration Guide

113 Understanding Application Foundation object migration Migrating dashboards 7 and publishes them in the CMS. The docid that referenced the corporate document in the dashboard is replaced by the new CUID in the dashboard s migrated XML definition. Dashboard menus and submenus In XI R2, menus and submenus are published to the CMS as InfoObjects. The Import Wizard parses the XML definition of the dashboard, and substitutes the DocIDs of the documents and analytics referenced in the dashboard definition by the new CUID supported in XI R2. Applications, menus and submenus are published as InfoObjects. Their structure is maintained. Each dashboard and application is assigned to a folder, and their submenus are stored in subfolders of the main folder. Dashboard security If you migrate security, the security on your Application Foundation 6.x dashboards at the application and menu levels is migrated and maintained in performance management XI R2. User rights stored in the Business Objects repository are now stored in the CMS as access levels, or ACLs. Note: The Import Wizard does not import analytic-level security within dashboards. See Migrating security commands on page 117 for more information. Agnostic documents The Import Wizard imports the following types of agnostic (third-party) documents referenced in dashboards and publishes them to the CMS: SVG, or snapshot views of analytics *.xml and *.swf (flash) *.csv used in custom calendar definition graphic files (such as *.gif, *.bmp, *.png, *.jpg files) used as backgrounds in Strategy Map definitions or Metric Tree backgrounds and in dashboards BusinessObjects 6.x to XI Release 2 Migration Guide 113

114 7 Understanding Application Foundation object migration Migrating analytics The Import Wizard publishes these files as InfoObjects in the destination environment, where they are accessed by the performance management applications that reference them. The CMS also supports the following object types as InfoObjects: programs Microsoft Excel files Microsoft Word files Microsoft PowerPoint files Adobe Acrobat PDFs rich text format files text files hyperlinks object packages, which consist of report and/or program objects Migrating analytics You can use the Import Wizard to migrate analytics (.afd documents) from the BusinessObjects 6.x repository to performance management XI R2. During migration with the Import Wizard, you can select individual analytics for migration to performance management XI R2. The Import Wizard publishes the objects you select for migration in the CMS as InfoObjects. You can migrate both corporate and personal analytics in the Import Wizard. Migrating links to analytics and documents Links in analytics and dashboards to other analytics or documents are migrated by the Import Wizard. The Import Wizard locates links within the dashboards that you have selected for import. The Import Wizard then reads the BusinessObjects repository ID attributed to the target document in version 6.x. During import, the BusinessObjects 6.x repository ID is replaced with a new CUID when documents are published to the CMS. When links are migrated, the Import Wizard replaces the document s BusinessObjects 6.x repository ID in the link with document s XI R2 CUID. The reference to the target document is updated in the link, and the link will therefore open the same document, migrated to the new repository, using its new CUID. 114 BusinessObjects 6.x to XI Release 2 Migration Guide

115 Understanding Application Foundation object migration Migrating schedules 7 Migrating schedules In Application Foundation 6.x, the scheduler was run as an executable on the Application Foundation server. Scheduled tasks were stored in the ci_task table of the Application Foundation repository. The scheduler passed metric refresh information to the metric refresh engine. Application Foundation schedule definitions, rules that contain schedules in their definitions, and named events are imported during the update of the performance management XI R2 repository in the Import Wizard. The Import Wizard retrieves schedule descriptions from the ci_task table in the Application Foundation repository, then publishes and stores all migrated schedules in the CMS. In performance management XI R2, all scheduled tasks are managed by the CMS scheduler. Schedules related to performance management objects are stored in a dedicated performance management folder in the Schedule Manager of the CMS. Note: Application Foundation schedules created with Broadcast Agent are not supported in BusinessObjects Enterprise XI R2 and are therefore not migrated. See What you cannot migrate on page 118 for details. Tip: If you recreate the CMS on the destination environment, make sure that the AFScheduleProgram is present in the CMS before you migrate. If the AFScheduleProgram is not available, and you migrate the repository, you could lose the schedules in the source repository during migration. Troubleshooting schedule migration The situations described below may lead to an incomplete migration of schedules from the Application Foundation repository. Migrating with user credentials that are no longer valid If you attempt to migrate schedules with administrator credentials that are no longer valid, the AFScheduleProgram is created with invalid security credentials. The migration is successful, but migrated schedules will not work. To manually correct this problem after migration: 1. Log into performance management with a valid administrator profile. 2. In Setup > Parameters > Options > Scheduler Parameters, update the user account under which scheduled programs will run. 3. In Setup > Tools > Check & Cleanup, click Scheduled Programs to launch the Check & Cleanup Scheduled Programs window. 4. Click Select All then Fix to update all scheduled programs. BusinessObjects 6.x to XI Release 2 Migration Guide 115

116 7 Understanding Application Foundation object migration Migrating rules and named events Migrating schedules after reinstalling the CMS If you reinstall the CMS and the AFScheduleProgram is missing from the CMS, attempts to migrate schedules will fail. To manually correct this problem before migration: 1. Log into the CMC, and delete any AFScheduleProgram instances that may have been created (AFScheduleProgram instances are created when users attempt to access schedules). 2. Log into performance management XI R2 with a valid administrator profile. 3. In Setup > Parameters > Options > Scheduler Parameters, update the user account under which scheduled programs will run. 4. Migrate schedules to performance management XI R2. If schedules do not migrate correctly, perform the following steps after migration: 1. Log into performance management with a valid administrator profile. 2. In Setup > Parameters > Options > Scheduler Parameters, update the user account under which scheduled programs will run. 3. In Setup > Tools > Check & Cleanup, click Scheduled Programs to launch the Check & Cleanup Scheduled Programs window. 4. Click Select All then Fix to update all scheduled programs. Migrating rules and named events Rules are composed of events, conditions and actions. In Application Foundation 6.x, rules are stored in the Application Foundation repository. In XI R2, rule definitions continue to be stored in the ci_rule table in the performance management repository but are managed in various locations depending on the event type: Scheduled tasks are managed by the CMS scheduler (see Migrating schedules on page 115). Named events are launched by the Event server and managed in the Central Management Console. The event is then passed on to the appropriate performance management server for execution. During migration, named events are imported into the CMS. Named events can be referenced in a rule defined in performance management. Events based on the refresh of metrics and other performance management objects continue to be managed in the performance management repository. 116 BusinessObjects 6.x to XI Release 2 Migration Guide

117 Understanding Application Foundation object migration Migrating security commands 7 During migration with the Import Wizard, schedules and rules containing scheduled tasks are imported from the Application Foundation repository to the CMS. Links to documents within rule definitions are updated in the ci_rule table during migration of the Application Foundation repository. Note: Rules that contain actions requiring the pre-rendering of HTML by the Broadcast Agent scheduler are migrated, but these types of actions are no longer supported in performance management XI R2. See Broadcast Agent schedules on page 119 for details. Migrating security commands Application Foundation 6.x security is defined: in security commands in the Business Objects repository in security commands associated with the Application Foundation application in Supervisor in custom security commands created with appsecurity.exe In XI R2, security is managed in the CMS. If you decide to import security, when you migrate Application Foundation objects, the Import Wizard reads the current access rights, converts them into ACLs, then applies the appropriate ACL to the appropriate InfoObject. For example, the Import Wizard reads the access rights applied to a specific dashboard and its submenus, publishes the access rights as ACLs, then applies them as required to the InfoObjects referenced by the dashboard. Security commands applied to individual analytics within a dashboard are not migrated by the Import Wizard. Objects must be published in the CMS in order to be secured individually with ACLs. Choose one of the following options for migration of dashboards with analytic-level security restrictions: The Import Wizard migrates the dashboard and any sub-menus and applies standard page-level security, which is translated as an ACL in the CMS. With this option, the least restrictive set of rights is applied. The Import Wizard skips any dashboards with analytic-level security restrictions during migration. The Import Wizard migrates dashboards with analytic-level security restrictions and saves them directly in an access-restricted folder. The administrator can then modify these dashboards manually before publishing them to a wider audience. BusinessObjects 6.x to XI Release 2 Migration Guide 117

118 7 Understanding Application Foundation object migration What you cannot migrate Managing user rights in Performance Management XI R2 To manage ACL rights for Performance Management users 1. Launch the Central Management Console. 2. In the Manage menu, select BusinessObjects Applications. 3. Select Performance Management from the list of applications. 4. In the Rights tab, click Check User Rights to display a detailed list of rights per user or user group, or click Add/Remove to change the rights currently granted to users or groups. See the BusinessObjects Enterprise XI Release 2 Administrator s Guide for more details on managing ACLs. Managing rights at the object level in Performance Management XI R2 In performance management XI R2, you can grant rights to corporate analytics, application menus, documents and folders in the Central Management Console. In performance management XI R2, you cannot create custom security commands as you could in Application Foundation 6.x. Use the Central Management Console to secure individual objects. See the BusinessObjects Enterprise XI Release 2 Administrator s Guide for more details on managing object-level security. The following sections describe product features and objects that cannot be migrated from Application Foundation 6.x. What you cannot migrate The following sections describe product features and objects that cannot be migrated from Application Foundation 6.x. 118 BusinessObjects 6.x to XI Release 2 Migration Guide

119 Understanding Application Foundation object migration What you cannot migrate 7 Analytic-level security within dashboards Security on dashboards, application menus and submenus are migrated by the Import Wizard. Restrictions on individual analytics on a dashboard page are not migrated, however. See Migrating security commands on page 117 for more information. Broadcast Agent schedules In Application Foundation 6.x, you can use the Broadcast Agent to schedule a cache preload for faster HTML rendering. This feature no longer exists in XI R2. The following options are no longer available: When you customize the properties of BusinessObjects documents imported into dashboards, the Only look for documents in personal inbox option no longer exists. When you customize the properties of BusinessObjects documents imported into dashboards, the Use Pre-generated HTML when available option no longer exists. When you create or edit rules on the Rules page of Dashboard Manager, the Schedule HTML generation option no longer exists. Application Foundation 6.x rules containing actions that required prerendering are migrated in the Import Wizard. The action that calls for prerendering a document is not executed. Tip: You can check the integrity of rules on the Tools tab of the System menu. When you run the integrity check on rules, it detects rules that include actions requiring document pre-rendering with Broadcast Agent scheduler. After you determine which migrated rules contain obsolete actions, you can edit the rule to delete the obsolete actions or delete the rule entirely. Application Foundation 6.x Corporate and Personal dashboards containing BusinessObjects documents on which pre-rendering was activated are migrated in the Import Wizard. When the impacted document is called, it is rendered normally without preloading the cache. BusinessObjects 6.x to XI Release 2 Migration Guide 119

120 7 Understanding Application Foundation object migration What you cannot migrate 120 BusinessObjects 6.x to XI Release 2 Migration Guide

121 BusinessObjects 6.x to XI Release 2 Migration Guide Understanding rights migration chapter

122 8 Understanding rights migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails Comparison of the security models Standard migration paths Special import scenarios Rights by product/component 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Security overview Although the rights model for versions XI R2 and 6.x may seem similar at first glance, fundamental differences between the inheritance, aggregation, and default rules of versions 6.x and XI R2 can complicate rights migration. For example, some version 6.x security commands are phrased in such a way that granting them is actually placing a restriction on the user or group; e.g. a user may be granted the right to Do not delete other user's documents. In XI R2, all rights increase a user's power when they are granted, so negatively-phrased 6.x rights are rephrased positively in XI R2, and the value of the corresponding right is reversed during migration. This chapter provides an overview of the rights models for versions 6.x and XI R2, describes how their differences impact migration, and then explains the approaches adopted to ensure equivalent rights in the migrated model. Note: You do not have to import rights when importing your BI content to XI R2. For information concerning whether to import security or rebuild security in the destination environment from scratch, see Importing security or not on page BusinessObjects 6.x to XI Release 2 Migration Guide

123 Understanding rights migration Security overview 8 Rights terminology The following table contains basic terminology you need to know to understand the security models and rights migration. Term collapse custom rights explicit vs. effective rights newly-denied newly-enabled newly-granted Definition If certain conditions are met on objects in 6.x, we need to set rights directly on the corresponding object(s) in XI R2. This may involve setting rights that were not explicitly set on the relevant 6.x objects (due to the difference in aggregation models). This process of copying explicit rights from 6.x is known as collapsing rights on the XI R2 object. In most cases, inheritance is broken when collapsing is done. Rights that are defined in the plugin pinfile for an object type (not including the meta-plugin types). The CMS is not aware of custom rights and cannot enforce them: they are enforced by the SDK. Explicit rights are set directly on the object, while effective rights are the net result rights considering inheritance, aggregation, and default settings. When determining whether a user is able to perform an action, it is only the effective rights that are important. A right that is effectively denied on the principal but effectively granted on the principal's parent (that is, granted explicitly or via inheritance). A security command that is effectively enabled on the principal but effectively denied or hidden on the principal's parent (explicitly or via inheritance). A right that is effectively granted on the principal but effectively denied on the principal's parent (that is, denied explicitly or via inheritance). BusinessObjects 6.x to XI Release 2 Migration Guide 123

124 8 Understanding rights migration Comparison of the security models Term principal View right Definition A user or group, typically one for whom rights are set on some object Abbreviation for the most basic access right to XI R2 objects. When referring to application objects, it corresponds to a version 6.x product access right (in the CMC, the option is worded Log on to <application_name> and view this object in the CMC). It gives users/groups the right to launch and use a product. When referring to other objects, it confers the right to access and view the object. Comparison of the security models 6.x vs. XI R2 rights types All XI R2 rights are Boolean, which is to say, Granted, Denied, or unspecified. Version 6.x Version XI R2 Product access rights Application rights are set on The right to use products such as application objects (like the Designer Web Intelligence and Designer, e.g. or Supervisor application object). Joe tries to log into Designer, but his The View right, which controls the product access right for Designer is user s ability to launch and use an Denied so his logon fails. application, corresponds to a version There is one product access right per 6.x product access right. product per user. 124 BusinessObjects 6.x to XI Release 2 Migration Guide

125 Understanding rights migration Comparison of the security models 8 Version 6.x Security commands The right to use certain features of a product. Security command rights are associated with a product such as Web Intelligence or Designer and typically correspond to actions such as Save docs or Rename docs; these are usually distinct actions offered by the user interface. Possible values are: Enabled (UI element visible) Disabled (UI element grayed-out) Hidden (UI element not shown) If the right is not specified, it is considered enabled. Applications can have multiple security commands. Domain access rights The right to access the contents of a universe or document domain. Universe/document access The right to access individual universes or documents. Users need both the domain access right and the universe/document right to use a document or universe. Other rights such as overloads and object level security (not discussed in this chapter). Version XI R2 In XI R2, security commands can be equivalent to application rights set on application objects (like the Designer or Supervisor application object), or object rights, set on content objects or the folder that contains them (like universe or Web Intelligence document objects or domain folders). For detailed information on how each 6.x security command migrates to XI R2, see Rights by product/ component on page 150. Many security commands, however, have no meaning in the XI R2 system and are therefore not migrated. Object rights are set on content objects or the folder that contains them (like universe or Web Intelligence document objects or domain folders). BusinessObjects 6.x to XI Release 2 Migration Guide 125

126 8 Understanding rights migration Comparison of the security models 6.x vs. XI R2 default and aggregate rules per right type The fundamental default and aggregate rules governing rights change in version XI R2, to maintain tighter system security. In the following table, blue columns contain version 6.x information, and white columns display XI R2 information. Right Type (6.x) Product access right Security command Domain access right Document/ universe access right Default Value in Version 6.x Granted (Except for Designer and Supervisor access rights, which are set to Denied on the root folder at install time.) Default Value in Version XI R2 Denied Aggregation Rules in Version 6.x If Granted or unspecified anywhere: Granted If Denied everywhere: Denied Enabled Denied If Hidden anywhere, then Hidden If Disabled anywhere, then Disabled Otherwise, Enabled Granted Denied If Granted (or unspecified) anywhere: Granted Denied Denied If Granted anywhere: Granted Aggregation Rules in Version XI R2 If unspecified or Denied anywhere, then Denied Hidden in 6.x = Denied in XI R2 If unspecified or Denied anywhere, then Denied If unspecified or Denied anywhere, then Denied If unspecified or Denied anywhere, then Denied Universe restriction set aggregation When are access restrictions aggregated? Users generally belong to multiple groups, as they are all part of the Everyone group and are likely to belong to at least one other group. In version 6.x, a user can have multiple instances. For users with multiple instances, instance priorities (defined in Supervisor) are used to resolve conflicts. 126 BusinessObjects 6.x to XI Release 2 Migration Guide

127 Understanding rights migration Comparison of the security models 8 In XI R2, there is no notion of user instances. Users can inherit from multiple groups, so group priorities are used to resolve conflicts: Users have higher priority than groups. Priority 1 is the highest priority. You can preview net restrictions for any given user or group. Restriction preview is available for all 6 tabs. Connection overloads In version 6.x, connection overloads are defined in Supervisor. In XI R2, connection overloads are part of access restrictions. Use Designer to define an access restriction. 6.x vs. XI R2 inheritance The main challenge during migration is the difference in inheritance rules between version 6.x and XI R2: In 6.x, rights inheritance is propagated through groups only. For example, because Tom and Lea belong to the Marketing group, they inherit all the rights established for the Marketing group. BusinessObjects 6.x to XI Release 2 Migration Guide 127

128 8 Understanding rights migration Comparison of the security models In XI R2, rights are inherited both through groups and through objects. In this environment, for example, Tom and Lea would still inherit all Marketing group rights. In addition, however, if the rights set for the Sales Results folder allowed Tom to access that folder, if no subfolder or document rights contradicted that right, Tom would automatically have access to all the documents in that folder. Version 6.x Version XI R2 The only type of rights inheritance is group inheritance. When a right is set on a group it applies to all subgroups, unless it is overridden for a subgroup or user. Rights set lower down in the group tree take priority. That is, rights on an user's parent take priority over those on the grandparent, and so on. Both group and folder inheritance exist. Rights are inherited from ancestor objects and groups, unless either type of inheritance is explicitly turned off. Turning off inheritance prevents that type (group or object) of inheritance for all the rights for a principal (user or group) on an object. You cannot turn off inheritance for some rights but not others. Inherited rights are equal to explicit rights, and when rights conflict, denied always takes priority, regardless of the source of the conflicting rights. Because of this model, and because denied takes priority over granted, you cannot give child users or groups more rights than their parents without breaking inheritance. You can change a right from unspecified (effectively denied) to granted, but not from denied to granted. Breaking inheritance in XI R2 In the XI R2 inheritance model, you must break inheritance if you want to grant a right for a child that has been specifically denied for a parent. (Partly for this reason, the XI R2 BusinessObjects Enterprise SDK automatically breaks the inheritance when a role is set on a principal.) Breaking inheritance allows XI R2 to imitate the 6.x inheritance model somewhat, but the break applies to all rights; you cannot turn off inheritance for some rights but not others. 128 BusinessObjects 6.x to XI Release 2 Migration Guide

129 Understanding rights migration Standard migration paths 8 In XI R2 you can break both group and folder inheritance. Breaking group inheritance however is more important to consider during import, because hierarchical folders do not exist in version 6.x. Standard migration paths User right migration Key security features provided by BusinessObjects 6.x (as applied to the integrated components) are available in version XI R2. Along with the ability to specify rights at the object level, version XI R2 provides the ability to specify global rights for Web Intelligence, Desktop Intelligence, and Performance Management Applications. BusinessObjects 6.x to XI Release 2 Migration Guide 129

130 8 Understanding rights migration Standard migration paths Right type in version 6.x Product access rights The following identifies the migration path for integrated rights: Migrated to version XI R2 as... Right to view application object (View right) For more information, see Application rights migration on page 132. Security commands Right to corresponding application object, domain folder, or content object For more information, see Application rights migration on page 132. BusinessObjects security commands migrate as rights set on: the Desktop Intelligence application (application rights) Desktop Intelligence documents or document domain folders (object rights) Web Intelligence security commands migrate as rights set on: the Web Intelligence application the InfoView application Web Intelligence documents or document domain folders Designer security commands migrate as rights set on: the Designer application universe domain folders Value migration: 6.x = XI R2 Granted = Granted Denied = unspecified Positively-phrased security commands: Hidden = Denied Denied = Denied Unspecified = Denied Negatively-phrased security commands: Granted = Denied Denied = Granted Unspecified = Granted (See Negatively- and positively-phrased security command migration below.) Some security commands are combined when they are migrated. See the following section. 130 BusinessObjects 6.x to XI Release 2 Migration Guide

131 Understanding rights migration Standard migration paths 8 Right type in version 6.x Domain access rights Document/universe access rights Migrated to version XI R2 as... Right to view corresponding domain folder (domains are migrated as folders, and their universes/documents as child objects of the domain folder) For more information, see Document/universe domain rights migration on page 136. Child universes/documents inherit folder rights unless inheritance is broken. Right to view corresponding content object For more information, see Document/universe rights migration on page 143. Value migration: 6.x = XI R2 Granted = Granted Denied = Denied Unspecified = Denied The value of the migrated domain access right affects the value of migrated security commands and document access rights. See Combining security commands during migration below. Combining security commands during migration Some security commands are combined when they are migrated in order to better map to XI R2 rights. When two or more 6.x security commands are mapped to the same XI R2 boolean right, both commands must be granted for the XI R2 right to be granted; otherwise the XI R2 right is denied. For example, the two 6.x commands Generate in PDF Format and Generate in Excel Format are migrated as the single right Export. The Export right is set to granted only if both the Generate in PDF Format and Generate in Excel Format rights are set to granted in the source environment. If this is not the case, the Export right is denied. Negatively- and positively-phrased security command migration Negatively-phrased security commands are migrated differently than positively-phrased ones, because the negatively-phrased rights are reworded to be positively-phrased during migration. For example, if the fictional 6.x right You cannot delete were denied, then the user would have the right to delete. During migration, the right is changed to You can delete, and so its value is migrated as granted. The net result is that the user still has the right to delete. BusinessObjects 6.x to XI Release 2 Migration Guide 131

132 8 Understanding rights migration Special import scenarios The following table shows how version 6.x negatively- and positively-phrased security commands are migrated. Positively-phrased security commands Granted are migrated as Granted Denied are migrated as Denied Negatively-phrased security commands Granted are migrated as Unspecified Denied are migrated as Granted Special import scenarios Rights collapsing Whenever you use the Import Wizard, you choose the groups you want to import. You can migrate a user or group, known generically as a principal, without a parent. This is always the case when the principal is a root group itself, and therefore has no parents. This is also the case when the principal has a parent in the source deployment, but you choose not to migrate it. For users, this is true if any of the groups to which it belongs is not imported. This case typically triggers rights collapsing. When a parent group is not migrated, inheritance is broken, and the children become roots themselves. The children are not reconnected to their grandparents; instead, rights are collapsed on these new roots. Although the parent is not migrated, any rights set explicitly on the parent are still considered when collapsing the rights on the now-orphaned child. In general, the effective rights of imported principals are preserved, even if other principals which contribute to those rights (such as grandparents) are not imported. Application rights migration The following 6.x rights can be migrated to an application object in XI R2: Product access rights Security commands 132 BusinessObjects 6.x to XI Release 2 Migration Guide

133 Understanding rights migration Special import scenarios 8 Full collapse When application objects are migrated, a full collapse of rights is triggered for users/groups in the following cases: A principal is being imported without a parent. The effective product access right for a principal is newly-granted. A security command is newly-enabled for the principal. A full collapse for application objects means that: Group and folder inheritance is broken. The effective security commands on the 6.x application object are calculated and mapped to the application object in XI R2. The effective product access right is calculated and set on the application object as a View right. BusinessObjects 6.x to XI Release 2 Migration Guide 133

134 8 Understanding rights migration Special import scenarios Migration (no full collapse) In some cases in migration, for the sake of efficiency, rights that are not required are not explicitly set, but left unspecified after the import. Import scenario 1 (application objects) Principal Imported with parent Product access right for principal Newly-granted Result The View right is set as Granted 134 BusinessObjects 6.x to XI Release 2 Migration Guide

135 Understanding rights migration Special import scenarios 8 Import scenario 1 (application objects) Principal Principal s security command Result Imported with parent Effectively hidden, or disabled, but effectively enabled for parent Set as Granted for principal, and unspecified for the parent (if positivelyphrased) BusinessObjects 6.x to XI Release 2 Migration Guide 135

136 8 Understanding rights migration Special import scenarios Document/universe domain rights migration Document and universe domains are migrated as folders. The following 6.x rights can be migrated to a domain folder in XI R2: Domain access rights Security commands Domain right rules Remember that: Some security commands on the Designer application are migrated as XI R2 rights on universe domain folders. Some security commands for the Web Intelligence application are migrated as XI R2 rights on document domain folders. Rights set on documents or universes in the domain may affect rights set on the domain itself (see Document/universe rights migration on page 143). Documents contained in a folder inherit the rights from their parent domain folder, unless inheritance is broken. Full collapse In some domain folder imports, a full collapse of rights is triggered. This means: Group and folder inheritance is broken. The effective values for object-level security commands are mapped to the domain folder. Full collapsing on the domain folder is triggered in the following cases. 136 BusinessObjects 6.x to XI Release 2 Migration Guide

137 Understanding rights migration Special import scenarios 8 Special import scenario 1 (domain rights) Principal Principal s domain access right Result Imported without parent Effectively granted Full collapse: View right is added as Granted, and is inherited by all documents in folder BusinessObjects 6.x to XI Release 2 Migration Guide 137

138 8 Understanding rights migration Special import scenarios Special import scenario 2 (domain rights) Principal Principal s domain access right Result Imported without parent Effectively granted Full collapse: View right is added as Granted, and is inherited by all documents in folder 138 BusinessObjects 6.x to XI Release 2 Migration Guide

139 Understanding rights migration Special import scenarios 8 Special import scenario 3 (domain rights) Principal Principal s domain access right Principal s security commands Result Imported with parent(s) Granted Has a newly-enabled security command Full collapse: View right is added as Granted, and inherited by all documents in folder BusinessObjects 6.x to XI Release 2 Migration Guide 139

140 8 Understanding rights migration Special import scenarios Migration (no full collapse) The following particular migration cases exist: Special import scenario 4 (domain rights) Principal Principal s domain access right Principal s security commands Result Imported with parent(s) Granted, but not newly-granted No newly-enabled security commands Full collapse: View right is added as Granted, and inherited by all documents in folder Applicable, newly-denied security commands are mapped to this domain. (In this case, only newly-denied security commands are migrated. If a security command was denied for the parent, it is inherited as Denied in the new system; to reduce the number of rights that are explicitly set, it is not migrated.) 140 BusinessObjects 6.x to XI Release 2 Migration Guide

141 Understanding rights migration Special import scenarios 8 BusinessObjects 6.x to XI Release 2 Migration Guide 141

142 8 Understanding rights migration Special import scenarios Special import scenario 5 (domain rights) Principal Imported with parent(s) Principal s domain access right newly-denied Result No security commands are migrated (as the principal doesn t have access to the domain, they would be irrelevant). No View rights are added. Group and folder inheritance are broken. 142 BusinessObjects 6.x to XI Release 2 Migration Guide

143 Understanding rights migration Special import scenarios 8 Document/universe rights migration Document and universe access rights in 6.x are migrated to XI R2 as View rights on the corresponding document or universe object. Note: Everything described for documents in this section also holds true for universes as well. Net access for documents/universes A document's net access is the document access right aggregated with the domain access right. This means that if either the document access or domain access right is denied, the document access right is denied. The view right on the document can also be inherited from the view right on the folder to which it belongs in the destination system. Migration (no full collapse) The following migration cases exist: Special import scenario 1 (domains/universes) Principal Imported with parent Imported without parent Net document access newly-granted Granted Result: Any applicable security commands that were set on the corresponding application are migrated directly to the document domain containing the document. Rights are migrated like this because a newly-granted document right could mean that inheritance will be broken somewhere up the group structure. If inheritance is broken, then the security commands will not be inherited properly and therefore need to be explicitly migrated. The concepts in this paragraph are illustrated in the two diagrams below. In the first case (Case A) the containing domain has the View right explicitly granted during migration. This View right will be inherited by the document in BusinessObjects 6.x to XI Release 2 Migration Guide 143

144 8 Understanding rights migration Special import scenarios that domain folder. In the second case (Case B), the containing domain will not have the view right explicitly granted when it is migrated. Therefore it must be explicitly added to this document as Granted. 144 BusinessObjects 6.x to XI Release 2 Migration Guide

145 Understanding rights migration Special import scenarios 8 Case B BusinessObjects 6.x to XI Release 2 Migration Guide 145

146 8 Understanding rights migration Special import scenarios Special import scenario 2 (domains/universes) Principal Net document access Result: Imported with parent newly-denied Both folder and group inheritance are broken. Net document access (document access combined with domain access) is newly-denied. Both folder and group inheritance are broken. 146 BusinessObjects 6.x to XI Release 2 Migration Guide

147 Understanding rights migration Special import scenarios 8 BusinessObjects 6.x to XI Release 2 Migration Guide 147

148 8 Understanding rights migration Special import scenarios Special import scenario 3 (domains/universes) Principal Net document access Containing domain Result: Imported with parent Denied View right = Granted Both folder and group inheritance are broken. 148 BusinessObjects 6.x to XI Release 2 Migration Guide

149 Understanding rights migration Special import scenarios 8 Connection objects (stored procedure rights) migration A stored procedure is a group of SQL statements that perform a particular task. Stored procedures are kept in the database. Version 6.x stored procedure rights, migrated as rights to database connection objects, control access to the stored procedures kept on that database. Granted stored procedure rights are migrated as Granted, and denied stored procedure rights are migrated as unspecified. Connections are secured in XI R2 but not in version 6.x. The following XI R2 rights are therefore always set to Granted on the connection object: connection access right View right In addition, the stored procedure right is migrated to the connection object. By default, new connection rights are disabled in XI R2, just as they are in 6.x. Full collapse A full collapse of rights is triggered on connection objects when: a principal is imported without a parent the stored procedure right for a principal is newly-denied Special import scenario (stored procedures) Principal Principal s stored procedure right Result: Imported without parent newly-denied Full collapse Full collapse for a connection object means: folder and group inheritance are broken the View right is added as Granted the data access right is added as Granted the stored procedure right is added: Granted is migrated as Granted Denied is migrated as unspecified BusinessObjects 6.x to XI Release 2 Migration Guide 149

150 8 Understanding rights migration Rights by product/component Migration (no full collapse) Special import scenario (stored procedures) Principal Principal s stored procedure right Result: Imported with parent newly-granted The stored procedure right to the connection object is added as Granted. Rights by product/component This section includes: BusinessObjects/Desktop Intelligence rights Web Intelligence/Web Intelligence rights Designer rights Connection rights Note: In this section, XI R2 rights: beginning with the words securely modify mean that the user with this right can only grant or deny rights that they have themselves to other users. ending with on objects that the user owns are calculated based on who the owner of the object is BusinessObjects/Desktop Intelligence rights This section covers: Application rights in the destination vs. source environments Document rights (.rep or.rea) How source BusinessObjects security commands migrate Application rights in the destination vs. source environments The following table lists access rights for the BusinessObjects application, their values for the View access level, and how they are migrated from version 6.x. 150 BusinessObjects 6.x to XI Release 2 Migration Guide

151 Understanding rights migration Rights by product/component 8 In this table: General rights are those that BusinessObjects inherits from application rights (Application object). Custom rights are those which concern BusinessObjects only. No Access means all rights are Denied; Full Control means that all rights are Granted. General rights in XI R2 View Rights in source environment Log on to BusinessObjects and Granted N/A view this object in the CMC Edit this object Inherited N/A Modify the rights users have to Inherited N/A this object Securely modify rights users have to objects Inherited N/A Custom rights in XI R2 View Rights in source environment Drill Through Granted Drill Through Edit Scope of Analysis Granted Edit Scope of Analysis Work in Drill Mode Granted Work in Drill Mode Work in Slice-and-Dice Mode Granted Work in Slice-and-Dice Mode Create And Edit Connections Inherited Create And Edit Connections Copy to Clipboard Inherited Copy to Clipboard Create Documents Inherited Create Documents Create Templates Inherited Create Templates Data Provider Manipulation Inherited Data Provider Manipulation Document Interactions Inherited Document Interactions Edit Euro Converter Rate Inherited Edit Euro Converter Rates Euro Converter Inherited Euro Converter Manage All Corporate Categories Manage My Corporate Categories Inherited Inherited Manage All Corporate Categories Manage My Corporate Categories Print Documents Granted Print Documents Refresh Document List and Inherited Refresh Documents Categories BusinessObjects 6.x to XI Release 2 Migration Guide 151

152 8 Understanding rights migration Rights by product/component Custom rights in XI R2 View Rights in source environment Refresh Document Granted Refresh Documents Report Interactions Granted Report Interactions Import Documents Granted Either Retrieve Documents from Other Users, or Retrieve Documents from Repository Save Documents Granted Save Documents Save documents for all users Inherited Save for All Users Send Documents to MAPI Granted Send Documents to MAPI Export Documents Granted Send Documents to Repository Use Templates Inherited Use Templates Edit Free-hand SQL Inherited Edit Free-hand SQL Scripts Use Free-hand SQL Inherited Use Free-hand SQL Edit Personal Data Files Inherited Edit Personal Data Files Use Personal Data Files Inherited Use Personal Data Files Edit Stored Procedures Inherited Edit Stored Procedures Use Stored Procedures Inherited Use Stored Procedures Edit VBA Code Inherited Edit Scripts/VBA Code Install Add-Ins Inherited Install and Uninstall Add-Ins Run VBA Code Granted Run Scripts/VBA Code Always Regenerate SQL Inherited Negation of (Do not always regenerate SQL) Use Queries Inherited Use Queries Use List of Values Inherited Use Lists of Values Use User Objects Inherited Use User Objects Edit Queries Inherited Edit Query Edit List of Values Inherited Edit Lists of Values Edit Query SQL Inherited Edit Query SQL Refresh List of Values Inherited Refresh Lists of Values Use other SQL requests than Select Inherited Negation of (Restrict SQL to Select only) View SQL Inherited View Query SQL Change Password Inherited Change Password 152 BusinessObjects 6.x to XI Release 2 Migration Guide

153 Understanding rights migration Rights by product/component 8 By default, the following ACEs are created for the BusinessObjects application: The Administrators group has the Full-Control access level for this application. The Everyone group has the View access level for this application. Document rights (.rep or.rea) In version XI R2, you can set rights on reports or add-in Desktop Intelligence documents. As these objects use the same desktop plug-in in the XI R2 framework, they have the set of rights. The following table lists these rights and their values for View, Schedule and View on Demand access levels. For the No Access role, all rights are Denied; for the Full Control role, all rights are Granted. Like Web Intelligence documents, Desktop Intelligence documents inherit General rights, and have their own set of custom rights. General rights for Desktop Intelligence documents Add objects to the folder View Schedule View on Demand Not Specified Not Specified Not Specified View objects Granted Granted Granted Edit objects Not Specified Not Specified Not Specified Modify the rights users have to Not Specified Not Specified Not Specified objects Schedule the document to run Not Specified Granted Granted Delete objects Not Specified Not Specified Not Specified Define server groups to Not Specified Granted Granted process jobs Delete instances Not Specified Not Specified Not Specified Copy objects to another folder Not Specified Granted Granted Schedule to destinations Not Specified Granted Granted View document instances Granted Granted Granted Pause and Resume document Not Specified Not Specified Not Specified instances Securely modify rights users Not Specified Not Specified Not Specified have to objects Reschedule instances Not Specified Not Specified Not Specified BusinessObjects 6.x to XI Release 2 Migration Guide 153

154 8 Understanding rights migration Rights by product/component General rights for Desktop Intelligence documents Schedule on behalf of other Not Specified Not Specified Not Specified users View objects that the user Not Specified Not Specified Not Specified owns Edit objects that the user owns Not Specified Granted Granted Modify the rights that users Not Specified Not Specified Not Specified have to objects that the user owns Delete objects that the user owns Delete instances that the user owns View document instances that the user owns Pause and Resume document instances that the user owns Securely modify rights users have to objects that the user owns Reschedule instances that the user owns Custom rights for Desktop Intelligence documents Refresh the report s data Edit Query View Schedule View on Demand Not Specified Not Specified Not Specified Not Specified Granted Granted Not Specified Not Specified Not Specified Not Specified Granted Granted Not Specified Not Specified Not Specified Not Specified Granted Granted View Schedule View on Demand Not Specified Not Specified Granted Not Specified Not Specified Not Specified Refresh List of Values Not Specified Granted Granted Use List of Values Not Specified Granted Granted View SQL Not Specified Not Specified Not Specified Export the report s data Not Specified Granted Granted Download files associated with Not Specified Not Specified Not Specified the object 154 BusinessObjects 6.x to XI Release 2 Migration Guide

155 Understanding rights migration Rights by product/component 8 How source BusinessObjects security commands migrate The following table shows how version 6.x security commands are migrated to version XI R2, and the mechanism by which each security command is enforced. Some rights are mapped to a right that can be set both at the application and document level, but 6.x security commands are migrated at the application level only. Note: BusinessObjects 6.x releases prior to version 6.5 may not include all of these security commands BusinessObjects security commands in source environment XI R2 rights Enforced by Analysis Drill Through Drill Through Desktop Intelligence Edit Scope of Analysis Edit Scope of Analysis Desktop Intelligence Work in Drill Mode Work in Drill Mode Desktop Intelligence Work in Slice-and-Dice Mode Work with BusinessMiner Connections Create and Edit Connections Documents Work in Slice-and-Dice Mode (Application no longer used) Create and Edit Connections Desktop Intelligence Desktop Intelligence Attach Scripts to (Not used in XI R2) Scheduled Processing Change File Locations (Not used in XI R2) Conditional Formatting (Not used in XI R2) Copy to Clipboard Copy to Clipboard Desktop Intelligence Create Documents Create Documents Desktop Intelligence Create Templates Create Templates Desktop Intelligence Data Provider Manipulation Delete Corporate Documents Sent by Other Users Data Provide Manipulation (Not needed, enforced by framework) Desktop Intelligence CMS BusinessObjects 6.x to XI Release 2 Migration Guide 155

156 8 Understanding rights migration Rights by product/component BusinessObjects XI R2 rights Enforced by security commands in source environment Do Not Refresh with the (Not used in XI R2) Profile of Each Recipient Document Interactions Document Interactions Desktop Intelligence Edit Euro Converter Rate Edit Euro Converter Rate Desktop Intelligence Euro Converter Euro Converter Desktop Intelligence Manage All Corporate Categories Manage My Corporate Categories Manage All Corporate Categories Manage My Corporate Categories Desktop Intelligence Desktop Intelligence Print Documents Print Desktop Intelligence Refresh Document List and Categories Refresh Document List and Categories Desktop Intelligence Refresh Documents Refresh Document Desktop Intelligence + document (refresh the report s data) Report Interactions Report Interactions Desktop Intelligence Retrieve documents from Import Documents Desktop Intelligence Other Users Retrieve Documents from Repository Import Documents Desktop Intelligence Retrieve Documents from Scheduled Processing (Not a BusinessObjects right - Enforced by framework) Job Server Save Documents Save Documents Desktop Intelligence Save documents for all users Schedule Corporate Documents Send Documents for Scheduled Processing Save documents for all users (Not a BusinessObjects right - Enforced by framework) (Not a BusinessObjects right - Enforced by framework) Desktop Intelligence CMS Job Server Send Documents to MAPI Send Documents to MAPI Desktop Intelligence Send Documents to Other (Not used in XI R2) Users 156 BusinessObjects 6.x to XI Release 2 Migration Guide

157 Understanding rights migration Rights by product/component 8 BusinessObjects XI R2 rights Enforced by security commands in source environment Send Documents to Export Documents Desktop Intelligence Repository Use Broadcast Agent (Not used in XI R2) Console Use Templates Use Templates Desktop Intelligence Work with Web Server (Broadcast Agent publishing a document on the Web in HTML format. Not used in XI R2) Free-hand SQL Edit Free-hand SQL Edit Free-hand SQL Desktop Intelligence Scripts Use Free-hand SQL Use Free-hand SQL Desktop Intelligence Miscellaneous Cannot View User/Groups (Not used in XI R2) Hierarchy View All Users (Not used in XI R2) Multi-dimensional data Edit DB2 OLAP Data (Not used in XI R2) Edit Essbase Query (Not used in XI R2) Edit Express Query (Not used in XI R2) Use DB2 OLAP Data (Not used in XI R2) Use Essbase Data (Not used in XI R2) Use Express Data (Not used in XI R2) Personal data files Edit Personal Data Files Edit Personal Data Files Desktop Intelligence Use Personal Data Files Use Personal Data Files Desktop Intelligence Programmability Download VBA from Web Intelligence (Used only by version 5 users) Import/convert scripts (Used only by version 5 users) BusinessObjects 6.x to XI Release 2 Migration Guide 157

158 8 Understanding rights migration Rights by product/component BusinessObjects XI R2 rights Enforced by security commands in source environment Edit Scripts/VBA Code Edit VBA Code Desktop Intelligence Install and Uninstall Add- Install Add-Ins Desktop Intelligence Ins Run Scripts/VBA Code Run VBA Code Desktop Intelligence Query Technique Do not Always Regenerate SQL Always Regenerate SQL (Negative rephrasing!) Desktop Intelligence Edit List of Values Edit List of Values Desktop Intelligence Edit Query Edit Query Desktop Intelligence + document (Edit Query) Edit Query SQL Edit Query SQL Desktop Intelligence Refresh List of Values Refresh List of Values Desktop Intelligence + document (Refresh List of Values) Restrict SQL to Select Only Use other SQL Requests than Select (Negative rephrasing!) Desktop Intelligence Use List of Values Use List of Values Desktop Intelligence + document (Use List of Values) Use Queries Use Queries Desktop Intelligence Use User Objects Use User Objects Desktop Intelligence View Query SQL View SQL Desktop Intelligence + document (View SQL) Stored procedures Edit Stored Procedures Edit Stored Procedures Desktop Intelligence Use Stored Procedures Use Stored Procedures Desktop Intelligence Tools Change Password Change Password Desktop Intelligence Login As (Not used in XI R2) 158 BusinessObjects 6.x to XI Release 2 Migration Guide

159 Understanding rights migration Rights by product/component 8 Web Intelligence/Web Intelligence rights In version XI R2, some new rights have been added for the Web Intelligence application: Edit SQL, to control the user s ability to edit SQL query Merge dimensions for synchronization, to control the user s ability to edit a semantic link for multiple data providers Enable Query - HTML, to control the user s ability to use the HTML Report Panel Rights linked to interactive editing have also been updated to provide more granularity. This section covers: Application rights in the destination vs. source environment Document rights (.wid) How Web Intelligence security commands migrate Application rights in the destination vs. source environment The following table lists how the Web Intelligence rights are migrated from a version 6.x system. Web Intelligence XI R2 application general rights Log into Web Intelligence and view this object in the CMC Edit this object Modify the rights users have to this object Securely modify rights users have to objects Equivalent in source environment N/A N/A N/A N/A Web Intelligence XI R2 application Equivalent in source environment custom rights Java Report Panel: Edit SQL (New in XI R2) Merge dimensions for (New in XI R2) synchronization Enable interactive HTML viewing (if Use Interactive Viewing license permits) BusinessObjects 6.x to XI Release 2 Migration Guide 159

160 8 Understanding rights migration Rights by product/component Web Intelligence XI R2 application custom rights Enable Query - HTML Report Panel Enable HTML Report Panel Enable Java Report Panel Extend scope of analysis Enable drill mode Create document Java Report Panel: Enable formula toolbar Interactive: General - Enable right click menu Interactive: General - Edit My Preferences Interactive: Left Pane - Enable document summary Interactive: Left Pane - Enable data summary Interactive: Left Pane - enable document structure and filters Interactive: Left Pane - Enable available objects, tables and charts Interactive: Formatting - Enable toolbar and menus Interactive: Reporting - Create and edit report filter Interactive: Reporting - Create and edit sort Interactive: Reporting - Create and edit break Interactive: Reporting - Create and edit predefined calculation Interactive: Reporting - Create and edit alerter Equivalent in source environment Use Web Intelligence HTML Report Panel N/A Once migrated, set to Not Specified Use Web Intelligence Java Report Panel Extend Scope of Analysis Allows working in drill mode Allows creation of documents Allows use of the Formula bar when creating documents in the Java Report Panel (New in XI R2) (New in XI R2) (New in XI R2) (New in XI R2) (New in XI R2) Use Formatting Toolbar (New in XI R2) (New in XI R2) (New in XI R2) (New in XI R2) (New in XI R2) 160 BusinessObjects 6.x to XI Release 2 Migration Guide

161 Understanding rights migration Rights by product/component 8 Web Intelligence XI R2 application custom rights Interactive: Reporting - Create and edit rank Interactive: Reporting - Insert or duplicate report, table, chart and cell Interactive: Formula - Enable toolbar and variable creation Equivalent in source environment (New in XI R2) (New in XI R2) (New in XI R2) Document rights (.wid) In version XI R2, you can set rights on documents. The following table lists these rights and their values for View, Schedule and View on Demand access levels. For the No Access role, all rights are Denied; for the Full Control role, all rights are Granted. Like Desktop Intelligence documents, Web Intelligence documents inherit general rights, and have their own set of custom rights. Web Intelligence (.wid) XI R2 document general rights Add objects to the folder View Schedule View on Demand Not Specified Not Specified Not Specified View objects Granted Granted Granted Edit objects Not Specified Not Specified Not Specified Modify the rights users have to Not Specified Not Specified Not Specified objects Schedule the document to run Not Specified Granted Granted Delete objects Not Specified Not Specified Not Specified Define server groups to Not Specified Granted Granted process jobs Delete instances Not Specified Not Specified Not Specified Copy objects to another folder Not Specified Granted Granted Schedule to destinations Not Specified Granted Granted View document instances Granted Granted Granted Pause and Resume document Not Specified Not Specified Not Specified instances Securely modify rights users Not Specified Not Specified Not Specified have to objects Reschedule instances Not Specified Not Specified Not Specified BusinessObjects 6.x to XI Release 2 Migration Guide 161

162 8 Understanding rights migration Rights by product/component Web Intelligence (.wid) XI R2 document general rights Schedule on behalf of other Not Specified Not Specified Not Specified users View objects that the user Not Specified Not Specified Not Specified owns Edit objects that the user owns Not Specified Granted Granted Modify the rights that users Not Specified Not Specified Not Specified have to objects that the user owns Delete objects that the user owns Delete instances that the user owns View document instances that the user owns Pause and Resume document instances that the user owns Securely modify rights users have to objects that the user owns Reschedule instances that the user owns Web Intelligence (.wid) document custom rights Refresh the report s data Edit Query View Schedule View on Demand Not Specified Not Specified Not Specified Not Specified Granted Granted Not Specified Not Specified Not Specified Not Specified Granted Granted Not Specified Not Specified Not Specified Not Specified Granted Granted View Schedule View on Demand Not Specified Not Specified Granted Not Specified Not Specified Not Specified Refresh List of Values Not Specified Granted Granted Use List of Values Not Specified Granted Granted View SQL Not Specified Not Specified Not Specified Export the report s data Not Specified Granted Granted Download files associated with Not Specified Not Specified Not Specified the object 162 BusinessObjects 6.x to XI Release 2 Migration Guide

163 Understanding rights migration Rights by product/component 8 How Web Intelligence security commands migrate The following table shows how version 6.x security commands are migrated to version XI R2, and the mechanism by which each security command is enforced. Some rights are mapped to a right that can be set both at the application and document level, but 6.x security commands are migrated at the application level only. Note: Depending on your precise source version, your release may not include all of these security commands. Web Intelligence security commands in source environment XI R2 right Enforced by Administration Change Password (Not used in XI R2) Download 3-tier (Not used in XI R2) BusinessObjects Use interactive viewing Use interactive viewing Web Intelligence Use the Web Intelligence HTML Report Panel Use the Web Intelligence Java Report Panel Analysis Enable HTML Report Panel Enable the Java Report Panel Web Intelligence Web Intelligence Extend Scope of Analysis Extend Scope of Analysis Web Intelligence Transparent Drill Outside of Cube (Not used in XI R2 - used only with 5.x documents) Work in Drill Mode Enable drill mode Web Intelligence InfoView Add External Content to My InfoView Add External Content to My InfoView InfoView Change Skin (Not used in XI R2) Customize the Interface Change Homepage InfoView Manage My Corporate Categories (Not used in XI R2 - defined instead with rights on the folder and the categories) BI platform BusinessObjects 6.x to XI Release 2 Migration Guide 163

164 8 Understanding rights migration Rights by product/component Web Intelligence security commands in source environment Manage All Corporate Categories Manage Personal Categories Read Corporate Documents (Not used in XI R2 - defined instead with rights on the folder and the categories) (Not used in XI R2 - defined instead with rights on the folder and the categories) (Not used in XI R2 - defined instead with rights on the document and the folder) BI platform Intelligence tier Intelligence tier Read Inbox Documents View Inbox InfoView Refresh View of Document Lists and Categories (Not used in XI R2) Save and Read Personal Documents Save to Corporate Documents (Not used in XI R2 - defined instead by rights on the folder) (Not used in XI R2 - defined instead by rights on the folder) Upload Documents (Not used in XI R2 - defined instead by rights on the folder) Publications Manage (Not used in XI R2) Publications Manage Web Publications (Not used in XI R2) Query and Web Panel Allows creation of documents XI R2 right Create Documents (Allows creation of Web Intelligence documents) Enforced by BI platform BI platform BI platform Web Intelligence Do Not Always Regenerate SQL Edit Documents Edit Documents Web Intelligence 164 BusinessObjects 6.x to XI Release 2 Migration Guide

165 Understanding rights migration Rights by product/component 8 Web Intelligence XI R2 right Enforced by security commands in source environment Edit Query Edit Query Web Intelligence Refresh Lists of Values Refresh List of Values Web Intelligence Use Formatting Toolbar Interactive: Formatting - enable toolbar and menus Web Intelligence Use Formula Language / Create Variables Interactive: Formula - Enable toolbar and variable creation Use Lists of Values (Not used in XI R2 - defined instead with rights on the document) View SQL (Not used in XI R2 - defined instead by rights on the document) Web Intelligence Web Intelligence Web Intelligence Designer rights This section covers: Application rights in the destination vs. source environment Universe rights How Designer security commands migrate Application rights in the destination vs. source environment Designer application general rights Log on to the Designer and view this object in the CMC Edit this object Modify the rights users have to this object Securely modify rights users have to objects Equivalent in source environment N/A N/A N/A N/A BusinessObjects 6.x to XI Release 2 Migration Guide 165

166 8 Understanding rights migration Rights by product/component Designer application custom rights Check Universe Integrity Refresh Structure Window Use Table Browser Apply Universe Constraints Link Universe Equivalent in source environment Check Universe Integrity Refresh Structure Window Use Table Browser Apply Universe Constraints Link Universe Universe rights In version XI R2, you can set rights on universes. Universes inherit general rights, and have their own set of custom rights. Universe general rights Add objects to the folder View objects Edit objects Modify the rights users have to objects Schedule the document to run Delete objects Copy objects to another folder Securely modify rights users have to objects View objects that the user owns Edit objects that the user owns Modify the rights users have to objects that the user owns Delete objects that the user owns Securely modify rights users have to objects that the user owns Universe custom rights New List of Values Print Universe Show Table or Object Values Equivalent in source environment Export universe (to a given folder) Enable universe N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Equivalent in source environment New List of Values Print Universe Show Table or Object Values 166 BusinessObjects 6.x to XI Release 2 Migration Guide

167 Understanding rights migration Rights by product/component 8 Universe custom rights Edit Access Restrictions (New in XI R2) Unlock Universe (New in XI R2) Data Access (New in XI R2) Equivalent in source environment How Designer security commands migrate The following table shows how version 6.x security commands are migrated to version XI R2, and the mechanism by which each security command is enforced. Some rights are mapped to a right that can be set both at the application and document level, but 6.x security commands are migrated at the application level only. Note: Depending on your precise version, your release may not include all of these security commands. Designer security commands in source environment Connection Create, Modify and Remove Connection View All Secured Connections Miscellaneous XI R2 right (Not used in XI R2) (Not used in XI R2) Enforced by BI platform BI platform Check Universe Integrity Check Universe Integrity Designer Refresh Structure Window Refresh Structure Window Designer Use Table Browser Use Table Browser Designer Tools Change Password (Not used in XI R2) Login As (Not used in XI R2) Universe Apply Universe Constraints Apply Universe Constraints Export List of Values (Not used in XI R2) Export Universe (Not used in XI R2) Import Universe (Not used in XI R2) Designer BusinessObjects 6.x to XI Release 2 Migration Guide 167

168 8 Understanding rights migration Rights by product/component Designer security commands in source environment Link Universe Link Universe Designer New List of Values New List of Values Universe New Universe (Not used in XI R2) Prevent from Overwriting Edit Objects (General) Universe Universe Print Universe Print Universe Universe Show Table or Object Values XI R2 right Show Table or Object Values Enforced by Universe Connection rights In version 6.x, you can allocate stored procedures to users. In XI R2, a stored procedure is implemented as a new right for the connection object: Use connection for Stored Procedures. During migration, for all stored procedures enabled for a user, an ACE (Access Control Entry) is created for the user, the corresponding connection and the correct stored procedures access. This ACE is set to Granted. 168 BusinessObjects 6.x to XI Release 2 Migration Guide

169 BusinessObjects 6.x to XI Release 2 Migration Guide Understanding Import Wizard options chapter

170 9 Understanding Import Wizard options Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails Security migration options The Merge and Update import scenarios 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Overview The Import Wizard contains a number of options that impact how selected principals (users or groups) or objects are imported. These options concern issues such as: whether objects are imported with or without source security settings whether imported objects can update existing objects in the CMS and if so, how whether objects can be renamed to coexist with like-named objects Security migration options Because of the difference between the 6.x and XI R2 security models and the clear superiority of the latter the recommendation for the migration of large or complex deployments is to migrate your BI content without migrating its security, and then rebuild security using the greater granularity and control of the new environment. You can import objects without security simply by importing them without any users or groups. 170 BusinessObjects 6.x to XI Release 2 Migration Guide

171 Understanding Import Wizard options Security migration options 9 If you want to import both objects and principals at one time, however, you can still import the objects without their rights by choosing the appropriate option in the Import Wizard s Security Migration Options dialog box. When you select users/groups to be imported, rights may be imported as well: If you have selected objects as well, users rights on these objects will be imported. Rights on applications, such as InfoView and Web Intelligence are always imported. To give you more flexibility in how these rights are migrated, the Import Wizard provides three security migration options which allow you to import objects either with their rights or without them; if you import security, it also allows you to restrict user rights. BusinessObjects 6.x to XI Release 2 Migration Guide 171

172 9 Understanding Import Wizard options Security migration options To migrate the rights of the objects you re importing Choose one of the first two options: The first option imports the objects content and rights, in order to reproduce the version 6.x security model. It also sets additional rights in the destination CMS pertaining to the imported objects: Object Performance Management folder (top level) access level All Desktop Intelligence rights All Web Intelligence rights All Designer rights Value No Access Not specified Not specified Not specified As these rights are set for the Everyone group, they apply to all users, unless they are explicitly assigned another value. To give them access, administrators must use the CMC to explicitly grant the proper users the appropriate rights. This is the most secure option, selected by default. The second option imports the objects contents and rights, in order to reproduce the version 6.x security model, but does not set the restrictions in the target CMS that it sets in the first option. Default settings are set in the Everyone group for some rights, and apply to all users. As these default values may be different from the version 6.x defaults, this may allow migrated users to have more rights than they had in the source environment. If you want to avoid this, use the first option (see above) or do not migrate security and recreate it in the new environment (see next section). In both cases, the Import Wizard sets the access level for the Everyone group to No Access for all imported domain folders. This restricts access for all users for whom no default rights are given. After the import, you must use the CMC to explicitly give access to users and groups for specific folders. If you give access to a domain folder to the Everyone group, all users will have access to this folder and be able to see all documents in it. Before doing this, make sure you have thoroughly reviewed the security using the CMC. 172 BusinessObjects 6.x to XI Release 2 Migration Guide

173 Understanding Import Wizard options The Merge and Update import scenarios 9 To migrate objects without their rights Choose the third option to migrate object content without object rights. Here are the consequences: Security is neither imported nor created for corporate universes (.unv) and universe domains. Security is neither imported nor created for corporate Desktop Intelligence (.rep,.rea,.ret), Web Intelligence (.wqy,.wid), Analytics (.afd) and agnostic documents and document domains Security is neither imported nor created for connections. This includes the Stored Procedures right that is not set for the connection object. Power user logins such as General Supervisor, Supervisor, and Designer are not added into administration groups (Administrators, Designer Users, Report conversion tool Users, etc.). Users are not assigned to the appropriate Object Level Security groups, which apply limits on top-level universe folders. Full-control owner rights on the top-level user and user group folders are not set for Supervisors. Application rights (InfoView, Web Intelligence, BusinessObjects/Desktop Intelligence, Designer) rights are not migrated and not recreated. As no security is migrated at all, this option is recommended if you want to redesign the security in your destination repository, and fully benefit from the XI R2 framework. For help in assessing what this entails, see Chapter 12: Recreating security in XI R2. The Merge and Update import scenarios When you use the Import Wizard, you can choose to merge the source and destination systems, or you can update the destination environment with the objects in the source system. BusinessObjects 6.x to XI Release 2 Migration Guide 173

174 9 Understanding Import Wizard options The Merge and Update import scenarios These options primarily affect behavior when the same objects are imported into a destination system multiple times. They also affect the conflict resolution behavior when two different objects with the same name are imported to the same location. The options difference comes into play only when you re-import objects that have already been imported into the CMS. Note: The consequences of all Merge and Update options are summarized in tables at the end of this section. How the Import Wizard compares source and destination objects Depending on the import scenario, the Import Wizard compares objects by one of the following: name (including path) 174 BusinessObjects 6.x to XI Release 2 Migration Guide

175 Understanding Import Wizard options The Merge and Update import scenarios 9 by CUID, a cluster unique identifier based on object type, object ID/object name (if no ID), and the repository GUID. Any object imported from version 6.x is assigned CUID during import. If the object is imported to the target CMS multiple times, the object is assigned the same CUID each time. Merging environments If you choose the Merge import scenario, the Import Wizard tries to add objects from the source to the destination CMS without overwriting objects in the destination environment. In most cases, the Import Wizard looks for an object with the same path and name in the CMS repository. If it finds no matching object, the 6.x object is imported. If it finds that an object with the same name exists: If you have chosen the Rename option, imported like-named objects are renamed in the CMS. Its children are added under it and not renamed. If the imported object has the same CUID, the renamed copy is given a new CUID. Users and groups cannot be renamed, so import typically fails if duplicate users/groups exist. Certain other objects are always enforced to use Update mode, even when Merge is selected (see the following section). If you did not choose the Rename option, the import of objects with the same path and name fails. Special case The Import Wizard does not usually combine objects with the same name. When it tries to locate users and groups in the destination database, however, it looks for existing objects with the same name as imported objects. If it finds top-level folders of the same name, it merges them if the Rename option is not chosen. BusinessObjects 6.x to XI Release 2 Migration Guide 175

176 9 Understanding Import Wizard options The Merge and Update import scenarios Example: Merge with no Rename Before import After import Source environment Folder A (CUID=1234, ID=1) Rpt A (CUID=2345, ID=2) Destination environment Folder A (CUID=6789, ID=3) Folder A (CUID=6789, ID=3) No change in existing folder content except following addition: Rpt A (CUID=2345, ID=4) Updating the destination environment The Update option applies to the incremental import of objects from a source to a destination environment. If you choose the Update option, the Import Wizard compares the CUID of the imported object with the object CUIDs in the CMS database to determine whether the object has already been imported. If the source object has never been imported, it is given a new CUID and imported into the CMS repository. If a source object has already been imported into the same CMS, and therefore has the same CUID as an object in the destination environment, the destination object is updated with the source object s parameters. Rename In certain Update cases, you should select the Rename option because of name clashes. For example: You update an object. One of the parameters to update is the document s name. Unfortunately, another document already has the same name => name clash. You import an object (there is no other object with the same CUID in the CMS), but there is another object with a different CUID but with same name => name clash If you checked the Rename option, an imported object with the same path and name as a pre-existing object in the destination CMS, the object import fails. Note: Whenever an object (excluding users and groups) is added to the CMS, even renamed, its children are created beneath it. 176 BusinessObjects 6.x to XI Release 2 Migration Guide

177 Understanding Import Wizard options The Merge and Update import scenarios 9 Update the contents/rights of the object When you import an object more than once from a source to destination environment, the object may have been modified in the source or destination environment since the last import. The following updating options allow you to define in what way you want to update the same object in the destination environment during incremental migrations: Overwrite object contents When you reimport an object, it will completely overwrite and replace the object (and its associated files) that you imported earlier. You can choose to do this for any or all of the following types of objects: Dashboards, Analytics, and Documents Universes Connections Overwrite object rights When you reimport an object, its associated security rights will overwrite the rights of the object you imported earlier. Overwrite Object Rights is not selected and cannot be modified if you have chosen not to migrate security. BusinessObjects 6.x to XI Release 2 Migration Guide 177

178 9 Understanding Import Wizard options The Merge and Update import scenarios The following table summarizes the effect of checking or unchecking these options. Overwrite object rights is selected Overwrite object rights is cleared Overwrite object contents is selected (for any object type) Update the object contents and its ACL rights for concurrentlyimported principals. Use this to import objects and their security, especially if they have been modified in the source deployment Only object content is modified. ACLs are not modified. Use this to import objects that may have been modified in the source deployment, without overwriting destination security settings for them. Overwrite object contents is cleared (for all three object types) Import the object s ACL only. Select principals + objects. Object content will not be modified. Use this to overwrite the objects security but not other potential object modifications in the destination CMS. Neither the object s content nor ACL is modified in the CMS. Use this to reimport a set of objects without updating objects that were already imported, but only add the new objects in the source repository. Merge vs Update for imported principals When you are importing principals, the Merge option merges the group hierarchy of the existing user with the hierarchy of the incoming (source) user. This means that if a user has parents A and B in 6.x, and has a parent A and C in the destination system (because the user was imported already and its group has changed since that time, either in the source or the destination environment) it will have parents A,B and C in the CMS after the import. If the Update option is selected (with or without rights fidelity), the existing user s hierarchy in the CMS is erased and replaced with the incoming user s. In the previous example, the user would only have parents A and B. In other words, the only parents (other than Everyone) that the imported user will have in the destination CMS are the parents that were imported at the same time. 178 BusinessObjects 6.x to XI Release 2 Migration Guide

179 Understanding Import Wizard options The Merge and Update import scenarios 9 Summary of Merge/Update consequences The following table summarizes the consequences of choosing a Merge or Update scenario in conjunction with selecting the Rename option or not. These scenarios assume that the relevant Update the contents of the object options (documents, universes, or connections) are selected. In the Merge scenarios below, the same path case can happen for top level objects only, because the object will be renamed in the destination CMS, and so the subfolders belonging to them necessarily won t have the same path as in the source environment. In the examples below, italicized text indicates source objects, either in the source environment, or after migration to the destination environment. Import scenario options Merge No rename Merge No rename Merge No rename Objects have... Different CUID Different path/ name Same CUID Different path/ name Different CUID Same path/name Result The source object is added to the CMS, with the same name and CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport (no existing objects from version 6.x deployment) Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The source object is added to the CMS, with the same name and CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder B [CUID = 1] Destination postimport Folder A [CUID = 3] Rpt A [CUID = 2] Folder B [CUID = 1] For all objects but folders, import of the source object fails. For example: BusinessObjects 6.x to XI Release 2 Migration Guide 179

180 9 Understanding Import Wizard options The Merge and Update import scenarios Import scenario options Merge No rename Merge rename Objects have... Same CUID Same path/name Different CUID Different path/ name Source Rpt A [CUID = 1] Destination preimport Rpt A [CUID = 2] Destination postimport Same as preimport. Rpt A fails due to name clash. For folder objects, import succeeds, with incoming objects in the folder merging into the contents of the same-named folder in the CMS. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder A [CUID = 3] Rpt A [CUID = 4] Destination postimport Folder A [CUID = 3] Rpt A [CUID = 4] Rpt A [CUID=2] (Only succeeds if Rpt A [CUID = 2] is different object type than Rpt A [CUID = 4].) Import of the source object fails because of the duplicate object name. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Result Destination preimport Folder A [CUID = 1] Rpt A [CUID = 2] Destination postimport Same as preimport. Folder A import fails due to name clash; Rpt A fails because parent import failed. The source object is added to the CMS, with the same name and CUID. For example: 180 BusinessObjects 6.x to XI Release 2 Migration Guide

181 Understanding Import Wizard options The Merge and Update import scenarios 9 Import scenario options Merge Rename Merge Rename Objects have... Same CUID Different path/ name Different CUID Same path/name Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport (no existing objects from version 6.x deployment) Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The source object is imported with the same name and CUID. The object in the CMS repository with the same CUID loses its CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder B [CUID = 1] Destination postimport Folder A [CUID = 3] Rpt A [CUID = 2] Folder B [CUID = 1] The source object is added to the CMS repository under a new name and the same CUID. The object in the destination CMS with the same name retains its name and CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Result Destination preimport Folder A [CUID = 3] Rpt A [CUID = 4] Destination postimport Folder A(2) [CUID = 1] Rpt A [CUID = 2] Merge Rename Same CUID Same path/name Folder A [CUID = 3] Rpt A [CUID = 4] The source object is imported with a new name and the same CUID. The object in the CMS with the same name and CUID retains its name and loses its CUID. For example: BusinessObjects 6.x to XI Release 2 Migration Guide 181

182 9 Understanding Import Wizard options The Merge and Update import scenarios Import scenario options Objects have... Source Folder A [CUID = 1] Rpt A [CUID = 2] Result Destination preimport Folder A [CUID = 1] Rpt A [CUID = 2] Destination postimport Folder A(2) [CUID = 3] Rpt A [CUID = 4] Update No rename Update No rename Update No rename Different CUID Different path/ name Same CUID Different path/ name Different CUID Same path/name Folder A [CUID = 1] Rpt A [CUID = 2] The source object is added to the CMS, with the same name and CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport (no existing objects from version 6.x deployment) Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The source object is added to the CMS, keeping its name and updating the object with the same CUID. Properties that don t exist on the incoming object are preserved. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder B [CUID = 1] Rpt A [CUID = 2] Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The import of the source object fails: folder fails due to name clash; report fails due to parent fail For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder A [CUID = 4] Rpt A [CUID = 3] Destination postimport Import fails. 182 BusinessObjects 6.x to XI Release 2 Migration Guide

183 Understanding Import Wizard options The Merge and Update import scenarios 9 Import scenario options Update No rename Update Rename Update Rename Update Rename Objects have... Same CUID Same path/name Different CUID Different path/ name Same CUID Different path/ name Different CUID Same path/name In most cases, the source object is added to the CMS, keeping its name and updating the object with the same CUID. Properties that don t exist on the incoming object are preserved. Other cases however can cause the import to fail. See Special cases for updating objects on page 184. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder A [CUID = 1] Rpt A [CUID = 2] Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The source object is added to the CMS, with the same name and CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder B [CUID = 3] Rpt A [CUID = 4] Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] Folder B [CUID = 3] Rpt A [CUID = 4] The source object is added to the CMS, with the same name, but overwriting the object with the same CUID. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Result Destination preimport Folder B [CUID = 1] Rpt A [CUID = 2] Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] The source object is added to the CMS under a new name, but keeps the same CUID. For example: BusinessObjects 6.x to XI Release 2 Migration Guide 183

184 9 Understanding Import Wizard options The Merge and Update import scenarios Import scenario options Update Rename Objects have... Same CUID Same path/name Source Folder A [CUID = 1] Rpt A [CUID = 2] Destination preimport Folder A [CUID = 3] Rpt A [CUID = 4] Destination postimport Folder A[2] [CUID = 1] Rpt A [CUID = 2] Folder A [CUID = 3] Rpt A [CUID = 4] The source object is added to the CMS under a new name. It updates the object with the same CUID. Other cases, however, can cause the import to fail. See the next section. For example: Source Folder A [CUID = 1] Rpt A [CUID = 2] Result Destination preimport Folder A [CUID = 1] Rpt A [CUID = 2] Destination postimport Folder A [CUID = 1] Rpt A [CUID = 2] Special cases for updating objects There are special cases for updating objects in an Update + Rename scenario. One is when an object with the same CUID exists, and an object with the same name but different CUID exists in parent folder of the imported objects. Since the object with the same CUID as the imported object typically has the same name and is contained by the same parent, this rare scenario might occur if: You import an object named ObjectA then move it to a different folder which wasn t imported. You then create another object called ObjectA in the folder where the original imported ObjectA object lived. You run another import, and now have two ObjectA objects, the original one with the same CUID in some other folder, and the new ObjectZ object in the original folder, so you get a name clash. 184 BusinessObjects 6.x to XI Release 2 Migration Guide

185 Understanding Import Wizard options The Merge and Update import scenarios 9 You import an object called ObjectZ which lives in folder A. You also import folder B, which is related neither to A nor ObjectZ. After import, you create a new object ObjectZ in folder B. In the source system, you move the original ObjectZ object from folder A to B. Now when you import, the Import Wizard will try to move the ObjectZ in A (which is the original object and has the same CUID) to folder B, and a name clash occurs. BusinessObjects 6.x to XI Release 2 Migration Guide 185

186 9 Understanding Import Wizard options The Merge and Update import scenarios 186 BusinessObjects 6.x to XI Release 2 Migration Guide

187 BusinessObjects 6.x to XI Release 2 Migration Guide Understanding deployment configuration migration chapter

188 10 Understanding deployment configuration migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning XI R2 deployment rules XI R2 deployment rules 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning XI R2 deployment rules Rule 1 An XI R2 repository must be connected to at least one CMS. 188 BusinessObjects 6.x to XI Release 2 Migration Guide

189 Understanding deployment configuration migration XI R2 deployment rules 10 Why? The repository is a combination of database schema and the File Repository Server (FRS). The FRS actually stores the repository content such as universes and documents, and the database, maintained by the CMS, contains the InfoObjects describing and pointing to that content. Unlike with version 6.x, it is not possible to connect to the repository directly. All queries to the repository must go through the CMS. The server itself must be connected to by a web server and an application server. The web server/application servers are required because security, users, and scheduling are all managed through the web. There is no longer a full-client security/administration application like Supervisor. Rule 2 With XI R2, as with version 6.x, a single server process cannot be connected to multiple repositories. BusinessObjects 6.x to XI Release 2 Migration Guide 189

190 10 Understanding deployment configuration migration XI R2 deployment rules Rule 3 Each repository must have its own dedicated server machine, or cluster of server machines. If you decide to cluster multiple server machines together to provide more power, the clustering must be Business Objects clustering, similar to version 6.x. Unlike version 6.x, an XI R2 repository can only be connected to a single cluster. Multiple clusters cannot connect to the same repository. Rule 4 The CMS process is critical to all processes in an XI R2 cluster. All processing is either initiated or controlled by this process. You can have multiple CMSs running, but the CMSs must all be running on the same network subnet. No other processes are restricted by this rule. 190 BusinessObjects 6.x to XI Release 2 Migration Guide

191 Understanding deployment configuration migration XI R2 deployment rules 10 Rule 5 The CMS must be physically located as close to the repository database as possible, as the amount of interaction between the CMS(s) and the repository is considerably higher compared to version 6.x. BusinessObjects 6.x to XI Release 2 Migration Guide 191

192 10 Understanding deployment configuration migration Migrating deployment configurations Rule 6 The File Repository Server (FRS) cannot be geographically distributed. It can exist in one location only. Though multiple FRS server processes can be running on different server machines, connecting to the same file system, only one is active; the others remain passive, available for failover only. Migrating deployment configurations Given the difference in architecture in moving from version 6.x to version XI R2, migrating from certain 6.x deployment configurations to version XI R2 may require modification and additional administrative steps. XI R2 does not support repositories with domains that are geographically distributed. Version XI R2 does not support the use of multiple clusters for a single repository. 192 BusinessObjects 6.x to XI Release 2 Migration Guide

193 Migration planning and assessment part

194

195 BusinessObjects 6.x to XI Release 2 Migration Guide Assessing migration by product and functionality chapter

196 11 Assessing migration by product and functionality Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning BusinessObjects/Desktop Intelligence Web Intelligence Designer and universes Auditing and Auditor Scheduling and publishing SDKs Application Foundation/performance management Web Intelligence OLAP 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning This chapter describes dimensions of XI R2 migration and their practical consequences. Obviously each migration will be a combination of several of these scenarios (such as BusinessObjects, Web Intelligence, Broadcast Agent Scheduler), therefore you may need to apply multiple scenarios to match any given configuration. 196 BusinessObjects 6.x to XI Release 2 Migration Guide

197 Assessing migration by product and functionality BusinessObjects/Desktop Intelligence 11 BusinessObjects/Desktop Intelligence Deployment Migration involves an update for local BusinessObjects reports, meaning that you open the report in Desktop Intelligence, and then save it to version XI R2 format, and an Import Wizard import for documents in the repository. This type of migration requires a side-by-side migration, meaning that both Desktop Intelligence and BusinessObjects are installed on the same client machines. 2-tier deployments of Desktop Intelligence For administrators, however, a major deployment difference consists of having to install a CMS server somewhere on the network. Even for Desktop deployments, however, you will need a web and application server, as well as a server to house the CMS somewhere on the network. Unlike in 2-tier deployments of BusinessObjects, Desktop Intelligence users log in through the CMS server, via the CORBA protocol. Here, for example, is a simple source deployment. This is what the same deployment looks like in the destination environment. BusinessObjects 6.x to XI Release 2 Migration Guide 197

198 11 Assessing migration by product and functionality BusinessObjects/Desktop Intelligence 3-tier deployments of BusinessObjects Similar to BusinessObjects, Desktop Intelligence calls are still tunnelled through HTTP. In XI R2, users cannot download Desktop Intelligence through InfoView, as they could 3-tier deployments of BusinessObjects in version 6.x. Instead, you can: install Desktop Intelligence manually from a CD install from a shared location/directory use an install package (like SMS) to automate the install No.rkey or.key files are required. A <Server Name+.NET or J2EE>.extranet file is created when the user launches Desktop Intelligence from InfoView. How Desktop Intelligence differs Look and feel Report authors should feel like Desktop Intelligence and BusinessObjects are the same, except for OLAP data providers and interaction with the platform (login, send/receive). Desktop Intelligence documents are displayed differently: version XI R2 has a new page-by-page HTML viewer, and the ActiveX enhanced report viewer available in version 6.x is no longer available. You need to redo any portal customization. Features Desktop Intelligence supports Unicode data sources, as well as report instances and discussions. You can set a value that formats a document s data (ndependently of the UI s language). It is this value that is taken into account when calculations are performed within the document. Each document therefore has its own locale. OLAP data providers are no longer available. You can rebuild those documents using Crystal Reports, Web Intelligence, or OLAP Intelligence. 198 BusinessObjects 6.x to XI Release 2 Migration Guide

199 Assessing migration by product and functionality BusinessObjects/Desktop Intelligence 11 Many workflows change with Desktop Intelligence: All retrieve workflows (from corporate documents, from user, and from personal documents) are merged into a single Retrieve workflow. You cannot schedule documents from Desktop Intelligence; you use the CMC. Desktop Intelligence documents you want to schedule or send to other users must already have been published to the repository. Version 6.x of BusinessObjects cannot connect to an XI R2 repository. If you want users to be able to connect to both BusinessObjects and Desktop Intelligence documents, you must have a side-by-side installation (6.x and XI R2) to connect to both versions of the repository from XI R2. After the import, for Desktop Intelligence documents viewed via InfoView, report-to-report links need to be updated. Documents using Web Connect are not supported. You cannot save a Desktop Intelligence document in.bqy format. Although you can view and refresh Desktop Intelligence documents based on stored procedures and imported to Desktop Intelligence, you cannot edit them. You cannot view published Desktop Intelligence documents which have a read/write password through web-based viewers such as InfoView or Web Services. The following table summarizes Desktop Intelligence support for processing VBA macros and add-ins: Macros Client Add-ins Server Potential calculation issues after conversion to new format Due the changes in the calculation engine over the course of version 5.x to 6.x development, the automatic conversion of BusinessObjects documents to Desktop Intelligence format during import may in specific cases return different results than in the original documents. For complete information, see Checking for calculation updates on page 309. BusinessObjects 6.x to XI Release 2 Migration Guide 199

200 11 Assessing migration by product and functionality BusinessObjects/Desktop Intelligence Unicode implications Unicode font sizes are different than their non-unicode equivalents. Therefore, if you have migrated BusinessObjects documents to Desktop Intelligence, and have also migrated your 6.x data sources to a Unicode database, you may encounter the following: Documents are not pixel-per-pixel identical. When a cell isn t big enough to display all its contents, it uses ### to indicate that the contents have been truncated. Because the Unicode fonts are sometimes bigger than their non-unicode equivalents, you may see ### in cells where previously you saw data. The size of documents may be affected. Functions like NumberOfPages() may return different values in the case of Autofit cells. For changes in the calculation engine, see Checking for calculation updates on page 309. Note: The move to Unicode has no impact on sorts. Access rights via InfoView In version 6.x, InfoView was not a formal construct. Security rights for InfoView are therefore not migrated. One consequence is that although access rights for BusinessObjects documents are maintained for the same documents in Desktop Intelligence, they are not maintained when the documents are accessed via InfoView. After import, therefore, you must add these rights manually using the CMC. Compatibility Repository and server connection Desktop Intelligence can connect to an XI R2 repository or cluster only. BusinessObjects cannot connect to an XI R2 repository or cluster. BusinessObjects 6.x cannot connect to a version XI R2 repository, and cannot open Desktop Intelligence reports. Universes Desktop Intelligence can use any universes imported into, or created in BusinessObjects Enterprise XI R2. The Import Wizard imports version 6.x universes, automatically converting them into version XI R2 format. 200 BusinessObjects 6.x to XI Release 2 Migration Guide

201 Assessing migration by product and functionality BusinessObjects/Desktop Intelligence 11 What does migration involve? After backing up the source environment and setting up the new XI R2 server environment, install Desktop Intelligence on the same computer(s) running 6.x versions of BusinessObjects. Desktop Intelligence cannot access 6.x repositories. If you need to access a 6.x repository after having installed Desktop Intelligence, you must access it using your source version of BusinessObjects. To be able to access both repositories concurrently, you must install Desktop Intelligence on the same machine as BusinessObjects 6.x (side-by-side installation). This is recommended in order to compare the two environments. Upload all secured local BusinessObjects documents to the repository. Run the Import Wizard to import all BusinessObjects documents stored in the repository. They are automatically converted to Desktop Intelligence XI R2 format and stored in the CMS repository. The Import Wizard maintains and updates the links between the reports and universes it migrates, replacing old universe IDs with new ones in the file. Documents can therefore be refreshed right after migration, whether they contain one or multiple queries, based on one or multiple universes. Note: Importing this type of document impacts Import Wizard performance, as unlike Web Intelligence documents, each BusinessObjects document must actually be opened during import. Run the Report conversion tool to convert any required Desktop Intelligence documents to Web Intelligence format. Business Objects recommends that you contact your PSO organization to maximize results. For BusinessObjects documents stored locally: open existing documents with BusinessObjects installed on the same machine. Saving a.rep file with Desktop Intelligence always saves it to XI R2 format. Open all secured documents in Desktop Intelligence, then save them with the option Save for all users. Open each document in both BusinessObjects (in the source environment) and Desktop Intelligence (in the destination environment) and compare the two versions for any changes in calculations or formatting. See BusinessObjects document migration on page 310. BusinessObjects 6.x to XI Release 2 Migration Guide 201

202 11 Assessing migration by product and functionality Web Intelligence If required: Re-establish report-to-report hyperlinks. Update any VBA macros. Some macros may no longer work because the platform-related part of the BOSDK object model has been updated. Check the rights on the imported documents, using either the CMC or the Query Builder tool. Converting Desktop Intelligence documents to Web Intelligence Moving to a purely web environment can reduce deployment costs. The best approach to move to the web is to convert some of the Desktop Intelligence documents you have imported to Web Intelligence using the Report conversion tool, and to publish other Desktop Intelligence documents to the web. Typically: Documents that require user interaction (drill, sort, filter, calculations, formatting, etc.) over the web should be converted to Web Intelligence. Documents used for enterprise reporting (i.e., that don't require user interaction) can be published over the web and viewed through the InfoView portal or some other enterprise portal. For more information, see To convert or not to convert (.rep to.wid) on page 244. If you plan to convert Desktop Intelligence documents to Web Intelligence, Business Objects recommends that you contact your PSO organization to maximize results. Web Intelligence Web Intelligence users and consumers (who view Web Intelligence documents through a portal such as InfoView) will face two set of changes: Portal changes. XI R2 InfoView presents a new look-and-feel. You can customize it using the BusinessObjects Enterprise SDK. Potential Web Intelligence report changes for customers using Web Intelligence version 2.x Web Intelligence XI R2 provides a set of new features which give it roughly the same query and reporting capabilities as BusinessObjects. Here's a summary of the top new features in XI R2: Advanced queries (same as BusinessObjects 6.5) Multiple data providers with synchronization 202 BusinessObjects 6.x to XI Release 2 Migration Guide

203 Assessing migration by product and functionality Designer and universes 11 Ranking Custom sorts Formula language (same as BusinessObjects 6.5) In addition, Web Intelligence provides an unmatched user experience for report consumers. This includes the ability to drill into reports and to interact with reports (sort, filter, calculations, formatting, etc.) directly on the HTML report output. WQY documents (Web Intelligence version 2.x) Web Intelligence documents in.wqy format are converted on the fly during import by the Import Wizard. The converted.wid files are then stored in the CMS repository. WID documents (WebIntelligence version 6.x) You use the Import Wizard to move.wid documents from a version 6 repository to an XI R2 repository. What does migration involve? After backing up the source environment and setting up the new environment, run the Import Wizard to import all Web Intelligence documents. Open each document in both Web Intelligence (in the source environment) and Web Intelligence (in the destination environment), and compare the two versions for any changes in calculations or formatting. If required, re-establish report-to-report hyperlinks. Check the rights on the imported documents, using either the CMC or the Query Builder tool. Designer and universes Migrating the Designer application is a simple update. BusinessObjects 6.x to XI Release 2 Migration Guide 203

204 11 Assessing migration by product and functionality Designer and universes Universe storage in XI R2 Universe files are stored in the FRS (File Repository Server) as both.unv and.unw. The difference is transparent to users. In XI R2, all universe information is contained in the.unv file (except for universe security, which is separate)..unw files.unw files are an internal universe storage format used by Web Intelligence. These files are stored: in the FRS stored in the file system in the cache folder used by Web Intelligence Under no circumstances should you modify or move these files, as it may cause a universe to become unusable in Web Intelligence. Creating universe subfolders In XI R2, you can create subfolders under the main universes folder, allowing for more fine-tuned management of universes. Importing universes from a source repository When the Import Wizard imports universes from the repository, it also migrates any universe-document or universe-universe links, as well as universe overloads. Importing locally-saved universes You import universes stored on local machines by simply ensuring they are saved using the Saved for all users option, then opening them with Designer XI R2. When you save these universes in Designer XI R2, they are saved to XI R2 format. This does not, however, migrate universe security or links. Universes are stored to the new.unw format in the XI R2 FRS for use with Web Intelligence, but are still saved in.unv format on desktops. There is no descending compatibility. Designer 6.x cannot open universes created with Designer XI R2 due to a file format change (ZIP vs. OLECF). 204 BusinessObjects 6.x to XI Release 2 Migration Guide

205 Assessing migration by product and functionality Designer and universes 11 Note: Unlike in previous Business Objects versions, you cannot delete the repository version of universes and expect to use the locally stored version as a back up. As the locally stored version is linked to the repository version, the local version becomes unusable. For more information on how universes are imported, see Universes and universe connections on page 92. LOV (List of Values) migration Universe security LOVs in XI R2 are the same as in your source environment. In XI R2: BusinessObjects uses both.unv and.lov files (.lov files contain SQL definitions and LOV data). Web Intelligence uses.unw files, which include LOV definitions (SQL definitions, but no actual data). When the Import Wizard imports LOVs, both the query definition and the.lov file are moved. LOVs are not InfoObjects. In XI R2, universe security is composed of: ACLs, which define what universe groups/users are allowed to use the universes Managed in the CMC via the Universes page, an ACL is created for each universe folder or each universe. BusinessObjects 6.x to XI Release 2 Migration Guide 205

206 11 Assessing migration by product and functionality Designer and universes access restrictions, known as universe access restrictions, are defined for a particular universe, and consist of: Connections Controls (query limits) SQL Object restrictions (hide) Row restrictions Table mappings They apply restrictions to users/groups. There is at most one restriction per user and per group; users inherit restrictions from parent groups. Access restrictions can be applied to multiple users/groups. Formerly defined in Supervisor, in XI R2 universe access restrictions are defined in Designer. After import, access restrictions appear in Designer when you open a universe. Access restrictions are created in the CMS and are child objects of a universe. Note: For more information about migrating universe access rights, see Understanding rights migration on page 121. Migrating users with designer rights If you choose to import security, know that users whose profiles allow them to run Designer in version 6.x (General Supervisor/Designer/Supervisor- Designer/Versatile with Designer access) are not by default added to the Universe Designer Users group. This group has full control over the Universes folder. To allow imported universe designers to use the Designer application and manage particular universes, therefore, you must grant them specific rights through the CMC. 206 BusinessObjects 6.x to XI Release 2 Migration Guide

207 Assessing migration by product and functionality Auditing and Auditor 11 Auditing and Auditor In your source deployment, you can audit your cluster s activity using: the Administration Console s Audit facility, which saves data to a text file or an Audit database the Auditor application that allows you to monitor and analyze user and system activity for Web Intelligence, InfoView, BusinessObjects in 3-tier mode, and Broadcast Agent, and then display the results in predefined BusinessObjects reports known as indicators. How auditing differs in XI R2 In BusinessObjects Enterprise XI R2, you audit BusinessObjects Enterprise using the CMC exclusively. The CMC collects audit information from all of the servers (processes) on the framework (cluster), and then writes it to the BI Warehouse (audit database). Unlike in version 6.x, you cannot audit multiple clusters. Most of the reporting functionality offered by Auditor except Impact Analysis is provided by a specific universe and two sets of 28 audit reports (Web Intelligence and Crystal Reports), organized by categories: Object Management Activity Reporting Security Reporting The reports are generated from the Audit database to report User, Document, Application and Server event monitoring. Most Audit reports include report sections, displaying the reported information grouped or charted in a different manner, such as usage information graphed by month/week/day, or by server/location. Report sections are displayed in Web Intelligence as multiple tabs, and in Crystal Reports are packaged as separate subreports delivered together as a single report. Each of these report sections is specified separately but together they are delivered in a single report. Auditor s dashboard capabilities have been superseded by the XI R2 InfoView dashboard capabilities. BusinessObjects 6.x to XI Release 2 Migration Guide 207

208 11 Assessing migration by product and functionality Scheduling and publishing Scheduling and publishing In version XI R2, publishing is considered an extension of scheduling. The CMC and InfoView support basic scheduling capabilities for Crystal Reports, OLAP Intelligence, Desktop Intelligence, and Web Intelligence reports, such as scheduled refresh, save, and publishing, prompts, and Save as Excel. It does not support certain options such as print, then refresh, and then print. For Desktop Intelligence jobs In XI R2, Conditional processing is not available The version 6.x Refresh in the Name Of scheduling option becomes Refresh on Behalf of. In XI R2, scheduling for Desktop Intelligence documents is limited to a single output. In XI R2, you may need to define multiple jobs where you had a single job before. Report bursting is not supported VBA macros In version 6.x, you can embed VBA macros in BusinessObjects documents to extend the Broadcast Agent Scheduler functionality. In XI R2, VBA add-ins (.rea files) won't work server side; embedded VBA macros, however, will continue to work (except for VBA macros that include calls to the platform such as Login or Logout). Business Objects therefore recommends that you use VBA macros instead of VBA add-ins. For Web Intelligence jobs Web Intelligence document scheduling jobs can be imported if the job is supported in XI R2. There is no File Watcher. There is, however, a service in the framework called the Event Server that does watch for the creation/modification of arbitrary files to kick off schedule events. 208 BusinessObjects 6.x to XI Release 2 Migration Guide

209 Assessing migration by product and functionality Scheduling and publishing 11 Publishing The functionality provided by Broadcast Agent Publisher is incorporated into XI R2 and is called publishing. For this release, the key capabilities have been implemented which will allow many customers to move to this new release, with the remaining capabilities being added in the following release. XI R2 has focused on re-engineering Publisher to be an integral part of the platform, hence it being named publishing, and there are many changes to existing workflows. For this release, users must re-create their publications in the destination environment using a combination of InfoView and the CMC: InfoView for the publications themselves CMC for managing users, groups, and their personalization profiles Note: You can import users, groups, and profiles from a text file, which would allow you to transfer this information between Publisher and XI R2. See the Import Wizard online help for more details for the format of the text file. Publishing profiles Profiles let you personalize the scheduled publication for groups of recipients. Profiles are defined in the Central Management Console. Personalization uses the following concepts: Profile name Identifies the name for the personalization to be applied, such as city or store name. Each user or group can have one or more profiles defined. Profile value Defines the value of the profile name, such as city = San Diego. Profile target Defines how a profile name applies to a report. Profile objects can be an object within a universe, a variable within a report, or a field within a table. BusinessObjects 6.x to XI Release 2 Migration Guide 209

210 11 Assessing migration by product and functionality SDKs What does migration involve? SDKs Client SDK Server SDKs Before importing, documenting and assessing the document scheduling in your version 6.x deployment After the import, recreating some broadcasting using the CMC in XI R2 BusinessObjects (renamed Desktop Intelligence SDK) and Designer SDKs are available in XI R2 and almost unchanged from version 6.5. SDKs no longer available in XI R2: Web Intelligence SDK Administration SDK RECOM, as MSFT is replacing COM with.net SDKs available in XI R2: BusinessObjects Enterprise SDK (Java,.NET, and COM) BusinessObjects Enterprise.NET Server Controls BusinessObjects Enterprise JavaServer Faces Components Report Application Server SDK (Java,.NET, and COM) Report viewers SDK (COM, Java) Business Objects web services Documentation and samples are provided to explain how to rewrite an application based on WICOM or WIBean with RENET or REBean, and with the BOE SDK. 210 BusinessObjects 6.x to XI Release 2 Migration Guide

211 Assessing migration by product and functionality Application Foundation/performance management 11 Desktop Intelligence SDK There are changes to platform-specific calls (Login, Publish, etc.), but the rest is unchanged. VBA macros are carried over during the import of BusinessObjects documents (they are embedded in the.rep file). VBA macros execute correctly on Windows but are ignored on UNIX. Web Intelligence SDK WebIntelligence SDK, Administration SDK and RE COM are superseded by RE SDK and BOE SDK. The REBean and RECOM SDKs are fully supported. Application Foundation/performance management In XI R2, these products are known as performance management. How performance management differs With version XI R2, Application Foundation is part of the BusinessObjects Enterprise platform. Features The analytics displayed in dashboards and scorecards are enhanced to offer more interactivity and flexibility in display and formatting options. New visualization techniques are applied to gauges and charts. New metric attributes are available. You can add additional metadata about metrics to metrics properties, providing end users with information about the name of an owner, the last refresh date, and a metric description. This helps users understand and identify the source of the information on dashboards and scorecards and makes it easy for users to take actions that improve business performance. BusinessObjects 6.x to XI Release 2 Migration Guide 211

212 11 Assessing migration by product and functionality Web Intelligence OLAP Instead of entering goals manually, you can now use a universe to import goals from corporate data sources to populate the values of goals such as the target or tolerance limits, and then visualize those goals in querybased analytics such as Interactive Metric Trends (IMT). You can build queries that include multiple SQL statements, which allow you to build powerful queries that match the level of complexity provided by Web Intelligence, and then visualize results in analytics. You can create query-based analytics on universes mapped to OLAP data sources. The workflow for creating new analytics has been simplified. Enhanced process tracking includes: expanded document attachments to activities to Desktop Intelligence and OLAP Intelligence calling Process Tracker instances via URLs Support for activity duration, suggested activity end dates based on input duration, and enhanced activity date validation A variety of Portal Integration Kits is provided. What does migration involve? See Understanding Application Foundation object migration on page 103. Web Intelligence OLAP The migration path for Web Intelligence OLAP users is to recreate their reports using OLAP Intelligence. Although no migration utility is provided, this effort is facilitated by the capabilities delivered in OLAP Intelligence, which in XI R2 represents a superset of Web Intelligence capabilities. One key technical consideration is to match or reuse the MDX statements previously generated by Web Intelligence OLAP to achieve certain analyses. It is recommended that you get PSO support if you have large numbers of this type of document. 212 BusinessObjects 6.x to XI Release 2 Migration Guide

213 Recreating security in XI R2 chapter

214 12 Recreating security in XI R2 Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning Designing your security model Group security by functionality Content security: access to reports and universes Security model for functionality and content combined Administrators group 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning This chapter provides guidelines for recreating security in the new environment, instead of importing it from the source environment. Note: Creating your security in the new environment is a one-time exercise that allows you to reap long-term benefits. Designing your security model With version 6.x it is good practice to organize security around functionality and content. With XI R2 this model works even better, due to the availability of two parents not available in version 6.x, whose strict tree structure means that a user can be in multiple groups, but a group can t have two parents. It is recommended that you structure your system s security around two axes: What a user can do What content a user can access The distinction is important, because being able to do something by right, such as refreshing a document or accessing a universe, is always related to the content the user has access to. 214 BusinessObjects 6.x to XI Release 2 Migration Guide

215 Recreating security in XI R2 Designing your security model 12 A security model should be easy to administer and yet restrictive enough on both functionality and content so that users cannot do or access things they should not. You must also ensure that users can see what they are allowed to see and do what they are allowed to do in the new environment. Principles for security group design There are a number of best practices associated with the design of security group structures. Principle of most restrictive: i.e. everything denied, unless explicitly granted Making use of hierarchy in groups and inheritance Rolling up profiles of common security levels into parent groups Security requirements This chapter takes as an example an organization with four separate business areas. These business areas do not all share content between groups, so content used by each group is isolated from each other. This organization also has five different functional user profiles: Universe designers: users with access to the Designer application to create universes. Practically speaking, these users should also have the same rights as Report Developers, which makes this profile even if not implemented in that way the most functional of all, apart from Administrators, who can do everything. Report Developers: users who can create documents, whether inside Web Intelligence to create Web Intelligence ad-hoc reports, or develop Web Intelligence or Crystal Reports documents for use by other users in their business area, available through the public folders for their group. Power Users: users who can create ad-hoc reports and edit existing ones for themselves inside Web Intelligence and can share them with others, but whose reports are not intended or allowed to end up in the public area. Casual Users: users who can view documents and refresh them Consumer: users who can only view documents BusinessObjects 6.x to XI Release 2 Migration Guide 215

216 12 Recreating security in XI R2 Group security by functionality Note that not all exact rights and privileges are specified in this list for these profiles. There are business requirements for additional functionality and some confusion still exists about some of them, like sending reports to other users through the system, or via , FTP or unmanaged (by the BusinessObjects Enterprise XI R2 environment) disk. Evaluate these elements of functionality separately for the different groups, especially where implementation of it has architectural and security consequences. Make sure therefore that you keep the structure for the profiles such that you can actually make changes later on without weakening the security structure. Note: These profiles or roles are relatively arbitrary. The definitions for universe and report developers are obvious, but the actual definition of Power Users, Casual Users or Consumers can be different in different locations, and even have different names. The point is that you have multiple profiles, which you will later on combine with a business group. Separate from these user profiles, you have administrators who administer the system and fall outside these user profiles. Group security by functionality Creating group hierarchies for inheritance By default, all groups in XI R2 are created on the same level unless you enforce a hierarchy by making a group a parent, or adding subgroups to an existing group. By enforcing or creating a hierarchy, you can use inheritance rules. If you don t, although you can easily create a structure that looks good at first, it may become hard to handle when you add the content, or need to distinguish between user groups. Using inheritance and the principle of most-restrictive You make use of inheritance by creating a general profile, and then splitting it out again by business area, each still associated with the master profile. In the diagram below, each profile is set up as a master group, with groups underneath it created for each business area. 216 BusinessObjects 6.x to XI Release 2 Migration Guide

217 Recreating security in XI R2 Group security by functionality 12 Note: The diagrams used in this section list business areas, but they might also be geographical areas or whatever grouping is most appropriate for your organization. These master profile groups cover common functionality into a single profile; their subgroups tie into a business area (or content or subject area) and inherit this master profile. This allows you to make global changes to a profile, overriding it for individual groups if you need to. For instance, you could think of a profile that by default doesn't allow for scheduling, but would allow on-demand refresh. Suppose that the documents in one content area take over 20 minutes to run. In that case you could subjectively decide that this one group, even though the master profile doesn't allow it, can schedule documents. That makes this quite a flexible model. For example, the top group for all report developers in the environment is the BO Report Developers group. This group sets the most restrictive settings for the profile of a report developer: these users are able to create new Web BusinessObjects 6.x to XI Release 2 Migration Guide 217

218 12 Recreating security in XI R2 Content security: access to reports and universes Intelligence and Crystal Reports and edit existing ones, but are not allowed to publish documents to any public folders outside the development environment. Since the groups for report developers within the various business areas belong to the BO Report Developers group, they inherit all these rights and privileges and under normal circumstances will not require changes in these rights. This means you set the main rights and restrictions on functionality only once for all users. If, however, report developers in one business area have an important business requirement for particular types of functionality -- for instance, with HR needing the ability to save documents away to an FTP location or unmanaged disk, which according to best practices you should only allow after an evaluation of security and technological impact -- you can apply this as an override on the group of HR Report Developers. This change would only apply to the HR Report Developers, so it makes it easy to grant additional rights without impacting report developers of other business areas. This method not only provides flexibility, but allows you to see relatively easily the specific privileges for an individual group that are different from the parent, as those would be rights explicitly granted, instead of inherited from BO Report Developers. Content security: access to reports and universes How inherited rights work in XI R2 In case of the profile groups, you are assuming that all profiles are the same, and therefore inherit all rights from the parent group. For content areas this will be a little different, as different groups inheriting from the top group will be able to do different things to the content that they have access to. It is therefore good to discuss briefly how XI R2 deals with inherited rights. 218 BusinessObjects 6.x to XI Release 2 Migration Guide

219 Recreating security in XI R2 Content security: access to reports and universes 12 In this diagram you see that for each right you have three options. If you set the right to be Denied on the top group, you cannot override this on lower levels, so all subgroups will have that right denied. When you grant a right on a top group (see left branch of the diagram), you can either deny it on a subgroup, or the right will be granted whether through inheritance or by setting it more explicitly. Best practices for security follow the model you see in the right branch of the diagram. If you use it consistently, it is easy for you to follow the principle of most-restrictive. On the top level, you either grant a right, or you do not set it. Since by default a right is denied if it is not specified, this means that for each child group, you should grant rights that are additional to the most-restrictive set you granted on the top group. Note that some of the boxes in the diagram have thicker borders: these are the paths you should use. That is, you do one of the following: deny a right on a top group (which may or may not have subgroups) to explicitly deny a certain right completely grant a right on a parent group, and inherit it by not specifying it in the child group do not set the right at the parent, and only grant it if the child group should have rights, and leave it inherited and not specified when it should not BusinessObjects 6.x to XI Release 2 Migration Guide 219

220 12 Recreating security in XI R2 Content security: access to reports and universes Make full use of the Not Specified option. If you deny something on a high level, it will always be denied, so only grant rights, and try to not deny unless you know that it will never be used. Of course, you can change a Denied to Not Specified, and inheritance should still ensure that if it wasn't explicitly denied lower down the hierarchy, it will still effectively be denied. But it gets confusing fast. Grant the least rights you need for any of these profiles, and then grant explicitly if there are changes or overrides for individual groups. As a best practice, avoid double grants and double denies. That is, if something is already granted on a higher level, avoid granting the right again for a subgroup. If you grant a right to a profile which you later want to revoke by setting it to Not Specified, if a subgroup has the right granted, still that group would be able to do it, as the effective right would be set to Granted. Therefore, following the principle of least-privilege or most-restrictive, set the lowest rights on the master profile, and only grant additionally where needed. Be careful with Denies. Since a continuous hierarchy of Not Specified leads to an effective denied, there is no explicit need for setting anything to denied. Moreover, you would lose the flexibility of changing a master profile and the change being inherited by the lower groups if the right is denied in the subgroup. Since you can never grant a right that has been denied in the parent group, avoid using explicit denies in subgroups. Using business area groups to give access to areaspecific content folders When it comes to content, implement a model similar to that for functionality, but now based on a business area. That is, you can build a group structure that matches up with the business area, and then move all the different profile groups for that area into its top level. Now set access to folders for each specific business area at its top level group, so that it is inherited by all the groups within that business area. In the example here for Sales, you set the Sales group to have access to the Sales folder within the <customer name> folder, and no others. Repeat this for each group, so that each group has its own area that nobody else but administrators is able to see. 220 BusinessObjects 6.x to XI Release 2 Migration Guide

221 Recreating security in XI R2 Content security: access to reports and universes 12 Using the principle of most-restrictive and inheritance Following the above approach locks the system down for access from other groups, and assigns the folder to those subfolders underneath the main group for the business area. It also allows you to use the principle of most-restrictive and inheritance. Again, try to set the rights on the top group to such an extent that extra rights are granted explicitly for the subgroups. This means that the rights on the Sales group for the sales folder should be the same as the lowest common rights, i.e. the rights and privileges of the Sales Consumers group. Since this set is the most restrictive, you need to explicitly grant rights to the other groups within the business area only as per their desired/required profile. Final Status is the effective right for the user or group for a specific right or privilege. Checking group rights on folders To check the rights any group has on a folder in the CMC, click the link that corresponds to the folder, then click the folder s Rights tab. Click the Show Rights tab, then the name of the group in the Available groups list, then the Display rights button. When checking the rights for, say, the HR Casual Users you will be able to see exactly in the Explicitly column what rights have been explicitly granted to this group over and above what is allowed within the main Casual Users group. When you move a level of functionality up, when you look at power users, you can see a whole lot more rights explicitly granted. And finally the universe developers can do almost everything apart from delete objects and instances. Note: You can see in this sample that you grant explicitly additional rights for the groups, different from the master profile, which here is the business area group. The granted by inheritance items come from the business area profile which sets the most restricted access rights on the business area folder. The explicitly granted items are rights that this group has over and above what the base rights are of that business area (i.e. in our example, the rights that consumers have on the folder. Consumers inherit all their rights, and no individual grants on the group are set.) BusinessObjects 6.x to XI Release 2 Migration Guide 221

222 12 Recreating security in XI R2 Security model for functionality and content combined Security model for functionality and content combined When you combine the two models for functionality and content, each group has two parents: a functionality parent: i.e. BO Report Developers, BO Universe Designers, BO Power Users, BO Casual Users or BO Consumers a content parent, such as Sales, Marketing, Finance, and HR In the diagram below you see this visualized for the Sales group. The Sales Report Developers a child of the BO Report Developers group also belongs to the Sales group itself. Similarly, the Sales Universe Designers belong to both the BO Universe Designers group, as well as the Sales group, and so forth for all the profile groups. This is not mapping between separate hierarchy trees for functionality and content, but in fact the exact same group that has two parents and thus belongs to two hierarchies at the same time, and will inherit from both. Users only need to be added to the correct business area specific profile group to inherit the functionality of the master profile, and the content access of the business area group. 222 BusinessObjects 6.x to XI Release 2 Migration Guide

223 Recreating security in XI R2 Administrators group 12 You see the same model for all the other business areas, so that once implemented, all of the individual profile groups per business area have two parents: the business area and the functional group. Checking group membership In the CMC, by clicking Groups, the name of the group, and then the Member of tab, you can see the names of all the groups that group belongs to. Two parent groups should be displayed for each group apart from the top groups they aren t, the implementation is not correct.) Summary of benefits This flexible model makes it easy to grant or deny access to content for an entire business area, or grant or remove rights to do certain tasks. It allows for group (or even individual) overrides if you need them, and ensures that users exist only in a single group, rather than copied into multiple groups as you would in version 6.x group structures. If a user needs access to multiple content groups, you can add a separate group that combines the two content groups and a functionality profile, and you can inherit from two business area groups and the functionality profile. You can even have different profiles in the two content areas. In this case you would pick the highest profile group, and then set the rights on the content as required. For example, UserA is a power user in HR, but a report consumer in the Marketing group. For the HR folder you would then set the rights as for HR Power Users while setting the rights for the Marketing folder as with Marketing Consumers. Administrators group Entirely separate from this group model, you have an Administrators group. This group only and exclusively contains system administrators for the environment, that is, those who configure the servers, perform maintenance and other system tasks, and are the guardians of the system. These administrators create users and perform the promotions between environments. All administrators are IT staff. Content wise, too, these administrators have access to everything. They have full rights on the root content folder which contains the Marketing, Sales, HR and Finance groups. BusinessObjects 6.x to XI Release 2 Migration Guide 223

224 12 Recreating security in XI R2 Administrators group 224 BusinessObjects 6.x to XI Release 2 Migration Guide

225 BusinessObjects 6.x to XI Release 2 Migration Guide Planning the migration chapter

226 13 Planning the migration Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning Formulating your migration strategy Repository migration options Migrating to XI R2-supported versions and platforms Capturing scheduling information What users/groups should you migrate? What objects should you migrate? Setting up a new folder/group structure International considerations Cleaning up your source environment 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Note: Before planning your migration in detail, it is recommended that you read all of Part I Migration fundamentals in this guide. Formulating your migration strategy The two major decisions impacting your migration strategy are: Do you want to migrate all at once, or over time? Do you want to migrate security, or recreate security from scratch in the new environment? 226 BusinessObjects 6.x to XI Release 2 Migration Guide

227 Planning the migration Formulating your migration strategy 13 Choosing your migration method You can migrate to XI R2 either all at once, or over a period of time. Single pass Incremental You can migrate to version XI R2 in a single pass with the Import Wizard, either with or without security. Single pass with security Do a single pass with security if your BI deployment is relatively small, and you don't want to recreate your security system in the new environment, or you want to go into production quickly. Typically, migrating security means you may end up with all documents in a single folder (assuming you had a single doc domain), which is quick but far from ideal. Single pass without security Do a single pass without security if you want to recreate security from scratch (applying best practices etc.) and if you want to migrate all your groups and applications at the same time, which is unlikely to happen in a large organization. Note: Single pass implies moving your XI R2 environment to production relatively quickly to minimize desynchronized modification of BI content in source or destination environments. Even after a single pass migration, an additional period of time is nonetheless required for specific post-migration procedures, verification of the migrated objects, comparison with the objects in the source deployment, verification of security, and other adjustments. There is no such thing as an instant migration. Most migrations are performed gradually, both in the initial, phased import of BI content, and in the ongoing updating of the destination environment in the transition period between the final shutdown of the source environment, and the switch to the destination system. The initial migration By importing your source user groups and content into the new environment gradually, you can validate the import s success after each pass with the Import Wizard; if there are issues, you don t have to begin the entire migration all over again. BusinessObjects 6.x to XI Release 2 Migration Guide 227

228 13 Planning the migration Formulating your migration strategy How you structure you migration s phases can depend on the structure of your repository or the logical groupings of user groups and resources. It is recommended that you use Supervisor to help you analyze your repository for logical groupings that help speed and ease migration. You might decide, for example to migrate incrementally by: department Your repository may reflect your organization s structure, with separate universe and document domains for specific departments, such as sales, HR, or marketing. Migrating this way allows you to treat each department s import as a separate project that you can test and fine-tune in the new environment. application (by resource type) Importing by resource type allows you to concentrate on a specific type of import at a time and limit use of the deployment to specific applications in the new environment in each stage. domain Importing universe and document domains separately allows the Import Wizard to perform a single type of import at a time. As documents and universes are organized by domains, and all the objects in a domain are migrated to the same folder in the CMS database, domains represent natural sets of objects within the migration process. This type of import is also logical given that different domains may be linked to different databases, or located in different places. Authorization may also differ from one domain to another. locale In some cases, the locales used in BusinessObjects and Web Intelligence documents may not be stored in the document definitions. As XI R2 documents require a locale, when you import documents, the Import Wizard allows you to choose a default locale for the entire set of documents you are importing. Importing sets of documents which use the same locale can therefore streamline the migration process by getting locales right immediately. Ongoing updates For most migration scenarios, safe migration requires a certain period of time, during which the imported content can be tested, fine-tuned and verified, often using staging areas and BIAR files for moving the content from the testing environment to production. The final environment will undoubtedly need adjusting for your organization s particular requirements, security testing, and rollout. 228 BusinessObjects 6.x to XI Release 2 Migration Guide

229 Planning the migration Formulating your migration strategy 13 In most circumstances, therefore, you will be performing ongoing updates on your destination environment as your source environment continues to evolve. The Import Wizard provides a number of incremental update options to give you more control over precisely what you migrate when you import objects more than once from the source to the destination repository: Overwrite object contents When you reimport an object, it will completely overwrite and replace the object (and its associated files) that you imported earlier. You can choose to do this for any or all of the following types of objects: Documents Universes Connections Overwrite object rights When you reimport an object, its associated security rights will overwrite the rights of the object you imported earlier. If you decided not to import security in the Security Migration Options dialog box, then the Overwrite object rights option is not relevant, and is therefore not available. If you don t select any overwrite options, the object in the destination repository will not change when you try to import it again. For more detailed information, see Understanding Import Wizard options on page 169. Importing security or not Migrating from one system to the other is an opportunity to review the existing security structure in the source environment with a view to benefiting optimally from the more secure framework provided in XI R2. The following chapters should allow you to appreciate just how different the 6.x and XI R2 frameworks are. Understanding user and group migration on page 65 Understanding object migration on page 81 Understanding rights migration on page 121 Understanding Application Foundation object migration on page 103 BusinessObjects 6.x to XI Release 2 Migration Guide 229

230 13 Planning the migration Formulating your migration strategy Although you can import version 6.x rights to XI R2 and obtain the same effective rights in XI R2, because of the difference in security models, subsequent modifications to rights can have unforeseen consequences. If you do not have a small deployment, it is recommended that you rebuild your environment s security from scratch in version XI R2 s superior security structure. One of the major advantages of version XI R2 is its flexible and granular security structure based on ACLs, a common IT standard. These ACLs encompass what in version 6.x environments are known as security commands, profiles, document access, and delegated administration. In version 6.x, you can use security commands to restrict user and group access to functionalities in Business Objects products.you cannot restrict access at the object level. For example, if you grant a group the right to refresh, but not create documents, the restriction will apply regardless of the documents being used. In XI R2, the use of ACLs means that imposition of restrictions is much more granular. You can apply user, group, and role level security at the object level, to documents, categories, folders, universes, connections, applications, and even servers and groups of servers. All hierarchies are based on inheritance: Folder hierarchies include root folders, and their cascading subfolders, and continue down through the objects each folder contains. Group hierarchies include root groups and their cascading groups. Common rules are used to compute aggregation and inheritance for these hierarchies. The resulting granularity means, for example, that you can allow a group to refresh document A, but not refresh document B. See Security migration options on page 170 for the Import Wizard options you can use to migrate your BI deployment without bringing security over with it. If you decide to recreate your security in the new environment, see Recreating security in XI R2 on page 213 for guidelines. Overall security recommendations after import Once you have imported your objects into the destination environment using the Import Wizard, it is recommended that you start configuring security by doing the following: 230 BusinessObjects 6.x to XI Release 2 Migration Guide

231 Planning the migration High-level migration strategy scenarios Set the default access level at the global level (all users) to No Access. Then grant specific access to the appropriate groups for specific folders. This is the most efficient way of restricting access to only the designated users. 2. Assign security at the folder level to groups whenever possible. Avoid setting rights for specific users on specific objects. This reduces the complexity of your security model. 3. Use predefined access levels whenever possible. Avoid setting advanced rights. This reduces the complexity of your security model. The XI R2 security model is a combination of application and object rights. To develop a model that supports customization of rights, consider defining functional groups for which you grant advanced object and application rights. High-level migration strategy scenarios To understand the implications of each of the Import Wizard options mentioned in this table, read Understanding Import Wizard options on page 169 Security migrated Single pass In the Import Wizard s Choose objects to import dialog box, select all source objects including users and groups, domains, documents, universes and connections, and categories. In the Security Migration Options dialog box, select the first or second option, indicating that you want to migrate security. It doesn t matter whether you choose Update or Merge as migration scenario. If you chose Update, it doesn t matter what you select in the Incremental Import dialog box. (If you chose Merge, this dialog box doesn t appear.) This imports all your source users and content into the XI R2 environment, along with the same approximate effective security. Incremental With each pass with the Import Wizard, select the users and/or objects you want to import. Select the first or second option in the Security Migration Options dialog box, indicating that you want to migrate security. The Update migration scenario is automatically selected for you. In the Incremental import dialog box, select whether you want imported objects to overwrite the content of instances already imported into XI R2, and/or the rights for those objects. Select the types of objects you want. This imports selected objects into the and content into the XI R2 environment; the same approximate effective security is retained in the destination environment. BusinessObjects 6.x to XI Release 2 Migration Guide 231

232 13 Planning the migration Repository migration options Security not migrated Single pass In the Import Wizard s Choose objects to import dialog box, select all source objects including users and groups, domains, documents, universes and connections, and categories. Select the third option in the Security Migration Options dialog box, which specifies you don t want to migrate security. It doesn t matter whether you choose Merge or Update as migration scenario. If you chose Update, it doesn t matter whether you choose to overwrite objects content. The option to overwrite objects rights is greyed out. This imports all your source users and content into the XI R2 environment without any security. Incremental With each pass with the Import Wizard, select the users and/or objects you want to import in the Import Wizard s Choose objects to import dialog box. Select the third option in the Security Migration Options dialog box, which specifies you don t want to migrate security. Choose Update as your migration scenario. In the Incremental Import dialog box, choose to overwrite objects content. Select the objects you want. The option to overwrite objects rights is greyed out. This imports selected objects into the XI R2 environment without any security. Repository migration options Before you migrate to XI R2 you need to decide if you want to merge your existing source repositories. You must also determine whether you need multiple repositories even if you did not in version 6.x. Merging multiple repositories into one In your version 6.x deployment, you may have multiple repositories or security domains. As the reason for multiple repositories may no longer be valid in XI R2, migration may provide an opportunity to merge existing repositories into one. 232 BusinessObjects 6.x to XI Release 2 Migration Guide

233 Planning the migration Repository migration options 13 With version 6.x you may have had to support distinct repositories for: managing complex security profiles In XI R2 a user can have a complex security profile. For example a user can view and refresh some documents, and just view others. This isn't possible in version 6.x. using different authentication/authorization schemes. (Not applicable for all versions). In XI R2 it is possible to set up different authentication schemes in which some users are able to use repository authentication, while others use Basic or an LDAP authentication. This isn't possible in version 6.x unless you use different web applications, one for each authentication scheme. If either of these reasons applies, then you may be able to merge your repositories into one. Merging repositories with the same ID If the source repositories you want to merge in XI R2 have different IDs, simply use the Import Wizard with the Merge option. If any two of the source repositories have identical IDs (often the case when a repository has been copied for an updated version of the Business Objects suite), however, the Import Wizard may not be able to distinguish between objects coming from one repository or the other. This is an issue if you are migrating security, because this migrates application rights. When you migrate application rights, you migrate supervisors. And when a user who was a supervisor in version 6.x is created in the XI R2 repository, to determine which group(s) the user is allowed to administer, the Import Wizard assigns the user to the group(s) that the original user had administration rights over. This assignment is based on the ID number of the source 6.x group(s). If the two repositories have the same repository ID and share the same group IDs, then this assignment will be incorrect. In this case it is therefore good practice to consolidate the repositories into a single one before migrating to version XI R2. Determining a repository s ID You can determine a repository s ID by running this SQL against the repository database: SELECT M_GENPAR_C_LABEL FROM OBJ_M_GENPAR WHERE M_GENPAR_N_ID=121 BusinessObjects 6.x to XI Release 2 Migration Guide 233

234 13 Planning the migration Repository migration options Note: Never change the repository ID. Any modification could lead to a number of unwanted side effects that could stop your system from working. Moving from one to multiple repositories in XI R2 There may be different reasons to split a repository into many distinct, separate repositories under XI R2, than you've seen for version 6.x. In XI R2 you may need a separate, distinct, repository for: Different life-cycle phases Distributed deployments Both of these are discussed in the next two sub-sections. Different life-cycle phases Before you can determine your migration path, remember how the Import Wizard works when promoting content from one XI R2 repository to another XI R2 repository (see The Merge and Update import scenarios on page 173 for detailed information). The Import Wizard offers two import scenarios: The Merge scenario adds objects. There is an option to rename if the object name clashes, if this option is not selected, then the new object is not created. If there is a name clash, then a new parent folder is created and the object is created in this new folder. The Update scenario adds and/or updates objects. This works by comparing objects by Cluster Unique Identifiers (CUIDs). If the CUID already exists, then the object is updated. If the CUID does not exist, then a new object is created. There is also an option to rename if the object name clashes. If the CUID matches but there is already an object of the same name, the new object will only be created, with a new name, if the rename option is selected. Should the CUID not match, the object will only be created if there is no name clash, unless the rename option is selected, in which case the object is created but with a new name. 234 BusinessObjects 6.x to XI Release 2 Migration Guide

235 Planning the migration Repository migration options 13 Using the Update scenarios for life-cycle management The Merge scenario does not replace existing objects, it only adds new objects. To use the Merge scenario for promoting content from one life cycle phase to another would therefore require that you delete all the target objects first, or alternatively perform the merge, and then remove duplicated objects. The Update scenario replaces existing objects, ideal for promoting content from one life cycle phase to another. It also allows you to change the names of objects. For example, you may have an object in the Prod environment called Customer Satisfaction v1 document. You can then develop an updated version to this called Customer Satisfaction v2 document in your Dev environment. If you are able to promote this object from Dev to Test, then Test to Prod, the Prod object will not only be updated, but its name will change to Customer Satisfaction v2 document. Quite an advantage over version 6.x. To make it possible to promote objects using the Update scenario, you must make sure that all your objects share CUIDs across all environments. The diagram above shows two objects: Sales Document Marketing Document All three instances of each document share the same CUID across all three repositories. Because the CUIDs are the same across all environments, this deployment can use the Update scenario to promote content from one environment to another. BusinessObjects 6.x to XI Release 2 Migration Guide 235

236 13 Planning the migration Repository migration options To arrive at this situation, you must follow one of two workflows depending on whether you deployed your version 6.x system: within a single repository: if this is the case there are other important considerations to be considered using separate repositories for each life-cycle phase Support for separate, distinct repositories for each life-cycle phase in XI R2 is considerably superior to version 6.x. The Import Wizard is designed to move content from one repository to another. When using the Import Wizard you specify which content (documents, universes, connections, users, etc.) you want to import. The Import Wizard can then either directly load that content into a target repository, or it can store the selected content into a BIAR file (Business Intelligence Application Resource). A BIAR file is like a.zip file, which can be passed around and loaded into a target repository later on. The file can also be re-applied. One of its advantages is that, should you want to roll-back, you can simply re-apply your original BIAR file. For more information on BIAR files, see the Import Wizard online help. Different life-cycle phases within a single repository The Update scenario is only available when you use separate, distinct repositories for each life-cycle phase. If you decide you want to manage different life-cycle phases within one repository, you will not be able to take advantage of the benefits of using the Update scenario. In version 6.x, you can manage different life-cycle phases such as Development, Test, and Production within a single repository by creating many different document/universe domains. With this type of deployment you have the option to: use different hardware for each life-cycle phase use a different installation of the Business Objects software for each lifecycle phase. This means you can test a Service Pack or a Hot Fix in isolation from your production environment. With XI R2 you no longer have these options. You can still manage all your different life-cycle phases within one repository, however. One repository directly implies the same cluster, the same hardware and the same software version (rules 1 and 3). 236 BusinessObjects 6.x to XI Release 2 Migration Guide

237 Planning the migration Repository migration options 13 To implement this in XI R2, you must create a normal object folder structure and a universe folder structure for each life-cycle phase. Make sure that only your production users can see the production folder structures and your development users can only see the development folder structures etc. You can then simply move or copy documents and universes from one folder structure to another when you want to promote from one life-cycle phase to another. You should create migration users that have access to multiple lifecycle phase folder structures so these users have permissions to copy or move content. It is important that your 'normal users only have access to one life-cycle phase folder structure, otherwise documents built on universes will not be refreshable. This is because of 'run-time rebinding'. A universe data provider, within a document, is 'binded' to a universe by means of the universe identifier. The universe identifier is unique within the repository. If at run-time the universe is not available, because the universe is no longer present or the user does not have access to it, then it will search for other universes of the same short filename. As long as only one other universe is found, then the data provider will automatically re-bind itself to that universe before refreshing the document. If multiple universes are found, the document will not refresh. If you manage all your life-cycle phases within one repository, as described above, it is quite typical for some users to be denied access to certain connections, but granted access to others. When a universe is promoted from one life-cycle phase folder structure into another, the universe will point to a connection that the users may not have access to. Manual intervention will be required to correct this so that the universe points to the correct connection. BusinessObjects 6.x to XI Release 2 Migration Guide 237

238 13 Planning the migration Repository migration options It is recommended that you use separate, distinct repositories for each lifecycle phase. To migrate to this structure from a source environment in which all life-cycle phases were managed within a single repository, you must take the following steps. Note: The diagram uses the term XI R2 repository to represent both the repository and the FRS. 1. Migrate users, documents, universes, connections, and so on from your source repository to your new Development XI R2 repository. Migrate only content from your security domain and your production universe and document domains -- not from your Development and Test domains. 2. Copy all the content from your Development XI R2 repository to Test XI R2 repository. 3. Copy all the content from Test to Production. The CUID of an object in one repository will now have the same CUID as its corresponding objects in the other repositories. 238 BusinessObjects 6.x to XI Release 2 Migration Guide

239 Planning the migration Repository migration options 13 This process implies that all development and test work has been promoted to production, since these domains are not migrated. BusinessObjects 6.x to XI Release 2 Migration Guide 239

240 13 Planning the migration Repository migration options Separate repositories for each life-cycle phase To migrate your source deployment to XI R2 which will enable you to use the Update scenario you must take the following steps. 1. Migrate all users and content from your Production source repository to your new Development XI R2 repository. Do not migrate content from your Development and Test repositories. 2. Copy all the content from your Development XI R2 repository to Test XI R2 repository. 3. Copy all the content from Test XI R2 to Production XI R2. The CUID for an object in one repository will now have the same CUID as its corresponding objects in the other repositories. 240 BusinessObjects 6.x to XI Release 2 Migration Guide

241 Planning the migration Migrating to XI R2-supported versions and platforms 13 If you do not follow this workflow, but decide to migrate each repository to an XI R2 repository, then each object will have a CUID that is not shared across the other repositories. You will not benefit from the Update scenario features mentioned above, and will only be able to use the Merge scenario. This process implies that all development and test work has been promoted to production, since these domains are not migrated. Migrating to XI R2-supported versions and platforms Before beginning migration, you must evaluate which platform and version changes you will need to implement as you move from your source to destination environment. These factors include supported databases, web and application servers, web browsers, and operating systems. In this context, the term upgrading means moving to a newer version of the same software, such as from IIS 5.0 to IIS 6.0. Migrating, on the other hand, means moving to a different brand of software completely, such as from Tomcat to WebLogic. Note: For a constantly updated list of supported platforms and versions, see: Changing repository databases The Import Wizard seamlessly migrates your BI content from any supported version 6.x database to any supported XI R2 database. BusinessObjects 6.x to XI Release 2 Migration Guide 241

242 13 Planning the migration Capturing scheduling information Changing query databases You must migrate any data from databases that are not supported for XI R2 to supported platforms. If you do not, universes based on those databases will not work. Capturing scheduling information If you are planning to schedule documents for batch processing in the new environment, you need to record scheduling information from the source system prior to the import because the Import Wizard does not import all jobs from version 6.x. You may need to recreate some schedules in the XI R2 environment. You can use the Broadcast Agent Console to capture detailed information about the documents you have scheduled in your version 6.x deployment, including the type of document (BusinessObjects or Web Intelligence), its size, location, and scheduling duration and intervals. For a full list, see the Broadcast Agent Administrator s Guide. From the Console you can export the list of scheduling tasks in.csv (Comma Separated Value) format, which makes the list printable and viewable from a standard text editor. You can also use Auditor to analyze information concerning Broadcast Agent usage, such as jobs per user, Broadcast Agent, and frequency. For more information, see the version 6.x BusinessObjects Auditor Guide. What users/groups should you migrate? Migrating to a new system in which users and groups are organized differently, and security is based on completely different rights inheritance and aggregation models gives you the opportunity to rethink your current security system. Instead of trying to superimpose your current user/group security framework on the new framework, it is recommended that you assess, before import, how you can best take advantage of the reinforced security and granularity provided by BusinessObjects Enterprise XI R2. Before migration, remove useless users and groups. Auditor can help you assess this. Its predefined indicators let you check for the last time users logged in, for example, or for users who have never logged in. The User Information Detail indicator tells you what users are in each group. 242 BusinessObjects 6.x to XI Release 2 Migration Guide

243 Planning the migration What objects should you migrate? 13 This is also the moment to reorganize users and groups into more functional groupings, and review delegated administration. What objects should you migrate? You should only migrate universes, documents, and categories still useful for your organization. It is recommended that you use BusinessObjects Auditor to monitor and analyze which documents and universes are used, and with what frequency. Auditor comes with a set of pre-defined indicators, each one of which contains one or more BusinessObjects reports focussing on a specific area of analysis. These indicators can help you pinpoint those documents and universes (and even universe objects) which are rarely or no longer used. BusinessObjects documents For each BusinessObjects document in the source environment, you have four migration options: Declare the document obsolete and either leave it in the source environment or delete it altogether. Import the document, then re-use it in the new Desktop Intelligence format. Import the document, and then convert it to Web Intelligence format using the Report conversion tool. Rewrite the document in the new environment using Crystal Reports. Have some documents become obsolete? Business Objects suggests you use BusinessObjects Auditor to monitor which documents have become obsolete in your version 6.x deployment. For example, you can use the pre-defined indicators 10 Least Read Reports or Document Usage. One option is to move all the obsolete documents into a specific category then not select that category when running the Import Wizard. BusinessObjects 6.x to XI Release 2 Migration Guide 243

244 13 Planning the migration What objects should you migrate? To convert or not to convert (.rep to.wid) By converting BusinessObjects documents to Web Intelligence format you can benefit from interactivity over the web in a zero-footprint environment. This also reduces the size of the document. It is recommended that you not convert BusinessObjects documents to Web Intelligence format when the documents use: One or multiple VBA macros Non-universe data providers The Show/Hide object feature Conditional formatting It is recommended that you convert when: The above features are rarely used. You require a strictly web deployment. Users need interaction with reports. To rewrite or not to rewrite (.rep to.rpt) Enterprise reports It is recommended that you not import certain BusinessObjects documents, but instead rewrite them directly in Crystal Reports XI R2 when these documents: served an enterprise reporting purpose in the first place have sophisticated formatting requirements For more information, see the Crystal Reports XI R2 User s Guide. The scenario is typically the following: A group of IT experts centralizes users requests and creates reports to address users needs. The documents are pushed to a large number of report consumers through the InfoView portal. In this type of scenario, it may be better to use Crystal Reports to author the reports. Crystal Reports provides better scalability and on a large scale, is a better solution for enterprise reporting. 244 BusinessObjects 6.x to XI Release 2 Migration Guide

245 Planning the migration Setting up a new folder/group structure 13 Highly formatted reports Crystal Reports may also be a better choice when users require: Pixel-perfect quality reports Printable reports Highly formatted reports Financial reports Regulatory/legal reports Setting up a new folder/group structure To prevent security breaches, you will need to create a new folder and group structure in the destination environment, and then move documents into the folders, and users into the groups, before any users begin to use the system. In version 6.x, you publish documents to a group (this secures the document so that no one outside that group can see it) and to a document domain (the container). In version XI R2, you publish to a folder (the container) only; you do not specify security at that time. In terms of migration, this difference is exposed in the following manner: When you import security, the rights imported on the objects are correct, regardless of the folder they re in and so they make sure that the right users see the right objects. When new objects are published to the folder from XI R2, however, they inherit the rights of the folder. Anyone having access to the domain folder, therefore, will have access to all the documents within it, unless the rights for specific document objects, defined in the CMC, prohibit it. Instead of having an administrator define specific rights on each document each time it is published, you must set up a coherent folder and group structure that will manage access to published documents through inheritance. BusinessObjects 6.x to XI Release 2 Migration Guide 245

246 13 Planning the migration Setting up a new folder/group structure You can do this before or after the import, but the structure must be in place before users begin using the system. If you don t import security, you will need to create your new security system in XI R2 before system use. For detailed information, see Recreating security in XI R2 on page 213. Setting up an adequate initial folder/group structure in the destination repository involves: Creating a new document folder structure in the destination repository Creating a new group structure based on role in the destination repository Implementing the relationships between the two 246 BusinessObjects 6.x to XI Release 2 Migration Guide

247 Planning the migration Setting up a new folder/group structure 13 Creating a new document folder structure Your destination document folder structure should mirror your source group structure. If the document domains in the source repository are generally mapped one-to-one to a specific user group (only one group has the right to access the documents in a specific domain), your task is relatively simple: for each of the groups in the source repository, simply create a document folder for each group beneath the Public folder. From the version 6.x groups......create these document folders beneath the pre-existing Public folder. If the source repository is not structured according to clear groupdocument domain relationships, then you will need to determine how best to structure the destination folder system in order to group documents to be accessed by a single group only. BusinessObjects 6.x to XI Release 2 Migration Guide 247

248 13 Planning the migration Setting up a new folder/group structure Once you have created your new folder structure, and after you have imported your documents into their destination domain folders, you copy (do not move) the documents into the appropriate folders in the new folder structure. In the end, all the documents in a given folder should be available to a specific group. If documents are shared by multiple groups You have two options for structuring documents accessed by more than one group: Option 1: You can copy the document into the folder corresponding to each group with access to the document. Advantage You don t have to create shared folders. Disadvantage You may end up with lots of copies of documents that may need maintaining. Option 2: For documents being shared by the same groups, you can create shared folders. Advantage You have only one instance of a shared document to manage. Disadvantage You must create stored folders, which requires the proper analysis up front. 248 BusinessObjects 6.x to XI Release 2 Migration Guide

249 Planning the migration Setting up a new folder/group structure 13 Creating a new group structure based on role Now create a new group structure in the destination repository which groups users not by their business or geographical area (as in the diagrams above), but by the common sets of rights they are granted on documents. For example, in version 6.x, the Sales group uses the documents in the repository s Sales domain. Not everyone in the Sales group has the same rights on the objects in that domain: some people can create documents, some can edit them, others can only view or refresh documents. For example: Power users Schedule documents Edit documents Publish documents Refresh documents BusinessObjects 6.x to XI Release 2 Migration Guide 249

250 13 Planning the migration International considerations Note: The following table sums up the main actions users can take on documents, as well as the mechanisms which enforce rights to these actions in version 6.x, and in version XI R2. Document actions Version 6.x Version XI R2 View Object right Object right Refresh Security command (application right) Object right Create Security command (application right) Application right Edit Security command (application right) Object right Publish Security command (application right) Object right Implementing the relationships between the two Now give access rights to specific document folders to the appropriate role groups, so that your users can do the right things on the objects within those folders. Once this is done, whenever a document is published to a folder, the correct users automatically have the correct rights to that document, and all the documents in the folder. International considerations Specifying document locales for import In the 6.x repository, some.wqy and.rep (as well as associated.rea and.ret files) documents may not store their locale. To set the locales in these documents when they are saved in the CMS after their conversion into XI R2 format, the Import Wizard asks for default locales: the document s locale the locale of the machine used to create the document Locale format is: language iso-639(lower case) + "_" + country iso-3166 (upper case). For example: en_us. 250 BusinessObjects 6.x to XI Release 2 Migration Guide

251 Planning the migration Cleaning up your source environment 13 Once you select these locales, they are stored in the document itself when it is imported to the CMS. These default locales apply to all documents without locales in the current import. Applying wrong locales to a document may corrupt it (date, currency incorrectly displayed) If the repository contains documents with different locales, it is best practice to run the import by steps, one step for each document language, in order to avoid setting a default English locale to a Japanese document for example. Cleaning up your source environment When documents are removed from the 6.x repository by importing them into the destination environment, they are logically but not physically deleted. To physically delete documents that have already been deleted logically, you should use Supervisor s Compact action on each document domain (Tools > Repository > Scan). Even before importing, it is a good practice to perform a Repair and Compact, which checks the repository domains for structural and consistency errors, and deletes useless documents. Be aware that a Repair and Compact can be a time-consuming procedure. BusinessObjects 6.x to XI Release 2 Migration Guide 251

252 13 Planning the migration Cleaning up your source environment 252 BusinessObjects 6.x to XI Release 2 Migration Guide

253 Importing to the destination environment part

254

255 BusinessObjects 6.x to XI Release 2 Migration Guide Before using the Import Wizard chapter

256 14 Before using the Import Wizard Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The phases in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning 3. Preparing for import Before installing XI R2 Installing XI R2 Before importing 4. Importing from the source to destination environment 5. Post-import checking and tuning Before installing XI R2 Before installing version XI R2, prepare your system by: Running a Repair and Compact on your source repository Backing up your source repository Exporting locally stored objects Updating platforms and versions if required Creating data sources on destination machines for all domains in source deployment Running a Repair and Compact on your source repository Use Supervisor to check the integrity of your source repository s security and document domains by scanning domains for structural and consistency errors, as well as physically delete documents that have been logically but not physically deleted. To do this, click Tools > Repository > Scan. Be aware that a Repair and Compact can be a time-consuming procedure. 256 BusinessObjects 6.x to XI Release 2 Migration Guide

257 Before using the Import Wizard Before installing XI R2 14 Backing up your source repository Business Objects strongly recommends backing up your 6.x source repository before beginning the migration. In addition, it is good practice to run the Import Wizard on a copy of the source repository, and not on the production version. If you follow this practice, make sure that you point all the domains to the copied repository, so that the domains are no longer associated with the original (production) repository. Exporting locally stored objects Objects that you are planning to import to the destination environment using the Import Wizard must reside in the version 6.x repository. If objects are stored locally on users computers, you must make sure the users export the objects to the repository before you begin the import. Tip: Create a specific category to store local content. Updating platforms and versions if required For performance or support reasons, you may be required to update various components (operating system, web server, application server, web browsers, databases, etc.) in your Business Intelligence environment either to more recent versions, or to different platforms altogether. It is recommended that you read the official list of supported platforms carefully for the most up-to-date support information. You can find it at: Recreating required connectivities Migrating to a different repository database The databases supported as repository databases in version 6.x may not be supported as CMS databases in version XI R2. Nonetheless, the Import Wizard can import objects from any supported type of source repository database seamlessly into any supported CMS repository database. BusinessObjects 6.x to XI Release 2 Migration Guide 257

258 14 Before using the Import Wizard Installing XI R2 Migrating query databases All data access is kept from version 6.x. Connection Server is an integral part of BusinessObjects Enterprise XI R2, and all the databases it supported in version 6.x continue to be supported in the new environment. Check the list of supported platforms at supported_platforms_xi_release2/, however, for the specifically supported driver versions. If you do not migrate data in unsupported database platforms to a supported platform, universes based on them will not work in the destination environment. ONAMES on Oracle The Import Wizard does not support Oracle systems that use ONAMES naming servers. You must use TNSNAMES instead. Creating data sources on destination machines for all domains in source deployment Create data sources on each destination server machine for every repository domain in the source deployment. The name and configuration details for the data sources must match the data sources in the source deployment. Certain databases that can host a version 6.x repository are not supported for an XI R2 repository. For the latest information, see the list of supported platforms at: Installing XI R2 For complete instructions for installing BusinessObjects Enterprise XI R2, see the BusinessObjects Enterprise Installation Guide. Install at least one CMS. Install Desktop Intelligence on client machines. Install the Import Wizard on a Windows machine. 258 BusinessObjects 6.x to XI Release 2 Migration Guide

259 Before using the Import Wizard Installing XI R2 14 Where should I install the Import Wizard? If you are using Windows server machines, the Import Wizard is installed on the BusinessObjects Enterprise XI R2 server machine by default. This speeds up the Import Wizard s connection to the CMS and the File Repository Servers. You can install the Import Wizard using a Custom install, either on a standalone Windows machine, or even on an existing version 6.x Windows server. If you install it on a standalone machine, the import process will not interfere with server processing in either the source or destination deployments. If you install it on a version 6.x machine, communication is faster with the source repository and cluster. Both of these Custom options result in more CORBA traffic with the CMS. You must also make sure that any firewalls between the Import Wizard machine and the CMS machine are taken into account and are correctly configured to permit communication through appropriate ports. If you are using UNIX server machines If your XI R2 server runs on UNIX, you need to install the Import Wizard on a separate Windows machine. You also need to use a third-party utility to map the Windows drives to UNIX. See the Microsoft documentation on Interoperability with UNIX/Planning and Installing Services for UNIX on Windows 2000 Professional. As of this writing, the URL is: reskit/en-us/default.asp?url=/resources/documentation/windows/2000/ server/reskit/en-us/prork/prci_unx_houn.asp Tips for optimal Import Wizard performance You can substantially reduce importing time if you install the Import Wizard on the same machine as the CMS and the CMS repository database. If the repository is split among different sites, accessing remote domains via the Import Wizard may take a long time, depending on network traffic and bandwidth. To further reduce import duration, Business Objects highly recommends that you copy the remote source repository domains to the local machine. Update the repository to these local copies before running the Import Wizard. BusinessObjects 6.x to XI Release 2 Migration Guide 259

260 14 Before using the Import Wizard Before importing To streamline access and optimize import time, it is recommended that you use several physical disks, so that parallel Input Output file access can be performed: one disk containing the XI R2 installation folder, and specifically the Import Wizard executable. By default, it is located in C:\ one disk for the file system containing the objects stored in the repository (CMS and FRS) one disk for the Import Wizard temporary folder. This temporary folder can be modified by using the IMPORTWIZARDTMP variable (see Flow of resources on page 83). Make sure these last two disks contain enough free space. Because all objects to be imported in the CMS are first copied to the temporary folder, the free space in the temporary folder must be greater than the combined size of all imported objects. If you are using Tomcat If you are migrating from v. 6.5 to XI R2, and using Tomcat as application server, you may encounter a conflict when the Tomcat in both the source and destination environments try to use the same default port. If this occurs, you can manually change the port number of one of the Tomcat applications servers (to 8081, for example). To change the port number 1. Open the server.xml file. 2. Modify the port number. For example, if you are using standard authentication, the line to edit would be: <Connector classname="org.apache.coyote.tomcat4.coyoteconnector" port="8081" minprocessors="5" maxprocessors="75" enablelookups="true" redirectport="8443" acceptcount="100" debug="0" connectiontimeout="20000" useurivalidationhack="false" disableuploadtimeout="true" /> 3. Restart Tomcat. Before importing Before importing with the Import Wizard: 260 BusinessObjects 6.x to XI Release 2 Migration Guide

261 Before using the Import Wizard Before importing 14 Backing up the destination CMS database Ensuring you have appropriate rights Checking for correct Import Wizard installation Mapping the Import Wizard to Inbox and personal files Ensuring the Import Wizard can connect to the XI R2 CMS Starting destination servers Setting up auditing in the destination system If you count on using an LDAP external user management system, Configuring the LDAP security plug-in Backing up the destination CMS database If you have any content in the destination CMS database, make sure you have a copy in case the database become corrupted. Ensuring you have appropriate rights Make sure you have the following rights: In version 6.x, you must have a General Supervisor profile. In XI R2, you must belong to the Administrator group in the CMS. To import any resource into the CMS, you must have the rights needed to add objects to the destination folder to which the resource is assigned. Checking for correct Import Wizard installation Make sure the Import Wizard is properly installed by launching it by clicking Start > Programs > BusinessObjects 11.5 > BusinessObjects Enterprise > Import Wizard. The executable file (ImpWiz.exe) is located in: $INSTALLDIR\BusinessObjects Enterprise 11.5\win32_x86\ Mapping the Import Wizard to Inbox and personal files On the Import Wizard machine, map the drives to the source environment directories containing the deployment s.key files, personal documents and categories, and users Inboxes: $INSTALLDIR\locData for access to 5.1.x.key files BusinessObjects 6.x to XI Release 2 Migration Guide 261

262 14 Before using the Import Wizard Before importing $WISTORAGEDIR\user if you are importing personal documents and categories $WISTORAGEDIR\mail if you are importing the read content of users Inbox folders $INSTALLDIR\nodes\<nodename>\<clustername>\locdata for access to 6.x.key files $INSTALLDIR\nodes\<nodename>\<clustername>\storage\user if you are importing personal documents and categories $INSTALLDIR\nodes\<nodename>\<clustername>\storage\mail if you are importing the read content of users Inbox folders If your server machines are running UNIX To import version 6.x Inbox and personal files from one UNIX environment to another, you must tar the source files from each cluster node, then unzip them into folders on the Import Wizard Windows machine before running the import. On the Import Wizard machine, map drives to the local folders containing the unzipped source environment directories. Ensuring the Import Wizard can connect to the XI R2 CMS The Import Wizard connects to the CMS through CORBA. Make sure you use appropriate ports if you have to go through a firewall. Starting destination servers Before importing, you must start and enable at least the following servers in the XI R2 environment, using the CMC: Central Management Server Input File Repository Server Output File Repository Server To log on to the CMC: 1. In an Internet browser: 262 BusinessObjects 6.x to XI Release 2 Migration Guide

263 Before using the Import Wizard Before importing 14 Go to the following page: Replace <webserver> with the name of the web server machine that has the Web Connector component installed. If you changed this default virtual directory on the web server, you will need to type your URL accordingly. If you have BusinessObjects Enterprise installed locally on your machine, click Start > Programs > BusinessObjects Enterprise 11.5 >BusinessObjects Enterprise Administration Launchpad. Inside the Launchpad, click Launch the Central Management Console. Go to the following page: Replace <webserver> with the name and port number of your Java application server. 2. When the Log On page appears, select Enterprise in the Authentication Type list. 3. Type your username and password. 4. Click Log On. The CMC Home page appears. Note: If you cannot access BusinessObjects Enterprise, start the Central Configuration Manager (CCM) from the BusinessObjects Enterprise program group. Ensure that all of the servers listed are both started and enabled. Setting up auditing in the destination system Auditing allows you to monitor and record key facts about your XI R2 system. You can set up auditing to track errors in the import process. The CMS acts as the system auditor. The BusinessObjects Enterprise servers are the audited components. To track errors in the import process, you first determine which servers control the actions involved in importing. Then you enable auditing of those actions in the Server Management area of the CMC. The server records the audit results in a local log file. For more information and instructions, see the BusinessObjects Enterprise XI Release 2 Auditor s Guide. BusinessObjects 6.x to XI Release 2 Migration Guide 263

264 14 Before using the Import Wizard Before importing Configuring the LDAP security plug-in If you want the Import Wizard to import external LDAP groups, you need to configure XI R2 with the LDAP server used by your 6.x system. For more information, see the BusinessObjects Enterprise XI Release 2 Administrator s Guide. 264 BusinessObjects 6.x to XI Release 2 Migration Guide

265 Before using the Import Wizard Before importing 14 If you plan on using an LDAP provider for authentication, you must configure the LDAP wizard in the BusinessObjects XI R2 system before importing the external users. 1. Configure LDAP from the CMC. You just have to configure the connection parameters, you don t have to map any groups. 2. Use the Import Wizard to import your content make sure you check the option when it asks you about LDAP users. Note: The Import Wizard will add an LDAP alias to every group brought over that it can find in the configured LDAP system (it does this by matching the name of the group to the name of a group in the LDAP system) Note: The Import Wizard will do an update of the LDAP plug-in after the users and group have been brought over, this will add an LDAP alias to every user that belongs (in the LDAP system) to one of the groups with an LDAP alias. 3. After Import, it s recommended that the administrator go through the users and groups in the XI system to make sure that the Import Wizard made correct assumptions about what users and groups were intended to be LDAP users and groups. Administrator should delete/re-assign/add LDAP aliases as necessary. Additional LDAP groups can also be mapped at this point if you want to. Note: If you chose to import user s personal content, only users that actually exists (i.e. have user objects) in the repository will have their personal content imported to XI R2. BusinessObjects 6.x to XI Release 2 Migration Guide 265

266 14 Before using the Import Wizard Before importing 266 BusinessObjects 6.x to XI Release 2 Migration Guide

267 BusinessObjects 6.x to XI Release 2 Migration Guide Using the Import Wizard chapter

268 15 Using the Import Wizard Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The steps in blue are described in this chapter. Where you are now Step in overall migration process 1. Assessment and planning 2. Preparing for import 3. Importing from the source to destination environment Launching the Import Wizard Setting the source and destination environments Selecting the types of objects to import Selecting an import scenario Importing specific objects Finalizing the import If you re migrating Application Foundation 4. Post-import checking and tuning Overview The Import Wizard lets you import Business Intelligence resources to XI R2. These resources include users and user groups, universes, connections, and documents. Chapter 6: Understanding object migration explains how the Import Wizard imports resources. This chapter explains how to perform the import. Note: Before using the Import Wizard, you must have completed all steps in Chapter 14: Before using the Import Wizard. 268 BusinessObjects 6.x to XI Release 2 Migration Guide

269 Using the Import Wizard Launching the Import Wizard 15 How long will importing take? How long importing takes depends on a number of factors. Performance is best if: the Import Wizard is on the same machine as the CMS and the repository database you have copied the source repository domains to the Import Wizard machine Document import can be time-consuming, taking up to three seconds per document. It may take even longer if you are accessing a remote repository through the network, or if your source repository is geographically distributed. The size of the documents and the number of users are also key factors, as is the size of the repository. Launching the Import Wizard The Import Wizard guides you through the process of importing user accounts, groups, universes, documents, and other objects. The dialog boxes that appear vary, depending on the source environment and the types of information that you import. First, you connect to the source repository and specify the destination CMS. You then select the information you want to import, and the Import Wizard imports the requested information from the source to the destination. During import, all objects in the source repository are copied to a temporary folder on the machine running the Import Wizard. (See Flow of resources on page 83.) To launch the Import Wizard On a Windows machine in the destination environment, do either of the following: From the Windows Start menu, point to Programs > BusinessObjects 11.5 > BusinessObjects Enterprise > Import Wizard. From the command prompt, run ImpWiz.exe. ImpWiz.exe is located in: $INSTALLDIR\BusinessObjects Enterprise 11.5\ win32_x86\ The Welcome page appears. BusinessObjects 6.x to XI Release 2 Migration Guide 269

270 15 Using the Import Wizard Setting the source and destination environments Summary of steps The remaining steps in the Import Wizard are divided into: Type of import and type of object Setting the source and destination environment Selecting the types of objects to import Selecting import options Selecting an import scenario Importing specific objects Users and groups Broadcast Agents Categories Document domains and documents Universe and connection objects Universe domains and universes Setting the source and destination environments In this step, you set a source environment and a destination environment. To set the source and destination environments 1. On the Welcome page of the Import Wizard, click Next. The Source Environment dialog box appears. If you are importing Application Foundation objects, go to If you re migrating Application Foundation on page In the Source list, select BusinessObjects Enterprise 6.x You are prompted for administrative account information. The fields that appear depend on the type of source environment you selected. 3. Type a user name and password that give you administrative rights to the source environment. Note: You must have a General Supervisor profile in the repository. 4. In the Domain Key File field, type or browse for the path to the.key file you created for the repository in your source environment. 270 BusinessObjects 6.x to XI Release 2 Migration Guide

271 Using the Import Wizard Selecting the types of objects to import If you want to import Application Foundation objects using the Import Wizard, select the Import Application Foundation Contents check box. You can import Application Foundation objects only if you selected BusinessObjects Enterprise 6.x (or XI) in the Source list. Note: If you are importing Application Foundation objects, go to If you re migrating Application Foundation on page Click Next. A warning appears that summarizes the items that can be imported. 7. Read the warning, and then click Next. The Destination Environment dialog box appears. 8. Type the name of the CMS of the destination environment. 9. Type a user name and password that give you Administrator rights to the destination environment, and then click Next. The Import Wizard verifies the login at the CMS. The Select Objects to Import dialog box appears. 10. Click Next. Selecting the types of objects to import In this stage of the importing process, you select the types of objects you want to import. At a later stage, you will select the objects themselves. To select the types of objects to import 1. In the Select Objects to Import dialog box, select the types of objects you want to import. The options that appear depend on the source environment and its version, and on whether you selected the Import Application Foundation Contents check box. See If you re migrating Application Foundation on page 281 for details. Note: The Import Broadcast Agent Schedules check box is dimmed and cannot be selected if there are no Broadcast Agents and no jobs to import in the repository. 2. Click Next. BusinessObjects 6.x to XI Release 2 Migration Guide 271

272 15 Using the Import Wizard Selecting the types of objects to import Security Migration Options If you selected Import users and user groups in the Select Objects to Import dialog box, the Security Migration Options dialog box appears. (If you did not select it, go to Personal and inbox documents on page 272.) The Security Migration Options dialog box allows you to select the way you want to migrate security and whether you want to migrate security at all. There are three options: Yes, migrate security on imported objects and secure the destination system This is the most secure option. Yes, migrate security on imported objects Users in the destination system may receive more rights than in the source system. No, don t migrate security Select this option only if you are rebuilding security in XI R2. For more information, see Security migration options on page 170. Note: Universe overloads are not included in the Security migration. You select overload migration in Universe and connection objects on page 279. To select a security migration option 1. In the Security Migration Options dialog box, select one of the three options. 2. Click Next. Personal and inbox documents If, in the Select Objects to Import dialog box, you selected the import of objects stored either in inbox or personal folders, the Personal Documents and Inbox Documents dialog box appears. (If you did not select it, go to Selecting an import scenario on page 274.) For more information on how Personal and Inbox documents are migrated, see Personal documents on page 86 and Inbox documents on page BusinessObjects 6.x to XI Release 2 Migration Guide

273 Using the Import Wizard Selecting the types of objects to import 15 To import personal and/or inbox documents 1. If you want to import unread Inbox documents (of imported users), select the check box. These unread Inbox documents are stored in the repository. 2. If you want to import read Inbox documents (of imported users), select the check box and type or browse for the path in the source environment. If the folders are located on a remote or UNIX server, you must have mapped them to local drives. 3. If you want to limit the import of Inbox documents to those received after a certain date: Select the Import Inbox documents received after check box Set the date 4. Type or browse for the path of your Personal documents in the source environment. If the folders are located on a remote or UNIX server, you must have mapped them to local drives. BusinessObjects 6.x to XI Release 2 Migration Guide 273

274 15 Using the Import Wizard Selecting an import scenario 5. If you want to limit the import of Personal documents to those created or modified after a certain date: Select the Import Personal documents that have been modified or created since check box Set the date 6. Click Next. The Import Scenario dialog box appears. Selecting an import scenario You can merge the source and destination environments, or you can update the destination environment without merging: Merging the environments The Import Wizard adds all objects from the source to the destination CMS without overwriting objects in the destination environment. This is the safest import option. All of the objects in the destination environment are preserved. Updating the destination environment All objects in the source are added to the destination CMS, but if a source object has the same unique identifier as an object in the destination environment, the destination object is updated. For more information, see The Merge and Update import scenarios on page 173. To select an import scenario 1. In the Import Scenario dialog box, select the type of import you want. To merge the source and destination environments, select I want to merge the source system into the destination system. If you want to automatically rename top-level folders that match toplevel folders on the destination system, select the check box. To update the destination environment without merging, select I want to update the destination system by using the source system as a reference. If you want to automatically rename objects when an object with the same title already exists in the destination folder, select the check box. 274 BusinessObjects 6.x to XI Release 2 Migration Guide

275 Using the Import Wizard Selecting an import scenario Click Next. If you selected the Update option in the previous step, the Incremental Import dialog box appears. Go to Updating previously imported objects on page 275. If you selected the Merge option, you are prompted to select specific objects for import. Go to Importing specific objects on page 276. Updating previously imported objects You may need to import some objects more than once from the source repository to the destination repository. In this situation, you have the following update options: Overwrite object contents You select the types of objects for which the content overwrite applies: Dashboards, Analytics, and Documents Universes Connections When you reimport an object, it will completely overwrite and replace the object (and its associated files) that you imported earlier. Overwrite object rights When you reimport an object, its associated security rights will overwrite the rights of the object you imported earlier. If you decided not to import security in the Security Migration Options dialog box, then the Overwrite object rights option is not relevant, and is therefore not available. If you don t select any overwrite options, the object in the destination repository will not change when you try to import it again. To update previously imported objects 1. In the Incremental Import dialog box, select the type of objects whose content you want to overwrite: Dashboards, Analytics, and Documents Universes Connections 2. If you want to overwrite object rights, select the Overwrite object rights check box. BusinessObjects 6.x to XI Release 2 Migration Guide 275

276 15 Using the Import Wizard Importing specific objects 3. Click Next. Depending on the type of objects that you selected for import, you are prompted to select specific objects. Go to the section below for instructions regarding that object type. If the Ready to Import dialog box appears, go to Finalizing the import on page 280. Importing specific objects LDAP/AD options If you chose to import users, groups, domains, Web Intelligence documents, BusinessObjects documents, categories, universes, folders, repository objects, or Broadcast Agents, you are now prompted to select the specific objects you want to import. You can import all of the objects or select individual ones. At each stage, it may take some time for objects to be displayed, because the Import Wizard is retrieving them from the repository. If your source repository is 6.x and if an LDAP configuration is found in the 6.x system, the LDAP/AD Options dialog box is displayed. (See Migrating external groups (LDAP/Active Directory) on page 77.) You are notified that you need to have the same LDAP or Active Directory configuration on both the source and destination environments. To select LDAP/AD options 1. Read the notice on the LDAP/AD Options dialog box, and take action if necessary. 2. Click Next. The LDAP/AD group mapping and external users page appears. 3. If you want to import LDAP or Active Directory group mappings, select the appropriate check box. 4. If you want to import external users, select the Import external users check box. 5. Click Next. If you have chosen to import external users, then mapped LDAP/AD users will be displayed in the list of users to import (see Users and groups on page 277). You will be able to choose the ones to import. 276 BusinessObjects 6.x to XI Release 2 Migration Guide

277 Using the Import Wizard Importing specific objects 15 Users and groups If you are importing users and groups, the Users and Groups dialog box appears. For detailed information on the import of users and groups, see Understanding user and group migration on page 65. To select users and groups 1. In the Groups list, select the groups you want to import. 2. In the Users list, select specific members of any group. For performance reasons, external users are listed at the root level in the user/group tree. All external users are part of the External group. The actual group association for the selected users takes place only after you click the Finish button. 3. If you want all groups containing users you select to be imported automatically, select the Select groups that contain selected users check box. 4. Click Next. Populating database credentials After users and groups are imported, the Populate Database Credentials for Users dialog box appears. This dialog box enables you to automatically set the DBUSER and DBPASS attributes, for all imported users, with their login and password. These can be used as default database credentials for connections (see BOUSER/ BOPASS on page 94). To populate database credentials 1. Do either of the following: If you want to populate the database credentials of imported users with their BusinessObjects user name and password, select Yes. If you do not want to do this, select No. 2. Click Next. BusinessObjects 6.x to XI Release 2 Migration Guide 277

278 15 Using the Import Wizard Importing specific objects Broadcast Agent Categories If you are importing Broadcast Agents, the Broadcast Agents dialog box appears. This dialog box enables you to select the Broadcast Agents you want to import. Under each domain in the tree, jobs are organized into two major folders: Corporate domain schedules Inbox schedules Note: A Broadcast Agent job can be migrated from BusinessObjects Enterprise 6.x to XI R2 only if the job is supported in XI R2. (For details, see Broadcast Agent Scheduler on page 87.) To select Broadcast Agents for import 1. In the Broadcast Agent dialog box, select the jobs you want to import. Note that all the jobs, for each selected Broadcast Agent, are selected by default. 2. Click Next. If you are importing categories, the Categories dialog box appears. To select categories 1. Select the categories you want to import. For large document domains, you can import incrementally, and import documents one category at a time. 2. If you want to import all the objects associated with the category, select the Import all objects that belong to the selected categories check box. 3. Click Next. Document domains and documents If you are importing one of the following types of corporate document: Web Intelligence BusinessObjects Analytics (performance management) Third-party 278 BusinessObjects 6.x to XI Release 2 Migration Guide

279 Using the Import Wizard Importing specific objects 15 then the Domains and Documents dialog box appears. The list contains a separate branch for each domain. Domains that cannot be opened are dimmed. If you previously chose to import all the objects of a given category, they are preselected and cannot be cleared from the list. To select domains and documents 1. Select the domains and individual documents you want to import. When you select a domain, all the documents within it are highlighted. 2. Click Next. Universe and connection objects If you chose to import universes in the Select Objects to Import dialog box, the Import Options for Universes and Connections dialog box appears. (If you did not, go to Universe domains and universes on page 280.) To import universe and connection objects 1. Select an import option: Import all universes and all connection objects This imports all universes from the source environment in one batch. You cannot select individual universes or connections. Import all universes, and only connection objects used by these universes Import universes and connections that the selected Web Intelligence and BusinessObjects documents use directly In a later dialog box, you will be able to select additional universes to import. 2. If you want to migrate universe overloads, select the Keep universe overloads for imported users and groups check box. If you do not select this, then no universe overloads will be migrated. Universe overloads are imported only for users and groups that are imported into the CMS. 3. Click Next. BusinessObjects 6.x to XI Release 2 Migration Guide 279

280 15 Using the Import Wizard Finalizing the import Universe domains and universes If you chose to import universes and connections that are linked to specific documents (see Universes and universe connections on page 92), the Universe Folders and Universes dialog box appears. To select universes 1. Select the universes you want to import. The universes that are linked to specific documents cannot be cleared from the list. You can select additional universes that are not used by any imported document. 2. Click Next. Locales and platform options In the Locales and Platform Options dialog box, you set the default locales for 2.x/5.x Web Intelligence and BusinessObjects documents. These are the locale used in the documents and the locale of the platform where the documents were created. To set the locales 1. From the lists, select the default locale (language) of the documents and the platform. In a version 6.x repository, some Web Intelligence 2.x (.wqy) documents and BusinessObjects documents may not store their locales. In order to set locales in these documents when they are saved in the CMS (after conversion to.wid), the default locales provided by the user are added to the documents. 2. Click Next. Finalizing the import When the Import Wizard completes its collection of information, the Ready to Import dialog box appears. This procedure may take some time, because a large quantity of data is being retrieved. To finalize the import 1. Click Finish. 280 BusinessObjects 6.x to XI Release 2 Migration Guide

281 Using the Import Wizard If you re migrating Application Foundation 15 The Import Progress dialog box appears. It shows: the progress of the import a summary of the events taking place When the import is complete, the Import Completed dialog box appears. It displays the results of the import. 2. To see more information about the events, click View Detail Log, and then see Checking the Import Wizard log file on page Click Quit to quit the Import Wizard. The import is now complete. If you re migrating Application Foundation If you are importing Application Foundation objects, follow the procedures below. This section covers all the procedures in the Import Wizard. To migrate Application Foundation objects to Performance Management 1. In the Source Environment dialog box, select the source environment (6.1.b, and 6.5 are supported for migration to Performance Management XI R2). You are prompted for administrative account information. The fields that appear depend on the type of source environment you selected. 2. Type a user name and password that give you administrative rights to the source environment. Note: You must have a General Supervisor profile in the repository. 3. In the Domain Key File field, type or browse for the path to the.key file of the source environment. 4. Select the Import Application Foundation Contents check box and click Next. The Import Wizard verifies the connection to the repository, the credentials, the validity of the General Supervisor login, and the repository version. 5. In the Dashboard files section of the Application Foundation source screen, browse to the location of the Application Foundation storage folder. By default, it is $INSTALLDIR/Application Foundation/server/conf. 6. In the Application Foundation source repository section, indicate the repository s details using one of the following methods: BusinessObjects 6.x to XI Release 2 Migration Guide 281

282 15 Using the Import Wizard If you re migrating Application Foundation check the Use conf file option This option allows you to specify the location of the AF configuration file that contains the repository database information rather than entering it manually. It is highly recommended that you upgrade a copy of the source repository, and that you point the connection to the copy when you upgrade the repository. manually enter the following repository database information: name of the source repository database engine network layer of the source repository a user name and password to access the database Note: The user name and password you type must belong to an Administrator profile. It is highly recommended that you upgrade a copy of the source repository, and that you point the connection to the copy when you upgrade the repository. 7. Click Next. The Application Foundation Repository Update dialog box appears. 8. Select one of the following options: Yes to update the repository in the Import Wizard No to skip the repository update and migrate the repository later Note: If you want to perform the migration in several steps, the Application Foundation repository must be updated at the end of the migration process. You can only update the repository once. If you are migrating rules and schedules, you must migrate them in the same Import Wizard session as the repository update. 9. Click Next. If you chose not to upgrade the repository, a dialog box listing the objects you can import appears. Click Next to continue. If you chose to upgrade the repository, a warning message appears. You must acknowledge that you have read the warning by checking the I understand. I want to continue. box to proceed with the repository upgrade. 10. In the Destination Environment dialog box, indicate the name of the destination CMS into which you want to import migrated objects. 282 BusinessObjects 6.x to XI Release 2 Migration Guide

283 Using the Import Wizard Selecting the types of objects to import Type a user name and password that give you Administrator rights to the destination environment, and click Next. The Import Wizard verifies the login at the CMS. A warning appears that summarizes the items that can be imported. 12. Read the warning, and then click Next. Selecting the types of objects to import In this stage of the import process, you select the types of objects you want to import. At a later stage, you will select the objects themselves. To select the types of objects to import 1. In the Select Objects to Import dialog box, select the types of objects you want to import. The Application Foundation objects available in this dialog box are: Universes and documents referenced by analytics you are importing Analytics (*.afd) Rules and schedules (this option is only available if you selected Yes for the Application Foundation repository upgrade) Named events (this option is only available if you selected Yes for the Application Foundation repository upgrade) Dashboards (corporate and personal) Standard Application Foundation security Note: The Import Broadcast Agent Schedulers check box is dimmed and cannot be selected if there are no Broadcast Agents and no jobs to import in the repository. 2. Click Next. Security Migration Options If you selected Import users and user groups in the Select Objects to Import dialog box, the Security Migration Options dialog box appears. (If you did not select it, go to Personal and inbox documents on page 272.) The Security Migration Options dialog box allows you to select the way you want to migrate security and whether you want to migrate security at all. There are three options: BusinessObjects 6.x to XI Release 2 Migration Guide 283

284 15 Using the Import Wizard Selecting the types of objects to import Yes, migrate security on imported objects and secure the destination system This is the most secure option. Yes, migrate security on imported objects Users in the destination system may end up with more rights than in the source system. No, don t migrate security Select this option only if you are rebuilding security in XI R2. Note: Universe overloads are not included in the Security migration. You select overload migration in Universe and connection objects on page 279. To select a security migration option 1. In the Security Migration Options dialog box, select one of the three options. 2. Click Next. Personal and inbox documents If, in the Select Objects to Import dialog box, you selected the import of objects stored either in inbox or personal folders, the Personal Documents and Inbox Documents dialog box appears. (If you did not select it, go to Selecting an import scenario on page 274.) For more information on how Personal and Inbox documents are migrated, see Personal documents on page 86 and Inbox documents on page 85. To import personal and/or inbox documents 1. If you want to import unread Inbox documents (of imported users), select the check box. These unread Inbox documents are stored in the repository. 2. If you want to import read Inbox documents (of imported users), select the check box and type or browse for the path in the source environment. If the folders are located on a remote or UNIX server, you must have mapped them to local drives. 3. If you want to limit the import of Inbox documents to those sent after a certain date: Select the Import Inbox documents sent after check box Select the date from the lists 284 BusinessObjects 6.x to XI Release 2 Migration Guide

285 Using the Import Wizard Selecting an import scenario Type or browse for the path of your Personal documents in the source environment. If the folders are located on a remote or UNIX server, you must have mapped them to local drives. 5. If you want to limit the import of Personal documents to those created or modified after a certain date: Select the Import Personal documents that have been modified or created since check box Select the date from the lists 6. Click Next. The Import Scenario dialog box appears. Selecting an import scenario You can merge the source and destination environments, or you can update the destination environment without merging: Merging the environments The Import Wizard adds all objects from the source to the destination CMS without overwriting objects in the destination environment. This is the safest import option. All of the objects in the destination environment are preserved. Updating the destination environment All objects in the source are added to the destination CMS, but if a source object has the same unique identifier as an object in the destination environment, the destination object is updated. For more information, see The Merge and Update import scenarios on page 173. To select an import scenario 1. In the Import Scenario dialog box, select the type of import you want. To merge the source and destination environments, select I want to merge the source system into the destination system. If you want to automatically rename top-level folders that match toplevel folders on the destination system, select the check box. BusinessObjects 6.x to XI Release 2 Migration Guide 285

286 15 Using the Import Wizard Selecting an import scenario To update the destination environment without merging, select I want to update the destination system by using the source system as a reference. If you want to automatically rename objects when an object with the same title already exists in the destination folder, select the check box. 2. Click Next. If you selected the Update option in the previous step, the Incremental Import dialog box appears. Go to Updating previously imported objects on page 275. If you selected the Merge option, you are prompted to select specific objects for import. See the section below for instructions regarding that object type. Updating previously imported objects You may need to import some objects more than once from the source repository to the destination repository. In this situation, you have the following update options: Overwrite object contents You select the types of objects for which the content overwrite applies: Dashboards, Analytics, and Documents Universes Connections When you reimport an object, it will completely overwrite and replace the object (and its associated files) that you imported earlier. Overwrite object rights When you reimport an object, its associated security rights will overwrite the rights of the object you imported earlier. If you decided not to import security in the Security Migration Options dialog box, then the Overwrite object rights option is not relevant, and is therefore not available. If you don t select any overwrite options, the object in the destination repository will not change when you try to import it again. 286 BusinessObjects 6.x to XI Release 2 Migration Guide

287 Using the Import Wizard Importing specific objects 15 To update previously imported objects 1. In the Incremental Import dialog box, select the type of objects whose content you want to overwrite: Dashboards, Analytics, and Documents Universes Connections 2. If you want to overwrite object rights, select the Overwrite object rights check box. 3. Click Next. Depending on the type of objects that you selected for import, you are prompted to select specific objects. Go to the section below for instructions regarding that object type. If the Ready to Import dialog box appears, go to Finalizing the import on page 280. Importing specific objects If you are importing users, groups, domains, Web Intelligence documents, BusinessObjects documents, categories, universes, folders, repository objects, or Broadcast Agents, you are now prompted to select the specific objects you want to import. You can import all of the objects or select individual ones. It may take some time before objects are displayed, because the Import Wizard is retrieving them from the repository. LDAP/AD options If your source repository is 6.x and if an LDAP configuration is found in the 6.x system, the LDAP/AD Options dialog box is displayed. (See Migrating external groups (LDAP/Active Directory) on page 77.) You are notified that you need to have the same LDAP or Active Directory configuration on both the source and destination environments. To select LDAP/AD options 1. Read the notice on the LDAP/AD Options dialog box, and take action if necessary. 2. Click Next. The LDAP/AD group mapping and external users page appears. BusinessObjects 6.x to XI Release 2 Migration Guide 287

288 15 Using the Import Wizard Importing specific objects Users and groups 3. If you want to import LDAP or Active Directory group mappings, select the appropriate check box. 4. If you want to import external users, select the Import external users check box. 5. Click Next. If you have chosen to import external users, then mapped LDAP/AD users will be displayed in the list of users to import (see Users and groups on page 277). You will be able to choose the ones to import. If you are importing users and groups, the Users and Groups dialog box appears. For detailed information on the import of users and groups, see Understanding user and group migration on page 65. To select users and groups 1. In the Groups list, select the groups you want to import. 2. In the Subgroups and Users list, select specific members of any group. For performance reasons, external users are listed at the root level in the user/group tree. All external users are part of the External group. The actual group association for the selected users takes place only after you click the Finish button. 3. If you want groups containing users you select to be imported automatically, select the Select groups that contain selected users check box. 4. Click Next. Populating database credentials After users and groups are imported, the Populate Database Credentials for Users dialog box appears. This dialog box enables you to automatically set the DBUSER and DBPASS attributes, for all imported users, with their login and password. These can be used as default database credentials for connections (see BOUSER/ BOPASS on page 94). 288 BusinessObjects 6.x to XI Release 2 Migration Guide

289 Using the Import Wizard Importing specific objects 15 To populate database credentials 1. Do either of the following: If you want to populate the database credentials of imported users with their BusinessObjects user name and password, select Yes. If you do not want to do this, select No. 2. Click Next. Broadcast Agent Categories If you are importing Broadcast Agents, the Broadcast Agents dialog box appears. This dialog box enables you to select the Broadcast Agents you want to import. Under each domain in the tree, jobs are organized into two major folders: Corporate domain schedules Inbox schedules Note: A Broadcast Agent job can be migrated from BusinessObjects Enterprise 6.x to XI R2 only if the job is supported in XI R2. (For details, see Broadcast Agent Scheduler on page 87.) To select Broadcast Agents for import 1. In the Broadcast Agent dialog box, select the jobs you want to import. Note that all the jobs, for each selected Broadcast Agent, are selected by default. 2. Click Next. If you are importing categories, the Categories dialog box appears. To select categories 1. Select the categories you want to import. For large document domains, you can import incrementally, and import documents one category at a time. 2. If you want to import all the objects associated with the category, select the Import all objects that belong to the selected categories check box. 3. Click Next. BusinessObjects 6.x to XI Release 2 Migration Guide 289

290 15 Using the Import Wizard Importing specific objects Dashboards If you are importing Application Foundation content and have chosen to import dashboard objects, the Dashboards dialog box appears. To select dashboards 1. Select the dashboards you want to import. When you select an application, its submenus are also selected. 2. Click Next. The Import Wizard checks whether any dashboards in the source repository include security. If the Import Wizard detects security on any dashboards, the Import Dashboard Option dialog box appears. If none of the dashboards selected for import includes security, skip to step If dashboards selected for import include security, select one of the following options: Import and apply page security on all page elements The Import Wizard migrates the dashboard and any sub-menus and applies standard page-level security, which is translated as an ACL in the CMS. With this option, the least restrictive set of rights is applied. Don t import such dashboards The Import Wizard imports all dashboards, including dashboards with analytic-level security restrictions, but empties all content from pages containing secured elements. Dashboard menu structures are preserved. Import but move to administrator s Favorites folder for revision The Import Wizard imports all dashboards, including secured dashboards, but empties the content of all secured dashboards. When you choose this option, dashboard menu structures are preserved and a copy of each secured dashboard, including its contents, is moved to the administrator s favorite folder. A prefix is added to the secured dashboard s name so that the administrator can easily identify it after migration, then modify it manually before publishing it to a wider audience. 290 BusinessObjects 6.x to XI Release 2 Migration Guide

291 Using the Import Wizard Importing specific objects 15 Document domains and documents If you are importing one of the following types of corporate document: Web Intelligence BusinessObjects Analytics (performance management) Third-party then the Domains and Documents dialog box appears. The list contains a separate branch for each domain. Domains that cannot be opened are dimmed. If you previously chose to import all the objects of a given category, they are preselected and cannot be cleared from the list. To select domains and documents 1. Select the domains and individual documents you want to import. When you select a domain, all the documents within it are highlighted. 2. Click Next. Universe and connection objects If you chose to import universes in the Select Objects to Import dialog box, the Import Options for Universes and Connections dialog box appears. (If you did not, go to Universe domains and universes on page 280.) To import universe and connection objects 1. Select an import option: Import all universes and all connection objects This imports all universes from the source environment in one batch. You cannot select individual universes or connections. Import all universes, and only connection objects used by those universes Import universes and connections that the selected Web Intelligence and BusinessObjects and Application Foundation documents use directly In a later dialog box, you will be able to select additional universes to import. BusinessObjects 6.x to XI Release 2 Migration Guide 291

292 15 Using the Import Wizard Importing specific objects 2. If you want to migrate universe overloads, select the Keep universe overloads for imported users and groups check box. If you do not select this, then no universe overloads will be migrated. Universe overloads are imported only for users and groups that are imported into the CMS. 3. Click Next. Universe domains and universes If you are importing universes and connections that are linked to specific documents, the Universe Folders and Universes dialog box appears. To select universes 1. Select the universes you want to import. The universes that are linked to specific documents cannot be cleared from the list. You can select additional universes that are not used by any imported document. 2. Click Next. The Import Wizard checks that universe IDs and names are consistent between the Application Foundation repository and BusinessObjects repository, and that the two repositories are of the same version. If the Import Wizard detects inconsistencies in universe names/ids or repository versions, universes selected for import (or imported by default because they are referenced by other objects selected for import) a warning is displayed and you are prompted to resolve the inconsistencies before migrating. See Best Practices for Migrating to BusinessObjects Performance Management XI R2 for more information on resolving universe inconsistencies. If the universe is not found, the associated documents will not be imported and a warning message appears. If this occurs, link the documents to a universe, republish them to the repository, and retry the import. Locales and platform options In the Locales and Platform Options dialog box, you set the default locales for 2.x/5.x WebIntelligence and BusinessObjects documents. These are the locale used in the documents and the locale of the platform where the documents were created. 292 BusinessObjects 6.x to XI Release 2 Migration Guide

293 Using the Import Wizard Finalizing the import 15 To set the locales 1. From the lists, select the default locale (language) of the documents and the platform. In a version 6.x repository, some WebIntelligence 2.x (.wqy) documents and BusinessObjects documents may not store their locales. In order to set locales in these documents when they are saved in the CMS (after conversion to.wid), the default locales provided by the user are added to the documents. 2. Click Next. Finalizing the import When the Import Wizard completes its collection of information, the Ready to Import dialog box appears. This procedure may take some time, because a large quantity of data is being retrieved. To finalize the import 1. Click Finish. The Import Progress dialog box appears. It shows: the progress of the import a summary of the events taking place When the import is complete, the Import Completed dialog box appears. It displays the results of the import. 2. To see more information about the events, click View Detail Log, and then see Checking the Import Wizard log file on page Click Quit to quit the Import Wizard. The import is now complete. BusinessObjects 6.x to XI Release 2 Migration Guide 293

294 15 Using the Import Wizard Finalizing the import 294 BusinessObjects 6.x to XI Release 2 Migration Guide

295 Verifying and completing the new environment part

296

297 BusinessObjects 6.x to XI Release 2 Migration Guide Checking and adapting the new environment chapter

298 16 Checking and adapting the new environment Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Assessment and planning 2. Preparing for import 3. Importing from the source to destination environment 4. Post-import checking and tuning Verifying overall import success Checking user/group and object import Checking imported documents Checking universe access restrictions Checking and adjusting security Recreating scheduling jobs Overview Now that you have finished using the Import Wizard, you need to: verify that objects have been properly imported verify the functioning of the objects in the destination environment perform final adjustments Verifying overall import success The sections below explain how to verify that your import was successful. Checking the Import Wizard log file During the import, a log file is generated by the Import Wizard. For each item, the log contains a system-generated ID number, a description of the imported information, and an explanation of any action taken by the system. 298 BusinessObjects 6.x to XI Release 2 Migration Guide

299 Checking and adapting the new environment Verifying overall import success 16 The log stores events that occurred during the import, as well as options selected before starting the import. You can access the log via the Import Progress dialog box, or by opening the log file from the installation directory. A separate log event is generated for each Broadcast Agent document that cannot be migrated because the job is not supported in XI R2. From the Import Progress dialog box The Import Progress dialog box appears at the end of the importing process (see Finalizing the import on page 280). To access the log file via the Import Progress dialog box 1. In the Import Progress dialog box, click View Detail Log. The Detail Log dialog box appears. This dialog box lists all the objects the Import Wizard has migrated and their status, as well as any errors that may have occurred. You can sort the entries according to any column, by clicking the column s heading. 2. For more details on a given item, select it from the list. The details are displayed at the bottom of the dialog box. 3. When you have finished reviewing the log, click OK. From the installation directory To open the log file from the installation directory 1. In the XI R2 installation directory, go to \...\win32x86\ The default location is: C:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\win32x86\ 2. Open the ImportWiz.log file. BusinessObjects 6.x to XI Release 2 Migration Guide 299

300 16 Checking and adapting the new environment Verifying overall import success Checking the import via the CMC The CMC can display the total user count at the top of the user area. It can also show the total number of objects, as well as information about the objects. You can review the list of users in the CMS and check whether 6.x users and groups have been correctly created. If you are migrating security, then you can also check that rights and assignments are correctly set. 300 BusinessObjects 6.x to XI Release 2 Migration Guide

301 Checking and adapting the new environment Checking user/group and object import 16 Checking the import using Query Builder Query Builder is a tool that allows you to type SQL-like expressions to run queries such as: show me the user count show me all objects of type rep, wid, wqy To start Query Builder from the Administration Launchpad, click Administrative Tools > Query Builder. Checking user/group and object import To check whether users/groups and objects were imported, you can also: Log into the products Try to log into the various XI R2 products using a migrated user login. Log into InfoView and check whether the documents that should be visible in the portal, are actually visible. Do the same with Web Intelligence and Desktop Intelligence. Checking imported documents Most imported documents undergo some updating during the import. You should verify to what extent this has changed the documents. Desktop Intelligence calculations In recent years, Business Objects has made a number of improvements to the BusinessObjects/Desktop Intelligence calculation engine (the part of the software that calculates report values). As a result, the same report might sometimes return different values in certain circumstances, depending on the calculation engine version. Checking for calculation updates on page 309 describes the calculation engine changes in detail. It helps you identify reports that might return different values under Desktop Intelligence, explains why these values are different and how to modify your reports to return the former values. Because there is more than one group of calculation engine changes, the precise impact on your reports depends on their original version. BusinessObjects document migration on page 310 describes these groups of changes in detail. BusinessObjects 6.x to XI Release 2 Migration Guide 301

302 16 Checking and adapting the new environment Checking imported documents Impact of migrating to a Unicode database Unicode font sizes are different than their non-unicode equivalents. Therefore, if you have migrated BusinessObjects documents to Desktop Intelligence, and have also migrated your 6.x data sources to a Unicode database, you may encounter the following: Documents are not pixel-per-pixel identical. When a cell isn t big enough to display all its contents, it uses ### to indicate that the contents have been truncated. Because the Unicode fonts are sometimes bigger than their non-unicode equivalents, you may see ### in cells where previously you saw data. The size of documents may be affected. Functions like NumberOfPages() may return different values in the case of Autofit cells. For changes in the calculation engine, see Checking for calculation updates on page 309. Note: The move to Unicode has no impact on sorts. Web Intelligence documents Locale In some Web Intelligence 2.x versions, locale was not stored in the.wqy file. Normally, during the import, if no locale is found in the.wqy file, the Import Wizard prompts you for a locale. it is recommended that you check the locale of converted Web Intelligence documents, to make sure it has been correctly migrated. Customizing formatting When WebIntelligence 2.x documents are converted from.wqy to.wid, there may be slight changes in formatting. You can readjust certain formatting by modifying the wqyconversionsettings.xml file, which is located in: $INSTALLDIR\BusinessObjects Enterprise 11.5\win32_x86\wqyConversionSettings.xml 302 BusinessObjects 6.x to XI Release 2 Migration Guide

303 Checking and adapting the new environment Checking imported documents 16 Below are the lines of the XML file to modify for each type of formatting (default settings are shown). Formatting element Avoid page break in section Cell minimum width and height Font size for page or report headers Font size for section variables Font size for table header, footer, or body text Parameter to force Read as HTML to become web link Section cells (Repeat on each new page) Vertical table (repeat header on every page) Lines to modify <OPTION NAME= avoid_page_break_in_section VALUE= auto /> <OPTION NAME="cell_min_width" VALUE="8"/> <OPTION NAME="cell_min_height" VALUE="6"/> <SIZE NAME="page_header" VALUE="auto" /> <SIZE NAME="report_title" VALUE="auto" /> <SIZE NAME="section_cell" VALUE="auto" /> <SIZE NAME="table" VALUE="auto" /> <SIZE NAME="table_header" VALUE="auto" /> <SIZE NAME="table_footer" VALUE="auto" /> <OPTION NAME= html_is_weblink VALUE= auto /> <OPTION NAME= add_section_on_everypage VALUE= auto /> <OPTION NAME= add_header_on_everypage VALUE= auto /> Wraptext option for page <OPTION header/footer, report NAME= wraptext_for_freecell_and_he ader VALUE= false /> header and section header Re-establishing document-to-document links After the import, if you have integrated document-to-document links using opendoc in BusinessObjects or Web Intelligence documents, you need to manually re-establish those links in Desktop Intelligence and Web Intelligence. (Links based on OpenAnalytic, however, are migrated.) BusinessObjects 6.x to XI Release 2 Migration Guide 303

304 16 Checking and adapting the new environment Checking universe access restrictions Troubleshooting documents that have not been correctly migrated If during import some documents have not been correctly migrated, you may get error messages in the Import Wizard log file such as: Failed to get contents for BusinessObjects documents wqyreader::open failed for Web Intelligence documents If this occurs, make sure that the documents are not corrupted in the source repository. If they are corrupted, they can t be imported. Also make sure that temporary disk space has not been completely used up by the Import Wizard temporary files. Update any VBA macros. Some macros may no longer work because the platform-related part of the BOSDK object model has been updated. Documents containing OLAP data providers are migrated by the Import Wizard, but these data providers can no longer be refreshed. Therefore, the documents must be rebuilt. Checking universe access restrictions It is recommended that you look at universe overloads (access restrictions) in Designer XI R2 to see what group ordering has been defined by the Import Wizard for particular universes. You can then fine-tune the ordering if necessary. Checking and adjusting security If you have imported security, you may need to adjust security for users after migration. Everyone user group rights When you migrate to XI R2, all existing users become members of the Everyone user group. This means that your users may acquire access rights they did not have previously. Or, they may be denied rights they had before the migration. 304 BusinessObjects 6.x to XI Release 2 Migration Guide

305 Checking and adapting the new environment Checking and adjusting security 16 The new access rights depend on which of the following three options you selected in the Security Migration Options dialog box of the Import Wizard. Security migration option Yes, migrate security on imported objects and secure the destination system Yes, migrate security on imported objects No, don't migrate security Impact Being the most secure option, this denies access to all objects and applications for the Everyone group. You must manually allow the access you want. This is a less secure option, so the settings for the Everyone group are not modified. You may need to manually restrict access. No security is migrated. The migrated system is completely open and all users have access to all resources. You should only use this option if you are rebuilding security from the ground up. No matter which option you selected, it is recommended that you make sure the Everyone group gives or denies only the rights you want for your users. Check the rights given or denied to Everyone for: BusinessObjects Enterprise applications; for example, InfoView folders Remember that when users have access to a folder, they have access to the contents of the folder unless explicitly denied. documents universes connections For detailed information and instructions on setting user rights and access to applications, see the BusinessObjects Enterprise XI Release 2 Administrator s Guide. For example, to check and adjust the rights for InfoView 1. Log into the CMC. 2. Select BusinessObjects Enterprise Applications > InfoView. 3. Click the Rights tab. 4. Adjust the rights to InfoView for the Everyone group. BusinessObjects 6.x to XI Release 2 Migration Guide 305

306 16 Checking and adapting the new environment Recreating scheduling jobs If you have not imported security You need to recreate security for your XI R2 environment. For guidelines, see Chapter 12: Recreating security in XI R2. Recreating scheduling jobs A Broadcast Agent job can be migrated from BusinessObjects Enterprise 6.x to XI R2 only if the scheduler associated to the jobs is supported in XI R2. If a job contains non-supported elements or features, you must drop the feature or recreate it in the 5.x/6.x system so that it is consistent with the XI R2 platform. Schedules that are not supported in XI R2 are copied to special folders. For complete information, see How scheduled documents are migrated on page 88. As you recreate non-supported jobs manually, take into account that all XI R2 jobs include a refresh and a single output. To output a report to multiple formats (such as PDF and XLS), you must create multiple jobs. Non-supported jobs In XI R2, the first action for scheduled documents is always a refresh. Therefore, a job can be imported from 6.x only if its first action is a refresh. A job cannot be imported if it has any of the following: multiple outputs conditional processing custom macros You can, however, have embedded VBA macros (those that include calls to the platform, such as Login or Logout, will need to be updated). report bursting ( refresh with the profile of each recipient ) saved in XML format In addition, the following 6.x task scheduling options (in either BusinessObjects or Web Intelligence) are not supported in XI R2: Daily Week periodicity Weekly Week periodicity 306 BusinessObjects 6.x to XI Release 2 Migration Guide

307 Checking and adapting the new environment Verifying the performance management environment 16 Monthly interval Business day Weekend day Month periodicity User-defined Weekday Business day Weekend day Note: The migrated document may be assigned a different periodicity in XI R2. Verifying the performance management environment For recommendations on checking the new performance management environment, refer to Best Practices for Migrating to BusinessObjects Performance Management XI R2. BusinessObjects 6.x to XI Release 2 Migration Guide 307

308 16 Checking and adapting the new environment Verifying the performance management environment 308 BusinessObjects 6.x to XI Release 2 Migration Guide

309 Checking for calculation updates chapter

310 17 Checking for calculation updates Where you are now Where you are now Here is an overview of the migration process, and where you should be now. The topics in blue are described in this chapter. Where you are now Step in overall migration process 1. Understanding what migration entails 2. Assessment and planning 3. Preparing for import 4. Importing from the source to destination environment 5. Post-import checking and tuning Document conversion during import BusinessObjects document migration Document conversion during import During the import to the XI R2 environment, the Import Wizard automatically converts BusinessObjects (.rep) and Web Intelligence (.wqy and.wid) documents to XI R2 format. Depending on the type and version of the document, some differences in format and even results may occur. This chapter explains those differences and how you can correct them. BusinessObjects document migration Business Objects made several adjustments to the BusinessObjects calculation engine in BusinessObjects 5.x and 6.x. The Desktop Intelligence calculation engine is based on the BusinessObjects calculation engine. Note: The calculation engine is the part of the software that calculates report results. In certain circumstances, these adjustments mean that certain versions of BusinessObjects reports can return different values when migrated to version XI R2. This section helps you identify reports that might be affected and explains the steps necessary to modify the reports. 310 BusinessObjects 6.x to XI Release 2 Migration Guide

311 Checking for calculation updates BusinessObjects document migration 17 There are two sets of calculation engine modifications: BusinessObjects modifications and BusinessObjects 6.0 modifications. These two sets of modifications are cumulative: if you migrate a report from BusinessObjects to XI R2, the migrated report contains both sets of modifications. This chapter also considers Desktop Intelligence modifications that do not, strictly speaking, affect the calculation engine. Because these modifications can affect report results in certain circumstances, it makes sense to consider them here. The following table contains a brief summary of all modifications: Document version From through Calculation issues may arise if the documents contain: Multiple cubes and global filters Multiple cubes and complex filters Incompatible objects in the same block The NoFilter() function Multiple cubes can occur either when the document contains multiple data providers, or when a single data provider contains multiple cubes. Global filters are filters that apply to an entire report. Complex filters are filters based on a formula (e.g. Country <> France ). From 6.0 through 6.5 Blocks with objects from different data providers and the Count() function to count the rows in the blocks Filters that apply to objects that contain empty values Master/detail reports with incompatible objects in the section header and body and filters applied to the header Rankings in blocks that contain empty values and objects from different data providers The NoFilter() function used with a Where clause Blocks with the Avoid Duplicate Rows Aggregation setting activated Desktop Intelligence The UniverseName() function Unicode fonts Decimal precision BusinessObjects 6.x to XI Release 2 Migration Guide 311

312 17 Checking for calculation updates BusinessObjects document migration BusinessObjects modifications BusinessObjects modifications affect: global filters complex filters incompatible objects in the same block aggregation levels in synchronized data providers Do you need to read this section? You could be affected by these modifications if you have BusinessObjects reports that contain the following: multiple data providers or a single data provider with multiple cubes, and global filters multiple data providers or a single data provider with multiple cubes, and complex filters incompatible objects in the same block Global filters Global filters are filters that apply to an entire report tab, as opposed to block filters, which apply to specific blocks only. Global filters behave differently in BusinessObjects and Are your reports affected? If your reports contain global filters and multiple cubes, whether from single or multiple data providers, your reports are affected by the change in global filters behavior. Global filters behavior in BusinessObjects In this example a report has three data providers containing several linked objects: Data Provider 1: Country, Resort, Service, Service Line, Revenue Data Provider 2: Country, Resort, Service, Service Line, Revenue Data Provider 1: Country, Resort, City The City object in Data Provider 3 is not linked to the other data providers, but Country and Resort in Data Provider 3 are both linked to Country and Resort of Data Provider 1 and 2. There is a global filter defined on City with a condition that is not met: City = test. BusinessObjects creates a report with one table per data provider. 312 BusinessObjects 6.x to XI Release 2 Migration Guide

313 Checking for calculation updates BusinessObjects document migration 17 The first table is based on Data Provider 1, the second on Data Provider 2 and the third on Data Provider 3. The filter impacts the table based on Data Provider 3 only: the table has no data because no row matches the filter criterion. Global filters behavior in BusinessObjects BusinessObjects behavior is modified to account for indirect filters. In the example, indirect filtering means that all tables do not now show any data because BusinessObjects indirectly applies the filter on table 3 to the other two tables. It does this because the other tables are linked to the table containing the object referenced in the filter. This mechanism is similar to an equi-join in a RDBMS, where the rows returned from all joined tables are determined by a WHERE restriction on any individual table. Obtaining BusinessObjects results in BusinessObjects You can recreate BusinessObjects behavior in two ways: by moving the filter to the block level, or by desynchronizing the queries. Moving the filter to the block level In the example, you can ensure that all tables are not filtered by applying the filter City= test to table 3 only. Note that this solution works only if the filtered block contains the object referenced in the filter. If the block does not contain the City object, you cannot apply the filter to it. Desynchronizing the data providers The other solution is to desynchronize the data providers. By removing the links between them, you ensure that BusinessObjects will not apply the filter indirectly to other data providers. Indirect filters and calculations The new indirect filters behavior has implications for calculations. In this example, you have two data providers: Data Provider 1: Country, Resort, Revenue Data Provider 2: Country, Future Guests BusinessObjects 6.x to XI Release 2 Migration Guide 313

314 17 Checking for calculation updates BusinessObjects document migration You have a report with three blocks. The third block contains the objects Country (from Data Provider 1), Resort, Revenue and Future Guests. If you add a sum on the Revenue and Future Guest columns in the third block and a complex filter, Resort= Bahamas Beach, on the Resort object, you get the following result: Country (DP1) Resort Revenue Future Guests US Bahamas Beach $971, Sum: 102 The Sum for Future Guests is wrong in BusinessObjects because the indirect filters behavior is not implemented. In this case, the filter on the first data provider is not applied indirectly to the second data provider, with the result that the Future Guests figure is counted twice. In BusinessObjects , the sum is correct. Note: if you add a sum to the Future Guests column before applying the complex filter, BusinessObjects still gives the figure 102, even though the column contains three figures: 46, 56 and 56. For an explanation of this, see Aggregation levels in synchronized data providers on page 320. BusinessObjects calculates the correct sum as follows: filter on the first data provider to get a list of rows that need to be preserved. join this set of rows with the second data provider on the data providers linked dimensions. This join returns a row only if there is a row in each data provider. In the example: filter on Resort in the first data provider to return one row (US, Bahamas Beach). join to the second data provider to return one row and the correct value for Future Guests. Complex filters Complex filters are filters that are based on a formula, for example: Country <> France Are your reports affected? If your reports contain complex filters and multiple cubes, whether from single or multiple data providers, your reports are affected by the change in complex filters behavior. 314 BusinessObjects 6.x to XI Release 2 Migration Guide

315 Checking for calculation updates BusinessObjects document migration 17 Complex filters in BusinessObjects The complex filter algorithm in BusinessObjects produced errors in certain situations involving linked data providers. This had the following symptoms: Incorrect display of lists of values Different behavior when filtering empty values Lists of values in BusinessObjects The following example looks at a list of values associated with a filter. Here are the details of the report: Data Provider 1: Country, Quarter, Year, Revenue Data Provider 2: Country, Number of Guests The two data providers are synchronized on Country. A variable called Test whose formula references objects in both data. A complex filter with the formula Test<> FRA. When you view the list of values related to the Test variable, all values not equal to FRA should be selected, but this is not always the case. When you open the report with BusinessObjects , all values are selected. Note: BusinessObjects and give the same results with simple filters. Empty values in BusinessObjects The complex filters fix has implications for filtering on empty values. Before the fix, this filtering occurred automatically. Now there is no automatic filter on empty values in a multi-data provider report. The following example illustrates this. You have a simple report as follows: Data Provider 1: Country, Revenue Data Provider 2: Country, Revenue The second data provider has a query condition that restricts Country to US. This is the report display: Country(DP1) Revenue(DP1) France $835,420 US $2,451,104 BusinessObjects 6.x to XI Release 2 Migration Guide 315

316 17 Checking for calculation updates BusinessObjects document migration Country)DP2) Revenue(DP2) US $2,451,104 Country(DP1) Revenue(DP2) France US $2,451,104 If you add a complex filter on Revenue on the third table, <Revenue(DP2)> <> , BusinessObjects takes the empty value into consideration and the third table with synchronized data providers contains one row: Country(DP1) France Revenue(DP2) Empty values in BusinessObjects In the above example, BusinessObjects does not display any results in the third table because the filter does not account for the empty revenue value. Obtaining BusinessObjects results in BusinessObjects You make BusinessObjects behave like BusinessObjects by forcing it to account for empty values. To force BusinessObjects, you incorporate an object from the first data provider into the filter definition. If you change the filter definition in the above example to (<Revenue(DP2)> <> ) And (<Country(DP1)> = <Country(DP1)>) the result is the same as the BusinessObjects result. By including an object, Country(Q1), from the first data provider, you force BusinessObjects to take the empty value into account. Incompatible objects BusinessObjects contains changes that can affect reports containing incompatible objects under certain circumstances. Incompatible objects are objects that belong to different contexts in a universe. BusinessObjects universe designers often use contexts to resolve loops in database structures. If a query references incompatible objects, it cannot be expressed as a single SQL query; BusinessObjects therefore builds multiple data cubes and synchronizes them. 316 BusinessObjects 6.x to XI Release 2 Migration Guide

317 Checking for calculation updates BusinessObjects document migration 17 Determining if your reports are affected If your reports have incompatible objects that appear in the same block, they are affected by the change in incompatible objects behavior. You can quickly tell if a report is affected. Open the Data Manager dialog box by selecting Data > View Data on the menu. The Data Manager shows the data cube or cubes that BusinessObjects uses internally to build the report, and the objects within each cube. Each cube is populated from one SQL query; if there is more than one cube, the report contains multiple queries. If the report has more than one cube or SQL query, check whether objects from different cubes (incompatible objects) appear in the same block of data. If you have reports that satisfy these conditions, they are affected by the incompatible objects fix in BusinessObjects You can further see why these objects are incompatible by examining the Island Resorts Marketing universe, which has two contexts. The Reservation Year object (derived from reservations.res_date) and the Revenue object (derived from sales.invoice_date) each belong to a different context: Incompatible objects in BusinessObjects A report contains the Country, Year, Reservation Year, Revenue and Future Guests objects. Because Reservation Year and Revenue come from different contexts, BusinessObjects needs to perform two steps: Sum Future Guests by Country by Reservation Year Sum Revenue by Country by Year To do this BusinessObjects generates two SQL statements and builds the following cubes: Cube 1: Country, Year, Revenue Cube 2: Country, Reservation Year, Future Guests You can examine the underlying cube structure of a report using the Data Manager dialog box. The Data Providers pane on the left shows the cubes used in the report. You can also examine the SQL generated by BusinessObjects in the SQL Viewer dialog box that you access from the Query Panel: BusinessObjects 6.x to XI Release 2 Migration Guide 317

318 17 Checking for calculation updates BusinessObjects document migration Internal handling of multiple cubes When processing a report that contains multiple cubes, BusinessObjects fuses all cubes into a single cube. For the above example, this cube is as follows: Country Year Reservation Year Future Guests Revenue France FY93 FY96 17 $295,940 France FY94 FY97 15 $280,310 France FY95 FY98 14 $259,170 US FY93 FY96 48 $767,614 US FY94 FY97 8 $826,930 US FY95 <empty> <empty> $856,560 There is no true relationship between the Year and Reservation Year objects in this cube. The cube contains two different kinds of information, based around the incompatible objects: Revenue by Country by Year Future Guests by Country by Reservation Year This information is synchronized around the one common dimension Country, but the relationship between Year and Reservation Year for any row is arbitrary. Incompatible objects and filters A problem arises if you apply a filter on, for example, the Reservation Year column and exclude Year from the report. If you restrict Reservation Year to FY96 only, the cube produces the following data: Country Reservation Year Future Guests Revenue France FY96 17 $295,940 US FY96 48 $767,614 In this situation the Revenue column clearly displays incorrect data. It shows the revenues for France and US for FY93. But because Year, the second object around which Revenue is aggregated, does not appear in the report, it should show the total revenues for France and US respectively, irrespective of year. (That is, by Country - the other object on which Revenue is aggregated.). 318 BusinessObjects 6.x to XI Release 2 Migration Guide

319 Checking for calculation updates BusinessObjects document migration 17 In other words, the aggregation of revenue by country is unrelated to Reservation Year. Cube filtering Cubes are filtered either internally by BusinessObjects or when a user applies a filter. When BusinessObjects is working with cubes behind the scenes, or when the user drills on a report, BusinessObjects sometimes applies internal filters. The NoFilter() function BusinessObjects has a function called NoFilter(). When you use this function, BusinessObjects ignores any user-defined filters when performing calculations. In BusinessObjects NoFilter() could cause BusinessObjects to ignore internal filters (filters applied by BusinessObjects when processing cubes), resulting in incorrect results. Incompatible objects in BusinessObjects In BusinessObjects , user-applied filters have no effect on unrelated aggregations when a block contains incompatible objects. In behind-thescenes processing, BusinessObjects ensures that filters do not affect unrelated aggregations. Furthermore, the NoFilter() function no longer causes BusinessObjects to ignore internal filters. These changes ensure that the rare occasions on which BusinessObjects could return incorrect data from blocks with incompatible objects no longer occur. Activating the fix The incompatible objects fix is not active by default in BusinessObjects You activate it by setting values in the Windows registry. Because each case of a potential incompatible objects problem is unique, you need to discuss your particular case or cases with BusinessObjects Customer Support, who will advise you which values to use for these registry settings. The MultiCube() function MultiCube() is a function that ensures that BusinessObjects takes all cubes into account when performing calculations in reports that contain synchronized queries. If you have used MultiCube() in your multi-cube reports, you should not remove it even after activating the BusinessObjects fix. You still need to use MultiCube() in BusinessObjects BusinessObjects 6.x to XI Release 2 Migration Guide 319

320 17 Checking for calculation updates BusinessObjects document migration Aggregation levels in synchronized data providers Whenever you work with synchronized data providers, you must pay close attention to the structure and semantics of your data, because certain anomalies can arise from the data structure rather than limitations in BusinessObjects. Indirect filters and calculations on page 313 gives an example of this. Remember that there are two data providers: Data Provider 1: Country, Resort, Revenue Data Provider 2: Country, Future Guests You build a block that contains dimensions and measures from both data providers: Country(DP1) Resort Revenue(DP1) France French Riviera $835,420 US Bahamas Beach $971,444 US Hawaiian Club $1,479,600 Country(DP2) Future Guests France 46 US 56 Country(DP1) Resort Revenue(DP1) Future Guests France French Riviera $835, US Bahamas Beach $971, US Hawaiian Club $1,479, Sum: 102 Count: 3 Count: 2 The Sum and Count figures for the Future Guests column are clearly anomalous. The point to note is that Future Guests is compatible with both Country and Resort, yet it is placed in the third block from a data provider that aggregates solely by Country. As a result, BusinessObjects recognizes only two values for Future Guests (which is why the sum is anomalous) and does not calculate future guests by country and resort (which is why the values for the two US resorts are anomalous). You remove this anomaly by including the Resort dimension in the data provider that contains Future Guests. BusinessObjects is then able to calculate Future Guests correctly. 320 BusinessObjects 6.x to XI Release 2 Migration Guide

321 Checking for calculation updates BusinessObjects document migration 17 In general, if you place a measure from one data provider in a block containing dimensions from another data provider that are compatible with the measure, you need to make sure that the measure data provider contains all the compatible dimensions in the block. This ensures that the measure is aggregated at the correct level in the block. BusinessObjects 6.0 modifications BusinessObjects 6.0 modifications affect: The Count() function Filtering on empty values Filters on master detail reports containing incompatible objects Rankings The NoFilter() function Duplicate row aggregation Do I need to read this section? You need to read this section if you have reports that contain any of the following: Blocks with objects from different data providers and the Count() function to count the rows in the blocks Filters that apply to objects that contain empty values Master/detail reports with incompatible objects in the section header and body and filters applied to the header Rankings in blocks that contain empty values and objects from different data providers The NoFilter() function used with a Where clause Blocks with the Avoid Duplicate Rows Aggregation setting activated The Count() function Count() is a BusinessObjects function that calculates the number of rows in a data provider. Are your reports affected? Your reports are affected if they contain multiple cubes, multiple data providers and the Count() function. Multiple cubes occur when a BusinessObjects query contains incompatible objects. As a result, BusinessObjects 6.x to XI Release 2 Migration Guide 321

322 17 Checking for calculation updates BusinessObjects document migration BusinessObjects splits the query into two or more cubes in order to resolve it. You do not control the creation of multiple cubes; BusinessObjects does this internally. Multiple data providers occur when you explicitly create more than one cube in a report, by building the report from more than one data provider. The Count() function in BusinessObjects 5.x In this example your report contains two data providers: Data Provider 1: Country, Year, Reservation Year, Number of Guests Data Provider 2: Country When you run DP1, BusinessObjects cannot resolve it with a single query because the Year and Reservation Year objects are incompatible. BusinessObjects creates two cubes: (Country, Year, Number of Guests) and (Country, Reservation Year). As a result your report has three cubes in total: DP1 Cube 1: Country, Year, Number of Guests DP1 Cube 2: Country, Reservation Year DP2: Country It is this combination of multiple cubes and data providers that causes the Count() function to return different results in BusinessObjects 5.x and 6.0. If you create a block that contains the Country object from DP2 and the Number of Guests object from DP1, then apply the Count() function to the Number of Guests column, you get the following result: Country Number of Guests Australia France 446 Germany Holland Japan UK US 1105 Count: 7 In this situation the underlying cube created by BusinessObjects to build the block contains empty values, because not all countries have a value for Number of Guests. (See Filtering on empty values on page 323 for an explanation of empty values.) BusinessObjects 5.x counts these empty values when performing calculations using the Count() function. 322 BusinessObjects 6.x to XI Release 2 Migration Guide

323 Checking for calculation updates BusinessObjects document migration 17 The Count() function in BusinessObjects 6.0 BusinessObjects 6.0 no longer counts the empty values, with the result that the Count() function for this block returns 2 rather than 7. Obtaining BusinessObjects 5.x results in BusinessObjects 6.0 To obtain BusinessObjects 5.x results you need to apply the Count() function to a column that does not contain empty values. In the example, the formula for the total is Count(<Number of Guests>). If you change this to Count (<Country(DP2)>) you get the BusinessObjects 5.x result: Filtering on empty values Empty values occur in a BusinessObjects report for one of two reasons: A query returns empty values (for example, SQL queries containing outer joins often return NULL values) BusinessObjects internal cube processing creates a cube that contains empty values; for example, the cube underlying the block in the example for the Count() function described above Are your reports affected? If you have reports with filters on objects that return empty values, they are affected by the enhancement to BusinessObjects filter capability. BusinessObjects 5.x and 6.0 In BusinessObjects 5.x it is not possible to select an empty value when creating a filter. BusinessObjects 6.0 allows you to include the empty values in the filter definition, which allows you to build filters that, for example, exclude all empty values from the report. Filters in master/detail reports with incompatible objects Filters behave differently in BusinessObjects 6.0 in master/detail reports that contain incompatible objects in the section header and body. Are you reports affected? Your reports are affected by this issue if they contain incompatible objects that appear in the header and body sections of a master/detail report. The following is a BusinessObjects 5.x example: You have a report that contains the Country, Resort, Year, Reservation Year and Revenue objects. (Year and Reservation Year are incompatible objects.) Reservation Year appears in the section header; the section body contains a block with Country, Year and Revenue. BusinessObjects 6.x to XI Release 2 Migration Guide 323

324 17 Checking for calculation updates BusinessObjects document migration If you apply a filter on Reservation Year, for example Reservation Year= FY98, the filter also causes the entire contents of the block in the section body to be filtered. In BusinessObjects 6.0, the filter on the object in the section header does not affect the objects in the section body: Rankings in blocks with different data providers and empty values In BusinessObjects 6.0, ranking returns correct sub-totals in reports from rankings on blocks that contain objects from different data providers and empty values. Are your reports affected? Your reports are affected by this issue if they contain rankings with sub-totals in blocks that contain objects from different data providers empty values In this BusinessObjects 5.0 example you have a report with two data providers: Data Provider 1: Country Data Provider 2: Country, Resort, Number of Guests Your report has a block that contains Country (DP1), Resort and Number of Guests. You rank the top country by Number of Guests and include sub-totals in the ranking. US Bahamas Beach 565 US Hawaiian Club 540 Sum: 1105 Sum Other: 446 Sum All: 1551 The Sum and Sum Other totals are incorrect. Sum totals all Number of Guests figures in the report, rather than those left in the block by the ranking, and Sum Other does not include the figures excluded from the block by the ranking. These sums are correct in BusinessObjects BusinessObjects 6.x to XI Release 2 Migration Guide

325 Checking for calculation updates BusinessObjects document migration 17 The NoFilter() function with a Where clause NoFilter() is a function that tells BusinessObjects to ignore all filters when calculating a value. Are your reports affected? Your reports are affected by this issue if they use the NoFilter() function with a Where clause. NoFilter() Where in BusinessObjects 5.x You have a report containing the Resort, Services and Revenue objects. You apply a filter on Services to retain the value Bungalow only. The function NoFilter(<Revenue>) returns the total revenue for all services because it ignores the filter. You can refine the NoFilter() function with a Where clause; for example, NoFilter(<Revenue>) Where (<Service> = Excursion ) returns the total revenue for all Excursion services. In BusinessObjects 5.x it does not matter where you place the parentheses that enclose the input to the NoFilter() function. For example, NoFilter (Sum(<Revenue>) Where (<Service>="Excursion")) and NoFilter ((Sum(<Revenue>)) Where (<Service>="Excursion") return the same result. NoFilter() Where in BusinessObjects 6.0 In BusinessObjects 6.0, the position of the NoFilter() parentheses is critical. NoFilter (Sum(<Revenue>) Where (<Resort>="Bahamas Beach")) returns the same value as BusinessObjects 5.x, but NoFilter ((Sum(<Revenue>)) Where (<Service>="Excursion") returns an empty value. When you use the second syntax, BusinessObjects does not apply NoFilter() function to the sum before applying the Where clause. As a result, BusinessObjects returns an empty value, because the application of the filter (Service= Bungalow ) followed by the Where clause (Service= Excursion ) excludes all revenue values. Obtaining BusinessObjects 5.x results in BusinessObjects 6.0 To obtain BusinessObjects 5.x results, ensure that your NoFilter() Where functions or variables use the syntax that returns the same result as BusinessObjects 5.x. BusinessObjects 6.x to XI Release 2 Migration Guide 325

326 17 Checking for calculation updates BusinessObjects document migration Duplicate row aggregation The Avoid Duplicate Row Aggregation setting for a block tells BusinessObjects to return a single row for all rows where all column values are duplicated across multiple rows. When you select this option in a block in a report with multiple data providers, BusinessObjects ignores sorts on the block. BusinessObjects 5.x BusinessObjects 6.0 behavior In this example you have two data providers: Data Provider 1: Customer, Reservation Year Data Provider 2: Customer You create a block from Customer and Reservation Year (both from the same data provider) and place a sort on Customer in the block. When you include all rows in the table and include duplicates by selecting the Avoid Duplicate Rows Aggregation option, BusinessObjects ignores the sort on Customer. When you exclude duplicate rows from the table by deselecting the option, BusinessObjects sorts the table on the Customer object. BusinessObjects 6.0 applies the sort whether or not the Avoid Duplicate Rows Aggregation option is selected. Desktop Intelligence XI R2 modifications The UniverseName() function The UniverseName() function now returns the short name of a universe, rather than the long name. For example, where the function previously returned Island Resorts Marketing, it now returns beach. This change could affect the overall report size if the Autofit properties of the cell containing the function are enabled. The size of Autofit cells changes in relation to the data they contain, and the change in cell size might affect the size of the whole report. Changes in report size could in turn affect functions whose output relates to the report size, for example NumberOfPages(). 326 BusinessObjects 6.x to XI Release 2 Migration Guide

327 Checking for calculation updates BusinessObjects document migration 17 Unicode fonts The sizes of the Unicode fonts used by Desktop Intelligence are not identical to the sizes of the corresponding non-unicode fonts. This might have the following impacts: Data in cells which previously displayed all the cell data is now truncated, resulting in ###s to denote the truncation. Functions that return data relating to the report size - for example NumberOfPages() - might return different values in reports with cells whose Autofit properties are enabled. The size of Autofit cells changes in relation to the data they contain, and these changes in cell size might affect the size of the whole report. Reports are not identical when compared in a pixel-by-pixel comparison. Decimal precision Desktop Intelligence supports up to 24 decimal places, as opposed to 10 in previous versions. This increased precision might affect the output of some functions, in particular the euro conversion functions. BusinessObjects 6.x to XI Release 2 Migration Guide 327

328 17 Checking for calculation updates BusinessObjects document migration 328 BusinessObjects 6.x to XI Release 2 Migration Guide

329 Appendices part