Assess your readiness

At the start of your transformation journey, assess your current readiness for adopting IBM® Cloud Pak for Integration.

As an initial step, it is important to establish which versions of IBM Integration Bus or IBM App Connect Enterprise are supported for migration into a containerized environment, and which features are unsupported. Options are available for refactoring some of the unsupported features before you attempt to migrate.

Supported versions for migration

To migrate to a containerized environment, you must be running IBM App Connect Enterprise 11 or 12.

If you are using IBM Integration Bus 10 or earlier, you must first migrate to IBM App Connect Enterprise 11 or 12 before attempting to migrate to containers. For more information, see the Migrating section in the IBM App Connect Enterprise version 11 or version 12 documentation.

Unsupported features for migration

The following features in IBM App Connect Enterprise are not supported for migration to containers:

Tip: If you are planning to move to containers, it might be useful to run the Transformation Advisor tool in your IBM App Connect Enterprise environment to collect data about what is deployed to your integration node or to a specific integration server. Then, analyze the data collected to see whether any unsupported features were identified, and determine how (or whether) you can refactor your message flow definitions before you migrate. For more information about the Transformation Advisor tool and its rules, see Running the Transformation Advisor tool in the IBM App Connect Enterprise documentation.


Integration nodes

The concept of using an integration node to manage a set of associated integration servers is not applicable in a containerized environment. If you are intending to run IBM App Connect Enterprise in containers, you can deploy your applications to independent integration servers without the need to create and configure an integration node.

In the containerized environment, you deploy integration servers by using broker archive (BAR) files, which package the message flows and resources in your IBM App Connect Enterprise Toolkit integrations. For more information, see App Connect Integration Server reference and Deploying Designer and Toolkit integrations to integration servers.

.NetCompute and .NetInput message flow nodes

The .NetCompute and .NetInput message flow nodes, which are built-in Transformation nodes in the IBM App Connect Enterprise Toolkit, are supported on Windows only. Therefore, they are not supported in a containerized environment, which runs on Linux® only. BAR files that are exported for any integration servers with these message flow nodes are not supported for import and deployment to containers.

CDInput and CDOutput message flow nodes

In the IBM App Connect Enterprise Toolkit, the built-in CDInput and CDOutput message flow nodes provide file transfer support through integration with IBM Sterling Connect:Direct®. These nodes require IBM MQ to be installed on the same computer as your integration server, to control the storage queues that hold file transfer information.

To use the capabilities that are provided by these nodes in a containerized environment, a local IBM MQ queue manager would be required to run in the same pod as the integration server, which isn't supported.

Embedded global cache

The embedded global cache is supplied with IBM App Connect Enterprise to store data that you want to reuse within and between integration servers. The global cache is implemented by using WebSphere® eXtreme Scale technology, which provides resiliency by hosting a known number of catalog and container servers in a fixed topology. This is not compatible with the ephemeral nature of containers running in elastically scaled cloud environments such as Kubernetes. Therefore, WebSphere eXtreme Scale does not support running the catalog or container server components in containerized environments such as Kubernetes, Docker, or Podman. As a result, IBM App Connect Enterprise does not support the embedded global cache when running an integration server in a containerized environment.


The following alternatives are available for refactoring your existing global cache topology into a suitable topology for containers.
Note: For some of these options, you might need to use configuration files such as server.conf.yaml or policy projects to create configuration objects for use with the integration server in the containerized environment. For more information about configuration objects, see Configuration reference and Configuration types for integration servers.
Client connection to an external IBM App Connect Enterprise or WebSphere eXtreme Scale instance

The embedded global cache supports client connections to an external IBM App Connect Enterprise on-premises system or an external WebSphere eXtreme Scale grid when running in a container. You can implement this hybrid topology as follows:

Extended Structured Query Language (ESQL) shared variables

With an embedded global cache, you can use Mapping nodes or JavaCompute nodes to store and retrieve data in a map in the global cache. To provide a supported alternative for containers, you can use the Compute node and ESQL shared variables to implement an in-memory cache in an integration server's message flow:

  1. Edit the relevant message flow to replace the Mapping or JavaCompute node with the Compute node.

    Configure access to a database from the Compute node, code ESQL statements with appropriate long-lived ESQL data types to cache data in memory, and then set properties for the Compute mode and for message validation. For more information, see ESQL overview and Long-lived variables.

  2. Disable the global cache by updating the integration server's server.conf.yaml file. For more information, see Configuring the embedded global cache.

The Using a Compute node to access a Lookup table stored in a shared variable in memory tutorial in the IBM App Connect Enterprise documentation provides guidance on how to access in-memory ESQL shared variables by using a Compute node.

Restriction: With the ESQL solution, the cache can be used by a single integration server only rather than shared between integration servers.

Java™ HashMap-based caching by using the embedded local cache
Availability:

Supported on integration servers at version 12.0.4.0-r1 or later

You can configure the embedded local cache to allow flows that contain cache lookups to run within containers. When using the embedded local cache, a Java HashMap is used as the underlying storage for the map instead of a WebSphere eXtreme Scale grid, so the embedded local cache is scoped to a single integration server. Each integration server has its own in-memory copy of the cache, and updates that are made in one integration server are not reflected in any other integration servers. Cache transactions are also not supported when using the embedded local cache. For more information, see the Using the embedded local cache section in Embedded global cache, and Accessing the global cache by using a JavaCompute node.

Globally coordinated message flows

In message flows that are configured to process messages in globally coordinated transactions, coordination is provided by an external transaction manager. The transaction manager interacts with participating resource managers to initiate the correct actions for each resource. In IBM App Connect Enterprise deployments on distributed systems, a local IBM MQ queue manager needs to be configured as the transaction manager and associated with an integration node that manages the message flows. Because integration nodes are not supported in a containerized environment, globally coordinated transactions are therefore also not supported. BAR files that are exported for any integration servers that include globally coordinated message flows are not supported for import and deployment to containers.

For more information, see Message flow transactions and Configuring global coordination of transactions (two-phase commit) in the IBM App Connect Enterprise documentation.