Upgrade Management Tool

Configuring UMT

To use UMT for upgrade, you need to configure UMT for better performance. Run “Java –Xmx” command while you launch Upgrade Management Tool to run it with Java Heap → Right click on UMT and go to Properties, as explained below −

You have to copy the “Target” path to Notepad and replace “Xmx” with amount of Heap configure for your system, as shown below −

You can also configure your timeout in Upgrade Management Tool. Set the below parameter −

To set CORBA timeout for UMT, you have to navigate to Properties file and add the below entry. Properties file is located in your BO installation directory at this path − “SAP BusinessObjects Enterprise XI 4.0\java\apps\upgradeManagementTool\jars”

<entry key="umt.systemVar.backendCommunicationTimeoutInMS">630000</entry>

It is recommended to keep value below 630000, otherwise, you may face error related to CMS login.

Setting up source and target in UMT

You can define your source and target CMS system in UMT and check the connectivity. Run Upgrade Management Tool from All Programs → Select Incremental upgrade → Next. The screen given below explains the same.

Enter your source and target CMS name and provide the credentials. Provide the upgrade scenario from drop down list, as shown below −

You have different upgrade scenarios available in UMT, such as −

Live to Live − This will require both source and target system to be up.
BIAR to Live − This option is used to import the objects from BIAR file format to live target system.
Live to BIAR − This option is used to export the objects in BIAR format from live system.

These scenarios can be used based on status of your source and target system. Both systems are up, you can perform live to live upgrade without exporting/importing objects.

In BO 4.2, UMT has few new features as below −

You can define log level as low, medium and high from the drop-down list.
When you select log level - “High”, it captures all the errors, warning and failures during the process.

You can also define temp space to any of required directory and relaunch UMT tool after changes.
The temp space usually stores all the entries of Derby Database and once upgrade is completed; these files can be removed.

When you perform BO upgrade from BOXI 3.x to BI 4.1, you can have multiple scenarios to migrate different objects, contents, users, etc. and scope defined in each scenario. As per SAP recommendation, below iterations can be used −

Iteration	Scope
Iteration #1	In this iteration, following objects were migrated with their dependencies − User groups Access Levels Applications The same approach can be used for all user groups, all access levels in a single iteration. However, this can be time consuming based on the number of objects etc. Therefore it's recommended to decide the number of iteration based on your repository objects.
Iteration #2	The following objects were considered for update with dependencies. You can select these objects for migration in the Object selection screen − Folders and Objects Repository Objects Universes For this pattern book, we have done migration in a single iteration. However, depending upon the number of iterations based on your repository objects.
Iteration #3	In the initial "Select Filter" screen, the time filter was set according to the requirement. In our pattern book, we are.selecting the start date as 02/01/2016 and the end date as 02/05/2016. So, only the following objects will be listed and migrated − Universe - Universe modified between the start date and date mentioned in the select filter Web intelligence Reports − Reports modified between the start date and end date mentioned in the select filter.
Iteration #4	The following objects were considered for upgrade with dependencies. These are the objects selected for migration in the Object Selection screen − Applications Calendars Corporate Categories Remote Connections and Replication Jobs Repository Objects Universes In this iterations, all the content dependencies(related to all the documents) were set to be upgraded first. However, this can also be done in increments. Note that any objects that have already been migrated will not be listed in the object selection screen. Again, in this iteration as we are using the feature "Hide objects which are already upgraded" from the selection filter screen.
Iteration #5	The following objects were selected for upgrade with dependencies − Public folders and their objects, except those objects that were upgraded in iteration 2 QaaWS objects Events Mobile Subscriptions Objects dependencies will be listed in UMT, but will be unselected later For this pattern book, we have done the migration in a single iteration. However, depending upon the number of objects, this iteration cab be time consuming. Therefore it's recommended to decide the number of iterations based on your repository size and number of objects.

Iteration

Scope

Iteration

In this iteration, following objects were migrated with their dependencies −

User groups
Access Levels
Applications

The same approach can be used for all user groups, all access levels in a single iteration. However, this can be time consuming based on the number of objects etc. Therefore it's recommended to decide the number of iteration based on your repository objects.

Iteration

The following objects were considered for update with dependencies. You can select these objects for migration in the Object selection screen −

Folders and Objects
Repository Objects
Universes

For this pattern book, we have done migration in a single iteration. However, depending upon the number of iterations based on your repository objects.

Iteration

In the initial "Select Filter" screen, the time filter was set according to the requirement. In our pattern book, we are.selecting the start date as 02/01/2016 and the end date as 02/05/2016. So, only the following objects will be listed and migrated −

Universe - Universe modified between the start date and date mentioned in the select filter
Web intelligence Reports − Reports modified between the start date and end date mentioned in the select filter.

Iteration

The following objects were considered for upgrade with dependencies. These are the objects selected for migration in the Object Selection screen −

Applications
Calendars
Corporate Categories
Remote Connections and Replication Jobs
Repository Objects
Universes

In this iterations, all the content dependencies(related to all the documents) were set to be upgraded first. However, this can also be done in increments.

Note that any objects that have already been migrated will not be listed in the object selection screen. Again, in this iteration as we are using the feature "Hide objects which are already upgraded" from the selection filter screen.

Iteration

The following objects were selected for upgrade with dependencies −

Public folders and their objects, except those objects that were upgraded in iteration 2
QaaWS objects
Events
Mobile Subscriptions
Objects dependencies will be listed in UMT, but will be unselected later

For this pattern book, we have done the migration in a single iteration. However, depending upon the number of objects, this iteration cab be time consuming. Therefore it's recommended to decide the number of iterations based on your repository size and number of objects.

Previous Page Print Page