We’re thrilled to announce the availability of IBM App Connect Enterprise v18.104.22.168. This is the first fix pack released for App Connect Enterprise software. We intend to provide fix packs on a regular cadence, approximately once per quarter. In fact we’re currently expecting to provide a further two fix packs this calendar year. Fix packs are intended to provide both regular maintenance for the product, and also new functional content. This blog post summarises all the latest and greatest capabilities:
- Introducing App Connect Enterprise integration nodes
- A Web UI for viewing multiple nodes and servers
- Administrative REST APIv2 for controlling App Connect Enterprise v11
- Policy Enhancements and Overrides
- In memory aggregation using the new Group nodes
Expand the sections below to find out more!
Introducing App Connect Enterprise integration nodes
Existing users of IBM Integration Bus may already be familiar with the concept of an integration node. Architecturally speaking, an integration node is a parent process which is responsible for looking after one or more associated integration server processes. An Integration Server is used to provide an isolated runtime environment for a set of deployed message flows and resources. Each Integration Server runs as a unique operating system process in a separate address space. App Connect Enterprise v22.214.171.124 was the first time that Integration Server processes could be defined independently from an Integration Node. An Integration Node provides a higher level operating system process, as part of a wider process hierarchy, which is designed to look after the servers which are owned by it. If you are planning to run the App Connect Enterprise software in conjunction with a container framework such as Kubernetes or IBM Cloud Private, then it is the responsibility of this framework to ensure that the servers remain running (or are restarted appropriately) so in this situation using independent Integration Servers would be the preferred architectural choice.
However, many people will be planning to run the App Connect Enterprise software directly on a physical machine without any wider container orchestration framework. In this situation you are advised to define Integration Servers under an Integration Node. The Integration Node capability of the product and the node-wide HTTP Listener, are delivered in ACEv126.96.36.199 as Technology Preview Code for customers to use in non-production environments. This early access is provided for internal use for evaluation purposes and to allow customers to provide feedback and functionality suggestions to IBM before the Integration Node becomes fully supported.
At first glance, integration nodes will be very familiar to existing IBM Integration Bus users. You can create and start an integration node and its integration servers using some existing commands that have been with the product for a very long time, which should help existing users who are keen to reuse administrative scripts from earlier product versions. To create an integration node and an associated integration server, launch an App Connect Enterprise command console and use the following commands:
mqsicreateexecutiongroup TESTNODE_ACE -e server1
You can connect your App Connect Enterprise Toolkit to both independent integration servers, and also those which are owned by an integration node:
App Connect Enterprise Web UI for viewing multiple nodes and servers
- You can connect your web browser to a specific independent integration server (the same as in ACEv188.8.131.52)
- You can connect your web browser to an integration node to administer all of the servers which it owns
- You can define an integration server to be used for the specific purpose of hosting an admin dashboard which can be used to view multiple integration nodes and integration servers which can be distributed throughout your network across multiple physical machines, virtual machine images or containers.
The animated screen show below demonstrates each of these three types of administrative web user interface options:
Administrative REST APIv2 for controlling App Connect Enterprise v11
IBM App Connect Enterprise v11 provides an administrative REST API, which you can use to control integration nodes and integration servers. This REST API is utilised by both the App Connect Enterprise Toolkit and the administrative Web User Interface. You can also investigate this API for yourself directly using an HTTP client such as cURL. With the delivery of ACEv184.108.40.206, another excellent option to help you become familiar with this API, is a new interactive documentation page which is served directly from both nodes and servers. The REST API classes and methods are described in the App Connect Enterprise REST API V2 specification, which you can view in a browser by specifying the address of your integration node or integration server, and the administration REST API port, followed by /apidocs. For example, to display the REST API specification for an integration node, you might use a URL such as
The animated screen show below demonstrates how to locate the REST API documentation which is being served both from an independent integration server (in this example, through port 7600), and also from an integration node (in this example, through port 4422):
Policy Enhancements and Overrides
IBM Integration Bus v10 provided the concept known as configurable services in order to control the runtime behaviour of the product in a particular environment. Configurable services could be used to define properties relating to connections with external services such as an external JDBC or JMS provider, or operational properties such as in order to configure activity logging. App Connect Enterprise v11 evolves this idea into the concept of a Policy. Policies are used to provide the product runtime with equivalent information to configurable services, however in ACEv11 a policy can be created in the App Connect Enterprise Toolkit inside a policy project. These artifacts can be checked into version control, and also deployed to the product runtime using a Broker Archive file. Fix pack 1 allows policies to be overidden using policies which are placed directly onto the filesystem of the runtime installation and which take precedence over policies which are deployed through a BAR file. This enables an administrator to assert control over artifacts deployed to the runtime by a developer.
The animated screen show below provides a quick tour of creating policies in the App Connect Enterprise toolkit:
In memory aggregation using the new Group nodes
Fix pack 1 of App Connect Enterprise provides a new set of three message flow nodes known as the Group nodes. These nodes provide a new stateless alternative to the Aggregation nodes which have been a part of the IBM Integration Bus product for many years. We have deliberately chosen not to deprecate the Aggregation nodes, as we feel that the two sets of nodes are complementary and provide distinctly different qualities of service which each bring unique value to the product. The three Group nodes are as follows:
- The Group Scatter node marks the beginning of a Group
- The Group Gather node matches up reply messages to Groups based on Reply identifiers / Message identifiers
- The Group Complete node behaves like a new “input” node and deals with the propagation of completed groups, timed-out groups and timed-out unknown messages downstream to other nodes in the message flow.
The Group nodes are non-transactional in their approach. The data on which their behaviours are based, is stored in memory of the integration server, in contrast to the approach used by the Aggregation nodes which utilises the storage of messages on MQ queues. IBM has not yet published results of formal performance and load tests with these nodes, but our internal testing has yielded very positive results in terms of non-functional requirements compared to the Aggregation nodes. When using the Group nodes compared to the Aggregation nodes we have observed the potential for significantly higher throughput, lower mean response times and smaller CPU cost per message. These aspects suggest that the group nodes will be particularly helpful for users dealing with low-latency, rapid response scenarios.