Revision as of 19:48, September 16, 2015 by Bonniem (talk | contribs) (→‎Pulling from Multiple Interaction Servers)
Jump to: navigation, search

Interacting with eServices

Starting with ORS 8.1.400.27, in your Configuration Environment, the ORS Application, as a client of eServices' Interaction Server, must have connections to each Interaction Server Application of Interaction Server type in its Connections list. Genesys recommends this method for interacting with eServices/Interaction Server. In addition, this method enables ORS to support multiple Interaction Servers. Two options support this feature: switch-multi-links-enabled (mandatory) and mcr-pull-after-error-timeout (optional).


Note: Previously, the configuration for interacting with eServices/Interaction Server involved importing two templates to create two Interaction Server Application objects:

  • An Interaction Server Application template for the Application object that you were using for the actual installation.
  • A T-Server Application template (with its default configuration) for the second Application object.

Starting with ORS 8.1.400.27, you create the Interaction Server Application(s) using only the Interaction Server Application template. There is no need to create an Interaction Server Application using a T-Server Application template for the second Application object. For backward compatibility, both methods of deployment are supported.

Configuring eServices Application with Type T-Server

The information below describes the legacy method of enabling ORS to operate with eServices interactions by configuring two Interaction Server Application objects. The recommended method is described in Pulling from multiple Interaction Servers.

  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 pull 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.

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.

Pulling from Multiple Interaction Servers

Starting with Release 8.1.400.27, Orchestration Server supports the pulling of interactions from multiple Interaction Servers belonging to the same Tenant with one multimedia Switch. In order to support more than one Interaction Server for the same Switch, the ORS Application level option, switch-multi-links-enabled in the orchestration section, must be set to true. This feature is supported for both enhanced pulling and the legacy pulling mechanism.

Pulling Interactions

When this feature is enabled, ORS will send pull requests to each Interaction Server on its Connections list belonging to the same Tenant. In order to limit access by any Interaction Server to some interaction Queue\View\Submitter\Enhanced Routing Script, you must configure permissions on those objects only for the Accounts and Access Groups that were configured on the Interaction Server Application.

Queuing Interactions

If two Interaction Servers are configured, ORS will pull interactions from both servers and the routing strategy (workflow) will place those interactions into different queues. In this case, for a particular interaction, ORS will send RequestPlaceInQueue to same Interaction Server that it pulled that interaction from.

Routing Interactions

If two Interaction Servers are configured (one for e-mail, one for chat) and one set of agents is logged in to handle e-mail interactions, and another set of agents is logged in to handle chat interactions, ORS pulls interactions from both Interaction Servers and the routing workflow routes those interaction to targets. In this case, for a particular interaction, ORS will route the interaction to the target on same Interaction Server from which it pulled the interaction.

Connections to Interaction Servers

ORS can be connected to Interaction Servers in one of the following ways:

  • Starting with 8.1.400.27, you configure ORS to directly connect to Interaction Server Application objects.

ORSMultIxnSup2.png

Configuring Options

Two options are associated with this feature: switch-multi-links-enabled and mcr-pull-after-error-timeout. Option switch-multi-links-enabled is mandatory; mcr-pull-after-error-timeout is optional.

  • An optional Application level option, mcr-pull-after-error-timeout, can be set.

mcr-pull-after-error-timeout

Option section: orchestration

Default value: 120 (seconds)

Valid values: Any non-negative integer from 60 to 3600

Value changes: Immediately upon notification.

This option specifies the time interval, in seconds, when RequestPull for the same strategy or View/Queue will be re-sent to the same Interaction Server, if the previous request triggered a response with one of the specific errors listed below.

Interaction Server Error Messages

If Interaction Server receives RequestPull and some object (such as a strategy\Submitter\View\Queue) that is necessary to process the RequestPull is not visible/accessible for this Interaction Server, it will respond with specific error(s). Depending on object, Interaction Server will respond with one of the following errors: 

__we_error_unknown_view_in_request (42)
__we_error_view_definition_invalid (83)
__we_error_strategy_does_not_exist (107)
__we_error_stategy_has_no_views (108)
__we_error_stategy_is_disabled (109)

If ORS receives such an error from an Interaction Server, it waits for the specified mcr-pull-after-error-timeout timeout before repeating the RequestPull. ORS then sends all subsequent interaction-related requests to the same Interaction Server that this interaction was pulled from. Consult the eServices documentation for configuration information in these cases.

Notes:

  • The list of Tenants specified in ORS and Interaction Server must overlap. If an Interaction Server Application's Tenants list contains different, non-intersecting sets of Tenants from ORS, then ORS will not connect to that Interaction Server. For example, assume ORS has only Tenant A in the Server Info tab of Genesys Administrator and Interaction Server has only Tenant B in the Server Info tab. ORS will not connect to that Interaction Server even if that Interaction Server is specified in ORS’s server connections in the Server Info tab.
  • For some Tenants, there may be different Interaction Servers configured to support different media types. One reason for this could be to support ORS strategies that can create an interaction of a different media type from the parent interaction. In this case, you must configure eServices to ensure that each Interaction Server (via the Media Server connected to that Interaction Server with ESP protocol) is capable of creating an interaction of a different media type.

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.

Comments or questions about this documentation? Contact us for support!