iStock_000020343379_XXXLargeIBM Integration Bus is pleased to announce the availability of IBM Integration Bus v10.0.0.8. Fix pack releases, published every quarter, provide both regular maintenance for the product, and also new functional content. This blog post summarises all the latest and greatest capabilities!

Connect to IBM Cloud Product Insights in Bluemix

Late last year, IBM announced the arrival of a new Bluemix experimental service called Hybrid Connect, for helping register and track the usage of several on-premise IBM products such as IBM Integration Bus, IBM MQ, WebSphere Application Server, WebSphere Liberty, Operational Decision Manager and Business Process Manager. The service lets you:

  • Register on-premise IBM software products with a Bluemix service in the IBM cloud.
  • Gather product information and usage data from enabled and configured on-premise software, such as IBM Integration Bus.
  • View information about all enabled and configured products through a single centralized dashboard in Bluemix.
  • Gain a greater insight into the workload of the enabled and configured products, by accessing the runtime usage data.

The latest refresh of this Bluemix service is called IBM Cloud Product Insights. Product Insights provides improved features:

  • Product grouping views There is now a customizable way to group products in the dashboard so that IT Administrators can organize product instances in a more logical way. IIB lets you tag integration server instances, so at a glance you can easily separate different environments for example such as Production, QA, Integration Test, and Development. This facility also includes aggregating runtime usage data.
  • Advisor recommendations Product Insights now recommends other Bluemix services that may be of interest
  • Revocable API keys and new geos The Product Insights service is now available in other Bluemix regions beyond North America and revocable API keys make it easier to authenticate with the service
  • Getting Started The Getting Started experience for product registration has become even easier so you can see meaningful data from your product instances within a few minutes.

IBM Integration Bus provides the mqsichangebluemixreporting command to allow administrators to quickly register integration servers with the service. In line with the Product Insights service moving its status from an Experimental Bluemix service to a fully supported offering, with IIBv10.0.0.8 we have chosen to change some of the command flags, so even if you’ve already played around with the Hybrid Connect service using the IIBv10.0.0.7 release then you may wish to check out our documentation in the IIB Knowledge Center.

IIB now provides three product usage metrics which are displayed graphically in the Product Insights UI:

  • Number of active CPU processors which can be used by the Integration Server/li>
  • CPU time (ms) which shows the CPU usage of the Integration Server
  • Resident Set Size which shows the amount of memory used by the Integration Server


The service also still captures basic information about the registered IIB Integration Servers:

  • IBM Integration Bus product ID, defined in the IBM License Metric Tool (ILMT)
  • IBM Integration Bus installation root directory
  • Host name
  • Host operating system name
  • Host operating system version
  • IBM Integration Bus integration node name
  • IBM Integration Bus integration server name
  • IBM Integration Bus product version
  • All APARs that have been applied
  • The URL of the IBM Integration Bus web user interface for this integration server.

For more details check out the IIB Knowledge Center.

Asynchronous Callable Flow nodes

Callable message flows were introduced into IBM Integration Bus about a year ago as part of IIBv10.0.0.4. This capability provides IIB users with a Hybrid Cloud solution which can be used to easily burst workload between IIB installed in an on-premise data center and the IBM managed IIB on Cloud service. You can split flows between different applications in an integration server or between different integration servers, which can be on different integration nodes. A calling flow processes information in one location, then calls another flow in a different location. Servers can be hosted on separate physical machines and the IIB switch component used to connect them. This original feature used a synchronous link between the invoking flow and the flow being called. IIBv10.0.0.8 expands the callable flow capability to provide an asynchronous linkage. The new CallableFlowAsyncInvoke node is paired with a new CallableFlowAsyncResponse node by assigning the same uniqueId property to each node. The invoke node issues a call to a separate callable message flow which contains a CallableInput node and a CallableReply node. When the callable message flow completes its processing, control is passed back to the CallablFlowAsyncResponse node. If you wish, you can also choose to share data between the calling flow and the response flow by storing and retrieving data in the UserContext folder in the Environment.

For more details check out the IIB Knowledge Center.

Graphical Mapper support for JSON allOf, anyOf and oneOf

In recent fix packs IIB has focussed on extending our capabilities for interacting via REST and JSON. You can use our Graphical Data Mapping editor to create and transform JSON messages. You can define the data model from a JSON schema or from a REST API swagger document, which can be in JSON or YAML format. IIBv10.0.0.8 adds support for three further JSON constructs: allOf, anyOf and oneOf. These combination keywords facilitate the reuse of defined structures in your JSON schema.

