bh44620_.htm |
Last updated Friday, 21 July 2017Some minor changes in behavior are present in IBM® Integration Bus Version 9.0 if you are migrating from Version 7.0 or Version 6.1; for example, those changes that are caused by defects that were fixed between versions.
Timezones might now display in additional places but you can revert to the original behavior if required:
mqsichangeproperties NODENAME -e ISNAME -o ComIbmGenericXmlParserFactory -n storeTimeZoneInValue -v nomqsichangeproperties NODENAME -e ISNAME -o ComIbmGenericXmlParserFactory -n writeTimeZone -v OPTION| Value | Description |
|---|---|
| never | Do not display any timezones. |
| nonUTC | Display all timezones except for UTC |
| nonLocal | Display all timezones except for the local timezone |
CMP applications that you develop in Version 9.0 can connect to your existing Version 8.0 and Version 7.0 brokers, and your existing Version 8.0 and Version 7.0 CMP applications can connect to Version 9.0 brokers.
However, if you are migrating from Version 6.1, you must update your CMP applications to use the file that is supplied by Version 9.0 before you can connect to a Version 9.0 broker.
For more information, see Migrating CMP applications.
The record and replay feature can be used only with Version 9.0 or Version 8.0 brokers, or brokers that you migrated to Version 9.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 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.
IBM Integration Bus version 9.0.0.7 ships with ICU V51.2 (International Components for Unicode) for date, time, and codepage conversions.
The product has a default codepage that is used for syslog output and for Trace node output that is written to a file. On UNIX systems, this default codepage is derived from the locale of the shell that starts the integration node. The ICU upgrade might result in a different default codepage being set for some locales. If this result causes problems in Trace node or syslog output, you can change the locale as described in the topic Changing your locale on Linux and UNIX systems.
The following behavioral changes apply only if you are migrating from Version 6.1.
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 (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 9.0, you can manage these user IDs and passwords for your databases by using the mqsisetdbparms command.
Long and short description properties of deployed IBM Integration artifacts were not held in the deployed integration server repository, so they are not migrated to the Version 9.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 9.0 broker.
For more information about defining keywords, see Guidance for defining keywords.
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 9.0 does not ship or support the Derby database. You must reconfigure your database samples by following the updated instructions in the samples documentation.
When you create a broker by using the mqsicreatebroker command, a default integration server is no longer created.
If you use either the IBM Integration Toolkit or the IBM Integration Explorer to create a broker, you can select an option to create a default integration server with the name default (unless you specify another name).
You can also create integration servers by using the mqsicreateexecutiongroup command.
Starting and stopping integration server behavior is updated in Version 9.0. When you start or stop an integration server by using the mqsistartmsgflow or mqsistopmsgflow commands without the -m parameter, the integration server process is stopped or started. When you stop the integration server in this way, or by using the IBM Integration Toolkit, or the IBM Integration Explorer, the run state of the message flows deployed to the integration server is recorded. When you next start the integration server only those message flows that were running when the integration server was stopped are restarted, unless you specifically request all flows to be started, or use the -j parameter on the command.
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.
The Version 9.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 9.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-d525e90f1528This error is generated because the Version 9.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).
The default behavior for publishing monitoring events is changed. In versions before Version 9.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 IBM Integration Toolkit.
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;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 9.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 9.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.
The following changes are present in the IBM Integration Toolkit:
Last updated Friday, 21 July 2017