Migration Tasks for Siebel Open UI

This topic provides information about some of the migration tasks that you might need to perform when you are deploying Siebel Open UI. It contains the following information:

"Using Legacy Browsers When Migrating to Siebel Open UI"
"Migrating SRF Files and SWT Files"
"Migrating Browser Scripting"
"Migration Options for Siebel File System Features in Siebel Open UI"
"Behavior of Standard Interactivity Views in Siebel Open UI"
"Migration Options for Siebel Calendar Features"
"Migrating Siebel Portlets"
"Migration Options for Standard Interactivity Portals"

Related Books

Configuring Siebel Open UI

Using Legacy Browsers When Migrating to Siebel Open UI

Migration to Siebel Open UI can be achieved while retaining an existing Siebel CRM deployment, with minimal development effort. If the migration is planned properly, then the addition of a Siebel Open UI deployment does not have to affect your existing deployment.

Review the following options for deployments that currently use legacy browsers, which have conformance and performance limitations:

Deploy one or more browsers specifically for use with Siebel Open UI applications, which conform to the required browser standards. A third-party product, such as Browsium Catalyst, can route traffic to specific browsers, based on enterprise requirements.
Continue to deploy high interactivity Application Object Managers for users that have support available for legacy browsers only.
Continue to deploy standard interactivity Application Object Managers for users that have older browsers.
Consider using a Web browser layout engine plug-in that meets standards and performance requirements to update browsers to fast versions.

Note:
Third-party products, such as plug-in solutions, are solely dependent on the third parties building them. Oracle has no part in the support of those solutions.

You must take into account the constraints of the browsers that are supported by each client. The Siebel Open UI client requires standards-compliant browsers, while the Siebel high interactivity client requires Internet Explorer 8 or earlier. Installing multiple browsers and meeting both requirements allows users to switch back to the legacy deployment and to use the appropriate browser in each case. If browser constraints are considered properly, then there is no risk in maintaining both environments until user acceptance tests are completed with successful results.

For more information about running high interactivity clients in an environment that supports Siebel Open UI, see Siebel Open UI Deployment Guide, 1499842.1 (Article ID) on My Oracle Support.

This topic is part of "Migration Tasks for Siebel Open UI".

Migrating SRF Files and SWT Files

In general use cases, it is not necessary to recompile the SRF to run Siebel Open UI, apart from exceptions mentioned in this guide.

You can store Siebel Web templates (SWT files) in the new location for custom Siebel Web templates or keep them in their existing location. Moving the files to their new location is described in Configuring Siebel Open UI.

Note:

For the current release, Siebel Tools does not support SWT work with browsers other than Microsoft Internet Explorer. Additional limitations apply to previous Siebel CRM releases. For more information, see Siebel Open UI Deployment Guide, 1499842.1 (Article ID) on My Oracle Support.

This topic is part of "Migration Tasks for Siebel Open UI".

Migrating Browser Scripting

It is not necessary to change your existing client-side browser scripting to run Siebel Open UI. However, to make sure that your applications work the same in multiple browsers, you must make sure that no browser-specific JavaScript is implemented in your existing browser scripts.

Specific methods in Siebel CRM have been enhanced or changed for a variety of reasons, including security. These methods, which apply to all user interfaces, include the following:

WriteRecord. For more information, see 1551530.1 (Article ID) on My Oracle Support.
SetProfileAttr. This method has been disabled for HTTP calls, for security reasons. By default, a browser script that references SetProfileAttr will not work. You can override this change, although doing so reintroduces the security vulnerability. Any decision to override must be done after careful consideration of the risks. To activate access to SetProfileAttr, set the server parameter EditProfileAttr to True.

This topic is part of "Migration Tasks for Siebel Open UI".

Migration Options for Siebel File System Features in Siebel Open UI

W3C-based client applications typically run inside of a Web browser container and, for security reasons, are limited in their interactions with client-side applications and files on user computers. Conforming to a Web-standards approach dictates or suggests specific recommendations for designers of hosted deployments involving Siebel Open UI applications and documents or templates that use either structured or unstructured data.

Current Siebel Business Applications features for correspondence, for example, also force a change in the interaction between the user and the Siebel Open UI client, regarding legacy client-side proprietary document formats and applications.

For example, if a user tries to drag an email from Microsoft Outlook into the Siebel client, in order to save it as an attachment in the Siebel File System, then this operation cannot be completed. Such applications typically use different drag-and-drop methods and storage structures than those of the operating system itself. Before the user can save an item (such as an email message) into the Siebel application as an attachment in the Siebel File System, the user must save it as a file in a local or network directory.

Where Java Runtime Environment is present on the user computer, however, attachment files can be saved directly to the Siebel application.

