Skip to content
PDF

Upgrading Module Suite

Upgrading from a previous version

Whenever a new release of Module Suite is released, it is highly recommended for customers to update their installation. New releases not only contains fixes for the identified bugs, but most importantly new features that might open new usage scenarios for your Module Suite applications. Updating Module Suite is quite a straight forward procedure, that should take between 15 to 45 minutes (depending on how complex your Content Server architecture is). The system down time is limited to the two restarts required for each node.

We will refer to the Content Server installation directory as %OTCS_HOME%

Upgrading the primary node

This section only applies to your primary cluster node, or to non-clustered environments (single box). Please see section “Upgrading a secondary node” for the update procedure on secondary nodes.

Do not complete the installation procedure

For both the two procedures mentioned above stop at the step: Select “Install Modules”

  • Perform the modules upgrade using the standard Content Server tools

    1. Login as Administrator and access the Module administration panel
    2. Select “Upgrade Modules”
    3. From the available modules, select “Content Script X.Y.Z”
    4. Follow the installation steps and re-start Content Server when prompted.
    5. Return to the Module administration. In the “Update Modules” panel, select “Beautiful WebForms X.Y.Z”
    6. Follow the installation steps but do not restart Content Server

  • Stop Content Server

  • Apply relevant hot fixes

  • Start Content Server

  • From the Administration Home, select AnswerModules Administration > Base Configuration, then if necessary, change the core configuration or the configuration of the extension modules. Additionally, make sure you apply the new License Key in the relevant configuration entry.

Saving the Base Configuration is required even if no changes have been applied to the configuration page, since some of the values (typically configuration options of newly installed extension packages) have to be saved at least once. Additionally, saving the Base Configuration is necessary to the licensing process.

What do I need to upgrade ?

How the library upgrade works

The 'Upgrade' operation will rename the existing library folders in the Content Script volume, and import a new version of the same (the only exception is the 'CSFormTemplates' folder, which will be discussed later). As such, any modification that has been applied to one of the libraries will be relocated and no longer available.

Examples include:

  • any custom Beautiful WebForms components added to the CSFormSnippets folder
  • any custom Rest API endpoints added to the CSServices folders
  • any callbacks configured in the CSEvents or CSSynchEvents folders
  • any Classic UI modifications applied through the CSMenu, CSAddItems, CSBrowseView, CSBrowseViewColumns
  • any other object created or modified within one of the upgraded folders

As part of the upgrade operation, you should identify such changes and make sure they are ported to the new libraries.

CSFormTemplates have a slightly different upgrade process. Since objects in this folder are referenced by object DataID (their unique identifier on OTCS) they can't be replaced with the updated version, since this would potentially cause issues in any existing form using the template. For this reason, the upgrade process for CSFormTemplates automatically updates each single template by adding a new version to the object, thus preserving the original DataID. For this reason, no "backup" folder will be found for CSFormTemplates..

  • Cleanup. The folders named “Backup-_yyyyMMdd-AAAAAA” are backup folders containing the previously installed library scripts/snippets. They can be safely exported and removed

In case any of the standard components were customized, patched or otherwise modified, or new custom components were added within the standard library, make sure that you transfer any relevant changes to the new libraries before deleting the old version.

Script Console

Script Console can be upgraded performing a so-called "parallel" upgrade, which means installing on the same/different server the newer version of the console and configure it as the previous one. This typically requires to copy over the relevant configuration files from the previous Script Console together with any custom script you might have created/deployed on the console: %SCHOME%/config/cs-console-schedulerConfiguration.xml, %SCHOME%/config/cs-console-security.xml %SCHOME%/config/cs-console-systemConfiguration.xml

Upgrading a secondary node

This procedure only applies to cluster secondary nodes. The primary node should always be upgraded first: the steps below assume that the primary node has already been upgraded. To upgrade the primary node (or if your environment is a non-clustered environment) please refer to section “Upgrading the primary node”. Upgrading the secondary nodes in a cluster has the purpose of re-aligning the installed modules and support folders with the primary node in the cluster. Any cluster-wide configuration or update (for example, the library upgrade procedure) is not necessary on secondary nodes as it has already been executed on the primary node.

The following steps should be executed on each secondary node

  • Make a copy of the following resources from the primary node, and make them available in a working folder on the secondary node:

    1. %OTCS_HOME%/module/anscontentscript_x_x_x
    2. %OTCS_HOME%/module/ansbwebform_x_x_x
    3. %OTCS_HOME%/support/anscontentscript
    4. %OTCS_HOME%/support/ansbwebform

  • Stop Content Server’s services

  • Move the old module and support folders to a backup location

  • Copy the new folders in place of the old folders

  • Reconcile the opentext.ini (with particular reference to the [Modules] section) file in %OTCS_HOME%/config

  • Start the Content Server’s services