224 WebSphere InterChange Server Migration Scenarios
9.1 In-place database migration: V4.2.1 to V4.3 on Windows
This section describes an in-place database migration scenario of WebSphere
InterChange Server Version 4.2.1 to WebSphere InterChange Server
Version 4.3.0. The complete repository from Version 4.2.1 is reused in this
scenario. This includes component definitions, failed flows, and relationships.
For the full description of an in-place database migration, refer to Chapter 4,
“General planning” on page 53.
9.1.1 Pre-migration steps
The environment must be put into a quiescent state before the migration is
attempted. It is also necessary to take a backup of the system.
Put the environment in a quiescent state
The WebSphere InterChange Server is in a quiescent state when all of the
following conditions exist:
򐂰 All working queues are emptied.
򐂰 All collaborations are paused so that no new data can be written to the
cross-reference tables.
򐂰 All data is consistent between the integrated applications.
Tip for advanced users: Appendix A, “WebSphere InterChange Server
migration checklist” on page 419 provides a checklist of the migration steps.
򐂰 Before starting the migration, ensure that the current WebSphere
InterChange Server is running at least Version
򐂰 Ensure that all components follow the Naming Conventions. Refer to the
appropriate V4.3 Development Guide for each component. For example,
business object names and attributes can only be used with US English
character set (umlauts can not be migrated).
򐂰 WebSphere InterChange Server names that contain dots (.) are no longer
supported. See Chapter 5, “Technical impact of major design changes” on
page 67.
For more information, view the relevant publications at:
Chapter 9. Migration procedures for WebSphere InterChange Server V4.2.1 to V4.3 225
To put WebSphere InterChange Server into a quiescent state:
1. Stop all adapters from polling the event tables by setting the Poll Frequency
property of the adapter to No
using Connector Configurator.
2. Resolve transactional status of transactional collaborations using the Flow
Manager of the WebSphere Business Integration Toolset. Refer to the
Administration Guide for Version 4.2.1 for information about using the Flow
Manager. Transactional collaborations that are in transactional status can be
migrated but it is recommended that they be resolved in this pre-migration
3. Resubmit failed events or discard the events using the Flow Manager of the
WebSphere Business Integration Toolset. Refer to the System Administration
Guide for Version 4.2.1 for information about using the Flow Manager. Failed
flows can be migrated, but it is recommended that they be resolved in this
pre-migration step.
4. After all events are processed by the system, stop all collaborations. To
confirm that all events are processed, check the collaboration statistics in
System Manager. Ensure that the in-process and pending event counter is 0.
Backing up and shutting down the components
This section describes the steps needed to shut down and take a backup. It is
recommended that you take a backup that enables the recovery of any data that
might be inadvertently overwritten during the installation of WebSphere
InterChange Server 4.3. Additional information about backing up the system can
be found in the WebSphere InterChange Server System Administration Guide:
In the left pane, expand Interchange Server and Toolset Administration
PDFs and click System administration in the right-side pane.
There are two types of data in the WebSphere InterChange Server system: static
and dynamic.
Static data includes:
򐂰 WebSphere InterChange Server repository (except for relationship tables)
򐂰 Custom collaborations components, such as Java class files and message
򐂰 Custom connectors
򐂰 Map components, including: map design files, Java class files, and message
226 WebSphere InterChange Server Migration Scenarios
Dynamic data includes:
򐂰 Relationship database tables
򐂰 Work-in-progress tables and transaction database tables
򐂰 WebSphere MQ message data
򐂰 Log files (as desired for historical information)
These steps perform the backup:
1. Back up the current InterChange Server repository using the repos_copy
For example, suppose the InterChange Server instance is WIN421 and has
the default login of admin
and the password of null. The following repos_copy
command creates a backup of the repository objects in a file called
Repository421.jar. This file is created in the directory where the repos_copy
command was run.
repos_copy -sWIN421 -uadmin -pnull -oRepository421.jar
2. To export existing user projects, connect System Manager to the running
WebSphere InterChange Server instance and follow the steps in System
a. Right-click User Projects and select Export Solution.
b. Select all user projects that are to be exported and enter a destination
Note: A repos_copy may not be required during an in-place migration;
however, it is still a recommended practice for backing up the current
definitions of the WebSphere InterChange Server repository.

Get WebSphere InterChange Server Migration Scenarios now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.