Planning an Upgrade to Siebel 7 > Planning an Upgrade > Assessing Interface Migration Tasks >

Migrating Scripts

Scripts in Siebel 7 are classified as either browser scripts or server scripts. In general, server scripts are oriented towards data access and manipulation of business components, and browser scripts are oriented towards UI interaction. Scripts are migrated as either browser script, server script, or as a combination of the two. This is significantly different from prior versions.

You might need to modify scripts that reference event handlers or methods that are obsolete in the new version.

Understanding Browser and Server Scripts

Server Scripts are designed to enhance object-interactivity and integration with legacy applications as well as other services. Written in either Siebel VB (for Windows only) or Siebel eScript (for all supported Siebel Server operating systems), server scripts run on the Siebel Server. Server scripts are executed in the context of the Siebel Object Manager. Tasks performed by server scripts include the following examples:

• Creating an instance of a business component and updating a field.
• Creating an instance of a business component and executing a query that retrieves records of the business component.
• Retrieving data from or sending data to the database.

Browser scripts are designed to enhance user interactivity and desktop integration. Written in JavaScript, browser scripts run on the client's Web browser. Browser scripts are executed in the browser at run time. Tasks performed by browser scripts include the following examples:

• Displaying the progress of a lengthy process by displaying a progress bar or text on the Client Status bar.
• Enabling or disabling a control, or changing the background color of a control, based on a user condition.
• Interacting with the desktop applications such as a script that accesses personal contacts stored in Microsoft Outlook.

Browser scripts are written in JavaScript. Therefore, if you have written code in Siebel 6.X using Siebel VB or Siebel eScript, then you must rewrite it in JavaScript.

Migration Decision: Browser or Server Script?

If you are migrating from Siebel 5.x or 6.x, you must review the characteristics of each script to determine whether to migrate it as a browser script or a server script. Scripts that manipulate the user interface (UI) are typically migrated as browser scripts. Scripts that interact with the server are typically migrated as server scripts.

Table 6 describes script migration scenarios.

Carefully categorize scripts that access operating system functions as either browser scripts or server scripts. Re-evaluate references to OS-specific behavior or location to make sure they are interacting with the intended environment (the client computer or the Siebel Server).

The most common script migration scenario is for a script containing a combination of code that interacts with the UI and code that interacts with the server. Because you cannot pull a random block out of a script to place it on the browser, analyze whether part of a UI-interactive script needs to be moved to a browser script, and consider the sequence of execution—browser scripts are executed before server scripts.

A script containing code that only interacts with the server requires no development effort, but there are a few things that you should consider:

• Both Siebel VB and Siebel eScript are supported on server scripts.
• In Siebel 7, scripts written in different languages can coexist in the same repository, but a given object will only support one language at a time.
• If a script must be designed for a heterogeneous Web server, then you should write it as Siebel eScript, because eScript is platform independent while Siebel VB will work only on Windows environments.

A script containing code that only interacts with the UI is executed at the client machine before the request is submitted to the server.

A script that interacts with the desktop could be migrated as a server script if the logic is executed on the server away from the user's UI.

Determining Which Scripts to Migrate

To generate a list of repository differences between the standard Siebel 7 repository and your customized Siebel 5.x or 6.x repository, use the repository merge tool.

To use the repository merge tool for this purpose, specify only the Prior Customized Repository and the New Standard Repository fields, instead of specifying four repositories to perform a merge. (See the Upgrade Guide for the operating system you are using for instructions about how to perform a repository merge.)

Review the list of repository differences to determine which scripts to migrate.

Scripting Best Practices

The following scripting best practices can increase Siebel 7 performance and scalability, reduce deployment risks and costs, and help you maximize the return on your investment in Siebel 7 applications.

• Only use indexed fields in scripting queries.

  Most customers have thousands of accounts in the Siebel accounts table. By creating an index for those accounts—for example, tying all accounts to an account number—and then using that index field in the query script, you can increase query speeds considerably.

  If you use non-indexed fields, the server searches every record to find the desired account, leading to slower performance.

• Release Siebel objects to increase available memory.

  Because memory is allocated to Siebel objects used in scripts, you must release the objects to free the memory. To release Siebel objects, set the object to null in the script.

  Release dependent objects before releasing independent objects. If an independent object is released first, the dependent objects are not removed from memory, resulting in unpredictable outcomes.

  If you do not release Siebel objects, they are not removed from memory, resulting in memory overflow and leakage that affects performance and scalability. This issue often occurs in deployments of Siebel Call Center because business objects are constantly queried in the call center environment.

• Use the Option Explicit statement in all scripts.

  Use the Option Explicit statement to force a compile-time check for all declared variables and their data types.

  If you do not use the Option Explicit statement, variables with no declared data type are classified as variants, which use more memory. For example, if Option Explicit is not used in a Visual Basic script, an incorrectly classified string variable could receive numeric data, making debugging difficult.

• Make sure error handling is in place for all scripts.

  Even if a script does not manipulate Siebel objects and does not access the operating system, it may be changed in the future. Implement error-handling constructs for all scripts to make sure that errors are always handled no matter how or when the script is modified.

• Make sure that shared programs on the server are threadsafe.

  Make sure that programs shared by multiple Siebel clients can support requests from multiple clients at the same time. If you do not take this precaution, you might encounter concurrency and scalability problems.

• Do not overuse the "Immediate Post Change" property.

  Setting the Immediate Post Change property on a Field object forces the PreSetFieldValue event to execute. During the implementation design phase, decide which fields to validate immediately. Consider that setting a large number of fields to this property results in slower performance.

  The Immediate Post Change property is new in Siebel 7. To set the Immediate Post Change property in Siebel Tools, navigate to the Buscomp screen and open the Fields node.