Genesys 8.0 intelligent Workload Distribution Deployment Guide

See Figure 35 for an example).

Opens the tenant business process inventory report that contains detailed information about tenant business configuration (such as departments, processes, and rules).

Deployment Guide 113

Chapter 4: Configuration General Configuration

Figure 35: Inventory Report

Import and Export

The Import/Export function enables you to import and export the iWD configuration to and from an XML file. This function allows you to:

•

Transfer configurations between environments and tenants.

•

Load the configuration from the solution template, an exported configuration of a solution that can be used as the basis for configuring a new solution

Figure 36

shows the Import/Export function.

114 intelligent Workload Distribution 8.0

Chapter 4: Configuration General Configuration

Figure 36: Import/Export

Table 2 lists the properties and actions available in the Import/Export view.

Table 2: Import and Export Properties and Actions

Property/Action Description

Allows selection of a configuration file to import.

Configuration

File/Browse

Import

Export custom attributes

Export security policy

Export lookup tables

Export Solution

Business

Configuration

Imports the configuration file that is selected in the field above.

Whether to include the tenant’s custom attributes (see

page 112 ) in the exported configuration file.

Whether to include the tenant’s security policies (see

page 116 ) in the exported configuration file.

Whether to include the tenant’s lookup tables (see

page 120

) in the exported configuration file.

Whether to include the tenant’s Solution Business

Configuration (such as departments, processes, rules, and business calendars) in the exported configuration file.

Export Solution

Technical

Configuration

Whether to include the tenant’s Solution Technical

Configuration (such as runtime nodes and services) in the exported configuration file.

Deployment Guide 115

Chapter 4: Configuration General Configuration

Table 2: Import and Export Properties and Actions (Continued)

Property/Action Description

Solutions

Modules

Export

Which of the tenant’s solutions (see

page 137 ) to include

in the exported configuration file.

Which of the tenant’s modules (see page 126

) to include in the exported configuration file.

Exports the configuration objects that are selected above to an XML configuration file.

Security Policies

A Security Policy (see

Figure 37

) allows you to create custom security roles for each tenant and map them to Genesys Configuration Server Access Groups.

During authentication, a user is granted all of the permissions that are combined from roles that are mapped to the Genesys Configuration Server

Access Groups of which the user is a member. A role can contain any combination of permissions from three groups: administrative permissions

(technical configuration), configuration permissions (business user configuration), and task management permissions (the Global Task List view in iWD Manager). For them to function properly, most permissions must be added in groups; for example, modify or delete permissions are useless without the view permission.

Users (

Person

objects) are assigned to these groups in Genesys Configuration

Server. Any person assigned to a group that you choose to map to under Group

Mapping will have all the selected permissions within iWD Manager. You

116 intelligent Workload Distribution 8.0

Chapter 4: Configuration General Configuration might have to create multiple new Access Groups in Genesys Configuration

Server so the appropriate mapping can be done in the Security Policy dialog.

Figure 37: Security Policies

Key features:

•

Multiple roles can be mapped to the same Genesys Configuration Server

Access Group.

•

Any Person or User in Genesys Configuration Server who is a member of the Administrators or Super Administrators access group in the

Environment Tenant has non-restricted access to all tenants.

•

Automatic Access Group lookup from Genesys Configuration Server.

Table 3 lists the properties available for Security Policies.

Table 3: Security Policy Properties

Property

Name

Description

Role name. This is a mandatory field and must be unique within the tenant.

Deployment Guide 117

Chapter 4: Configuration General Configuration

Table 3: Security Policy Properties (Continued)

Property

Group Mapping

Description

Description

Configuration Server Access Group mapping. This is a mandatory field. Select the Configuration Server Access

Group from the drop-down list.

A plain text description of the role (up to 4,000 characters).

Note:

In iWD 8.0, iWD maintains its own security roles. These roles are independent from Roles that are defined in Genesys Administrator.

That is, for a single user defined in the Genesys System, they may be assigned one or more roles in Genesys Administrator, as well as inheriting one or more roles that have been defined in iWD Manager.

The roles in Genesys Administrator are used to define which tasks a user can perform in specific applications, such as Genesys

Administrator itself as well as Genesys Interaction Workspace. The roles in iWD are used to define what tasks a user can perform in iWD

Manager.

Managed Tenant Details

The Managed Tenant Details view (shown in

Figure 38

) displays and allows

you to modify general managed tenant attributes (see “Tenants” on page 29 ).

Figure 38: Managed Tenant

118 intelligent Workload Distribution 8.0

Chapter 4: Configuration General Configuration

Table 4 lists the attributes and actions available in Managed Tenant view.

Table 4: Managed Tenant Properties and Actions

Property/Action Description

ID Tenant ID. This field becomes read-only after a tenant is created.

Name

CME Tenant

Tenant name.

The name of the corresponding tenant in Genesys

Configuration Server.

When creating your iWD Tenant, select the corresponding

Configuration Server Tenant from the drop-down list. This ensures that the user in iWD Manager only has access to the Configuration Server data objects for which he or she has permission.

In a single-tenant environment the configured managed tenant must map to the

Resources

tenant in Genesys

Configuration Server.

An iWD Managed Tenant may have a one-to-one relationship with a tenant in Genesys Configuration

Server.

Description Tenant description.

Assigned Modules Modules (or functionality) that are assigned to the tenant.

Such modules are available for use in tenant solutions.

Unassigned

Modules

Save/Save &

Close/Cancel/

Delete

Modules that are not assigned to the tenant. Such modules are not available for use in tenant solutions.

Standard iWD Manager functions as described in “Object

dropdown controls. See Figure 39 .

Deployment Guide 119

Chapter 4: Configuration General Configuration

Lookup Tables

Users can specify lookup tables that can be used in rules, custom attributes, and metrics. Lookup tables are simple key/label pairs and are displayed as

Figure 39: Lookup Tables

Distribution Points and Lookup Tables

The concept of Distribution Points has changed in iWD 8.0. They are no longer required, but to keep reporting functionality intact they remain as configuration objects in iWD (as opposed to the Services they were in earlier releases).

Distribution points should be configured as Lookup Tables (see page 120 ) at

the Tenant level. The following procedure describes the steps used to configure

Distribution Points as Lookup Tables.

120 intelligent Workload Distribution 8.0

Chapter 4: Configuration General Configuration

Procedure:

Configuring Distribution Points as Lookup Tables

Purpose: To configure Distribution Points as Lookup Tables and assign them to Rules.

Start of procedure

1. In iWD Manager, configure a new Lookup Table for your tenant as shown

in Figure 40 . The name of the Lookup Table must be

distributionPoints

Note:

The distributionPoints

lookup table must be configured under the iWD managed tenant in which the rule action to assign the distribution point to a task is defined.

Deployment Guide

Figure 40: Create a Lookup Table

121

Chapter 4: Configuration General Configuration

2. In a new or existing Rule Template, add the newly created Lookup Table

(Distribution Point) as a parameter, as shown in

Figure 41

Figure 41: Add as a Parameter to the Rule Template

3. Add an Action.You can copy and paste the Language Expression and Rule

Language Mapping from the rule action

Assign distribution point

that is part of the Standard Rules Template. If you have created a new rule

template, follow the procedure Procedure: Adding a Rule Template to your

Solution, on page 128 . See

Figure 42

Figure 42: Add an Action

122 intelligent Workload Distribution 8.0

Chapter 4: Configuration General Configuration

4. Once the rule template has been updated with the new action, the

Distribution Point can be assigned in Classification Rules, as shown in

Figure 43

Figure 43: Classification Rules

End of procedure

Next Steps

It is possible to configure separate sets of Distribution Points for each Solution:

•

On the Tenant level, several Lookup Tables should be created, each with its own set of Distribution Points.

•

Several Rule Templates should be created. Each has to use its own Lookup

Table.

•

On the Tenant level, several Modules should be created and corresponding

Rule Templates should be assigned.

•

On the Solution level, corresponding Modules should be assigned to the particular Solution.

Each Solution will “see” its own set of Distribution Points during Rules creation.

History

The History page (see

Figure 44

) provides a detailed log of activities that have been performed in iWD Manager by users. Each activity is represented by an

Deployment Guide 123

Chapter 4: Configuration General Configuration audit event that represents what was changed, by whom, and when the change was made.

Figure 44: History

Table 5 lists the properties and actions are available in History view.

Table 5: History View Properties and Actions

Property/Action Description

Date/Time Date/time when the activity was performed.

User

Object Code

Who performed the activity.

Represents the type of object on which the activity was performed:

•

TNT

: Tenant

•

SLT

: Solution

•

SRV_INS

: Service Instance

•

RNT_ND

: Runtime Node

•

RL_TMP

: Rule Template

•

MDL

: Module

•

PRC

: Process

•

: Rule

•

DPT

: Department

•

ROLE

: Security Policy Role

•

: Business Calendar

124 intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components

Table 5: History View Properties and Actions (Continued)

Property/Action Description

Event Code Represents the type of activity:

•

CRT

: Create

•

UPD

: Update

•

DLT

: Delete

•

IMP

: Import

•

EXP

: Export

Formatted description of the activity.

Event

Details Displays attribute-level changes to the object for the activity that is selected in the main History table. Only update activities (Event Code is

UPD

) contain these details.

Modules and Components

The Modules and Components configuration section is used to define objects for iWD functionality:

•

A component is an object that provides a specific iWD function. The following component types are used in iWD:



Service templates: This component provides a template for an iWD service that implements specific functionality. Service templates are preconfigured and are not changeable in iWD Manager. Service

instances (see page 139 ) that are based on service templates, however,

are configurable.



Rule templates (see

page 127 )

Metrics templates (see page 135 )

•

A module (see “Modules”

) is a group of components.

Assigning Modules to Tenants and Solutions

Whenever you create a new Tenant or a new Solution under a Tenant, be sure to verify the Assigned Modules are correct for the Tenant or Solution.

After you create a new Tenant, go to the General section in iWD Manager.

Select the System tenant from the tenant selection drop-down list. In the navigation tree, locate your new Tenant in the Managed Tenant tree. On the right hand side of the screen, be sure that the

Assigned Modules

list includes all

Modules to which you want the Managed Tenant to have access.

After you create a new Solution under that Managed Tenant, select that

Managed Tenant from the tenant selector, and then click on the name of your

Deployment Guide 125

Chapter 4: Configuration Modules and Components

Solution in the navigation tree. On the right hand side of the screen, make sure you assign the Modules you want to use as part of that Solution.

Modules

Modules bundle a set of iWD components into a named functional area.

Modules are used to group “features”, such as capture from WebSphere, reporting, and so on. Each feature maybe be implemented by one or more components where the component can be a service, a rule template, a metric template and a (transformation) script.

This is done in order to:

•

simplify the exporting/importing of configuration that enables particular functions.

•

simplify the enabling/disabling of a particular function to a tenant.

Figure 45

shows an example.

Figure 45: Module

126 intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components

Table 6 lists the properties and actions available in the Modules view:

Table 6: Modules View Properties and Actions

Property/Action Description

Name

Is Inherited

Name of the module

Indicates whether a module is inherited from the parent tenant. This means that the module has been assigned to this managed tenant by the parent tenant. If this is true, all fields are read-only. All standard modules in iWD belong to the

System

tenant, and are inherited by child tenants.

Description

Assigned

Components

Description of the module.

Services, rule templates, metrics templates, and scripts that belong to the module.

Unassigned

Components

Services and rule templates that do not belong to the module.

Save/Save & Close/

Cancel/Delete

