Message re-routing

Interchange can act as the hub of a hub-and-spoke network to re-route messages. In a hub-and-spoke architecture, the hub (Interchange) mediates messages exchanged between trading partners. In such a network, the spoke partners send messages only to Interchange. Interchange then re-routes messages to the intended receiving partners. This arrangement simplifies the technical requirements for the spokes, which need to define only a single partner (the hub) for exchanges with multiple partners.

Figure illustrates a hub and spoke network in which B2Bi is the hub, mediating message distribution to spoke partners.

When Interchange receives a message and determines that the intended recipient is a spoke partner (and not Interchange), Interchange repackages the message and sends it to the true receiver.

All re-routing takes place within Interchange. Re-routed messages are not shuttled to an inbound application delivery before being sent on to the true receiver. For this reason, inbound messages that are re-routed cannot be post-processed in delivery exchanges. Instead, you configure post processing for outbound re-routed messages. For information about configuring post-processing through a delivery exchange, see Post-processing configuration details.

The following figure illustrates how re-routing occurs. Partner A sends a message to the hub, but the true receiver is Partner B. Upon receiving the message, the hub sends a receipt to Partner A and determines Partner B is the true receiver. The hub then sends the message to Partner B, which sends a receipt to the hub.

Figure illustrates re-routing, where Partner A sends a message to the hub, but the true receiver is Partner B.

Prerequisites to re-routing

Before setting up re-routing in Interchange, administrators must perform the following tasks:

Distribute the hub's community profile as a partner to all of the spoke partners. For secure trading you must include the community public key certificate. See Add a community.
In the Activator configuration, set up a partner for each spoke partner. For secure trading each partner must have a public key certificate. Depending on whether the partner uses Axway software or an interoperable third-party trading engine, partners can be imported from files or added manually. See Partners.
Make sure re-routing is enabled for the community. To do this:
Click Trading partners on the navigation graphic at the top of the community summary page. Select Allow messages to be re-routed.
If necessary, advise the spoke partners to configure their trading engines to send messages to the hub, with other spoke partners as the end recipients of messages.
Determine the types of messages to be re-routed. Although Activator hub can re-route all document types (EDI, XML and binary), determining type can help in knowing how the system determines senders and receivers.
Determine the re-routing method to use and configure Activator accordingly:

Re-routing configurations

There are several ways to configure Interchange to act as a hub in re-routing messages.

Message handler re-routing

You can configure Message handler to re-route received messages when specified conditions are met.

To do this you work in the Message Handler to set up a re-routing message action that is based on a message metadata trigger. For details see Set up message-processing actions.

Message header re-routing

You can use message headers that specify senders and receivers or routing IDs in documents for re-routing.

Notes:

Message handler re-routing overrides this method.
This method does not work with No Packaging or PGP deliveries. If your configuration includes either of these, set up message actions that trigger message re-routing following the instructions in Set up message-processing actions.

When the hub community and spoke partners are configured correctly on the hub trading engine, the system can perform re-routing with little configuration. However, you must make sure re-routing is enabled for your community. To do this:

Click Trading partners on the navigation graphic at the top of the community summary page.
Select Allow messages to be re-routed.

Spoke partners must configure their trading engines to send messages to the hub.

If the spoke partner uses 5.0.2 or later, EDI and XML documents can be re-routed through the hub, but not binary documents. Instead of parsing for the receiver when the partner's system picks up documents from integration, the partner can use a static receiver to send messages to the hub.
If a spoke partner uses , the partner imports the hub's profile as a partner and then adds other spoke partner's IDs as secondary IDs in the hub profile.

Upon receiving a message from a partner, Activator unpacks it as usual and determines the sender and receiver. It does so in a number of ways:

Activator (without additional From/To parsing or fixed metadata options), parses for true sender and true receiver headers in the top-most MIME header of inbound messages. The true sender is the spoke partner that originated the message. The true receiver is the spoke partner that is the intended end recipient. These headers are in the following format:
X-Cyclone-True-Receiver: <routing ID>
X-Cyclone-True-Sender: <routing ID>
Activator (without additional From/To parsing or fixed metadata options) parses for a subject header in the top-most MIME header of inbound messages. The subject header identifies the IDs of the true sender and the true receiver. The header is in the following format:
Subject: true-receiver ID [; true-sender ID]
The true receiver ID is required and the true sender ID is optional.
A spoke partner who uses an email client application to send messages to the hub can add the true sender and true receiver IDs in the subject line of email messages.