9Preparing Siebel Application Data for Upgrade

Preparing Siebel Application Data for Upgrade

This chapter provides guidelines for preparing your Siebel Business Applications data for the Siebel database upgrade. This chapter includes the following topics:

• Preparing Siebel Workflow Processes for Upgrade

• Preparing Siebel Customized Seed Data for Upgrade

• Migrating Siebel Household Data

• Preparing Siebel Mobile User Data for Upgrade

• Preparing Siebel Address Data for Upgrade

• Preparing Siebel Territory Management Rules for Upgrade

• Preparing Siebel Customizable Product Data for Upgrade

Preparing Siebel Workflow Processes for Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

This task prepares workflows for upgrade.

Caution: In order to be preserved after you perform a full upgrade or run incremental repository merge, any paused workflow processes and task-based UIs must be completed first, before you perform these upgrade operations.

To prepare workflow processes for upgrade

1. Deactivate all workflow processes in the Siebel client as follows:

   1. Navigate to the Administration - Business Process screen, Workflow Deployment view, then the Active Workflow Processes subview.

   2. Click Menu and then click Deactivate Process for each workflow process that you want to deactivate.

   Doing this ensures that run-time event actions associated with old workflow processes are cleaned up properly.

   If there are multiple versions of a workflow process, as in the case of customer modified workflow processes for example, then you must deactivate all versions of the workflow process except the most recent version with a Status of Completed in Siebel Tools.

   For more information on how to deactivate a workflow process including more than one workflow process instance, see Siebel Business Process Framework: Workflow Guide.

2. Verify that all tasks with the status of QUEUED are removed from S_SRM_REQUEST.

   The upgrade process does not clear these.

For more information on how workflow records are handled during and after a repository merge, see Upgrade Planning for Siebel Workflow Designer.

About Workflow Processes in Siebel Repository

Workflow processes are workspace-versioned in Siebel 17.x, Siebel 18.x and later releases. However, note the following about workflow processes in Siebel Tools:

• As of Siebel CRM 19.7 Update, the latest version of a workflow process (where Status is Completed and Inactive is set to False) is editable. Older versions of workflow processes (where Status is Not in Use and Inactive is set to True) are read-only and should not be used.

• In releases prior to Siebel CRM 19.7 Update, to activate workflow processes post upgrade, including the most recent version of the workflow process with a Status of Completed or any other workflow process that you deactivated before upgrade, you must do the following in Siebel Tools:

  • Rename and inactivate the old versions of the workflow process that are not in use (where Status is Not In Use).

    To inactivate a workflow process in the Repository in Siebel Tools, set the Inactive property to True.

  • Activate the most recent version of the workflow process that you want to use (where Status is Completed).

    To activate a workflow process in the Repository in Siebel Tools, set the Inactive property to False.

• A Single workspace cannot have multiple pre-Siebel Innovation Pack 2017 versions of the same workflow process in Siebel Tools active. The workflow versioning that existed prior to Siebel Innovation Pack 2017 is eliminated and workflow processes now have workspace versioning just as other objects do. As a result, older workflow versions must be inactivated and are available only as read-only workflow processes.

Preparing Siebel Customized Seed Data for Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

Modified seed data are not upgraded, even if the upgraded seed data are required for an application to run normally, with the following exceptions:

• If you have modified seed data through the user interface or through Siebel Enterprise Integration Manager, then the repository merge preserves the modifications using the same logic as for other repository objects.

• As of Siebel CRM 8.0, customizations to seeded workflows in the Prior Customer Repository are merged into workflows in the New Customer Repository by the repository merge process.

Before starting the upgrade, evaluate whether you must retain your seed data modifications. If practical, consider discarding the modifications. After the upgrade, you can reimplement those modifications that do not interfere with operation of applications.

Seed data are records provided in the Siebel database tables as part of a release. Seed data provides information needed to run a Siebel application. Examples of seed data are the values in a List of Values (LOV) definition, default mappings of views to responsibilities, and predefined queries.

