Chapter 10. Migration procedures for WebSphere InterChange Server V4.2.2 to V4.3 389
CxIgnore case in a future version. It is recommended that Failed Flows are
handled before migration until this problem has been resolved.
Check the support site to see if a fix for the problems mentioned in this section
This section describes the steps to uninstall the previous version of WebSphere
InterChange Server and the related software. The following steps list the order of
uninstalling relevant software
1. Uninstall JDK as the root user using smit, only if it is not required by other
products. For this release, the JDK is typically Java 2 SDK v.1.3.1. Contact
the system administrator for further assistance.
2. Uninstall WICS using the uninstaller located in the product directory once it is
certain that the previous version is no longer needed. After the uninstaller has
completed, the product directory can be deleted.
10.4 Without in-place database migration of V4.2.2 to
V4.3 on AIX
This section describes a without in-place database migration scenario and the
migration of Version 18.104.22.168 to Version 4.3.0. The 4.3.0 WebSphere InterChange
Server is started with a new and empty repository. Repository content
(component definitions) are exported from the original WebSphere InterChange
Server 4.2.2 version and deployed in WebSphere InterChange Server
Version 4.3.0 environment.
10.4.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.
390 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
All data is consistent between the integrated applications.
To put the 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 System Manager.
2. Resolve transactional status of transactional collaborations using the Flow
Manager. All status information is lost during the migration.
3. Resubmit failed events or discard the events using Flow Manager. Failed
flows are lost after migration.
4. When all events have been processed by the system, stop all collaborations.
To confirm that all events are processed, check the collaboration statistics in
System Manager. Be sure that the in-process and pending event counter is 0.
Backing up and shutting down components
This section describes the steps for shutting down and taking 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 WebSphere
InterChange Server 4.3.0.
Before starting the migration, ensure that the current WebSphere
InterChange Server is running at least at V22.214.171.124.
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