Standard iWD Manager functions as described in “Object

) and save it (refer to Table 7

Rule Templates

In the iWD solution, Rule templates are used to set up different business rules for task classification, department, and processes, as well as rules at the global level. Business rules usually have the following:

•

Conditions—“when” or “if” expressions

•

Actions—“then” expressions (required)

•

Parameters—used in the actions and conditions

Business rules within iWD are based on Rule templates that are provided out-of-the-box. The out-of-the-box Rule templates are maintained by IT personnel. IT personnel may create new Rule templates and modify out-of-the-box templates to meet business requirements. Business rule templates provide the foundation for business users to create business rules that govern task handling in iWD. Business users are empowered to make the necessary changes to business rules while IT personnel manage the rule template.

Note:

Definition of Rule templates requires a basic knowledge of the Java programming language.

After you create a new Rule Template, you have to explicitly add it to your

Solution. This outlined in the following procedure.

Deployment Guide 127

Chapter 4: Configuration Modules and Components

Procedure:

Adding a Rule Template to your Solution

Purpose: New Rule Templates need to be explicitly added to your Solution before you can use them. This procedure outlines how to add the Rule

Template to your Solution.

Start of procedure

1. Create the new Rule Template (

Modules & Components > Rule Templates >

New

for the configurable properties). Your new

Rule Template will become a new Component, which needs to be added to a Module.

2. Add the new Rule Template Component to an existing Module, or create a new Module and add it there. Do this by going to Modules & Components >

Modules

. You should see your new Rule Template in the

Unassigned

Components

list. Check it and click the arrow to move it to the

Assigned

Components

list. Save the change.

3. If you used an existing Module in

Step 2 , and that Module is already

assigned to your Solution, you should be done. If you created a new

Module in Step 2

, then you need to add this Module to your Solution. Go to

Services

, select your Tenant, and then click on the name of your

Solution. There you will see a list of

Assigned Modules

and

Unassigned

Modules

. Select your new Module (with your Rule Template in it) from the list of Unassigned Components . Click the arrow to move it to the Assigned

Modules

list. Save the change.

4. If you added the Rule Template to an existing Module, you do not need to redeploy your Solution in order to use the new template. If you created a

new Module in Step 2 , you will be prompted to deploy the Solution first.

Note:

These steps assume you have created the Rule Template under a specific iWD Tenant. You can follow the same steps to create a new template under the System Tenant, if desired.

End of procedure

128 intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components

Table 7 lists the properties available in Rule Template view.

Table 7: Rule Template View Properties

Property

Rule Template

Name

Conditions

Description

The name of the rule template. This field is mandatory.

Actions

The rule condition template; that is, a when or if expression (for example, when due time is in x hours). The

Rule template can contain any number of (or no) conditions. See

“Conditions and Actions”

The rule action template; that is, a then expression (for example, then assign priority). The Rule template can contain any number of actions. See

“Conditions and

Actions” .

Parameters Rule parameters that are used in conditions and actions.

These describe how parameters are presented to the user

(who is creating the rule), how input is validated, and so

on. See “Parameters” on page 131

Functions Allows definition of more complex functions, which then can be referenced in actions and conditions. See

“Functions” on page 133

Save/Save & Close/

Cancel

Standard iWD Manager functions as described in “Object

Table 8 lists the property specifications.

Deployment Guide 129

Chapter 4: Configuration Modules and Components

Conditions and Actions

Although conditions and actions have different purposes, their definition is the same.

Table 8: Conditions and Actions Properties

Property

Language

Expression

Rule Language

Mapping

Description

Semantics of the rule language; meant for business people.

They are simple enough to be understood by non-Java specialists. Language expressions can contain different parameters.

Warning: Do not use the word end

in rule language expressions. Using the word end

causes rule parsing errors.

The same rule language expression, in Java code. This is the real code that is executed; it requires an understanding of Java and JBoss rules. JBoss is the underlying rule engine used in iWD.

Figure 46

shows an example of conditions for a Rule template.

Figure 46: Rules Template—Conditions Tab

Reviewing the third condition, the language expression contains the parameter

{department}

, which is mapped to the rule language. This expression is executed for each task to which this rule can apply, as follows: the parameter is replaced with the current parameter value, which is compared to the task department value, which in turn is retrieved by calling a Task object method and converted to an integer value. During the building of rules, only the

130 intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components language expressions are visible to business users. This enables them to build rules that are easy to read and understand.

Note:

Rule language mapping follows JBoss Rules syntax (which is Java with some minor extensions). Regarding available methods, there is a single variable available to rules called

$data

which represents task attributes as a key-value collection. It is an instance of the

KeyValueCollection

class which is part of Platform SDK (refer to the

Platform SDK 7.6 (or later) Developer’s Guide for more information).

Parameters

Rule-language expressions and the corresponding language mappings (used in conditions and actions) can contain different parameters. For example, the expression

Process is {process}

has the parameter process

Figure 47

shows an example of parameters for a Rule template.

Figure 47: Rules Template—Parameters Tab

Parameters that are used as simple input controls appear only as specific names in action and condition definitions. If a parameter (such as a combo box) is more complex than a simple input control, it must be defined in the Parameters

tab. Table 9

lists the properties in the Parameters tab.

Deployment Guide 131

Chapter 4: Configuration

132

Modules and Components

Table 9: Parameters Tab Properties and Actions

Property/Action Description

Parameter Name

Parameter Type

Configuration

The name of the parameter. This field is mandatory.

The type of input control for the parameter. There are six input control types:

•

SelectConstant

: constant combo box with labels and values.

•

SelectDynamic

: dynamic combo box. Labels and values are received from the specific Java class that implements the interface evo.rules.cmc.RuleSelectDynamicSource.

•

InputText

: input box that allows you to enter any text.

•

InputInteger

: input box that allows you to enter integer values.

•

InputNumber

: input box that allows you to enter number values.

•

InputDate

: input box that allows you to enter date values.

•

LookupTable

: drop-down box with key value pairs that were defined under

Tenant > Lookup Tables.

•

SelectDynamicFiltered

: dynamic combo box with a filter. That Java class that implements

RuleSelectDynamicFilteredSource

This field is mandatory.

The attributes for

SelectConstant

and

SelectDynamic type parameters.

The pattern for

SelectConstant

is the following:

“<value_1>”:”<label_1>”, “<value_2>”:”<label_2>”,

..., “<value_n>”:”<label_n>”

The pattern for

SelectDynamic

is the following:

This field is mandatory for

SelectConstant

and

SelectDynamic

type parameters.

Mapping several instances of a parameter to a single parameter definition

The underscore ( _ ) character in parameter names has a special meaning when building rule templates. It is used to specify an index of the parameter, if the rule expression requires more than one instance of the particular parameter.

The most common example is a range definition. intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components

For example, suppose you need to create a condition which has to check if the task’s due date is in the date1

to date2

range, or in the date3

to date4

range.

There are two possible approaches:

1. Create a condition such as:

Due is in “{dueDT1}” to “{dueDT2}” or in “{dueDT3}” to “{dueDT4}”

This will require the definition of 4 parameters with type InputDate in the

Parameters section. This approach is not very convenient, especially if there is more than one occurrence of the condition/action.

2. Use underscore and index:

Due is in “{dueDT_1}” to “{dueDT_2}” or in “{dueDT_3}” to

“{dueDT_4}”

Using this approach, you need to specify only one parameter, with name dueDT

and type

InputDate

Note:

Rules will not be executed properly if you use underscores while defining parameters in the rule template (for example, dueDT

or thisIsMyTextParam will work fine, whereas due_DT or this_Is_My_Test_Param

will not be recognized). Use underscores only when referring to the multiple instances of the same parameter when creating conditions and actions, as described above.

Functions

When defining rule templates, elements that are more complex than conditions

and actions might be required. The Functions tab (see Figure 48 ) enables you

to write specific Java functions for different purposes for use in rule templates.

The specified functions are used in the Rule Language Mappings.

Note:

During use of a rule function in a condition or action, make sure that each function name and parameter is prefixed with a space, such as the following; otherwise, the function might not be recognized by the rules parser: eval( someFunction( param1, param2) )

Deployment Guide 133

Chapter 4: Configuration Modules and Components

Figure 48: Rules Template—Functions Tab

Table 10

lists the properties that are available in the Functions tab.

Table 10: Functions Tab Properties and Actions

Property/Action Description

Function Name

Description

Body

The name of the function. This property is mandatory.

A short description of the function. This property is optional.

The function code, with the following syntax: function <return type> <function name>(<arguments>) {...}

This field is mandatory.

134 intelligent Workload Distribution 8.0

Chapter 4: Configuration Modules and Components

Metrics Templates

Metrics templates can be used to define various types of metrics that will be available at the business user level to specify actual values for departments and processes. Metrics templates are just like any other module components and must be assigned to a module to be available under departments and processes.

Figure 49

shows an example.

Figure 49: MetricsTemplate

Table 11

lists value types for the Metric template. Refer to “Metrics” on page 203

for more information about Metrics.

Table 11: Metric Template Value Types

Value Type

Time

Flag

Number

Description

Time value in days, hours, minutes, or hours.

Check box for true/false values.

Number value, basic number validation.

Deployment Guide 135

Chapter 4: Configuration Solutions and Services

Table 11: Metric Template Value Types (Continued)

Value Type

Percentage

Date

Lookup Table

Description

Percentage from 0% to 100%.

Calendar control for selecting month, day, and year.

Drop-down list of Lookup Tables configured under the

Tenant.

Solutions and Services

The Services configuration section allows the setup of iWD runtime instances for a specific infrastructure and environment:

•

Use Solution Details view (see page 137

) to create new solutions, as well as to view and modify general solution attributes.

•

Use Runtime Nodes view (see

page 138

) to define runtime nodes in which services will run.

•

Use Services view (see page 139 ) to monitor and manage service status.

•

Use Service Details view (see

page 140

) to create new services, as well as to view and modify configuration of existing services.

•

Use Deployment view (see page 143 ) to deploy solution configuration to

runtime nodes, as well as to activate services.

•

Use Change History view (see

page 144

) to check the history of each deployed configuration version.

Note:

It is recommended that you do not create any Solutions and Services under the System Tenant. You should do so under a Managed Tenant.

136 intelligent Workload Distribution 8.0

Chapter 4: Configuration Solutions and Services

Solution Details

Solution Details view displays, and lets you modify, general solution attributes.

For more information on solutions, refer to “Solutions” on page 30 of

Chapter 2

Figure 50

shows an example.

Figure 50: Solution Details

Table 12

lists the properties and actions available in Solution Details view.

Table 12: Solution Details Attributes and Actions

Property/Action Description

ID The ID of the solution. This field becomes read-only after the solution is created.

Name

Description

The name of the solution.

A description of the solution.

Assigned Modules Modules (or functionality) that are assigned to the solution. Components such as Services and Rule templates from these modules are available for use in the solution.

Unassigned

Modules

Modules that have not been assigned to the solution.

Components from these modules are not available for use in the solution.

Save/Save &

Close/Cancel/

Delete

Standard iWD Manager functions as described in “Object

the solution's services are running. See “Runtime Nodes” on page 30

Deployment Guide 137

Chapter 4: Configuration Solutions and Services

Runtime Nodes

Runtime Nodes view lets you view and configure the runtime nodes in which

for more information about runtime nodes.

Figure 51

shows an example.

Figure 51: Runtime Node

Table 13

describes the properties and actions that are available in Runtime

Nodes view.

Table 13: Runtime Node Properties and Actions

Property/Action Description

Name

Context URL

The name of the runtime node.

The URL of the runtime node. This depends on how the runtime node was installed. For example, a possible context URL is http://localhost:8080/iwd_node, where

8080

is the port used by Tomcat, and iwd_node

is the Runtime Node webapp in the Tomcat container.

New...

Allows for definition of a new runtime node.

138 intelligent Workload Distribution 8.0

Chapter 4: Configuration Solutions and Services

Table 13: Runtime Node Properties and Actions (Continued)

Property/Action Description

Application

Save/Save &

Close/Cancel/

Delete

The iWD Runtime Node application, as configured in the

Configuration Server database. This application is the one that will manage the connection to Interaction Server.

Each Runtime Node must have its own configured

Runtime Node application in Configuration

Manager/Genesys Administrator.

Standard iWD Manager functions as described in “Object

of Chapter 2 for more information about services.

Services

Services view displays the status of each service that has been configured in the solution and allows you to manage service status manually. Refer to

“Services” on page 31

Figure 52

shows an example.

Figure 52: Services View

Deployment Guide 139

Chapter 4: Configuration Solutions and Services

Table 14

describes the properties and actions that are available in the Services view.

Table 14: Services View Properties and Actions

Attribute/Action Description

Runtime Node

Service Name

The runtime node on which the service is running. This field is absent for any service that runs on all available runtime nodes.

The name of the service. Click here to open the Service

Details view (see

page 140 ).

Starts a stopped service.

Status

Status Message

Log

Stops a started service.

Service status:

•

Started

—the service is active (running).

•

Scheduled

—the service is scheduled to run in the future.

•

Queue

—the service is scheduled to run after another job that is in the same execution queue has finished.

•

Stopped

—the service is stopped.

•

Error

—the service has encountered an error during its last operation; error details are provided in the Status

Message column.

•

Not Deployed

—the service is configured in the solution, but the configuration is not yet deployed to the runtime node.

•

Not Accessible

—the runtime node is not accessible.

This can be caused by an invalid runtime node configuration or because the application server on which the node is installed is not running.

Displays additional service-status details, when available, such as an error message. Click it to view details in a larger window (shortcut menu).

Opens the Log Viewer dialog box (see

page 145 ) for the

specified service.

Service Details

Service Details view (see

Figure 53

) displays, and lets you modify, service

specific service types.

140 intelligent Workload Distribution 8.0

Chapter 4: Configuration Solutions and Services

Figure 53: Service Details

Table 15

describes the properties and actions that are available in the Service

Details view.

Table 15: Service Details View Properties and Actions

Property/Action Description

ID The ID of the service. This field becomes read-only after the service has been created. When a new service is created in iWD configuration, the default ID generated by iWD is based on the type of service being created. For example, if a new Web Service Capture Point service is created, the default ID generated by iWD will be

WS_CP_x

, where x

is an integer that increments as additional Web

Service Capture Point services are created.

Service Name The name of the service.

Deployment Guide 141

Chapter 4: Configuration Solutions and Services

Table 15: Service Details View Properties and Actions (Continued)

Property/Action Description

Service Template The template on which the service is based. This field becomes read-only when the service is created. See

“Modules and Components” on page 125

for more information about service templates.

Runtime Node The runtime node on which the service runs. This field is absent for any service that is running on all available runtime nodes.

A description of the service. Description

Properties The properties of the service that configure its functionality:

•

Name

—the name of the property.

•

Default

—whether to use the property’s default value.

•

Value

—the property’s value. Depending on property type, this field can be a text box, check box, or dropdown box. When the

Default

box has been checked, this field is read-only.

Different service types have different properties. For a

detailed reference on specific service types, see “iWD

Services” on page 146

Save/Save &

Close/Cancel/

Delete

View Tasks

Standard iWD Manager functions as described in “Object

comments in the Change History (see page 144 ).

Opens the Global Task List view in iWD Manager. This action is available only for capture points.

142 intelligent Workload Distribution 8.0

Chapter 4: Configuration Solutions and Services

Deployment

Changes to the configuration in iWD Manager are not automatically activated.

Deploy, shown in

Figure 54

, performs this task by distributing a solution's configuration across the defined runtime nodes.

Figure 54: Deploy

Table 16

describes the properties and actions that are available in Deploy.

Table 16: Deploy Properties and Actions

Property/Action Description

Undeployed

Changes/

Undeployed

Changes Details

Comments

Detailed information about activities performed in iWD

Manager since the last deployment. For more details, see

“History” on page 123 .

Deployment comments. They will be displayed as version

Deployment Guide 143

Chapter 4: Configuration Solutions and Services

Table 16: Deploy Properties and Actions (Continued)

Property/Action Description

Deploy

Undeploy

Schedule

Deployment

Deploys the configuration. Depending on the configuration’s complexity and runtime environment characteristics, this action can take several seconds.

Note: Deployment deploys the entire solution whether it is done from the Services section or from the Departments and Processes section. When deploying changes in the

Departments and Processes section, all changes made to

Services will also be deployed.

All configured runtime nodes must be available to deploy.

Deployment generates and copies a set of configuration

XML files and JBoss rules files to runtime nodes. The configuration files are stored in the

WEB-INF/config directory under the runtime node, but the Deploy function handles the files and manual intervention or manipulation of the files is not needed. All files are always regenerated and overwritten each time the configuration is deployed.

Stops all of the services of a solution, and undeploys the configuration from all available runtime nodes. If any runtime node that is defined in the solution is not available, iWD Manager will display a warning message.

All configured services are deactivated. Deployed configuration files are removed and the runtime node reloads the empty configuration.

Allows deployment to be performed on a specific date/hour. This allows you to deploy changes during a quiet period, when there is nothing happening in the system.

Note: If you have more than one iWD Manager instance connected to a single iWD Configuration database, there iwd.host parameter in the iwd.properties

file must be unique for every host on which iWD Manager is running.

The iwd.properties file can be found in the web application server’s webapps

folder for iWD Manager. For example, for Tomcat this might be

<TomcatDirectory>\webapps\iwd_manager\WEB-INF\ classes

Change History

Change History maintains the history of deployed configuration versions.

Whenever a solution configuration is deployed, a new configuration version

144 intelligent Workload Distribution 8.0

Chapter 4: Configuration Solutions and Services record is created that contains all of the changes that have been made in the

configuration since the previous version (deployment). Figure 55 shows an

example.

Figure 55: Change History

Table 17

describes the attributes and actions that are available in Change

History view.

Table 17: Change History Attributes and Actions

Attribute/Action Description

Deployed On

Deployed By

Comments

When the configuration was deployed.

Who deployed the configuration.

Deployment comments.

Log Viewer

Log Viewer (see

Figure 56

) allows you to view iWD service log files remotely.

Various viewing methods can be used, including near-real-time viewing with

Deployment Guide 145

Chapter 4: Configuration iWD Services

Auto Refresh functionality, as well as viewing of historical log files for the particular service.

Figure 56: Log Viewer

iWD Services

iWD services implement actual iWD functionality, such as capturing tasks or loading data into the Data Mart. iWD Services are classified as Core Services,

Capture Points, or Reporting Services.

Note:

Services are configured per solution, and each solution must be configured under a tenant in iWD Manager. Therefore, before configuring services, you must configure a tenant and solution. Refer

to Chapter 3, “Installation,” on page 37 for more information.

Core iWD Services

Core iWD services are mandatory in any iWD solution and enable the core iWD functionality:

146 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

•

Rules Service—Is a mediator between iWD services and rule engine implementation. It allows iWD services to execute various rules

•

Logging Service—Provides internal logging capabilities within an iWD solution

•

Configuration Server Connector Service—Maintains a physical connection to the Genesys Configuration Server

•

Interaction Server Connector Service—Maintains a physical connection to the Genesys Interaction Server

•

Business Context Management Service—Works in conjunction with the

Rules service to enable business rules to be invoked from within routing strategies.

Capture Points

Capture points represent an interface for feeding tasks to iWD. A number of different capture points are available, such as the following:

•

Web Service Capture Point Service—Provides the ability for third-party applications to submit tasks to iWD via a Web service interface. It also provides an interface for managing submitted tasks, such as holding and restarting.

•

Database Capture Point Service—Captures tasks directly from database tables. Configuration for this is based on SQL.

•

XML File Capture Point Service—Captures tasks from XML files. The files should comply with the iWD Task XML schema.

•

WebSphere MQ Capture Point Service—Captures tasks from systems using IBM WebSphere MQ as a message bus. Refer to the iWD 8.0

WebSphere MQ Capture Adapter Reference Guide for more information about this capture point.

•

Beginning in version 8.0.2, eServices offers integrated JMS Capture Point functionality. Refer to the eServices documentation for more information.

Version 8.0.210 of eServices (specifically, the Interaction Server component) also includes integrated XML File Capture Point functionality.

Version 8.1.0 of eServices (the Interaction Server component) includes an integrated Database Capture Point.

Note:

In order for iWD to function properly, a Capture Point ID is required for all tasks. Therefore, when capturing tasks through media servers other than iWD capture points, such as through Genesys E-mail

Server or Genesys SMS Server, you must configure a “dummy”

capture point. Refer to Appendix C, “Adapting the iWD Business

Process for Standard Genesys Channels,” on page 275 for additional

information.

Deployment Guide 147

Chapter 4: Configuration iWD Services

Reporting

The Statistics Adapter Service allows performance of custom aggregations on data and sends the resulting statistics to Genesys Stat Server. Statistics then can be viewed in CCPulse+ or any other Stat Server client.

Historical reporting is enabled by a number of ETL jobs that transform and load iWD runtime data into a separate reporting database that is called the iWD

Data Mart (see Table 18 for a list of preconfigured ETL jobs). Essentially, the

iWD Data Mart is a set of star schemas that contain historical iWD data that is optimized for reporting. The ETL jobs are set up as scheduled services in iWD.

Refer to the iWD Data Mart Reference Guide for more information.

Table 18: Preconfigured ETL Jobs

Job Function

Initialize iWD Data

Load Configuration

Load Intraday

Attribute

Job Name

Function

Schedule

Job Name

Function

Schedule

Job Name

Function

Schedule

Description

Initialize

Initializes the necessary data structures, and populates static dimensions, such as the

AGE dimension.

Runs once.

Load Configuration

Loads updates from iWD configuration tables into dimension tables.

Configurable through service properties; typically runs on a 15-minute cycle.

Load Intraday

Loads updates from the Interaction Server database tables into core fact tables.

Configurable through services properties; recommended that it be scheduled to run after the

Load Configuration Job ends through the Job

Dependency option.

148 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 18: Preconfigured ETL Jobs (Continued)

Job Function

Aggregate Intraday

Attribute

Job Name

Function

Aggregate Statistics

Load Historical

Aggregate Historical

Maintain iWD

Schedule

Job Name

Function

Schedule

Job Name

Function

Schedule

Job Name

Function

Schedule

Job Name

Function

Schedule

Description

Aggregate Intraday

Aggregates data that previously was loaded into fact tables by the Load Intraday Job into aggregation tables.

Recommended that it be scheduled immediately after the Load Intraday Job has completed— typically, running every 15 minutes. The frequency of this aggregate job does not have any bearing on the 15-minute aggregate that is being populated.

Aggregate Statistics

Generate statistics by executing statistics plug-ins.

Recommended that it be scheduled immediately after the Aggregate Intraday Job has completed, because most of the statistics plug-ins are using aggregated facts.

Load Historical

Moves data from intraday fact tables into historical fact tables.

Runs daily through the schedule that is defined in the service properties.

Aggregate Historical

Aggregates data from historical fact tables into

15-minute, hourly, daily, and monthly aggregation tables.

Runs once a day, after the Load Historical Job.

Maintain

Cleanses historical tables—that is, removes expired facts from these tables, based on rules that are defined on the ETL Service property in iWD

Manager.

Runs once a day, after the Aggregate Historical Job.

Deployment Guide 149

Chapter 4: Configuration iWD Services

Table 18: Preconfigured ETL Jobs (Continued)

Job Function

Prune events and interactions

Attribute

Job Name

Function

Schedule

Description

Prune

Removes event logs and interactions from the databases that are loaded in the Data Mart when tasks/interactions have reached their final state.

Runs once a day, after the Maintain Job.

Workforce Management

iWD 8.0 supports Workforce Management objects. A new service has been added, that uses the template “Workforce Management Connector”.

Configuring this service allows you to see some objects that exist in the WFM database.

Recommended Order of Configuration for iWD Services

Table 19

lists the iWD services in their recommended order of configuration and indicates any dependencies on other services.

Scripting Service

Note:

The following table includes all iWD services. The Installation chapter does not provide information on how to configure each service, only some of the services. The general procedure is the same for each service.

Table 19: iWD Services

Name

Logging Service

Configuration Server

Connector

Yes

Interaction Server

Connector

Yes

Mandatory Category

Yes Core

Core

No Core

Dependencies

None

Notes

See

page 152 .

See

page 153 .

Genesys

Configuration Server

Connector

See

page 154 .

None Required only when iWD transformation is being used in

WebSphere MQ or

XML Capture Points.

See

page 156 .

150 intelligent Workload Distribution 8.0

Chapter 4: Configuration

Table 19: iWD Services (Continued)

Name Mandatory Category

Web Service Capture

Point

XML File Capture

Point

Database Capture

Point

WebSphere MQ

Capture Point

Rules Service Yes

Business Context

Management Service

Yes

Database Service

Statistics Adapter

Kettle ETL Service No

Scheduled ETL Job No

WFM Connector No

Capture Point

Core

Reporting

Workforce

Management iWD Services

Dependencies

None

Notes

See

page 157 .

Scripting Service* See

page 159 .

*Scripting Service is only required when iWD transformation is being used.

None See

page 161 .

Scripting Service* See the iWD 8.0

WebSphere MQ

Capture Adapter

Reference Guide for information about deploying this component.

*Scripting Service is only required when iWD transformation is being used.

None See

page 167 .

Genesys

Configuration Server

Connector

See

page 168 .

None

See

page 169 .

See

page 170 .

Database See

page 173 .

Kettle ETL Service A separate scheduled

ETL job that must be created for each job type.

See

page 176 .

Genesys

Configuration Server

Connector

See

page 180 .

Deployment Guide 151

Chapter 4: Configuration iWD Services

Service Log Levels

For each service, a log level can be specified in the logLevel

property. The level should be set to

Default

unless otherwise directed by Genesys Technical

Support.

The possible log levels are:

•

Default

—uses the log level that was configured for the Logging Service (see

“Logging Service” on page 152

•

Debug

—the most detailed informational events that are most useful in debugging an application.

•

Info

—informational messages that highlight the progress of the application.

•

Warning

—potentially harmful situations.

•

Error —error events that might not affect the application’s ability to run.

•

Trace

—turns on all logging.

•

Off

—turns off all logging.

Logging Service

The Logging Service is a mandatory iWD service that provides internal logging capabilities within an iWD solution.

Note:

The Logging Service must be configured even if you only want to create logs through the Genesys Message Server.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 20 are configurable for the Logging

Service.

Table 20: Logging Service Properties

Property

startAutomatically logLevel logAgeInDays

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Info

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level.

Sets the number of days that log files should be kept in the system. A value of

disables this limit. This property is not available if logLevel

is set to

Off

152 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 20: Logging Service Properties (Continued)

Property

logMaxFileSizeMegaBytes logFilesToKeep logDirectory

Description

Sets a limit on the size of a single log file, in megabytes. A value of

0 disables this limit. This property is not available if logLevel

is set to

Off

Sets a limit on the number of log files that are kept for this service, excluding the current log file. A value of

disables this limit. This property is not available if logLevel

is set to

Off

The directory in which the log files will be stored, for all services. If it starts with

(on Unix-based operating systems) or a drive letter (on

Windows), an absolute path will be used; otherwise, the path is relative from the web applications folder on the application server.

Note: It is strongly recommended that you only set the file path to a directory on a local machine, not a remote location such as a shared network drive. Logging to a remote location can severely impact performance.

Configuration Server Connector Service

The Configuration Server Connector service maintains a physical connection to the Genesys Configuration Server. The Configuration Server Connector

service needs to be created manually in iWD Manager.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 21 are configurable for the

Configuration Server Connector service.

Table 21: Configuration Server Connector Service Properties

Property

startAutomatically logLevel reconnectionAttempts

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

In addition to the options and actions described in “Service Details” on page 140

for descriptions of these common properties.

Exception handling:

The maximum number of attempts to connect to Configuration

Server, before connecting to the backup server.

Deployment Guide 153

Chapter 4: Configuration iWD Services

Table 21: Configuration Server Connector Service Properties (Continued)

Property

reconnectionPeriod protocolTimeout eventBufferSize addpTimeout addpRemoteTimeout

Description

Exception handling:

The time, in seconds, between individual reconnection attempts.

Exception handling:

The timeout of the Genesys Configuration Server protocol; specifies the number of milliseconds that the connector will wait for

Configuration Server to respond to the request.

Performance tuning:

The number of Configuration Server events that can be queued up in memory, until they are processed by the service.

Used to configure local and remote timeouts (respectively) for

Advanced Disconnect Detection Protocol (ADDP). In Configuration

Manager or Genesys Administrator, you should enable ADDP on the connection to Interaction Server on the

Connections

tab of your iWD

Runtime Node application.

Used to configure local and remote timeouts (respectively) for

Advanced Disconnect Detection Protocol (ADDP). In Configuration

Manager or Genesys Administrator, you should enable ADDP on the connection to Interaction Server on the

Connections

tab of your iWD

Runtime Node application.

Interaction Server Connector Service

The Interaction Server Connector service maintains a physical connection to the Genesys Interaction Server. This service uses the Genesys Configuration

Server Connector service to retrieve additional configuration data, such as the name of the host and the port of the target Interaction Server.

154 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

, the properties listed in

Table 22 are configurable for the Interaction

Server Connector service.

Table 22: Interaction Server Connector Service Properties

Property

startAutomatically logLevel protocolTimeout eventBufferSize threads attributeFilerInclude

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise instructed by Genesys Technical Support. See

“Service Log Levels” on page 152

for a description of each log level. Depending on the setting of this property, additional

logging properties might be available. Refer to “Logging

Service” on page 152

for descriptions of these common properties.

Exception handling:

The timeout of the Interaction Server protocol; specifies the number of milliseconds that the connector will wait for

Interaction Server to respond to the request.

Performance tuning: The number of Interaction Server events that can be queued up in memory, until they are processed by the service.

Performance tuning: The size of the thread pool.

This value of this property is used to determine which interaction attached data keys will be used to trigger taskUpdated

notifications to a source system, and which interaction attached data keys will be shown on the iWD

Manager's

Attributes

tab when the task is selected in the

Global Task List. A subset of what is defined by this filter may be negated by the filter specified in the attributeFilterExclude

property.

The wildcards that are allowed are the following:

* (asterisk) any number of any characters

? (question mark) any character.

For example:

*Agent*

: Any pair whose name contains “Agent”

?code

: Any pair whose name starts with any character and ends with “code”

Deployment Guide 155

Chapter 4: Configuration iWD Services

Table 22: Interaction Server Connector Service Properties (Continued)

Property

attributeFilterExclude configurationServerConnector addpTimeout addpRemoteTimeout

Description

This value of this property is used to determine which interaction attached data keys will be filtered out of the list that will trigger taskUpdated

notifications to a source system, and which will be shown on the iWD Manager’s

Attributes tab, when the task is selected in the Global Task List. Any attached data key matching those listed in the attributeFilterExclude

property will be filtered out. By default this filter includes the URS-specific attached data keys.

The wildcards that are allowed are the following:

* (asterisk) any number of any characters

? (question mark) any character

For example:

*Agent*

: Any pair whose name contains “Agent”

?code

: Any pair whose name starts with any character and ends with “code”

Note: It is important to configure this property correctly if you are using any custom task attributes so that they will be displayed on the Attributes tab of the Global Task List as expected.

Mandatory dependency: The Configuration Server Connector

service (see page 168

); provides access to the Configuration

Server.

Used to configure local and remote timeouts (respectively) for Advanced Disconnect Detection Protocol (ADDP). In

Configuration Manager or Genesys Administrator, you should enable ADDP on the connection to Interaction Server on the

Connections

tab of your iWD Runtime Node application.

Used to configure local and remote timeouts (respectively) for Advanced Disconnect Detection Protocol (ADDP). In

Configuration Manager or Genesys Administrator, you should enable ADDP on the connection to Interaction Server on the

Connections

tab of your iWD Runtime Node application.

Scripting Service

The Scripting Service is an optional iWD service that provides scripting capabilities for message transformation purposes for XML File Capture Points

156 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

(see

page 159

) and WebSphere MQ Capture Points (see the iWD 8.0

WebSphere MQ Capture Adapter Reference Guide for more information).

Note:

The iWD Scripting Service is not used for the JMS Integrated Capture

Point. Groovy scripting for XML transformation is supported for the

JMS Capture Point, but the scripting is built into Interaction Server.

Refer to the eServices 8.0 User’s Guide for more information.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 23 are configurable for the Scripting

Service.

Table 23: Scripting Service Properties

Property

startAutomatically logLevel

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

In addition to the options and actions described in “Service Details” on page 140

for descriptions of these common properties.

Web Service Capture Point

The Web Service Capture Point is an iWD service that allows third-party systems to submit and manipulate tasks in iWD via a SOAP Web Service interface.

Note:

When developing an integration to a source system using the iWD

Web Service Capture Adapter in a .NET environment, .NET

Framework 2.0 or higher must be in place.

For more information on the Web Service Capture Point, see the iWD Web

Service Capture API documentation.

Note:

The iWD Web Service Capture API documentation is available at

https://sites.google.com/a/iwdlab.com/iwd8/capture/webservice

Deployment Guide 157

Chapter 4: Configuration iWD Services

, the properties listed in

Table 24 are configurable for the Web

Service Capture Point.

Table 24: Web Service Capture Point Properties

Property

startAutomatically logLevel checkIfAlreadyCaptured timezone defaultMediaType defaultTaskExpirationInDays interactionServerConnector webserviceURLMapping

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

page 154 ) that should be used for connectivity to the Interaction

for descriptions of these common properties.

If true, iWD will verify whether another task that has a given captureId

has already been captured.

The time zone of the Web Service Capture Point. Date/time values will be converted from the specified time zone to UTC, before those values are stored in the iWD. If this parameter is not specified, it defaults to the tenant time zone.

The media type attribute that will be assigned to tasks captured by the capture point. The list of available media types is retrieved dynamically from Configuration Server. In Configuration Server itself, the media type attribute is configured as a type of Business

Attribute. The default media type used by the capture point may be overwritten if it is specified in the

attribute in the

<CreateTask> message.

The default task expiration date. All tasks that are captured by this capture point will expire after the specified amount of days. This value can be overridden by explicitly specifying the task expirationDateTime

attribute in the capture data.

Mandatory dependency: The Interaction Server Connector service

(see

Server.

The webservice URL mapping. The URL is composed as follows:

<runtime node context URL>/services/ <webserviceURLMapping>, for example: http://server:8080/iwdnode/services/webserviceCapturePoint

To retrieve a WSDL file for the Webservice, attach

?WSDL

to the URL.

158 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 24: Web Service Capture Point Properties (Continued)

Property

stringOnlyParameters timeZoneIsSupplied

Description

If selected, only string parameters will be accepted.

If this property is selected ( timezoneIsSupplied

), then:

• If the datetime has a timezone set, the date is treated as submitted in that timezone.

• If the datetime has no timezone set, the date is treated as submitted in the capture point’s timezone.

The time format includes the timezone designator and the time without milliseconds, separated by a

(yyyy-MM-dd'T'HH:mm:ssZZ).

For example:

2008-07-21T21:00:00+01:00

If this property is not selected ( timezoneIsSupplied

OFF

), then:

• If the timezone is present in the datetime string, it is ignored, and the datetime is treated as submitted in capture point’s timezone

XML File Capture Point

The XML File Capture Point is an iWD service for capturing tasks from XML files. The XML files can be formatted according to the standard iWD XML

message schema (described in detail in “iWD Messages” on page 225

) or in a custom XML format.

To handle custom XML formats, two transformation scripts must be created: one for input transformation, and one for output. iWD currently supports the

Groovy scripting language for these purposes. For more information on transformation scripts, see the standard iWD input and output transformation scripts that are included in the iWD core package.

These transformation scripts are enabled if you import the

iwd_transform.xml

file into the iWD

System or managed tenant. The

iwd_transform.xml

file is installed when you install the iWD Manager installation package, in the

config

directory. For example, at

C:\Program Files\GCTI\iWD Manager\config

.

Deployment Guide 159

Chapter 4: Configuration iWD Services

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 25 are configurable for the XML File

Capture Point.

Table 25: XML File Capture Point Properties

Properties

startAutomatically logLevel checkIfAlreadyCaptured timezone defaultMediaType defaultTaskExpirationInDays interactionServerConnector threads idleSleepTimeSeconds emergencySleepThreshold

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152

for a description of each log level. Depending on the setting of this property, additional logging properties might be

page 167 ). If specified,

for descriptions of these common properties.

If true, iWD will verify whether another task that has a given captureId

already has been captured.

The time zone of the XML File Capture Point. Date/time values will be converted from the specified time zone to UTC, before those values are stored in iWD. Also, any date/time values that are included in response XML files will be converted to the specified time zone. If this parameter is not specified, it defaults to the tenant time zone.

The media type attribute that will be assigned to tasks captured by the capture point.

The list of available media types is retrieved dynamically from

Configuration Server. In Configuration Server itself, the media type attribute is configured as a type of Business Attribute. The default media type used by the capture point may be overwritten if it is specified in the

attribute in the

message.

attribute in the capture data.

Mandatory dependency: The Interaction Server Connector service

(see page 154

) that should be used for connectivity to the Interaction

Server.

Performance tuning: The size of the thread pool.

Service-idle period when there are no more tasks to process.

Exception handling: Once distribution attempts fail the specified number of times, processing will be held.

160 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 25: XML File Capture Point Properties (Continued)

Properties

emergencySleepSeconds incomingFileDirectory capturedFileDirectory completedFileDirectory rejectedFileDirectory errorFileDirectory

TransformScriptingService

TransformInputScript

TransformOutputScript

TransformOutputRootNode backupFor

Description

Exception handling: Specifies how long to hold processing after emergencySleepThreshold

failed distribution attempts.

The directory in which the XML File Capture Point looks for new files to capture.

The directory into which captured files are put.

The directory into which completed tasks are exported. Each task is exported to an xml file with the naming convention

<interaction id>.xml

The directory into which rejected tasks are exported. Each task is exported to an xml file with the naming convention

<interaction id>.xml

The directory into which files that contain errors are placed.

Optional dependency: Scripting Service (see

XML input/output will be transformed using input/output transformation scripts.

The input transformation script; must be specified when

TransformScriptingService

is selected.

The output transformation script; must be specified when

TransformScriptingService

is selected.

The name of the XML root node in output files.

High Availability:

The primary XML File Capture Point in a high availability setup scenario. This service will perform a backup role in such a setup, and will take over processing if the primary service becomes unavailable.

Database Capture Point

The Database Capture Point is an asynchronous capture point service that creates tasks in iWD, based on records in a database. As a task in iWD goes through its life cycle stages, the Database Capture Point allows you to make updates to the database, to mimic the task life cycle in the originating system.

The Database Capture Point allows execution of a certain database query or update statement, depending on the task state:

Deployment Guide 161

Chapter 4: Configuration iWD Services

•

Capture—the Database Capture Point scans the result set that is returned from the originating database by a special “capture” query and creates tasks in iWD that are based on the information that is provided by each result-set record.

•

Captured—after the task is created in iWD, the Database Capture Point may execute a “captured” update query to update the respective database record and notify the originating system that the task for the respective row in the database has already been created.

•

Assigned—the task has been assigned to a user. The Database Capture

Point may execute an “assigned” update query to update the respective database record and notify the originating system that the iWD task for the respective row in the database has been assigned to the user.

•

Completed—the task has been completed by a user. The Database Capture

Point may execute a “completed” update query to update the respective database record and notify the originating system that the iWD task for the respective row in the database has been completed.

•

Restarted—the task has been restarted (that is, returned to the iWD for reprocessing and distribution at a later time). The Database Capture Point may execute a “restarted” update query to update the respective database record and notify the originating system that the iWD task for the respective row in the database has been restarted.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 26 are configurable for the Database

Capture Point.

Table 26: Database Capture Point Properties

Property

startAutomatically logLevel checkIfAlreadyCaptured timezone

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

page 154 ) that should be used for connectivity to the Interaction

for descriptions of these common properties.

If true, iWD will verify whether another task that has a given captureId

already has been captured.

The time zone of the target database. Date/time values will be converted from the specified time zone to UTC, before those values are stored in the iWD. If this parameter is not specified, it defaults to the tenant time zone.

162 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 26: Database Capture Point Properties (Continued)

Property

defaultMediaType defaultTaskExpirationInDays interactionServerConnector threads idleSleepTimeSeconds emergencySleepThreshold emergencySleepSeconds jdbcDriver jdbcURL username password idField processIdField

Description

The media type attribute that will be assigned to tasks captured by the capture point.

The list of available media types is retrieved dynamically from

Configuration Server. In Configuration Server itself, the media type attribute is configured as a type of Business Attribute.

The core iWD attribute mediaType

may be specified in the

CreateTask message. If the mediaType

attribute is returned as a result of the query configured in captureQuerySQL

, then it will override the default mediaType

specified in the Database Capture Point service property defaultMediaType

attribute in the capture data.

Mandatory dependency: The Interaction Server Connector service

(see

Server.

Performance tuning: The size of the thread pool.

Service-idle period when there are no more tasks to process.

Exception handling: Once distribution attempts fail the specified number of times, processing will be held.

Exception handling: Specifies how long to hold processing after emergencySleepThreshold

failed distribution attempts.

The name of the JDBC driver class to access the database.

The URL of your JDBC connection. For information on how to construct a valid URL, see your JDBC driver documentation.

The name of the database user.

The password of the database user.

The name of the column that uniquely identifies the record in the result set that is returned by the database query that is specified in the captureQuerySql

parameter. The value of the field is mapped to the captureId

parameter in the consecutive update statements.

The name of the column that contains the process ID. If the value of this field matches a process ID in iWD, a process and department will be assigned to the task.

Deployment Guide 163

Chapter 4: Configuration iWD Services

Table 26: Database Capture Point Properties (Continued)

Property

fieldsToAttach captureQuerySql capturedUpdateSql errorUpdateSql assignedUpdateSql completedUpdateSql

Description

A list of fields that will be attached to task data. Multiple fields should be separated by a comma. This property also supports

and

wildcards.

For example: field1,field2,special*

This expression means that the fields that have the names field1

and field2

will be attached, as well as any field that has a name that starts with special

The database query that returns the result set in which each row will be captured as a task in iWD. The result set that is returned by this query must contain also the column that is specified in the idField parameter.

For example: s elect * from TABLE where STATUS=”new”

The database update statement that updates the database to reflect that certain data has already been captured as a task in iWD. The captureId

parameter can be used to reference the particular row.

For example: update TABLE set STATUS='captured' where idField=:captureId

The database update statement that updates the database to reflect that the associated task in iWD has been held by an error. The captureId parameter can be used to reference the particular row.

For example: update TABLE set STATUS='error' where idField=:captureId

The database update statement that updates the database to reflect that the associated task in iWD has been assigned. The captureId parameter can be used to reference the particular row. The userId parameter can be used to set the name of the user who is working on the task.

For example: update TABLE set STATUS='assigned', USER=:userId where idField=:captureId

The database update statement that updates the database to reflect that the associated task in iWD has been completed. The captureId parameter can be used to reference the particular row.

For example: update TABLE set STATUS='completed' where idField=:captureId

164 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 26: Database Capture Point Properties (Continued)

Property

canceledUpdateSql heldUpdateSql queuedUpdateSql errorHeldUpdateSql rejectedUpdateSql restartedUpdateSql

Description

The database update statement that updates the source database to reflect that the associated task in iWD has been canceled. The captureId

parameter can be used to reference the particular row.

For example: update TABLE set STATUS=’canceled’ where idField=:captureId

The database update statement that updates the source database to reflect that the associated task in iWD has been put on hold. The captureId

parameter can be used to reference the particular row.

For example: update TABLE set STATUS=’held’ where idField=:captureId

The database update statement that will be executed when a task, captured by the Database Capture Point, is queued.

For example: update TABLE set STATUS='queued' where idField=:captureId

The database update statement that updates the source database to reflect that the associated task in iWD has been put in an error held status due to an internal processing error. For example, a task may be put into an error held status if no Process is assigned to the task during the Classification phase of the rule execution. The captureId parameter can be used to reference the particular row.

For example: update TABLE set STATUS=’errorHeld’ where idField=:captureId

The database update statement that will be executed when a task, captured by the Database Capture Point, is rejected.

For example: update TABLE set STATUS='rejected' where idField=:captureId

The database update statement that updates the database to reflect that the associated task in iWD has been restarted in iWD. The captureId parameter can be used to reference the particular row.

For example: update TABLE set STATUS='restarted' where idField=:captureId

Deployment Guide 165

Chapter 4: Configuration iWD Services

Table 26: Database Capture Point Properties (Continued)

Property

updatedUpdateSql sourceUpdateQuerySql sourceUpdatedUpdateSql sourceErrorUpdateSql captureBatchSize sourceUpdateBatchSize

Description

The database update statement that updates specific attributes of a task in a special table in the source database when a task has been updated in iWD. The captureId

parameter can be used to reference the particular row.

For example: update UPDATE_TABLE set PRIORITY=:priority where idField=:captureId

The database query that fetches a set of rows, where each row represents an update request coming from the source system. Each such update request may contain one or more columns that represent task attributes. The name of the column represents the name of the task attribute, but the value is the new value of that attribute.

For example: select id, channel, category, by businessValue from

UPDATE_TABLE where processed='F'; id channel category businessValue

-------------------------------------

1 fax new 200

2 e-mail new 150

The database update (or delete) query that will execute against a special table in the source database to mark a particular update as having been processed.

For example: update UPDATE_TABLE set processed=’T’ where idField=:captureId

This update is executed when there is an error executing an update request (the one that is fetched by sourceUpdateQuerySql

). For example, if the task can not be found, then sourceErrorUpdateSql

is executed and the error parameter is set to

Cannot update task with captureId=<taskId>: task not found

Performance tuning:

The maximum number of rows that are to be returned by the query specified in the captureQuerySql

parameter. A value of

sets the

JDBC driver default value.

Performance tuning:

The maximum number of rows that are to be returned by the query specified in the sourceUpdateQuerySql

parameter. A value of

sets the JDBC driver default value.

166 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 26: Database Capture Point Properties (Continued)

Property

backupFor validateConnection validationQuery

Description

High Availability:

The primary Database Capture Point in a high availability setup scenario. This service will perform a backup role in such a setup, and will take over processing if the primary service becomes unavailable.

Enables and disables the validation of the connection to the capture database.

Enables a query to determine if the connection to the capture database is active. The default query works with Oracle databases. For other database servers, Genesys recommends that you use a query that returns at least one row. This is important because if your query returns zero rows the validation will fail. If you do have a query that returns zero rows, Genesys recommends that you complete the following steps:

1. Create an additional

TABLE

in your database that contains one integer field and one row.

2. Run the following statement: select

from

<THAT_TABLE>

Note that the validationQuery

property will only be visible once you select (check) the validateConnection

property.

Rules Service

The Rules Service is a mandatory iWD service that allows iWD services to execute various rules.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 27 are configurable for the Rules

Service.

Table 27: Rules Service Properties

Property

startAutomatically logLevel

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

page 221 for information about configuring multiple

for descriptions of these common properties.

Deployment Guide 167

Chapter 4: Configuration iWD Services

Business Context Management Service

The Business Context Management service is a mandatory service that works in conjunction with the Rules service to enable business rules to be invoked from within routing strategies:

•

The Business Context Management service invokes the Rules service to execute rules for a particular interaction based on the ESP (Business

Context Management Service) method that has been requested

•

The Rules service executes rules, updates interaction attached data and passes this information back to Business Context Management Service and

Interaction Server .

The Business Context Management

Application

is created by the iWD Setup

Utility. The Business Context Management service needs to be created manually in iWD Manager.

Note:

Refer to

Business Context Management Services.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 28 are configurable for this service.

Table 28: Business Context Management Service Properties

Property

startAutomatically logLevel

CMEApplicationName configurationServerConnector

RulesService

Description

Whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless

otherwise instructed by Genesys Technical Support. See “Service

Log Levels” on page 152

for a description of each log level.

Depending on the setting of this property, additional logging

properties might be available. Refer to “Logging Service” on page 152

for descriptions of these common properties.

The name of the corresponding application in the Configuration database. This application was created by using the iWD Setup

Utility. Refer to Procedure: Using the iWD Setup Utility, on page 69

Mandatory dependency: The Configuration Server Connector service (see

page 168 ); provides access to the Configuration Server.

Mandatory dependency: The Rules service (see page 167

) that is used to execute business rules.

168 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 28: Business Context Management Service Properties (Continued)

Property

workerThreads maxPriority

Description

Performance tuning:

The size of the thread pool.

The maximum priority that can be assigned to a task. The priority will be automatically limited to this value if it exceeds it.

Database Service

The Database Service provides a connection to a database server. A typical iWD solution has one defined database connection for historical reporting data

(iWD Data Mart).

The configured database and user must exist in the database server. The user must have read/write permissions to the database.

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 29 are configurable for the Database

Service.

Table 29: Database Service Properties

Property

startAutomatically logLevel

DatabaseType

ServerName

MysqlServerPort

SQLServerCustomURL

SqlServerJDBCURL

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless

otherwise instructed by Genesys Technical Support. See “Service

Log Levels” on page 152 for a description of each log level.

Depending on the setting of this property, additional logging

properties might be available. Refer to “Logging Service” on page 152 for descriptions of these common properties.

The type of the database server. Refer to the Genesys Supported

Operating Environment Reference Manual for supported databases.

The host name of the database server.

The TCP port of the MySQL database server. This is available only when the

DatabaseType

MySQL

If selected, the connection is configured by specifying a custom MS

SQ JDBC URL. This option is available only when the

DatabaseType

MS SQL Server

The JDBC connection URL for MS SQL. This option is available when

SqlServerCustomURL

is selected.

Deployment Guide 169

Chapter 4: Configuration iWD Services

Table 29: Database Service Properties (Continued)

Property

SqlServerPort

DatabaseName

OracleCustomURL

OracleJDBCURL

OracleServerPort

OracleSID

Username

Password

AutoSynchronize

Description

The TCP port of the MS SQL database server. This option is available only when the

DatabaseType

MS SQL Server

The name of the database. This is available only when the

DatabaseType

MS SQL Server

MySQL

If this is checked, the connection is configured by specifying a custom Oracle JDBC URL. This option is available only when the

DatabaseType

Oracle

The JDBC connection URL for Oracle. This option is available when

OracleCustomURL

is selected.

The TCP port of the Oracle database server. This option is available only when the

DatabaseType

Oracle

Oracle System ID of the database. The Oracle System ID (SID) is used to uniquely identify a particular database on a system.

The database user name.

The password for the database.

If selected, iWD will try to initialize/upgrade database structure automatically.

Statistics Adapter

The iWD Extended Statistics Service that existed in 7.6.1 has been merged into the Statistics Adapter service.

The Statistics Adapter Service processes the statistical data created by the

Aggregate Stats ETL job and writes stat-types and filters in the configuration for Genesys Stat Server. CCPulse+ requests iWD statistics from Stat Server, and reads the stat-types and filters from the Stat Server configuration.

170 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 30 are configurable for the Statistics

Adapter Service.

Table 30: Statistics Adapter Service Properties

Property

startAutomatically logLevel triggerMode

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless

otherwise instructed by Genesys Technical Support. See “Service

Log Levels” on page 152

for a description of each log level.

Depending on the setting of this property, additional logging

properties might be available. Refer to “Logging Service” on page 152 for descriptions of these common properties.

How the ETL job will be triggered (started):

•

Trigger using CRON expression

: Starts a job automatically, based on a CRON scheduling expression.

•

Trigger after another scheduled service

: Starts a job automatically after another scheduled job has finished.

•

Trigger manually

: Job can be started manually via the iWD

Manager Services Status screen (see Figure 52 on page 139

triggerMode and startAutomatically

The startAutomatically

property controls whether the service will be started at all. If it is unchecked, the service will not start on any of these trigger events.

You can still start the service manually from the Service Status screen. In that case, the particular service will be in a wait state. It will wait for the trigger event to happen in order to start.

Notes: If the triggerMode

is set to

Trigger manually

and startAutomatically

is unchecked, after deployment when you start the service it will be started, but it will wait for a manual trigger, so you will need to start it again so it can perform its tasks.

If startAutomatically

is checked and the triggerMode

is set to

Trigger using CRON expression

, the service will start according to the CRON expression.

Deployment Guide 171

Chapter 4: Configuration iWD Services

Table 30: Statistics Adapter Service Properties (Continued)

Property

cronExpression executionQueueName dimensionMapping datamartDatabase virtualQueueName configurationServerConnector

CMETenantName statServerName

Description

Standard CRON scheduling expression when triggerMode

is set to

Trigger using CRON expression

. For example, the following expression will cause the job to be executed every 15 minutes:

0 0,15,30,45 * * * ?

See http://www.quartz-scheduler.org/docs/tutorials/crontrigger.

html

for more information.

The execution queue is configured only for jobs that are triggered with a cron expression or triggered manually.

For chained jobs (

Trigger after another scheduled service

), the execution queue automatically assumes the value of the parent job.

For example, if you have Load Intraday chained to Load Config and

Aggregate Intraday chained to Load Intraday, Load Config will never start while Aggregate Intraday is still running.

Scheduled services that have the same executionQueueName

will never be run in parallel within the same solution.

If a scheduled service is triggered while another scheduled service that has the same executionQueueName

is in progress, it will be queued until the other service has completed its processing.

Note: This only works within the boundaries of a single runtime node. If you have services on different nodes, this will have no effect across the nodes.

Defines how statistical dimensions are mapped.

Filter

: Dimensions are mapped to CCPulse+ filters.

Virtual

Queue: Dimensions are mapped to Genesys virtual queues.

A reference to the Database service (see page 169

) that points to the iWD Data Mart database.

Name of the Genesys virtual queue to which statistics are distributed.

A reference to the Configuration Server Connector (see

page 153

); provides connectivity to Configuration Server.

The name of the (Genesys Configuration Server) tenant in which the

Stat Server application is defined.

The name of the Stat Server application.

172 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 30: Statistics Adapter Service Properties (Continued)

Property

serviceIndex extensionSectionName extensionFileName

Description

Statistical service index for configuration options. This should be unique inside the set of indexes, assigned to statistical services served by the one instance of Genesys Stat Server.

Required to support a Genesys reporting environment with multiple instances of Stat Server Java Extensions. This property maps to the section name for the specific Stat Server Java Extension in Stat

Server configuration.

Required to support a Genesys reporting environment with multiple instances of Stat Server Java Extensions. This is the name of the Stat

Server Java extension jar file (

BPR_iWD_Extension.jar

). This file was saved to the Stat Server installation directory during installation of the iWD Stat Extensions. You can find the location of this file in

Stat Server configuration options as the value of the java-libraries-dir option in the java-config

section.

Data Mart ETL Services

The Data Mart ETL services enable batch loading and aggregation of data into the iWD Data Mart. The Kettle ETL service defines general ETL configuration, such as the database in which the aggregated data will be stored.

The Scheduled ETL Job service defines execution characteristics (such as scheduling) for each specific ETL job.

Kettle ETL Service

The Kettle ETL service represents an embedded Kettle ETL Engine that runs

ETL scripts for loading and aggregating task and configuration data into the iWD Data Mart.

Deployment Guide 173

Chapter 4: Configuration iWD Services

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 31 are configurable for the Kettle ETL

service.

Table 31: Kettle ETL Service Properties

Property

startAutomatically logLevel repositoryDirectory customTaskAttributeMapping

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless

otherwise instructed by Genesys Technical Support. See “Service

Log Levels” on page 152

for a description of each log level.

Depending on the setting of this property, additional logging

properties might be available. Refer to “Logging Service” on page 152 for descriptions of these common properties.

The directory on the server in which iWD Data Mart ETL scripts are stored. For example, the default path used when iWD Data

Mart is installed is

C:\Program Files\GCTI\iWD Data Mart\etl.

Up to 10 comma-separated names of a task's custom attributes that will be loaded into

task_fact

custom attribute fields

(

CUSTOM_ATTRIBUTE1-10

). Names must start with a letters, and only underscores and alphanumeric characters are supported.

In order for Kettle to pick them up, it is necessary to create fields in the Event Log Database. In the rpt_interaction

and rpt_esp tables, add the fields in the following format:

Name: <attribute_name>, type: varchar(length)

These fields should be added to the mappings in the Event Log

DAP options in the esp-custom-data and

itx-custom-data sections.

For example, in order to store a custom attribute with the name order_total

in the iWD Data Mart, as a task custom attribute:

1. Create a new column in the rpt_interaction table: order_total

, type: varchar(50)

2. Create a new column in the rpt_esp table: order_total

, type: varchar(50)

3. Create a new option in the esp-custom-data

section of the

Event Log DAP options: order_total=order_total

4. Create a new entry option in the itx-custom-data section of the Event Log DAP options: order_total=order_total

5. Add order_total

to Kettle ETL service’s customTaskAttributeMapping

attribute list

174 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 31: Kettle ETL Service Properties (Continued)

Property

customTaskDimensionMapping

Description

Up to 5 comma-separated names of a task's custom attributes that will be loaded into the

CUSTOM_DIM dimension and associated to the task via the

CUSTOM_DIM_KEY

field. Names must start with a letters, and only underscores and alphanumeric characters are supported.

In order for Kettle to pick them up, it is necessary to create fields in the Event Log Database. In the rpt_interaction and rpt_esp tables, add the fields in the following format:

Name: <attribute_name>, type: varchar(length)

These fields should be added to the mappings in the Event Log

DAP options in the esp-custom-data and

itx-custom-data sections.

For example, in order to store a custom attribute with the name order_total

in the iWD Data Mart, as a task custom attribute:

1. Create a new column in the rpt_interaction table: order_total

, type: varchar(50)

2. Create a new column in the rpt_esp table: order_total

, type: varchar(50)

3. Create a new option in the esp-custom-data

section of the

Event Log DAP options: order_total=order_total

4. Create a new entry option in the itx-custom-data section of the Event Log DAP options: order_total=order_tota l

5. Add order_total

to Kettle ETL service’s customTaskDimensionMapping

attribute list customTenantAttributeMapping Up to 5 comma-separated names of a tenant's custom attributes that will be loaded into the

CUSTOM_DIM

dimension and associated to the tenant via the

CUSTOM_DIM_KEY

field.

customDepartmentAttributeMapping Up to 5 comma-separated names of a department’s custom attributes that will be loaded into the CUSTOM_DIM dimension and associated to the contract via the

CUSTOM_DIM_KEY

field.

customProcessAttributeMapping detailsExpirationDays aggregation15minExpirationDays

Up to 5 comma-separated names of a process's custom attributes that will be loaded into the

CUSTOM_DIM

dimension and associated to the process via the

CUSTOM_DIM_KEY

field.

The number of days after which the detailed task (t ask_fact, task_event_fact,

and task_work_fact

) data will be removed from the database.

The number of days after which the data will be removed from

15 minute aggregation tables.

Deployment Guide 175

Chapter 4: Configuration iWD Services

Table 31: Kettle ETL Service Properties (Continued)

Property

datamartDatabase statisticsAdapter timeZone

Description

Mandatory dependency: Database (see

page 169 ) in which to

load and aggregate reportable data (Data Mart).

Optional dependency: Statistics Adapter service (see

page 170 )

to use for the delivery of statistics for current-intraday reporting.

The time zone that will be used to store all date/time information in the fact tables.

Scheduled ETL Job

In addition to the options and actions described in “Service Details” on page 140

, the properties listed in

Table 32 are configurable for the Scheduled

ETL Job service.

Table 32: Scheduled ETL Job Service Properties

Properties

startAutomatically logLevel

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise

instructed by Genesys Technical Support. See “Service Log Levels” on page 152 for a description of each log level. Depending on the

setting of this property, additional logging properties might be

Manager Services Status screen (see Figure 52 on page 139 ).

for descriptions of these common properties.

176 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Table 32: Scheduled ETL Job Service Properties (Continued)

Properties

triggerMode cronExpression

Description

How the ETL job will be triggered (started):

•

Trigger using CRON expression

: Starts a job automatically, based on a CRON scheduling expression.

•

Trigger after other scheduled service

: Starts a job automatically after another scheduled job has finished.

•

Trigger manually

: Job can be started manually via the iWD

triggerMode and startAutomatically

The startAutomatically

property controls whether the service will be started at all. If it is unchecked, the service will not start on any of these trigger events.

You can still start the service manually from the Service Status screen.

In that case, the particular service will be in a wait state. It will wait for the trigger event to happen in order to start.

Notes: If the triggerMode

is set to

Trigger manually

and startAutomatically

is unchecked, after deployment when you start the service it will be started, but it will wait for a manual trigger, so you will need to start it again so it can perform its tasks.

If startAutomatically

is checked and the triggerMode

is set to

Trigger using CRON expression

, the service will start according to the CRON expression.

Standard CRON scheduling expression when triggerMode is set to

Trigger using CRON expression

. For example, the following expression will cause the job to be executed every 15 minutes:

0 0,15,30,45 * * * ?

See http://www.quartz-scheduler.org/docs/tutorials/crontrigger.

html

for more information.

Deployment Guide 177

Chapter 4: Configuration iWD Services

Table 32: Scheduled ETL Job Service Properties (Continued)

Properties

executionQueueName etlService jobName

Description

The execution queue is configured only for jobs that are triggered with a cron expression or triggered manually.

For chained jobs (

Trigger after another scheduled service

), the execution queue automatically assumes the value of the parent job.

For example, if you have Load Intraday chained to Load Config and

Aggregate Intraday chained to Load Intraday, Load Config will never start while Aggregate Intraday is still running.

Scheduled services that have the same executionQueueName

will never be run in parallel within the same solution.

If a scheduled service is triggered while another scheduled service that has the same executionQueueName

is in progress, it will be queued until the other service has completed its processing.

Note: This only works within the boundaries of a single runtime node. If you have services on different nodes, this will have no effect across the nodes.

Mandatory dependency: The Kettle ETL Service (see

page 173 )

The name (type) of the ETL job. See Table 18, “Preconfigured ETL

Jobs,” on page 148 for descriptions of the various types of iWD Data

Mart ETL jobs. Additional information can be found in the iWD 8.0

Data Mart Reference Guide.

Configuration of iWD Current-Day Statistics in CCPulse+

This section explains how to configure iWD current-day statistics in

CCPulse+. This section contains the following procedures:

•

Procedure: Configuring CCPulse+ for iWD

•

Procedure: Creating a CCPulse+ template, on page 179

Procedure:

Configuring CCPulse+ for iWD

Purpose: In Genesys, iWD current-day statistic measure types are presented as statistic objects, and iWD statistic dimensions are defined as filters. Therefore, it is necessary to combine statistic objects with filters in order to get a measure type for a dimension.

178 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Prerequisites

•

The iWD Data Mart database has been created, and the corresponding

Database service has been configured and is running.

•

The Aggregate Statistics ETL job is configured and running.

•

Stat Server must be running, with the iWD Stat Extensions installed.

•

The Statistics Adapter service must be configured and running.

Start of procedure

1. Start CCPulse+, and connect to the Genesys Stat Server (

File > New

2. In the

Object Types

dialog box, select the

Virtual Queue

object type for the corresponding Genesys tenant and switch, and click

3. In the

Object Instances dialog box, select the virtual queue that is used by the iWD to submit statistics, and click

Finish

Note:

This is the virtual queue that was specified in Procedure: Using the iWD Setup Utility, on page 69 .

End of procedure

Next Steps

•

To be able to view iWD current-day statistics in Genesys CCPulse+, it is necessary to create a CCPulse+ template. The following procedure explains how to create a CCPulse+ template.

Procedure:

Creating a CCPulse+ template

Purpose: To create a CCPulse+ template to use to view iWD current-day statistics.

Start of procedure

1. Open the CCPulse+ template wizard by selecting

Template Wizard... from the Tools menu..

2. In the

Template Definition

dialog box, select the

Virtual Queue

object type in the Available Object Types list, then select the Create New

Template

option, and click

3. In the Pre-defined Statistics dialog box, enter the template name, then click the

New Group

button, and enter a name for the newly created statistic group.

Deployment Guide 179

Chapter 4: Configuration iWD Services

4. Expand the

TotalCustomValue stat type in

Available Statistics

tree view, and select the iWD statistic that you want to add to the template (all iWD statistic names have a “GTL” prefix).

5. Click the

button to add the selected statistic to the newly created statistic group.

6. In the

Requested Statistics

tree view, select the newly added statistic, and then click the

Properties

button.

7. In the

Statistic Properties

dialog box enter

Alias

(which is how the statistic is displayed in CCPulse+). Set

Insensitivity Value

; set

Interval Type

Selection and GTLAggregated

; set

Notification Mode

Changes Based

; and set

Filter

to the filter type that represents the required iWD dimension; and then click

8. Add more statistics and statistic groups, if necessary, and then click the

button.

9. In the

Graph

dialog box, adjust graph parameters, if necessary, and then click

Finish

10. In the CCPulse+ main window, select the virtual queue instance that is used by the iWD to submit statistics. Create a real-time view for this virtual queue:

In the Real-Time Data Template dialog box, select the previously created template from the list, and click

End of procedure

Workforce Management Connector Service

The Workforce Management Connector Service allows you to use objects that exist in the WFM database, such as:

•

Business Units and Sites that belong to Business Units

•

Multi-Site Activities configured under Business Units

•

Activities configured under Sites.

In order to use this service, an

Application

must be configured in

Configuration Server.

Procedure:

Configuring iWD to work with WFM

Purpose: To configure the Workforce Management Connector Service in iWD

Manager, and add a connection to the WFM Server.

180 intelligent Workload Distribution 8.0

Chapter 4: Configuration iWD Services

Prerequisites

•

Workforce Management is installed and configured, as described in the

Workforce Management 8.0 Administrator’s Guide.

•

The attributeFilterExclude

property of the Interaction Server Connector service should contain the

WFM Activity

parameter (see Table 22 on page 155

for a list of the Interaction Server Connector service’s properties).

Start of procedure

1. Login to Configuration Manager or Genesys Administrator.

2. Locate the iWD Manager

Application

object and open its properties.

3. On the

Connections

tab, add a connection to the WFM Server application and save the change.

4. Login to iWD Manager.

5. Configure the corresponding Service in iWD Manager. Refer to “Service

Details” on page 140 for the common service options.

Table 33

lists the additional configurable properties for the Workforce Management

Connector Service.

6. Once the service is configured, WFM objects can be used in iWD.

7. In Departments and Processes, select any Capture Point, Department or

Process, and add the action

Assign WFM Activity

. This action has two drop-down boxes. The first one contains Business Units and Sites, and the second one contains Multi-Site Activities and Activities.

8. If WFM Server is running, a list of Business Units and Sites for which the current user has permissions, is shown.

9. Select any Business Unit or Site.

10. Select a Multi-Site Activity or Activity from the second drop-down box.

11. When a task is generated you can see BU (or Site) in the

WFMContext attribute and Multi-Site Activity (or Activity) in the

WFMActivity

attribute in the task’s properties.

End of procedure

Deployment Guide 181

Chapter 4: Configuration Departments and Processes

Table 33: Workforce Management Connector Service Properties

Property

startAutomatically logLevel

CMEApplicationName configurationServerConnector

Description

Indicates whether the service should be started automatically after the configuration deployment.

The Service log level. This should be set to

Default

unless otherwise instructed by Genesys Technical Support. See

“Service Log Levels” on page 152

for a description of each log level. Depending on the setting of this property, additional

logging properties might be available. Refer to “Logging

Service” on page 152

for descriptions of these common properties.

The name of the WFM Server as configured in Configuration

Manager or Genesys Administrator. This is the WFM Server that was added to the

Connections tab of your iWD Manager application.

Mandatory dependency: The Configuration Server Connector

service (see page 168

); provides access to the Configuration

Server.

Warning!

When any changes are made to the WFM Connector Service

(including creation of the service), the Undeployed Changes message does not appear in the Header bar. The changes do have to be deployed in order to take affect, so be sure to deploy your changes.

Departments and Processes

The Departments and Process configuration section is used to configure iWD business logic.

•

Use Department Details view (see page 183

) to create new departments, and to view and modify general department attributes and contract-level

Metrics (see

page 203

•

Use Process Details view (see

page 185

) to create new processes, and to view and modify general process attributes and process-level Metrics (see

page 203

•

Use Rules view (see page 191 ) to create, view, and modify iWD business

rules.

182 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

•

Use Global Rules (ss

page 192 ) to create, view, and modify global business

rules.

•

Use Business Calendars view (see page 203

) to create, view, and modify iWD business calendars.

•

Use Deployment view (see page 205 ) to deploy solution configurations.

Department Details

Department Details view displays, and lets you modify, general department

attributes. Refer to “Departments and Processes” on page 182

for more information about departments.

Figure 57

shows the Department Details view.

Figure 57: Department Details

Deployment Guide 183

Chapter 4: Configuration Departments and Processes

Table 34

lists the attributes and actions that are available in the Department

Details view.

Table 34: Department Details Attributes and Actions

Attribute/Action

Department Name

Start Date

End Date

Description

Contact Name, Phone and E-Mail

Metrics

Custom Attributes

Save/Save & Close/Cancel/Delete

View Tasks

Description

The ID of the department.

The name of the department. This field is mandatory.

The date on which the department becomes active.

The last day that the department is active. If left empty, the period end date is unconstrained (that is, the department will be active infinitely).

A free-form description of the department.

The contact information for the department, for informational purposes.

A set of user-defined metrics, for reporting purposes (described

in “Metrics” on page 203

A set of user-defined attributes, for informational and reporting purposes. Each attribute must have a name, type (either

Text,

Number, Currency,

Date

), value, and optional description.

Standard iWD Manager functions as described in “Object

Refer to “Departments and Processes” on page 182

Opens a corresponding task view in iWD Manager.

184 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Process Details

Process Details view displays, and lets you modify, general process attributes.

for more information about

processes. Figure 58 shows the Process Details view.

Figure 58: Process Details

Table 35

lists the attributes and actions that are available in Process Details view.

Table 35: Process Attributes and Actions

Attribute/Action

Process Name

Start Date

Description

The ID of the process.

The name of the process. This field is mandatory.

The date on which the process becomes active.

Deployment Guide 185

Chapter 4: Configuration Departments and Processes

Table 35: Process Attributes and Actions (Continued)

Attribute/Action

End Date

Description

Contact Name, Phone and E-Mail

Metrics

Custom Attributes

Save/Save & Close/Cancel/Delete

View Tasks

Description

The last day that the process is active. If left empty, the period end date is unconstrained (that is, the process will be active infinitely).

A free-form description of the process.

The contact information for the process, for informational purposes.

A set of user-defined metrics, for reporting purposes (described

in “Metrics” on page 203

A set of user-defined attributes for informational and reporting purposes. Each attribute must have a name, a type (either

Text,

Number, Currency,

Date

), a value and an optional description.

Standard iWD Manager functions as described in “Object

Figure 59 shows an example of

Opens a corresponding task view in iWD Manager.

Business Calendars

A business calendar is a set of rules that define working days and hours, as well as holidays, that are applicable for the business. Business calendars can be used in iWD rules to perform date and time calculations, taking into account the working schedule of the business. Business calendars are defined on a solution level and can be used in rules only for that particular solution.

Managing Business Calendars in iWD Manager

To create new (or to manage existing) business calendars, open Departments &

Processes view in iWD Manager, and select the Business Calendars entry in

186 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes the tree on the left-hand side of iWD Manager.

a solution’s business calendars.

Figure 59: List of Solution's Business Calendars

The right-hand side of iWD Manager is split horizontally into two panes. The upper displays a list of a solution's business calendars. The

New Business

Calendar

button that is underneath this list is used to create a new business calendar. You can delete business calendars by clicking the delete button that is on the right-hand side of the business calendar in the business calendar list.

When a calendar in the business calendar list is selected, the lower pane displays the attributes of the selected business calendar.

Figure 60

shows an example of the attributes of a business calendar.

Figure 60: Attributes of a Business Calendar

Deployment Guide 187

Chapter 4: Configuration Departments and Processes

Business calendars consist of a set of standard mandatory attributes, as well as

optional business calendar rules. Table 36 describes the standard attributes of a

business calendar.

Table 36: Business Calendar Attributes

Attribute name Description

ID The business calendar identifier. This attribute is generated automatically by iWD Manager when the calendar is created.

Name

Timezone

Week starts on

Week ends on

Start time

End time

The name of the business calendar as it will appear throughout iWD Manager.

The time zone of the business calendar.

The first day of a working week.

The last day of a working week.

The start time of a working day. This attribute is a representation of time in 24-hour format (hh:mm, where

hh are hours and mm are minutes).

The end time of a working day. This attribute is a representation of time in 24-hour format (hh:mm, where

hh are hours and mm are minutes).

Business calendar rules describe exceptions to the regular working schedule that is defined by business calendar standard attributes. It is possible to add and delete business calendar rules by clicking the and icons located on the right side of the business calendar rule list. Depending on calendar placement

188 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes and entry type, the definition of a business calendar rule can have different

attributes. Table 37 describes the attributes of a business calendar rule.

Table 37: Business Calendar Rule Attributes

Attribute Description

Name

Entry type

The name of the business calendar rule.

The type of business calendar rule. This can be one of the following:

Holiday

: The business calendar rule describes a holiday.

Time Change

: The business calendar rule describes working hours that differ from the working hours of the business calendar.

Note: A business calendar's holidays precede time changes; therefore, if any rule sets a day as a holiday, and there is a time change for that specific day, the time change will have no effect. This applies only to holidays that are specified by the rules of the business calendar.

Calendar placement The calendar placement of the business calendar rule. This can be one of the following:

Fixed

: The business calendar rule is tied to a specific date.

Relative

: The business calendar rule is described in a relative way and is not tied to a specific date; for example, the first Monday of September would be a relative description.

Annual

: The business calendar rule that happens every year on a specific date.

Deployment Guide 189

Chapter 4: Configuration Departments and Processes

Table 37: Business Calendar Rule Attributes (Continued)

Attribute

Definition

Description

The contents of this attribute depend on the selected calendar placement and entry type:

Date input control

: This parameter applies only to business calendar rules that have a fixed calendar placement. The year portion of this date is not taken into account, when performing calculations; thus, making this date recurrent on yearly basis.

Relative calendar placement controls

: This set of controls applies only to business calendar rules that have a relative calendar placement. There are three drop down list controls that allow specification of Place in month,

Day of week, and Month of year. Place in month is defined by a value of

Every, First, Second, Third,

Fourth,

and is used in conjunction with

Day of week

(Monday, Tuesday, and so on) to describe relatively the day of month. Month of year defines to what month a business calendar applies; besides month names, it allows also specification of “ any month

,” if the business calendar rule must be recurrent on a monthly basis. The following are examples of definitions of a relative calendar placement:

[Second] [Tuesday] of [September]

[Every][Saturday] of [May]

[First][Monday] of [any month]

Annual calendar placement controls

: This set of controls applies only to business-calendar rules that have an annual calendar placement. There are two dropdown list controls that allow specification of month and date.

Working hours definition controls

: This set of controls applies only to business calendar rules that have a time-change type. Two input controls allow the entering of a start time and end time of the working day. Each value is a representation of time in 24-hour format (hh:mm, where

hh are hours and mm are minutes).

190 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Simple example

The following procedure explains how to configure a simple business calendar.

Procedure:

Configuring a business calendar

Purpose: To configure a business calendar in which Monday-Friday are standard working days 09:00 to 18:00, Saturday 10:00 to 16:00.

Start of procedure

1. Create a new calendar, select

Timezone

, and set

Week starts on Monday

and

Week ends on Friday . Then, set Start time and End time .

2. Add a time-change rule for Saturdays (it will mark it as working day).

3. Some holidays can be specified with rules, such as Christmas or New

Year's Day. See

Figure 61

End of procedure

Rules

Figure 61: Example Business Calendar

In iWD Manager, when a department, process, capture point, or global rule is selected in the navigation tree, the rules for that particular context are shown on the right side of iWD Manager, under the Rules tab. Rules are presented in a list, in the same order as they are applied to tasks. You can change the order of rules by clicking the Up and Down buttons. The logic of a particular rule can be expressed as either a linear rule or a decision table.

Any interaction attribute can be read or updated by business rule conditions and actions, respectively.

Deployment Guide 191

Chapter 4: Configuration Departments and Processes

Global Rules

iWD 8.0 supports “Global Rules”. Global business rules allow you to specify classification and prioritization rules for the entire iWD Solution. They provide:

•

the ability to configure classification rules globally instead of per Capture

Point.

•

the ability to configure prioritization rules globally instead of per

Department or Process.

•

support for tasks (interactions) not captured by iWD Capture Points. This includes Genesys as well as third-party media servers, such as Genesys

E-mail Server, G+ Adapters, and custom integrations previously built using Open Media API.

Global rules are applied before any other rules. This means that for classification, the sequence is:

1. Global rules

2. Capture point rules

3. Department rules

4. Process rules

Note:

Any of these steps are optional. However after Step 3 a process has to be assigned, otherwise the task status will be changed to

ERROR_HELD

For example, a department can be assigned in a global rule or capture point rule, followed by assigning a process at the department level.

Alternatively, a process may be directly assigned in a global rule or capture point rule. If a department or process is assigned in both global and capture point rules based on the same conditions, the capture point rules will override.

For prioritization the sequence is:

1. Global rules

2. Department rules

3. Process rules

Linear Rule

A linear rule is a business rule that has a set of conditions (when) and actions

(then), and is used for a simple (linear) business case. For example, when a

192 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

task is due in 1 to 8 hours, set the task's priority to 20. Figure 62 shows an

example.

Figure 62: Linear Rule

The following procedure explains how to specify a linear rule.

Procedure:

Specifying a linear rule

Purpose: To specify a linear rule for a simple business case.

Start of procedure

1. In iWD Manager, in the

Department & Processes

navigation tree, select a department, process, capture point, or global rule.

2. On the right side of iWD Manager, in the

Rules

tab, click

New Linear Rule

3. In the rule Name, enter a name that identifies the rule.

4. Select the Phase in which to apply the rule. Depending on the current context (capture point, department, process, or global rule) this can be either classification, prioritization, or archiving.

5. If needed, set the

Start Date

and

End Date

Leaving these empty means that the rule activation period is unconstrained.

Deployment Guide 193

Chapter 4: Configuration Departments and Processes

6. Select one or several conditions for the rule from the

Add condition

combo box.

Conditions are logically concatenated by using the logical

AND

function.

Note:

Available actions and conditions are defined in Rules templates. If a new action or condition type is required, add it to either an existing rules template or a new template.

7. Select one or several actions for the rule from the

Add action

combo box.

8. To save the specified rule, click either

Save

Save & Close

End of procedure

Decision Table

Decision tables have a set of the same conditions (when) and actions (then), but have different parameters and are used for a complex (structured) business case.

Use decision tables to avoid dozens of linear rules in the system. Defining a decision table is similar to defining a linear rule. The following procedure explains how to define a decision table.

Procedure:

Defining a decision table

Purpose: To define a decision table for a complex business case.

Start of procedure

1. In the Rules tab, click New Decision Table .

2. Specify the rule

Name, Phase, Start Date,

and

End Date,

as required (in the same way as for a linear rule).

3. Click the add rule icon, and then enter the name of the rule.

4. Select one or several conditions for the rule from the

Add condition

combo box. For each selected condition, set the parameter value.

5. Select one or several actions for the rule from the

Add action

combo box.

For each selected action, set the parameter value.

6. To delete condition, action, or rule, click the Delete icon, which is located on the right side of the column (for conditions and actions), or on the right side of the row (for rules).

194 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

7. Repeat

Steps 3 through 5 , until you have set all of the required cases. The

result is a table in which the columns represent rule conditions and actions and the rows contain real conditions and action parameter values.

Figure 63

shows an example.

Figure 63: Decision Table

8. To save the specified rule, click either

Save

Save & Close

End of procedure

Standard Rules Template

The Standard Rules Template defines the most commonly used rule conditions, actions, parameters, and functions..

Note:

The ACME sample (see

page 94

) contains sample business rules that show how some of the Standard Rules Template conditions and actions can be used in practice. This includes assigning a task to an iWD process based on specific attributes of the task such as Product

Type, as well as setting priority and business value based on the iWD process. The sample also includes examples of how to set the reprioritization interval in a rule.

Deployment Guide 195

Chapter 4: Configuration Departments and Processes

Conditions

Table 38

describes conditions for the Standard Rules Template.

Table 38: Standard Rules Template Conditions

Condition

Business value is

“from” to “to”

Explanation

If the business value of the task is between from and to, then...

Note: This rule condition is designed to test inclusive conditions. That is, the “from” and “to” conditions that are being checked are “>=” and “

”, respectively. This must be understood in order to use this rule condition effectively.

Due Time is in

“from” to “to”

“units”

Priority is

“operator”

“priority”

If the task due date/time is between from and to specified time units, then...

Note: This rule condition is designed to test conditions that are not inclusive. That is, the “from” and “to” conditions that are being checked are “>” and “

”, respectively. This must be understood in order to use this rule condition effectively.

If iWD priority of the task is equal to/not equal to/less than/less than or equal to/greater than/greater than or equal to

value, then...

Channel is

“channel”

Department is

“department”

If the specified channel of the task is channel, then...

If the specified department of the task is department, then...

Integer “attribute”

“operator”

“integerValue”

When the value of a specified custom attribute of type integer

is greater than/less than/equal to

the specified integerValue, then...

Is first prioritization When the rules being applied are part of the initial prioritization step (the value of the task attribute reprioritizeDateTime

is empty), then…

Is reprioritization When the rules being applied are part of the reprioritization step (the value of the task attribute reprioritizeDateTime

is not empty), then…

Media type is

“mediaType”

When the specified media type of the task is mediaType, then...

196 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Table 38: Standard Rules Template Conditions (Continued)

Condition Explanation

String “attribute” equals

“stringValue”

When the value of a specified custom attribute of type string

is equal to the specified stringValue, then…

No process selected If process is not assigned to the task, then..

Process is “process” If the task is assigned to process, then...

Task is overdue When the task is overdue, then...

Actions

Table 39

describes Standard Rules Template actions.

Table 39: Standard Rules Template Actions

Action

Activate task in

“amount” “units”

Explanation

Activate the task in the specified amount of time units.

Activate task in

“amount” working

“units”

Activate the task in the specified amount of time units according to the task's business calendar (working days, working hours and so on).

Note: Business calendar must be assigned to the task before this action can be used.

Archive destination

“archive”

Set the archive destination for the task.

Assign business calendar “business

calendar”

Assign the specified business calendar to the task.

Assign distribution point “distribution

point”

Assign the specified distribution point to the task.

Assign iWD department

“department”

Assign the task to the specified department.

Assign iWD process “process”

Assign the task to the specified process.

Deployment Guide 197

Chapter 4: Configuration Departments and Processes

Table 39: Standard Rules Template Actions (Continued)

Action

Assign WFM

Activity

“wfmActivity”

Increase iWD priority “amount”

Multiply business value “amount”

Reprioritize after

“period”

“periodType”

Explanation

Assign the task to the specified Genesys Workforce

Management Activity.

Note: For iWD to read objects from Genesys Workforce

Management, the Workforce Management Connector

Service (see page 180

) must be configured.

Increase the iWD priority of the task by the specified

amount.

Multiply the business value of the task by the specified

amount.

Reapply prioritization rules to the task after the specified

amount of time units from the current time.

Reprioritize after

“period” working

“periodType”

Reapply prioritization rules to the task after the specified amount of time units, according to the task's business calendar (working days, working hours, and so on).

Note: Business calendar must be assigned to the task before this action can be used.

Request a specific agent for the task.

Request agent

“agent”

Request skill

“skill”

Request a specific skill for the task.

Request agent group

“agentGroup”

Specify which agent group is required to process the task.

Request place group

“placeGroup”

Specify which place group is required to process the task.

Set activation date from

“customAttribute”

Set the activation date/time of the task from the specified

custom attribute of the task.

Set activation time

“time”

Set the time when the task will be activated.

Set business value of the task to the specified value.

Set business value

“businessValue”

Set due date from

“customAttribute”

Set the due date/time of the task from the specified

custom attribute of the task.

198 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Table 39: Standard Rules Template Actions (Continued)

Action Explanation

Set due time “time” Set the time when the task is due.

Set integer

“attribute” value

“integerValue”

Set priority

“priority”

Set string

“attribute” value

“stringValue”

Task Due in

“period”

“periodType”

Set the value of a specified custom attribute of type integer

to the specified integerValue.

Set the iWD priority of the task to the specified value.

Set the value of a specified custom attribute of type string

The task is due in, after the specified amount of time

units.

to the specified stringValue.

Task Due in

“period” working

“periodType”

The task is due in, after the specified amount of time units, according to the task's business calendar (working days, working hours, and so on).

Note: A business calendar must be assigned to the task before this action can be used.

Sets the task’s expiration date/time after the specified

amount of time units.

Task expires in

“period”

“periodType”

Task expires in

“period” working

“periodType”

Sets the task’s expiration date/time after the specified

amount of time units, according to the task’s business calendar (working days, working hours, and so on).

Note: A business calendar must be assigned to the task before you can use this action.

Parameters

Parameters in a Rules template describe the nature of the parameters that are used in rule conditions and actions. This includes how parameters are presented to the user (who is creating the rule), how input is validated, and so on.

Deployment Guide 199

Chapter 4: Configuration Departments and Processes

Table 40

describes parameters for the Standard Rules Template.

Table 40: Rules Template Parameters

Parameter

periodType periodTypeBC businessValue period priority process

Description

Presents you with predefined types of time periods, such as days, hours or minutes.

Presents you with predefined types of time periods used in business calendars, such as working days, working hours, or working minutes.

Allows you to enter the numeric value that represents business value.

Allows you to enter the numeric value. Combined with the period type, it gives the actual value of the time period.

Allows you to enter the numeric value that represents iWD priority.

Presents you with a list of processes that are defined in the solution. This list is dynamic; it changes as processes get added or removed.

periodFrom periodTo customAttribute

Allows you to enter the numeric value that represents the start point of a period, in time units, according to period type.

Allows you to enter the numeric value that represents the end point of a period, in time units, according to period type.

Allows you to enter text that represents the name of a task custom attribute.

skill Presents you with a list of skills that are read from the

Genesys configuration database. This list is dynamic; it changes as skills get added or removed.

businessCalendar Presents you with a list of business calendars that are defined in the solution. This list is dynamic; it changes as business calendars get added or removed.

wfmActivity mediaType

The associated WFM activity.

The media type.

200 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Table 40: Rules Template Parameters (Continued)

Parameter

operator department taskChannels agent agentGroup placeGroup distributionPoint integerValue stringValue attribute archive

Description

Provides operators Equal To, Not Equal To, Less Than,

Less Than or Equal To, Greater Than, and Greater Than

or Equal To, that can be used to compare values of custom attributes of type integer, to values specified in a rule condition.

Presents you with a list of departments that are defined in the solution. This list is dynamic; it changes as processes are added or removed.

Presents you with a list of predefined task channels, read from an iWD Lookup Table.

Presents you with a list of agents’ user names that are read from the Genesys configuration database. This list is dynamic; it changes as agents are added or removed.

Presents you with a list of Agent Groups that are read from the Genesys configuration database. This list is dynamic; it changes as agents are added or removed.

Presents you with a list of Place Groups that are read from the Genesys configuration database. This list is dynamic; it changes as agents are added or removed.

Presents you with a list of distribution points that are defined in the solution. This list is dynamic; it changes as entries in distributionPoint

lookup table are added or removed.

Allows you to enter an integer value for use in rule conditions or actions that evaluate the value of tasks custom attributes.

Allows you to enter a string value for use in rule conditions or actions that evaluate the value of tasks custom attributes.

Allows you to enter text that represents the name of a task attribute.

Presents you with a list of possible archive destinations for expired tasks.

Deployment Guide 201

Chapter 4: Configuration Departments and Processes

Functions

Table 41

describes functions for the Standard Rules Template.

Table 41: Rules Template Functions

Function

getCurrentDT getPeriodDTFrom setDepartmentAndProcess isProcess setTime getDueDT compareInteger setIntValue getIntValue setStringValue getStringValue increaseIntegerValue multiplyIntegerValue getDTValue setDTValue notNull isNull getWFMActivityContext getWFMActivity

Description

Returns the current date and time, in UTC.

Adds the specified amount of time units (minutes, hours, days) to the specified date/time value.

Sets the department and process of the given task from a given string, in department|process format.

Is true if a given task is assigned to a given process, false otherwise.

Sets the time portion of a given date/time value from a string value, in hh:mm format.

Returns the task due date or throws an exception if a due date is not set.

Compares the value of two integers.

Sets the value of a task attribute as an integer.

Gets the value of a task attribute as an integer.

Sets the value of a task attribute as a string.

Gets the value of a task attribute as a string.

Increases the value of an integer by adding to it.

Increases the value of an integer by multiplying it by some factor.

Gets the value of a task attribute as date/time.

Sets the value of a task attribute as date/time.

Is true if a task attribute value is Not Null, false otherwise.

Is true if a given task attribute value is Null, false otherwise.

Retrieves WFM Activity context (Business Unit or Site).

Retrieves WFM Activity.

202 intelligent Workload Distribution 8.0

Chapter 4: Configuration

Metrics

Departments and Processes

A key component of dashboards and reports is the comparison of actual metrics against target goals. Understanding the effectiveness or efficiency of organizations requires measuring performance against important goals that have been set by the organization.

Targets can be associated with a number of objects in iWD Manager, such as processes, departments, or tenants. For example, a work-time goal for a task will differ, based on its process; for example, orders will take longer than address changes.

Figure 64

shows an example.

Figure 64: Metrics

Metrics can be configured at the business-user level for departments and processes using metric types that are defined in available Metrics templates

(see “Metrics Templates” on page 135

). When a metrics value is set, it will be stored as a named attribute in Data Mart. If the value is changed, the updates are pushed through to Data Mart with a

valid_from and valid_to

date/time stamp. This is important for historical reporting; example, if you update the target on November 1 from 2.5 to 3.5, all tasks up to November 1 will use 2.5, and all new tasks will use 3.5.

If the value is set at a department level, it applies to all processes, unless there is a specific value for that process. For example, Department 1 has four processes: A, B, C, and D. Cost/Task @ Department 1 = 2.50, which applies to

Processes B, C, and D. Cost/Task @ Process A = 1.50, which applies only to

Process A.

Using business calendars in iWD rules

After business calendars are defined, it is possible to use them in iWD rules.

Business calendars should be assigned to a task before any business calendar related calculations can be performed on task values.

Table 42

describes the

Deployment Guide 203

Chapter 4: Configuration Departments and Processes business calendar-related actions that are available in the Standard Rules

Template.

Table 42: iWD Rules Actions

Action

Assign business calendar

Reprioritize after

Task Due in

Parameters Description

{businessCalendar} Assigns a business calendar to a task. A business calendar must be assigned to a task, before any business calendar-related calculations can be performed on task values. A dropdown list displays a list of business calendars that are defined for the solution.

{period} working {periodType} Sets a task's re-prioritization date/time to value that is calculated, based on current date/time, the task's business calendar, and specified parameters.

{period} is a numeric value, and

{periodType} specifies “working” minutes, hours, or days.

{period} working {periodType} Sets a task's due date/time to a value that is calculated, based on the task's creation date/time, the task's business calendar, and specified parameters.

{period}

is a numeric value, and

{periodType}

specifies

“working” minutes, hours, or days.

204 intelligent Workload Distribution 8.0

Chapter 4: Configuration Departments and Processes

Table 42: iWD Rules Actions (Continued)

Action

Activate task in

Task expires in

Parameters Description

{period} working {periodType} Sets a task’s activation date/time to a value that is calculated, based on task’s creation date/time, the task’s business calendar, and specified parameters.

{period}

is a numeric value, and

{periodType}

specifies

“working” minutes, hours, or days.

{period} working {periodType} Sets a task’s expiration date/time to a value that is calculated, based on task’s creation date/time, the task’s business calendar, and specified parameters.

{period}

is a numeric value, and

{periodType}

specifies

“working” minutes, hours, or days.

In addition to these standard rule actions that use business calendars, you may build other rule expressions that use business calendar functions. For more details, see https://sites.google.com/a/iwdlab.com/iwd8/rules/bc.

Deployment

Deployment in the Departments and Processes configuration section is identical to Deployment in the Services configuration section. Refer to

“Deployment” on page 143 for more information.

Solution User Access

Departments and processes support instance-level security. The User Access page under Solution allows the assignment of configured User roles to specific departments or processes. Any roles that have been specified on a department level are automatically inherited by all child processes. Process roles are appended to inherited ones.

Deployment Guide 205

Chapter 4: Configuration Departments and Processes

User access can be copied to another solution, if there are departments or processes that have matching IDs.

Note:

This user access only pertains to access to iWD business context elements, through iWD Manager. It does not relate directly to Genesys

Configuration Access Groups or other Configuration Server object permissions.

206 intelligent Workload Distribution 8.0

Chapter

iWD Manager and Task

Management

This chapter describes how to monitor and manage tasks in intelligent

Workload Distribution (iWD).



This chapter contains the following section:

Task Management, page 207

Task Management

Task Management allows monitoring and management of tasks that are being processed by iWD:

•

Use Task Monitoring (see page 207 ) to view a list of tasks that are

associated with different business contexts, as well as details and history for each task.

•

Use Task Operation (see

page 213

) to override configured task-handling logic by performing a manual task operations on specific tasks such as

Hold, Resume, Cancel, and Modify.

•

Use Filters (see page 215 ) to refine the list of tasks that are available in

Task Monitoring by defining filter criteria and visible task attributes

(columns).

Task Monitoring

Task Monitoring allows you to view a current list of tasks for a number of business contexts:

•

Solution

•

Department

Deployment Guide 207

Chapter 5: iWD Manager and Task Management Task Management

•

Process

•

Capture Point

All of the available contexts are displayed in the navigation tree, as shown in

Figure 65

. When a context is selected, the corresponding list of tasks is displayed in the Global Task List.

Figure 65: Navigation Tree

208 intelligent Workload Distribution 8.0

Chapter 5: iWD Manager and Task Management Task Management

Global Task List

The Task List displays a list of tasks for the selected business context, as

illustrated below in Figure 66 .

Figure 66: Global Task List

Table 43

lists the actions that are available in the Global Task List.

Table 43: Global Task List Actions

Attribute/Action Description

Filter

Advanced Filters

Refines the Global Task List and displayed columns, based on the selected filter. For more information on

filters, see “Filters” on page 215

Advanced filters let you further narrow down the tasks that are listed in the Global Task List. Up to three additional conditions can be added to a selected filter. All of the task’s core and extended attributes are available. To add an advanced filter, select the attribute name from the drop down list. Advanced filters cannot be saved and are retained only during an iWD Manager session.

Refresh Refreshes the Global Task List.

Deployment Guide 209

Chapter 5: iWD Manager and Task Management Task Management

Table 43: Global Task List Actions (Continued)

Attribute/Action Description

Hold, Resume,

Cancel, Modify,

Export to XML

Configuration

Click task row

Performs the corresponding operation on the selected task.

The task is selected if the first column of the task row in the list is checked. To select/deselect all tasks in the list, click the first column in the table header. If no task is checked, but task details are opened for some task, this task is also considered to be selected. For more

information on specific operations, see “Task Operations” on page 213 .

Opens the configuration view of the current business context. This action can be restricted by a security policy.

Displays task details. The selected row is marked as

illustrated in Figure 66 .

Task Details

When a task is selected from the Global Task List, its attributes will be

displayed. Figure 67 shows an example of the Task Details.

Figure 67: Task Details

Attributes are broken down into three sections:

•

Top—core task attributes

•

Middle—extended task attributes (displayed only when the task has extended attributes)

210 intelligent Workload Distribution 8.0

Chapter 5: iWD Manager and Task Management Task Management

•

Bottom—custom task attributes. These attributes can be filtered by configuring the attributeFilterInclude

and attributeFilterExclude

properties of the Interaction Server Connector service (see page 154

For attributes that display a timestamp such as Task Due D/T , it is possible to view the offset from the current time by moving the mouse cursor on top of the attribute. The offset is displayed in a hint.

Task History

Task History can be viewed by clicking the History tab in the Task Details view. It displays all of the events that are related to the task that has been selected in the Global Task List.

Table 44

lists the attributes and actions that are available in the Task History.

Table 44: Task History Attributes

Attribute/Action Description

Date/Time The date/time when the event occurred.

Actor Shows who triggered the event. This is empty for iWD system-triggered events.

Deployment Guide 211

Chapter 5: iWD Manager and Task Management Task Management

Table 44: Task History Attributes (Continued)

Attribute/Action Description

Event Code Represents the type of the event:

NEW

: Task has just been created.

CLASSIFY_START

: Task classification has started.

CLASSIFY

: Task classification has finished.

PRIORITIZE_START

: Task initial prioritization has started.

PRIORITIZE

: Task initial prioritization has finished.

HOLD

: Task is held. This can be triggered by the task source system or by the user with the task Held operation

(see

page 213 ).

RESUME

: Task is resumed from the held state. This can be triggered by the task source system or by the user with the

task Resume operation (see page 213

REJECT

: Task was rejected. Either the contract or the process to which the task was associated is expired or not yet active.

ERROR

: A processing error has occurred, and the task was held for that reason.

UPDATE

: Task attributes are updated. This can be triggered by a task source system or based on updates to a task’s attached data from a routing strategy or Genesys

Interaction Server client such as an agent or knowledge worker’s desktop application.

UPDATE_COMPLETE

: Task attributes are updated after a task is completed.

ASSIGN

: Task is assigned to an agent.

FINISH

: Agent has finished working on the task.

FINISH_RETURN

: Agent has returned the task to queue.

STOPPED

: That task has stopped (removed from database).

COMPLETE

: Task is completed.

QUEUE : The task is queued.

DISTRIBUTE_QUEUE

: The task is put into a queue.

DISTRIBUTE_WORKBIN

: The task is put into to a workbin.

REPRIORITIZE

: Task reprioritization has finished.

Event A formatted description of the event.

212 intelligent Workload Distribution 8.0

Chapter 5: iWD Manager and Task Management Task Management

Task Operations

Task operations provide the ability to override manually the configured task-handling business logic. Task operations are performed on the selected

task, as described in “Task Monitoring” on page 207 .

Hold Tasks

The Hold Tasks operation holds the selected task, so that no further processing is performed on a task until it is resumed by the Resume Tasks operation.

When a task is held, it will not be reprioritized, distributed, or assigned to an agent.

Resume Tasks

The Resume Tasks operation resumes processing of a held task. Only held tasks can be resumed.

Cancel Tasks

The Cancel Tasks operation permanently cancels processing of the selected task. A task cannot be canceled if it is has been completed, canceled, or rejected. A task can be canceled if it is already in an Assigned state. The task can be canceled by a source system (through an iWD capture adapter) or by a user through iWD Manager's Global Task List view.

Deployment Guide 213

Chapter 5: iWD Manager and Task Management Task Management

Modify Tasks

The Modify Tasks operation allows an update of a number of task attributes

and, optionally a restart of the task. Figure 68 shows an example.

Figure 68: Modify Task

An attribute will be updated only if the check box that is next to it is checked; it will be checked automatically if a value of the corresponding field has changed. If the task is also restarted, its status is set to New , and it is classified and prioritized again in the same way as a new task.

Example—Save & Restart

Consider the following use case: a task is assigned to a Process, but that

Process has a start date that is in the future. In this scenario, the task is placed into the iWD_Rejected

queue. How can this task be re-initiated once the start date of the Process has been reached? In order to re-initiate processing of this task, you must perform a

Save & Restart

in the Global Task List. Processing of the task will not re-initiate automatically.

Select one or more tasks in the Global Task List and click on the

Modify

button.

At the bottom of the screen, click

Save & Restart

. You do not have to modify any attributes. The result is that the interaction (task) will be placed back into the iWD_New

queue in the iWD business process.

This

Save & Restart

action might be taken if the task is in the

Rejected

status, or potentially for other business reasons where the task should be treated as if it has just been captured.

214 intelligent Workload Distribution 8.0

Chapter 5: iWD Manager and Task Management Task Management

Export Tasks to XML

The Export Tasks to XML operation exports all selected tasks from the Global

Task List to an XML file. The XML file will contain all of the available attributes for each task in the standard iWD format.

Once it has been exported, a task from an XML file can be imported into a third-party application (such as Microsoft Office Excel) for further analysis and processing.

The setUpdateTrigger Function in URS

The URS setUpdateTrigger

function can be used in the Distribution routing strategy prior to the task (interaction) going to the Target block. Then, while the task (interaction) is in the Target block waiting to be routed to an agent, if the Priority attribute is modified through the Global Task List, the internal queue in URS will take this new priority into account. Refer to the Universal

Routing 8.0 Reference Manual for more information about this function.

Note:

The setUpdateTrigger

function was introduced in URS 8.0.1.

Filters

Filters allow you to refine the list of tasks that are displayed in the Global Task

List. Each filter is defined by a set of filter criteria (optional) and table columns

that will be displayed in the Global Task List. Figure 69 shows an example.

Deployment Guide

Figure 69: Filters

215

Chapter 5: iWD Manager and Task Management Task Management

Figure 45

lists the attributes and actions that are available in Filters view.

Table 45: Filter Attributes

Attribute/Action Description

Name

Public

Filter Criteria

The name of the filter.

Whether the filter will be available to all users (checked) or only the current user (unchecked).

Tasks that do not match the defined criteria will be excluded from the Global Task List when the filter is selected. New criteria conditions can be added by selecting them from the

Select criteria to add drop-down. Some criteria conditions are parameterized; for such conditions, parameters can be configured directly in a criteria table (such as status for “Status is ...” criteria).

Table Columns The Global Task List will display these columns when the filter is selected. Columns can be added, removed, and reordered.

Save, Save & Close,

Cancel, Delete

Standard iWD Manager functions as described in “iWD

Manager Overview” on page 97 .

Search by Attributes that are not Displayed in the

Advanced Filter

This section provides some examples how to search by attributes that are not displayed in the Advanced filter by default.

Scenario

You want to filter by an attribute that does not already appear as a column in the interactions

database table. In this case, the data is being held in BLOB format in the flexible_properties column in the database table, but you can add a new column to represent this attribute.

For example, you are submitting tasks through the XML File Capture Adapter, and your messages contain a custom data tag with the key

which is used to send a customer’s city to iWD as part of the task. You want to be able to search for tasks in the Global Task List based on the customer’s city.

Your XML file looks something like this:

…

<Data>

<myCity>Calgary</myCity>

216 intelligent Workload Distribution 8.0

Chapter 5: iWD Manager and Task Management Task Management

…

</Data>

</CreateTask>

</GTLMessages>

You need to do two things in order to enable filtering by this custom attribute.

1. Add a new column to the Interaction Server database interactions

table, giving it a meaningful name that you want to see in the Global Task List’s

Advanced filter drop-down list, such as

City

. Save the change to the database.

2. In Configuration Manager or Genesys Administrator, add a new

Interaction Custom Property.

This is a type of Business Attribute. You can find this by going into Configuration Manager or Genesys

Administrator. Under your Tenant, go to Business Attributes and look at the Attribute Values of the Interaction Custom Property object. The value of the

Name

property on the

General

tab is important; it must be the same as the key of your custom attribute. In this example it would be myCity

. On the

Annex

tab, the value of the translate-to

option in the translation section must exactly match the name of the database column you added in

Step 1

3. Restart Interaction Server.

4. Restart your web application server (such as Tomcat) if it is already running.

5. You should now see your new attribute name in the Advanced filter drop-down list.

Note:

Refer to “Task Attributes and Interaction Properties” on page 245 for

more information about task attributes and interaction properties that can be used for Filtering in the Global Task List.

Deployment Guide 217

Chapter 5: iWD Manager and Task Management Task Management

218 intelligent Workload Distribution 8.0

Chapter

High Availability

This chapter describes high-availability and redundancy in iWD. This chapter is divided into the following sections:



Redundancy, page 219

Configuring Multiple Business Context Management Services, page 221

Deploying Services on Multiple Runtime Nodes, page 222

Interaction Server Redundancy, page 223



Redundancy

A redundant service configuration maintains application availability by eliminating all single points of failure within the application itself. iWD provides the option of distributed deployment across logical and physical servers to minimize single points of hardware or OS/application-service software failures.

Figure 70

illustrates this configuration.

Deployment Guide 219

Chapter 6: High Availability Redundancy

Figure 70: Distributed Deployment with Centralized Management

In addition to this distributed architecture, a redundant solution typically comprises two services:

•

A primary service that runs during normal operations

•

A backup service that supports the primary service in case of failure, with a failover mechanism that ensures that the backup will take over from the primary service in case of service failure.

High Availability for iWD Components

In iWD 8.0, the iWD Capture Points support hot standby.

Redundancy Support Matrix for iWD Services

Table 46

lists intelligent Workload Distribution services and their supported redundancy mode or modes:

Table 46: Redundancy Support Matrix iWD Service

WebSphere MQ Capture

XML Capture

Redundancy Support

Hot Standby

220 intelligent Workload Distribution 8.0

Chapter 6: High Availability Configuring Multiple Business Context Management Services

Table 46: Redundancy Support Matrix (Continued) iWD Service

Database Capture iWD Data Mart ETL

Web Service Capture Point

Business Context Management Service

Redundancy Support

Hot Standby

N/A

N/A (configured in the Configuration Management environment)

Configuring Multiple Business Context

Management Services

It is possible to configure multiple Business Context Management Services

(BCMS) for purposes of high availability or load balancing.

It is important to remember that from a Genesys Configuration Server perspective, the BCMS is a “Third Party Server” to which Interaction Server establishes a connection in order to process requests that will be passed to the iWD rule engine. Interaction Server manages the connection to the BCMS, and how it passes on requests to the BCMS depends on several factors, which will differ depending on the goal of the configuration. The first option is a primary/backup configuration. The second option is a load balancing configuration.

Primary/Backup Configuration

You may configure multiple BCMS in a primary/backup mode. On the BCMS applications themselves (the applications defined in Configuration Server, not the services configured through iWD Manager), you will configure one as primary and one as backup. They can be on the same host or on different hosts, but the ports must be different. On the

Connections

tab of the Interaction

Server application you will only specify the primary BCMS.

On the

External Service

blocks in your routing strategies, where the BCMS external service is invoked, you should list the name of your BCMS

application that is serving as the primary. See also “Business Context

Management Service” on page 168

and “Configuration of List Objects” on page 252

You will also need to configure two BCMS services in iWD, each of which will correspond to one of the applications defined in Configuration Server.

Deployment Guide 221

Chapter 6: High Availability Deploying Services on Multiple Runtime Nodes

Load Balancing Configuration

In this scenario, you do not configure the BCMS applications as primary/backup. Configure your two BCMS applications as an “application cluster”. You do this by creating a new Third Party application in

Configuration Server of type ApplicationCluster (the application template is on the Interaction Management CD and must be imported first). When you create the application, give it a meaningful name such as

BCMS_Cluster_1

Because you need to define different BCMS applications for each Solution in iWD, it is recommended to number the application clusters or use some other nomenclature so you can understand the correlation. In the

Connections

tab of this

ApplicationCluster

object you will add connections to your two (or more)

BCMS applications. In the

Connections

tab of your Interaction Server, add a connection to this ApplicationCluster .

Now, in the List Object (see “Configuration of List Objects” on page 252

) where the correspondence between the BCMS application names and the iWD

Solution IDs is defined, instead of using an actual BCMS application name, you will use the name of your application cluster, such as BCMS_Cluster_1 .

You will not have to change the default logic in the

IWDBP

business process, because the routing strategies will use that List Object to retrieve the name of the ESP application based on the iWD Solution ID. In this case, it will retrieve the name of the

ApplicationCluster

application, which will instruct Interaction

Server to use the two BCMS applications under that cluster when making requests to the external service.

Note:

Refer to the eServices (Multimedia) 8.0 User’s Guide for more information about using Application Clusters for high availability of

ESP Servers.

ESP Object in Interaction Routing Designer

If you do not have the option in IRD to select an application cluster in the ESP object, you can update the options for your IRD application. In the default section, add an option named tools-tuneup

and set the value to extended

Restart IRD.

Deploying Services on Multiple Runtime

Nodes

A Solution’s services can be deployed on multiple runtime nodes. For example:

•

“Backup” services should be deployed on a separate runtime node from

“Primary” services.

222 intelligent Workload Distribution 8.0

Chapter 6: High Availability Interaction Server Redundancy

•

Data Mart-related services should be deployed on yet another runtime node, separate from the backup and primary services

The following procedure provides deployment steps for installing and configuring multiple Runtime Nodes.

Procedure:

Deploying Services on multiple Runtime Nodes

Purpose: To install and configure multiple Runtime Nodes in your environment.

Start of procedure

1. Install additional Application Server(s) (for example, additional instances of Tomcat).

2. Run the iWD Runtime Node setup on every Application Server.

3. Add additional Runtime Node application(s) in Configuration Manager or

Genesys Administrator that map to each installed Runtime Node.

4. Add Runtime Node(s) in iWD Manager for each installed Runtime Node.

5. Install the following components, specifying the specific iWD Runtime

Node to which you are deploying them:

•

iWD Rules

•

iWD Capture

•

iWD Data Mart

6. When deploying for backup purposes rather than partitioning purposes, you must run the install of iWD Rules and iWD Capture twice; once against each Runtime Node (you cannot install iWD Data Mart against two

Runtime Nodes).

End of procedure

Next Steps

•

Configure iWD Services in iWD Manager, specifying the desired Runtime

Node.

Interaction Server Redundancy

Refer to the eServices 8.0 User’s Guide for information about high-availability and redundancy supported by Interaction Server.

Deployment Guide 223

Chapter 6: High Availability Interaction Server Redundancy

224 intelligent Workload Distribution 8.0

Appendix

iWD Messages

This Appendix describes the messages that are supported in iWD 8.0.



It contains the following sections:

Messages, page 225

Task Attributes and Interaction Properties, page 245

Messages

This section provides a detailed description of all of the input and output iWD

Messages that are supported. The following information is documented for each message:

•

Direction—“In” or “Out”. All “In” messages come from the originating system and results in an “Out” message, unless the specific “Out” message is turned off in capture point configuration. “Out” messages are sent as responses to “In” messages, as well as notifications when the task state changes within iWD.

•

Description—a functional description of the message.

•

Format—the XML format of the message. This illustrates a structure of the

entire XML message, by using data types (see Table 47 on page 226 )

instead of node values.

•

Attributes—a description of each attribute that is used in the XML message.

•

Response messages—the response messages that this message can trigger.

Response messages are only applicable for messages that have an “In” direction.

•

Error codes—the error codes that this message can return by using the

“Error” message. Error codes are only applicable for messages that have an

“In” direction.

Deployment Guide 225

Appendix A: iWD Messages Messages

This Appendix also includes the section “Task Attributes and Interaction

Properties” on page 245 , which explains how task attributes are mapped to

interaction properties.

Note:

There is now an XML schema available for the iWD messages. It is available here: https://sites.google.com/a/iwdlab.com/iwd8/capture/schema

Data Types

Table 47

describes the data types used in iWD messages.

Table 47: Data Types for iWD Messages

Type

Integer

String

Boolean

DateTime

Description

An integer value (-2

<value <2

A string value. The maximum length is specified in parentheses, where applicable.

A Boolean value ( true

or false

A date/time value. Date/time should be formatted according to the ISO 8601 standard

YYYY-MM-DDThh:mm:ss

(for example 2007-08-26T21:32:00) and should be provided for the time zone that is configured for the given

Capture Point.

Task Action

Direction: In

Description: This section describes common attributes and responses for all inbound messages.

Format:

<BrokerId>String</BrokerId> or <CaptureId>String(64)</CaptureId>

<Actor>String(255)</Actor>

<Reason>String(255)</Reason>

<ActionDateTime>DateTime</ActionDateTime>

[attributes specific to action]

</ActionName>

</GTLMessages>

Attributes: See

Table 48

226 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

Table 48: Attributes for Task Action Messages

Attribute

BrokerId

Description

The task’s interaction ID. This is a unique ID assigned by

Interaction Server.

CaptureId

Actor (optional)

The task’s ID in the originating system.

The user or system that triggered the message. This is a free-form text field that is used for auditing purposes and will be set to name of the capture point, if none is provided.

Reason (optional) The reason that the message was submitted. This is a free-form text field that is used for auditing purposes.

ActionDateTime

(optional)

The date/time when the action was triggered. This will be set to the current date/time that the message is processed, if none is provided.

Response messages: Action-specific response messages or error messages

(see “Error” on page 230 ).

Error codes: See Table 49 .

Table 49: Error Codes for Task Action Messages

Error code

INVALID_FORMAT

TASK_NOT_FOUND

Description

The message is not formatted correctly.

The task that has the requested CaptureId or BrokerId is not found.

This error code can be triggered for all action messages, except for the

CreateTask message (see “CreateTask” on page 228

Task Notification

Direction: Out

Description: This section describes common attributes and responses for all outbound messages.

Format:

<[notification name]>

<BrokerId>String</BrokerId>

<CaptureId>String(64)</CaptureId>

<CapturePointId>String(16)</CapturePointId>

<DistributionPointId>String(16)</DistributionPointId>

<Actor>String(255)</Actor>

Deployment Guide 227

Appendix A: iWD Messages Messages

<Reason>String(255)</Reason>

<EventDateTime>DateTime</EventDateTime>

[attributes specific to notification]

</[notification name]>

</GTLMessages>

Attributes: See Table 50

Table 50: Attributes for Task Notification Messages

Attribute

BrokerId

Description

The task’s interaction ID. This is a unique ID assigned to the task by Interaction Server.

The task’s ID in the originating system.

CaptureId

CapturePointId The service ID of the capture point by which the task was captured.

DistributionPointId This attribute is provided for backward compatibility.

Actor The user or system that triggered the notification.

Reason

EventDateTime

The reason for the notification.

The date/time when the notification was triggered.

CreateTask

Direction: In

Description: Creates a new task in iWD and populates it with the provided attributes. All attributes of this message are optional. Typically, most of the core task attributes, such as

ProcessId, Priority,

and

BusinessValue,

are calculated and assigned with the iWD rules and, therefore, should be left out.

Interaction Server assigns a unique Interaction ID for each task. Interaction

Server stores and maintains the IDs in the Interaction Server database.

Note:

In the

message for the Web Service Capture Point, the iWD core attribute createdDateTime is now mandatory, not optional.

The value can be null, however. The reason it has been changed from optional to mandatory is to support migration of tasks from iWD 7.6.1 to 8.0, where createdDateTime

would be populated during the redistribution of tasks from 7.6.1 to 8.0.

Format:

Standard action attributes, as documented in “Task Action” on page 226 ,

except for

BrokerId

228 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

<channel>String(32)</channel>

<mediaType> string(32) </mediaType>

<category>String(32)</category>

<activationDateTime>DateTime</activationDateTime>

<dueDateTime> DateTime </dueDateTime>

<expirationDateTime> DateTime </expirationDateTime>

<businessValue> Integer </businessValue>

<priority>Integer</priority>

<processId>String(16)</processId>

<Ext>

<customerID>String(64)</customerID>

<customerSegment> String(64)</customerSegment>

<productType> String(64)</productType>

<productSubtype> String(64)</productSubtype>

<resultCode> String(64)</resultCode>

<sourceFirstCreatedDateTime>DateTime</sourceFirstCreatedDateTime>

<sourceCreatedDateTime>DateTime</sourceCreatedDateTime>

<sourceDueDateTime>DateTime</sourceDueDateTime>

<sourceProcessType> String(64)</sourceProcessType>

<sourceProcessSubtype> String(64)</sourceProcessSubtype>

<sourceTenant> String(64)</sourceTenant>

</Ext>

<Data>

<CustomAttribute1> String(255)</CustomAttribute1>

...

</Data>

<Hold>Boolean</Hold>

</CreateTask>

</GTLMessages>

Attributes: See Table 51

Table 51: Attributes for CreateTask Messages

Attribute

Hold

CaptureId

(optional) mediaType

Description

Whether to hold the task initially. If true, the task will be created with its initial status set to

NewHeld

and will not be processed further, until a subsequent

ResumeTask

message

(see “ResumeTask” on page 241

If a

CaptureId

is not provided, it will be assigned to the same generated value as

BrokerId

If a media type is specified, it will override the default media type configured for the iWD Capture Point Service that is being used.

See “Task Action” on page 226

and “TaskInfo” on page 231 for the

description of the remaining attributes.

Response message:

TaskCreated

(see “TaskCreated” on page 230

Deployment Guide 229

Appendix A: iWD Messages Messages

Error codes: see Table 52 .

Table 52: Error Codes for CreateTask Messages

Error code

TASK_ALREADY_CAPTURED

Description

If the captures point’s checkIfAlreadyCaptured

flag is enabled, iWD will check whether a task that has a given captureId already exists in the database. If this is the case, the task will not be captured, and an error message that has the

TASK_ALREADY_CAPTURED code will be submitted to the

Outbound queue.

TaskCreated

Direction: Out

Description: The TaskCreated message is submitted as a response to the

CreateTask

message (see page 228 ) and indicates successful task creation.

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskCreated>

</GTLMessages>

Error

Direction: Out

Description: The

Error

message is submitted as a response to iWD request messages, indicating that the requested operation has failed.

Format:

<Error>

<Message>String</Message>

<Code>String</Code>

<Parameter>String</Parameter>

...

</Error>

</GTLMessages>

230 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

Attributes: See Table 53

Table 53: Attributes for Error Messages

Attribute

Message

Code

Parameter

Description

The formatted error message.

The error code (string).

The error parameter. There can be zero, one, or multiple error parameters. The number of parameters is specific to each error code.

GetTaskInfo

Direction: In

Description: Request task details by the given task's capture ID or interaction

ID.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

</GetTaskInfo>

</GTLMessages>

Response message: “TaskInfo” .

TaskInfo

Direction: Out

Description: The TaskInfo message is submitted as a response to the

GetTaskInfo

message (see “GetTaskInfo” on page 231 ) and provides detailed

information about the requested task.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

<tenantId>String(16)</tenantId>

<solutionId> String(16)</solutionId>

<DepartmentId> String(16)</DepartmentId>

<processId> String(16)</processId>

<channel>String(32)</channel>

<mediaType> String(32) </mediaType>

<category> String(32)</category>

<status> String(16)</status>

<businessCalendarId> String(16)</businessCalendarId>

<createdDateTime>DateTime</createdDateTime>

<heldDateTime>DateTime</heldDateTime>

Deployment Guide 231

Appendix A: iWD Messages Messages

<assignedDateTime>DateTime</assignedDateTime>

<completedDateTime>DateTime</completedDateTime>

<activationDateTime>DateTime</activationDateTime>

<dueDateTime>DateTime</dueDateTime>

<expirationDateTime>DateTime</expirationDateTime>

<priority>Integer</priority>

<reprioritizeDateTime>DateTime</reprioritizeDateTime>

<businessValue>Integer</businessValue>

<assignedToUser>String(64)</assignedToUser>

<Queue>String(255)</Queue>

<QueueType>String(16)</QueueType>

<QueueTarget>String(255)</QueueTarget>

String(16)

</distributionPointId>

<Ext>

<customerID>String(64)</customerID>

<customerSegment> String(64)</customerSegment>

<productType> String(64)</productType>

<productSubtype> String(64)</productSubtype>

<resultCode> String(64)</resultCode>

<sourceFirstCreatedDateTime>DateTime</sourceFirstCreatedDateTime>

<sourceCreatedDateTime>DateTime</sourceCreatedDateTime>

<sourceDueDateTime>DateTime</sourceDueDateTime>

<sourceProcessType>String(64)</sourceProcessType>

<sourceProcessSubtype>String(64)</sourceProcessSubtype>

<sourceTenant>String(64)</sourceTenant>

<requestedAgent>String(64)</requestedAgent>

<requestedSkill>String(64)</requestedSkill>

<requestedAgentGroup>String(64)</requestedAgentGroup>

<requestedPlaceGroup>String(64)</requestedPlaceGroup>

</Ext>

<Data>

<customAttribute1> String(255)</customAttribute1>

...

</Data>

Attributes: See Table 54

Table 54: Attributes for TaskInfo Messages

Attribute

tenantId solutionId

Description

The task’s tenant ID, as configured in iWD Manager, assigned as soon as the task is created. This attribute is submitted to the CIM

Platform with the

IWD_tenantId

key; updates in the CIM Platform are ignored.

The tasks’s solution instance ID, as configured in iWD Manager, assigned as soon as the task is created. This attribute is submitted to the CIM Platform with the

IWD_solutionId

key (even if it is excluded by a filter); updates in the CIM Platform are ignored.

232 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

Table 54: Attributes for TaskInfo Messages (Continued)

Attribute

DepartmentId processId channel category status businessCalendarId createdDateTime

Description

The tasks’s department ID, as configured in iWD Manager, assigned when the task’s process is identified either by iWD rules or explicitly by the task-originating system. This attribute is submitted to the CIM

Platform with the

IWD_DepartmentId

key; updates in the CIM

Platform are ignored.

The tasks’s process ID, as configured in iWD Manager, assigned when the task’s process is identified either by iWD rules or explicitly by the task-originating system. This attribute is submitted to the CIM

Platform with the

IWD_processId

key; updates in the CIM Platform are ignored.

The task’s media channel—for example Fax, E-mail, or Webform.

This attribute is submitted to the CIM Platform with the

IWD_channel key; updates in the CIM Platform are picked up.

The task’s category—for example

Followup

. This attribute is submitted to the CIM Platform with the

IWD_category

key; updates in the CIM Platform are picked up.

Task status:

New

—The task has just been created and will be processed.

Captured

—The task was processed, but it has not been prioritized.

Queued

—The task was processed and prioritized at least once.

Assigned

—The task is assigned to an agent.

Completed

—The task is completed.

Held

—The task is held and will not be reprioritized or distributed until it is resumed.

Error

—An error has occurred during task processing, prioritization, or distribution. Error details are stored in the custom extended task attribute

Error

. The task can be restarted, and iWD will attempt to process the task again.

Canceled

—The task is canceled.

Rejected

—The task was rejected during processing. This can occur when the task is assigned to an expired department or process.

The ID of the business calendar that is assigned to the task, as configured in iWD Manager.

Note: Maximum length is 16 characters

The date/time when the task has been created in iWD. This attribute is submitted to the CIM Platform with the

ReceivedAt

key; updates in the CIM Platform are ignored.

Deployment Guide 233

Appendix A: iWD Messages Messages

Table 54: Attributes for TaskInfo Messages (Continued)

Attribute

heldDateTime assignedDateTime completedDateTime activationDateTime dueDateTime expirationDateTime priority reprioritizeDateTime businessValue assignedToUser

Queue

QueueType

Description

The date/time when the task has been held (set only when task status is either

Held

Error

The date/time when the task has been assigned.

The date/time when the task has been completed.

The date and time when the task becomes active; before that, it will stay queued and will not be reprioritized and distributed. If this is not set, the task becomes active instantly.

The date and time by which the task should be completed, according to the service-level agreement (SLA). This attribute is submitted to the CIM Platform with the

IWD_dueDateTime

key; updates within the

CIM Platform are picked up.

The date and time when the task expires and will be archived. Only tasks that have been

Canceled, Completed,

Rejected

are archived.

The task priority, which is an integer value that is used to order tasks.

The higher the value, the higher the task will stand in the queue and the sooner it will be routed. This attribute is submitted to the CIM

Platform with the

Priority

key; updates in the CIM Platform are picked up.

The date/time when the task should be reprioritized; if this is set to null

, no more reprioritization will be done. This value is normally updated during prioritization, based on rule expressions, such as

“Reprioritize in 5 minutes”.

The business value of the task. This attribute is submitted to the CIM

Platform with the

IWD_businessValue

key; updates in the CIM

Platform are picked up.

The user ID to which a task is assigned, as supplied by the CIM

Platform.

The distribution’s queue name.

The type of distribution queue:

InteractionQueue

AgentWorkbin

AgentGroupWorkbin

PlaceWorkbin

PlaceGroupWorkbin

234 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

Table 54: Attributes for TaskInfo Messages (Continued)

Attribute

QueueTarget customerId distributionPointId customerSegment productType productSubtype resultCode sourceFirstCreatedDateTime sourceCreatedDateTime sourceDueDateTime sourceProcessType

Description

The queue target—for example,

Agent ID

, if the queue type is

AgentWorkbin

The customer’s ID. This attribute is submitted to the CIM Platform with the

IWD_ext_customerId

key; updates in the CIM Platform are picked up.

This attribute is provided for backward compatibility.

The customer’s segment or value. This attribute is submitted to the

CIM Platform with the

IWD_ext_customerSegment

key; updates in the CIM Platform are picked up.

The related product—for example, DSL. This attribute is submitted to the CIM Platform with the

IWD_ext_productType

key; updates in the CIM Platform are picked up.

The subtype of the related product—for example, PremiumDSL.

This attribute is submitted to the CIM Platform with the

IWD_ext_productSubtype

key; updates in the CIM Platform are picked up.

The task result code/outcome; typically, set by an agent in a softphone or another client application. This attribute is submitted to the CIM Platform with the

IWD_ext_resultCode

key; updates in the

CIM Platform are picked up.

The earliest timestamp of the task in the enterprise; it is applicable if there is another system, such as a fax server, that is used before the task originating system. This attribute is submitted to the CIM

Platform with the

IWD_ext_sourceFirstCreatedDateTimeTime

key; updates in the CIM Platform are ignored.

The task-creation timestamp in the task-originating system. This attribute is submitted to the CIM Platform with the

IWD_ext_sourceCreatedDateTime

key; updates in the CIM Platform are ignored.

The task-due timestamp in the task-originating system. This attribute is submitted to the CIM Platform with the

IWD_ext_sourceDueDateTime

key; updates in the CIM Platform are ignored.

A related process in the task-originating system—for example:

Order. This attribute is submitted to the CIM Platform with the

IWD_ext_sourceProcessType

key; updates in the CIM Platform are ignored.

Deployment Guide 235

Appendix A: iWD Messages Messages

Table 54: Attributes for TaskInfo Messages (Continued)

Attribute

sourceProcessTypeSubtype sourceTenant requestedAgent requestedSkill data

Description

The subtype of the related process in the task-originating system.

This attribute is submitted to the CIM Platform with the

IWD_ext_sourceProcessSubtype

key; updates in the CIM Platform are ignored.

The tenant ID or name in the task-originating system. This attribute is submitted to the CIM Platform with the

IWD_ext_sourceTenant key; updates in the CIM Platform are ignored.

The agent requested for the task.

The skill requested for the task.

Custom task attributes. These attributes can be used to associate additional task originating system-specific data to the task that can be used in iWD rules, routing, and historical reporting.

UpdateTask

Direction: In

Description: Updates the attributes of the task that has the given task's capture

ID or interaction ID. This results in the interaction properties of the task being updated through the Genesys Interaction Server.

All attributes except for CaptureId and BrokerId are optional. If the attribute is not provided, it will not be updated.

Format:

Standard notification attributes, as documented in “Task Action” on page 226

<category>String(32)</category>

<activationDateTime>DateTime</activationDateTime>

<dueDateTime> DateTime </dueDateTime>

<expirationDateTime> DateTime </expirationDateTime>

<businessValue>Integer</businessValue>

<priority>Integer</priority>

<ext>

<customerID>String(64)</customerID>

<customerSegment> String(64)</customerSegment>

<productType> String(64)</productType>

<productSubtype> String(64)</productSubtype>

<resultCode> String(64)</resultCode>

<sourceFirstCreatedDateTime>DateTime</sourceFirstCreatedDateTime>

<sourceCreatedDateTime>DateTime</sourceCreatedDateTime>

<sourceDueDateTime>DateTime</sourceDueDateTime>

236 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

<sourceProcessType> String(64)</sourceProcessType>

<sourceProcessSubtype> String(64)</sourceProcessSubtype>

<sourceTenant> String(64)</sourceTenant>

</ext>

<data>

<customAttribute1> String(255)</customAttribute1>

...

</data>

</UpdateTask>

</GTLMessages>

Attributes:

See “Task Action” on page 226

Response message: “TaskUpdated”

for a description of the attributes.

Note:

If you use UpdateTask to update a task’s priority, in order for that updated priority to be taken into account in your routing strategy you may want to use the URS function setUpdateTrigger

. By using this

URS function, if the

Priority

attribute of a task is updated—even while the task is in a Target block of a routing strategy waiting to be routed to an agent—the internal queue in URS will take this new priority into account. For more information about this function, refer to the Universal Routing 8.0 Reference Manual.

The setUpdateTrigger

function was introduced in URS 8.0.1.

TaskUpdated

Direction: Out

Description: The

TaskUpdated

message is submitted as a response to the

UpdateTask

message (see “UpdateTask” on page 236 ), as well as when the task

is updated either via the iWD Manager or within the CIM Platform.

Format:

Standard notification attributes, as documented in“Task Notification” on page 227

<tenantId>String(16)</tenantId>

<solutionId> String(16)</solutionId>

<DepartmentId> String(16)</DepartmentId>

<processId> String(16)</processId>

<channel>String(32)</channel>

<mediaType> String(32) </mediaType>

<category> String(32)</category>

<status> String(16)</status>

<businessCalendarId> String(16)</businessCalendarId>

<createdDateTime>DateTime</createdDateTime>

<heldDateTime>DateTime</heldDateTime>

<assignedDateTime>DateTime</assignedDateTime>

<completedDateTime>DateTime</completedDateTime>

Deployment Guide 237

Appendix A: iWD Messages Messages

<activationDateTime>DateTime</activationDateTime>

<dueDateTime>DateTime</dueDateTime>

<expirationDateTime>DateTime</expirationDateTime>

<priority>Integer</priority>

<reprioritizeDateTime>DateTime</reprioritizeDateTime>

<businessValue>Integer</businessValue>

<assignedToUser>String(64)</assignedToUser>

<ext>

<customerID>String(64)</customerID>

<customerSegment> String(64)</customerSegment>

<productType> String(64)</productType>

<productSubtype> String(64)</productSubtype>

<resultCode> String(64)</resultCode>

<sourceFirstCreatedDateTime>DateTime</sourceFirstCreatedDateTime>

<sourceCreatedDateTime>DateTime</sourceCreatedDateTime>

<sourceDueDateTime>DateTime</sourceDueDateTime>

<sourceProcessType> String(64)</sourceProcessType>

<sourceProcessSubtype> String(64)</sourceProcessSubtype>

<sourceTenant> String(64)</sourceTenant>

</ext>

<data>

<customAttribute1> String(255)</customAttribute1>

...

</data>

<actor>String(255)</actor>

Attributes: See “Task Action” on page 226

Standard notification attributes, as documented in “Task Notification” on page 227 .

for a description of the attributes.

TaskDistributedQueue

Direction: Out

Description: The

TaskDistributedQueue

message is submitted when the task is moved by the CIM Platform into any interaction queue or workbin, other than

Interaction Server's predefined queues and workbins reserved for iWD.

Format:

<Queue>String(255)</Queue>

<QueueType>String(16)</QueueType>

<QueueTarget>String(255)</QueueTarget>

</TaskDistributedQueue>

</GTLMessages>

Attributes: See “Task Notification” on page 227

Standard notification attributes, as documented in “Task Notification” on page 227

for a description of the attributes.

238 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

TaskAssigned

Direction: Out

Description: The TaskAssigned message is submitted when the task is assigned to an agent.

Format:

<AssignedToUser>String(64)</AssignedToUser>

</TaskAssigned>

</GTLMessages>

Attributes: See “Task Notification” on page 227

Standard action attributes, as documented in“Task Action” on page 226

for a description of the attributes.

CompleteTask

Direction: In

Description: Completes the task that has a given capture ID or interaction ID.

Format:

</CompleteTask>

</GTLMessages>

Attributes: See “Task Action” on page 226 for a description of the attributes.

Error codes: See Table 55 .

“TaskCompleted”

Table 55: Error Codes for CompleteTask Messages

Error code

CANNOT_COMPLETE_TASK

Description

Cannot complete the task, because it is already completed or assigned.

TaskCompleted

Direction: Out

Description: The

TaskCompleted

message is submitted as a response to the

CompleteTask

message (see “CompleteTask” on page 239 ), as well as when the

task is placed into the predefined

CompletedQueue

interaction queue in

Interaction Server.

Format:

Deployment Guide 239

Appendix A: iWD Messages Messages

Standard notification attributes, as documented in “Task Notification” on page 227

</TaskCompleted>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

HoldTask

Direction: In

Description: Holds the task that has given task’s capture ID or interaction ID.

As soon as it is held, the task will not be reprioritized or, potentially, assigned

until it is resumed (see “ResumeTask” on page 241 ).

Only tasks that are not held, assigned, completed, canceled, or rejected can be held.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

</HoldTask>

</GTLMessages>

Attributes: See “Task Action” on page 226 for a description of the attributes.

Response message: “TaskHeld”

Error codes: See Table 56 .

Table 56: Error Codes for HoldTask Messages

Error code Description

CANNOT_HOLD_

ASSIGNED_TASK

Cannot hold the task because it is assigned, completed, canceled, rejected, or already held.

TaskHeld

Direction: Out

Description: The

TaskHeld

message is submitted as a response to the

HoldTask

message (see “HoldTask” on page 240

), as well as when the task is held from the iWD Manager.

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskHeld>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

240 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

TaskErrorHeld

Direction: Out

Description: The TaskErrorHeld message is submitted when the task gets held because of a configuration error (such as incomplete rules).

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

<Error>String(255)</Error>

</TaskErrorHeld>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

ResumeTask

Direction: In

Description: Resumes the held task that has the given task's capture ID or interaction ID.

As soon as it is resumed, the task will be processed and assigned normally, according to the iWD rules.

Only tasks that are held can be resumed.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

</ResumeTask>

</GTLMessages>

Attributes: See “Task Action” on page 226 for a description of the attributes.

Response message: “TaskResumed” .

Error codes: See Table 57 .

Table 57: Error Codes for ResumeTask Messages

Error code

CANNOT_RESUME_TASK

Description

Cannot resume the task, because it is not held.

TaskResumed

Direction: Out

Description: The

TaskResumed

message is submitted as a response to the

ResumeTask

message (see “ResumeTask” on page 241 ), as well as when a task

is held from iWD Manager.

Deployment Guide 241

Appendix A: iWD Messages Messages

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskResumed>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

RestartTask

Direction: In

Description: Restarts the task that has the given task’s capture ID or interaction ID.

As soon as it is restarted, the task will be reclassified and reprioritized.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

</RestartTask>

</GTLMessages>

Attributes: See “Task Action” on page 226 for a description of the attributes.

Error codes: See Table 58 .

“TaskRestarted” .

Table 58: Error Codes for RestartTask Messages

Error code

CANNOT_RESTART_TASK

Description

Cannot restart the task, because it is held or assigned.

TaskRestarted

Direction: Out

Description: The

TaskRestarted

message is submitted as a response to the

RestartTask

message (see

“RestartTask”

, above), as well as when the task is either restarted from the iWD Manager or moved to the predefined

New interaction queue within the CIM Platform.

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskRestarted>

</GTLMessages>

242 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Messages

Attributes: See “Task Notification” on page 227

for a description of the attributes.

CancelTask

Direction: In

Description: Cancels the task that has the given task’s capture ID or interaction ID.

As soon as it is canceled, the interaction is moved to the iWD_Canceled

queue.

Tasks that have already been canceled cannot be canceled again. All other tasks can be canceled.

Format:

Standard action attributes, as documented in “Task Action” on page 226 .

</CancelTask>

</GTLMessages>

Attributes: See “Task Action” on page 226 for a description of the attributes.

Error codes: See Table 59 .

“TaskCanceled” .

Table 59: Error Codes for CancelTask Messages

Error code

CANNOT_CANCEL_TASK

Description

Tasks that have already been canceled cannot be canceled again, and tasks that have been assigned cannot be canceled. All other tasks can be canceled.

TaskCanceled

Direction: Out

Description: The

TaskCanceled

message is submitted as a response to the

CancelTask

message (see “CancelTask” ), as well as when the task is canceled

from iWD Manager.

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskCanceled>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

Deployment Guide 243

Appendix A: iWD Messages Messages

TaskRejected

Direction: Out

Description: The TaskRejected message is submitted when the task gets rejected by the iWD Classification Service. The task can be rejected when a process or department to which the task gets assigned is currently inactive (that is, either expired or not yet active).

Format:

Standard notification attributes, as documented in “Task Notification” on page 227 .

</TaskRejected>

</GTLMessages>

Attributes: See “Task Notification” on page 227

for a description of the attributes.

Ping

Direction: In

Description: A simple

Ping

message that can be used to check the health of the Capture Point. The message includes an optional ID, which will be present in the corresponding

Pong

message.

Format:

</GTLMessages>

message (see “Ping” on page 244

“Pong” .

Pong

Direction: Out

Description: Submitted as a response to the

Ping

), indicating that the Capture Point service is active. The

Pong message contains the ID that was sent in the

Ping

message.

Format:

</GTLMessages>

244 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Task Attributes and Interaction Properties

Task Attributes and Interaction Properties

iWD task attributes are separated into three categories:

•

Core

•

Extended

•

Custom

Most of the iWD task attributes can be set when a task is created or updated through an iWD capture adapter, although some, such as interaction ID, are set by iWD components or by Interaction Server. Most of the task attributes are displayed in the

Attributes

tab when a task is selected in the Global Task List.

These attributes are maintained as pieces of attached data of the interaction, as it is stored in the Interaction Server’s interactions database table. Some of the attributes are stored in independent columns in that database table, while others are stored in a binary (BLOB) format in a column in the interactions table called flexible_properties

There are many reasons to update or access the data stored in the iWD task attributes, including:

•

Setting the value of one or more task attributes as part of an iWD message such as CreateTask , when working with an iWD capture adapter.

•

Reading or updating task attributes in business rules.

•

Using the data in the

Condition

Order

, and

Segmentation

tabs of Views in

Genesys Business Processes.

Note:

You cannot use properties with a

Timestamp

data type on the

Segmentation tab.

•

Reading or updating the data contained in task attributes within a routing strategy.

•

Making the data available to an agent or knowledge worker desktop application, either to display to the agent or to facilitate a screen pop.

•

Filtering the display of the Global Task List.

Note:

There are specific columns in the interactions

table that you should

not change. Please refer to Chapter 8, “Interaction Properties”, in the

eServices 8.0 User’s Guide.

Table 60

provides information about how the iWD task attributes map to the columns in which their values are stored in the interactions database table, as well as the key name that is used in the attached data of the interaction, and the label used for that attribute as it appears on the

Attributes

tab of the Global

Task List.

Deployment Guide 245

Appendix A: iWD Messages Task Attributes and Interaction Properties

Refer to the beginning of this Appendix for details about how these task attributes are used in iWD messages such as

CreateTask.

Table 60: Task Attribute Mapping

Task Attribute Column Name in

Interactions Table

Type Interaction

Attached Data

Key

Label in Global

Task List

Core Attributes

BrokerId

Status a

Id queue

String

String mediaType

TenantId media_type

IWD_tenantId

String

String businessCalendarId in <flexible_properties> String

InteractionId

Queue

MediaType

IWD_tenantId

IWD_business

CalendarId

Status

Media Type

Tenant

Business Calendar

DepartmentId

ProcessId

Channel

Interaction Custom Properties

If you want to use the value of a task attribute in the

Condition

Order

, and

Segmentation

tabs of Views in Genesys Business Processes, or if you want to filter or sort the display of the Global Task List by using a task attribute, that task attribute must be represented in an independent column in the Interaction

Server’s interactions

database table. If that task attribute is inside the binary data in the flexible_properties

column, you must create an Interaction

248 intelligent Workload Distribution 8.0

Appendix A: iWD Messages Task Attributes and Interaction Properties

Custom Property that corresponds to that attribute. The data type of the property can be a timestamp, string, or number.

Note:

Properties with the Timestamp data type cannot be used on the

Segmentation

tab of Views in a Genesys Business Process.

Procedure:

Configuring a custom interaction property

Start of procedure

1. Decide on an attached data key that will be the source of the content of the custom property.

2. Create a new field directly in the interactions database.

3. Create a new Business Attribute:



Name = InteractionCustomProperties

Display name =

Interaction Custom Properties

Type =

Custom

If such an attribute already exists go to the next step.

4. Expand

Interaction Custom Properties and open its

Attribute values.

5. Give it an

Attribute Value

, with a name exactly matching the attached data key name that you decided on in Step 1. The matching is case sensitive (you can create a separate display name).

6. In your new attribute value, go to the

Annex tab and create a section called translation.

7. In the new

translation section, create an option called

translate-to, with its value duplicating the name of the new field you created in

Step 2 .

End of procedure

Note:

If you specify a custom field as not null, you must ensure that you provide some data to that field upon creation of a task. If no data is provided, the request will fail because Interaction Server sends NULL for empty fields, and that will be rejected by the DBMS.

Deployment Guide 249

Appendix A: iWD Messages Task Attributes and Interaction Properties

250 intelligent Workload Distribution 8.0

Appendix

iWD Business Process

(IWDBP)

This Appendix describes the default iWD business process (

IWDBP

) that is supplied in the iWD Setup Utility component.

•

The Universal Routing 8.0 Deployment Guide describes how to have the

Interaction Design shortcut bar appear in IRD, if it has not appeared automatically.

•

The Universal Routing 8.0 Business Process User’s Guide provides an in-depth discussion of business processes.

•

The Universal Routing 8.0 Interaction Routing Designer Help describes how to create, save, import and export a business process, and how to load the strategies that comprise the business process.

Note:

When Interaction Routing Designer (IRD) starts up, it checks for an eServices solution installed by the eServices Configuration Wizard. If none is found, the IRD main window does not contain an

Interaction

Design

shortcut bar. You cannot navigate to the

Business Processes list pane or open the Interaction Design window. To change the default, use the

Views

tab in

Routing Design Options

, which opens from the

Tools

menu. Clear the default

check box and click



This Appendix contains the following sections:

Configuration of List Objects, page 252

iWD Business Process, page 253

Modifying the iWD Business Process, page 272

Deployment Guide 251

Appendix B: iWD Business Process (IWDBP) Configuration of List Objects

Configuration of List Objects

One Business Process can serve several solutions under the same tenant. At least one ESP service server has to be configured per solution (see

“Configuring Multiple Business Context Management Services” on page 221

for information about using Application Clusters). Capture Points add Solution

ID to an interaction automatically. Inside of the business process, an ESP service is invoked. In order to specify which ESP service is invoked, the correlation between an iWD solution and an ESP service is set up inside of a

List Object.

The iWD Setup Utility creates an empty List Object called Iwd_Esp_List . In environments with only one solution, no further configuration needs to be done on the List Object. If you have multiple solutions (or add one at a later time) the

Iwd_Esp_List

List Object needs to be updated.

Notes:

If you run the iWD Setup Utility more than once, the new Business

Context Management Service(s) will be added to the existing

Iwd_Esp_List

List Object.

Refer to

page 221 for information about configuring multiple

Business Context Management Services.

The List Object looks like a list of pairs:

Solution_1 ESPService_1

Solution_2 ESPService_2

Solution_i ESPService_i

Where the Solution ID is the key, and the name of the Business Context

Management Service

Application

is the value.

Note:

It is very important that the pairs are set up correctly. If, for example,

Solution_1 is mapped to ESPService_2 instead of to ESPService_1, business rules for Solution_2 will be applied to all interactions which were submitted by Capture Points from Solution_1.

252 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

These key-value pairs in a List Object need to be set up only once per tenant, and can be configured in Interaction Routing Designer (IRD). See

Figure 71

Figure 71: List Objects in IRD

Figure 72

shows the details of the List Object.

Figure 72: List Object Details

iWD Business Process

The iWD business process (

IWDBP

) contains the following strategies:

• Classification

• Prioritization

Deployment Guide 253

Appendix B: iWD Business Process (IWDBP) iWD Business Process

• Distribution

• Archive

The iWD business process contains the following subroutine:

• DetermineESPServerName

The iWD business process contains the following queues:

• iWD_New

• iWD_Captured

• iWD_Queued

• iWD_Canceled

• iWD_Rejected

• iWD_Completed

• iWD_ErrorHeld

The Interaction Queues that are included in the out of the box

IWDBP

business process must be present, and the names should not be changed. The Global

Task List looks for specific Interaction Queue names, as they appear in the business process (such as iWD_New and

iWD_Queued

). If you modify the business process to add additional queues or rename existing queues, the interactions will not display properly in the Global Task List. No status will be displayed for interactions in Interaction Queues with names that the Global Task List does not recognize.

Figure 73

shows the entire business process as it appears in the

Interaction

Design

window of Interaction Routing Designer.

Figure 73: iWD Business Process

The group of objects on the left-hand side are part of the “Main Flow” of the business process.

Figure 74

shows this section in more detail. The group of

254 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process objects on the right-hand side represent the “Archiving” section of the business process.

Figure 75

shows the Archiving section in more detail.

Figure 74: iWD Business Process—Main Flow

Deployment Guide 255

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Figure 75: iWD Business Process—Archiving

Classification Strategy

The purpose of this strategy is to invoke corresponding classification rules, analyze the result of the rules application and place the interaction into the appropriate queue, depending on the result.

This strategy processes interactions from the following queues:

• iWD_New



Interactions have to satisfy the following conditions (see Figure 76 ):

There are no conditions here.

Interactions are taken in order they were submitted.

256

Figure 76: The ‘All’ Interaction Queue View Properties

Note:

ESP stands for External Service Protocol. In this document it is the

Business Context Management Service.

intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP)

Figure 77

shows the

Classification

strategy.

iWD Business Process

Figure 77: Classification Strategy

Summary of flow

Note:

The IRD objects described in this section are keyed to the numbers in

Figure 77

1. Variables are initialized (see

Figure 78



_counter

is the running counter for the numbers of attempts to invoke the ESP service.

Deployment Guide 257

Appendix B: iWD Business Process (IWDBP) iWD Business Process



_max_repeate_counter

specifies how many times to attempt to invoke the ESP service

_delay

specifies the delay (in milliseconds) between attempts to invoke rules.

Figure 78: Initialize Variables

2. A command is sent to URS to use interaction age while sorting interactions in internal queues.

3. The subroutine that determines the correct ESP server name is invoked.

This subroutine also sets up cases when there is reason to retry to invoke the ESP server.

4. If the subroutine fails an error is extracted.

5. This error is attached to user data as a key-value pair with the key

IWD_ESP_Determination_Error

6. A request to apply classification rules to the interaction is sent.

7. If ESP server reports that operation was completed successfully, the results are attached to user data as a key-value pair with the key ESP_Result . This key-value pair will have the following format: return:ok| NumberOfRulesApplied:<number of applied rules>|RulesApplied:<rule 1 id> <rule1 name>, <rule2 id> <rule2 name>, ...

Here is an example of what the result might look like:

AttributeUserData [list, size (unpacked)=168] =

‘ESP_Result’ [str] =

“return:ok|NumberOfRulesApplied:12|RulesApplied:McrSlt1GlbClsf1

McrSlt1GlbClassification1, McrSlt1GlbClsf2

McrSlt1GlbClassification2”

8. Verification is done to check if a business process was assigned by a classification rule.

9. If a business process was assigned, then the interaction is placed in the iWD_Captured queue.

258 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

10. If a business process was not assigned in

Step 8

, then the interaction is placed in the iWD_ErrorHeld

queue.

11. If rules could not be applied, the reason is provided.

12. The reason is analyzed, and a decision is made whether another attempt should be made to apply the rules.

13. The last error is attached to user data as a key-value pair with the key

ESP_Error

. The following is an example of what the result could look like:

AttributeUserData [list, size (unpacked)=143] = ‘ESP_Error’ [str] =

“605 Department 'McrSlt1_D1' has expired on 2010-08-15T00:00:00”

14. The last error is analyzed. If error is between 604 and 607, that means the

Department/Process is not active yet.

15. If the department or process is not active yet, the interaction is placed in the iWD_Rejected

queue.

16. For all other errors, the interaction is placed in the iWD_ErrorHeld

queue.

17. A check is done to see if the maximum number of attempts (see Step 1

) has been reached.

18. If the maximum number of attempts has been reached, the most recent error is attached to the interaction and the interaction is placed in the iWD_ErrorHeld

queue.

19. If the maximum number of attempts has not been reached, the counter is increased by 1.

20. The interaction is delayed for the amount of milliseconds specified in

_delay

(see

Step 1

) before another attempt is made to apply the rules.

Prioritization Strategy

The purpose of this strategy is to invoke the corresponding prioritization rules, analyze the result of the rules application and place the interaction into the appropriate queue, depending on the result.

This strategy processes interactions from the following queues:

• iWD_Captured



Interactions have to satisfy following conditions (see

Figure 79

Active interactions only, (interactions which do not have the property

IWD_activationDateTime set, or this property has a time stamp which is in the past.

Interactions are taken in the order they were submitted.

Deployment Guide 259

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Figure 79: The ‘Active interactions only’ Interaction Queue View Properties

• iWD_Queued



Interactions have to satisfy the following conditions (see Figure 80 ):

Interactions that are subject for immediate reprioritization (interactions that have the property IWD_reprioritizeDateTime set, and this property has a time stamp which is in the past)

Interactions are taken in order of

IWD_reprioritizationDateTime

(oldest first).

Figure 80: The ‘To reprioritize’ Interaction Queue View Properties

Figure 81

shows the

Prioritization

strategy.

260 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Figure 81: Prioritization Strategy

Summary of Flow

Note:

The IRD objects described in this section are keyed to the numbers in

Figure 81

1. Variables are initialized:

•

source_queue

is the queue from which the interactions came. It will be used to determine if the prioritization service is being requested for initial prioritization or reprioritization.

•

BCMS_error_timeout_ms

specifies the delay (in milliseconds) between attempts to invoke rules.

•

_default_priority specifies the priority which will be assigned if a priority is not specified by the customer (as part of the task capture) or by rules.

Deployment Guide 261

Appendix B: iWD Business Process (IWDBP) iWD Business Process

2. The subroutine that determines the correct ESP server name is invoked.

This subroutine also sets up cases when there is reason to retry to invoke the ESP server.

3. If the subroutine fails an error is extracted.

4. This error is attached to user data as a key-value pair with the key

IWD_ESP_Determination_Error

5. The User Data key-value pairs

ESP_Result

and

ESP_Error

are set to an empty string.

6. A request to apply prioritization rules to the interaction is sent.

7. If the ESP server reports that the operation was completed successfully, the result is attached to user data as a key-value pair with the key

ESP_Result

This key-value pair will have following format:

“return:ok| NumberOfRulesApplied:<number of applied rules>|RulesApplied:<rule 1 id> <rule1 name>, <rule2 id> <rule2 name>, “

The following is an example of what the result could look like:

AttributeUserData [list, size (unpacked)=168] =

'ESP_Result' [str] =

“return:ok|NumberOfRulesApplied:2|RulesApplied:McrSlt1GlbPrior1

McrSlt1GlbPrioritization1, McrSlt1GlbClsf2

McrSlt1GlbPrioritization2”

8. A check is made as to whether it is the initial prioritization, and whether the priority was set.

9. If the request to apply prioritization rules is for reprioritization, or if the priority was set to a value (other than the default value set by the BCMS service, which is

), than the interaction is placed in the iWD_Queued queue.

10. If the request to apply prioritization rules is for initial prioritization, and priority was not set in rules, then the following error message is attached:

Priority is not set up by rules.

11. The interaction is placed in the iWD_ErrorHeld

queue.

12. If rules could not be applied, the reason is provided.

13. The most recent error is attached to user data as a key-value pair with the key

ESP_Error

. The following is an example of what the result will look like if prioritization rules were not configured: attr_changed_prop [list, size (unpacked)=65] = 'ESP_Result' [str] =

“return:ok|NumberOfRulesApplied:0|RulesApplied:”

14. The interaction is delayed for the amount of milliseconds specified in

_BCMS_error_timeout_ms

(see Step 1

) before another attempt is made to apply the rules.

262 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Distribution Strategy

This simple strategy routes interactions to a requested Agent, requested Agent

Group, requested Skill, or to the default iWD Agent Group.

This strategy processes interactions from the following queues:

• iWD_Queued



Interactions have to satisfy the following conditions (see Figure 82 ):

Interactions that are not subject for immediate reprioritization

(interactions that do not have the property IWD_reprioritizeDateTime set, or that have this property set to a time stamp that is in the future).

Interactions are taken in order of priority (highest priority first)

Figure 82: The ‘To distribute’ Interaction Queue View Properties

Figure 83

shows the

Distribution

strategy.

Deployment Guide 263

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Figure 83: Distribution Strategy

264 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Summary of Flow

Note:

The IRD objects described in this section are keyed to the numbers in

Figure 83

1. Extract information about requested agent and skill and initialize internal variables. See

Figure 84

Figure 84: Requested Agent and Skill

2. A calculation is done to determine the timeout—how long the interaction should wait for a target to become available.

3. If the reprioritize time was set up and the calculated timeout is less than or equal to the default timeout (

1 hour

, see Step 1 ), then the timeout remains

as it is.

4. If the reprioritize time was not set, or the calculated timeout is greater than the default timeout, then the waiting timeout is set to the default (

1 hour

5. Analysis is done to determine whether an agent was requested.

6. If an agent was requested, the URS variable is prepared ( .a is added).

Deployment Guide 265

Appendix B: iWD Business Process (IWDBP) iWD Business Process

7. Try to route the interaction to the requested agent without waiting (see

Figure 85

Figure 85: Route to Agent

8. Try to route the interaction to an agent with the requested skill without waiting (see

Figure 86

266

Figure 86: Route to Skill

9. Analysis is done to determine whether an Agent Group was requested.

10. If an Agent Group was requested, the URS variable is prepared (

.ga is added).

intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

11. Try to route the interaction to the requested Agent Group without waiting

(see

Figure 87

Figure 87: Route to Requested Agent Group

12. Try to route the interaction to the iWD agent group with a wait time of 60 seconds (see

Figure 88

Deployment Guide

Figure 88: Route to Agent Group

13. Get the last error.

14. Verification is done as to why the target was not found.

15. An error code is attached in case of any error other than a timeout.

If more than one target is available, URS uses the

StatAgentsLoading

statistic to select the Agent who has the minimum load (this applies to routing to Skills and routing to Groups only; routing to a requested Agent does not use statistics). For more information about this statistic, see the Universal Routing

8.0 Reference Manual.

267

Appendix B: iWD Business Process (IWDBP) iWD Business Process

The Route Interaction object also has an

Interaction Queue

tab. See

Figure 89

. (This applies to all three Route Interaction objects in this strategy.)

Figure 89: Route Interaction Properties—Interaction Queue



The optional

Interaction Queue

tab enables you to specify two types of queues:

Queues for existing interactions (the queue in which the interaction should be placed after the agent is done working with it).

Queues for new interactions (the queue in which new interactions created by the agent should be placed).

A Description (optional) appears as a hint on the agent desktop as to where to place the interaction.

Archive Strategy

The purpose of this strategy is to invoke the corresponding archiving rules, analyze the result of the rules application, and process the interaction accordingly. There are three archive destinations: delete the interaction, reschedule archiving for some time in the future, and archive the interaction to another Interaction Server database. A key-value pair in user data with the key

IWD_expirationDateTime contains information about when an interaction has to be archived.

This strategy processes interactions form following queues:

• iWD_Completed

• iWD_Canceled

• iWD_Rejected

268 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

Interactions have to satisfy the following conditions (see Figure 90 ):

•

Interactions that are not subject for archiving (interactions that do not have the property

IWD_expirationDateTime

set, or this property has a time stamp which is in the past).

•

Interactions are taken in the order they were submitted.

Figure 90: The ‘Expired only’ Interaction Queue View Properties

Figure 91

shows the

Summary of Flow

Note:

The IRD objects described in this section are keyed to the numbers in

Figure 91

1. Variables are initialized (see

Figure 92



_default_reschedule

is the default interval (in seconds) for archive rescheduling. The default value is

864000

(10 days). The default value will be used if archiving rules were not configured, a new archiving time was not configured, or in case of error.

_old_expiration_dt_str

is a string that is taken from the interaction before any archive rules are invoked.



_old_expiration_dt_int

is an integer that is taken from

_old_expiration_dt_str.

Figure 92: Archive Strategy—Initialize Variables

2. The subroutine that determines the correct ESP server name is invoked.

This subroutine also sets up cases when there is reason to retry to invoke

the ESP server. A retry mechanism is not included. See “Classification

Strategy” on page 256 for an example.

3. If the subroutine fails an error is extracted.

4. This error is attached to user data as a key-value pair with the key

IWD_ESP_Determination_Error

5. The User Data key-value pairs

ESP_Result

and

ESP_Error

are set to an empty string.

6. A request to apply archiving rules to the interaction is sent.

7. The ESP result is formed in the following format:

“return:ok| NumberOfRulesApplied:<number of applied rules>|RulesApplied:<rule1id> <rule1name>, <rule2id> <rule2name>,

...”

8. The result is attached to User Data as a key-value pair with the key

ESP_Result

270 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) iWD Business Process

9. The result of the rules application is analyzed. See

Figure 93

Figure 93: Result of Rules Application

10. Any archiving destination except those listed in Figure 93 will cause

processing of the interaction to stop. The interaction will also be deleted from the Interaction Server runtime database.

11. An exact copy of the interaction will be submitted to the Interaction Server that is specified in the

Application Name

field of the External Service block. See

Figure 94

Deployment Guide

Figure 94: Specify Interaction Server

271

Appendix B: iWD Business Process (IWDBP) Modifying the iWD Business Process

12. If the submission is a success, processing will be stopped on the interaction and the interaction will be deleted from the Interaction Server runtime database.

13. If the submission failed, the last error is retrieved.

14. The most recent error is attached to User Data as a key-value pair with the key

ESP_Error

15. If a new expiration timestamp exists, it is extracted.

16. Analysis is done to determine if a new expiration timestamp was set up.

17. If the new expiration timestamp is different from the old one, it means that archiving rules were configured and applied correctly. Therefore, the interaction is returned to the original queue for future archiving.

18. If there is no new expiration timestamp, a default timestamp is created. See

Figure 95

Figure 95: Default Timestamp is Created

19. The new expiration timestamp is attached to user data as a key-value pair with the key

IWD_expirationDateTime

20. The reason why the operation failed is received.

21. The most recent error is attached to user data as a key-value pair with the key

ESP_Error

. The following is an example of what the result could look like:

AttributeUserData [list, size (unpacked)=130] = 'ESP_Error' [str] =

“608 No archive destination set by archiving rules

Modifying the iWD Business Process

For most environments, the only modification that will need to be made to the iWD Business Process is to the

Distribution

strategy (see

page 263 ). The

recommended approach to do this is to add a new strategy into the iWD

Business Process, and replace the connection from

iWD_Queued/All

view to the

Distribution

routing strategy with a connection from iWD_Queued

to your own

272 intelligent Workload Distribution 8.0

Appendix B: iWD Business Process (IWDBP) Modifying the iWD Business Process routing strategy where distribution logic is described. Then, link your new distribution strategy to the out of the box iWD_Completed

queue.

By modifying the business process in this way, rather than simply updating the provided Distribution strategy, you can easily import any new versions of the iWD Business Process that might be available in the future (the links will have to be reestablished to your own distribution strategy).

Deployment Guide 273

Appendix B: iWD Business Process (IWDBP) Modifying the iWD Business Process

274 intelligent Workload Distribution 8.0

Appendix

Adapting the iWD Business

Process for Standard

Genesys Channels

This Appendix describes how to adapt the iWD Business Process (

IWDBP

) to work with standard Genesys non-voice channels, such as e-mail, chat, SMS,

Gplus Adapters, and custom integrations built with Open Media.



This Appendix contains the following sections:

Adapting IWDBP to Serve E-mail Interactions, page 275

Examples, page 281

Adapting IWDBP to Serve E-mail

Interactions

This section explains what should be done to adapt the iWD business process to serve e-mail interactions.

Adding Required Properties to Interactions

In order to keep Data Mart functionality intact and to make Genesys standard channel interactions visible in iWD Manager, some key-value pairs need to be added to the user data of these interactions. The interactions should only be placed into the input queue for the default iWD business process after these key-value pairs have been added.

The key-value pairs are:

•

IWD_tenantId

•

IWD_solutionId

Deployment Guide 275

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Adapting IWDBP to Serve E-mail

•

IWD_capturePointId

To make the process easier, the iWD Setup Utility includes an additional business process,

Standard Genesys to IWD adapter

(see Figure 96 ). This

business process attaches the required key-value pairs to an interaction and places it into the input queue of the default business process

IWDBP

Figure 96: Standard Genesys to iWD Adapter Business Process

Figure 97

shows the

Genesys to IWD

strategy.

Figure 97: Genesys to iWD Strategy

In the

Multi Assign

object, you have to initialize all variables, as shown in

Figure 98

Figure 98: Assign Variables

276 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Adapting IWDBP to Serve E-mail

The IDs are taken from iWD Manager. Figure 99 and Figure 100 show where

to find your Tenant ID and Solution ID, respectively.

Figure 99: Tenant ID

Figure 100:Solution ID

In order to get an ID for a capture point you have to create a “dummy” capture point. This will represent a Genesys standard server (in our example, E-mail server). Use the

Webservice Capture Point

template to create a simple

“dummy” capture point. The ID is the only property that is needed. It does not

matter what you enter for the rest of the properties. Figure 101

shows the iWD

Capture Point ID.

Deployment Guide 277

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Adapting IWDBP to Serve E-mail

Figure 101:iWD Capture Point ID

Adding E-mail Server

E-mail Server needs to be added to the

Standard Genesys to IWD Adapter business process. You can add E-Mail Server in two ways:

1. In Configuration Manager or Genesys Administrator, you can update the

E-Mail Server application options to specify iWD_Adapter_ext as an output queue. Add a section called endpoint:[YourTenantDBID].

In this section, add a new option default

. Set the value of default

to iWD_Adapter_ext

, as shown in

Figure 102 . Next, refresh in IRD and E-mail Server will be added

to the business process with the iWD_Adapter_ext queue.

Figure 102:Updating E-mail Server for Standard Genesys to IWD Adapter Business Process

2. The second way to add E-mail Server is to do so explicitly in IRD. Add

E-mail server from

Media Servers

to the

Standard Genesys to IWD Adapter business process and make a connection to the iWD_Adapter_ext queue. In this method, IRD will update the corresponding option and section in the

E-Mail Server application.

278 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Adapting IWDBP to Serve E-mail

Figure 103 shows how the

Standard Genesys to IWD Adapter

business process will look after these modifications.

Figure 103:Standard Genesys to iWD Adapter Business Process After

Modifications

Modify the Distribution Strategy

In IRD, open the IWDBP business process. Open the Distribution strategy.

Since there are business actions

Request Agent

and

Request Skill

, the default business process has to take this into consideration. This is why there are three objects of type

Route Interaction

If you have only one Stat Server listed in the Connections tab of Interaction

Server, you can skip this step. If not, for the object

Route interaction to

AgentGroup IWD

in the

Target Selection

tab, change the Genesys Stat Server application name and target according to your configuration. Also you can change how long URS has to wait for the next available agent (by default it is

set to 60 seconds). See Figure 104 .

Figure 104:Update Route Interaction to Agent Group IWD

Deployment Guide 279

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Adapting IWDBP to Serve E-mail

You might want to check all of the provided

Route Interaction

objects (by double-clicking on them) to see if they satisfy your business logic. Pay attention only to what statistics are used for

Skill

and

AgentGroup

routing.

Allowing Agents to Send Replies to Inbound E-mails

There are two ways to allow agents to send replies to inbound e-mails: create a new queue and a new strategy in the

IWDBP,

or use a business process that already exists. In this example an existing business process will be used to illustrate how other business processes can be used from the iWD business process.

First, choose a business process to handle agent’s replies and outbound e-mails. Second, specify the queue into which the agent’s reply will be placed.

Third, specify the business process and queue for single outbound e-mails from agents.

In this example the

ABC Simple

business process will process agent’s replies

(with the Outbound queue). Also, agents will be given the ability to place interactions into the iWD_Completed

queue. All of this will be done in the

Distribution strategy. The Route Interaction properties in the strategy must be

as shown in Figure 105

280 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 105:Route Interaction Object for Distribution Strategy

Examples

In these examples we assume that the default iWD Business Process (

IWDBP

) provides all necessary steps for e-mail processing—namely classification, prioritization, and distribution.

The purpose of these examples is to show what needs to be done in order to use

IWDBP

and standard iWD functionality (such as classification and prioritization rules) for e-mail processing.

Note:

The following examples are presented as guidelines. Some of the strategies and objects in the business processes might not be exactly as shown in the following examples.

Deployment Guide 281

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Requirements:

•

A Genesys E-mail solution is installed

•

An iWD solution is installed

Assumptions:

Only one iWD solution will be served by iWDBP

. The default iWD business process will process interactions with any media type (the interaction will pass through the business process and be delivered to an agent), but business rules created in these examples will be applicable to e-mails only. We have only one

Agent Group to which the interactions will be assigned.

For all examples, the main flow of IWDBP is as shown in

Figure 106

Figure 106: Main Flow of IWDBP

You can add E-Mail Server in two ways:

1. In Configuration Manager or Genesys Administrator, you can update the

E-Mail Server application options to specify iWD_New

as an output queue.

Add a section called endpoint:[YourTenantDBID].

In this section, add a new option default

. Set the value of default

to iWD_New

, as shown in

Figure 106 . Next, refresh in IRD and E-mail Server will be added to the

business process with the

iWD_New

queue.

282 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 107:Update E-Mail Server Options

2. The second way to add E-mail Server is to do so explicitly in IRD. Add

E-mail server from

Media Servers

to your business process and make a connection to the iWD_New

queue. In this method, IRD will update the corresponding option and section in the E-Mail Server application.

Example 1

This is a simple example of how business rules can be used. In this example, the default iWD business process will be used for processing Genesys e-mails.

Use Case

In this example, the following scenario/use case is used:

•

For all interactions with

MediaType = email

, the property

ServiceType

will be set to

ChangeAddress

•

The property priority

will be set to

100

for all e-mail interactions.

•

Interactions of any

MediaType

should be delivered to the Agent Group

IWD

(interactions with the highest priority have to be delivered first).

•

E-mail interactions have to be reprioritized every 2 hours.

•

After each reprioritization the priority have to be increased by 5.

Genesys

Configuration

Preparation of Components

To prepare the Genesys configuration:

•

Add Agents into the

IWD

Agent Group.

•

Set up a connection between Interaction Server and the External Service

Provider service. According to

IWDBP

, Interaction Server will send interactions to an iWD External Service Provider service (ESPService) to apply business rules. In order to do that, we have to “explain” to

Interaction Server where to find the ESPService. This is done by adding an

Application that represent the ESPService, to the

Connections

of the

Interaction Server application.

•

Set the proper outbound queue for E-mail Server. Interactions that are submitted by E-mail Server have to reach the iWD business process in some way. In order to do that we need to change the outbound queue for the E-mail Server application to iWD_New in the endpoints

section (refer to the first method of adding E-mail Server to the business process on

page 282

for details). Now your E-mail Server will submit interactions into the iWD_New

queue, which is the entry point for the default iWD business process.

Deployment Guide 283

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

iWD Configuration

To prepare the iWD configuration:

Note:

It is recommended to give meaningful names for iWD services and objects. The following format could be useful:

IWDBP

Preparation

•

person account.

•

Create a new iWD tenant. From the drop-down list choose the corresponding Genesys Tenant. It is recommended to give the new iWD tenant the same name as the Genesys tenant. In this example the iWD tenant name will be Mcr .

•

Under iWD tenant

Mcr

create a new solution and name it

McrSlt.

•

Under iWD tenant

Mcr

create a new Role under Security Policy and give some permissions.

•

Under the new solution create the following iWD configurations objects:

 iWD Runtime Node. For

Context URL

use the directory name iwd_node provided during installation (by default it should be http://localhost:8080/iwd_node/

). For the

Application

property, use the iWD Runtime Node application as configured in Configuration

Manager or Genesys Administrator.



 iWD Rules service iWD Logging service



 iWD Configuration Server Connector service iWD Interaction Server Connector service iWD Business Context Management service. For the

Application property, use the iWD Business Context Management Service application as configured in Configuration Manager or Genesys

Administrator.

To prepare the iWD business process:

•

In IRD open

IWDBP

. Open the

Distribution

strategy. Double-click on the

RouteInteraction

block. In the

Target Selection tab, change the Genesys

Stat Server application name and target according to your configuration.

You can also change how long URS has to wait for an available agent. By default it is set to 60 seconds. See

Figure 108 .

284 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 108:Preparing the iWD Business Process

Modify the

Standard Rules

Template

Create Rules

For simplicity, in this example conditions will be added to the Standard Rules

Template, which is used for all iWD tenants.

1. Under

Modules & Components

choose the

System

tenant, expand

Rule

Templates

and choose

Standard Rules Template

. Click the add icon

(labeled as 1 on

Figure 109 ).

2. In the

Language Expression

column, add a description for the condition

(see

Table 61

3. In the

Rule Language Mapping

column enter the corresponding text (see

Table 61

Deployment Guide 285

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels

4. Click

Save

Examples

Figure 109:Add a Condition to the Standard Rules Template

Add more Conditions. Enter the text according to

Table 61

Table 61: Conditions

Language Expression

If Reprioritization was not set up

If Reprioritization was set up and in the past

Rule Language Mapping

eval( isNull(“IWD_reprioritizeDateTime”, $data) );

Note: The Standard Rules Template contains a standard rule condition called “Is first prioritization” that does the same thing as “If

Reprioritization was not set up”, but “If

Reprioritization was not set up” is included in this example to give you another working example of how to achieve the same result in a business rule.

eval( notNull(“IWD_reprioritizeDateTime”, $data)

&& getDTValue(“IWD_reprioritizeDateTime”,

$data).before(getCurrentDT()) );

286 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Table 61: Conditions (Continued)

Language Expression

If KVPair “{k}” is “{v}”

If KVPair “{k}” is not “{v}”

Rule Language Mapping

eval( getStringValue(“{k}”, $data).equals(“{v}”) );

Note: The Standard Rules Template contains a standard rule condition called “String “{attribute}” equals “{stringValue}” that does the same thing as

If KVPair “{k}” is “{v}”. If KVPair “{k}” is “{v}” is included in this example to give you another working example of how to achieve the same result in business rules.

If KVPair “{k}” is not “{v}”eval( notNull(“{k}”,

$data) && !getStringValue(“{k}”,

$data).equals(“{v}”) );

To make this example as flexible as possible, add a universal action. This action will make it possible to add an key-value pair to user data. Click on the

Action tab, and add a new action. In the Language Expression column enter:

Attach Custom KVPair “{key}” “{value}

In the

Rule Language Mapping column enter: setStringValue(“{key}”, “{value}”, $data);

Note:

The Standard Rules Template contains a standard rule action that does the same thing as

Attach Custom KVPair

Set string “{attribute}” value “{stringValue}”. Attach Custom KVPair is used here as an example of how to configure an action.

Create a

Classification Rule

Create a classification rule. The numbers in the following steps are keyed to

Figure 110

. For simplicity Global Rules are used in this example, but these classification rules could also be created at the Capture Point level, if a Capture

Point ID was added to the interaction as described in “Adding Required

Properties to Interactions” on page 275

1. Select

Departments & Processes.

2. Select your iWD tenant.

3. Select

Global Rules.

4. Select

New Linear Rule.

5. Enter a name for the new rule.

6. Select classification

as the

Phase.

7. Click

Add condition

and select a condition.

8. The selected condition is added.

9. Select e-mail.

Deployment Guide 287

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels

10. Click

Add action.

11. Select Attach Custom KVPair.

12. Enter

ServiceType

and

ChangeAddress.

13. Also add

Set Priority 100.

14. For simplicity we will set up time for Reprioritization here.

15. Click Save .

Examples

Figure 110:Create a Classification Rule

Create a

Prioritization Rule

Create a prioritization rule. The numbers in the following steps are keyed to

Figure 111

. For simplicity, Global Rules are used in this example, but these prioritization rules could also be created at the Department or Process level. In this case, you would first need to add a rule back at the Global Rules or

Capture Point level with the rule action Assign iWD process , to assign the interaction to an iWD Process.

1. Select Departments & Processes.

2. Select your iWD tenant.

3. Select

Global Rules.

4. Select

New Linear Rule.

5. Enter a name for the new rule.

6. Select prioritization

as the

Phase.

7. Click

Add condition

and select a condition.

8. The selected condition is added.

288 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

9. Select e-mail.

10. Add one more condition.

11. Select

Add action

and select

Increase Priority

and

Reprioritize After

12. The selected actions are added.

13. Set values

2 hours

and

5 like in

Figure 111

14. Click Save .

Figure 111:Create a Prioritization Rule

Deploy

Modifications

After new rules are created or business objects are modified, the changes have to be deployed before they will have an affect on your business process. If there are undeployed changes in your environment, a notification will appear in the header bar in iWD Manager. See

Figure 112

. You can either click the

solution name (labeled as 1 in Figure 112 ) or you can click on Deploy under the solution in the navigation tree (labeled as 2 in Figure 112 ).

Deployment Guide 289

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 112:Deploy Changes

Notes on the iWD Business Process

The following are some important things to note about the iWD business process:

•

Behavior of the iWD_Queued

queue and

ActivatedOnly

view—if the interaction does not have a key-value pair with the key

IWD_activationDateTime

it will be processed immediately; otherwise the interaction will be delayed according to the time stamp in the key-value pair.

•

Behavior of iWD_Queued

queue and

ToReprioritize

view—interactions will only be taken through this view if they have a user data key-value pair with the key

IWD_reprioritizeDateTime

and only then if the time that is specified is in the past. This key-value pair is set up by a prioritization

business rule. See “Create a Prioritization Rule” on page 288 .

Path of E-mail Interactions in IWDBP

All business rules will only affect interactions with a

MediaType

equal to email

The following are the steps which the interaction will pass through:

•

The interaction is submitted by E-mail Server and is placed into the iWD_New

queue.

290 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

•

The interaction is processed by the

Classification strategy. As a result, the classification business rules will be applied to interaction. In this example,

ServiceType

will be set to

ChangeAddress

. Also, the initial

Priority

will be set to

100

and the initial

Reprioritization

time will be set to in 2 hours

•

The interaction is placed into the iWD_Captured

queue.

•

The interaction is processed by the

Prioritization

strategy. As a result, the prioritization business rules will be applied to interaction. In this example we have set the initial priority in classification rules, so prioritization rules will be used on the reprioritization step.

•

The interaction is placed into the iWD_Queued

queue.

•

In this example, if no available agents are found, the e-mail interaction will be reprioritized every 2 hours. Its priority will be increased by 5 each time.

Example 2—Departments and Processes

In this example more iWD business objects will be added. This example will show how one flow of interactions can be divided into three streams, and how different business rules can be applied to each stream. In this example the default iWD business process is used for processing Genesys e-mails.

Use Case

In this example the following scenario is used: all interactions with

MediaType

= email

should be divided into three groups based on

Subject

NewAccount,

Support,

and all others. All interactions will be delivered to one Agent Group

(

IWD

), but interactions with

Subject = NewAccount

will have highest priority and will be reprioritized more often. Interactions with

Subject = Support

will have lower priority and all other interactions will have the lowest priority and will be reprioritized less often.

Create a

Department and

Processes in iWD

Rules Creation

Create the Department and Processes in iWD. The following steps are keyed to

the numbers in Figure 113 .

1. Select Departments & Processes.

2. Select your iWD tenant.

3. Select

New Department.

4. Enter a name for the new department (in this example,

CustomerService

5. Click

Save.

Deployment Guide 291

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 113:Create Department

Create a new process under the new department. The following steps are keyed

to the numbers in Figure 114 .

1. Select

New Process.

2. Enter a name for the process (in this example, Sales ).

3. Click

Save

4. Create two more processes under the

CustomerService

department:

Support and

Others

292 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 114:Create Process

Create Global

Classification

Rules

Create new Global classification rules as shown in Figure 115 ,

Figure 116 , and

Figure 117

. Remember to save each rule.

Figure 115:Classification Rules for Example 2—Rule 1

Deployment Guide 293

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels

Figure 116:Classification Rules for Example 2—Rule 2

Examples

Figure 117:Classification Rules for Example 2—Rule 3

Create

Classification

Rules for each

Process

Create a new classification rule for each process (use

Figure 118

as an example).

For the

Sales

process:

Action

Set Priority 100

For the

Support

process:

Action Set Priority 50

For the

Others

process:

Action

Set Priority 10

294 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 118:Example Classification Rule for a Process

Create

Prioritization

Rules for the

Processes

Create prioritization rules for your processes. See

For the

Sales

process, create the rules outlined in

Table 62: Sales Process Prioritization Rules

Figure 119

Table 62 .

for an example.

Rule Name

McrSlt1Prior1Sales

McrSlt1Prior2Sales

Conditions

If Reprioritization was not set up

If Reprioritization was set up and in the past

Actions

Reprioritize after 1 hour

Increase priority 10

For the Support process, create the rules outlined in

Table 63

Table 63: Support Process Prioritization Rules

Rule Name Conditions

McrSlt1Prior1Support If Reprioritization was not set up

McrSlt1Prior2Support If Reprioritization was set up and in the past

Actions

Reprioritize after 2 hours

Increase priority 5

Deployment Guide 295

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

For the

Others

process, create the rules outlined in

Table 64

Table 64: Others Process Prioritization Rules

Rule Name

McrSlt1Prior1Others

McrSlt1Prior2Others

Conditions

If Reprioritization was not set up

If Reprioritization was set up and in the past

Actions

Reprioritize after 3 hours

Increase priority 1

For rules in this example order is not important, but order can be important for other cases. You can change order of your rules by using the arrow buttons that are circled in

Figure 119

Figure 119:Prioritization Rules for the Others Process

Deploy Changes

Deploy your modifications. Refer to page 289 .

Path of E-mail Interactions in IWDBP

All business rules will only affect interactions with a MediaType equal to email .

The following are the steps which the interaction will pass through:

•

The interaction is submitted by E-mail server and is placed into the iWD_New queue.

•

The interaction is processed by the Classification strategy. As a result, the classification business rules will be applied to the interaction. In this example, interaction will be assigned to one of the iWD processes depending on

Subject.

•

Classification rules from the assigned process will be applied. As a result, the initial

Priority

will be set—

100

for the

Sales

process,

for the

Support

process, and

for the

Others

process.

296 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

•

The interaction is placed into the iWD_Captured

queue.

•

The interaction is processed by the

Prioritization

strategy. As a result, prioritization business rules from the previously assigned process will be applied to the interaction. In this example it means that the interaction will be scheduled for reprioritization (each hour for the

Sales

process, every 2 hours for the

Support

process, and every 3 hours for the

Others

process).

•

The interaction is placed into the iWD_Queued

queue.

•

In this example, if no available agents are found, the interaction will be passed into the

Prioritization

strategy based on the schedule that was set up earlier, and the

Priority

will be increased based on the assigned process.

How to Modify IWDBP to Allow Agents to Reply to

Inbound E-mails and Send Single Outbound E-mails

This section describes how to modify the iWD business process to allow agents to send replies to inbound e-mails, and to send single outbound e-mails.

There are 2 options: create a new queue and a new strategy in

IWDBP

, or use an existing business process. In this example an existing business process will be used to illustrate how other business processes can be used from the iWD business process.

First, choose a business process to handle agent’s replies and outbound e-mails. Second, specify the queue into which the agent’s reply will be placed.

Third, specify the business process and queue for single outbound e-mails from agents.

In this example the

ABC Simple

business process will process agent’s replies

(with the

Outbound

queue). Also agents will be given the ability to place interactions into the following queues in IWDBP : iWD_Completed and iWD_Canceled

. All of this will be done in the

Distribution strategy. The Route

Interaction properties in the strategy must be as shown in

Figure 120 .

Deployment Guide 297

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 120:Route Interaction Properties

Next, assign the E-mail Server that will process the outbound e-mail interactions. To do this in the

ABC Simple business process, open the

Send ABC strategy. In the Send Email property, select the E-mail Server (see

Figure 121 ).

298 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Figure 121:Select E-Mail Server

After these modifications the iWD business process should look like

Figure 122 .

Figure 122:iWD Business Process after Modifications

Save all modifications and run all participating strategies.

Deployment Guide 299

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels

Figure 123 shows the

ABC Simple

business process.

Examples

Figure 123:ABC Simple Business Process

Note:

In this example only one endpoint is configured for E-mail Server, so there is no connection between E-mail Server and the Inbound queue in the

ABC Simple business process.

Example 3—How to Add Another Solution

One iWD business process serves one iWD tenant. One iWD tenant can have several iWD solutions. This example shows how to modify the default iWD business process to make it serve several iWD solutions.

Assume that you want to have two business solutions: one for e-mail interactions (exactly as in Example 2) and a second solution for fax interactions. Fax interactions will be submitted by an XML capture point

(

MediaType = fax

). In this example, the only difference between these two solutions will be the MediaType of interactions.

Environment

There are two streams of input interactions: one from E-mail Server (

MediaType

= email ) and second one from an XML capture point.

Use Case

In this scenario, all interactions from E-mail Server have to pass through business rules that are configured inside of Solution1 . All interactions that are submitted by the XML Capture Point have to pass through business rules that are configured inside of

Solution2

, which is the solution to which this capture point belongs. Generally, any kind of interaction can be passed into the iWD business process, but, due to the rules configuration, business rules will be applied to interactions with

MediaType = email

(business rules in

Solution1

) and to interactions with

MediaType = fax

(business rules in

Solution2

Business rules can be completely different in both solutions, in this example they are created identically, just for simplicity.

300 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Create a Solution

Configuration

Create a solution. The following steps are keyed to the numbers in

Figure 124 .

1. Select your iWD tenant (in this example, Mcr ).

2. Select

New Solution Instance

3. Enter a name for the solution (in this example,

McrSolution2

4. Click

Save

Figure 124:Create a Solution—Example 3

Deployment Guide 301

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels

Create Services

Create all necessary services under the new solution. See

Figure 125

Examples

Figure 125:Create Services for the New Solution

Create Department and Processes

Create

Classification

Rules

Create

Prioritization

Rules

Deploy

Modifications

Create a department and processes as in Example 2 (see “Create a Department and Processes in iWD” on page 291 ).

Create new Global classification rules as exactly as in Example 2 (see “Create

Global Classification Rules” on page 293

), but specify fax as the MediaType .

Create new prioritization rules as exactly as in Example 2 (see “Create

Prioritization Rules for the Processes” on page 295

), but specify fax as the

MediaType

Deploy your modifications, as described in “Deploy Modifications” on page 289

302 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

Update the

Interaction Server

Configuration

Currently iWD supports only one ESP Server per solution. Each ESP Server has to have its own Application configured in Configuration Manager or

Genesys Administrator. Therefore, we have to create another Application and add it to the

Connections

tab of the Interaction Server application. See

Figure 126 .

Figure 126:Add ESP Server to Interaction Server’s Connections

Modify the Default

Business Process

The business process has to be updated to choose the correct ESP Server to invoke from inside the strategy, based on Solution ID. A List Object is used to

make a link between the ESP Server and the solution. See “Configuration of

List Objects” on page 252 for more information.

After installation the List Object

Iwd_Esp_List

is empty. In this case,

Interaction Server will select an ESP Server from one of the Third Party

Servers in its

Connections

tab based on load balancing. Since Example 3 uses two solutions, edit the List Object to reflect the two solutions. The following steps are keyed to the numbers in

Figure 127 . Open IRD and select the correct

tenant, then do the following:

1. Select

Routing Design.

2. Select the group List Objects.

3. Select the List Object named

Iwd_Esp_List

4. Select item

ESPServerList.

5. Enter the Solution ID you attached to the e-mail interaction, as described

“Adding Required Properties to Interactions” on page 275

. If you did not attach an iWD Solution ID to the e-mail interaction, enter empty

as the key.

6. Enter the application name in Configuration Manager (or Genesys

Administrator) for the ESP Service from Example2 as a value.

7. Enter the solution ID from Example 3 (

McrSlt2

) as a key.

8. Enter application name in Configuration Manager (or Genesys

Administrator) for the ESP Service from Example 3 as a value

(

Mcr801_Solution2_ESPServer)

Deployment Guide 303

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

9. Save the List Object by clicking

Note:

In Step 5 , if a Solution ID was not added to the e-mail interaction,

empty must be entered as the key because Solution2 is intended to process interactions which were submitted not by an iWD capture point, but by Genesys Media servers (E-mail, Chat, and so on) and therefore do not have a solution ID, unless explicitly added as

described in “Adding Required Properties to Interactions” on page 275

. The key word empty

must be entered exactly as in

Figure 127 .

Figure 127:Update the List Object

Path of Interaction

Some important steps are taken in the Classification strategy. As soon as an interaction is placed in the strategy a decision is made as to which ESP Server to invoke for this interaction. This decision is made based on the presence and value of of the key-value pair IWD_solutionId in the user data of the

304 intelligent Workload Distribution 8.0

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples interaction. Interactions that were created by iWD capture points will have this key-value pair and the Solution ID will equal the ID of the Solution to which this Capture Point belongs.

•

If the key-value pair is missing from user data, then the ESP Server will be taken from the List Object

Iwd_Esp_List

, item

ESPServerList

, value for key empty

(all interactions submitted by E-mail server will not have the key-value pair, and therefore in this example

Mcr801_Solution1_ESPServer will be chosen).

•

If the key-value pair is found and matches with a key in List Object

Iwd_Esp_List

, item

ESPServerList

, then the corresponding ESP Server will be chosen (in this sample each interaction submitted by XML Capture

Point will have key-value pair IWD_solutionId = McrSlt2 , and therefore

ESP Server

Mcr801_Solution2_ESPServer

will be chosen for these interactions).

•

If the key-value pair

IWD_solutionId

is found but does not match with any key in List Object

Iwd_Esp_List

, item

ESPServerList

, then the ESP Server will be chosen by Interaction Server and the result is unpredictable

(Interaction Server will select one of Third Party Servers in its

Connections tab based on load balancing).

Path of Interactions Submitted by E-mail Server

The following flow is used for interactions that are submitted by E-mail Server

(

MediaType = email

•

The interaction is submitted by E-mail Server and is placed into the iWD_New queue.

•

The interaction is processed by the

Classification

strategy. ESP Server

Mcr801_Solution1_ESPServer

will be assigned and invoked. As a result, classification business rules will be applied to the interaction. In this example, the interaction will be assigned to one of the iWD business processes depending on

Subject

•

Classification rules from the assigned process will be applied. As a result, the initial

Priority

will be set—

100

for the

Sales

process,

for the

Support

process and

for the

Others

process.

•

The interaction is placed into the iWD_Captured

queue.

•

The interaction is processed by the

Prioritization

strategy. As a result, prioritization business rules from the previously assigned process will be applied to the interaction. In this example, that means that the interaction will be scheduled for reprioritization (each hour for the

Sales

process, every 2 hours for the

Support

process, and every 3 hours for the

Others process).

•

The interaction is placed into the iWD_Queued

queue.

Deployment Guide 305

Appendix C: Adapting the iWD Business Process for Standard Genesys Channels Examples

•

In this example, if no available agents are found, the interaction will be passed to the

Prioritization

strategy based on the schedule that was set up earlier and the

Priority

will be increased based on assigned process.

Path of Interactions Submitted by a Capture Point

As was stated earlier, the two solutions are identical, and the only difference is that Solution1 will apply business rules to e-mail interactions, and Solution2 will apply business rules to fax interactions. Therefore the following flow is the same as above for e-mail interactions except for the ESP Server. You can modify business rules for these interactions however you wish.

The following flow is used for interactions that are submitted by a Capture

Point ( MediaType = fax ):

•

The interaction is submitted by an XML Capture Point and is placed into the iWD_New queue.

•

The interaction is processed by the

Classification

strategy. ESP Server

Mcr801_Solution2_ESPServer

Subject

•

Classification rules from the assigned process will be applied. As a result, the initial

Priority

will be set—

100

for the

Sales

process,

for the

Support

process and

for the

Others

process.

•

The interaction is placed into the iWD_Captured

queue.

•

The interaction is processed by the

Prioritization

Sales

process, every 2 hours for the

Support

process, and every 3 hours for the

Others process).

•

The interaction is placed into the iWD_Queued

queue.

•

In this example, if no available agents are found, the interaction will be passed to the Prioritization strategy based on the schedule that was set up earlier and the

Priority

will be increased based on assigned process.

306 intelligent Workload Distribution 8.0

Appendix

iWD Rules and Existing

Business Processes

This Appendix explains how to use iWD business rules functionality with existing business processes. It explains what modifications have to be done in order to use iWD business rules within existing business processes.



This Appendix contains the following sections:

Using iWD Rules in Existing Business Processes, page 307

Example, page 309

Using iWD Rules in Existing Business

Processes

Remember that because you are not using the standard

IWDBP

, if you view these interactions in the Global Task List, sometimes the

Status

column will be empty. This is because the

Status

reported through the Global Task List is taken from the name of the queue in which the interaction is placed within the

Business Process, and the Global Task List assumes that these queues all have names beginning with iWD_

. Therefore, when the interaction is located in any other queue, such as

Inbound

in this example, it will not be displayed in the

Status

column.

Requirements:

•

A Genesys E-mail solution is installed. (An e-mail solution is used in the example. Modifications will be the same for any other type of media).

•

An iWD solution is installed.

Deployment Guide 307

Appendix D: iWD Rules and Existing Business Processes Using iWD Rules in Existing Business Processes

Assumptions:

•

There is only one iWD solution per business process. If you want to use a business process in several iWD solutions, you must:



For iWD native interactions (which always have

IWD_solutionId

): change the List Object

Iwd_Esp_List

accordingly (see

“Configuration of List Objects” on page 252 ).

Note:

“Native interactions” refers to interactions captured by an iWD capture adapter. Interactions going through the iWD

Business Process that do not come through an iWD capture adapter (that is, interactions coming into the system from a standard Genesys media server, through a Gplus Adapter, or through an integration built with the Genesys Open Media

SDK) are referred to as “non-native” or “foreign” interactions.



For non-native interactions (which do not have IWD_solutionId ): change the logic for assigning solutionId

, based on an interaction’s property, in the

IWD_BusinessRules_Ext

strategy (

Assign Properties block with comment solutionId = ‘Your_solution_id’

Figure 133 on page 311

shows the strategy.

•

Interactions with

MediaType = email

are the only interactions that come as input into existing business processes. If you expect interactions of several media types as input, you must adjust classification rules in iWD Manager accordingly (add condition “Media type is” ).

•

There is only one Agent Group to which the interactions can be assigned.

If you want to use several Agent Groups you must modify the target selection in the

Process ABC

strategy, which is part of the

ABC Simple BP business process that comes with eServices Interaction Workflow installation.

ABC Simple BP

The example uses the ABC Simple BP business process that comes with

eServices Interaction Workflow installation. See Figure 128

Figure 128:ABC Simple BP

308 intelligent Workload Distribution 8.0

Appendix D: iWD Rules and Existing Business Processes Example

Example

This is a simple example that shows how a business process could be modified to use iWD rules.

Use Case

In this scenario, there is a working business process, and you want to deliver interactions to agents based on priority. Priority should be assigned based on e-mail subject.

All incoming interactions (in this example they all have

MediaType = email

) should be divided into three groups based on Subject : NewAccount, Support, and all others. All interactions will be delivered to one Agent Group (

IWD

), but interactions with

Subject = NewAccount

will have highest priority and will be reprioritized more often. Interactions with

Subject = Support

will have lower priority and all other interactions will have the lowest priority and will be reprioritized less often.

Modify the Existing Business Process

Modify the existing business process. Add one more strategy, which will invoke the iWD service to apply business rules. Also, one queue will be added to the business process. This queue will provide the mechanism for reprioritization and delivering interactions to an agent based on priority.

The iWD Setup Utility includes a sample business process that contains a couple of strategies and a queue.

Figure 129 shows the

ABC IWD Simple BP business process.

Figure 129:ABC IWD Simple BP

In this business process, the property of the

All by priority

view is

configured as shown in Figure 129

(the

Conditions

tab is empty). Thus,

Deployment Guide 309

Appendix D: iWD Rules and Existing Business Processes Example interactions from this queue and through this view will be taken by priority.

The interaction with the highest priority will be taken first.

310

Figure 130:All by Priority Interaction Queue View Properties

Properties of the

To reprioritize

view are configured as in Figure 131 and

Figure 132 . Thus, interactions from this queue and through this view will be

taken sorted by

IWD_reprioritizeDateTime

; and only if

IWD_reprioritizeDateTime

was set and has expired.

Figure 131:‘To Reprioritize’ Properties—Condition Tab

intelligent Workload Distribution 8.0

Appendix D: iWD Rules and Existing Business Processes

Figure 132:‘To Reprioritize’ Properties—Order Tab

Figure 133 shows the iWD Business Rules Ext strategy.

Example

Figure 133:iWD Business Rules Ext Strategy

Figure 134 shows the

iWD_Reprioritization_Ext

strategy. The key-value pair

IWD_solutionId

will always be attached after the

IWD_BusinessRules_Ext

Deployment Guide 311

Appendix D: iWD Rules and Existing Business Processes Example strategy. This is why no check is made for the presence of that key-value pair in the strategy.

Figure 134:iWD Reprioritization Ext Strategy

Move the iWD_Processed queue, as well as the iWD_BusinessRules_Ext and iWD_Reprioritization_Ext

strategies from the

ABC IWD Simple BP business process to the

ABC Simple BP

business process. Figure 135 shows how the

ABC

Simple BP

will look at this point.

Figure 135:ABC Simple BP with Queue and Strategies Added

Insert the added group between

Inbound queue

and

Process ABC

Figure 136

shows how the

ABC Simple BP

business process will look at this point.

Figure 136:ABC Simple BP with Group Added

The existing business process is now updated. Next, create business rules in iWD.

312 intelligent Workload Distribution 8.0

Appendix D: iWD Rules and Existing Business Processes Example

Rules creation

Open iWD Manager and modify the Standard Rules Template as described in

“Modify the Standard Rules Template” on page 285

. Assume that all incoming interactions have

MediaType = email

, so you only need to add the four new

Actions.

Create an iWD Tenant and an iWD Solution, as described in “iWD

Configuration” on page 284

Create a department and processes as described in “Create a Department and

Processes in iWD” on page 291

Create new Global classification rules as described in “Create Global

Classification Rules” on page 293

(in this example we do not check media type, assuming that all interactions have

MediaType = email

Create prioritization rules for your processes as described in“Create

Prioritization Rules for the Processes” on page 295

Deploy your modifications.

Path of E-mail Interactions

The following are the steps which the interaction will pass through:

•

The interaction is submitted by E-mail server and is placed into the

Inbound queue.

•

The interaction is processed by the

IWD_BusinessRules_Ext

strategy:



The

SetBusinessContext

method of the ESP Service is invoked:



First, global classification rules are applied. As a result, the interaction will be assigned to one of iWD processes depending on

Subject.

Immediately after global classification rules are applied, classification rules of the assigned Department and Process will be applied. As a result, the initial

Priority

will be set—

100

for the

Sales

process,

for the

Support

process, and

for the

Others process.



The Classification step is completed.

The Prioritize method of the ESP Service is invoked:



As a result, prioritization business rules from the previously assigned process will be applied to the interaction. In this example, that means that the interaction will be scheduled for reprioritization

(each hour for the

Sales

process, every 2 hours for the

Support process, and every 3 hours for the

Others

process).

The Prioritization step is completed.

•

The

IWD_BusinessRules_Ext

strategy is completed and the interaction is placed into the iWD_Processed

queue.

Deployment Guide 313

Appendix D: iWD Rules and Existing Business Processes Example

•

In this example, if no available agents are found, the interaction will be passed to the

IWD_Reprioritization_Ext

strategy based on the schedule that was set up earlier. Priority will be increased based on the prioritization rules specified in the assigned process. Interaction will be rescheduled for reprioritization and placed back into the iWD_Processed

queue.

314 intelligent Workload Distribution 8.0

Supplements

Resources

The following resources provide additional information that is relevant to this software. Consult these additional resources as necessary.

intelligent Workload Distribution (iWD)

•

iWD Data Mart Reference Manual, which describes/provides information about the iWD Data Mart.

•

iWD WebSphere MQ Capture Adapter Reference Guide, which provides installation and configuration information for the WebSphere MQ Capture

Adapter.

In addition, the https://sites.google.com/a/iwdlab.com/iwd8/

website provides additional information about working with iWD. The content on this website is updated frequently.

eServices

•

eServices 8.0 Deployment Guide, which includes a high-level overview of features and functions of Genesys eServices together with architecture information and deployment-planning materials. It also introduces you to some of the basic concepts and terminology that are used in this product.

The eServices Deployment Guide also provides information about deploying the JMS Integrated Capture Point.

•

eServices 8.0 User’s Guide, which provides overall information and recommendations on the use and operation of Genesys eServices, and the use and operation of the JMS Integrated Capture Point.

•

eServices 8.0 Reference Manual, which provides information about the configuration options for each eServices component, including options specific to the JMS Integrated Capture Point.

•

eServices 8.0 Open Media Interaction Models Reference Manual, which presents a set of basic interaction models—showing the components that are involved and the messaging (requests, events) among them.

Deployment Guide 315

Genesys

•

Genesys Technical Publications Glossary, which ships on the Genesys

Documentation Library DVD and which provides a comprehensive list of the Genesys and computer-telephony integration (CTI) terminology and acronyms used in this document.

•

Genesys Migration Guide, which ships on the Genesys Documentation

Library DVD, and which provides documented migration strategies for

Genesys product releases. Contact Genesys Technical Support for more information.

•

Release Notes and Product Advisories for this product, which are available on the Genesys Technical Support website at http://genesyslab.com/support .

Information about supported hardware and third-party software is available on the Genesys Technical Support website in the following documents:

•

Genesys Supported Operating Environment Reference Manual

•

Genesys Supported Media Interfaces Reference Manual

Consult these additional resources as necessary:

•

Genesys Hardware Sizing Guide, which provides information about

Genesys hardware sizing guidelines for the Genesys 8.x releases.

•

Genesys Interoperability Guide, which provides information on the compatibility of Genesys products with various Configuration Layer

Environments; Interoperability of Reporting Templates and Solutions; and

Gplus Adapters Interoperability.

•

Genesys Licensing Guide, which introduces you to the concepts, terminology, and procedures that are relevant to the Genesys licensing system.

•

Genesys Database Sizing Estimator 8.x Worksheets, which provides a range of expected database sizes for various Genesys products.

For additional system-wide planning tools and information, see the release-specific listings of System Level Documents on the Genesys Technical

Support website. These documents are accessible from the system level documents by release

tab in the Knowledge Base

Browse Documents

Section.

Genesys product documentation is available on the:

•

Genesys Technical Support website at http://genesyslab.com/support

•

Genesys Documentation wiki at http://docs.genesyslab.com/ .

316 intelligent Workload Distribution 8.0

Document Version Number

A version number appears at the bottom of the inside front cover of this document. Version numbers change as new information is added to this document. Here is a sample version number:

80fr_ref_06-2008_v8.0.001.00

You will need this number when you are talking with Genesys Technical

Support about this product.

Screen Captures Used in This Document

Screen captures from the product graphical user interface (GUI), as used in this document, may sometimes contain minor spelling, capitalization, or grammatical errors. The text accompanying and explaining the screen captures corrects such errors except when such a correction would prevent you from installing, configuring, or successfully using the product. For example, if the name of an option contains a usage error, the name would be presented exactly as it appears in the product GUI; the error would not be corrected in any accompanying text.

Type Styles

Table 65

describes and illustrates the type conventions that are used in this document.

Table 65: Type Styles

Type Style Used For

Italic

Examples

• Document titles

• Emphasis

• Definitions of (or first references to) unfamiliar terms

• Mathematical variables

Also used to indicate placeholder text within code samples or commands, in the special case where angle brackets are a required part of the syntax (see the note about angle brackets on

page 319

Please consult the Genesys Migration

Guide for more information.

Do not use this value for this option.

A customary and usual practice is one that is widely accepted and used within a particular industry or profession.

The formula, x +1 = 7 where x stands for . . .

318 intelligent Workload Distribution 8.0

Document Conventions

Table 65: Type Styles (Continued)

Type Style Used For Examples

Monospace font

(Looks like teletype

or typewriter text

)

All programming identifiers and GUI elements. This convention includes:

• The names of directories, files, folders, configuration objects, paths, scripts, dialog boxes, options, fields, text and list boxes, operational modes, all buttons (including radio buttons), check boxes, commands, tabs, CTI events, and error messages.

• The values of options.

• Logical arguments and command syntax.

• Code samples.

Also used for any text that users must manually enter during a configuration or installation procedure, or on a command line.

Select the

Show variables on screen check box.

In the

Operand

text box, enter your formula.

Click

to exit the

Properties

dialog box.

T-Server distributes the error messages in

EventError

events.

If you select true

for the inbound-bsns-calls

option, all established inbound calls on a local agent are considered business calls.

Enter exit

on the command line.

Square brackets ([ ])

A particular parameter or value that is optional within a logical argument, a command, or some programming syntax. That is, the presence of the parameter or value is not required to resolve the argument, command, or block of code. The user decides whether to include this optional information.

smcp_server -host [/flags] smcp_server -host <confighost>

Angle brackets

(< >)

A placeholder for a value that the user must specify. This might be a DN or a port number specific to your enterprise.

Note: In some cases, angle brackets are required characters in code syntax (for example, in XML schemas). In these cases, italic text is used for placeholder values.

Deployment Guide 319

Document Conventions

320 intelligent Workload Distribution 8.0

Index

Symbols

[] (square brackets)

. . . . . . . . . . . . . . 319

< > (angle brackets)

. . . . . . . . . . . . . 319

ABC IWD Simple BP business process

. . . 309

ABC Simple BP business process

. . . . . . 308

Access Groups

. . . . . . . . . . . . . . . . 116

ACME Sample Application

. . . . . . . . . . 94

Actions properties and actions

. . . . . . . . . . . 130

ADDP

. . . . . . . . . . . . . . . . . . . .56

–

angle brackets

. . . . . . . . . . . . . . . . 319

Apache

. . . . . . . . . . . . . . . . . . . . 41

application cluster

. . . . . . . . . . . . . . 222

application installation

. . . . . . . . . . . . 28

Archive strategy

. . . . . . . . . . . . . . . . . . . 226

269

audience, for document

. . . . . . . . . . . 13

Boolean

BPR_iWD_Extension.jar

. . . . . . . . . . . 173

BPR_iWD_Extension.jar Stat Server option

. 78

brackets angle

. . . . . . . . . . . . . . . . . . . . 319

square

. . . . . . . . . . . . . . . . . . . 319

Business Attribute

. . . . . . . . . . . . . . 71

Business Calendars view

. . . . . . . . . . 183

Business Context Management

Service

. . . . . . . . . . . . 74

151

creating

. . . . . . . . . . . . . . 221

high availability

business logic

. . . . . . . . . . . . . . . . 182

CancelTask message

. . . . . . . . . . . . 243

capacity rule

. . . . . . . . . . . . . . . . 68

Capture Adapters

. . . . . . . . . . . . . . . 17

Database

. . . . . . . . . . . . . . . . . . 18

JMS

. . . . . . . . . . . . . . . 18

147

Web Service

. . . . . . . . . . . . . . . . 17

XML

. . . . . . . . . . . . . . . . . . . . . 17

CCPulse+ template

. . . . . . . . . . . . . 179

centralized logging

. . . . . . . . . . . . . . . 21

centralized logging configuration

. . . . . . . 82

Change History view

. . . . . . . . . . . . . . . . . 113

144

properties and actions

. . . . . . . . . . 145

Classification strategy

. . . . . . . . . 253

257

CME Tenant

commenting on this document

. . . . . . . . . 13

compatibility

. . . . . . . . . . . . . . . . . . 41

completed-queues Interaction Server option

. 85

CompleteTask message

. . . . . . . . . . . 239

component

. . . . . . . . . . . . . . . . . . 125

Conditions properties and actions

. . . . . . . . . . 130

configuration sections

. . . . . . . . . . . . 106

Departments & Processes

. . . . . . . . 106

Global Task List

. . . . . . . . . . . . . . 106

Modules & Components

. . . . . . . . . 106

Services

. . . . . . . . . . . . . . . . . . 106

Configuration Server

. . . . . . . . . . . . . 101

Configuration Server Connector

Service

. . . . . . . . . . .80

150

153

creating

. . . . . . . . . . . . . 82

configuring a custom interaction property

. . . . . . . 249

centralized logging

iWD Manager logging

. . . . . . . . . . . . 82

iWD Runtime Node logging

. . . . . . . . . 82

using the iWD Setup Utility

. . . . . . . . . 69

Context history

. . . . . . . . . . . . . . . . 109

conventions in document

. . . . . . . . . . . . . . . . 318

Deployment Guide 321

Index type styles

. . . . . . . . . . . . . . . . . 318

CreateTask message

. . . . . . . . . . . . . 228

creating iWD Configuration database

. . . . . . . . 50

iWD Data Mart database

. . . . . . . . . . 62

iWD Runtime Node in iWD Manager

. . . . 65

iWD Solution in iWD Manager

. . . . . . . . 65

iWD Tenant in iWD Manager

. . . . . . . . 65

services in iWD Manager

. . . . . . . . . . 80

current-day statistics

. . . . . . . . . . . . . 179

custom properties (interaction)

. . . . . . . . 248

Data Mart ETL services

. . . . . . . . . . . 173

Data Types

. . . . . . . . . . . . . . . . . . 226

database iWD Configuration database

. . . . . . . . 28

Database Capture Adapter

. . . . . . . . . . 18

Database Capture Point

. . . . . . . . . . . 161

properties

. . . . . . . . . . . . . . . . . 162

Database Capture Point Service

. . . . . . . 151

database preparation

. . . . . . . . . . . . . 28

Database Service

. . . . . . . . . . . 151

169

properties

. . . . . . . . . . . . . . . . . 169

databases

Interaction Server

. . . . . . . . . . . . . . 85

DateTime

. . . . . . . . . . . . . . . . . . . 226

Department Details view

. . . . . . . . 182

183

Departments & Processes configuration section

. . . . . . . . .106

182

Deployment

Departments and Processes

. . . . . . . 183

properties and actions

. . . . . . . . . . . 143

Solutions and Services

. . . . . . . .136

143

Details view

. . . . . . . . . . . . . . 103

107

DetermineESPServerName subroutine

. . . 254

Direction

. . . . . . . . . . . . . . . . . . . 225

Distribution strategy

. . . . . . . . 254

263

279

document audience

. . . . . . . . . . . . . . . . . . . 13

change history

. . . . . . . . . . . . . . . . 14

conventions

. . . . . . . . . . . . . . . . 318

errors, commenting on

. . . . . . . . . . . 13

version number

. . . . . . . . . . . . . . 318

Error message

. . . . . . . . . . . . . . . . 230

ESP block

. . . . . . . . . . . . . . . . . . 25

ESP object

. . . . . . . . . . . . . . . . . . 222

Extended Statistics Service

. . . . . . . . . 170

External Service Protocol (ESP) block

. . . . 25

F font styles italic

. . . . . . . . . . . . . . . . . . . . 318

monospace

. . . . . . . . . . . . . . . . 319

Functions tab

. . . . . . . . . . . . . . . . 133

properties and actions

. . . . . . . . . . 134

General configuration

. . . . . . . . . . . . 111

Genesys Administrator

. . . . . . . . . . . . 101

Genesys Chat

. . . . . . . . . . . . . . . . . 12

Genesys E-mail

. . . . . . . . . . . . . . . . 12

Genesys Info Mart

. . . . . . . . . . . . . . . 21

Genesys Interaction Server Connector

Service properties

. . . . . . . . . . . . . . . . . 155

Genesys SMS

. . . . . . . . . . . . . . . . . 12

GetTaskInfo message

. . . . . . . . . . . . 231

Global Rules

. . . . . . . . . . . . . . . . . 192

Global Task List

. . . . . . . . . . . . . . . 106

configuration section

. . . . . . . . . . . 106

Header bar

. . . . . . . . . . . . . . . 103

104

historical reporting

. . . . . . . . . . . . . . . 21

History view

. . . . . . . . . . . . . . . . . 123

properties and actions

. . . . . . . . . . 124

HoldTask message

. . . . . . . . . . . . . . 240

ICON

. . . . . . . . . . . . . . . . . . . . . . 21

ics_multi_media_agent_seat technical license

. . . . . . . . . . . . . . . . . 22

Import and Export function

. . . . . . . . . . 114

Import and Export view

. . . . . . . . . . . 111

Import/Export properties and actions

. . . . 115

Import/Export view

. . . . . . . . . . . . . . 114

In messages

. . . . . . . . . . . . . . . . . 225

installation

. . . . . . . . . . . . . . . . . . . 27

installing

Interaction Server and its databases

. . . . 43

iWD Capture

. . . . . . . . . . . . . . . . 60

iWD Data Mart

. . . . . . . . . . . . . . . 61

iWD Manager

. . . . . . . . . . . . . . . . 51

iWD Rules

. . . . . . . . . . . . . . . . . . 59

iWD Runtime Node

. . . . . . . . . . . . . 46

iWD Setup Utility

. . . . . . . . . . . . . . 68

iWD Stat Extensions

. . . . . . . . . . . . 78

Integer

. . . . . . . . . . . . . . . . . . . . 226

322 intelligent Workload Distribution 8.0

Index intelligent Workload Distribution features

overview

. . . . . . . . . . . . . . 13

intended audience

Interaction Concentrator

. . . . . . . . . . . 21

interaction custom properties

. . . . . . . . 248

interaction properties mapping

. . . . . . . . 245

Interaction Queues

. . . . . . . . . . . . . . 254

Interaction Server

. . . . . . . . . . . . . . 41

Interaction Server Connector

Service

. . . . . . . . . . . 80

150

154

creating

. . . . . . . . . . . . 245

Interaction Server database

. . . . . . . . . 86

interactions table

248

italics

. . . . . . . . . . . . . . . . . . . . . 318

iWD

system configuration

. . . . . . . . . . . . 29

Configuration database

. . . . . . . . . . . 28

features

. . . . . . . . . . . . . . . . . . 27

installation

overview

. . . . . . . . . . . . . . . . 12

iWD application

iWD business process

. . . . . . . . . . . . 251

iWD business rules using within an existing business process

. 307

iWD CDs

. . . . . . . . . . . . . . . . . . . 41

iWD Extended Statistics Service

. . . . . . . 170

iWD installation preparation

. . . . . . . . . . . . . . . . . 39

prerequisites

. . . . . . . . . . . . . . . . . 40

iWD Manager

. . . . . . . . . . . . . . . . . 97

iWD Rules Service

. . . . . . . . . . . . . . 25

iWD services recommended configuration order

. . . . 150

iWD Setup Utility installing

. . . . . . . . . . . . . . . . . . . 68

iWD solution

. . . . . . . . . . . . . . . . . 12

iWD state model

. . . . . . . . . . . . . . . 25

IWD_BusinessRules_Ext strategy

. . . . . . 311

iWD_Canceled queue

iWD_Captured queue

. . . . . . . . . . . 254

iWD_Completed queue

iWD_ErrorHeld queue

. . . . . . . . . . . . . . . . . 252

Iwd_Esp_List

iWD_New queue

. . . . . . . . . . . . . . . 254

iWD_Queued queue

. . . . . . . . . . . . . 254

iWD_Rejected queue

. . . . . . . . . . . . . 254

iWD_Reprioritization_Ext strategy

. . . . . . 311

IWDBP

. . . . . . . . . . . . . . . . . . . . 251

adapting for standard Genesys channels

. 275

strategies

. . . . . . . . . . . . . . . . . 253

Java SDK

. . . . . . . . . . . . . . . . . . . 41

java-extension-jar Stat Server option

. . . . . 78

jaxb-api.jar

. . . . . . . . . . . . . . . . . 48

jaxb-impl.jar

. . . . . . . . . . . . . . . . 48

jdbc-driver Stat Server option

. . . . . . . . . 79

jdbc-url Stat Server option

. . . . . . . . . . . 79

JMS Capture Point

. . . . . . 18

147

157

Kettle ETL Service

. . . . . . . . . . . 151

173

properties

. . . . . . . . . . . . . . . . . 174

Last Viewed

. . . . . . . . . . . . . . . . . 107

licensing

. . . . . . . . . . . . . . . . . . . . 21

List Object

. . . . . . . . . . . . . . . . . . 252

Log Viewer

. . . . . . . . . . . . . . . . . . 145

log4j.properties

. . . . . . . . . . . . . . . . 83

Logging Service

. . . . . . . . . . .80

150

152

creating

. . . . . . . . . . . . . . . . . 152

properties

logs

Management Layer

. . . . . . . . . . . . 316

lookup tables

. . . . . . . . . . . . . . . . . 120

Lookup Tables view

. . . . . . . . . . . . . 111

M managed tenant

. . . . . . . . . . . . . . . . 29

Managed Tenant Details view

. . . . . . 111

118

Managed Tenant view properties and actions

. . . . . . . . . . 119

Management Layer logging

. . . . . . . . . 316

Message Server

. . . . . . . . . . . . . . . . 21

messages

CancelTask

. . . . . . . . . . . . . . . . 243

CompleteTask

. . . . . . . . . . . . . . . 239

CreateTask

. . . . . . . . . . . . . . . . 228

Error

. . . . . . . . . . . . . . . . . . . . 230

GetTaskInfo

. . . . . . . . . . . . . . . . 231

HoldTask

. . . . . . . . . . . . . . . . . 240

Ping

. . . . . . . . . . . . . . . . . . . . 244

Pong

. . . . . . . . . . . . . . . . . . . 244

RestartTask

. . . . . . . . . . . . . . . . 242

ResumeTask

. . . . . . . . . . . . . . . 241

Task Action

. . . . . . . . . . . . . . . . 226

Task Notification

. . . . . . . . . . . . . 227

TaskAssigned

. . . . . . . . . . . . . . . 239

TaskCanceled

. . . . . . . . . . . . . . . 243

TaskCompleted

. . . . . . . . . . . . . . 239

TaskCreated

. . . . . . . . . . . . . . . 230

Deployment Guide 323

Index

TaskDistributedQueue

. . . . . . . . . . . 238

TaskErrorHeld

. . . . . . . . . . . . . . . 241

TaskHeld

. . . . . . . . . . . . . . . . . . 240

TaskInfo

. . . . . . . . . . . . . . . . . . 231

TaskRejected

. . . . . . . . . . . . . . . 244

TaskRestarted

. . . . . . . . . . . . . . . 242

TaskResumed

. . . . . . . . . . . . . . . 241

TaskUpdated

. . . . . . . . . . . . . . . 237

UpdateTask

. . . . . . . . . . . . . . . . 236

Metric template value types

. . . . . . . . . . . . . . . . 135

Metrics templates

. . . . . . . . . . . 125

135

Modules

. . . . . . . . . . . . . . . . . . . 126

Modules & Components configuration section

. . . . . . . . . . . 106

Modules view properties and actions

. . . . . . . . . . . 127

monospace font

. . . . . . . . . . . . . . . 319

N native interactions

. . . . . . . . . . . . . . 308

Navigation panel

. . . . . . . . . . . . . . . 104

navigation sections

General

. . . . . . . . . . . . . . . . . . 106

navigation tree

. . . . . . . . . . . . . . . . 107

navigation sections

. . . . . . . . . . . . . . 106

Navigational panel

. . . . . . . . . . . . . . 103

Object Actions

. . . . . . . . . . . . . . . . 108

Open Media API

. . . . . . . . . . . . . . . 12

Out messages

. . . . . . . . . . . . . . . . 225

Parameters tab

. . . . . . . . . . . . . . . . 131

properties and actions

. . . . . . . . . . . 131

password encoder

. . . . . . . . . . . . . . 53

password Stat Server option

. . . . . . . . . 79

passwordEncoder.cmd file

. . . . . . . . . . 53

Person

. . . . . . . . . . . . . . . . . . . . 101

Ping message

. . . . . . . . . . . . . . . . 244

Pong message

. . . . . . . . . . . . . . . . 244

Prioritization strategy

. . . . . . . . . . 253

260

Process Details view

. . . . . . . . . . . . . 182

Profile view

. . . . . . . . . . . . . . . 111

112

properties and actions

. . . . . . . . . . . 112

R refresh-interval Stat Server option

. . . . . . 79

Reporting

. . . . . . . . . . . . . . . . . . . 21

RestartTask message

. . . . . . . . . . . . 242

ResumeTask message

. . . . . . . . . . . . 241

Rule Template view properties and actions

. . . . . . . . . . 129

Rule templates

. . . . . . . . . . . . . 125

127

Rules Service

. . . . . . . . . . . .80

151

167

creating

. . . . . . . . . . . . . . . . . 167

properties

Rules view

. . . . . . . . . . . . . . . . . . 182

Runtime Nodes view

. . . . . . . . . . . . . . . 94

138

properties and actions

. . . . . . . . . . 138

S sample application

Scheduled ETL Job Service

. . . . . . . . . 151

Scheduled ETL Job service

. . . . . . . . . 176

properties

. . . . . . . . . . . . . . . . . 176

Scripting Service

. . . . . . . . . . . . 150

156

properties

. . . . . . . . . . . . . . . . . 157

Security Policies properties and actions

. . . . . . . . . . 117

Security Policies view

. . . . . . . . . . . . 111

Security Policy

. . . . . . . . . . . . . . . . 116

Service Details view

. . . . . . . . . . . . . . 125

140

properties and actions

. . . . . . . . . . 141

Service templates

Services configuration section

. . . . . . . . . . . 106

Configuration Server Connector

. . . . . 153

Data Mart ETL Services

Kettle ETL Service

. . . . . . . . . . . 173

Data Mart ETL services

. . . . . . . . . . 173

Database Capture Point

. . . . . . . . . 161

Database service

. . . . . . . . . . . . . 169

Interaction Server Connector Service

. . . 154

iWD Extended Statistics Service

. . . . . 170

Logging Service

. . . . . . . . . . . . . . 152

Rules Service

. . . . . . . . . . . . . . . 167

Scheduled ETL Job Services

. . . . . . . 176

Scripting Service

. . . . . . . . . . . . . 156

Web Service Capture Point

. . . . . . . . 157

XML File Capture Point Service

. . . . . 159

Services configuration section

. . . . . . . . 136

Services view

. . . . . . . . . . . . . 136

139

properties and actions

. . . . . . . . . . 140

Setup Utility

See iWD Setup Utility

Solution Details view