Siebel Database Upgrade Guide > Performing the Siebel Repository Merge >

Migrating Siebel Repository Objects to the Standard UI


Upgrades from: All Supported Siebel releases. Perform this task if you selected Incorporate Custom Layout (ICL) on your previous upgrade.

Environments: Development environment only.

Platforms: Windows, UNIX, IBM z/OS.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

If you selected the Incorporate Custom Layout (ICL) merge option for your prior upgrade, UI objects in the New Customer Repository were deactivated and replaced by UI objects from the Prior Customer Repository. Before upgrading to the next release, you must reactivate the standard UI objects. You do this after the development upgrep and before the repository merge.

For example, you upgraded from Siebel 7.5 to Siebel 7.7 and selected the ICL merge option to preserve the Siebel 7.5 UI look and feel. Now you are upgrading from Siebel 7.7 to the latest Siebel Release. Before doing the repository merge, you must activate the Siebel 7.7 standard UI objects. This migrates your UI to Siebel 7.7.

The migration returns the UI to the state it would have been after a regular merge instead of an ICL merge. The following list refers to the Prior Customer Repository from your previous upgrade.

  • Customer-Created screens, views and applets are retained.
  • UI controls you added in the Prior Customer Repository are retained, but control placements may need to be reconfigured.
  • UI controls, list columns, page tabs, charts, applet web template items, and view web template items that you deleted in the Prior Customer Repository remain deleted.
  • Customer-Modified screens, views, and applets in the Prior Customer Repository that were further customized afterward are not migrated to the standard UI. Customizations are preserved, but you may need to revise object layouts to conform to the UI standard in the new release.
  • Standard objects in the Prior Customer Repository that were not deleted, or modified afterward are migrated to the standard UI. No reconfiguration should be required.
  • Standard objects in the Prior Customer Repository that were modified afterward are not migrated to the standard UI. Customizations are preserved, but you may need to revise object layouts to conform to the UI in the new release.

Migrating to the standard UI uses defined logic to select objects and then modifies these objects as follows:

  • ICL objects: These are the screens, views, applets and child objects that received ICL handling in your previous upgrade. The ICL merge deactivated standard UI objects in the New Customer Repository and replaced them with ICL objects from the Prior Customer Repository. Migration to the standard UI deactivates and deletes ICL objects and activates their counterpart standard UI objects.
  • Standard UI objects. These are the UI objects that were deactivated by the ICL merge step and have -UPG appended to their names. They contain customizations from the previous repository merge, such as control deletion and addition. They do not contain certain UI layout customizations such as control placement. Migration activates these objects. Standard UI objects replace the ICL objects for the release you are upgrading from. The layouts of some of the standard UI objects will need to be reconfigured.

Using Lag Time to Identify Postupgrade Customizations

ICL objects you have customized after the previous upgrade are not affected by the migration to the standard UI. These changes are preserved and are included in the repository merge for the new release.

Siebel Tools identifies these customizations by comparing the modification time of ICL objects with their corresponding standard UI objects. If the modification times differ by more than a specified lag time, Siebel Tools does not change the ICL object, and it is treated as a customized object in the upcoming repository merge.

For example, your previous ICL repository merge required about three days to complete. This means the modification time of an ICL object and its corresponding standard UI object did not differ by more than three days when the repository merge completed. You later modified an ICL object. Its modification time now differs by more than three days from the corresponding standard UI object.

You then use Siebel Tools to migrate the repository to the standard UI and use a lag time of three days. Since the modification time comparison for the ICL object is greater than the lag time, the ICL object is not replaced by the corresponding standard UI object. The ICL object is treated as a customized object in the upcoming repository merge.

The default lag time is 72 hours. You can specify a lag time between 24 and 120 hours. Observe the following guidelines:

  • Avoid setting a lag time that is shorter than the time required to complete the previous repository merge. This can cause objects that were not customized after the merge to be treated as customized.
  • Do not set a lag time that is significantly larger than the length of the previous repository merge. This increases the risk that customizations were made before the lag time expired. These customizations are lost during the upcoming repository merge.

How Repository Objects Are Changed

The migration process locates both standard UI objects and ICL objects in the repository. The process then determines whether to modify the standard UI object or the corresponding ICL object:

  • Deleting the ICL object and activating the corresponding standard UI object migrates the UI object to standard.
  • Deleting a standard UI object and retaining the corresponding ICL object preserves the customized ICL object.

