It is difficult to generalize a migration process because there are so many variables and each organization's situation is likely to be different from everyone else's. The following suggestions were contributed by an experienced Rhapsody consultant as a guide to completing this task successfully.

Manual Migration

Manually managing a migration means that a developer must take what they have configured in the DEV system and replicate it exactly in the PROD system manually. It is important that a number of tasks are completed before starting this process; these are listed at the end of this section.

The advantage of a manual migration is that it forces the user to change the system without having Rhapsody overwrite parts of the system creating duplicate registry and guide keys using the reload and save function. It also means it takes longer to redevelop the new routes in the Production system; if there is a large number of components, there is a good chance of missing parts of the new configuration. But if the upgrade is small and not many changes are required, then this is the ideal way to transfer routes between environments.

Advantages

  • The Developer can make the changes and feel confident that the upgrade is working.
  • If there are variables in Rhapsody, these are changed correctly by the developer at the time of upgrade.
  • The process is cleaner if the DEV and PROD systems do not have the right naming conventions associated with the file structure or do not use the Variables Manager for configuration files.

Disadvantage

  • It may take longer to upgrade the Rhapsody configuration depending on the number of routes being upgraded.

Migration Using Rhapsody Tools

This is generally the way two environments should be migrated. Problems may arise if the naming conventions are not correct (i.e. file structures of the environments differ) when different routes are migrated. Any Rhapsody variables in use must be changed to reflect the new environment, otherwise data will be sent to the wrong system (at the very least) when their associated components are started.

The Rhapsody way must adhere to two sets of rules to enable a successful upgrade plan:

  1. Ensure both systems have a naming convention that is identical throughout the two environments i.e. if you have a route in DEV named "PAS to Radiology" then you must in PROD have a "PAS to Radiology" route if you want the upgrade of the DEV to PROD system to work correctly.
  2. Communication point and/or filter properties should use the Variables Manager for defining values. For example, a Rhapsody variable called radiology_port might have a set value of 9000 and can be referenced in a TCP communication point as $(radiology_port). This variable can be set up in DEV and PROD but the values might be different, in other words DEV "radiology_port" = "9000" PROD "radiology_port" = "9001".
    This simplifies the upgrade as you do not need to worry about changing individual configuration files or comm points.

Advantages

  • Quicker, cleaner and easy to upgrade individual routes.
  • Reference values mean that you have a record of individual components values.

Disadvantages

  • If folder structures between DEV and PROD are different then it becomes complicated as you need to rename components.

Pre/Post-upgrade Steps

  1. Always backup the Rhapsody datastore.
  2. Save the entire RLC configuration from the DEV and PROD systems, storing them safely in a folder that is easy to find.

  3. From the DEV environment, repeat the save but this time select the components of the routes that you wish to upgrade.

    The RLC file may contain certain dependencies. If these dependencies are missing routes that are in the PROD system, these can be missed.

    If these dependencies are configuration or definition files that have been changed, then these must be included.

  4. Once you have an RLC file that you wish to upgrade with, open the PROD system IDE and reload the configuration contained in the RLC file.

    It is recommended that the Stop All option for routes and communication points should be selected and that you do NOT select to overwrite the existing configuration.

  5. Once the upload of the new routes has completed, double check the route and make any changes to the uploaded property files. Double check again that all is correctly configured.
  6. Start the Output communication points first, followed by the routes then the Input components.
  7. Monitor and check using the Management Console.