App Connect

Increasingly, users of App Connect Enterprise software are wanting to embrace container technologies in order to derive benefits of scaling, agility, operational consistency and component portability. Since the re-architecture of the product in ACEv11 a large part of our longer term strategy has been to make the product more "container native" in the way that it operates. This has led to many of our users exploring new deployment models such as running independent integration servers, which are not owned by an integration node, inside containers which are orchestrated using a Kubernetes environment such as OpenShift.

As deployments become more granular and lightweight, generally the industry is shifting away from the Enterprise Service Bus design pattern, and fewer message flows are being deployed in each integration server container. The integration server's huge array of integration capabilities built up over two decades of development investment still make it a very natural choice for these newer styles of workload, but with this backdrop, it has become important for us to decrease the time it takes to start an independent integration server in a container. This runs alongside the aim to reduce the CPU requirements of the integration server, in particular at the time of server start up.

To achieve these aims, ACE 12.0.4.0 introduces a new capability to optimize an integration server. This modification release of the product introduces:

• A new command ibmint optimize server
• A new yaml configuration file (named server.components.yaml) interface for selectively “switching off” particular capabilities based on requirements of what has been deployed.

This server optimization feature works for independent integration servers with fixed configuration running in a container. For a given container based integration server process, you can examine the contents of the working directory and generate a server.components.yaml file. This enables you to start the integration server quicker and use less CPU.

Server optimization is suitable when the server content is fixed and it is desireable to reduce the startup time of the process to be as short as possible based upon the server's current settings and content. Before running the new command, you should ensure:

• Any compilable resources such as maps are compiled (by using the --compile-maps-and-schemas parameter with either the ibmint package command or the ibmint deploy command.) For more information, see the ibmint package command and ibmint deploy command
• Any desired overrides are applied to the applications flows by running the ibmint apply overrides command. For more information see the documentation on the ibmint apply overrides command

Optimization analyses the content of a server's work directory and determines which parts of an integration server are needed at startup. To optimize a server you can open a command console and issue the command as shown below:

The optimization process generates a configuration file named server.components.yaml (not to be confused with server.conf.yaml!) which is written to the root of the server's working directory. For example, the file will look a bit like this:

You can now start an integration server, and all components labelled as false in the yaml file will be disabled.  In the above example, most of the capabilitiies have been switched off, but nodeJS (which is used to support the administrative REST API) has been left enabled.  If you no longer want the server to be optimized, then you can simply delete the server.components.yaml file from the work directory. The server then starts up exactly as it did before you optimized it. Unlike the server.conf.yaml file, the server.components.yaml file does not support a copy in the overrides directory.

For more information on this feature check out the documentation for optimizing the startup time for an independent integration server and the ibmint optimize server command

ACE 12.0.4.0 provides a new message flow node in the flow palette:

The purpose of the new FileExists node is for polling for the existence of a specified file at a specified local file system directory location, and then propagating meta-data about the file down the message flow, without parsing the contents of the file itself.  The contents of the file can then be read and processed by another node (such as a FileRead node for example) later in the flow. You can also choose whether to delete the file or leave it in the file directory after it has been propagated through the flow.

For existing users, many of the FileExists message flow node's properties will be reminiscent of those on the FileInput node - for example the Basic tab properties shown above which control the selection criteria for the directory and file name properties. The new Delete file property determines whether the input file is deleted after it has been propagated through the node.

• If this property is set to Always, the file is deleted when it has been processed by the flow. The current transaction commits regardless of whether the file is deleted successfully. If you require any issues with the file deletion to be included in the transaction, they must be handled elsewhere in the flow (with a FileRead node, for example).
• If this property is set to Never, the FileExists node never deletes the file and the flow logic is responsible for deleting the file on the Out, Catch or Failure terminal.

When this property is set to Always, it is important to note that the file directory must be opened with write/execute permissions, where as when it is set to Never, the file directory can be opened with read-only permissions.

As usual, we have added new tutorials to the ACE Toolkit Tutorials Gallery to demonstrate these new product features, so if you'd like to learn more about the detail, this would be an excellent place to discover more:

For many years now, Apache Maven has been a popular automation tool in the Java community which can help marshal software dependencies as part of a build procedure. In particular for ACE Toolkit users, the introduction of the product's new Unit Testing framework (added in 12.0.1.0) has added Test Projects (containing JUnit testcases) to the lexicon of project types needing to be managed as part of an integration landscape. Test Projects will frequently have dependency on third party libraries, and within the Eclipse ACE Toolkit there is a right-click option on a project (eg Application project or Test Project) to Configure > Convert to Maven Project. In the Maven POM wizard that launches, there are options to add dependencies which are persisted in pom.xml files within the project. With these settings in place, the ACE 12.0.4.0 Toolkit's BAR build process can be driven to automatically gather the required dependencies using Maven to do so.

For more details, about using Maven with a Test project or a Java project, check out the relevant section of the IBM documentation.

As we continue to develop new features and functions for later releases of App Connect Enterprise, we are always keen to receive feedback from our users. For many years now we have run an Early Experience Program through which we discuss future potential plans for users willing to sign the relevant non-disclosure agreement, so please get in touch if you would like to join! We also currently have an IBM App Connect Enterprise v12 Open Beta download site, which is regularly refreshed with example code.