Peer network use cases

The peer network can be used for:

The peer network use cases describe how trading partners are distributed in each case.

Disaster recovery

By setting up multiple peer instances of the trading engine (ideally located at different physical sites), trading partners can be continuously replicated to a hot-backup instance of Interchange.

Swapping between the production and backup instances is handled outside of Interchange by way of network routing configured by the peer network user. For example, given an external URL such as http://edi.myco.com/exchange/myco, the network could be set up to route requests for edi.myco.com internally to IP address 10.10.1.1 if the production instance is active or to 10.10.1.2 if the backup instance is active.

Production and backup peers:

Related topics:

Staging environment

The peer network enables you to provide a staging environment for trading communities to perform test trading with new partners before the partners are promoted to the production trading environment.

In this use case, a staging instance of Interchange is set up as a peer of the production instance. The staging peer may have different application and trading exchanges than the production peer.

The following are possible steps for promoting a trading partner from the staging peer to the production peer.

  1. Set up or import the new partner on the staging peer.
  2. Export the staging peer’s trading community profile and send it to the new partner, who imports the profile as a partner profile on the partner’s system.
  3. Perform test trading as needed between the staging peer and the new trading partner’s system.
  4. At promotion time, use the trading partner cloning wizard in the staging peer to send the trading partner's changes to the production peer.
  5. Export the production peer’s trading community profile and send it to the new partner, who imports the profile as a partner profile on the partner’s system. If the production partner uses the same name or routing ID as the staging profile, tell the partner to select the "replace" option during import.
  1. The following figure shows the relationship between a single staging peer and a single production peer. Note that only the staging peer sends trading partner definitions, and only does so manually using the cloning wizard.

A staging environment could be comprised of multiple tiers (development, staging, production). The following figure shows a case with several staging peers and one production peer. In this example, new trading partners are promoted manually in phases until finally promoted to the production peer.

The following figure shows the relationship in a peer network with multiple staging peers and multiple production peers.

Related topics

Large-scale and global enterprises

There are constraints imposed by the amount of data that can flow through shared physical resources such as the database, network and file system. At some point, a Interchange cluster cannot be scaled further by adding more processing nodes. A peer network has the potential for almost unlimited scaling because each peer is connected to a separate network, database and file system.

Peers could be physically located at the same site or different sites. Moreover, each peer could integrate with a different back-end system. Alternatively, the same thing could be achieved by configuring the network with symbolic host and file system path names that map to different physical resources for each peer.

In a global enterprise case, peers can be widely dispersed geographically. For a global enterprise, as well as for the large-scale case, a peer network offers:

  • Redundancy.
  • Support for heterogeneous environments in which peers run on different operating systems (UNIX, Linux, Windows) and have different databases (Oracle, SQL Server, DB2, MySQL).
  • Ability for each peer to have different application exchanges for efficiently interfacing with local back-end systems.

The peer network is resistant to catastrophic failures at individual sites because physical hardware, processing capacity and configuration information are duplicated across multiple sites. However, if all nodes for one peer fail, some messages in-flight at that moment could be delayed until that peer is restarted. This is due to the loosely coupled nature of the peer network. In comparison, no in-flight messages are affected when a cluster node fails within a given Interchange instance.

The following figure shows an example of a large-scale or global peer network. Staging, backup and production peers are part of the network example. Notice how a peer’s role dictates whether trading partners flow automatically or manually.

Related topics

Staging for upgrades

Before upgrading to a higher version of Interchange, you can first upgrade one peer cluster and conduct tests to make sure the upgraded software performs to expectations. Then you can install the upgrade for the other peer clusters.

The following figure shows an upgrading case between two production peer clusters. Normally, both peers would auto-clone trading partnes to each other. During an upgrade, however, auto-cloning is turned off. Peer 1 suspends production trading and installs the upgraded software. Peer 2 continues operating as a production system. This presumes that a load balancer, if used, is re-directing all trading traffic to peer 2. After a period of testing on peer 1, peer 2 manually clones any changed or new trading partners to peer 1. Peer 2 suspends production, and peer 1 goes back into production. Peer 2 installs the upgrade. Following testing on peer 2, peer 1 manually clones any changed or new trading partners to peer 2. Finally, both upgraded peers turn auto-cloning back on and resume production.

Related topics

Related Links