New function added in Version 10.0 fix packs

You can authorize roles in IBM Integration Bus against a Lightweight Directory Access Protocol (LDAP) or Secure LDAP (LDAPS) server. You can grant and revoke administration authority for an integration node and each of its managed integration servers by configuring LDAP authorization for specified groups or attributes in LDAP to specified roles in IBM Integration Bus.

For more information, see Configuring authorization by using LDAP groups.

For more information, see Enabling the exception log.

For more information, see Group nodes and aggregation nodes.

You can configure your message flows to use the FTPS transfer protocol when handling files. The Transfer protocol property on the FileInput, FileRead, and FileOutput nodes provides the option to select FTPS when you are working with files in a remote file system.

For information about working with files, see Working with files.

The Shareable subscription property is introduced on the JMSInput node to allow the creation of shared subscription when working with a JMS 2.0 compliant provider.

For more information, see JMSInput node.

An AppConnectRESTRequest node is provided, which enables interaction between IBM Integration Bus and an App Connect REST API. The AppConnectRESTRequest node uses an imported Swagger document, which defines the REST API and the operations that are available. An App Connect REST Request pattern is also available, which you can use to configure the connection between IBM Integration Bus and the App Connect REST API.

For more information, see Connecting to an App Connect REST API.

The Java SDK that is provided on toolkit platforms, and the Java JRE that is provided on runtime-only platforms, have been upgraded to Java 8. This upgrade means that you can now deploy JAR files that have been built using Java 8 to the IBM Integration Bus runtime.

For more information, see IBM Integration Bus v10 support for Java 8.

Support is provided for running IBM Integration Bus in a Docker container. You can choose to build specific configurations into your IBM Integration Bus Docker images, such as integration servers that already have particular applications deployed, or you can choose to start up a Docker container from the image and then deploy changes to the running integration node.

You can create your own Docker images, or you can download an image of the IBM Integration Bus for Developers edition from https://hub.docker.com/r/ibmcom/iib/ and run this in a Docker container.

For more information, see Configuring IBM Integration Bus to run in Docker.

Support is provided for deploying the Developer Edition or Advanced Edition of IBM Integration Bus to the IBM private cloud, by using Helm Charts. The Developer Edition is available free of charge for evaluation, development, and test purposes, but not for use in a production environment. If you have purchased a license for IBM Integration Bus Advanced Edition, you can deploy that version of the product to IBM Cloud Private.

For more information, see Deploying IBM Integration Bus to IBM Cloud Private and Deploying IBM Integration Bus for Developers to IBM Cloud Private.

You can arrange for resource statistics to be written directly to the filesystem. If you enable this option, each resource manager writes a separate file that contains its resource statistics.

For more information, see Reporting resource statistics to files.

The restriction on the import of Swagger documents that contain recursive self references is lifted and applies to situations when you do not intend to use graphical maps, or you intend to use mappings only by using a Move transform from input to output.

For more information, see Restrictions on Swagger documents.

The integration server XPath cache has been enhanced. You can now control the frequency with which activity log messages are emitted by the XPath cache. You can also opt to disable the cache and this action might be useful in a highly multi-threaded environment where many XPath expressions are evaluated on each message flow invocation and there might be thread contention on the cache.

For more information, see Configuring the XPath cache.

To facilitate the creation of connection files for use when you connect to remote integration nodes, you can now use the IBM Integration Toolkit to export the connection details of a remote integration node to a .broker file.

For more information, see Connecting to a remote integration node.

The mqsicvp command is extended to allow you to perform CPU benchmark processing. The benchmark tests CPU performance by calculating a recursive, arithmetic sequence on one or more threads.

For more information, see mqsicvp command.

By using the Policy Set Bindings section of the editor in the IBM Integration Toolkit, you can specify that the password for an outbound username token is created in digest format instead of in plain text format. This option is applicable only to consumer bindings.

For more information, see Policy Sets and Policy Set Bindings editor: Authentication and Protection Tokens panel.

You can use the mqsisetdbparms command to provide the credentials in an httpproxy:: ResourceName. The ResourceName takes either the form httpproxy::proxyHostname, where proxy_hostname matches the host name specified in the HTTP(S) proxy location property on the node, or httpproxy::HTTPPROXY, which can be used as a default for any proxy server that does not have a matching httpproxy::proxyHostname setting.

For more information, see Routing requests through an HTTP proxy server that has authentication enabled.

You can configure the SalesforceRequest node to send requests through an HTTP proxy server, by specifying the location of the proxy server on the HTTP(S) proxy location parameter.

