Jump to: navigation, search

Deploying: Strategy Subroutines

Genesys Predictive Routing provides pre-configured strategy subroutines for use with either:

  • Interaction Routing Designer (IRD) and Universal Routing Server (URS)
  • Composer, Orchestration Server (ORS), IRD, and URS

These strategy subroutines are static strategies, that is, they run automatically once they have been set up. They respond to configured conditions without needing ongoing adjustments.

For descriptions of how the subroutines handle agent-surplus and interaction-surplus scenarios, see Interaction Flows.

Out-of-the-Box Strategy Subroutines

You use different strategy subroutines depending on whether your environment contains IRD/URS or Composer/ORS/URS. The following section lists the subroutines in each set:

IRD/URS Strategy Subroutines

  • ActivatePredictiveRouting: Called from a routing strategy when the conditions you specify are met. This subroutine automatically calls additional subroutines that handle scoring, ranking of scored agents, and evaluation as to whether there is an agent available with a score above the threshold (if you configured a threshold).
  • GetScoringAuthToken: Called from the ActivatePredictiveRouting subroutine to authenticate with the Journey Optimization Platform REST API.
  • GetActionFilter: Called from the ActivatePredictiveRouting subroutine to parse the target group string representation.
  • SetIdealAndReadyCondition: Called from subroutine ActivatePredictiveRouting. This is a wrapper subroutine around setup of callback subroutines such as ScoreIdealAgent, isAgentScoreGood. Implements Predictive Routing solution operation modes controlled by the prr-mode option.
  • ScoreIdealAgent: Called by URS before routing an interaction to an Agent Group or Virtual Agent Group at the time URS invokes function SelectDN. This subroutine sorts the agents within the target group according to their scores, in decreasing order. It can also rescale the agent score to the range accepted by URS, if necessary.
  • IsAgentScoreGood: URS calls this subroutine to suppress routing an interaction to the best available agent if that agent does not provide an acceptable match for the interaction. You can use this in conjunction with relaxation thresholds to target better-matched agents preferentially, and expanding the pool of agents if the best-match agents are unavailable.
  • PRRLog (macro): URS strategy macro for adding log messages into the URS log from the strategy subroutines described in this section.
  • PrrIxnCompleted: Attaches Predictive Routing-specific keys to interaction user data. The attached data includes the details required for performance analysis in order to track which models were used for routing. Links to the interaction ID in Genesys Info Mart.

Composer/ORS/URS Strategy Subroutines

The Composer strategy subroutines make use of the underlying functionality provided by the IRD/URS subroutines described above, but enable you to insert this functionality into a Composer workflow. The ActivatePredictiveMatching subroutine, once inserted into your Composer workflow, triggers the ActivatePredictiveRouting subroutine.

To use the ActivatePredictiveMatching subroutine, you must also use the IRD SetIdealAndReadyConditionForORS subroutine.

The PMIxnCompleted and (if needed) PMIxnCleanup subroutines can be inserted into the Composer workflow in the appropriate places. They perform the same functions of attaching matching user data and cleaning up the URS global map as the comparable PrrIxnCompleted and PrrIxnCleanup subroutines.

  • ActivatePredictiveMatching: Called from a Composer workflow when the conditions you specify are met. This subroutine automatically calls additional subroutines that handle scoring, ranking of scored agents, and evaluation as to whether there is an agent available with a score above the threshold (if you configured a threshold).
    This subroutine works by calling the URS-processed ActivatePredictiveRouting subroutine.
  • SetIdealAndReadyConditionForORS: IRD subroutine that provides the URS callbacks for the SetIdealAgent and SetReadyCondition functions in the context of an existing interaction. For details, see the explanation of how the Composer strategy subroutines work in Composer/Orchestration Server (ORS)/Universal Routing Server (URS), below.
  • BindSetMap: An IRD ecma/script strategy, which prepares the tagged URS Memory Map for the agent scores. The map is then associated with the current interaction being managed by the workflow. This binding assures that these maps are automatically deleted when the interaction ends.
  • SetAgentScoreMaps: An IRD ecma/script strategy, which adds the agent score for each agent to the memory map for agent scores.
  • PMIxnCompleted: Attaches Predictive Routing-specific keys to interaction user data. The attached data includes the details required for performance analysis in order to track which models were used for routing. Links to the interaction ID in Genesys Info Mart.

Overview: Integrating Predictive Routing Subroutines into Your Routing Strategy

To perform the integration, do the following steps:

  1. Configuring URS to Support Predictive Routing.
  2. Import the subroutines for your IRD or Composer, depending on which interface you use in your environment. For lists of the subroutines in each package, with descriptions of their functionality, see IRD/URS Strategy Subroutines or Composer/ORS/URS Strategy Subroutines
  3. Define the entry points in your IRD strategy or Composer workflow for the appropriate subroutines. See the complete integration instructions for IRD or Composer for specific recommendations and configuration information.
  4. Set appropriate values for the strategy subroutine configuration options, located in the Predictive_Route_CfgData Transaction List object.
  5. Configure the parameters for the subroutines used in your environment.
  6. Test that the subroutines are correcting directing interactions to agents.

