Contents

Migrating Standalone/Replicated Profile Runtimedata

There could be changes in the runtimedata structure from one release to another or in the content of the essential files used by servers. So, Runtimedata Migration is essential whenever there is a need to migrate from a previous installation to the new one.

Migrating Standalone/Replicated Profile Runtimedata

Icon

AGS runtimedata migration is needed only in case analytics data entry is pending to be processed. All pending API calls will get timed out and need not be moved.

Preliminary Steps

Ensure that the below exercise is completed before you start with executable steps:

Stop all running API projects and Fiorano servers in the old installer.
Clear runtimedata of the new Installation present in the $NEW_FIORANO_HOME directory. If required, take a backup of the runtimedata.
Icon
This step is mandatory, not following which may lead to the following problems:
- The MQ database of the AMS and AGS server may get corrupted.
- The repository will be overwritten. So, any API Projects with the same name gets overwritten.

HA Migration

Icon

Note

Icon

Not letting the previously active HA server profiles to reach the standalone state will lead to loss of:

user/group information, repository content (including but not limited to API projects, policies, notifications, reports, etc.) on HA AMS setup.
pending analytics data and user-defined custom queues/topics on HA AGS setup.

Passive servers do not need runtimedata migration because the start of the passive server after the active server reaching standalone state will synchronise the entire data from the active to the passive server. Even if data from passive servers get migrated due to the data's presence in the same runtimedata as that of the active server, there won't be any issue as this data gets overwritten with the data from the active server once the passive server is started after the previously active server is in the standalone state.

Executable Steps

Step 1: Set the required parameters in RunTimeDataMigration.properties file

To migrate a runtimedata from the previous version to the new Fiorano installation, you have to first configure the RunTimeDataMigration properties file. Hence, perform the following actions before running the utility:

Go to the location $FIORANO_HOME/esb/FioranoMigration/bin/ to find the RunTimeDataMigration.properties file.
Open the RunTimeDataMigration.properties file and provide values for the below properties in the file:
1. FIORANO_HOME:
2. OLD_INSTALLER_BUILD
3. NEW_ESTUDIO_WORKSPACE
4. OLD_ESTUDIO_WORKSPACE
Icon

The values entered for these parameters are case sensitive.

Descriptions of the parameters in the Runtimedata Migration properties file are in the table below.

Property	Description
OLD_FIORANO_HOME	Path to old Fiorano Installer from which runtimedata is being migrated. Example
OLD_INSTALLER_BUILD	Provide the installer Build number of the previous installation from which runtimendata is being migrated Icon It is important to provide correct build number of the installer as the set of changes done to Configs.xml file (to make it compatible with current version) depend on this value. Example Icon Check OLD_FIORANO_HOME\build.properties for the build number.
NEW_ESTUDIO_WORKSPACE	Path to the new eStudio workspace; location to which eStudio data is to be migrated. Example
OLD_ESTUDIO_WORKSPACE	Path to the old eStudio workspace. Location from which eStudio data is to be migrated. Example

Step 2: Execute the Migration Script

Open console from the location $FIORANO_HOME/esb/FioranoMigration/bin and execute the following script:

Windows

Linux

Repository Migration

Icon

As a part of this step, a prompt gets displayed to choose whether to migrate the whole runtimedata or just the repository of the runtimedata; select "Y" for full runtimedata and "N" for just the repository. The repository of the runtimedata consists of api projects, api policies, notifications, reports, etc.

Once the script execution completes, the runtimedata containing the migrated data will be present in the new installation.

Post Migration Activities

After migration, perform the following actions to ensure and confirm a proper migration:

Add the latest license to the license folder present at Fiorano_Home.
After running the servers, there should not be any errors on the server console and server status should be shown in the Server Status Tab of the API Dashboard.

Icon

HA profiles (both FES and FPS) from which the runtimedata is migrated (server profiles in the Active state before migration) should be started at first in the new installation and should be allowed to reach the Standalone state before starting the passive server.

Icon

For Cassandra Server Traffic data Migration, refer to the Cassandra Migration section.