| Siebel CRM Anywhere Administration Guide Siebel Innovation Pack 2016 E24720_01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Anywhere Administration Guide Siebel Innovation Pack 2016 E24720_01 |
|
Previous |
Next |
View PDF |
This chapter provides supplementary information for specific types of upgrade kits and other special circumstances in which Siebel Anywhere might be used. It includes the following topics:
"Example of Creating Multiple Upgrade Kits of the Same Type"
"Example of Constructing a Third Party Software Upgrade Kit"
When you must deliver additional language packs to Mobile or Developer Web Clients, follow these steps:
(Administrator) Install the new language packs and test them thoroughly.
For each language pack, create Siebel Client Executables__language-code upgrade kits using the package created in the previous step. Use the Delta Install type.
Distribute the upgrade kits to the appropriate configurations. You must have separate configurations for each combination of languages for your users.
This topic provides an example of a global deployment using Siebel Anywhere. The objective is to allow users to access and use the same application in different languages.
You have upgrade components for the languages you installed with your database server. You will map these to the applicable configurations. These configurations will be based upon the languages that different sets of users require to access the same application.
This example makes the following assumptions:
You have five sets of users for five different languages.
You will base your application on Siebel Call Center.
You will have five SRF files compiled, one for one each language.
You will have customer revisions, depending on the language.
You will use the same database.
Each user only uses the application in one language.
You will need:
Five components for the CFG files
Five components for the Siebel Repository Files (SRF)
Five components for Siebel Client Customer Revisions
Five configurations to distribute the upgrade kits
One component for Siebel Client Executables (base), including all applicable languages
For the records available, use values similar to those in the tables that follow.
|
Note: Substitute applicable language codes for ENU in these example records. |
Table 7-1 shows example values for defining a Siebel CFG File component.
Table 7-1 Example CFG Record in the Upgrade Component List View
| Field Name | Value |
|---|---|
|
Name |
Siebel Call Center CFG__ENU |
|
Component Type |
Siebel CFG File |
|
Min Version |
100 |
|
Max Version |
Leave this field blank |
|
Locate Method |
CFG |
|
Locate Information |
Siebel,ClientRootDir,bin\enu\uagent.cfg |
|
Version Method |
CFG |
|
Version Information |
Siebel,Version |
Table 7-2 shows example values for defining a Siebel Repository File component.
Table 7-2 Example SRF Record in the Upgrade Component List View
| Field Name | Value |
|---|---|
|
Name |
Siebel Client Repository File__ENU |
|
Component Type |
Siebel Repository File |
|
Min Version |
Leave this field blank |
|
Max Version |
Leave this field blank |
|
Locate Method |
CFG |
|
Locate Information |
Siebel,ClientRootDir,objects\enu |
|
Version Method |
SRF |
|
Version Information |
Siebel,RepositoryFile |
Table 7-3 shows example values for defining a Siebel Client Customer Revisions component.
Table 7-3 Example Siebel Client Customer Revisions Records in the Upgrade Component List View
| Field Name | Value |
|---|---|
|
Name |
Siebel Client Customer Revisions Siebel Client Customer Revisions__ENU |
|
Component Type |
Customer Revision |
|
Min Version |
Leave this field blank |
|
Max Version |
Leave this field blank |
|
Locate Method |
CFG |
|
Locate Information |
Siebel,ClientRootDir,bin\clntrev.cfg Siebel,ClientRootDir,bin\enu\clntenu.cfg |
|
Version Method |
CFG |
|
Version Information |
Siebel,Version |
Table 7-4 shows example values for defining a Siebel Client Configuration component.
Table 7-4 Example Client Configuration Record in the Upgrade Configurations View
| Field Name | Value / Comments |
|---|---|
|
Name |
Siebel Call Center ENU |
|
Configuration Type |
Siebel Client Configuration |
|
In the related components applet, make sure that the following components are included (assuming that you want to distribute all of these components): |
In the related components applet, make sure that the following components are included (assuming that you want to distribute all of these components): |
|
Siebel Call Center CFG__ENU |
Required |
|
Siebel Client Customer Revisions |
Required |
|
Siebel Client Customer Revisions__ENU |
Required |
|
Siebel Client Executables |
Required |
|
Siebel Quick Fix |
Required |
|
Siebel Client Executables__ENU |
Required for language-specific files using delta patch upgrade kits |
|
Siebel Client Repository File__ENU |
Required |
|
Siebel Database Schema |
Required |
|
Siebel Upgrade Wizard |
Required |
|
Third Party - File Attachment |
Not required |
|
Note: If you will be creating and distributing language-specific files using delta patch upgrade kits, then you must create a configuration for each language combination. For example, if a user installed both U.S. English (ENU) and French (FRA) on a system, then create a configuration with the components related to these two languages. For more information about multilingual deployments, see Siebel Global Deployment Guide. |
If you must distribute multiple custom files to different directories, then create an upgrade kit for each destination directory. Set the values of the Minimum Old Version and Maximum Old Version settings of the upgrade kits so that they create an unbroken sequence.
The following example uses the Customer Revision upgrade kit type (component type). The same logic can be used for other types of upgrade kits when you must distribute multiple upgrade kits of the same type.
Create the first upgrade kit (Upgrade Kit 1) in the usual manner. For example, set Minimum Old Version and Maximum Old Version to the null value, and set New Version to 1.
For the next upgrade kit, set Minimum Old Version to 1, Maximum Old Version to 1, New Version to 2, and so on.
If you have to skip a version number for some reason, then set the Minimum Old Version and Maximum Old Version values appropriately. Always set the value of Minimum Old Version to match the value of New Version for the previous active upgrade kit.
In this example, you need three upgrade kits, but Upgrade Kit 2 was skipped and replaced, because it contained one wrong file. The version information would be as shown in Table 7-5.
Table 7-5 Example of Version Settings for Multiple Upgrade Kits with One Skipped Upgrade Kit
| Upgrade Kit | Minimum Old Version | Maximum Old Version | New Version |
|---|---|---|---|
|
Upgrade Kit 1 |
Null |
Null |
1 |
|
Upgrade Kit 2 (This upgrade kit contains one wrong file, was never activated, and should be skipped.) |
1 |
1 |
2 |
|
Upgrade Kit 3 (This upgrade kit replaces Upgrade Kit 2.) |
1 |
2 |
3 |
|
Upgrade Kit 4 |
3 |
3 |
4 |
For more information about the version numbers used by Siebel Anywhere, see "About Siebel Anywhere Version Settings".
This topic describes the overall process of using Siebel Anywhere to update the Siebel database schema. Typical schema changes include:
Adding extension columns to Siebel base tables
Adding extension tables to the Siebel database
Creating or modifying indexes
To update the Siebel database schema, perform the following tasks:
Review the information presented in "Review What Happens During a Siebel Database Schema Upgrade".
Make and test the Siebel database schema changes in the development environment, using Siebel Tools. For more information about this step, see "Changing the Siebel Database Schema in a Development Environment".
Move the schema changes to the test environment, using the Siebel Database Configuration Wizard. For more information about this step, see "Moving Siebel Database Schema Changes Between Environments".
Create the necessary upgrade kits in the test environment. For more information about this step, see "Creating Upgrade Kits for Siebel Database Schema Changes".
Prepare the test Mobile Web Clients and Regional Node Servers for the schema changes. For more information about this step, see the following topics:
Install the schema changes on the test Mobile Web Clients and Regional Node Servers. For more information about this step, see the following topics:
Move the schema changes to the production environment, using the Siebel Database Configuration Wizard. For more information about this step, see "Moving Siebel Database Schema Changes Between Environments".
Create the necessary upgrade kits in the production environment. For more information about this step, see "Creating Upgrade Kits for Siebel Database Schema Changes".
Prepare the production Mobile Web Clients and Regional Node Servers for the schema changes. For more information about this step, see the following topics:
Install the schema changes on the production Mobile Web Clients and Regional Node Servers. For more information about this step, see the following topics:
This topic provides background information about what happens during a Siebel database schema upgrade.
This task is a step in "Process of Updating the Siebel Database Schema".
During Siebel database schema upgrades, new and changed objects are identified by comparing the current physical schema with the new virtual schema. Based on this comparison, Upgrade Wizard adds new objects and alters existing objects by using the following:
To create the new objects: create table, create index, and so on.
To alter the existing objects: alter table, alter index, and so on.
|
Caution: Downsizing existing columns is not recommended. Do not drop columns or tables. These operations can cause transactions that were created before the Siebel database schema change to be rejected, because data that was included in the earlier transactions might not fit into the new schema. |
Normally, the database does not allow downsizing a column that already contains data that could not fit into a new smaller column. If you downsize a column, then the column representation in the repository would be different from the physical schema. Under these conditions, Siebel Remote would fail, among other possible errors.
For example, after downsizing existing columns, one of the columns in the new database is shorter (it is created from the representation in the repository). Then, a local database is reextracted (this includes a new schema). After the Remote user synchronizes, initialization occurs. Upgrade Wizard first applies the new local database (including a new schema) to a Remote user's computer. Next, Upgrade Wizard applies any server transactions downloaded during synchronization.
If these transactions were generated before the Siebel database schema changed, then Upgrade Wizard tries to insert data that does not fit into the new column, causing the transaction to be rejected. Furthermore, if this occurs on a regional node, then the error might cause an outage.
The first step in deploying Siebel database schema changes is to make the schema changes in a development environment, using Siebel Tools. For more information about this step, see Configuring Siebel Business Applications.
This task is a step in "Process of Updating the Siebel Database Schema".
Keep track of whether your changes include creation or modification of views or applets. This information will affect later steps in the deployment.
Test the changes in the development environment before proceeding to the next part of the process.
When you are ready to move Siebel database schema changes from a developmental environment to a test environment, or from a test environment to a production environment, do not use Siebel Tools to make the changes. Instead, use the Migrate Repository option in the Siebel Database Configuration Wizard to migrate the entire Siebel Repository containing the schema changes to the new environment. For more information about this task, see Using Siebel Tools.
This task is a step in "Process of Updating the Siebel Database Schema".
Test the changes in the new environment before proceeding to the next part of the process.
The creation of a Siebel Database Schema upgrade kit has two consequences beyond the creation of the upgrade kit itself:
Schema changes from the logical schema (in Siebel Tools) are automatically applied to the physical schema of the HQ database.
The custom schema version number in the HQ database is automatically incremented by one.
This task is a step in "Process of Updating the Siebel Database Schema".
The number and type of upgrade kits that you need for deploying Siebel database schema changes depend on the kinds of changes you made to the schema:
Major schema changes. Siebel Anywhere is suitable for distributing minor Siebel database schema updates that have been created using database extensibility. If you are performing a major upgrade, then do not use Siebel Anywhere to distribute your changes.
For more information about performing major upgrades, see Siebel Database Upgrade Guide. For more information about extracting database changes for Mobile Web Clients, see Siebel Remote and Replication Manager Administration Guide, and for detailed information regarding database extensibility, see Configuring Siebel Business Applications.
Incremental schema changes. If your Siebel database schema changes are incremental (that is, if you have added tables, added columns, or changed the names of existing tables or columns), then you can create a Siebel Anywhere upgrade kit to upgrade Mobile Web Clients or a Regional Node Server. You do not need to reextract.
Preference for reextraction rather than Siebel Anywhere. It is possible to reextract databases for Mobile Web Clients and Regional Databases, rather than updating them using Siebel Anywhere, if you prefer. For more information, see Siebel Remote and Replication Manager Administration Guide.
Mandatory reextraction for nonincremental schema changes. If your Siebel database schema changes are nonincremental (that is, if you have removed or deactivated tables or columns, which are changes that are not recommended), then you must reextract all Mobile Web Clients and Regional Node Servers. Otherwise, synchronization might fail due to transactions that contain data for columns or tables that are no longer available. Reextraction makes it unnecessary to create a Siebel Database Schema upgrade kit.
After you define the upgrade kit or upgrade kits for your upgrade, you must activate and apply them as described in Chapter 6, "Activating, Applying, and Distributing Upgrade Kits." If you created both a Siebel Database Schema upgrade kit and a Siebel Repository File upgrade kit, then make sure that both are activated and applied before you proceed to the next part of the process.
In either a test environment or a production environment, it is recommended that you have your Mobile Web Client users synchronize before you distribute your Siebel Database Schema upgrade kit.
This task is a step in "Process of Updating the Siebel Database Schema".
|
Note: If any of your mobile users connect to a Regional Node Server, rather than the HQ Server, then the Regional Node Server must install the Siebel database schema changes before those mobile users can obtain and install the changes. |
After Mobile Web Client users have synchronized, you can distribute your active upgrade kits to an appropriate test or production configuration for your Mobile Web Clients. For more information about distributing upgrade kits, see "Distributing Upgrade Kits".
This topic describes how to prepare Siebel Regional Node Servers for Siebel database schema changes.
This task is a step in "Process of Updating the Siebel Database Schema".
Perform this task before you distribute your Siebel Database Schema upgrade kit to either test Regional Node Servers or production Regional Node Servers.
To prepare Siebel Regional Node Servers for Siebel database schema changes
Have your Regional Node Servers synchronize with the HQ Server.
Determine which configuration you will use to distribute the upgrade kit or upgrade kits to your Regional Node Servers.
The default configuration that ships with Siebel Business Applications is Siebel Regional Server. You can create your own configuration for Regional Node Servers to suit the particular needs of your organization. Make sure that the Siebel Database Schema component is associated with your custom configuration. For more information about these tasks, see "Identifying Configurations to Deliver Upgrade Components" and "Modifying and Creating Siebel Anywhere Configurations".
Inspect the Upgrade Component server parameter value for each Regional Node Server, and change it if necessary. For more information, see "Checking Siebel Regional Node Server Parameters Before a Siebel Database Schema Update".
Distribute your upgrade kit (or upgrade kits) to a configuration for your Regional Node Servers.
These might be either test Regional Node Servers, or production Regional Node Servers, depending on where you are in the process. For more information about distributing upgrade kits, see "Distributing Upgrade Kits".
This topic describes how to check Siebel Regional Node Server parameters before you distribute a Siebel Database Schema upgrade kit to a Regional Node Server.
This task is a step in "Process of Updating the Siebel Database Schema".
Before you distribute a Siebel database schema to a Regional Node Server, you must make sure that the server parameter Upgrade Component on the Regional Node Server is set to the correct value to match either Siebel Regional Server or any custom configuration you have made for your Regional Node Server. The simplest way to modify the parameter is to use the Server Parameters view, as described in the following procedure.
|
Caution: Before installing a Siebel Database Schema upgrade kit on a Regional Node Server in an IBM DB2 environment, you must drop all customized views and triggers in the regional database. Otherwise, the Upgrade Wizard will encounter errors when applying the changes in the logical schema to the physical schema. |
The following procedure describes how to set Siebel Regional Node Server parameters before you distribute a Siebel database schema update.
To set Siebel Regional Node Server parameters before distributing a Siebel database schema update
On the Regional Node Server, Navigate to the Administration - Server Configuration screen, then the Servers view.
The Siebel Servers list appears.
From the Siebel Servers list, select the appropriate server, and click the Parameters tab.
The Server Parameters list and the Additional Parameter Information form appear.
In the Server Parameters list, select Upgrade Component in the Parameter field, and set Value to Siebel Regional Server or the name of your custom configuration.
The Value on Restart setting is automatically populated with the same value when you leave the Value field.
Still in the Server Parameters list, select Table Owner Password in the Parameter field, and make sure that Value and Value on Restart are not blank.
Still in the Server Parameters list, select Version Check in the Parameter field, and set Value and Value on Restart to True.
|
Note: You can also check and modify the Upgrade Component, Table Owner Password, and Version Check parameters in Server Manager. |
You can also check and modify Regional Node Server parameters using Server Manager, as described in the following two procedures.
The following procedure describes how to check server parameters using the Siebel Server Manager command line.
To check server parameters using the Server Manager command line
From the command-prompt, enter:
list param <UpgComponent, VersionCheck, TableOwnPass>
The following procedure describes how to modify server parameters using the Siebel Server Manager command line.
To modify server parameters using the Server Manager command line
Enter:
change param param_alias=parameter_value
where param_alias is UpgComponent, VersionCheck, or TableOwnPass.
For more information about other steps in the process of preparing a Regional Node Server for a Siebel database schema update, see "Preparing Siebel Regional Node Servers for Siebel Database Schema Changes".
In a test environment, install the Siebel Database Schema upgrade kit (and any accompanying upgrade kits) on test Mobile Web Clients. In a production environment, install the Siebel Database Schema upgrade kit (and any accompanying upgrade kits) on production Mobile Web Clients. For more information, see Chapter 5, "Retrieving, Installing, and Testing Upgrade Kits."
This task is a step in "Process of Updating the Siebel Database Schema".
|
Note: The Siebel Database Schema upgrade kit will only be downloaded by Mobile Web Client users. |
Installing the Siebel Database Schema upgrade kit synchronizes the logical and physical schemas on Mobile Web Client databases.
To distribute an upgrade kit for Mobile Web Clients
For Mobile Web Clients assigned to the HQ Server, distribute the Siebel Database Schema upgrade kit under the appropriate configurations so each Mobile Web Client can receive the upgrade kit during synchronization.
For Mobile Web Clients assigned to a Regional Node Server, distribute the Siebel Database Schema upgrade kit to the configuration for the Regional Node Server, and install the update on the Regional Node Server before distributing the upgrade kit to the configuration for that server's Mobile Web Clients.
Siebel database schema changes must also be complete on a Regional Node Server before any Developer Web Clients connected to that server can resume normal operations.
In a test environment, install the Siebel Database Schema upgrade kit (and any accompanying upgrade kits) on test Siebel Regional Node Servers. In a production environment, install the Siebel Database Schema upgrade kit (and any accompanying upgrade kits) on production Regional Node Servers. The following procedure describes how to install a Siebel database schema update on a Regional Node Server.
This task is a step in "Process of Updating the Siebel Database Schema".
Installing the Siebel Database Schema upgrade kit synchronizes the logical and physical schemas on Regional Node Server databases.
|
Note: If any of your Mobile Web Client users connect to a Regional Node Server, rather than the HQ Server, then the Regional Node Server must install the Siebel database schema changes before those mobile users can obtain and install the changes. |
To install a Siebel Database Schema upgrade kit for regional databases
Disconnect all users from the Regional Node Servers and the HQ Server.
Stop all tasks on the Siebel Servers except those for the Replication Agent, Transaction Processor, Router, and Transaction Merger components.
Wait until the replication backlog has been processed.
Check the download and upload statistics in the Administration - Siebel Remote screen for each Regional Node. The three Last File and Last Transaction numbers match in the lower applet. Make sure that there are no outstanding transactions by checking that the docking\inbox and docking\outbox directories are empty on the regional Siebel Servers.
Verify that the server parameter Version Check is set to TRUE on the regional Siebel Server by using one of the following methods:
In the Server Parameters view, verify that the server parameter Version Check is set to TRUE on the regional Siebel Server.
Use the following commands to start srvrmgr and verify the value of the Version Check parameter:
srvrmgr /g gateway_host /e enterprise_server /s server_name /u user_name /p password
list param VersionCheck
The Replication Agent now performs a version check and shuts down itself and the regional Siebel Server so the Siebel administrator can perform the upgrade manually.
Check the appropriate log files (RepAgent.log and syncthrd.log) to verify whether you need to run the Upgrade Wizard.
Verify that the Siebel Server is properly shut down. If not, then shut it down manually.
Use one of the following methods to run the Upgrade Wizard:
In a Windows environment, in the server BIN directory, run siebupg.exe to perform the upgrade.
In a UNIX environment, in the server BIN directory, run srvrupgwiz to perform the upgrade.
After the upgrade, bring up the regional Siebel Server.
You can change the server parameter Version Check back to False, which is its default value.
|
Note: When you install the Siebel Database Schema upgrade kit, the schema changes are applied to the server and the custom version is incremented, which makes the database template obsolete. If there are Mobile Web Client users who connect to the Regional Node Server, then you must run Generate New Database task to create a new database template. |
Mobile Web Clients can synchronize and install the Siebel Database Schema upgrade kit in much the same manner as any other upgrade kits by using the Upgrade Wizard.
If the Siebel Business Applications developer created or modified applets or views to display data in new extension columns or new extension tables, then it is necessary to create and distribute the accompanying Siebel Repository File upgrade kit. Installing the combination of the Siebel Database Schema upgrade kit and the Siebel Repository File upgrade kit allows users to view these data after the schema upgrade.
After the Siebel database schema upgrade is finished, distribute the new SRF upgrade kit to its corresponding Mobile Web Clients.
Sometimes you might want to purge older upgrade kits to free up some space used by these upgrade kits. When you purge old upgrade kits, you must make sure that users will not encounter errors when they retrieve upgrade kits that are expecting to use information from upgrade kits that have been deleted.
Two groups of users can be adversely affected when old upgrade kits are deleted, new users and infrequent users. For example, assume that your end users belong to the same configuration. Also assume they are currently using version 3 of Siebel Client Customer Revisions and version 4 of SRF.
If you were to delete all the previous Siebel Client Customer Revisions and SRF upgrade kits, then a new user might have trouble with Siebel Client Customer Revisions if you start from version 0. This situation occurs because Siebel Client Customer Revisions upgrade kits often depend on the previous versions. If a new user needs version 2 in order to gain access to version 3, and if version 2 is deleted, then Siebel Anywhere would not be able to provide the new user with version 3. However, the new user would be able to install version 4 of the SRF, because SRF upgrade kits do not depend on any version history.
The correct way to handle this situation is to keep an updated installation for new users where each of the upgrade kits has been installed. You can do this by creating a package periodically and making the most current package available to new users. This method addresses the problem for new users, because they always install a client with up-to-date configurations.
However, do not delete old upgrade kits as soon as a new package is created. There might be infrequent users in your organization who have not logged in for months. While the rest of the company is using version 3, the infrequent users might still be on version 1. In this case, it is up to the individual Siebel administrators to assess the situation and determine how old the upgrade kit must be before deletion.
Sometimes you have a few upgrade kits of the type Customer Revision that were distributed long ago. Use the following procedure to delete them. Use the same logic if you are planning to delete any other upgrade kits.
To delete old Customer Revision upgrade kits
Establish one installation that includes all the Customer Revision upgrade kits ever installed.
Create a package from that installation.
Set up each new user with the package prepared in Step 1. This provides new clients with the files that were distributed through the old Customer Revision upgrade kits, and also provides new clients with the correct version of the clntrev.cfg file.
After you upgrade a Siebel application to a new release, check to make sure that version numbering continues for the releases for upgrade components in each Siebel Anywhere configuration. Upgrading to a new release of Siebel Business Applications upgrades the Siebel Anywhere table definitions. However, it does not reset the Upgrade Component information for Siebel Anywhere Configurations.
As a result, Siebel Anywhere will resume version checking against the existing component versions in the new release of Siebel Business Applications. If required upgrade kits for Siebel Client Repository File, Siebel Client Customer Revisions, or Siebel CFG File were distributed in the previous release, then newly upgraded production clients might be incorrectly prompted for upgrade kits when they synchronize with the server.
Before upgrading production users, test the upgrade kit on a Siebel administrator's client with version checking enabled. Verify that this client passes version check, so that after the upgrade kit is packaged and distributed, it will function correctly for the remainder of your production users.
To accomplish this testing, verify that the administrator's client has the latest versions for Siebel Client Repository File__language-code, Siebel Client Customer Revisions, and Siebel CFG__language-code.
The following procedure describes how to test repository components for consistency.
To test repository components for consistency
Determine the current version values of your repository components by completing the following substeps:
In your production Siebel environment, navigate to the Administration - Siebel Anywhere screen, then the Upgrade Component List view.
Use standard query techniques to select your server and client repository components.
Determine the current value of your repository components by inspecting their Min Version values. A blank Min Version field indicates a value of zero.
Use a computer and a login account that have read and write access to the location of the repository file you want to check, and open a command window.
Make sure that the repository file you want to check is not currently in use.
You might need to exit from any Siebel application that is using the repository.
In the command window, navigate to the directory where the srfstamp utility is located, as follows:
If you are using a server computer, then navigate to SIEBEL_ROOT\BIN, where SIEBEL_ROOT is the root directory for your Siebel Server software.
If you are using a client computer, then navigate to SIEBEL_CLIENT_ROOT\BIN, where SIEBEL_CLIENT_ROOT is the root directory for your Siebel Mobile Web Client or Siebel Developer Web Client software.
Enter the following command, where repository_file_name is the complete path and file name of your repository file, and language-code indicates the language for which this repository is used:
srfstamp /r repository_file_name /l language-code
After a brief pause, the current version number of the specified repository file is displayed.
Compare the version displayed by srfstamp to the component version you obtained in Step 1 of this procedure.
If you want to change the version number of the specified repository file (for example, to use your current repository version number for a new repository file during a major upgrade), then enter the following command:
srfstamp /w repository_file_name /v new_version_number /l language-code
|
Note: The srfstamp utility supports only integers for version numbers. |
The following procedures describe how to test Siebel Client Customer Revisions and CFG file components for consistency.
To test Siebel Client Customer Revisions components for consistency
Copy the clntrev.cfg file from one of your previous release production clients to the SIEBEL_CLIENT_ROOT\BIN directory of the Siebel administrator's client.
To test Siebel CFG file components for consistency
Edit the appropriate CFG file under SIEBEL_CLIENT_ROOT\BIN\language-code and increment the Version parameter in the [Siebel] section to the Maximum Version of the Upgrade Component Siebel Call Center CFG file for the previous release.
Sometimes you might need to upgrade third-party software based upon the version of a particular DLL file. An example would be an ODBC upgrade on a client, based upon the version of the file odbcint.dll.
The following procedure describes how to create a custom component and an upgrade kit that check the version of a particular DLL file.
To create an upgrade component and upgrade kit for DLL version check
Navigate to the Administration - Siebel Anywhere screen, then the Upgrade Component List view.
The Upgrade Components list appears
Create an upgrade component and specify the field values shown in the following table.
| Field Name | Value |
|---|---|
| Name | upgrade_component_name |
| Component Type | Third Party Software |
| Locate Method | Registry |
| Locate Information | hkey,subkey_name,value_name |
| Version method | FileVersion |
In this table, the value for Locate Information points to the registry hkey, subkey and a specific value that points to the DLL file that you want to version check. For example:
HKEY_LOCAL_MACHINE,SOFTWARE\ODBCFileDSN\DefaultIcon,Driver
If the registry value is DefaultIcon, then the value_name must be omitted. This value in the registry will then point to the specific DLL file. For example:
C:\WINNT\System32\odbcint.dll
After creating the custom component, as described in the previous steps of this procedure, define the upgrade kit as described in Chapter 4, "Defining Upgrade Kits."
When defining the upgrade kit, remember to select the name of the custom upgrade component (created above) when the Upgrade Kit Wizard page appears.
This topic provides an example of how to construct a Third Party Software upgrade kit, using WinZip as the example software for which the upgrade kit is created. The process shown in this topic can be used to construct upgrade kits for other third-party software applications, if the software is related to the use of Siebel Business Applications.
There are two procedures to this process:
The following procedure describes how to create a Third Party - WinZip upgrade component.
To create a new upgrade component Third Party - WinZip
Navigate to the Administration - Siebel Anywhere screen, then the Upgrade Component List view.
The Upgrade Components list appears.
On the Upgrade Components list, click New.
A blank record appears.
Enter the necessary information.
As an alternative, copy the record of an existing Third Party component and then edit the fields as required.
Enter the values shown in the following table.
| Field Name | Value |
|---|---|
| Component Name | Third Party - WinZip |
| Component Type | Third Party Software |
| Locate Method | Registry |
| Locate Information | HKEY_CLASSES_ROOT,WinZip\shell\open\command
Locate Information has the following structure when Locate Method is set to Registry: HKEY,Subkey,Name. If Name is equal to the default, that is, (Default) as seen in the Registry Editor, then leave Name as blank for Locate Information. |
| Version method | FileVersion |
From the link bar, select Upgrade Configurations.
The Upgrade Configurations list appears, along with the Upgrade Components list.
On the Upgrade Configurations list, select the desired clients such as Siebel Sales Client.
On the Upgrade Components list, click New.
The Upgrade Components pick list appears.
On the Upgrade Components Selection dialog box, select Third Party - WinZip.
The Upgrade Configurations list appears, along with the Upgrade Components list.
The new record (Third Party - WinZip upgrade component) is highlighted in the Upgrade Components list, which indicates that it is selected.
This step completes the procedure to create a new upgrade component, Third Party - WinZip.
The following procedure describes how to define a Third Party - WinZip upgrade kit.
To define a Third Party - WinZip upgrade kit
Navigate to the Administration - Siebel Anywhere screen, then the Upgrade Kits view.
The Upgrade Kits view appears.
Click Auto Create to invoke the Upgrade Kit Wizard.
The Upgrade Kit Wizard - Upgrade Components page appears.
Choose Third Party - WinZip in the list and click Next.
The Upgrade Kit Wizard - Add Files page appears.
Input the UNC path of the WinZip installer.
Click Next.
The Upgrade Kit Wizard - Select Execute File page appears.
Input the executable file name and the command-line argument, if any.
Follow the prompts to perform the following actions:
Review and verify the information.
Specify the new version number.
(Optional) Change the title, if you want to do so.
When you have finished entering upgrade kit information, click Finish.
Follow the procedures in Chapter 6, "Activating, Applying, and Distributing Upgrade Kits," to activate, apply, and distribute the upgrade kit.