Table 35 shows the logic used to modify these objects. Interpret the table columns as follows:

  • ICL Object Found? Yes means Siebel Tools has located a standard UI object that has a corresponding ICL object. No means that a corresponding ICL object is not in the Siebel Repository. In most cases, this is because the object was inactive in the Prior Customer Repository during the previous merge. When this occurs, the object is appended with -UPG, and no ICL object that preserves look and feel is created.
  • Within Lag Time? Yes means that the modification time comparison is within the specified lag time. No means the comparison is not within the specified lag time and that you have modified the ICL object after the repository merge.
  • Status in Prior Siebel Repository. Siebel Tools checks the Active/Inactive status in the Prior Siebel Repository. This prevents activating an object that is inactive in the Prior Siebel Repository.

In the table, Siebel Repository refers to your current Siebel Repository.

Table 35. Logic Used to Modify Repository Objects
ICL object Found?

Within Lag Time?

Status in Prior Siebel Repository
How Migration Modifies Objects in the Siebel Repository

Yes

Yes

Active

  • Deletes the ICL object.
  • Removes the -UPG suffix from the name of the corresponding standard UI object.
  • Changes object status from Inactive to Active in the Prior Customer Repository.
  • Removes the read-only restriction. You can delete or modify the object.

Yes

Yes

Inactive

  • Deletes the ICL object.
  • Removes the -UPG suffix from the name of the corresponding standard UI object.
  • Status is not changed from Inactive to Active in the Prior Customer Repository.
  • Removes the read-only restriction. You can delete or modify the object.

Yes

No

N/A

  • Makes no changes to the ICL object. (The object has been customized after the repository merge.)
  • Deletes the corresponding standard UI object and children of this object.

No

N/A

N/A

  • Status of object is not changed from Inactive to Active.
  • Removes the read-only restriction. You can delete or modify the object.

How Logging Is Done

The migration process writes the changes to the repository in the following log file:

SIEBEL_ROOT\log\iclmigration.log

The beginning of the log lists top-level objects that were affected by the ICL feature. For each object, the log then iteratively lists the operations performed on all child objects.

Specifying a Lag Time

The default lag time is 72 hours. You can revise this by editing the Siebel Tools .cfg file. The minimum is 24 hours, and the maximum is 120 hours.

  • Prerequisite: You must have installed the Siebel Tools that shipped in the new release.

To specify a lag time

  1. In the Siebel Tools installation directory, navigate to the \bin\lang directory, where lang is the installed language, for example ENU.
  2. Using a text editor, open tools.cfg, and locate the [Siebel] section.
  3. Add the following variable at the end of the section:

    PriorICLMergeTimeLag = time

    where time is an integer greater than or equal to 24 and less than or equal to 120.

  4. Save the file.
  5. Restart Siebel Tools.

Migrating to the Standard UI

A menu option in Siebel Tools migrates ICL objects to the standard UI. Upgrading the UI requires a minimum of three hours to complete.

Prerequisites:

  • You must have installed the Siebel Tools that shipped in the new release.
  • Set the lag time as desired. The default is 72 hours.
  • Verify that you have backed up the upgraded database.

To migrate to the standard UI

  1. Start Siebel Tools.
  2. In the Tools menu, choose Upgrade, and then select Migrate ICL Objects to Standard.
  3. In the ICL Migration dialog, make the following selections and click Continue:
    • Prior Customer Repository: Select Prior Customer Repository. This is the Siebel Repository in your current release, which you have renamed in preparation for the upgrade.
    • Prior Standard Repository: Select Prior V7.X Siebel Repository. This is the Prior Standard Repository for your currently installed release. This repository was loaded when you performed the database upgrep for the new release.
  4. In the ICL Migration Warning dialog, click Yes to confirm you have backed up the Prior Customer Repository.

    The ICL Migration Status dialog box appears. It displays log entries during the migration.

    During the migration, you cannot perform other operations in Siebel Tools. You also cannot close Siebel Tools.

    A pop-up message displays when the migration is complete.

  5. To cancel the migration after it has begun, do the following:
    1. In the ICL Migration Status dialog box, click Cancel.
    2. In the dialog box that asks you to confirm you want to cancel, click Yes.

      If you cancel the migration after it has begun, you must restore the saved Prior Customer Repository from backup and begin the migration again.

Related Topics

About the Siebel Repository Merge

About the Siebel Incorporate Custom Layout (ICL) Upgrade Option.

Siebel Database Upgrade Guide Copyright © 2008, Oracle. All rights reserved.