Adapters in a Separate JVM Overview

Adapter availability is the key to measuring Sterling B2B Integrator stability. Activities that prevent an adapter from being available may affect the ability to do business. Activities that currently require Sterling B2B Integrator to be unavailable include, but not limited to:
  • Installing a patch
  • Restarting the system to pick up property file updates
  • Out-of-memory and other system errors
You can choose to run adapters in a separate Java Virtual Machine (JVM), which in turn increases the adapter availability. The adapter is loosely coupled to Sterling B2B Integrator via the database and the Java Message Service (JMS). By running adapters in a separate JVM, you can:
  • Isolate adapters from engine failure.
  • Isolate engine from adapter failure.
  • Isolate one adapter failure from another adapter.
  • Separate lifecycle for adapters.
  • Receive data for adapter even if engine application server independent virtual machine (ASI VM) is down, but the database must be up.

You can run adapters in a separate JVM by creating an adapter container JVM. The adapter container JVM acts like a cluster node, but with limited functions. If you are running Sterling B2B Integrator in a single node environment, the adapter container JVM is listed as a cluster node. Similarly, if you are running Sterling B2B Integrator in a cluster environment, it is listed as a node along with other nodes, but you cannot schedule a business process to run in the adapter container JVM.

Sterling B2B Integrator requires a range of 100 consecutive open ports between 1025 and 65535. However, if you are running Sterling B2B Integrator in a vertical cluster environment, the ports reserved by Sterling B2B Integrator are higher than 100 ports. This can be calculated by the following formula:

(Number of nodes * 100)

The following server adapters can be run in a separate JVM by creating an adapter container JVM:
  • FTP
  • FTPS
  • SFTP
  • HTTP
  • HTTPS
  • Sterling Connect:Direct®