1. Database Upgrade Guide for DB2 for z/OS
  2. Siebel Repository and Workspace Version Tracking

Siebel Repository and Workspace Version Tracking

Because running the RepositoryUpgrade utility is optional, customers who have not executed the utility may end up in a situation where their Siebel CRM binaries (having installed the latest monthly update) might attempt to draw on repository content that is not actually in their own repository, since they have not run the RepositoryUpgrade utility.

To address this issue, the REP_VER_NUM column has been added to the S_WS_VERSION table so that the current Siebel Repository version (populated by running the RepositoryUpgrade utility) will be linked to a given Workspace version. The association between Siebel Repository version and Workspace version helps determine if the RepositoryUpgrade utility has been executed against a given Workspace version or not.

The S_WS_VERSION table contains a row for each version of every Workspace (MAIN, Integration, or Developer Workspace).

When an object manager starts, the repository version that the application is running against will be logged in the application object manager log. This (repository version) information will assist in debugging unexpected behavior after applying a monthly update.

Note: In Siebel CRM 21.10 Update, the REP_VER_NUM column (predefaulted to 17.0) is automatically added to the S_WS_VERSION table during Post Installation Database Update.

Example

Consider the following example, which shows what happens when a customer runs the RepositoryUpgrade utility for a monthly update and what happens when a customer does not run the RepositoryUpgrade utility.

  1. Customer Z previously ran the RepositoryUpgrade utility for 20.9.

  2. Customer Z installs the latest monthly update for 21.10 but does not run the RepositoryUpgrade utility.

    During Post Installation Database Update, the REP_VER_NUM column is automatically added to Customer Z's S_WS_VERSION table and predefaults to 17.0. In addition, all existing Workspace branches default to 17.0 (since there is no way to determine what has previously been imported, 17.0 is the one thing we can be sure of).

  3. As a result of the previous steps and not running the RepositoryUpgrade utility:

    • Customer Z's binary version is at 21.10 but their repository version is at 20.9.

    • Features or bug fixes in 21.10 will not work as expected because the supported repository changes are not present in Customer Z's repository.

    • Due to the time-lapse between 20.9 and 21.10, Customer Z may not be sure if (or when) the RepositoryUpgrade utility was run. For this reason, debugging unexpected behavior may be very difficult.

  4. When Customer Z runs the RepositoryUpgrade utility, they specify a particular parent Workspace under which to create a new Integration Workspace (IWS) that will include all the repository changes available in that release – changes which are cumulative from Siebel CRM 17.0 onwards.

    • If Customer Z runs RepositoryUpgrade for 21.10, then 21.10 will be set in S_WS_VERSION.REP_VER_NUM for the Integration Branch that RepositoryUpgrade creates.

    • Immediately after running RepositoryUpgrade, 21.10 will only exist in that Integration Branch but after testing the changes in that branch, Customer Z eventually delivers it to the parent IWS. At this stage:

      • The changes from 21.10 will also be in that parent IWS so the S_WS_VERSION record for the parent IWS will be updated to the version from the child that was delivered; and

      • Then that version will work its way upwards in the Workspace hierarchy until it ends at MAIN.

    • MAIN, at this point, and the children that were delivered will have the repository changes provided in the monthly update.

Related Topics