The WebSphere® ESB version-to-version
migration tools will handle different sets of data (application data, configuration
data, database information, and long-running processes) in different ways.
Application data
Your user applications
(any applications not provided with the
WebSphere ESB product)
are binary-compatible for the migration scenarios supported. (Refer to
Overview of migrating for supported migration scenarios.) All
user applications will be automatically migrated to the new server. You should
not have to modify any part of the application to have it run on the newer
version of
WebSphere ESB.
Note: For
information about migrating WebSphere Adapters,
refer to the documentation for your adapter in the WebSphere Integration
Developer documentation in the IBM® WebSphere Business Process
Management Version 6.2 information center.
Note: If
you have SCA modules which use a single reference for both dynamic and static
invocations, and the reference is wired to an import with a JMS or HTTP binding,
then the JMS or HTTP binding will now be used for dynamic invocations using
jms: or http: URLs, rather than performing a dynamic web service invocation.
To retain the version 6.1.2 behavior and continue to make Web service invocations
in this scenario, you must either update your module to correctly set the
bindingType to indicate a web service URL when making the invocation (for
MFC or POJO components) or otherwise set the WebSphere variable
SCA_USE_WS_FOR_DYNAMIC_INVOCATION to include the name of the modules in a
semi-colon delimited list, e.g. sca/myModule1;sca/myModule2
Except
for sample applications, applications that are provided as part of the
WebSphere ESB product are
migrated to the latest version of those applications. These are handled as
follows:
- For all system applications–applications that reside in the install_root /systemApps directory,
the newer version is installed.
Sample applications are handled differently. For
stand-alone profiles, the migration process will not install any sample applications.
To make sample applications available for a stand-alone profile, you can install
them using the installation wizard for the later version of WebSphere ESB.
For network deployment profiles, any samples installed with the previous version
of WebSphere ESB will
be installed during migration to the new version.
Configuration data
The version-to-version
migration
tools (wizard or scripts) will
automatically apply the configuration settings from the previous profile to
the new profile created during the migration process. In cases in which the
new profile has already been configured and values in the old profile and
new profile do not match, the values will be handled as follows:
- The installation directory name that has already been configured in the
new profile will be retained in the new profile.
- Any values from the old profile (other than the installation directory
name) will replace non-matching values in the new profile.
Database information
Automatic
database migration
If you are migrating from version 6.0.2.x and
have a Cloudscape database, the
migration tools will migrate the database configuration automatically, with
certain exceptions. See Migrating Cloudscape databases for
more information. In addition, the Cloudscape database
will be converted to a Derby database, which is the successor to Cloudscape and is supported by WebSphere ESB version 6.2.
Manual
database migration
If you have a database other than Cloudscape, the migration tools will automatically
migrate the provider and datasource definitions for each existing data source
and provider. However, database schema upgrades may also be required, which
could require special attention. If the server process has the required database
permissions and, in the case of some databases, meets other requirements,
the schema upgrades will happen automatically when the server is first started.
If
the server process does not have the required permissions or meet other requirements,
or if you would like to manually upgrade your database schemas, then you will
need to use the scripts provided.
If you have Business Process Choreographer
or Business Space configured, you must update the database manually.
See Upgrading databases for migration for
more information.
Long-running
processes
Long-running business process instances and human task
instances are taken care of during version-to-version migration as the databases
(storing the instances) are taken over. During migration, the database schema
is upgraded and the data is converted to the new schema. After migration,
those instances continue to run in the migrated environment.