Rhapsody 6 introduces features that require older configurations to be migrated:

Versioned Configurations

Rhapsody 6.0 introduces a versioned configuration repository that stores all changes made to configurations. This feature allows the configuration change history to be displayed within Rhapsody IDE, and the active configuration rolled back to an older version if required.

When upgrading from pre-Rhapsody 6 versions, the non-versioned configurations are migrated into the versioned configuration repository when Rhapsody is first started after being upgraded to Rhapsody 6 or later. The migration process loads the old unversioned configuration, and then immediately saves it into the new versioned configuration store as the initial configuration version. As part of the migration process, the old configuration store is removed after being backed up to the <Rhapsody>/rhapsody/data/config/migrated directory. If you need to roll back a post-Rhapsody 6 upgrade, then the old configuration can be restored by moving the contents of the <Rhapsody>/rhapsody/data/config/migrated back to the <Rhapsody>/rhapsody/data/config directory. Configuration restoration cannot be performed while Rhapsody is running.

 

Even though the old configuration is backed up as part of the migration process, it is still recommended that a manual backup be performed before starting the Rhapsody upgrade in the case the Rhapsody backup fails. Refer to Backup and Restore for details on how to configure backups.

The first migration check-in is automatically assigned a check-in comment of "Automatic import of existing Rhapsody configuration into the versioned configuration store when upgrading the Rhapsody engine" (translated to the system locale). The user for the check-in is recorded as the Rhapsody system user: RhapsodyInternal. 

Access Control-enabled Configurations

Rhapsody 6.1 introduces access control-enabled configurations which employ lockers.

When upgrading to Rhapsody 6.1, the configuration (folders, communication points, routes, definitions and message tracking schemes) is migrated by placing it inside a new locker named "Locker". The configuration's original folder structure within the locker is preserved. If the configuration is empty before migration, an empty locker is created.

Access rights which an access group previously had that apply at a locker level are granted as default locker rights for the migrated access group. A mapping is set up between the migrated access groups and the default locker that is created on configuration migration.

When upgrading from pre-Rhapsody 6 versions, the non-versioned configuration is first migrated to a versioned configuration repository and then placed in a locker, in a single check-in. The check-in comment for this check-in has two comments, representing each stage of the migration.

Only those parts of a configuration which support access control are placed in a locker during migration; the parts of a configuration which do not support access control are migrated as is. Refer to Access Control for details on which parts of a configuration do not support access control.

 

Migration Logging

All migration activities are logged at the INFO level as per standard migration logging with the addition of a note indicating they have been migrated to the new versioned repository:

  • Migration detection and startup process.
  • Create the default locker
  • Migrating Rhapsody variable.
  • Migrating Rhapsody variable overrides.
  • Migrating security objects.
  • Migrating message definitions.
  • Migrating message tracking schemes.
  • Migrating lookup tables.
  • Migrating the Web Service User Store.
  • Migrating web services.
  • Migrating folders.
  • Migrating routes.
  • Migrating filters (not enabled by default - DEBUG log level is required).
  • Migrating auxiliary Files (not enabled by default - DEBUG log level is required).
  • Migrating communication points.
  • Migration complete.

All errors during the migration process are logged.

Related Topics