The following sections provides detailed instructions for setting up your subroutines in each environment:

Configuring URS to Support Predictive Routing

There are two main steps to configure URS to work with Predictive Routing:

  1. Whether you are using an IRD-based or Composer-based environment, the Predictive Routing subroutines require that you create the static_strategy configuration option in the [default] section of the URS Application object and set its value to empty. You can set this option either on the level of individual routing points or on the tenant/URS level. Depending on where you set it, the option works slightly differently. This option takes effect immediately and does not require that you restart URS.
  2. Configure the http log for URS to check scoring requests and responses. To do this, set the verbose option in the [web] section to 3.
  3. Set the run_verbose option in the [default] section to 0.
  4. Set the vqtime option in the [default] section to 13:2048.

Strategy Subroutine Integration for URS/IRD

To use the strategy subroutines provided with Predictive Routing, perform the following steps:

  1. Navigate to the Export/Import Bar in IRD and import the strategy subroutines from the URS Strategy Subroutines IP.
    For instructions, see the Export/Import Bar topic in the Interaction Routing Designer Help, which you can open from the Universal Routing landing page.
  2. Open the strategy you plan to use with Predictive Routing and place the ActivatePredictiveRouting Call Subroutine object in the desired location. It must be inserted into the routing strategy before the call to a Routing block or a call to the SelectDN function. This subroutine requires the following three input parameters:
    • skill_target: Has the type STRING. Contains a string representation of the target selected by the URS for an interaction.
    • skill_data: Has the type LIST. It must contain the following two keys:
      • overflow_timeout: A STRING defining a period of time in seconds during which URS tries to route the interaction to the current target.
      • base_priority: An INTEGER defining the priority value the interaction has before the call to the ActivatePredictiveRouting subroutine.
    • default_skill_data: Has the type LIST. It must contain the following keys:
      • AgentScore: Takes either Y or N as its value.
      • predictor: Contains the name of the section in the Predictive_Route_DataCfg Transactions List configuration object that defines predictor configuration.
      • prr-ixn-timestamp: Contains a value defining the number of seconds since midnight when the interaction was queued.
  3. The PrrIxnCompleted subroutine can be inserted either as a Custom Routing step in the Routing object or immediately in front of the object in your strategy that contains a call to the RouteCall function.
  4. The PrrIxnCleanup subroutine can be inserted after the green port exit from either the Routing object, or the object that contains a call to the RouteCall function.
  5. Set values for the following configuration options in the Predictive_Route_DataCfg Transaction List Object.

Strategy Subroutine Integration for ORS/Composer

Predictive Routing comes with a pre-configured Composer strategy subroutine. You can use it as-is, edit it, or create your own based on the model of the pre-configured subroutine.

Design Considerations

The subroutine that comes with Predictive Routing has been created to work efficiently. It:

  1. Minimizes the use of IRD subroutines invoked by the Composer workflow.
  2. Reuses existing IRD subroutines as much as possible to avoid maintenance and upgrade of multiple versions.
  3. Uses the same configuration options as the strategy subroutines for URS, specifically those configured in the Predictive_Route_DataCfg Transaction List object.


Predictive Routing supports ORS strategies designed with Composer. The Composer subroutine ActivatePredictiveMatching is a wrapper around the URS subroutine ActivatePredictiveRouting and calls the latter via URS web API call.

The ActivatePredictiveMatching subroutine contains a number of functional blocks:

  • The Entry block handles the setAgtScores timeout, which is set once before the agent score memory maps are set.
  • The Score request content format_as_map can be set to set to false, which returns the agent scores as a JSON array with entries ordered by decreasing score, or to true, which returns scores as a dictionary, where the keys are employee IDs for the targeted agents and values are their scores for the interaction.
  • The WebRequestScore block is configured to use a single retry in the event of an error. After one retry, if the retry fails, an error is logged and recorded in the attached data and it returns a value of false.
  • The AgentScores ECMA script block parses the returned JSON array and prepares a JSON object with entries ordered by score. In case of JSON object parsing error the script assigns variables varResult.success = "false" and varResult.message = "Parsing of agent scores failed".
  • The AgentScoreMaps subroutine invocation block includes the parCustomerId parameter, which maintains consistency with the IRD version.
  • The PMSetIdealAndReady SCXML State block invokes the IRD SetIdealAndReadyConditionForORS strategy through an HTTP request to URS. Details of the invocation can be found below.

After a target is returned from the Target block in the ActivatePredictiveMatching subroutine, the PMIxnCompleted and PMIxnCleanup subroutines are invoked. They work essentially as the PrrIxnCompleted and PrrIxnCleanup IRD subroutines do, except that the PMIxnCleanup subroutine takes advantage of new memory map cleanup functionality implemented in URS 8.1.400.37, and therefore does not explicitly remove agent score data from the memory map.

