Interaction Server can balance among multiple Universal Routing Servers and among eServices application servers. It can also connect to its database via multiple Database Access Points (DAPs). It does not use a user-accessible API for load balancing.
Balancing Universal Routing Servers
Interaction Server can balance among multiple instances of URS. This balancing proceeds by strategy: when an interaction reaches a strategy object in a workflow, Interaction Server selects (in round-robin fashion) from among all URS instances that have that strategy loaded.
To enable this type of load balancing, you must:
Configure a connection from each URS to Interaction Server.
For all participating URS instances, set the
Annextab of Interaction Server, set the
truefor the Application names of all participating URS instances.
Choose each URS when activating each strategy in Interaction Routing Designer (IRD). Do this by shift-clicking all of the desired URS instances in the
Choose Routing Serverwindow of the Strategy Activation Wizard.
Suppose Interaction Server has two URS instances connected to it: URS 1 has Strategies A and C loaded, and URS 2 has Strategies B and C loaded. Then,
For interactions that arrive at Strategy A in a workflow, Interaction Server submits them to URS 1.
For interactions that arrive at Strategy B in a workflow, Interaction Server submits them to URS 2.
For interactions that arrive at Strategy C in a workflow, Interaction Server balances between URS 1 and URS 2.
If any instance of URS shuts down, Interaction Server detects that this instance is not available. If any interactions were pending in the unavailable URS, Interaction Server resubmits them to an available URS that has the required strategies loaded.
Balancing eServices Application Servers
An application server is a server that Interaction Server invokes when triggered to do so by a routing strategy. For example, a Classify object in a strategy triggers Interaction Server to invoke Classification Server. To do this, Interaction Server uses a protocol called External Services Protocol or ESP; therefore these servers are also called ESP servers.
The application servers that Interaction Server can balance among are:
Social Messaging Server.
When Interaction Server contacts these servers using ESP (for example, asking E-mail Server to generate an autoresponse), they are application servers (ESP servers) and Interaction Server is their client.
When these servers contact Interaction Server, using the Interaction Management Protocol, and ask to submit an incoming interaction, they are media servers and clients of Interaction Server.
You can load balance by configuring connections from Interaction Server directly to each instance of the application server.
This method encounters a limitation with multiple custom ESP servers that provide different service types. Custom ESP servers generally have the Third Party Server Application type in the Configuration Layer. This means that if, for example, you have several custom servers handling fax interactions and several custom servers handling IM interactions, and you configure them for load balancing by making direct connections, Interaction Server will be unable to distinguish the ones that handle fax from the ones that handle IM, and will therefore send fax requests to the IM servers and vice versa. The solution for this is to use Application Clusters, described in the next section.
Balancing Using Application Clusters
Starting in release 8.0.0, eServices supports the use of Application Clusters for ESP servers. You can configure a separate Application Cluster for each type of ESP server. Then a client such as URS can call on the appropriate Application Cluster by name.
Balancing DB Servers
Interaction Server must work with only one database. However, Interaction Server supports multiple DAP connections to the same database through different DB Servers. You can configure this using multiple connections (DAPs) to one database.