Fix pack 5 introduces support for running IBM App Connect Enterprise on the AIX operating system. As part of this release, our AIX support also includes several features which on IBM Integration Bus v10 have previously only been supported on Windows and xLinux platforms. As part of AIX support on v11.0.0.5 you can now also use the LoopbackRequest node, the SalesforceRequest node and the Callable Flow nodes in your message flows.

From ACEv11.0.0.5, the following hardware platforms are now supported:

• Microsoft Windows x86-64
• Linux on x86-64
• Linux on IBM Z / LinuxONE
• AIX on IBM Power System Big Endian

For more information about supported software, please see the full System requirements page.

The initial IBM App Connect Enterprise v11 product announcement included a statement of direction for the future addition of further platform support for Linux on IBM Power and IBM System Z. Users waiting for these currently unsupported platforms are encouraged to join the IBM App Connect Early Experience Program.

App Connect Enterprise provides the IBM Integration API as a remote programming interface that your custom integration applications can use to control integration nodes and their resources. Examples of the kind of tasks that you can execute using this API are as follows:

• Deploy BAR files
• Change the integration node configuration properties
• Create, modify, and delete integration servers
• Inquire about the status of an integration node and its associated resources
• Create and modify message flow applications

Although the Integration API has the same name as its predecessor API which was available in IBM Integration Bus v10, the packages and classes it contains have changed slightly.

• com.ibm.integration.admin.proxy This package has new classes to use for administering an Integration Node, Integration Server and deployed resources.
• com.ibm.integration.admin.model This package has classes which provide a model representation of resources. Use get methods to access specific properties.
• com.ibm.integration.admin.http This package has classes which allow you to send direct requests and receive responses to/from a local or remote Integration Node or Integration Server.
• com.ibm.broker.config.* This package contains deprecated classes and the limited capabilities were provided here simply to help make migration from IIBv10 easier. Moving forward, at the earliest opportunity, users are encouraged to use classes from com.ibm.integration.admin.proxy instead.

Fix pack 5 introduces support in App Connect Enterprise for pushing REST APIs to IBM API Connect. REST APIs which have been developed and deployed to the ACE runtime, can then be exported into IBM API Connect, which you can then use to manage and publish your APIs. This new capability can be driven from the IBM App Connect Enterprise web user interface, using the mqsipushapis commmand, or using the ACE product’s administrative REST API. The versions of IBM API Connect which are supported by this feature are:

• IBM API Connect 2018
• IBM API Connect Enterprise 5.0
• IBM API Connect Professional 5.0
• IBM API Connect Essentials 5.0
• IBM API Connect for IBM Cloud

Starting from the ACE web user interface, you can now choose the option to Push REST APIs to API Connect from the menu shown in the screenshot below:

Selecting this menu action will launch a wizard which begins by gathering information about the version of the API Connect system that you are connecting to, the connection details (Host and Port) and your connection credentials. When the connection has been established, values are retrieved from the API Connect system which allow the user to specify the target API Connect organization, product, and catalog. Once you’ve chosen the target organization, you can specify an existing product or create a new one, defining the title, name, and version of that product. If you want to stage the product, you can optionally also specify the name of the Catalog in which you want it staged. The next page in the dialog invites users to choose which REST APIs are to be exported to API Connect, as shown below:

The next page in the dialog afford the chance to override the host name and port that will be used by IBM API Connect to invoke the pushed APIs. When doing this you can specify HTTP proxy details, HTTPS proxy details, or both. The last step involves a status page showing the progress and result of the push to API Connect.

For users wishing to script this kind of administration, the mqsipushapis command is provided which offers the same functionality. Here’s an example of the command with its many different options!

mqsipushapis TESTNODE --integration-server default --apic-host mysystem
 --apic-port 443 --apic-version v5 --apic-username testuser --apic-password mypassword
 --apic-org myOrg –-apic-catalog-title MyCatalog --apic-product-title MyProduct
 –-apic-product-name ProdName –-apic-product-version 2.0.0 --rest-apis myapi1:myapi2:myapi3

For the security conscious, you can choose to be prompted for the IBM API Connect password rather than entering it in the command, by specifying --apic-password "" (an empty string in double quotes). The next example below shows how you can use the mqsipushapis command to push REST APIs to IBM API Connect Version 5 on IBM Cloud, and stage the product in the catalog:

mqsipushapis --admin-host localhost --admin-port 7600
--apic-host https://apimanager.eu-gb.apiconnect.cloud.ibm.com --apic-port 443
--apic-version v5-on-ibm-cloud --apic-api-key ab209e28-6ajd-1965-8916-7457d176b0c7
--apic-org myOrg –-apic-catalog-title MyCatalog --apic-product-title MyProduct
 --rest-apis myapi4:myapi5 --apic-disable-certificate-verification

