RepositoryUpgrade Utility

The RepositoryUpgrade utility delivers optional repository changes made by the Oracle Siebel CRM development team since Siebel CRM 17.0. The RepositoryUpgrade.zip file, located in the siebsrvr\bin folder, contains the payload for RepositoryUpgrade. Unzip the file to see its contents – a subfolder will exist for each release that has changes (for example: 20.3, 20.7, 20.8, ... 21.12, 22.1, and so on).

The RepositoryUpgrade utility inspects the database table S_APP_HIST to determine the last time it ran and the next release folder to start running updates from.

During execution, the RepositoryUpgrade utility imports data from the folders added since the last time it was run. This prevents customers having to re-resolve any conflicts they have already addressed.

If there are 10 folders for RepositoryUpgrade to process, then they will be processed in order of release but only a single Integration Workspace will be created. This ensures that if Object_X changed in 20.7 and again in 21.12, then the 21.12 changes will be merged with the 20.7 changes so that customers get only the latest version.

Assuming it is January 2022, the typical order of events to follow when planning to run the RepositoryUpgrade utility are:

1. Customer identifies a feature that they want in a monthly update (22.1 for example), which requires repository changes.

2. Assuming that the customer performs monthly internal releases, the customer analyzes the effort involved in consuming the changes (merge with existing customizations, test, and so on) and picks a future release when they plan to actually deploy it (April 2022 for example).

3. Customer runs the RepositoryUpgrade utility, pointing to the int_2022_April release branch, where they are staging the changes to be released in April. This keeps all the changes out of the in-progress February and March releases and:

   1. Creates a child Integration Workspace named int_siebel_updateN (where N is a sequential number).

      You cannot have two Workspaces with the same name and you may have to run RepositoryUpgrade more than once for features released in different monthly updates.

   2. Creates a child Developer Workspace under int_siebel_updateN where all changes are imported – you cannot directly edit an Integration Workspace.

      The Developer Workspace is automatically delivered to the int_siebel_updateN branch by RepositoryUpgrade. There will be no conflicts because int_siebel_updateN has no changes in it.

4. Customer delivers int_siebel_updateN to int_2022_April.

   This will work if there are no customizations to any of the changed objects; otherwise a Rebase will be required and the customer will have to resolve conflicts before delivery.

5. After delivery, int_2022_April will contain the latest (Oracle and all customer) changes and can be migrated to test environments as needed.