Siebel Database Upgrade Guide > Siebel Incorporate Custom Layout Upgrade Option >

About the Siebel Incorporate Custom Layout Upgrade Option

Upgrades 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:

• Screen layouts are revised
• View layouts are revised
• Controls are added or removed in applets
• Controls are moved in applets

If you have modified existing screens, views, and applets, then 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 Layout

If you are upgrading from Siebel CRM version 7.x or later, then 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, then 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:

• At the end of the merge process, Screen, View, and Applet object types along with specific child objects, are copied to the New Customer Repository from the Prior Customer Repository. They replace their counterpart objects in the New Customer Repository.
• When the postmerge utilities run, the Web template files for the new release are copied out and saved. New Web template files similar to those of the release you are upgrading from are copied-in.

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:

• ICL can be used only for upgrades from Siebel CRM version 7.x onward.
• If your UI customizations consist mostly of customer-modified objects, then ICL is a good choice. ICL is intended to preserve the layout and contents of customer-modified screens, views, and applets.
• If your customizations consist primarily of customer-created UI objects that specify an upgrade ancestor, then ICL is not recommended. This is because ICL ignores the Upgrade Ancestor property. For UI objects, if the configuration of an upgrade ancestor changes in the new release, then the changes are not propagated to the descendant.
• In each release, ICL handling cannot be applied to screens, views, and applets that have Upgrade Behavior set to Admin in Siebel Tools. If you have large numbers of customer-modified screens, views and applets that are excluded from ICL handling, then ICL might not be a good choice.
• You can select ICL for only every other upgrade. Choose ICL for upgrades where the most customizations occur.

  At the upgrade after an ICL upgrade, you must bring UI layouts forward to those of the installed release before performing the repository merge.

UI Objects That ICL Affects

To 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:

• Screen
  • Screen View and all child objects
• View
  • View Web Template and all child objects
• Applet
  • Applet Web Template and all child objects
  • Drilldown and all child objects
• Screens, Views, and Applets, must be a standard object or a customer-modified object. (Customer-Created screens, views, and applets receive regular merge handling.)
• The object must be preservable. A screen, view, or applet is preservable if its Upgrade Behavior property is not set to Admin.

In summary, both customer-modified and standard unmodified screens views, and applets that are preservable receive ICL handling.

Table 47 compares a regular merge and an ICL merge. The columns list the status of a repository object:

• Standard. The object appears in the Prior Standard Repository, in the New Siebel Repository, and is not customer-modified.
• Deleted. You have deleted the object from the Prior Customer Repository (customer-deleted).
• Customized. You have modified the object in the Prior Customer Repository (customer-modified).
• Revised. The object has changed in the new release (New Siebel Repository).
• New. You have created the object in the Prior Customer Repository (customer-created), or the object is new in the new release (New Siebel Repository).
• Inactive. The object is present in the New Siebel Repository and New Customer Repository but is inactive and not used in the new release. The object is obsolete.

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 47 are described in a section following the table.

Table Exceptions

Exceptions listed in Table 47 are as follows:

• In an ICL merge, UI navigation changes at Siebel CRM version 7.7 are implemented in screens copied-in from the Prior Customer Repository.
• A conflict exists when an object is different in all three repositories. The merge process typically resolves the conflict in favor of the New Siebel Repository. After the merge, you can review conflicts and change the resolution.

Some UI Objects Are Not Eligible for ICL Handling

Certain 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, then 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:

• Siebel CRM version 7.7: Applets and views for Siebel Employee Relationship Management (ERM) and Siebel Marketing.
• Siebel CRM version 7.8: Applets and views in the Quotes and Orders screens and related customer management applets and views.
• Siebel CRM version 8.0: Most application home page screens.

Upgrade Behavior Property

An object property called Upgrade Behavior determines whether a UI object is preservable:

• If this property is set to Preserve then the UI object is eligible for ICL handling.
• If this property is set to Non-Preservable, then the UI object is not eligible for ICL handling for upgrades to the currently shipping release. At a future release the setting might be changed to Preserve.
• If this property is set to ADMIN, then the UI object is never eligible for ICL handling.

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 Path

As 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 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, then these settings have the following effects:

• For upgrades from releases prior to Siebel X, the object is not eligible for ICL handling. Customizations will not be preserved.
• For upgrades from Siebel X and later, the Preserve status is effective, and the object is eligible for ICL handling. Customizations will be preserved.

For example:

• At Siebel CRM version 7.7, Applet A was redesigned.
• The changes were so great that preserving customizations to Applet A when upgrading from a previous release was not practical. So Applet A must be made ineligible for ICL handling for upgrades from releases prior to Siebel CRM version 7.7.
• There were no significant changes to Applet A at Siebel CRM 7.8. or Siebel CRM 8.0. So Applet A is eligible for ICL handling for upgrades from Siebel CRM version 7.7 and later.
• The following settings create this upgrade behavior for Applet A: Upgrade Behavior indicates Preserve, ICL Upgrade Path indicates 7.7.

Note that there are two ways to make an object ineligible for ICL handling in the currently shipping release:

• Set the Upgrade Behavior property to Non-Preservable.
• Set the Upgrade Behavior property to Preserve, and set ICL Upgrade Path to 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 UI

In 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.

Screens

The association of views with screens is preserved. For upgrades prior to Siebel CRM version 7.7, a new navigation scheme is introduced. When reviewing the UI after the merge, verify that all views can be displayed.

Views

• The association of applets with views is preserved.
• The layout of views is preserved.
• System pages such as Help, About View, About Record, and Technical Support are not preserved.

Applets

The Web templates of standard and customer-modified applets in the Prior Customer Repository are preserved:

• When a Web template is used for an applet. Exception: for upgrades prior to Siebel CRM version 7.7, the postmerge utilities provide a new Web template for MVG applets that the postmerge utilities have converted to shuttle-enabled.
• All Web template item properties are preserved:
  • All control types are preserved.
  • The controls that are visible are preserved.
  • No new controls from the New Siebel Repository are added or deleted. Exception: for upgrades prior to Siebel CRM version 7.7, MVG applets receive new controls as part of being shuttle-enabled.
  • The location of controls in applets is preserved.
  • Applet mode (whether an applet displays in More mode or Less mode) is preserved.

    Exception: for upgrades prior to Siebel CRM version 7.7, many flow-based form applets are converted to grid-based.

• Applet Drilldowns and their child objects are preserved:
  • Drilldown properties are preserved.
  • The columns that have drilldowns is preserved
  • The destination views of drilldowns are preserved

The following features are not preserved:

• Applet-level and application-level menus.
• Properties of controls or list columns. For example, row height, column width, caption, and pop-up icons are not preserved.
• As of Siebel CRM version 7.7, Pick and Association applets support in-line queries. This feature is implemented whether or not you choose ICL.

If you are upgrading from a Siebel CRM version 7.x release prior to Siebel CRM version 7.7, then ICL has the following specific effects on applet controls and layout:

• Siebel CRM version 7.7 added two buttons in attachment applets: New File and New URL. An ICL merge does not add these buttons to applets.
• As of Siebel CRM version 7.7, MVG dialog boxes display only an OK button to close them. After an ICL merge, MVG dialog applets will have both OK and Cancel buttons.
• Siebel CRM version 7.7 added two new UI features, Query Assistant and Quick Print. An ICL merge does not add these buttons to applets. You must add these buttons as desired after completing the upgrade.
• In Siebel CRM version 7.7, applets have three default buttons: New, Delete, and Query. If you select an ICL merge, then applets will keep their existing default buttons.
• In Siebel CRM version 7.7, the Reset button was removed from applets. If you select an ICL merge, then applets keep the Reset button.

Navigation

Changes to navigation in the release you are upgrading to are implemented. This might affect screen, view, and applet layouts.

