Summary: This step describes the process of splitting the Delivery folder when upgrading Console/Node packages to v. ≥ 1.13 from an older release.
Introduction
In Console 1.13 the format of the Delivery folder assigned to each Node was changed so that each Application now has its own dedicated Delivery folder within the parent Delivery folder (previously, the parent Delivery folder was global to all Applications).
Why is this split required?
- To allow each Application to have dedicated (DMT) plugins and to therefore avoid a "collision" of plugins across the Applications.
- Possibility to have multiple versions of plugins running on different Applications
- Easier to backup and restore the Delivery folder for one single Application
New delivery folder structure
The designated Delivery folder location will become the "parent" of all the "application delivery folders":
| Before the split is actioned | Post split - each folder corresponds to an Application |
|---|---|
|
Inside each Application specific subfolder, you will find the exact same folder structure as used previously:
|
When is the split actioned?
The process of "splitting" the Delivery folder is actioned automatically during an upgrade of the Console and Node packages to ≥ 1.13 as follows:
- When the Node installer detects that the Node's assigned Delivery folder is using the "old" structure, the split tool will be launched automatically:
Click to enlarge
- The installation continues after the split tool has successfully executed. If an error occurs, you will be notified.
- Post upgrade, you will find the same Delivery folder with the new structure and a backup of the original one:
- Existing Applications will continue to work in Console as before.
Situations that require manual migration before upgrading the Node package
You will need to manually execute the split tool before upgrading the Node package in the following situations:
- Where you have multiple Nodes with multiple CAST Storage Services/PostgreSQL instances, but only one shared Delivery folder
- Where you are using a mapped drive for your Delivery folder such as R:\
Manual Delivery folder split process
The Delivery folder split process requires a dedicated tool - Delivery Folder Migration Tool - 1.0. This tool can be found on CAST Extend. It can be run on any server which has access to the Delivery folder and the associated CAST Storage Service/PostgreSQL instances.
Step 1 - Ensure Console and all Nodes are stopped
Before you start, ensure that Console and all Nodes are not running by stopping the relevant services.
Step 2 - Modify config.json
Locate config.json provided in the downloadable extension. This file will be provided out-of-the-box as follows:
[
{
"delivery_folder_location": "C:\\CASTMS\\Delivery",
"destination_delivery_folder_location": "",
"log_file_location": "",
"css_servers": [
{
"dbname": "postgres",
"host": "localhost",
"port": "2282",
"username": "operator",
"password": "CRYPTED2:90B1A6EC1618661401B724DB5AC34595"
}
],
"applications": []
}
]
Edit this file with a text editor and enter the information as described below:
delivery_folder_location | Enter the location of the Delivery folder defined in the CAST Management Studio for the Application (s) you want to transform. See note below about the required path syntax for the config.json file. |
|---|---|
destination_delivery_folder_location | Leave this path empty. This ensures that the split is actioned in |
log_file_location | Enter a full path to a folder that will be used to store a log file called delivery.folder.migration.tool.logrecord that will contain log for the transformation process, for example: "log_file_location": "D:\\temp", See note below about the required path syntax for the config.json file. |
css_servers | Check that the "css_servers": [
{
"dbname": "postgres",
"host": "my_postgres1",
"port": "2282",
"username": "operator",
"password": "CRYPTED2:90B1A6EC1618661401B724DB5AC34595"
},
{
"dbname": "postgres",
"host": "my_postgres2",
"port": "2282",
"username": "operator",
"password": "CRYPTED2:90B1A6EC1618661401B724DB5AC34595"
}
],
The encrypted key in the password parameter corresponds to the default password for the operator user. If your CAST Storage Server/PostgreSQL instance uses different credentials, you can generate a new encryption key for the password entry, please see Using the aip-encryption-tool to encrypt credentials. |
applications | Leave this field blank. This ensures that all Applications in your Delivery folder are included in the split process. |
All paths specified in config.json must:
- use either double backslashes or single forward slashes. Single backslashes will cause an error when migration.bat is run.
- be valid (i.e. accessible) from the server on which you run migration.bat (see below).
Paths can refer to network shares or local paths.
For example, to split the Delivery folder located at Z:\delivery, with two CAST Storage Service/PostgreSQL instances associated to the Applications in that Delivery folder, use the following configuration:
[
{
"delivery_folder_location": "Z:\\delivery",
"css_servers": [
{
"dbname": "postgres",
"host": "localhost",
"port": "2282",
"username": "operator",
"password": "CastAIP"
},
{
"dbname": "postgres",
"host": "other_host",
"port": "2282",
"username": "operator",
"password": "CastAIP"
}
],
"applications": []
}
]
Step 3 - Run migration.bat
Run migration.bat provided in the downloadable extension. This will split the existing Delivery folder into the format required by Console ≥ 1.13.x. In addition, a backup of the existing Delivery folder will be created along side the current Delivery folder for roll back purposes.
You can check the log_file_location to ensure the transformation and move process functioned correctly.
What next?
Do not restart the Console and Node packages. Now move on to the next step in the upgrade process: Console upgrade.
