Cluster features

B2Bi supports up to server nodes per cluster.

B2Bi clustering provides the following features:

  • Distributed processing across multiple physical servers
  • High-availability processing continuity on failure of one or more nodes
  • Capability of adding and removing non-primary nodes without B2Bi stopping message processing
  • Security from loss of currently processed messages in the event of a single server failure
  • Scaling per node and extended capacity by adding nodes
  • Multi-node synchronized configuration and object deployment

To set up clustering you install the B2Bi server on multiple hosts, where each host constitutes a single service node. Trading engines and integration engines are linked together in a 1:1 relationship. You must install the trading engine and the integration engine of each node on the same host machine.

The clustered nodes share:

  • Database for the B2Bi Server.
  • Access to a common file system
  • Binary resources used at runtime are shared through the shared file system (MBC and Datamapper maps).
  • DML resources are deployed and synchronized to all nodes from Mapping Services.

The following figure illustrates a B2Bi cluster architecture on two nodes. Each cluster node consists of exactly one trading engine and one integration engine:

 B2Bi cluster architecture on two nodes

About nodes

In the B2Bi active/active environment the term "node" is used in two ways:

  • In the generic usage, a node is a computer that supports a set of related applications and is member of a high-availability cluster. In this sense of the term, B2Bi supports up to four nodes per cluster.
  • In a B2Bi-specific usage, a node is a sub-server of the B2Bi implementation. Each node supports a specific subset of the B2Bi system tasks. A single hosted instance of B2Bi requires three nodes:
    • B2B – Provides contextual processing information to the integration engine
    • Trading engine - Provides transport protocol and security handling
    • Integration engine - Provides message-content handling

About cluster roles

In a B2Bian Activator cluster, the integration engines instances are assigned operating roles:

  • System role – The integration engine operating in the System role runs the cluster singleton tasks. Cluster singleton tasks are always running. They can only run on one integration engine instance in the cluster. The integration engine with the System role is the first node that is started in supervised mode.
  • Primary node –The integration engine operating in the Primary role runs the integration engine user singleton tasks. Integration engine singleton tasks support polling pickups, dedicated processing environments (integration engine HMEs) for the multi-document envelopers and sequencing activities. The integration engine with the primary role is the first to start the user tasks.

These two B2Bi-specific roles can be attributed to the same cluster node or to different nodes, however it is best to configure them on different nodes.

Task distribution

Certain tasks, by their nature, can only be executed on a single B2Bi-specific node. This is the case, for example, for the B2Bi application pickups provided by the integration engine that execute polling (FTP, file system). B2Bi processes use cluster singletons to ensure that these types of tasks run only on the node which was started first. An internal load balancer then distributes the messages within the cluster if they are picked up as a result of the polling task.

Similarly, certain internal integration engine tasks can only run once in the cluster. For these tasks, a new proxy reroutes the initial connection from a client task to the system singleton task on the system node. All data exchange after that goes directly between the client task and the system singleton task.

Singleton activities

For certain activities it is necessary to process messages in sequence and avoid any parallelism. This is the case for enveloping multiple documents and for sequencing activities. These activities all use dedicated processing environments (integration engine HMEs) which only run on the primary node. HMEs are configured to process messages one by one. Enveloping of single documents takes place in separate activities that do not have these restrictions.

B2Bi engine dependencies

Integration engine processing tasks are started and stopped by the single associated trading engine instance.

An instance of the integration engine can only run when its associated trading engine instance is running. If the trading engine on a specific cluster node fails, it attempts to stop the associated integration engine instance. Additionally, the integration engine listens for a "keep-alive" message from the trading engine. If the keep-alive is missing, the integration engine stops itself.

Similarly, if the integration engine associated with a trading engine fails, the trading engine on the same cluster node stops itself.

A senior clustering control agent, located on the principal cluster, monitors and coordinates node activity.

Message processing continuity and checkpoints

