4Application Planning for a Siebel Upgrade
Application Planning for a Siebel Upgrade
This chapter provides information on Siebel Business Applications and issues to consider when upgrading your Siebel database. This chapter includes the following topics:
Upgrade Planning for Multilingual Siebel Deployments
Environments: Development, production test, production.
Platforms: Windows, UNIX, IBM z/OS.
As of Siebel CRM 8.0, the upgrade process upgrades both the primary (base) language and all deployed languages.
The development and production upgrep process does the following for the primary language and all deployed languages:
(Development upgrep). Imports user interface strings into the Prior Standard Repository, New Customer Repository, and New Siebel Repository.
Imports seed data into the database.
In the S_LST_OF_VAL table, an SQL script activates all newly imported records and configures them to support multilingual lists of values (MLOVs). LOVs remain enabled for the primary language.
No language-related manual tasks are required to upgrade the deployed languages, except where noted.
Validation
Prior to starting a development or production upgrep, you must have installed the new release’s language packs for all deployed languages.
The Database Configuration Utilities validate deployed languages by comparing the status of language packs installed on the Siebel Server with the language IDs of records in the S_LST_OF_VAL table. If there are language IDs in S_LST_OF_VAL but no corresponding deployed language on the Siebel Server, then the validation fails and you cannot continue the upgrade.
Prior to starting a development or production upgrep, you must review the records in S_LST_OF_VAL, using Siebel Tools. Remove or deactivate records for languages that you do not have deployed.
For more information, see Running the Siebel Database Configuration Wizard on Windows or Running the Siebel Database Configuration Wizard on UNIX, depending on your operating system.
Restrictions
The following restrictions apply to multilingual upgrades:
Installed languages must be deployed. If you have installed a language but not deployed it, then the language will not be upgraded.
A deployed language is one where you have installed the language pack, imported the user interface strings into the Siebel Repository, imported the seed data into the database, activated the seed data records added to S_LST_OF_VAL, and configured the records for MLOVs.
You cannot select which languages to upgrade. The Upgrade Wizard upgrades all deployed languages.
You cannot add or remove a language during an upgrade. If you want to add a language that is not currently deployed, then do so after the upgrade. For more information on adding new languages, see Siebel Global Deployment Guide and Siebel Installation Guide.
Upgrade Planning for Language String Migration
Upgrades from: All Supported Siebel releases.
Environments: Development, production test, production.
Databases: All databases.
Locale-specific language values can change from one release of Siebel Business Applications to another. Some ENU values shipped with your upgrade might no longer map to language strings from your previous release. For instance, in a German environment, the English word Individual mapped in previous releases to the German word Einzelperson, but in the subsequent release now maps to the German word Individuell. To ensure correct data migration, it is advised that you review your previous upglocale.lang_code file against the current file of the same name to determine whether any language strings require changes to ensure that they properly map when the upgrade utilities are run.
Upgrade Planning for Siebel Unicode Support
Environments: Development, production test, production.
For Western European languages and Japanese, Siebel Business Applications support both non-Unicode and Unicode code pages. For all other supported languages, Siebel Business Applications support only Unicode code pages.
Unicode is recommended if your installation uses Siebel Email Response, correspondence, or similar functionality, particularly if content is generated on a separate system.
This is because Siebel Business Applications use Unicode internally. If the RDBMS is not using Unicode, then Siebel Business Applications convert content from Unicode to the database code page. Using a Unicode code page for the database prevents string conversion problems on text content.
Before converting to Unicode, your encryption method must be RC4 or AES.
For Siebel language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.
For information about Unicode and global deployment for Siebel Business Applications, see Siebel Global Deployment Guide.
For information on upgrading to RC4 or AES encryption, see Siebel Security Guide.
Planning Considerations for the Unicode Migration
Migrations to Unicode require the assistance of Oracle’s Advanced Customer Services.
Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services to migrate your upgraded database from a non-Unicode code page to Unicode. To perform the migration, you can use either database vendor native utilities or Siebel utilities.
If you are planning to migrate your upgraded application to Unicode, then consider the following points:
Database size increase. Migration to Unicode increases the size of your database. For this reason, you must allocate additional space for your database before migrating to Unicode. For more information, create a service request (SR) on My Oracle Support. Also, you can contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
IBM DB2 data truncation. Migration to Unicode might cause truncation of certain data in IBM DB2 databases. In the past, long columns with a type of varchar could have a maximum length of 16,383 characters. However, in Unicode, the maximum length of long columns with a type of varchar is 16,350. During the migration to Unicode, long columns of type varchar that exceed 16,350 are truncated. To prevent this, you can perform tasks to identify which data might be truncated and take appropriate measures before migration. For more information, create a service request (SR) on My Oracle Support. Also, you can contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services. See also Identifying IBM DB2 Long Columns for Truncation in a Siebel Upgrade.
IBM DB2 custom tablespace information. The upgrade does not preserve custom tablespace information for IBM DB2 databases. This presents a problem during your migration to a Unicode code page, because you must know which tables need to be re-created. You must modify the upgrade scripts to handle custom tablespaces.
For instructions about how to modify upgrade scripts to handle custom tablespaces, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
Third-party product integration. Migration to Unicode might affect integration with third-party systems. For more information, create a service request (SR) on My Oracle Support. Also, you can contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
Environment code pages. You cannot use a non-Unicode code page for your development environment, and then later migrate to Unicode for your production environment.
Supported Types of Unicode
The current release supports two types of Unicode:
UTF-8. UTF-8 uses the same encoding for Western European languages. It occupies one byte for Western European languages and up to three bytes for some Asian languages, such as Japanese.
UCS-2. UCS-2 is supported for IBM DB2 and Microsoft SQL Server databases. UCS-2 does not map one-to-one with Western European languages. It occupies two bytes for all languages.
Upgrade Planning for Siebel RC4 or AES Encryption
Upgrades from: All Supported Siebel releases.
Environments: Development, production test, production.
Databases: All databases.
Platforms: Windows and UNIX only.
As of Siebel Innovation Pack 2014, Siebel CRM no longer supports RC2 encryption. Siebel 7.7 introduced support for the AES encryption method, the government standard for secure applications. Siebel Business Applications continue to support RC4 and AES data encryption.
Data that used the standard encryptor (supported in some prior releases) or RC2 cannot be read by applications in the current release. You must upgrade your encryption method to RC4 or AES.
Use the Encryption Upgrade Utility to convert unencrypted data and data that was encrypted using the standard encryptor or RC2 to the RC4 or AES encryption method. Also run the Encryption Upgrade Utility to upgrade to stronger encryption levels. To upgrade your encryption method, see Siebel Security Guide.
During the upgrade process, the encryption upgrade is run during the database upgrep and upgphys process. During the database upgrep upgrade, only the logical definition is updated. During the database upgphys process, only the physical data is updated. During the upghys encryption upgrade, the .cfg file could cause errors. The .cfg file must be updated correctly before running the Key Database Manager utility.
For more information on updating the .cfg file before running the Key Database Manager, see 2104053.1 (Article ID) on My Oracle Support.
Upgrade Planning for Siebel Web Template Files and Style Sheets
Environments: Development environment only.
Siebel Web templates and Siebel Web template files (SWT files) help define the layout and formatting of the user interface, such as views, applets, and controls. The Siebel Web Engine in the Siebel Server uses the Siebel Web templates to build Web pages, which it then forwards to the Siebel Application Interface.
A Siebel Web template file contains regular HTML or XML tags interspersed with Siebel tags. Siebel tags are prefixed by swe and contain placeholders for user interface objects such as controls and data. HTML formatting tags are defined in cascading style sheets (such as main.css).
When you install Siebel Application Interface or Siebel Tools, you receive new style sheet files. The upgrade process does not use your existing files. If you have manually customized your Siebel Web template files or style sheet files, then you must evaluate whether to reimplement these customizations in the new Siebel Web template files and style sheet file.
Observe the following planning guidelines for reimplementing customizations:
Resolve any user interface problems related to object definitions in the Siebel Tools repository first. While doing so, review the areas of the new user interface where you plan to implement Siebel Web template file customizations.
Evaluate existing customizations to Siebel Web template files, and decide which ones to reimplement. Changes to the user interface in the new release might make some customizations obsolete.
Document why each customization was reimplemented. This reference will help you evaluate customization issues later.
Use formal change control for managing versions of the Siebel Web template files and style sheet files. This allows you to maintain orderly distribution of the files to developers.
Applets typically have a separate Siebel Web template file for each applet mode. Customize all the mode Siebel Web template files for an applet at the same time. This allows you to verify applet functionality in a single test pass in the user interface.
Individual Siebel Web template files are typically used by multiple screens, views, or applets. Set up formal test plans that verify customizations are correct across all user interface objects that use each Siebel Web template file. This reduces the amount of time required to verify customizations and prevents unintended changes to the user interface.
Reimplement style sheet customizations in two passes. On the first pass, implement only those changes required to address user interface usability issues. On the second pass, implement the remaining style sheet customizations after Siebel Web template customizations are complete. This shortens the time required to resolve functional problems in the user interface.
All Siebel Web template files must be copied into one directory and you must provide the same folder path during the upgrade process. The style sheet files must be copied to the Siebel Application Interface installations in the environment. The files must also be included in upgrade kits sent to remote sites.
Siebel Web template files have an .swt file extension and are located in the webtempl directory in both the Siebel Server and Siebel Tools installations.
The style sheet files are located in the installation directory of Siebel Application Interface and Siebel Tools (Windows path syntax). For example:
Siebel Application Interface: SIEBEL_AI_ROOT\applicationcontainer\webapps\siebel\files
Siebel Tools: SIEBEL_TOOLS_ROOT\public\files\main.css
The steps for reimplementing customizations to these files and copying them to new environments are included in the upgrade process topics in Overview of Performing a Siebel Database Upgrade
For information on how Siebel Web templates and style sheet files work, see Configuring Siebel Business Applications and Configuring Siebel Open UI.
In Siebel Innovation Pack 2015 and later, a script is executed that migrates data from Siebel Web template files into table-based content in the Siebel database. For Incremental Repository Merge, Siebel Web template migration occurs during the upgrep operation. For full upgrades, this migration occurs during the upgphys operation.
For more information, see Converting Siebel Web Templates with the SWT to OD Conversion Utility.
Upgrade Planning for Siebel Access Control
Environments: Development, production test, production.
Platforms: Windows, UNIX, IBM z/OS.
Access control refers to all mechanisms that control visibility of screens, views, and data within Siebel Business Applications. Access control includes, but is not limited to, positions, responsibilities, organizations, and access groups.
To implement access control within your Siebel Business Applications, your Siebel administrator creates relationships between people and resources (a more general term for data that includes views and functionality). These relationships or policies are authorizations. Both people and resources can be grouped and placed in hierarchies to simplify administration.
External users, such as customers and channel partners, can be assigned varying access levels that control visibility of data and application functionality. When planning access policies, consider the following:
The complexity of access control policies (one data item or group of data items can be accessed by one or many users or groups, but not by all).
The amount of content that is distributed by the Siebel Business Applications, including Master data (data that is static and referential, such as Products) and Customer data (data that is created and managed by users of applications, such as Opportunities).
The number of users and entities that access the data. Also consider the complexity of relationships between users (partners, competitors, browsers, customers).
For more information on access control, see Siebel Security Guide.
Upgrade Planning for Migrating Siebel Address Data
In previous releases, address data was stored as follows:
The relationship between person and address was 1:M and was stored in the table S_ADDR_PER.
The relationship between account and address was 1:M and was stored in S_ADDR_ORG.
Both tables included a column ADDR_NAME, which is a computed value based on other attributes in the address table.
The user key for S_ADDR_PER included PER_ID and ADDR_NAME.
How Address Data Is Preserved
Because PER_ID is no longer part of the user key for S_ADDR_PER, the ADDR_NAME must be unique for all records.
It is possible that records within or across S_ADDR_ORG and S_ADDR_PER could have the same ADDR_NAME. If this occurs, then the ADDR_NAME for one of the records is preserved, and the upgrade process appends the ROW_ID to ADDR_NAME for the others. This prevents records from being deleted and preserves all records from both tables.
How to Manage Address Migration
You must perform the following tasks to migrate address data:
Before upgrading the database, you must run a script to identify records that have the same ROW_ID between S_ADDR_PER and S_ADDR_ORG. You must eliminate duplicate row IDs.
You must evaluate whether to modify upgrade scripts to migrate address data in custom extension columns in S_ADDR_PER and S_ADDR_ORG. Review the new schema and determine whether your custom columns can be mapped to standard columns. If no matching standard columns exist, then create new columns on the target tables. During the database upgrep, you do this after running the Database Configuration Utilities but before running the Upgrade Wizard.
After the upgrade is complete, review the records in S_ADDR_PER and eliminate duplicate and obsolete records.
To manage address migration, follow the steps in Process of Upgrading a Siebel Production Test Environment. Each of the address migration tasks is included as a step in this process. Each step refers you to a procedure for performing the task.
Upgrade Planning for Siebel Workflow Designer
Platforms: Windows, UNIX, IBM z/OS.
As of Siebel CRM 8.x, the repository merge process preserves customizations you have made to seeded workflows. A seeded workflow is a Workflow Process object and all child objects shipped as part of a Siebel release.
Special premerge and postmerge steps have been added to the regular repository merge to allow merging customer-modified seeded workflows:
Workflow premerge. When you start a repository merge, this step runs and prepares customer-modified seeded workflows in the Prior Customer Repository for the repository merge.
Repository merge. After the workflow premerge completes, the main repository merge runs. The repository merge identifies modifications you have made to seeded workflows in the Prior Customer Repository. It then copies the modifications to the corresponding seeded workflows in the New Customer Repository.
Workflow postmerge. After the main repository merge completes, the workflow postmerge runs and sets workflow versions in the New Customer Repository.
All three parts of the repository merge display in the status bar of the Merge Repositories dialog box when you perform a repository merge.
The workflow merge steps fit into the overall flow of a repository merge as follows:
Repository merge starts
Workflow premerge
Main repository merge
Workflow post-merge
ICL merge steps (If this is an ICL merge)
Merge ends
Run the postmerge utilities
Workflow Premerge
When you start the repository merge, the workflow premerge step runs and prepares customer-modified seeded workflows for the repository merge.
If the workflow exists in both the Prior Customer Repository and New Siebel Repository, and the version number in the Prior Customer Repository is greater than 0, then the workflow is customer-modified.
For these workflows, the premerge process makes the following changes:
Deletes version 0 of the customer-modified seeded workflow in the Prior Customer Repository.
In the Prior Customer Repository, copies the most recent version of the customer-modified seeded workflow and sets the copy’s version to 0.
The most recent version of the workflow is the one with the highest version number and Status indicates Completed. This is called the version n workflow.
Sets the copy’s Status as Completed.
The workflow premerge creates a version 0 copy of version n in the Prior Customer Repository because the merge process requires that workflows it compares between repositories must have the same name, must be version 0, and must have Status as Completed.
Repository Merge
The main repository merge compares workflows in the Prior Customer Repository, Prior Siebel Repository, and the New Siebel Repository:
Customer-Modified seeded workflows. The repository merge copies the modifications to version 0 of the workflow to the Prior Customer Repository to the same workflow in the New Customer Repository. The merge also copies versions 1 through n of the workflow to the New Customer Repository.
An exception is when a workflow’s object attributes are different in all three compared repositories. This means the object is both customer-modified and has also changed in the new release. This causes a merge conflict.
The repository merge handles workflow attribute conflicts in the same manner as other objects. The merge process typically resolves merge conflicts in favor of the New Siebel Repository. You can review workflow-related attribute conflicts in the Application Upgrade Attribute List screen in Siebel Tools.
If you modify a seeded workflow by deleting any of its child objects, then the merge process does not delete the child objects in the New Customer Repository. After the merge, you must review child objects and delete them as desired.
Unmodified seeded workflows. If the workflow exists in both the Prior Customer Repository and New Siebel Repository, and the highest version level is 0 in the Prior Customer Repository, then the workflow is unmodified.
After the merge, the seeded workflow in the New Customer Repository will be the one that shipped with the new release.
Customer-Created workflows. If the workflow exists in the Prior Customer Repository but not the Prior Siebel Repository, then the workflow is customer-created. The repository merge copies all versions of customer-created workflows to the New Customer Repository.
Customer-Deleted Workflows. If the workflow exists in the Prior Siebel Repository but not the Prior Customer Repository, then the workflow is customer-deleted. The repository merge does not delete the workflow from the New Customer Repository. After the merge, you must review these workflows and delete them as desired.
Obsolete seeded workflows. If the workflow exists in the Prior Siebel Repository but not the New Siebel Repository, then the workflow is obsolete. The repository merge does not copy obsolete seeded workflows from the Prior Customer Repository to the New Customer Repository unless they are customer-modified. After the merge, you must review customer-modified, obsolete workflows and delete them as desired.
Workflow Postmerge
The workflow postmerge step runs after the main repository merge completes and does the following for seeded workflows that are customer-modified:
Changes the version of the workflow from 0 to n + 1 and sets the n+1 version’s workflow status to In Progress.
For example, if the most recent version of customer-modified Workflow A in the Prior Customer Repository is version 3, then the merged version in the New Customer Repository will be version 4 and will have Status indicates In Progress.
Copies version 0 of the workflow from the New Siebel Repository to the New Customer Repository. This reinstates the version 0 seeded workflow that shipped with the new release.
Status of Customer-Modified Workflows After the Merge
After the whole repository merge is complete, customer-modified seeded workflows appear as follows in the New Customer Repository:
Version 0. This is the seeded workflow that shipped with the new release.
Versions 1 through n. These versions are copied intact from the Prior Customer Repository.
Version n+1. This is the new merged workflow version. It is a combination of the seeded workflow that shipped with the new release and the modifications contained in version n in the Prior Customer Repository.
Logging
Workflow premerge and postmerge. The workflow premerge and postmerge steps write to the same log file:
SIEBEL_TOOLS_ROOT\bin\merge0_ver.txt
Each time you run the merge process, the name of the merge0_ver.txt file is incremented, for example to merge1_ver.txt.
If the log file contains the error IDS_ERR_DEV_MRG_PREMERGE_FAILED, then this means that the premerge step could not delete one or more version 0 seeded workflows. This causes the main merge process to be unable to merge the customer-modified seeded workflow into the New Customer Repository. You must manually reimplement customizations to these workflows. You need not rerun the repository merge.
If the log file contains postmerge errors, then create a service request (SR) on My Oracle Support, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
Main repository merge. The main repository merge logs workflow-related messages to the standard merge log file, merge0.txt. If you find workflow-related errors in this log file, then create a service request (SR) on My Oracle Support, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
The main repository merge log file is located in the same directory as the log file for the workflow premerge and postmerge steps.
Upgrade Planning for Mobile Devices in the Siebel Environment
Platforms: Windows, UNIX, IBM z/OS.
Before the upgrade, verify that mobile devices are running an operating system supported by your version of Siebel CRM. Also, verify that third-party software is the correct version. For more information, see the Certifications tab on My Oracle Support.
After the upgrade, you must enter any mobile device-related application configuration changes into the mobile device administration screen.
Mobile Application Upgrade
Mobile applications do not upgrade automatically. Users might need to download the latest version of the application after an upgrade to the current release. It is not necessary to uninstall the application first.
Upgrade Planning for Resonate Central Dispatch in the Siebel Environment
Platforms: Windows, UNIX, IBM z/OS.
Support for Resonate Central Dispatch is discontinued as of Siebel CRM version 7.7. It has been replaced by a load balancing module that is included in the Siebel Web Server Extension and its successor module, Siebel Application Interface. For a description of the load balancing module and information about requirements for third-party HTTP load balancers, see Siebel Deployment Planning Guide. For information on configuring load balancing, see Siebel Installation Guide.
Upgrade Planning for Siebel String Translation
Platforms: Windows, UNIX, IBM z/OS.
Based on the language for the Siebel upgrade process, the Siebel upgrade scripts are created accordingly.
When the Database Configuration Wizard is started, the sqlgen utility generates the Siebel upgrade scripts based on the information located in the upgfile.xml file. When the Database Configuration Wizard completes, SQL scripts are generated, and replace the placeholders in the upgfile.xml with the language-specific values located in the DBSRVR_ROOT/lang_code/upglocale.lang_code file.
In the following example, the locale file is upglocale.fra, for a FRA based installation. The upgfile.xml contains the following statement:
update S_DOC_QUOTE
Set the QUOTE_SUB_TYPE_CD value to '<XTL_STRING>Private</XTL_STRING>'
Where the QUOTE_TYPE equals '<XTL_STRING>Template</XTL_STRING>'
The placeholders <XTL_STRING>Private</XTL_STRING> and <XTL_STRING>Template</XTL_STRING> are values that the sqlgen utility changes during the upgrade. The XTL_STRING values are replaced based on what the sqlgen utility locates as a match for the Private and Template strings in the upglocale.fra file, located under dbsrvr/FRA. For this example, the FRA base language dictates Template = Modèle and Private = Privé.
Upgrade Planning for Siebel Personalization
Access control is based on primary responsibility name. If you have defined conditional expressions for applets in the Administration - Personalization screen, then plan to review these after the upgrade and verify that they use Primary Responsibility name. For more information on access control, see Siebel Security Guide. For more information on personalization management, see Siebel Personalization Administration Guide.
Upgrade Planning for Siebel Pricer and Order Management
Data associated with Siebel Pricer features are upgraded as shown in the following table. These upgrade changes apply to upgrades from any Siebel CRM version 7.x release.
Table How Siebel Pricer Features Are Upgraded
| Feature | How This Feature Upgraded |
|---|---|
Price lists and cost lists |
Automatically upgraded as part of price list |
Customizable product pricing |
Automatically upgraded as part of price list |
Service pricing (based on covered product) |
Automatically upgraded as part of price list |
Volume discount |
Automatically upgraded |
Attribute pricing |
Automatically upgraded as attribute adjustment |
Pricing model
|
Not automatically upgraded. Must be redesigned and reimplemented as pricing procedures. Bundle factor definitions are upgraded to aggregate discounts and aggregate discount sequences. |
Siebel Pricer API user properties for internal or external application integration are also obsolete. After the upgrade, you must reimplement integrations using pricing procedures, signals, variable maps and other features of the order management infrastructure.
For information on the new Pricer architecture, on application integration, and on order management infrastructure, see Siebel Pricing Administration Guide and Siebel Order Management Infrastructure Guide.
For a scenario that describes how to reimplement Siebel CRM version 7.x pricing models, see 473908.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 639.