If the HTTP proxy server has been configured to require authentication through a user name and password, you can use the mqsisetdbparms command to provide these credentials on the httpproxy:: resource name. For more information, see Routing requests through an HTTP proxy server that has authentication enabled.

The support for callable message flows has been extended to include support for asynchronously callable message flows. You can split processing between asynchronously callable flows by using the CallableFlowAsyncInvoke and CallableFlowAsyncResponse nodes. For more information, see Developing asynchronously callable message flows.

You can also choose to share data between the flows that contain these nodes (the calling flow and the response flow) by storing and retrieving data in the UserContext folder in the Environment. For more information, see Sharing data between a calling flow and a response flow.

The KafkaConsumer node and KafkaProducer node have been enhanced to include support for the key environment variable, which you can use to associate a string value with a message when it is published. If a message is published to a topic with multiple partitions, the key value can be used to select the partition on which the message is stored. All messages published using the same key value are sent to the same partition. If no key is provided, messages are distributed across the topic partitions by Kafka.

For more information, see Processing Kafka messages and Using local environment variables with Kafka nodes.

You can share data between flows that contain RESTAsyncRequest and RESTAsyncResponse nodes, by storing and retrieving data in the UserContext folder in the local environment. You specify the context data to be stored by the RESTAsyncRequest node, and this data can later be accessed by the RESTAsyncResponse node.

For more information, see Using local environment variables with REST nodes.

The JSON schema keyword "allOf", which is used for combining schema type definitions, is fully supported in JSON schema files and REST API Swagger documents referenced from a message map. For more information, see Creating or transforming a JSON message by using a JSON schema.

The support for JSON schema keywords "anyOf" and "oneOf", which are used for combining schema type definitions in JSON schema files and REST API Swagger documents, has been extended. For more information, see Casting with JSON schema types and JSON schema requirements for message maps.

For more information, see Processing Kafka messages.

A set of REST request and response nodes are provided, enabling you to interact with external REST APIs. You can use the RESTRequest node to issue synchronous requests to external REST APIs. Alternatively, you can use the RESTAsyncRequest node with the RESTAsyncResponse node to construct a pair of message flows that interact asynchronously with an external REST API. For more information, see Connecting to external REST APIs.

Additionally, JSON types from both JSON schema and REST Swagger documents are available for performing mapping casts, enabling you to work with REST request nodes that place data in the environment tree. For more information, see Casting elements in a message map.

You can use the LoopBackRequest node to create, retrieve, update, and delete data records in external systems, through LoopBack connectors that you have downloaded separately, such as MongoDB, Cloudant®, and PostgreSQL.

You can download and install external LoopBack connectors by using the npm tool that is provided with IBM Integration Bus, and then use the LoopBackRequest node to issue CRUD requests through the LoopBack connectors. For more information, see Working with LoopBack connectors.

You can deploy REST APIs to integration servers that are configured to use the integration node HTTP listener. For more information, see Packaging and deploying a REST API.

You can also enable Cross-Origin Resource Sharing (CORS) on the integration node HTTP listener. For more information, see Permitting web browsers to access deployed HTTP services by enabling Cross-Origin Resource Sharing.

When you have created and deployed a REST API, you can push (export) the REST API definition to IBM API Connect or IBM API Management. You can push one or more REST APIs to IBM API Connect, by using either the IBM Integration Bus web user interface or the mqsipushapis command. Alternatively, you can push a single REST API to IBM API Connect or IBM API Management, by using the IBM Integration Toolkit. For more information, see Pushing REST APIs to IBM API Connect or IBM API Management.

You can configure the web user interface to use LDAP for web user authentication. When the integration node is enabled to use LDAP for authentication, web user access from Integration API applications and from the IBM Integration Toolkit (when connecting remotely to the integration node) is also authenticated by using LDAP. For more information, see Enabling an integration node to use LDAP for authentication.

You can view the activity log entries that are associated with a specific message flow, by selecting the message flow in the web user interface, and clicking the Activity Log tab. For more information, see Viewing Activity Logs for message flows.

For more information about REST APIs, see Developing integration solutions by using REST APIs.

You can create a message map that implements a REST API operation, by using the new option Message map with the input and output for the REST API operation operation-name. When you select this option, the map is fully populated with REST API parameters and request/response models. For more information, see Implementing a REST API operation by using a message map.

• Model definitions from a Swagger document in a REST API project
• JSON data types in a well formed JSON schema in a shared library

For more information, see Creating or transforming a JSON output message by using a JSON schema.

For more information, see Custom XPath.

