Summary: This step describes the process of splitting the Delivery folder when upgrading Console/Node packages to v. ≥ 1.13 from an older release.

If you are already using Console/Node v. ≥ 1.13, then please skip this step.

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

CAST AIP Console > Delivery folder split > tool.png

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 delivery_folder_location. A backup copy of the existing Delivery folder (with the suffix _old) will be created alongside the existing Delivery folder.

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 details correspond to the CAST Storage Server/PostgreSQL instances which are used to host the AIP schemas for the Applications you are transforming. You can specify more than one CAST Storage Server/PostgreSQL instance if you are using a shared Delivery folder and the Applications in it are managed on different CAST Storage Services. For example:

"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.