Combinations using allOf:
The allOf keyword lets you extend a structure with additional fields. For example, consider extending the definition of a person object to be an employee who is categorised as either an architect, a developer, architect or a manager:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "person": {
      "type": "object",
      "properties": {
        "first_name": {"type":"string"},
        "last_name": {"type":"string"},
        "age": {"type":"number"}
      },
      "required": ["first_name","last_name","age"]
    },
    "type": "object",
    "properties": {    
    "employee": {
      "allOf": [
        {"$ref": "#/definitions/person"},
        {"properties":
          {"type": {"enum": ["architect","developer","manager"]}},
          "required": ["type"]
        }
      ]
    }
  }
}

JSON schema containing allOf like the one above are no longer rejected by the IIB Toolkit, and are now available for mapping as shown in the screenshots below:

Combinations using oneOf:
The oneOf keyword lets you specify a structure which is valid if it matches exactly one of the defined options. For example, consider the example JSON schema definition below which has an array of vehicles, each of which is either a car or a bike:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "car": {
      "type": "object",
      "properties": {
        "transmissionType": {"type":"string"},
        "engineSizeCC": {"type":"string"}
      },
      "required": ["transmissionType", "engineSizeCC"]
    },
    "bike": {
        "type": "object",
        "properties": {
          "style": {"type":"string"},
          "numberOfGears": {"type":"number"}
        },
        "required": ["style", "numberOfGears"]
    },
    "vehicle": {
        "oneOf": [
                  { "$ref": "#/definitions/car" },
                  { "$ref": "#/definitions/bike" }        
                ]
    },
    "vehicleList": {
    	"type": "array",
    	"items": {"$ref": "#/definitions/vehicle"}
    }    
  }
}

JSON schema containing oneOf like the example above are no longer rejected by the IIB Toolkit, and are now available for mapping as shown in the screenshot below:

Combinations using anyOf:
The anyOf keyword is similar to oneOf, but specifies that one or more of the contained structures must validate against the instance value (rather than exactly one). For example, consider the very similar example JSON schema definition below where we have exchanged oneOf for anyOf in the previous example. This is also now acceptable to the IIBv10.0.0.8 graphical mapper.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "car": {
      "type": "object",
      "properties": {
        "transmissionType": {"type":"string"},
        "engineSizeCC": {"type":"string"}
      },
      "required": ["transmissionType", "engineSizeCC"]
    },
    "bike": {
        "type": "object",
        "properties": {
          "style": {"type":"string"},
          "numberOfGears": {"type":"number"}
        },
        "required": ["style", "numberOfGears"]
    },
    "vehicle": {
        "oneOf": [
                  { "$ref": "#/definitions/car" },
                  { "$ref": "#/definitions/bike" }        
                ]
    },
    "vehicleList": {
    	"type": "array",
    	"items": {"$ref": "#/definitions/vehicle"}
    }    
  }
}

For more details on this topic, check out the IIB Knowledge Center.

User Context support for RESTAsyncRequest and RESTAsyncResponse nodes

IIBv10.0.0.6 introduced asynchronous REST nodes to the product which can be used in a message flow to issue a REST request to an external REST API, and return control to the flow without waiting for a response. The response is received by a RESTAsyncResponse node, which can be in a separate message flow but must be in the same integration server. The nodes are used as a pair, and responses are correlated with the original requests using a unique identifier, which is specified by a developer as a property of both nodes.

IIBv10.0.0.8 extends the capability of this area of the product. You can now store user context data which you have available in the message flow prior to the RESTAsyncRequest node so that it can be used when the reply message is returned to the RESTAsyncResponse message. You can set a value for the variable OutputLocalEnvironment.Destination.REST.Request.UserContext, or create and populate variables below this part of the LocalEnvironment hierarchy.

For example, you could set values using ESQL expressions like these:

DECLARE Ref REFERENCE TO OutputLocalEnvironment;
CREATE LASTCHILD OF OutputLocalEnvironment AS Ref 
  TYPE Name NAME 'Destination';
SET Ref.REST.Request.UserContext = 'Important info';
SET Ref.REST.Request.UserContext.Name.FirstName = 'Fred';
SET Ref.REST.Request.UserContext.Name.Surname = 'Bloggs';		

For example, you could set values in a JavaCompute node like this:

MbMessage LocalEnvTree = outAssembly.getLocalEnvironment();
int type = MbElement.TYPE_NAME_VALUE;
MbElement LocalEnv = LocalEnvTree.getRootElement();
MbElement Dest =
  LocalEnv.createElementAsFirstChild(type, "Destination", null);
MbElement REST = 
  Dest.createElementAsFirstChild(type, "REST", null);
MbElement Req = 
  REST.createElementAsFirstChild(type, "Request", null);
MbElement UserContext = 
  Req.createElementAsFirstChild(type, "UserContext", "Important info");