In a typical message processing scenario, messages that are handled in a trading engine are produced to the integration engine that shares the same node. The integration engine processes these messages on the node on which they started their processing.

In the case of messages coming in through the integration engine, the messages are balanced over the various integration engines across the multiple nodes. The integration engine typically pushes the processed message to the local trading engine, which then produces it to the final destination.

Load balancing

  • For processes driven on the trading engine:
    • Protocols where messages are “pulled” by B2Bi (FTP, file system, …) – B2Bi provides built-in load-balancing.
    • Protocols where messages are “pushed” to B2Bi (HTTP, …) – Load-balancing must be provided externally (typically through hardware load-balancing).
  • For processes driven on the integration engine:
    • There is no active load balancing inside the integration engine. The queues are shared and all cluster nodes have equal access to all messages once messages are in the queue. This means that the processing can switch between cluster nodes for every activity.
    • Protocols where messages are “pulled” by B2Bi (FTP, file system, …) – No load-balancing mechanism (only the primary node polls).
    • Note: Once the message has been read, the processing of the message can switch between cluster nodes.
    • Protocols where messages are “pushed” to B2Bi (HTTP, …) from partner or application side – Load-balancing must be provided externally (typically through hardware load-balancing).
    • After message consumption – An automatic dispatching step of a single node distributes the load between the nodes in the cluster.
    • Messages received through the trading engine are processed on the node on which they have been delivered.

B2Bi engines

Trading engine

In B2Bi, the trading engine "drives" the integration engine. The trading engine connects to a server inside the integration engine (the kernel server). Whenever changes appear in the cluster, the trading engine communicates these events to the integration engine.

Within the cluster there are control nodes and trading engine nodes. Control nodes host the B2Bi user interface. Trading engine nodes host trading activity. The oldest node in the cluster runs singletons that control the cluster.

Whenever you add a node, it is assigned processing work and becomes responsible for a set of exchange points.

Integration engine

Within the cluster there are primary and secondary nodes. There is only one primary, typically the oldest (first started) node in the cluster. The primary node runs certain singletons not running on the secondary nodes and manages the “pull” protocols on application side. It also handles sequencing activities through single-message dedicated processing environments (integration engine HMEs). When the primary node fails, another node runs these particular singletons. When a node is added to a running cluster, the new node is a secondary node that receives workload from the primary node.


Architectural limitations

  • B2Bi supports up to four servers per cluster.
  • You can implement a maximum of one trading engine per physical server.
  • You can implement a maximum of one integration engine per physical server.
  • A single integration engine is associated with a single trading engine to form one cluster node unit.
  • Polling activities (example: FTP polling) and message consumption activities occur only on the primary node. They are not load balanced over the multiple nodes. Once messages are consumed, their processing is balanced across the cluster nodes.

Performance limitations

  • In the event of an uncontrolled stop of one of the nodes in the cluster, the whole cluster needs to “recycle”, causing a temporary outage due to a restart of both the trading engine and integration engine on the remaining nodes.
  • In the event of a controlled stop of the node running the integration engine in system mode, the whole cluster needs to “recycle”, causing a temporary outage due to a restart of the remaining trading engine and integration engine.
  • In the event of a controlled stop of the non-system node (integration engine), there is no cluster recycling.
  • In the event of a stop of one of the nodes, there is risk of failure of messages in process at the moment of the stop of the node. These messages need to be reprocessed in the trading engine (from the Message Tracker).

Management features

In the B2Bi user interface, users with B2Bi administrative rights can view and manage cluster nodes on the System Management page.

The following figure illustrates a System Management page view of the processing engines running on a host server:

 System Management page view with processing engines shown running on host server

In this figure you see three B2Bi processing nodes (engines) running on a single host to provide a cluster node:

  • B2Bi engine (linux28_b2b)
  • B2Bi trading engine (linux28_te)
  • B2Bi integration engine

From this page you can add, delete, start, stop and restart engines, as well as view and manage integration engine tasks.

Related Links