Learn about the main new functions in IBM® Integration Bus Version 10.0.
IBM Integration Bus is a compatible evolution of WebSphere® Message Broker that is designed to incorporate features that are found in WebSphere Enterprise Service Bus. IBM Integration Bus provides a universal integration capability that addresses a wide range of integration scenarios. These scenarios include web services such as SOAP and REST, messaging, database, file, ERP systems, mobile, physical devices, email, custom systems and more.
If you are migrating from WebSphere Message Broker Version 8.0, also see What else is new if you are migrating from Version 8.0?.
If you are migrating from WebSphere Message Broker Version 7.0, also see What else is new if you are migrating from WebSphere Message Broker Version 7.0?.
If you are migrating from WebSphere Enterprise Service Bus, also see What's new in IBM Integration Bus for WebSphere Enterprise Service Bus users?.
For more information, see Installing IBM Integration Bus software.
The Tutorials Gallery is included with the IBM Integration Toolkit, and is accessible from the Welcome page and from the Help menu. The Tutorials Gallery provides access to a number of tutorials that are stored on a GitHub repository, and automatically displays new tutorials when they are added to the GitHub repository.
From the Tutorials Gallery you can download, deploy, and test sample integration solutions, and then explore the configuration of the solution components to learn how to develop integration solutions of your own.
Shared libraries are introduced to share resources between multiple applications. Libraries in previous versions of IBM Integration Bus are static libraries.
If you use a static library to contain resources, each application that references that static library is deployed with its own private copy of that library. If a static library is updated, each application that references it must be redeployed with the updated static library. A shared library is deployed directly to an integration server. Any application can reference the resources in that deployed shared library. If that shared library is updated, the changes are immediately visible to all referencing applications.
For more information, see Shared libraries.
MQ Telemetry Transport (MQTT) is a lightweight publish/subscribe messaging protocol. You can now use IBM Integration Bus to connect to applications and devices that send and receive messages by using the MQTT messaging protocol.
You can create message flows to receive an MQTT message by using the MQTTSubscribe node to subscribe to one or more topics on an MQTT server. You can send an MQTT message by using the MQTTPublish node in your message flow to publish messages to a topic on an MQTT server.
For more information, see Processing MQTT messages.
WebSphere MQ is no longer a prerequisite for using IBM Integration Bus on distributed platforms, which means that you can develop and deploy applications independently of WebSphere MQ. You can also run and administer integration nodes without requiring the WebSphere MQ Explorer.
When you purchase a license for IBM Integration Bus, your license entitles you to install and use WebSphere MQ with IBM Integration Bus, enabling you to use the IBM Integration Bus capabilities that require MQ functionality, such as the MQ nodes and event driven processing capabilities such as message aggregation and sequencing.
For more information about using WebSphere MQ with IBM Integration Bus, see Enhanced flexibility in interactions with WebSphere MQ.
If you are not using WebSphere MQ with IBM Integration Bus, you can use the built-in MQTT pub/sub broker or an external MQTT server to publish integration node event messages. If you have installed WebSphere MQ, you can use the built-in MQTT broker, an external MQTT server, or a queue manager as your pub/sub broker. For more information about using MQTT for publish/subscribe functions, see Publishing event messages and Configuring the built-in MQTT broker.
On distributed systems, support for WebSphere MQ has been extended, introducing greater flexibility in the interactions between IBM Integration Bus and WebSphere MQ. You can configure local or client connections to WebSphere MQ, enabling your integration nodes to get messages from or put messages to queues on any local or remote queue manager. On z/OS®, you can have MQ message flow nodes connect to different local queue managers, not just the queue manager that is specified on the integration node.
You can specify a connection from an MQ node to a specific local or remote queue manager by using connection properties on the MQ node, including the destination queue manager name, host name, port, and channel. Alternatively, you can specify a queue manager on the integration node to be used for MQ processing that is required by flows in the integration node; the queue manager that you specify is then used for all message flow nodes that do not have queue manager connections explicitly defined or policies attached. For more information about policies, see Operational policy.
You can also create message flows that contain multiple MQInput and MQOutput nodes, each of which can access different queue managers as specified in the node; this enables you to adapt your message flows to your existing WebSphere MQ topologies. For more information about local and client connections between WebSphere MQ and IBM Integration Bus, see Configuring connections to WebSphere MQ.
You can choose between two modes of authorization when you enable administration security on an integration node: file-based authorization (file mode) or queue-based authorization (mq mode). You can specify your chosen authorization mode by using the mqsichangeauthmode command. If you configure the integration node to use file mode, you can set file-based permissions for accessing integration nodes and resources. These permissions are set using the mqsichangefileauth command. Alternatively, if you have installed WebSphere MQ and specified a queue manager on the integration node, you can control access to the integration node and its resources by setting permissions on WebSphere MQ authorization queues.
For more information, see Configuring administration security to use file-based or queue-based authorization.
When you configure a connection from an MQ node to a WebSphere MQ queue manager, you can optionally configure the connection to use a security identity for authentication, SSL for confidentiality, or both. The security identity, which passes user name and password security credentials to the queue manager, can be used on connections to local or remote queue managers. For connections to remote queue managers, you can choose whether to use the SSL protocol to provide confidentiality on the client connection. IBM Integration Bus supports a subset of the SSL functionality that is supported by WebSphere MQ. For more information, see Connecting to a secured WebSphere MQ queue manager.
You can return a list of parameters that are set on an integration node. In addition, you can use the mqsireportdbparms to check if security credentials are set, or identify if you are using the correct password for an integration node.
For more information about using the mqsireportdbparms command, see mqsireportdbparms command.
For more information, see IBM Integration Bus web user interface.
For more information, see Testing your message flow by using the Flow exerciser.
ODBC database drivers now have a fixed naming convention, which means that you do not have to update links to drivers and switch files after you update to a later version.
For more information, see Updating ODBC definitions when you migrate to IBM Integration Bus Version 10.0.
For more information about REST APIs, see Developing integration solutions by using REST APIs.
For more information about configuring an SQL Server database, see Creating and configuring a Microsoft SQL Server database for recording data.
For more information about IWA, see Integrated Windows Authentication.
For more information about CORS, see Cross-Origin Resource Sharing.
You can also use user-defined elements to define a JSON message, and a SOAP or XML message that has an xsd:any.
You can add, reuse, rename, transform, and delete a user-defined element directly into your message map during the development phase.
For more information, see Mapping user-defined elements.
For more information, see Mapping the environment tree.
You can use the Graphical Data Mapping editor to create a JSON message, or to transform a JSON message.
For more information, see Transforming a JSON message in a message map.
You can use the Graphical Data Map Specification Language to create a message map programmatically.
For more information, see Creating a message map programmatically.
Use operational policies to control the operational behavior of certain MQ and MQTT message flow nodes within message flows, without the need to redeploy your resources. A policy can be attached to one or more nodes in a message flow to control the values of a specific set of message flow node properties, such as connection credentials, at run time.
For more information, see Operational policy.