Chapter 10. Migration procedures for WebSphere InterChange Server V4.2.2 to V4.3 367
Check the support site to see whether a fix for the problem mentioned in this
section is available.
10.3 In-place database migration for V4.2.2 to V4.3. on AIX
This section describes an in-place database migration scenario and the
migration of WebSphere InterChange Server Version 4.2.2 to WebSphere
InterChange Server Version 4.3.0. The complete repository from WebSphere
InterChange Server 4.2.2 is reused in this scenario. This includes component
definitions, failed flows and relationships.
For the full description of a in-place database migration refer to Chapter 4,
“General planning” on page 53.
10.3.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. The steps for
performing these tasks are described in this section.
Note: After all the system tests are performed and the InterChange Server is
ready for production, ensure that the WebSphere InterChange Server is
re-started in Production mode.
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 at V4.1.1.9.
򐂰 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 use only the US English
character set (umlauts cannot 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. The Installation Guide for UNIX has more information about other
UNIX platforms.
368 WebSphere InterChange Server Migration Scenarios
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.
To put the WebSphere InterChange Server in a quiescent state, perform the
following steps:
1. Stop all adapters from polling the event tables by setting the Poll Frequency
property of the adapter to No using the System Manager.
2. Resolve transactional status of transactional collaborations using the Flow
Manager. Transactional collaborations that are in transactional status can be
migrated, however it is recommended that they are resolved in this
pre-migration step.
3. Resubmit failed events or discard the events using Flow Manager. Failed
flows can be migrated, however it is recommended that they are resolved in
this pre-migration step.
4. Once all events are processed by the system, stop all collaborations. To
check if all events are processed, check the collaboration statistics in System
Manager. Make sure the in-process and pending event counter is 0.
Backing up and shutting down components
This section describes the steps needed to shut down and take a backup. It is a
recommended practice to take a backup which allows the recovery of any data
that might be inadvertently overwritten during the installation of ICS 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 ICS system: static data
and dynamic data.
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

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.