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
Environments: Development, production test, production.
Platforms: Windows, UNIX, IBM z/OS.
This task prepares workflows for upgrade.
To prepare workflow processes for upgrade
Deactivate all workflow processes.
This ensures that run-time event actions associated with old workflows are cleaned up properly.
Verify that all tasks with the status of QUEUED are removed from S_SRM_REQUEST.
The upgrade process does not clear these.
Related Topic
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.
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:
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.
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.
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
In Siebel Tools, select the Table object.
In the list applet, query for
“*
in the Seed Filter column.The query returns a list of tables containing seed data.
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
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
-
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 tableownerPassword
is the tableowner passwordODBCDataSource
is the data source of the databaseOutputFileLocation
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
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
Perform a partial synchronization for mobile users, sending all transactions to the server database.
Verify that Siebel Mobile Web Clients have synchronized and that all changes have been merged into the server database as follows:
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
.Check the mobile users Remote Status view and resolve any insert conflicts.
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.
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.
To prevent synchronization of Siebel Mobile Web Clients with the database server, stop or disable all Siebel Remote components on all Siebel Servers.
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.
To prepare address data for upgrade
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.
Review the output generated by the script.
If the output contains records with duplicate row IDs, then use Siebel Enterprise Integration Manager or the application to delete unwanted records.
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
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
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.
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.