UserContext.createElementAsFirstChild(type, "FirstName", "Fred");
UserContext.createElementAsFirstChild(type, "Surname", "Bloggs");

You can use a graphical Mapping node to set a value, by mapping to the mixed child element underneath OutputLocalEnvironment.Destination.REST.Request.UserContext:

Alternatively you can create sub-elements using the mapper’s user defined elements or cast options:

To access the user context data after a RESTAsyncResponse node, read the value or children of the LocalEnvironment.REST.Response.UserContext environment variable.

For more details check out the IIB Knowledge Center.

Message Key Support for the Kafka nodes

The KafkaConsumer node and KafkaProducer node have been enhanced to include support for message keys. You can define a string value as a key which is to be associated with a message when it is published. If a message is published to a topic with multiple partitions, this 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. The key value can be defined in the LocalEnvironment structure which is passed in to a KafkaProducer node. For example, you can do this using Compute node ESQL like this:

SET OutputLocalEnvironment.Destination.Kafka.Output.key = 'keyval1';

After an instance of a KafkaProducer node, the key which was used is placed alongside the other Kafka values in the WrittenDestination area of the LocalEnvironment at LocalEnvironment.WrittenDestination.Kafka.key.

The KafkaConsumer node places the key that was associated with the received message (if there was one) in the LocalEnvironment too. This field exists only if a key was associated with the message when it was published. The received key value is received as a string by the KafkaConsumer node and is placed in the position LocalEnvironment.Kafka.Input.key.

For more details check out the IIB Knowledge Center.

Ten New Product Tutorials

Upgraded Components

This fix pack also includes upgrades to a couple of the internal IIB architectural components – The embedded Node.js implementation is now upgraded to version 4.7.2.1 and the MQ File Transfer Edition libraries which were previously at MQ FTE version 7.0.4.4 (+ APAR IT07171) have been upgraded to MQ v9.0.0.0 (+ APAR IT19645).

6 comments on"Explore the new features in IBM Integration Bus version 10.0.0.8"

  1. Hi,
    Any one can brief me on Usercontext?i tried toreplicate the same as above mentioned as
    #before async request node
    DECLARE ref reference to environment.Variables;
    Set *. Usercontext =cast(ref as blob ccid 1208);
    #how to retiev the date in response node?
    Any solution would be great helps

    • BenThompsonIBM September 28, 2018

      Hi PP,

      This page in the Knowledge Center should be helpful for you to get up and running with the UserContext folder for Callable flows: https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/cl28163_.htm

      Before the CallableFlowAsyncInvoke node you would use code like this:
      SET Environment.CallableFlow.UserContext = ‘myData’;

      Unfortunately it looks like your code snippet has the wrong case in a couple of places:
      1. For the Environment folder (lower case e at the front!)
      2. In your SET statement you have used “Usercontext” and not “UserContext”

      You can retrieve the data from after your CallableFlowAsyncResponse node by again looking in the same place in the Environment tree … For example like this:

      DECLARE BensNewVariable CHAR Environment.CallableFlow.UserContext; — In this example, BensNewVariable will be assigned the value myData

      Cheers,
      Ben

    • Ian_Larner June 30, 2017

      @Justin,
      The links to tutorial content GitHub are provided only for information outside the IBM Integration Toolkit. To run tutorials, you use the Tutorials Gallery in the IBM Integration Toolkit click Help > Tutorials Gallery in the Toolkit menu. For more information about the tutorials, see the Tutorials resource page.
      Regards, Ian

  2. Timm Bryant March 19, 2017

    I was reading the Knowledge Center entries for the Asynchronous Callable Flow nodes.

    I understand that the Application that contains the CallableInput/CallableReply nodes can be in a different Integration Server from where the Application(s) that contain the CallableFlowAsync* nodes.

    I couldn’t find any information regarding whether the Application that contains the CallableFlowAsyncInvoke node and the Application that contains the CallableFlowAsyncResponse node can be deployed to different Integration Servers. Would that be possible?

    • BenThompsonIBM April 05, 2017

      Hi Timm,

      Thanks for your comment … Right now, the CallableFlowAsyncInvoke and CallableFlowAsyncResponse node pair must be deployed to the same integration server. This restriction is in place to protect users who are utilising inbound transports to the initial flow containing the invoke node such as HTTP / REST / SOAP which ultimately need to be returned the response message in order to go back to the initiating client. There are of course cases of asynchronous transports like MQ driving the initial flow where this restriction might not necessarily be required for all scenarios so if this is your concern, we’d be open to receiving an RFE to lift this restriction in future.

      Cheers,
      Ben

Join The Discussion

Your email address will not be published. Required fields are marked *