114 WebSphere InterChange Server Migration Scenarios
Figure 7-2 shows the Windows environment setup before and after the migration.
Figure 7-2 Windows environment setup
During migration the previous WebSphere InterChange Server is uninstalled and
replaced by Version 4.3. The WebSphere InterChange Server names, queue
manager names, and database names were not changed during migration.
Because of this the content of Figure 7-2 is valid for the pre-migration and
post-migration environment.
The RELAT databases were used for the relationships and the connection pool.
7.2 Migrated test cases
To test the success of the migration process, some common key features of the
WebSphere InterChange Server were implemented in several test scenarios.
The scenarios were simplified to represent only one specific feature to avoid side
effects during the migration process. For the sake of consistency, the Visual Test
Connector is used to represent the adapter agent in all scenarios.
The following sections describe the test cases we used in more detail.
7.2.1 Long Lived Business Process
The Long Lived Business Process scenario has been implemented in
WebSphere InterChange Server Version 4.2.1 and 4.2.2 only because this
feature is not available in Version 4.1.1. The collaboration gets a business object
ICS instance:
Queue manager:
ICS instance:
Queue manager:
Toolse t
ICS instance:
Queue manager:
Toolse t
Chapter 7. Project environment setup 115
from the source adapter, including an attribute used to store the transaction
identifier. This business object is sent to the destination adapter, and the
collaboration waits for a response at another port configured for asynchronous
inbound calls. This scenario is used to test the Long Lived Business Process
functionality after migration. In addition, flows were migrated that were in waiting
status to check whether the response is accepted after migration. To test this, a
time-out has been set to seven days for the asynchronous inbound port.
7.2.2 CustomerSync collaboration including relationships
The customer sync collaboration represents the CustomerSync collaboration
offered by IBM. In addition, a dynamic relationship and a static relationship are
used in the map to:
򐂰 Maintain a relation between the two application key values (dynamic
򐂰 Look up the country code that is represented by different values in the two
applications (static relationship).
The purpose of this test case is to verify the migration of a commonly used
collaboration and static/dynamic relationships.
7.2.3 Connection pool
The collaboration uses a connection pool to insert a row into a table in a DB2
database. The entry is based on the content of the business object for monitoring
the events running through the collaboration. It is used to check the migration of
connection pools and the API call using the connection pool.
7.2.4 Collaboration group
The collaboration group consists of two simple passthrough collaborations. This
group is used to check the migration of collaboration groups. The focus is to
observe the behavior of the collaboration group after migration regarding failed
flows and administrative commands (start, stop, pause, and change properties)
compared to the previous version.
7.2.5 Polymorphic map
A polymorphic map is used to determine which map is called based on the
contents of the application-specific business object. This results in two different
generic business objects calling different collaboration objects. The polymorphic
map is used to check the polymorphic mechanism and the explicit binding of
maps after migration.

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.