322 WebSphere InterChange Server Migration Scenarios
10.1 In-place database migration: V4.2.2 to V4.3 on
This section describes an in-place database migration scenario of WebSphere
InterChange Server Version 4.2.2 to WebSphere InterChange Server
Version 4.3.0. The complete repository from Version 4.2.2 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.
10.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.
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 10. Migration procedures for WebSphere InterChange Server V4.2.2 to V4.3 323
򐂰 All data is consistent between the integrated applications.
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 the Connector Configurator.
2. Resolve transactional status of transactional collaborations using the Flow
Manager of the WebSphere Business Integration Toolset. Transactional
collaborations that are in transactional status can be migrated; however, it is
recommended that they be resolved in this pre-migration step.
3. Resubmit failed events or discard the events using the Flow Manager of the
WebSphere Business Integration Toolset. 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.0. Additional information about backing up the system
can be found in the System Administration Guide.
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 collaboration components, such as Java class files and message files
򐂰 Custom connectors
򐂰 Map components, including map design files, Java class files, and message
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)

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.