Reviewing technical changes in IBM Integration Bus Version 10.0

Some minor changes in behavior are present in IBM® Integration Bus Version 10.0; for example, those changes that are caused by defects that were fixed between versions.

If you are migrating from Version 9.0, read the following sections to understand the potential effects on your integration nodes and message flows::
If you are migrating from Version 8.0, read the following sections to understand the potential effects on your integration nodes and message flows::
If you are migrating from Version 7.0, read the following sections to understand the potential effects on your integration nodes and message flows:

Improvements in DFDL schema validation

The IBM implementation of DFDL has added extra validation checks to comply with the DFDL 1.0 specification. When a DFDL schema that is created in a previous version of IBM Integration Bus or WebSphere® Message Broker is validated in the IBM Integration Toolkit or during deployment, errors are reported under the following conditions:
  • The DFDL property length of an element must not exceed the capacity of the element's simple type. If the validation fails, the following error is generated: CTDV1534E. To prevent the error, change the simple type of the element so that it can cope with the length. For example, if a "two's complement" binary number has the DFDL property length set to 8 and the type is xs:int, change the type to xs:long to clear the error.
  • When the DFDL property initiatedContent is set to yes on the parent sequence or choice, additional checks are made on elements and groups. If the validation fails, one or more of the following errors are generated: CTDV1561E, CTDV1560E, or CTDV1431E. To prevent the error, set initiatedContent to no on the parent sequence or choice. However, if a new error (CTDV1559E) then appears, contact IBM support for further advice.
  • When the parent sequence or choice is the content of a global group, and DFDL properties are placed on group references to the group, additional cross-checks are made between DFDL properties of elements and groups, and DFDL properties on the parent sequence or choice. If the validation fails, one or more of the following errors are generated: CTDV1150E, CTDV1118E, CTDV1432E, CTDV1446E, CTDV1466E, or CTDV1467E. To prevent the error, correct the schema in accordance with the indicated error.
  • When the DFDL property occursCountKind of an element is set to parsed, and the parent sequence has a separator, the DFDL property separatorSuppressionPolicy of the parent sequence must be set to anyEmpty. If validation fails, the following error is generated: CTDV1625E. To prevent the error, correct the sequence so that the DFDL property separatorSuppressionPolicy is set to anyEmpty, or change the element so DFDL occursCountKind is set to implicit.
  • The DFDL property fillByte must resolve to a single-byte value. If validation fails, the following error is generated: CTDV1458E. To prevent the error, correct the DFDL property fillByte to use a single DFDL entity that resolves to a single-byte value.

XMLNSC timezone handling

In versions before IBM Integration Bus Version 9.0, timezones are not passed between the XMLNSC parser and ESQL or other parsers. This behavior is corrected in Version 9.0 and later versions.
Note: If you use a Mapping node to map to elements that are defined as xs:date, xs:dateTime, or xs:time and you want the timezone included, you must set the environment variable MQSI_USE_TIMEZONE to any value.

Timezones might now display in additional places but you can revert to the original behavior if required:

  • To revert to the original behavior for parsing XML documents, run the following command:
    mqsichangeproperties NODENAME -e ISNAME -o ComIbmGenericXmlParserFactory -n storeTimeZoneInValue -v no
    where NODENAME is the name of your integration node and ISNAME is the name of your integration server.

  • To revert to the original behavior for writing XML documents, run the following command:
    mqsichangeproperties NODENAME -e ISNAME -o ComIbmGenericXmlParserFactory -n writeTimeZone -v OPTION
    where OPTION has one of the following values:
    Table 1. Options for the -v flag
    Value Description
    never Do not display any timezones.
    nonUTC Display all timezones except for UTC
    nonLocal Display all timezones except for the local timezone

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.

Note: If required, you can revert to using a JMS BytesMessage format by setting the following environment variable: MQSI_STATS_MQSTR=false.

Upgrade to ICU V51.2

IBM Integration Bus Version 10.0 ships with ICU V51.2 (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.

This upgrade results in the following responses:
  • Time zones that are invalid receive a BIP2319 response from the integration node.
  • Time zones that have been obsolete since 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 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.