Consider the following recommendations to make it easier to manage data and user interactions of these types:

Where possible, integrate Siebel Open UI applications with true W3C-compliant client applications or hosted applications, such as Microsoft Outlook Web Access. Such applications can be integrated by using Web services on the back end or by using the JavaScript API on the client side, depending on the business requirements. Integrating with true Web-based client components can simplify many deployment challenges.
Application designers might consider moving content that currently uses attachments based on proprietary document formats and applications into structured or unstructured data fields that use Web-centric formats such as XML or HTML. This approach:
- Allows content to be formatted using Siebel Document Server or Oracle Business Intelligence Publisher.
- Supports audit trails and approvals as content is changed and added by users.
- Can make it unnecessary to manage content in documents. However, separate physical documents can be created as needed when content creation or revision is complete.
- Can make it easier to search the modified content.
Users must have locally available a directory, on the network or on the local computer (for example, a laptop), in which they can store modified files or content dragged from applications like Microsoft Outlook. Then they can save such files into the Siebel application as attachments in the Siebel File System.

This topic is part of "Migration Tasks for Siebel Open UI".

Behavior of Standard Interactivity Views in Siebel Open UI

The high interactivity client can display certain standard interactivity applets. However, Siebel Open UI does not support standard interactivity applets. When you convert a high interactivity application to Siebel Open UI, specific rules apply for converting any standard interactivity applets.

Siebel Open UI supports the following scenarios only when EnableOpenUI is set to True and HighInteractivity is set to True. If EnableOpenUI is False (Siebel Open UI is disabled), then all legacy checks apply. A standard interactivity applet is handled as follows in Siebel Open UI:

Applet with no business component. An applet that does not have a business component upgrades automatically to Siebel Open UI. A standard interactivity applet has no custom renderers.
Applets outside of a view.
- An applet that is standard interactivity only because of it is outside of the view (although all other conditions pass for RIA qualification) upgrades automatically to RIA. (RIA is rich Internet application, and represents the Siebel application display mode for Siebel Open UI.)
- An applet that is outside of the view and has custom renderers attached is blocked.
- Applets with renderers as base standard interactivity renderers (CSSPopupSIRenderer, CSSListPopupSIRenderer, CSSHtmlSIRenderer) upgrade automatically to high interactivity, to the extent possible.
- An applet that was standard interactivity only by the class definition in the repository is the best candidate for a straightforward conversion. Such applets upgrade automatically to RIA. Rendering might not be complete, because features such as links might not be fully supported. Recent records applets are implemented in Siebel Open UI as client-side artifacts, for example.

If a view has multiple applets with a combination of standard interactivity and high interactivity applets, then high interactivity applets are rendered and each standard interactivity applet is rendered as a rectangular outline containing a yellow exclamation point. In this use case, the image shown with a tooltip explanation is rendered to inform the user that the applet cannot be rendered.

For more information about converting standard interactivity applets to high interactivity for use in Siebel Open UI, see Configuring Siebel Open UI.

This topic is part of "Migration Tasks for Siebel Open UI".

Migration Options for Siebel Calendar Features

The Siebel Open UI calendar has been enhanced to provide additional capability. Workaround options are available to allow you to retain legacy calendar behavior in the Siebel Open UI client. For more information about these options, see Configuring Siebel Open UI.

This topic is part of "Migration Tasks for Siebel Open UI".

Migrating Siebel Portlets

You can migrate Siebel portlets to Siebel Open UI. Siebel Web Engine (SWE) APIs provide an interface to deliver data and metadata content. The SWE XML features are not available in Siebel Open UI. For more information, see Siebel Portal Framework Guide. See also Configuring Siebel Open UI.

This topic is part of "Migration Tasks for Siebel Open UI".

Related Books

Siebel Performance Tuning Guide

Configuring Siebel Open UI

Migration Options for Standard Interactivity Portals

If you use standard interactivity portals and want to use Siebel Open UI features, then several migration alternatives are available to you. Standard interactivity applets and functionality can, with a little effort, be switched to high interactivity, so they can render in Siebel Open UI. You can decide between the following options, each of which has advantages and disadvantages:

Perform manual tasks to migrate standard interactivity applets to high interactivity.
Use new features or applications that extend the customer-facing options in Siebel Open UI.

For example, new application features are available in Siebel Self Service Portal for Siebel Open UI and Siebel Partner Portal for Siebel Open UI. For more information about these new applications, see "Siebel Business Applications That Require Siebel Open UI". See also "Related Information About Deploying Siebel Open UI".
Continue using the standard interactivity applications.

This topic is part of "Migration Tasks for Siebel Open UI".