Your message flow might complete lots of different actions. If any of those actions are labor-intensive, you can split them from the main flow into a callable flow and complete them somewhere else. Callable flows also facilitate reuse because they can be called by multiple message flows. You can split your message flows between different applications in the same integration server, or between different integration servers, which can be in different integration nodes. Flows that are split between integration servers communicate securely by using a data router and connectivity agents.

For more information, see Callable message flows.

You can configure your embedded global cache to use different locking strategies for different cache maps, and you can configure the use of replica shards of a cache map for read access. For more information, see Optimizing the embedded global cache for use with different types of cache data.

You can use the SalesforceRequest node to make synchronous requests to Salesforce.com, to create, retrieve, update, and delete Salesforce records. The SalesforceRequest node uses an IBM loopback connector to connect to Salesforce.com and to manage the interactions. Salesforce message models are provided, which allow you to map message data in your flow. The message models are in the form of JSON schema. For more information, see Working with Salesforce.

You can now configure CICSRequest nodes so that any recoverable work is done under a global transaction, coordinated by Resource Recovery Service (RRS). This extends the support introduced in V10.0.0.2 for integration nodes on distributed systems.

For more information, see CICSRequest node and Configuring the CICSRequest node for global transactions on z/OS.

In previous releases, you can use a Database Routine transform to call a stored procedure from only a IBM DB2® database. In IBM Integration Bus Version 10.0 fix pack 3, support for stored procedures is extended so that you can also call a stored procedure from an Oracle database. For information about the support for stored procedures, see Support for stored procedures.

For more information, see Business transaction monitoring.

IBM Integration Bus does not include any database drivers that can be used with the Linux on POWER Little Endian platform. For details about third-party database drivers that are supported, see IBM Integration Bus system requirements web page.

On distributed systems, you can configure the CICSRequest node for globally-coordinated (two-phase commit) transactions.

For more information, see CICSRequest node and Configuring the CICSRequest node for global transactions on distributed systems.

The embedded global cache can use a WebSphere eXtreme Scale enterprise data grid. Enterprise data grids use the eXtreme data format (XDF) instead of Java object serialization. XDF allows for class evolution. With class evolution, you can evolve the class definitions that are used in the data grid without affecting older applications that are using previous versions of the class. For more information, see Enterprise data grid overview in the WebSphere eXtreme Scale product documentation. To enable the use of an enterprise data grid, an integration node must meet the following requirements:

For information about checking and setting function levels, see Changing the function level of your integration nodes.

For more information about using the global cache, see Managing data caching.

You can use Cache transforms in a Mapping node to interact with data that is stored in a global cache. You can add a key-value pair to the cache, get a value (that is associated with a specified key) from the cache, and remove a key-value pair from the cache. For more information, see Accessing the global cache by using a Mapping node.

In addition to communicating with WebSphere eXtreme Scale external grids that use the Object Request Broker (ORB) transport mechanism, IBM Integration Bus can now communicate with external grids that use the IBM eXtremeIO (XIO) transport mechanism. You do not need to configure integration nodes to enable or select a transport mechanism; the transport mechanism that is used is determined by the WebSphere eXtreme Scale external grid.

For more information, see Connecting to external WebSphere eXtreme Scale grids.

For more information, see The WebSphere ESB conversion tool.

For information about installing or updating the WebSphere ESB conversion tool, see Installing or updating the WebSphere ESB conversion tool.

In addition to the safe and fast modes available for user trace, there is a third mode temp that is available with integration server service trace only. This mode is the same as safe mode, but trace is automatically switched off when the component restarts. You can also specify up to 10 BIP numbers to stop the trace automatically.

For examples and more information about this mqsichangetrace option, see mqsichangetrace command - Windows, Linux, and UNIX systems

Any JDBC provider is supported, therefore if a JDBC provider is not listed in the supported database table, IBM Integration Bus provides limited support. This support has the following restrictions: The driver must be a JDBC Type 4 (Pure Java) driver. Global transaction coordination (XA) is not supported. Discoverability in the Graphical Data Mapper is not supported, and the automatic determination of field types in Graphical Data Maps is supported only if the driver correctly and fully implements java.sql.PreparedStatement.getParameterMetaData(). For more information about the field types, see Data type considerations for mapping database content.

For more information about supported JDBC drivers, see the IBM Integration Bus system requirements: http://www.ibm.com/software/integration/wbimessagebroker/requirements/

• Submaps
• Maps and paths to transient context, shared context, and correlation context

For more information, see The WebSphere ESB conversion tool.

For information about installing or updating the WebSphere ESB conversion tool, see Installing or updating the WebSphere ESB conversion tool.