Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

(tick)Upgrade processThe upgrade process is a "side-by-side upgrade". This means that the new dashboard WAR/ZIP file should be deployed alongside the existing WAR/ZIP/JAR file and any settings transferred from the existing to the new.
(tick)Where to run the upgrade?

The process must be run on the host server.

(tick)Obtain the installation media

Download the latest release of the required CAST Dashboard from CAST Extend. This media contains:

  • a WAR file for deployment on Apache Tomcat (all releases)
  • a ZIP file for deployment without Apache Tomcat (1.x 2.0 - 2.4 releases)
  • a ZIP JAR file for deployment without Apache Tomcat (≥ 2.x 5 releases)
(tick)Access to a CAST Storage Service/PostgreSQL instance (≥ 2.1)

When upgrading to ≥ 2.1 a graphical user interface has been implemented for managing the assignment of role and data authorizations to users and groups of users. This interface replaces the existing mechanism provided by the roles.xml and the authorizations.xml files. This new management interface relies on a schema hosted on a CAST Storage Service/PostgreSQL instance to store the roles/data authorizations. This schema is called cast_dashboards by default and will be created on first startup of the web application.

(tick)Stop all services

Before starting any upgrade process, you must ensure ALL services are stopped, for example stop Apache Tomcat or any existing Dashboards running in SpringBoot mode.

...

Remove the existing Dashboard deployment if necessary. This step is optional and you may wish to leave this in place until the new dashboard is fully tested and working.

Instructions for transitioning to ≥ 2.5 JAR files

To transition to ≥ 2.5 JAR files files there is no managed upgrade process. Instead install the new dashboard side by side with the existing dashboard.


Step 1 - Deploy the new JAR file

Info

Note that when deploying in Microsoft Windows, the installer will ask you whether you want to install a Windows Service to manage the deployment. If you have already installed a Windows Service for use with the ZIP files shipped in releases 2.0 - 2.4, then CAST highly recommends uninstalling this service before you proceed. You can do so using the following file:

Code Block
<unpacked_zip>\dashboard-service-uninstall.bat

or using the following command in command prompt (opened with elevated Administrator permissions), where <service_name> can be found in the properties of the Windows Service:

Image Added

Code Block
sc.exe delete <service_name>



Obtain the new .JAR file and deploy it on the target server as described in:

Step 2 - Configure your new Dashboard

You may now need to transfer the details of your environment (stored in the configuration files such as web.xml/context.xml/other .properties/.xml/.json files) from the old Dashboard to the new. Please be aware that you should not perform a merge or overwrite configuration files (unless specifically requested to do so in the instructions below) - instead you must manually update the new configuration files with the details from the old configuration files.

Use the following table to help. If you change any files in the new deployment, please ensure that you restart the Dashboard so that any changes are taken into account.

Existing fileNotes
authorizations.xml

See Data authorization - 2.x and above.

From 2.0.0 to ≥ 2.1.0 release

authorizations.xml has been replaced with a graphical user interface to manage data authorizations for users/groups. Configuration is stored in a schema called "cast_dashboards" on a chosen CAST Storage Service/PostgreSQL instance. There are two choices for how to proceed:

  • You can provide your authorizations.xml file and on first start-up of the web application the authorizations will be automatically transferred into the management interface (i.e. the schema called "cast_dashboards"). The authorizations.xml file will then be ignored on any subsequent web application startup and all changes from then on must be performed using the graphical interface.
  • You can assign the data authorizations from scratch using the graphical interface.

From ≥ 2.1.0 release

All authorization data is stored in the schema "cast_dashboards" and the authorizations.xml file is no longer used. CAST recommends re-using the "cast_dashboards" schema so that all existing authorizations are re-used. This is configured in the application.properties file.

license.xmlSee Dashboard Service license key configuration and Data authorization.
log4j2-spring.xmlSee Configuring the Log and Audit Trail.
roles.xml

See User roles - 2.x and above.

From 2.0.0 to ≥ 2.1.0 release

  • roles.xml has been replaced with a graphical user interface to manage role assignments for users/groups. Configuration is stored in a schema called "cast_dashboards" on a chosen CAST Storage Service/PostgreSQL instance. There are two choices for how to proceed:
    • You can provide your roles.xml file and on first start-up of the web application the role assignments will be automatically transferred into the management interface (i.e. the schema called "cast_dashboards"). The roles.xml file will then be ignored on any subsequent web application startup and all changes from then on must be performed using the graphical interface.
    • You can assign the roles from scratch using the graphical interface.

From ≥ 2.1.0 release

All roles data is stored in the schema "cast_dashboards" and the roles.xml file is no longer used. CAST recommends re-using the "cast_dashboards" schema so that all existing roles are re-used. This is configured in the <unpacked_zip>\configurations\application.properties file.

*.jsonIf you have made configuration changes to .JSON files to create custom tiles or layout and you want to retain those changes in the new version of the Dashboard, you can re-use old .JSON files with the new Dashboard, however, please note that doing so will mean that you will not benefit from any improvements or features added to the current release of the Dashboard.


Step 3 - Undeploy the existing WAR file (optional)

Undeploy the existing war file from Apache Tomcat if you are using it - you can use Apache Tomcat manager to do this, or simply delete the relevant folder and file in CATALINA_HOME\webapps. This step is optional and you may wish to leave this in place until the new dashboard is fully tested and working.