Contents

Popular
 Contents

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.

FPS Runtimedata Migration

Icon

Migrating peer server runtimedata is required only if custom queues/topics created or data (messages) pending for processing are to be moved from the previous installer.

Migrating Standalone/Replicated Profile Runtimedata

Preliminary Steps

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

  1. Stop all running  Event Processes and Fiorano servers in the old installer.

  2. 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 ESB and Peer server may get corrupted.
    • The repository will be overwritten. So, any Event Process 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 Event Processes, Named Configurations, Custom Schemas, Alert Configurations, Custom Components etc.) on HA FES setup.
  • pending message data and user-defined custom queues/topics on HA FPS 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:

  1. Go to the location $FIORANO_HOME/esb/FioranoMigration/bin/ to find the RunTimeDataMigration.properties file.



  2. Open the RunTimeDataMigration.properties file and provide values for the below properties in the file:
    1. OLD_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 for the parameters in the Runtimedata Migration properties file are in the table below.

PropertyDescription
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 Event Processes, Named Configurations, Schemas, Event Alerts, etc.

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

Migrating Shared HA Profile Runtimedata

For migrating Shared HA Profile Runtimedata, follow the same steps as illustrated in the Migrating Standalone Profile Runtimedata section, but provide the following values too in the RunTimeDataMigration.properties file:

  • EXISTING_SHARED_HA_FES_DATABASES
  • EXISTING_SHARED_HA_FPS_DATABASES

Descriptions of the parameters in the RunTimeDataMigration properties file are in the table below.

PropertyDescription
EXISTING_SHARED_HA_FES_DATABASES

Path to the SHARED HA FES Database(s).

Icon

Multiple entries can be made separated by comma(s) in case there are more than one shared HA database folders from different environments (DEV/UAT/PROD) of the same old installer.

Example
Icon

For the above example, Shared HA FES database for the new installer will be:

    • C:/DBFES1_${NEW_INSTALLER_BUILD}
    • C:/DBFES2_${NEW_INSTALLER_BUILD}
EXISTING_SHARED_HA_FPS_DATABASES

Path to the SHARED HA FPS Database(s).

Icon

Multiple entries can be made separated by comma(s) in case there are more than one shared HA database folders from different environments (DEV/UAT/PROD) of the same old installer.

Example
Icon

For the above example, Shared HA FPS database for the new installer will be:

    • C:/DBFPS1_${NEW_INSTALLER_BUILD}
    • C:/DBFPS2_${NEW_INSTALLER_BUILD}

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 Dashboard (Fiorano Web Console).
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.

Adaptavist ThemeBuilder EngineAtlassian Confluence