Note: The paragraphs that follow provide a generalized description of how seed data for U.S. English (ENU) is imported during the upgrade process, including whether existing data is replaced. This description does not apply to all types of seed data, including seed data for non-ENU languages.

The ROW_ID value for ENU seed data records provided in a release begins with 0 (zero). In addition, these records have a default LAST_UPD value of 1980-01-01. The LAST_UPD column stores the date when the record was last updated.

If you modify an ENU seed data record, then the value of LAST_UPD is changed from 1980-01-01 to the date the modification was made. If you add a new seed data record, then the ROW_ID value does not begin with 0, and the LAST_UPD value is the record creation date.

When you perform the upgrep part of the upgrade, the dataimp utility upgrades ENU seed data records as follows:

1. For records where the ROW_ID value begins with 0, it erases ENU seed data records where the value for LAST_UPD is 1980-01-01, unless prevented by scripting.

2. Dataimp replaces these records with those contained in seed data files included in the release. In the new records, the value for LAST_UPD is 1980-01-01.

3. Dataimp does not erase and replace seed data records where the value for LAST_UPD is later than 1980-01-01. Instead, for each of these records, dataimp writes an error to the log file. The error is benign and does not cause the upgrade to fail. Use these error entries to verify which seed data records were not changed.

For ENU seed data records you have modified, you can discard the modifications by changing the value of LAST_UPD to 1980-01-01. This causes dataimp to replace these records with those from the new release. For seed data records you have created, the upgrade process retains these records.

About Deactivated LOVs

If you deactivated any standard Siebel LOVs in your prior release, then you must, before executing the UPDATE statements on the S_LST_OF_VAL table, make sure to reactivate the corresponding standard Siebel LOVs through the prior release’s user interface. Standard Siebel LOVs that were manually deactivated through the Siebel user interface (by changing the Active value to N) will have a ROW_ID value beginning with 0, but the LAST_UPD value will no longer be 1980-01-01. For more information, see Running the Siebel Database Configuration Wizard on Windows or Running the Siebel Database Configuration Wizard on UNIX.

Discarding Seed Data Modifications

Use the following procedure to discard seed data modifications.

To discard seed data modifications

1. In Siebel Tools, select the Table object.

2. In the list applet, query for “* in the Seed Filter column.

   The query returns a list of tables containing seed data.

3. Use one of the following scripts to set LAST_UPD to 1980-01-01 for customized seed data records in these tables. In the scripts, tablename is the name of table containing seed data.

   Database	Script
   Oracle Database	UPDATE tablename SET LAST_UPD = TO_DATE('1980-01-01', 'YYYY-MM-DD') WHERE ROW_ID LIKE '0%' AND LAST_UPD > TO_DATE('1980-01-01', 'YYYY-MM-DD')
   IBM DB2 and IBM DB2 for z/OS	UPDATE tablename SET LAST_UPD = TIMESTAMP('1980-01-01-00.00.00') WHERE ROW_ID LIKE '0%' AND LAST_UPD > TIMESTAMP('1980-01-01-00.00.00')
   Microsoft SQL Server	UPDATE tablename SET LAST_UPD = CONVERT(DATETIME,'1980-01-01') WHERE ROW_ID LIKE '0%' AND LAST_UPD > CONVERT(DATETIME,'1980-01-01')

Related Topics

About the Siebel Database Upgrade Log Files

About the Siebel Repository Merge

Upgrade Planning for Siebel Workflow Designer

Migrating Siebel Household Data

Upgrades:Applies to Siebel Financial Services upgrades from 7.x that have retained the Siebel 6.x form of household associations.

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

Siebel CRM version 7.0.x introduced the Party model. This changed the way relationships between households and entities, such as activity and claim, are handled.

You have two options for migrating household data:

• Migrating household relationships to the Party model (recommended)

• Retaining the Siebel 6.x form of household relationships

