See information about the latest product version
Reviewing technical changes in WebSphere Message Broker Version 8.0
Some minor changes in behavior are present in WebSphere® Message Broker Version 8.0; for example, those changes that are caused by defects that were fixed between versions.
- Changes to user ID and password requirements
- Changes to location of description properties
- Default Configuration wizard and database usage on Windows
- Default execution group when you create brokers
- Starting and stopping execution groups
- Using SOAPAsyncRequest, SOAPInput, and SOAPRequest nodes
- Using HTTPS with HTTPInput and HTTPReply nodes
- Monitoring message flows
- ESQL field references with an index of zero
- Using RegistryLookup nodes
- Interfaces in the WebSphere Message Broker Toolkit
Message Broker API applications
Message Broker API applications that you develop in Version 8.0 can connect to your existing Version 7.0 brokers, and your existing Version 7.0 Message Broker API applications can connect to Version 8.0 brokers.
However, if you are migrating from Version 6.1, you must update your Message Broker API applications to use the file that is supplied by Version 8.0 before you can connect to a Version 8.0 broker.
For more information, see Migrating Message Broker API applications.
Record and replay
The record and replay feature can be used only with new Version 8.0 brokers, or brokers that you migrated to Version 8.0. It cannot be used with existing Version 7.0 or Version 6.1 brokers.
For more information, see Record and replay.
Resource statistics and message flow accounting and statistics XML publication messages
Resource statistics and message flow accounting and statistics XML publication messages are now published with an MQMD header, which has a FORMAT of MQSTR. This indicates that the publication message is composed entirely of character data.
If an WebSphere MQ JMS application is used to subscribe to the publication topic and read the messages, these messages are represented as a JMS TextMessage and not as a JMS BytesMessage.
Upgrade to ICU V4.8
WebSphere Message Broker Version 8.0 ships with ICU V4.8 (International Components for Unicode) for date, time, and codepage conversions. This is an upgrade from ICU 3.8.1, which was shipped with WebSphere Message Broker Version 7.0.
- Time zones that are invalid receive a BIP2319 response from the broker.
- Time zones that are now obsolete in ICU V4.8.1 are considered invalid. For example, "Alpha Time" and "Bravo Time".
- Date and time formatting that uses the pattern "zzz" might now return a time zone ID that implicitly represents a time zone and offset from GMT rather than "GMT" plus an offset.
- Codepages 897, 1277 and 5297 are no longer supported.
The following behavioral changes apply only if you are migrating from Version 6.1.
Changes to user ID and password requirements
- The requirement for a service user ID and password is removed
on all systems except Windows.
These parameters (-i, -a) are no longer used
when you migrate your brokers to Version
8.0.
If you restore a Windows broker to an earlier version, the password value is restored with the broker. If you changed the password by using the mqsichangebroker command, the updated value is set in the previous version.
- Because the Version
8.0 broker
has no requirement for a database, the parameters to define and change
database user IDs and passwords are removed.
If you configured database user IDs and passwords for the brokers that you are migrating, these parameters (-u, -p) are migrated with the broker, and are used as default values for data sources (user databases) for which you do not set explicit values. If you have not configured -u, -p, the values for -i, -a are migrated. In Version 8.0, you can manage these user IDs and passwords for your user databases by using the mqsisetdbparms command.
- The requirement for the broker service user ID to be a member of the mqm group is removed.
- If you change the database user ID and password by using the mqsisetdbparms command, you no longer need to restart the broker. You can instead restart the affected execution group by using the mqsireload command.
Changes to location of description properties
Long and short description properties of deployed Message Broker artifacts were not held in the deployed execution group repository, so they are not migrated to the Version 8.0 broker.
If the following fields were used to hold keywords, they are not displayed in the migrated artifacts:
$MQSI name = value MQSI$
To correct this behavior, redeploy the artifacts directly to the Version 8.0 broker.
For more information about defining keywords, see Guidance for defining keywords.
Default Configuration wizard and database usage on Windows
Some of the sample programs use a database; for example, the Airline sample. If you used the Default Configuration wizard to set up a default configuration on Windows, and deploy samples to the default broker, the samples that require a database use the Derby database that is embedded in the broker. Version 8.0 does not ship or support the Derby database. You must reconfigure your database samples by following the updated instructions in the samples documentation.
Default execution group when you create brokers
When you create a broker by using the mqsicreatebroker command, a default execution group is no longer created.
If you use either the WebSphere Message Broker Toolkit or the WebSphere Message Broker Explorer to create a broker, you can select an option to create a default execution group with the name default (unless you specify another name).
You can also create execution groups by using the mqsicreateexecutiongroup command.
Starting and stopping execution groups
Starting and stopping execution group behavior is updated in Version 8.0. When you start or stop an execution group by using the mqsistartmsgflow or mqsistopmsgflow commands without the -m parameter, the execution group process is stopped or started. When you stop the execution group in this way, or by using the WebSphere Message Broker Toolkit, or the WebSphere Message Broker Explorer, the run state of the message flows deployed to the execution group is recorded. When you next start the execution group only those message flows that were running when the execution group was stopped are restarted, unless you specifically request all flows to be started, or use the -j parameter on the command.
Using SOAPAsyncRequest, SOAPInput, and SOAPRequest nodes
The Failure action property of the SOAPAsyncRequest, SOAPInput, and SOAPRequest nodes is changed to be not configurable. If you configured this property, for example in a BAR file, the setting is ignored.
Using HTTPS with HTTPInput and HTTPReply nodes
The Version 8.0 broker checks for required SSL configuration when you run the mqsistart command.
If you deployed a message flow that includes HTTPInput or HTTPReply nodes to a Version 6.1 broker, and you migrate the broker to Version 8.0 and start the broker again, you might see the following error message generated. (Message lines are continuous, but are split to improve readability).
BIP3135S: An exception occurred while starting the servlet engine connector.
Exception text is HTTP Listener LifecycleException:
Protocol handler start failed: java.io.FileNotFoundException: /home/leed/.keystore
(No such file or directory)
at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1529)
at com.ibm.broker.httplistener.ConnectorWrapper.start(ConnectorWrapper.java:166)
at com.ibm.broker.httplistener.TomcatWrapper.startSecureHTTPSConnector
(TomcatWrapper.java:146)
at com.ibm.broker.httplistener.HTTPListenerManager.ensureServletContainer
(HTTPListenerManager.java:290)
at com.ibm.broker.httplistener.HTTPListenerManager.run(HTTPListenerManager.java:153)
at java.lang.Thread.run(Thread.java:735) :
DANBRK.httplistener: /build/S000_P/src/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 732:
ensureServletContainer: :
Oct 13 13:47:16 partick user:err|error WebSphere Broker v8000[303572]:
(DANBRK.default)[1]BIP2275E: Error loading message flow 'ef2a0606-2401-0000-0080-984a4915984c'. :
DANBRK.de427601-2401-0000-0080-d525e90f1528: /build/S000_P/src/DataFlowEngine/ImbDataFlowDirector.cpp:
2957: ImbDataFlowDirector::loadAllDataFlowsFromDatabase:
ExecutionGroup: de427601-2401-0000-0080-d525e90f1528
This error is generated because the Version 8.0 broker detects that you configured the HTTP nodes in the message flow to use HTTPS, but you did not configure the required SSL configuration; the broker does not load the message flow. In previous versions, this check is not performed and no error is generated.
To resolve this error, configure your HTTP nodes to use SSL, and redeploy the message flow. For SSL configuration information, see Configuring HTTPInput and HTTPReply nodes to use SSL (HTTPS).
Monitoring message flows
The default behavior for publishing monitoring events is changed. In versions before Version 8.0, monitoring events are emitted out of sync point. Now, the default for all events except transaction rollback is that events are emitted only if the message flow commits its unit of work successfully. By default, transaction rollback events are emitted in a second unit of work, independent of the main unit of work.
These changes mean that you no longer see events that are backed out because of a failed message flow; you see only the transaction start event and the transaction rollback event, if these events are defined. You also see all other events that are defined to be in an independent unit of work. See Monitoring basics for more information.
A sequence number is added to the eventSequence element of the monitoring event. Because both the creation time and sequence number are always emitted in the monitoring event, the Sequence tab is removed from the monitoring tab in the WebSphere Message Broker Toolkit.
ESQL field references with an index of zero
The validity of using a field reference index of zero is corrected. If you have statements in your ESQL modules that include an index of zero, error BIP3226E is generated when you deploy the message flow.
For example, if you have code that contains the statement:
SET OutputRoot.XMLNSC.Top.A[0].B = 42;
You must update the code to contain the following content:
SET OutputRoot.XMLNSC.Top.A[1].B = 42;
Using RegistryLookup nodes
The default for the Depth Policy property of the RegistryLookup node is changed from the value Return matched showing immediate relationships (for compatibility only) in Version 6.1 to the value Return matched only (Depth = 0) in Version 8.0.
If you do not explicitly set this property on a RegistryLookup node, it uses the default value Return matched only (Depth = 0) to determine the depth of the WSRR query and the contents of the entity data to be returned.
If you want to use the node in deprecated mode in Version 8.0, you must explicitly set the Depth Policy property to the value Return matched showing immediate relationships (For compatibility only), and rebuild the BAR file.
For more information about the RegistryLookup node and its properties, see RegistryLookup node.
Interfaces in the WebSphere Message Broker Toolkit
The following changes are present in the WebSphere Message Broker Toolkit:
- Problems view
- In WebSphere Message Broker Toolkit Version 6.1, you can configure the list of problems that are shown in the Problems view by clicking either the icon on the Problems view pane bar, or the down arrow next to the icon, and selecting Configure filter from the list of options displayed. In WebSphere Message Broker Toolkit Version 8.0, the icon is no longer shown. Click the down arrow that is shown at the right end of the bar, and select Configure contents.
- Broker Development view
- In WebSphere Message Broker Toolkit Version 8.0, the Broker Development view shows pattern instance projects in a separate pane, in addition to other projects in your workspace.
- Broker administration perspective
- In WebSphere Message Broker Toolkit Version 6.1, you can connect, configure, and deploy to brokers by using the Broker administration perspective in the WebSphere Message Broker Toolkit. In Version 8.0, the Broker Administration perspective is removed, and you can now connect, configure, and deploy to brokers by using the Brokers view in the Broker Application Development perspective. For more advanced configuration tasks, you can use the WebSphere Message Broker Explorer.
- Event Log viewer
- In WebSphere Message Broker Toolkit Version 6.1, deployment responses and messages from the broker are displayed in the Event Log viewer. In Version 8.0, deployment messages from your instance of the WebSphere Message Broker Toolkit are displayed in the Deployment Log view, in the Broker Application Development perspective.
- Command assistants
- In WebSphere Message Broker Toolkit Version 6.1, you can use the command assistants to create, change, and delete components such as brokers on your local system. In Version 8.0, you can use the Brokers view to create and delete components. Alternatively, you can use the WebSphere Message Broker Explorer to create, change, and delete brokers on your local system.
- XPath Expression Builder
- In WebSphere Message Broker Toolkit Version 6.1, the Data Types Viewer shows two top-level categories, Data Types and Variables. In Version 8.0, you can find the variables under the single top-level category Data Types.
Default trace for the admin agent
In WebSphere Message Broker Version 7.0.0.2 the default trace size for the admin agent was changed from 4 MB to 100 MB. If you are migrating from WebSphere Message Broker Version 7.0.0.1 or earlier, you must take this default size into consideration.