Both the web user interface and the command are based upon methods provided by the ACE administrative REST API, which can also be invoked directly using a REST client such as the Curl command for example. Three actions are provided:

• POST /apiv2/api-session This connects to a target API Connect environment and returns API Connect Organisations, Products and Catalogs. The response also provides an ACE-Session-xxxxxxxx cookie which must be set on the following two API invocations.
• POST /apiv2/api-push-api This creates / updates a single draft API and can be used to create / update a draft product and add the draft API to the draft product.
• POST /apiv2/api-stage-product This stages a product in a catalog.

IBM has now published a set of performance results and comparisons between IBM App Connect Enterprise v11 and IBM Integration Bus v10. Given the strong industry interest in moving to container environments for running integration workloads (due to the ease of administration, scaling, and improved resource utilization), we have opted to focus this first set of ACEv11 performance information on containers. The tests cover 6 scenarios, 3 message sizes and 3 concurrency levels and results are available for Windows and Linux operating systems.

Shown below is just one example of the points of comparison – demonstrating results for an HTTP Echo scenario with BLOB data. For full information please go here.

Although message flow nodes can be given hard-coded properties which define how App Connect Enterprise should connect to third party systems, typically users like to abstract these kind of specific settings away from the message flow itself. This capability is provided using App Connect Enterprise policy documents. For those familiar with IBM Integration Bus, a policy is very similar in concept to what used to be known as a configurable service in this earlier incarnation of the product. Policies can be created in the Toolkit and then deployed to the runtime using a Broker Archive file. System administrators can also place policies directly on to the filesystem of the runtime in order to override settings in deployed policies. This fix pack introduces two new policy types for use with the IMSRequest and CORBARequest message flow nodes. Just like other policy types, the Toolkit policy editor provides easy-to-fill templates for the required information as shown below:

Fix pack 5 also extends the range of policies which can be redeployed and dynamically configured without the need to restart the integration server. The policy types which are now supported for redeployment are shown in bold type in the following list:

• Activity Log
• Aggregation
• Connect:Direct Server
• CICSConnection
• Collector
• CORBA
• DotNet Application Domain
• EmailServer
• FtpServer
• IMSConnect
• Java Class Loader
• JDBC Providers
• JMS Providers
• MQEndpoint
• MQTTPublish
• MQTTSubscribe
• Resequence
• SAP Connection
• Security Profiles
• SMTP
• TCPIP Client
• TCPIP Server
• Timer
• User Defined
• Workload Management
• WXS Server

Important note: The Toolkit which was installed as part of earlier App Connect Enterprise fix packs provided HTTPConnector and HTTPSConnector policy types in addition to the above list. These policies controlled configuration aspects relating to the way ACE should receive data over HTTP. Having received feedback from our users that this was a little confusing, especially given the possibility of providing similar configuration through the integration server’s configuration yaml file, from fix pack 5 we have decided not to provide this policy type in the Toolkit user interface. HTTPConnector and HTTPSConnector policies which have previously been created and deployed will continue to work and be fully supported by the runtime which will still respect their settings, so no action is required by users in this regard – we simply provide this information here for the avoidance of any potential confusion.

App Connect Enterprise has now been enhanced in fix pack 5, to display details of custom keywords which have been assigned to message flows (in the Toolkit or as part of a build pipeline) by including a specific string in the source code (.msgflow file) of the resource. For example, in the Short Description or Long Description fields of a message flow’s properties you could insert text as follows:

$MQSI KeywordName=KeywordValue MQSI$

This enables developers to tag resources with documentation details such as the author of the resource, or their business area etc. This capability has been provided with earlier versions of IBM Integration Bus, so readers may well have resources which have already been tagged. As in previous releases, do not use the following characters within keywords because they cause unpredictable behavior:

^ $ . | \ < > ? + * = & [ ] ( )

You can use these characters in the values that are associated with the keywords but not in the keyword itself; for example:

• $MQSI RCSVER=$id$ MQSI$ is acceptable (because RCSVER is a valid keyword name).
• $MQSI $name=Fred MQSI$ is not acceptable (because $name is not a valid keyword name).

Consider an example message flow in the App Connect Enterprise Toolkit, where you could add keywords as shown below:

Once deployed, the keyword properties are displayed when using the mqsilist command with detailed level options:

You can also inspect the keywords which were set by looking at the Properties view of the deployed message flow in the Toolkit:

For those wishing to write external applications which interact with App Connect Enterprise, you can also get access to these values using the administrative REST API or using the java Integration API.