The main workflow should invoke the ActivatePredictiveMatching subroutine with the parameters shown in the following image:


The input variables default_skill_data, skill_data, and skill_target are equivalent to the IRD implementation. The varTargetPriority value is the targeting priority to be used. The output is a Boolean value indicating success if true, false if targeting fails.

The implementation and invocation of the IRS SetIdealAndReadyConditionForORS subroutine are a key part of the Composer integration. The implementation within this IRD subroutine provides the URS callbacks for the SetIdealAgent and SetReadyCondition functions. This enables the use of virtual queues for reporting and agent reservation within the main workflow implementation.

The workflow performs scoring authentication in the GetScoringAuthToken subroutine workflow, which obtains the url, api key, and so on from the Predictive_Route_DataCfg Transaction List object, just as in the IRD implementation. The agent scores are obtained from JOP, and URS memory maps are populated with agent ID, connid, and agent score. Again, this is equivalent to the IRD implementation. Next the workflow invokes the SetIdealAndReadyConditionForORS subroutine. After completion, normal workflow targeting proceeds.

The SetIdealAndReadyConditionForORS IRD subroutine uses the IRD function, RequestRouter, shown below, to invoke the SetIdealAgent and SetReadyCondition functions through an internal URS HTTP interface, directed at ##SELF, the URS on which the call is being handled. The Context is the connid to be used.

RequestRouteCompSub.png The example shows the invocation of the SetIdealAgent URS function. The equivalent is performed for the SetReadyCondition function as well.

Invoking the SetIdealAndReadyConditionForORS from a Composer workflow details are shown below.


The two ECMA Script blocks prepare the required information for the invocation, which occurs in the SCXML State block. Details of each block follow.


This block sets the following variables as below varConnID, varURSRequestURL, and ursRequestTimeout are User variables.

try {
	// get the connid of this interaction
	varConnID = _genesys.ixn.interactions[system.InteractionID].voice.connid;
	// set urs call start request
	var ursHost = _genesys.session.getConfigOption('null', "hostname", 
	var ursHttpPort = _genesys.session.getConfigOption('null', "http_port", 
        	varURSRequestURL =  'http://' + ursHost + ':' + ursHttpPort +'/urs/call/' +varConnID + '/exec';
	// fetch timeout in seconds for strategy - TODO - add to xlist
	ursRequestTimeout = 15;
} catch (error) {
	__Log('###DWS StrategyStartInfo error l = ' + uneval(error)  );


The User variable varDefaultSkillDataString is populated from the default_skill_data input variable to the ActivatePredictiveMatching.workflow subroutine, as show below.

try {
	var vKeys = Object.keys( default_skill_data );
	// want “prr-ixn-timestamp:64407|predictor:qaart-predictor|AgentScore:Y"
	var vKeyCount = vKeys.length;
	for ( var iKey = 0; iKey < vKeyCount; iKey++ )
		varDefaultSkillDataString  = varDefaultSkillDataString + vKeys[iKey]  +':' +   default_skill_data[vKeys[iKey]];
		if ( iKey < vKeyCount - 1)  varDefaultSkillDataString = varDefaultSkillDataString + '|';
} catch (error) {
	__Log('###PRRDemo ActivatePredictiveRouting PatseDefSkillData  error  = ' + uneval(error)  );


The onentry element performs the invocation with the following parameters:

  • skill_target and skill_data parameters: Equivalent to the IRD implementation. Input variables to the ActivatePredictiveMatching.workflow subroutine.
  • varPredictorCfg is also the equivalent to the IRD implementation, retrieved from the Predictive_Route_DataCfg Transaction List object for the defined predictor.
	<session:fetch requestid="ursCallRequestId" srcexpr="varURSRequestURL" method="'get'" timeout="ursRequestTimeout" >
		<param name="tenant" expr="_genesys.session.tenant"/>
		<param name="strategy" expr="'SetIdealAndReadyConditionForORS'"/>
	  	<param name="TARGET" expr="skill_target"/>
		<param name="TARGET_TIME_TO_WAIT" expr="skill_data"/>
		<param name="CustomerId" expr="parCustomerId"/>
		<param name="DefaultSkillData" expr="varDefaultSkillDataString"/>
		<param name="PredictorCfg" expr="varPredictorCfg"/>

The transitions from the state are as shown below. The session.fetch.done event body sets the varSuccess User variable to true.


The error.session.fetch event body leaves the varSuccess User variable at the default value of false.


Once this block has completed, the subroutine exits to the main workflow where normal targeting occurs if the invocation was successful. If not, the sample main workflow still performs normal targeting, but skips the PMIxnCompleted and PMIxnCleanup as shown below.


The PMIxnCompleted input is simply the resource selected returned from the Target block.

The PMIxnCleanup input parameters are the varInteractionId, which is the connid of the call being processed, and varResourceSelected, which is the same as for PMIxnCompleted.

Comment on this article:

blog comments powered by Disqus
This page was last modified on 1 February 2018, at 11:32.