Ever since the end of support date for WebSphere Message Broker (WMB) V6.0 was announced, we have been receiving a lot of queries on migration from the older versions of Message Broker to the latest WMB V7.0. In this blog, I have tried to address some common questions around migration.
You can migrate from your existing Message Broker components and its resources to WMB V7.0 in a streamlined fashion. You can also reverse migrate from a WMB V7.0 broker to the older version of broker provided you first migrated from this older version to V7.0 on that machine.
Simplicity of WMB V7.0: WMB V7.0 has fewer components to deal with. Some of the key components that no more exist are:
- Configuration Manager
- Broker database
- UserNameServer and Publish Subscribe
Fewer components make it easier to administer, manage and troubleshoot the WMB V7 product.
New features in WMB V7.0: New WMB V7.0 features enable the Administrators and Developers to work faster and effectively even in complex environments. Some of the new key features include:
- Pattern instances
- WebSphere Message Broker Explorer
- Clustering and Multi-instance brokers
- Monitoring and gathering statistics data
- Improved integration with Adapters (SAP, PeopleSoft and Siebel), WPS (WebSphere Process Server), WBM (WebSphere Business Monitor)
Co-existence and Interoperability
WMB V7.0 can co-exist with previous versions of Message Broker. Different versions of Message Broker can co-exist and run independently on the same servers as long as they are installed in different directory locations. You need to ensure that the broker names running in different versions are distinct though. You can also install multiple instances of the same version of WMB on the same machine, each in its own separate directory, including the broker with different FixPack levels. For example, V126.96.36.199 and V188.8.131.52 can co-exist on the same machine.
WMB V7.0 can co-exist with its previous versions with following considerations:
- The broker component can co-exist with runtime components at V6.0 and V6.1.
- WMB V7.0 Toolkit can co-exist with the toolkit at V6.0 and V6.1.
- WMB v7.0 Explorer and Toolkit work only with brokers created at V7.0 level or brokers that are migrated to V7.0.
- BAR files are upward compatible only. You cannot deploy a BAR file with WMB V7.0 resources to V6.x brokers
- WMB Explorer Plug-in support pack (IS02) cannot co-exist with WMB Explorer V7.0
Coexist table - (Click image to enlarge)
Supported migration paths
You can migrate to WMB V7.0 from previous versions of the following products:
- WebSphere Message Broker V6.1 (FP03 or later)
- WebSphere Message Broker RFE V6.1 (FP03 or later)
- WebSphere Message Broker V6.0 (FP9 or later)
- WebSphere Message Broker RFE V6.0 (FP9 or later)
- WebSphere Event Broker V6.0 (FP9 or later)
You cannot migrate any of the above products from Windows on x86 (any version) to Windows on x86-64 platform. On this platform, you must recreate the brokers from scratch.
Migrating the Development components
Generally, Toolkit components do not have to be explicitly migrated. You do not need to perform any specific tasks to migrate your development and deployment resources, such as message flows, message sets, ESQL, XML schemas, and BAR files. However, you are required to migrate your user-defined node source projects developed in the previous versions of Toolkits, before importing them in V7 Toolkit.
You can simply install WMB V7.0 Toolkit and point its workspace location to the Toolkit v6.x workspace. The V7.0 Toolkit will migrate the artifacts before opening it.
Alternatively, you can export V6.x projects into project interchange files and import these project interchange files directly into V7.0 Toolkit. The V7.0 Toolkit will automatically convert them to V7.0 format when you modify and save them for the first time. These resources can then be deployed to V7.0 broker.
WMB V7.0 Toolkit works only with brokers created at WMB V7 or the brokers that are migrated to V7.0. You cannot deploy resources from the WMB Toolkit V7.0 to brokers at previous versions.
WMB V7.0 Toolkit offers a unique feature of quick fixing certain types of warnings and errors after migration of the development resources. The types of warnings or errors that can be cleared using a quick fix are those where the construct has a broken link or where the construct has a facet that is not legal, or where the construct has been imported, and where a warning or error has occurred, but has been kept to ensure the integrity of structure that is being imported.
To apply the quick fix, you can follow these steps:
- Switch to Broker Application Development perspective.
- Ensure that the Problems view is visible in the Broker Application Development perspective of the WMB Toolkit. If the Problems view is not visible, from the WMB Toolkit menu, click Window > Show View > Problems.
- In the Problems view, right-click the task list warning or error that you want to apply the quick fix to, then click quick fix. Note that quick fix might not be available for the problem that you are trying to fix.
- Step through the windows that are displayed, making the selections that are required to ensure that the fix is applied in the appropriate way.
When the quick fix has successfully been applied to the task list warning or error, it is removed from the Problems view.
Migrating the runtime components
Since the configuration manager no longer exists in WMB V7, the only runtime component that needs to be migrated is the broker. The configuration manager ACLs that allow Toolkit connectivity for users and groups can be migrated to V7.0, but all the users and groups have to be manually granted read, write and/or execute authorizations based on the broker administration security feature in V7.0, that are equivalent to V6.x configuration manager ACL authorizations.
If you are using publish/subscribe and/or UserNameServer with topic-level security at your current WMB V6.x level, then you would need to migrate the subscriptions and publish/subscribe ACLs as well. WebSphere MQ must be upgraded / migrated to WMQ V7.0.1 before migrating Message Broker. This is because the publish/subscribe functionality is provided by the publish/subscribe engine which now exists in WMQ V7.0.1.
Note: When you migrate a broker to V7.0, all live data that is being stored for aggregations in progress is lost. Therefore, ensure that you have no aggregations in progress on your existing broker.
You can follow these steps for migrating your V6.x broker to V7.0:
- Migrate/Upgrade WMQ to V7.0.1
- Stop and backup your V6.x broker and its database.
- Install WMB V7.0 and run the steps below from V7 command line.
- Migrate your WMB V6.1 subscriptions and publish/subscribe Topic ACLs (if any) into WMQ V7.0.1 using the following commands:
a. migmbbrk -r <broker name>
b. migmbbrk -t –z <broker name>
c. Edit and run the commands from the amqmigrateacl.txt (generated in the previous steps) on the broker queue manager to recreate the topic and subscription security defined in the topic ACLs. This will migrate the ACLs from V6.x broker to V7.0.1 queue manager.
d. migmbbrk –c -z <broker name>
This will migrate the subscriptions and ACLs from V6.1 broker to V7.0.1 queue manager.
- If you are using application databases such as DB2, Oracle etc. with the existing WMB V6.x, then you would need to update your ODBC definitions to V7.0 format:
a. Point the database to the new ODBC drivers in ODBC DataSource Administrator (Windows) or odbc.ini (UNIXes)
b. For DB2 and Informix, ensure that the broker service Id’s environment contains the respective database client library references in the library path environment variable.
- Run the mqsimigratecomponents command to migrate the broker from WMB V7.0 command environment:
mqsimigratecomponents <broker name>
This will migrate your V6.x broker to V7.0 and all the message flows. You can uninstall WebSphere Message Broker V6.x and drop the old broker database (if you need to). However, then you won’t be able to migrate back to the older version.
Note: On the AIX®, Linux x86-64, and Solaris on SPARC platforms, support has changed from both 32-bit and 64-bit support to just 64-bit support only. This means that the 32-bit execution groups are converted to 64-bit as a part of migration on these platforms. Therefore, these platforms would now require 64-bit libraries and 64-bit ODBC configurations for the databases. The 32-bit execution group support is limited to Windows and Linux x86 environments only, so migration on these platforms would preserve the execution group bitness.
If you are using any custom plugin nodes, then you would need to do the following:
- Recompile C/C++ user-defined nodes, parsers, and exits to 64-bit, if the existing ones are 32-bit only.
- Configure the broker to point at these recompiled extensions by using the following command:
mqsichangebroker -l <userLilPath> -x <userExitPath>
where userLilPath defines one or more paths to your LIL files, and userExitPath defines one or more paths to your user exit programs.
Additionally, once you have completed your migration to WMB V7.0, it is advisable to review the post-migration tasks listed in the WMB V7 Information Center. This would help you analyze your WMB environment and see if there is any specific need or changes that you may expect or additional tasks that you may need to perform after migrating to WMB V7.0.
Hopefully, this blog has provided you with some migration pointers and an upgrade approach that would help you in your environments. Let me know if you have any questions.
WebSphere Message Broker V7.0 Information Center
Connecting Your Business Using IBM WebSphere Message Broker V7 as an ESB