WebSphere MQ and migration to IBM Integration Bus Version 10.0

Options for WebSphere MQ integration when you migrate to IBM® Integration Bus Version 10.0.

Support for WebSphere MQ is extended in IBM Integration Bus Version 10.0, introducing greater flexibility in the interactions between IBM Integration Bus and WebSphere MQ; see Enhanced flexibility in interactions with WebSphere MQ and WebSphere MQ topologies.

As part of your migration process, you might want to configure your IBM Integration Bus Version 10.0 deployment to take advantage of the greater flexibility.

In IBM Integration Bus Version 9.0 or earlier, the integration layer of your architecture must contain WebSphere MQ queue managers. If you have WebSphere MQ queues that you use in integration applications, you must have an existing WebSphere MQ topology in which application messages are routed to the queue manager that is specified on the integration node by using WebSphere MQ channels, remote queue definitions, and distributed messaging. It might be possible to simplify your system so that your message flows interact directly with remote queue managers, which might simplify the WebSphere MQ topology that you need to manage. This simplification requires that you redesign your message flows and your WebSphere MQ topology, and is more than just a migration of your existing solution. However, you might want to include these activities as part of your migration plans.

To determine which components of your existing deployment are using capabilities that require WebSphere MQ queue managers to be a part of the integration layer of your IBM Integration Bus Version 10.0 architecture, and which components are using capabilities that can integrate with WebSphere MQ application queues on a remote queue manager, see Installing WebSphere MQ.

Depending on whether you can change your WebSphere MQ topology during the migration process, you have the following options for migrating integration nodes:

  • Upgrade your existing integration node The existing configuration is retained; the integration node is associated with the same queue manager, and the WebSphere MQ application endpoints and WebSphere MQ topology remain the same (in-place migration).
  • Create a new Version 10.0 integration node and associate the integration node with a new queue manager. Add the new queue manager into your WebSphere MQ network, migrate the applications from the original integration node, and redirect application queues as required (parallel migration).
  • Create a new Version 10.0 integration node and associate the integration node with the same queue manager as the original integration node. Migrate the applications from the original integration node, and keep the WebSphere MQ application endpoints and WebSphere MQ topology the same (parallel migration).
    Note: This option cannot be used if your integration node has message flows that contain the following message flow nodes: AggregateControl, AggregateReply, AggregateRequest, Collector, Sequence, Resequence, TimeoutControl, or TimeoutNotification nodes; these nodes use MQ queues to save state, which cannot be shared between integration nodes.
  • Distributed systems only: Create a new Version 10.0 integration node and do not associate the integration node with a queue manager. Migrate the applications from the original integration node, and configure message flows that require WebSphere MQ queues to connect to specified queue managers, either by directly configuring the message flow or by using a policy (parallel migration).
    Note: If your IBM Integration Bus deployment runs on z/OS®, you must still associate your integration node with a queue manager.

For information about in-place migration and parallel migration, see Integration node migration options.