About the Runtime Repository Version Rollback Feature

If issues are found with the latest deployed version of an application, then administrators can roll back to the last published stable version of the application’s metadata (RR definitions) and activate that version for all users without any downtime. The rollback only applies to the application’s metadata that is deployed in RR tables. Other application artifacts which may have been migrated at the same time but are not deployed in the RR are not rolled back: artifacts such as the manifest, JavaScript files, schema, Workspace-enabled seed data or LOVs, as well as tasks that are deployed in workflow deployment tables.

Note: As of Siebel CRM 20.8 Update, browser scripts and workflows are part of the Workspace-versioned object definition in RR tables (so rollback is supported for browser scripts and workflows). As of Siebel CRM 22.7 Update, tasks are part of the Workspace-versioned object definition in RR tables (so rollback is supported for tasks).

Do not perform a rollback if you are unsure whether the latest version of these artifacts is consistent with the last stable version of the application’s metadata which will become active if you do a rollback, as it may lead to inconsistent application behavior.

Rolling back to a previously published stable version of an application’s metadata is required in the following circumstances:

• If an unstable MAIN Workspace version is published where users can start the application and navigate to the Workspace Dashboard view.

  In this case, administrators can go to the Workspace Dashboard view and roll back to the last stable version of the application. All active user sessions will have to log out of the application and then back in again to load the stable version set by administrators.

• If an unstable MAIN Workspace version is published and users cannot start the application. For example, either the login page does not appear or users cannot log in to the application.

  In this case, administrators can change the application object manager component level parameter WorkspaceBranchName to the Workspace version to roll back to.

  Caution: If the application is not in rollback mode and you cannot start the application, then it is recommended that you use the WorkspaceBranchName server parameter to go into rollback mode. If you are already in rollback mode, then setting this parameter has no effect because it does not update the rollback version number in the ACTIVE_VER column of the S_WORKSPACE table. The value (rollback version number) in the ACTIVE_VER column of S_WORKSPACE is read by the component at user login or component startup. Clicking the Rollback button on the UI updates the rollback version in the ACTIVE_VER column of S_WORKSPACE.

An example of the command syntax to use when rolling back to a previously published stable version of the Runtime Repository follows.

change param WorkspaceBranchName=<Workspace_name> for comp <OBjMgr_lang>

To specify a specific version, use the following command syntax:

change param WorkspaceBranchName=<Workspace_name>/<Workspace_version> for comp <OBjMgr_lang>

For example, if 2 is a stable version in the MAIN Workspace, then use the following command:

change param WorkspaceBranchName=MAIN/2 for comp SCCOBjMgr_enu

After the command is run, when users next log in to the application, the application starts with the specified Workspace version without any downtime. There is no need to restart the Application Object Manager component or the Siebel Server services to reflect changes. For more information about setting parameters for components, see Siebel System Administration Guide.

Note: Rolling back to the last published stable version of an application’s metadata is different from rolling back to a previously installed software release (that is, performing a rollback uninstallation), which is described in Siebel Installation Guide.