Migrating Household Relationships to the Party Model

To check household data integrity and support migration of household data to the Party model, you must run the household verification script (HH_MIG_populate.sql).

The script verifies that at least the same number of entities will belong to a household after the upgrade as belong to it before the upgrade.

The household verification script makes the following assumptions:

• A household has at least one contact.

• The primary contact of a Policy/Financial Account is one of the contacts associated with this Policy/Financial Account.

• The primary contact of a Claim is one of the contacts associated with this Claim.

• The primary contact of an Opportunity is one of the contacts associated with this Opportunity.

• The primary contact of a Company is one of the contacts associated with this Company.

The script populates a temporary table with data, TEMP_HH_OBJ_MIG and generates a report based on an output file. Output is in the form of row IDs. The script verifies that every household associated with an entity includes a contact associated with that entity.

If there is no output, then this means data integrity is good, and no action is required. If you receive output, then you must examine the relationship between contacts and households.

To run the household verification script

1. Run one of the following household verification scripts as required:

   Windows:

   odbcsql /U Tableowner /P Password /S ODBCDataSource /a /c REM /separator / /O OutputFileLocation\HH_Mig_populate.txt 
   /L LogFileLocation\HH_Mig_populate.log ScriptLocation\HH_Mig_populate.sql /v y 
   

   UNIX:

   odbcsql /U Tableowner /P Password /S ODBCDataSource /a /c REM /separator / /O OutputFileLocation/HH_Mig_populate.txt 
   /L LogFileLocation/HH_Mig_populate.log ScriptLocation/HH_Mig_populate.sql /v 
   

   where:

   • Tableowner is the tableowner

   • Password is the tableowner password

   • ODBCDataSource is the data source of the database

   • OutputFileLocation is the location of the output file:

     • Windows: SIEBEL_ROOT\log\HH_Mig_populate.txt

     • UNIX:$SIEBEL_ROOT/log/HH_Mig_populate.txt

   • LogFileLocation is the location of the log file:

     • Windows: SIEBEL_ROOT\log\HH_Mig_populate.log

     • UNIX: $SIEBEL_ROOT/log/HH_Mig_populate.log

   • ScriptLocation is the location of the script:

     • Windows: DBSRVR_ROOT\database_platform\HH_Mig_populate.sql

     • UNIX: DBSRVR_ROOT/database_platform/HH_Mig_populate.sql

   Windows example:

   odbcsql /U Tableowner /P Password /S ODBCDataSource /a /c REM /separator / /O 
   C:\sea7xx\siebsrvr\Log\HH_Mig_populate.txt /L 
   C:\sea7xx\siebsrvr\Log\HH_Mig_populate.log 
   C:\sea7xx\dbsrvr\DB2\HH_Mig_populate.sql /v y 
   

2. If you receive output, then review the temporary table and check the following for each contact. Make corrections as needed:

   • Contact is correct and household is incorrect.

   • Contact is incorrect and household is correct.

   • Contact is incorrect and household is incorrect.

Preparing Siebel Mobile User Data for Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

This topic applies primarily to developers running the Siebel Mobile Web Client in the development environment and to end users in the production environment. This topic applies to the production test environment only if it has Siebel Mobile Web Client users.

After synchronizing, mobile users must make no further changes to their local databases until the upgrade has been completed. Any changes made during the upgrade are lost when they are reinitialized following the upgrade.

Complete the following steps before beginning the upgrade of either a development environment or a production environment. For additional information on these steps, see Siebel Remote and Replication Manager Administration Guide and Siebel System Administration Guide.

To prepare Siebel Mobile Web client users for the database upgrade

1. Perform a partial synchronization for mobile users, sending all transactions to the server database.