Fix pack 5 enhances a few commands to better enable administrators wishing to control their ACE infrastructure.

mqsistartmsgflow This command is new in ACEv11.0.0.5 As its name suggests, its purpose is to enable users to individually start a particular message flow or set of message flows which have previously been deployed and are currently in the stopped state. Full details of the new command syntax are available in the Knowledge Center here.

mqsistopmsgflow This command is new in ACEv11.0.0.5 As its name suggests, its purpose is to enable users to individually stop a particular message flow or set of message flows which have previously been deployed and are currently in the started state. Full details of the new command syntax are available in the Knowledge Center here.

mqsirestorebroker This command is new in ACEv11.0.0.5 The purpose of the command is to restore the integration node configuration from a backup file that you have created by using the mqsibackupbroker command. You can restore an integration node only on a computer that has an identical configuration; the operating system must be at the same level, and the integration node and queue manager names must be identical. Full details of the new command syntax are available in the Knowledge Center here.

mqsistop This command is enhanced in ACEv11.0.0.5 Although earlier fix packs provided this command, its implementation was limited to the control of an Integration Node. In ACEv11.0.0.5, many other detailed options have been added to extend the granularity of the command to include:

• --integration-server (-e) server integration server name
• --all-integration-servers indicates all integration servers
• --application (-k) application application name
• --all-applications indicates all applications
• --library (-y) library static library name
• --all-libraries indicates all static libraries
• --flow (-f) messageFlow message flow name
• --all-flows indicates all message flows.

Full details of the new command syntax are available in the Knowledge Center here.

Fix pack 5 provides a minor enhancement to the Toolkit regarding the display of Integration nodes which are defined locally on the same machine where the Toolkit is installed. The ACEv11.0.0.4 Toolkit connected to local and remote Integration Nodes and standalone Integration Servers using the HTTP administrative REST API. In ACEv11.0.0.5, the Toolkit will display local Integration nodes without requiring further connection details from the user. This small usability enhancement has been made possible courtesy of the Integration API enhancements which were discussed earlier in this post:

As older users of IBM Integration Bus may be aware, a user exit is user-provided custom software, written in C, which can be a useful extension mechanism available to users to help track data passing through message flows. User-provided functions can be invoked at specific points during the life cycle of a message while it passes through the message flow, and can invoke utility functions to query information about the point in the flow, and the contents of the message assembly. For background information about this concept, please read the documentation which is available in the Knowledge Center here. Although User Exits have been available as part of IIBv10 and ACEv11 for many years, this fix pack provides some enhancements which make it much easier for user exit developers to influence the properties of MQ messages and HTTP communications which are consumed and produced by the message flow.

From Fix Pack 5, on the start up of the integration server any User Exit loadable exit libraries .lel files found on the userExitPath will be loaded. These libraries can register an “exit name” and provide callback functions which are labelled in the diagram below using the letters (b) – (f). The onStartServer function callback in the exit library is invoked if the provided exit name matches with a name in the activeUserExitList. The onStartServer function allows the exit to register transports that it wants to be called, along with header information which it wants to receive and set when it is called. The picture below shows a simple message flow, which has been annotated with the names of the new function callbacks which are provided as part of ACEv11.0.0.5. The letters describe the function callback names and show which callbacks are called from which message flow node. The numbers show the order in which they would be invoked. The example shown relates to HTTP nodes, but a similar design is possible using MQ nodes too.

• onTransportInputMessage Starts a flow trace/span and retrieves “Transport Headers“
• beforeTransportOutputMessage Allows injection of information into outbound “Transport Headers” e.g. traceparent
• afterTransportOutputMessage Allows inspection of actual emitted “Transport Headers” into HTTP or MQ Transport output occurring during a flow trace e.g. set trace meta-data using values from LE.WrittenDestination like requestURL or MsgId.
• onTransportResponseMessage Signals the arrival of a response from a synchronous HTTP/MQ transport interaction in a traced flow. Could be used to calculate response time for a request in a child span.
• onTransportTransactionComplete Signals the completion of processing of a traced message flow
• onStopServer Deregister and release all resources

If you wish to learn more about the possibilities available with these enhancements, please check out the sample code which is provided in AceSpanTraceExample.cpp available in the installation of App Connect Enterprise v11.0.0.5 in the sample directory. If you have installed the product in the default location on Windows for example, then you will find this at C:\Program Files\IBM\ACE\11.0.0.5\server\sample\extensions\userexits\transport\AceSpanTraceExample.cpp.

Presently these enhancements are provided for the benefit of users wishing to develop their own code and assert greater control with their own instrumentation tools. In future releases, IBM plans to potentially take advantage of these exits to provide richer insight when tracking the data passing through message flows.