Bookshelf Home | Contents | Index | PDF |
Siebel Database Upgrade Guide > How the Siebel Database Upgrade Works > About the Siebel Incorporate Custom Layout (ICL) Upgrade OptionUpgrades from: Siebel 7.x using ICL. Environments: Development environment only. Platforms: Windows, UNIX, IBM z/OS. In each new release, there are typically several types of changes to existing UI objects:
If you have modified existing screens, views, and applets, the changes in the new release can require significant UI layout reconfiguration after the repository merge. The purpose of an ICL merge is to reduce postmerge UI layout reconfiguration. Overview of Incorporate Custom LayoutIf you are upgrading from Siebel 7.x or later, you can choose Incorporate Custom Layout (ICL) when performing a repository merge. An ICL merge handles customer-modified screens, views, and applets differently than other repository objects. A regular merge identifies changes you have made to objects in the Prior Customer Repository (customer-modified objects) and merges those changes into the counterpart objects in the New Customer Repository. For example, if you added a control to Applet-A in the Prior Customer Repository, a regular merge adds the control to Applet-A in the New Customer Repository. An ICL merge does not merge changes into counterpart objects in the New Customer Repository. Instead, an ICL merge process replaces the configuration of screens, applets, and views in the New Customer Repository with those from the Prior Customer Repository. For example, you have added a control to Applet-A in the Prior Customer Repository. The merge process deactivates the Web template configuration for Applet-A in the New Customer Repository and replaces it with the Web template configuration for Applet-A from the Prior Customer Repository. The Web template configuration from the Prior Customer Repository contains the new control along with the correct layout of the control. In addition, after the merge, the postmerge utilities copy-in new Web template files that are similar to the release you are upgrading from. Web template files provide page containers that control screen, view, and applet layouts. The copied-in Web template files further ensure that the UI in the new release has layouts similar to the UI in the old release. An ICL merge adds two additional steps to the regular merge process. These two steps are called ICL handling:
Customer-created screens, views, and applets do not receive ICL handling. These UI objects are copied to the New Customer Repository intact. This is true even if a customer-created applet specifies an ICL object applet as an upgrade ancestor. Who Should Use ICL?Consider using ICL if it can significantly reduce your postmerge UI cleanup workload. ICL merges are intended for customer-modified UI objects. A customer-modified UI object is a standard screen, view, or applet you have modified and saved without changing its name. Screens, views, and applets that you create by copying them from a standard object and renaming them are customer-created UI objects. Use the following factors to assess whether to use ICL:
UI Objects That ICL AffectsTo receive ICL handling, a UI object must meet all the following criteria. Objects that meet all the criteria are called ICL objects: The object must be one of the following top-level object types. For each top-level object type, the child objects that ICL affects are also listed:
In summary, both customer-modified and standard unmodified screens views, and applets that are preservable receive ICL handling. Table 15 compares a regular merge and an ICL merge. The columns list the status of a repository object:
The first three columns list the status of the object in the three repositories that the merge process compares during the merge. The last two columns list the status of the object after the merge is complete and the postmerge utilities have run. The Merged New Customer Repository column lists the status of all repository object types after the repository merge. The ICL Merged New Customer Repository column lists the status of screen, view, and applet ICL objects after an ICL merge. Exceptions listed in Table 15 are described in a section following the table.
Table ExceptionsExceptions listed in Table 15 are as follows:
Some UI Objects Are Not Eligible for ICL HandlingCertain screens, views, and applets that are required to administer applications and support the standard operation of the application are never eligible for ICL handling. These include UI objects for Server Administration and Remote Administration. In addition, if the screens, views, and applets in an application have changed significantly in a new release, they are also excluded from ICL handling. ICL handling for these UI objects is not practical, because their layout and functionality have been greatly revised. Application areas excluded from ICL handling in recent releases are as follows:
Upgrade Behavior PropertyAs of Siebel 7.7, an object property called Upgrade Behavior determines whether a UI object is preservable:
The Upgrade Behavior property is defined on Screen, View, and Applet. At each release, Oracle sets the value of Upgrade Behavior for UI objects. Do not change these values. ICL Upgrade PathAs of Siebel CRM 8.0, an object property called ICL Upgrade Path controls the releases for which Upgrade Behavior indicates Preserve is effective. ICL Upgrade Path restricts eligibility for ICL handling to specific releases. You select ICL Upgrade Path from an LOV. Values include Pre-7.5.3, 7.5.3, 7.7, and 8.0. Like the Upgrade Behavior property, ICL Upgrade Path is defined on Screen, View, and Applet. If Upgrade Behavior is set to Preserve, and ICL Upgrade Path is set to Release X, these settings have the following effects:
Note that there are two ways to make an object ineligible for ICL handling in the currently shipping release:
At each release, Oracle sets the value of ICL Upgrade Path for UI objects. Do not change these values. How ICL Affects the Overall UIIn general, an ICL merge preserves the UI layouts of the Siebel Release you are upgrading from but also applies any significant UI navigation changes in the new Siebel Release. ScreensThe association of views with screens is preserved. For upgrades prior to Siebel 7.7, a new navigation scheme is introduced. When reviewing the UI after the merge, verify that all views can be displayed. Views
AppletsThe Web templates of standard and customer-modified applets in the Prior Customer Repository are preserved:
The following features are not preserved:
If you are upgrading from a Siebel 7.x release prior to Siebel 7.7, ICL has the following specific effects on applet controls and layout:
NavigationChanges to navigation in the release you are upgrading to are implemented. This may affect screen, view, and applet layouts. For example, in Siebel 7.7, a new navigation scheme was introduced. If you are upgrading from a release prior to Siebel 7.7, this navigation scheme is implemented during the upgrade regardless of whether you choose ICL. In parent list views, view tabs do not display in a row near the middle of the view as they did in 7.0x and 7.5x. You must select a record in the parent list applet to display the view tabs. How ICL Handles Deleted and Obsolete ObjectsAn ICL merge treats deleted UI objects in the same way as a regular merge. If you deleted screens, views, or applets in the Prior Customer Repository, and they are present in the New Siebel Repository they will be present in the New Customer Repository after the merge. You will need to manually verify and remove these as desired. In a regular merge, if an object is obsolete (inactive) in the New Siebel Repository, the object is inactive in the New Customer Repository after the merge. This is also true for an ICL merge. In addition, an ICL merge replaces the following object types with their counterparts from the Prior Customer Repository. The replacement object types are then set to inactive:
Any other UI object types that are obsolete in the New Customer Repository are handled the same way as a regular merge. ICL and Customer-Created UI ObjectsIf you created screens, view, or applets in the Prior Customer Repository, they are handled as follows:
ICL and the Upgrade Ancestor PropertyThe ICL merge step ignores the Upgrade Ancestor Property. Customer-created applets do not receive ICL handling. For example, you create Applet-B by copying standard Applet-A. In Applet-B you specify Applet-A as the upgrade ancestor. In the New Siebel Repository, Applet-A has a new button. After an ICL merge, Applet-B displays the new button, but Applet-A does not:
In a regular merge, both Applet-A and Applet-B display the new button. On an ICL merge, the regular merge portion propagates upgrade handling of non-ICL-object types (Business Component, and so on) to descendants normally. For this reason, using the Upgrade Ancestor Property with an ICL merge is recommended. How an ICL Merge WorksAn ICL merge is a regular merge that contains two additional steps:
Additional Merge StepAt the end of the regular merge portion, the ICL merge step runs and makes changes to ICL objects in the New Customer Repository:
The ICL merge step writes status and issues to the merge log files. Postmerge Utilities and Grid-Based AppletsThe second step occurs after the ICL merge step completes and the merge is finished. The postmerge utilities run and make additional ICL changes:
Postmerge Utilities and Web Template FilesThe postmerge utilities copy-in new Web template files. These Web template files are similar to those in the release you are upgrading from. They provide page containers and supporting Web templates that preserve screen, view, and applet layouts. They also implement navigation changes. If you have edited the Web template files in the release you are upgrading from, you must reimplement your customizations in the new Web template files. The postmerge utilities make the following changes to Web template files in the Siebel Tools installation directory:
The postmerge utilities write status and issues to the postmerge utilities log. ICL and HTML Style SheetsThe postmerge utilities do not copy-in a new version of the HTML style sheets, main.css and printmain.css. The style sheets for the new release are used to render all UI objects, including those copied-in from the Prior Customer Repository. If you customized the style sheets in the release you are upgrading from, you must reimplement your customizations in the style sheets in the new release. What Happens at the Next Siebel Release?You can perform an ICL merge for only every other upgrade. For example, if you performed an ICL merge when upgrading from Siebel 7.x to Siebel 7.7, performing an ICL merge when upgrading to the next release is not recommended. At the next release before you run the repository merge, you must run a Siebel Tools utility that restores repository objects to the standard UI. The utility makes the following repository changes:
A Tools utility provides a method for defining a filter to identify UI objects that you have modified since the prior upgrade. If an object has been modified since the prior upgrade, it is not replaced by its corresponding -UPG object. You must manually reconfigure these customer-modified objects after the merge as needed. Related Topics |
Siebel Database Upgrade Guide | Copyright © 2008, Oracle. All rights reserved. | |