For example, in Siebel CRM version 7.7, a new navigation scheme was introduced. If you are upgrading from a release prior to Siebel CRM version 7.7, then 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 Objects

An 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, then 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:

• Applet Toggle
• Control and child objects
• Drilldown and child objects
• List and child objects
• Chart and child objects
• Tree and child objects

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 Objects

If you created screens, view, or applets in the Prior Customer Repository, then they are handled as follows:

• The ICL merge step ignores the Upgrade Ancestor property. For example, New Applet specifies Standard Applet as an upgrade ancestor. New Applet does not receive ICL handling. This means that New applet and all its child objects are copied intact to the New Customer Repository. The child objects do not replace UI objects in the New Customer Repository.
• For an ICL merge, the postmerge utilities copy new Web template files to the Tools installation directory. These files replace those in the new release and will be used to render customer-created objects.

ICL and the Upgrade Ancestor Property

The 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:

• During the regular merge, Applet-B receives the new button, because it is a descendant of Applet-A.
• During the ICL merge portion, the Web template configuration of Applet-A is copied from the Prior Customer Repository to the New Customer Repository. This Web template configuration does not contain the new button. This removes the new button from Applet-A.
• Because the ICL merge portion ignores the Upgrade Ancestor property, this change is not propagated to Applet-B. Applet-B retains the new button.

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 Works

An ICL merge is a regular merge that contains two additional steps:

• The first step occurs at the end of the merge.
• The second step is part of the postmerge utilities, which run after the merge is complete.

Additional Merge Step

At the end of the regular merge portion, the ICL merge step runs and makes changes to ICL objects in the New Customer Repository:

• ICL objects from the new release, are deactivated, and -UPG is appended to their name. These objects are read-only and cannot be deleted.
• ICL objects from the Prior Customer Repository are copied to the New Customer Repository and are verified as active.

The ICL merge step writes status and issues to the merge log files.

Postmerge Utilities and Grid-Based Applets

The second step occurs after the ICL merge step completes and the merge is finished. The postmerge utilities run and make additional ICL changes:

• At Siebel CRM version 7.7, many form applets in the New Siebel Repository that were formerly flow-based are grid-based. After an ICL merge, flow-based form applets from the Prior Customer Repository will replace some of these grid-based applets in the New Customer Repository, particularly for upgrades from releases prior to Siebel CRM version 7.7. The postmerge utilities will convert these replacement flow-based applets to grid-based.
• For flow-based form-applets that are converted to grid-based, you can choose to put field labels on top or on the left when setting up the merge. The UI standard as of Siebel CRM version 7.7 is to place field labels on the left.

Postmerge Utilities and Web Template Files

The 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, then 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 utilities move the Web template files for the new release from webtempl to \temp\webtempl.
• The utilities copy Web template files from a subdirectory of reppatch\web_templates to \webtempl.

  These Web template files support the UI layout of the release you are upgrading from. They are similar but not identical to the Web template files included in that release. For example, if you selected the 7.5.3 and Label on Top ICL options, then the postmerge utilities copy Web template files from the 753 and TopLabel subdirectories of reppatch.

The postmerge utilities write status and issues to the postmerge utilities log.

ICL and HTML Style Sheets

The 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, then 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 CRM version 7.x to Siebel CRM version 7.7, then 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:

• Removes the ICL objects that were copied-in from the Prior Customer Repository.
• Activates the ICL objects with the -UPG suffix and removes the suffix. These -UPG objects are from the Prior Customer Repository (the repository in the release you are upgrading from). This reverses the effect of ICL and upgrades your UI to the current release.

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, then it is not replaced by its corresponding -UPG object. You must manually reconfigure these customer-modified objects after the merge as needed.

Related Topics

About the Siebel Repository Merge

About Inheriting Upgrade Behavior in a Siebel Upgrade

About the Siebel Postmerge Utilities

Reviewing Siebel Repository Object Property Conflicts