Embedded WebSphere eXtreme Scale (WXS) grid (deprecated)

Use the embedded WXS grid that is supplied with IBM® App Connect Enterprise to store data that you want to reuse.

Attention: As both the embedded and external WebSphere® eXtreme Scale (WXS) grids (deprecated from App Connect Enterprise version 13.0.3.0 onward) are based on Java™ 8, any new implementations should prefer the embedded global cache over the embedded WXS grid, and the external Redis global cache over the external WXS grid.

The embedded WXS grid in IBM App Connect Enterprise is disabled by default. To use the embedded WXS grid, you must enable and configure it by setting properties in the server.conf.yaml files for the integration servers that will share access to the cache. The embedded WXS grid is restricted to use in integration servers that are specified to run Java 8.

Note: WXS is designed to offer a resilient cache topology 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, WXS does not support running the catalog or container server components in containerized environments such as Kubernetes, Docker, or Podman. As a result, App Connect Enterprise does not support the embedded WXS grid when running an integration server in a containerized environment. App Connect Enterprise does support making a client connection to an external WXS grid when running in a container.

To find out more about the differences between the embedded WXS global cache and the external WXS grid, see Differences between the embedded WebSphere eXtreme Scale (WXS) grid and the external WXS grid.

Customizing the embedded topology

You can set properties explicitly for each integration server, by setting properties in each server.conf.yaml configuration file. For example, you might want to specify particular integration servers to host the catalog and container servers so that you can tune performance.

If you stop the integration server that contains the catalog server, the cache becomes unavailable and the data in the cache is lost. Therefore, you must ensure that you define the catalog server appropriately. If you restart the integration server that hosts the catalog server, it can no longer communicate with the container servers in other integration servers. Although these container servers are still running, they are no longer part of the cache, and your data is lost. Therefore, you must also restart the integration servers that host the container servers.

When you use multiple catalog servers, you can improve performance by taking the following steps:
  • Provide other integration servers that host container servers only, rather than having only integration servers that host both catalog and container servers.
  • Start and stop integration servers in sequence, rather than using the mqsistart or mqsistop commands to start or stop all integration servers at once. For example, start the integration servers that host catalog servers before you start the integration servers that host only container servers.

You can configure the global cache by using IBM App Connect Enterprise commands, or the IBM Integration API.

For more information, see Configuring the embedded WebSphere eXtreme Scale (WXS) grid (deprecated).

Interaction with the global cache

You can use Mapping nodes or JavaCompute nodes to store and retrieve data in a map in the global cache. When you get a global map from an external grid, the getGlobalMap method makes a connection to the grid if one does not exist. For more information, see Accessing the global cache by using a Mapping node or Accessing the global cache by using a JavaCompute node.

When you get an MbGlobalMap object, you can also specify how long the data remains in the global cache before it is removed automatically. This time is known as the time to live and is counted from when that map entry is last updated. The value applies to all cache entries that are created by using that MbGlobalMap object in that instance of the message flow. Data that is already in the map that you specify, or that is created by another MbGlobalMap object, is not affected by the time to live value. You can create multiple MbGlobalMap objects in different flows or integration servers, all resolving to the same map in the global cache, but with different time to live values.

By default, the time to live is set to zero so that the data is never removed. To set a specific time to live, create a session policy, which you can reference from the MbGlobalMap object. For detailed instructions, see Specifying how long data remains in the global cache by using the JavaCompute node.