Interacting with eServices

In your Configuration Environment, the ORS Application, as a client of eServices' Interaction Server, will have separate connections to each Interaction Server Application. Interaction Server is represented by Application objects in the ORS Connections tab.

You can think of the first Interaction Server Application object as a server and and the second object as its proxy. You need only install and operate one instance of Interaction Server: the server instance. It is not necessary to install the proxy instance because it does not run as an application.

Configuring eServices Application with Type T-Server

To enable ORS to operate with eServices interactions by configuring two Interaction Server Application objects.

1. Import two templates to create the Interaction Server Application objects.
   • Use an Interaction Server Application template for the Application object that you are using for the actual installation.
   • Use a T-Server Application template (with its default configuration) for the second Application object.
     
2. Create the Interaction Server Application objects. Ensure that both of the Interaction Server Application objects have different Application object names.
3. In the second Application object (based on the T-Server template), specify the multimedia switch in the Switches tab.
   Note: The first Interaction Server Application (created by using the Interaction Server template) has no association in its properties with a multimedia switch. ORS determines this association, based on the Tenant that is specified in the General tab of the ORS Application. Alternatively, the second the Interaction Server Application (based on the T-Server template) must have a multimedia switch configured in its properties, and it must be the same one that is used by the first Interaction Server Application.
4. On the Server Info tab of each Interaction Server Application, configure the same port number and ensure both Applications exist on the same Host.
   
5. Save the configuration.

Pulling Multimedia Interactions from Interaction Queues

Note: Composer 8.1.4 and Interaction Server 8.5.1 are required for enhanced pulling of multimedia interactions. Other eServices components can be 8.5.0.

Starting with 8.1.4, an ORS/Interaction Server protocol extension enhances the mechanism of getting the appropriate interactions for processing from Interaction Server to ORS. With enhanced pulling, the pull mechanism uses the strategy name and allows Interaction Server to set different priorities for different types of interactions (see Interaction Server Options section below). You can also use Composer's Workflow Block, Maximum Interactions property to configure the limit for each strategy. With the old pull mechanism, interactions were pulled for a specific view.

As a result of enhanced pulling, ORS does not need to constantly poll Interaction Server to determine if any interactions are present. This enhanced pull mechanism can result in improvements in performance and reliability for both ORS and URS. Genesys recommends this approach for all eServices customers.

Enhanced Pulling and Interaction Queues

As a result of enhanced pulling, ORS 8.1.4 supports two types of interaction queues:

1. "Enhanced" where SCXML-based applications are assigned to views instead of being assigned to interaction queues (as in previous releases) and an object called a Submitter is used for this (described below). Composer-created interaction process diagrams (associated with SCXML-based routing application) must be published into Configuration Server using Composer 8.1.4. The Orchestration section in the Annex of the Interaction Queue Script object is not present.
2. "Legacy" where SCXML-based applications are assigned to interaction queues and ORS 8.1.4 pulls interactions equally from all interaction queues as occurred in 8.1.3. The Orchestration section in the Interaction Queue Script object contains option application and value of that option specifies name of the Enhanced Routing Script object that handles interactions pulled from any View (filter) associated with the interaction queue. Composer-created interaction process diagrams (associated with SCXML-based applications) are published into Configuration Server using Composer 8.1.3 or earlier.

Interaction Server Options

See the eServices 8.5 Reference Manual for information about required configuration options for Interaction Server.

Note: The Interaction Server pull options are in addition to the push parameters you supply in Composer's View Properties dialog box. For more information, see the Views property in Composer's Interaction Queue block.

Submitters

Orchestration Server supports Submitter objects confgured in Composer. In the Composer GUI, the connection between an interaction queue View and a Workflow is represented by a Submitter object. A Submitter supplies parameters that control how Interaction Server submits interactions to Orchestration Server and subsequently to Universal Routing Server. For more information, see Submitter Objects in the Composer Interaction Queue Block topic.

Reporting on Virtual Queues

Starting with 8.1.4, ORS/Universal Routing protocol allows attaching of Virtual Queue data to multimedia interactions. The attached user data is provided by Universal Routing Server and can then be used by a Reporting Solution, such as a Solution created with Genesys Info Mart. The user data is attached to multimedia interactions and partial data is provided in virtual queue T-Library events.

The list of keys applicable to multimedia interactions includes: RVQID, RVQDBID, RTargetRule, RTargetAgentGroup, RTargetPlaceGroup, RPVQID, Reason, RTargetRuleSelected, RTargetTypeSelected, RTargetObjectSelecteD, RTargetAgentSelected, RTargetPlaceSelected, RTenant, RRequestedSkillCombination.

For example data, see the Contact Server 8.1 API Reference, Query Interactions topic, Examples section.