2. Verify that Siebel Mobile Web Clients have synchronized and that all changes have been merged into the server database as follows:

   1. Check that no transaction files remain in the synchronization inbox and outbox for any mobile user. The synchronization inbox for each user is on the Siebel Server:

      Windows: SIEBEL_ROOT\docking\MOBILEUSERNAME

      UNIX: $SIEBEL_ROOT/docking/MOBILEUSERNAME

      Transaction files are in the format number.dx; for example, 00000023.dx.

   2. Check the mobile users Remote Status view and resolve any insert conflicts.

   3. Log onto a Siebel Business Application, such as Call Center, as the Siebel administrator. Use the Tasks view from the Administration-Server Management screen to make sure that each Transaction Merger task has successfully completed.

   4. Verify that Workflow Monitor and Workflow Action agents have processed all pending requests. If Workflow Manager has completed successfully, then the S_ESCL_REQ table must not have any rows.

3. To prevent synchronization of Siebel Mobile Web Clients with the database server, stop or disable all Siebel Remote components on all Siebel Servers.

4. Disconnect all Siebel Web Clients from the Siebel Server by stopping the appropriate Application Object Managers, as described in Siebel System Administration Guide.

Preparing Siebel Address Data for Upgrade

Upgrades:

• From Siebel CRM 8.0.x (SEA) to Siebel CRM 8.1.1.x (SIA)

• From Siebel CRM 8.1.x (SEA) to Siebel CRM 8.1.1.x (SIA)

• From Siebel CRM 7.8.2 (SEA) to Siebel CRM 8.1.1 (SIA)

Environments: Production test, production.

Databases: All databases.

At Siebel CRM version 7.7, the way address data is stored changed. To prepare for the revised storage scheme, you must verify that there are no records with the same row IDs within or across the tables S_ADDR_PER and S_ADDR_ORG.

Caution: There must be no duplicate row IDs in these tables or the upgrade will fail.

To prepare address data for upgrade

1. Run rpt_dup_addr_rowids.sql against the Siebel database. The script is located in the following directory:

   Windows: DBSRVR_ROOT\database_platform

   UNIX: DBSRVR_ROOT/database_platform

   In these paths, database_platform is the database type, for example DB2.

2. Review the output generated by the script.

3. If the output contains records with duplicate row IDs, then use Siebel Enterprise Integration Manager or the application to delete unwanted records.

4. After addressing all the duplicate row IDs, rerun the script and verify there are no more duplicates.

Related Topic

Preparing Siebel Territory Management Rules for Upgrade

Preparing Siebel Territory Management Rules for Upgrade

Upgrades from: Siebel 7.8.x.

Environments: Production test, production.

Territory rules management was introduced in Siebel CRM 7.8. As of Siebel CRM 8.0, territory rules cannot have overlapping effective date ranges. For example, the following two rules have overlapping effective date ranges:

Rule 1

Territory: A100

Account: XYZ Corp

Effective Start Date: 1/1/2006

Eff. End Date: 6/30/2006

Rule 2

Territory: A100

Account: XYZ Corp

Effective Start Date: 4/1/2006

Eff. End Date:

You must identify rules with overlapping effective date ranges and modify the rules to eliminate any overlap.

To prepare territory rules for upgrade

1. Run the following script against the database:

   Windows: DBSRVR_ROOT\common\TM_DupRuleCheck.sql

   UNIX: DBSRVR_ROOT/common/TM_DupRuleCheck.sql

   The script returns a list of all territory rules that have overlapping effective date ranges.

2. In Territory Management, revise rule effective date ranges to remove the overlaps.

Preparing Siebel Customizable Product Data for Upgrade

Environments: Production test, production.

Customizable Products in Work Spaces

The upgrade does not migrate unreleased customizable products in work spaces. If you want to migrate unreleased customizable products, then you must release them before the upgrade. This includes products with components and products with attributes.

Class Products

Verify that the Orderable flag is not set for class products. When this flag is not set, class products do not display as selectable products in quotes and orders after the upgrade.

The upgrade converts class products to a product and a product class. The upgrade sets the Product Class property for the product to Product Class.