Parameters Editor
The Parameters Editor allows you to create rule parameters, which are optionally used in rule conditions and actions. You can also map a parameter to a fact model by using the button. See Mapping Parameters to a Fact Model.
Each parameter contains the same fields in the Details section:
Name: A name for the parameter.
Description: A brief description of the parameter.
Parameter Names
The underscore (_) character in parameter names has a special meaning when building rule templates. It is used to specify an index of the parameter in circumstances where the rule expression requires additional instances of the parameter. The most common example is a range definition.
For example, suppose you need to create a condition which has to check if the task’s due date is in either the date1 to date2 range, or in the date3 to date4 range. You could create a condition such as:
Due is in "{dueDT1}" to "{dueDT2}" or in "{dueDT3}" to "{dueDT4}")
But this requires the definition of 4 parameters with type InputDate in the Parameters section. This approach can become inefficient, especially if there is more than one occurrence of the condition/action.
A better solution is to use the underscore and index approach:
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.
Categories of Parameter
The Configuration section contains information that is dependent on the parameter type. When a type is selected from the drop-down list, different fields are displayed that relate to that type.
There are eight main categories of parameters:
- Configuration Server
- Input Value
- Database
- Operational
- Select Enumeration
- Web Service
- Workforce Management
- Calendar
Configuration Server
Configuration Server parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Configuration Server parameter may be configured to pull a list of Agent Groups from the Configuration Server database. The list is populated from Configuration Server. Configuration Server parameters require you to select the Object type—Business Attribute, Business Context, List Object, or List— as described below:
Selecting Business Attribute prompts you to select the name of the Business Attribute from a list defined in Configuration Manager.
Selecting Business Context prompts you to enter the level of the Business Context that is of interest for this parameter. Here, Business Context refers to the level of the hierarchy under the Business Structure folder in Configuration Server.
Selecting List Object prompts you to select the List and Section values for the List Object from a user-defined set of List objects.
Selecting List prompts you to select from a predefined set of lists as shown below:
- Agent Groups
- Agent Skills
- Agents
- Extensions
- External Route Points
- Interaction Queue
- Media Types
- Place Groups
- Places
- Route Points
- Switch
- T-Server
- Virtual Route Points
Input Value
Input Value parameters are simply parameters for which the rules author can provide a value based on the defined parameter type (Boolean, Integer, Numeric, String, Date, or Time). These parameters can also be constrained. For instance, an integer value can be constrained to be within a defined range.
Matching Patterns
For Input Value parameters of type String, you can enter a matching pattern that must be followed. Enter a Javascript regular expression to define the matching pattern. For example, a Zip Code parameter might have the matching pattern:
>^\d{5}$|^\d{5}-\d{4}$
which represents a 5-digit zip code. A Phone Number parameter might have the matching pattern:
^\(?(\d{3})\)?[- ]?(\d{3})[- ]?(\d{4})$
which represents a 10-digit phone number in the format (xxx)-xxx-xxxx.
The regex pattern supported should conform to the browser's Javascript engine and may vary slightly depending on the browser version.
Custom Tooltips
Use Custom Tooltip allows you to enter useful tooltip text when defining all Input Value parameters (except for the Boolean parameter type, which does not need a tooltip). If you check Use Custom Tooltip, the text that you enter in the tooltip field is displayed in GRAT when this parameter is used in a rule condition or action. If you do not check Use Custom Tooltip, GRAT displays an automatically generated tooltip; for example, {age} is an integer between 1 and 99.
Database
Database parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Database parameter may be configured to pull a list of Order Types from a database. The list is populated by a database query. Database parameters require the Profile Name (the name of the Configuration Server Script object that contains your database connection information), Query Type (Single Value or List, depending on what you want to show up in GRAT), and the SQL Query to be executed.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example To use a Database parameter, a parameter profile must previously have been configured for the Tenant in Configuration Server. This is a Script object that specifies the JDBC driver, as well as the database url, username, and password required to perform the query. Refer to the Genesys Rules System Deployment Guide for information on configuring these profiles. The name of this Script object is used as the profile name for the database parameter.
To obtain values from the database, a valid SQL Select statement must be specified. For instance, to get all the values of a column use a select statement of the following form:
SELECT column_name FROM table_name
For dynamic Database parameters, you can configure the parameter so that both a name (an internal value that is included with a rule evaluation request) and a label (the information that is displayed to a rules author when authoring a rule that uses this parameter) can be retrieved from two different database columns.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| driver | Mandatory | The name of the jdbc driver to be used. For example, com.mysql.jdbc.Driver |
| url | Mandatory | The url for the database in the correct format for the jdbc driver to be used. |
| username | Mandatory | A valid username to connect to the database. |
| password | Mandatory | The password needed for the user to connect to the database. |
| initSize | Optional | The initial size of the connection pool. The default is 5. |
| maxSize | Optional | The maximum size of the connection pool. The default is 30. |
| waitTime | Optional | The maximum time (in milliseconds) to wait for obtaining a connection. The default is 5000. |
In general, the optional values do not need to be set or changed.
In GRDT, you can only configure database parameters with an SQL SELECT statement. Any other type of statement will fail when configured.
Operational
Operational parameters are created by users through Genesys Administrator Extension and, when deployed, are stored as options of Transaction objects of the type List in the Genesys Configuration Server Database. At rule execution time, when the Rules Engine evaluates a rule that contains an Operational parameter, it obtains the current value of the associated Transaction object option from Configuration Server. The rule developer determines from which Transaction object, and which option of that object, the value of the Operational parameter is fetched, and the rule author uses this parameter as part of a condition or action.
Example An Operational parameter called waitTimeThreshold may be defined. If a caller is waiting longer than this threshold for an available agent, some other action may be performed.
Instead of specifying a value for the threshold in the rule like the following:
When Caller’s wait time is greater than 30 seconds Then Offer a callback
the rule author could specify:
When
Caller’s wait time is greater than "{waitTimeThreshold}"
Then
Offer a callback
The value of "{waitTimeThreshold}" can be changed at any time by a user using Genesys Administrator Extension and will have an immediate effect without having to modify and redeploy a rule package.
For example, use the following condition when you define the mapping:
Queue(waitTime > "{waitTimeThreshold}" )
To configure an Operational parameter you need two IDs:
- The List ID, which corresponds to the name of the Transaction object in which the Operational parameter is stored
- The Parameter ID, which corresponds to the name of an option of that Transaction object.
The option value contains the actual value of the Operational parameter that is retrieved by the Rules Engine when the rule is evaluated. Operational parameters are always stored as Transaction objects of the type List, but the precise configuration of the options within that List object varies depending on how the Operational parameter was configured.
Refer to the Genesys Administrator Extension Help for general information about Operational parameters.
Select Enumeration
Select Enumeration parameters are linked with an Enumeration. This provides the rules author with a specific list from which to select.
Web Service
Web Service parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Web Service parameter may be configured to pull a list of stock symbols from an external web service. The list is populated by a Web Service query. Web Service parameters require the Profile Name (the name of the Configuration Server Script object that contains your web service connection information), Query Type (Single Value or List), and the XPath Query to be executed. In addition, Web Service parameters require that some Protocol Settings be entered, specifically the HTTP Method, Path, and the Message Body.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example Similar to a Database parameter, a parameter profile must also have been previously created. This profile will contain information such as the server’s address (host and port), the path to the service, and any other necessary HTTP settings. Refer to the Genesys Rules System Deployment Guide for information about configuring these profiles.
To obtain values from the service, a valid message for the service must be specified. This message must be constant. In other words, no variable substitution will occur.
Note: No message can be sent for HTTP GET requests. All the information in the request is provided through the query string and/or headers.
For instance, to obtain the weather forecast for San Francisco, the following request can be made to the Weather Underground REST service:
http://api.wunderground.com/auto/wui/geo/ForecastXML/index.xml?query=94129
However, this is the complete request. The host (api.wunderground.com) and the base path (/auto/wui/geo/ForecastXML/), must be specified in the profile.
To define a parameter to make this request, the profile name must reference the correct information described above. In addition, the Protocol Settings must specify GET as the method, along with index.xml?query=94129 as the path. No message is needed for this request.
To obtain values from the result, a valid XPath expression must be specified. The Web Service must return results in XML or JSON. Please see the XPath specification for more information on XPath expressions.
For example, to get the forecast highs from the previously described request, the following XPath expression may be used:
//high/fahrenheit/text()
In Configuration Server, Web Service Scripts must have a section called webservice. The table below lists the properties that you can specify for web service parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| host | Mandatory | The host for the service. |
| base_path | Mandatory | The base path to access the service. |
| protocol | Optional | The default is http. |
| port | Optional | The default is 80. |
| headers | Optional | Any custom HTTP headers that are needed for the service. |
| parameters | Optional | Any custom HTTP settings that are needed to tune the connection. |
In general, the parameters values do not need to be set or changed. Headers and parameters are lists in the following format:
key:value[,key:value]
You cannot specify headers or parameters that contain "," in the value. If you are sending a message to the service, it is expected that Content-Type is specified in the header since it defines the overall message interaction with the server. An optional charset can be included. For example, Content-Type:applicaton/json;charset=UTF-8.
In GRDT, the path for the parameter is added to the base_path in the script. For example, if the Script contains:
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
and the GRDT specifies:
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
then the message that is sent is:
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
This will return the week's highs in Fahrenheit:
81 77 81 81 83 85
Workforce Management
Workforce Management (WFM) parameters enable the rules author to select a value from a drop-down list of activities (a WFM database object that represents contact center tasks in which agents can be engaged) and multi-site activities (a collection of activities performed at multiple physical sites) that is dynamically retrieved from the Genesys Workforce Management Server. Workforce Management parameters require the WFM Profile (the Configuration Server Script object of type Data Collection).
Example: An activity is the main planning object that is used when building forecasts and schedules. An activity can be associated with an individual WFM Site object, or multi-site activities can be created at the WFM Business Unit level, which aggregates information from multiple "child" activities across multiple WFM Sites. So, when providing the rules author a list of WFM activities that are dynamically fetched from the WFM Server, the name of the WFM activity or multi-site activity is prefixed with the name of the WFM Site or the WFM Business Unit, respectively.
For example, if the WFM configuration has the following structure:
Business Unit with the name ‘ACME’
– Site with the name ‘San Francisco’ – Activity with the name ‘Disputes’ – Activity with the name ‘Billing Inquiries’ – Site with the name ‘Chicago’ – Activity with the name ‘Disputes’ – Activity with the name ‘Address Changes’ – Multi-Site Activity with the name ‘Billing’ (comprised of ‘Billing Inquiries’ from the San Francisco site and ‘Address Changes’' from the Chicago site) – Multi-Site Activity with the name ‘Disputes’ (comprised of ‘Disputes’ from the San Francisco site and ‘Disputes’ from the Chicago site)
The rules author will see the following items in the drop-down list when using the rule action Assign WFM Activity in a rule:
B.U. ACME: Billing B.U. ACME: Disputes Site Chicago: Address Changes Site Chicago: Disputes Site San Francisco: Billing Inquiries Site San Francisco: Disputes
In Configuration Server, Workforce Management Scripts must have a section called wfm. The table below lists the properties that you can specify for Workforce Management parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| wfmCfgServerApplName | Mandatory | Configuration Server application name for the WFM server. |
| wfmCfgServerUserName | Mandatory | Configuration Server user name. |
| wfmCfgServerPassword | Mandatory | Configuration Server password. |
| wfmServerUrl | Mandatory | URL of WFM Server. |
When configuring a new parameter of type “Workforce Management” under the Genesys Rules Development Tool, simply name the parameter and choose the WFM profile (script object just created) from the drop-down list. When the author is using this parameter, the GRAT will fetch the current list of WFM Activities from the WFM Server and display them to the rule author.
Calendar
Calendar parameters indicate to the GRAT that it should display a drop-down list of business calendars associated with the rule package being edited. The rule author can then choose one of the calendars.
Example: Calendar parameters can be used in a rule to dynamically assign a calendar as follows:
Assign business calendar "{businessCalendar}"
When defining a Calendar parameter, the template designer only needs to provide the parameter name and select a type of Calendar. There is no other configuration required.
Parameters Editor
The Parameters Editor allows you to create rule parameters, which are optionally used in rule conditions and actions. You can also map a parameter to a fact model by using the button. See Mapping Parameters to a Fact Model.
Each parameter contains the same fields in the Details section:
Name: A name for the parameter.
Description: A brief description of the parameter.
Parameter Names
The underscore (_) character in parameter names has a special meaning when building rule templates. It is used to specify an index of the parameter in circumstances where the rule expression requires additional instances of the parameter. The most common example is a range definition.
For example, suppose you need to create a condition which has to check if the task’s due date is in either the date1 to date2 range, or in the date3 to date4 range. You could create a condition such as:
Due is in "{dueDT1}" to "{dueDT2}" or in "{dueDT3}" to "{dueDT4}")
But this requires the definition of 4 parameters with type InputDate in the Parameters section. This approach can become inefficient, especially if there is more than one occurrence of the condition/action.
A better solution is to use the underscore and index approach:
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.
Categories of Parameter
The Configuration section contains information that is dependent on the parameter type. When a type is selected from the drop-down list, different fields are displayed that relate to that type.
There are eight main categories of parameters:
- Configuration Server
- Input Value
- Database
- Operational
- Select Enumeration
- Web Service
- Workforce Management
- Calendar
Configuration Server
Configuration Server parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Configuration Server parameter may be configured to pull a list of Agent Groups from the Configuration Server database. The list is populated from Configuration Server. Configuration Server parameters require you to select the Object type—Business Attribute, Business Context, List Object, or List— as described below:
Selecting Business Attribute prompts you to select the name of the Business Attribute from a list defined in Configuration Manager.
Selecting Business Context prompts you to enter the level of the Business Context that is of interest for this parameter. Here, Business Context refers to the level of the hierarchy under the Business Structure folder in Configuration Server.
Selecting List Object prompts you to select the List and Section values for the List Object from a user-defined set of List objects.
Selecting List prompts you to select from a predefined set of lists as shown below:
- Agent Groups
- Agent Skills
- Agents
- Extensions
- External Route Points
- Interaction Queue
- Media Types
- Place Groups
- Places
- Route Points
- Switch
- T-Server
- Virtual Route Points
Input Value
Input Value parameters are simply parameters for which the rules author can provide a value based on the defined parameter type (Boolean, Integer, Numeric, String, Date, or Time). These parameters can also be constrained. For instance, an integer value can be constrained to be within a defined range.
Matching Patterns
For Input Value parameters of type String, you can enter a matching pattern that must be followed. Enter a Javascript regular expression to define the matching pattern. For example, a Zip Code parameter might have the matching pattern:
>^\d{5}$|^\d{5}-\d{4}$
which represents a 5-digit zip code. A Phone Number parameter might have the matching pattern:
^\(?(\d{3})\)?[- ]?(\d{3})[- ]?(\d{4})$
which represents a 10-digit phone number in the format (xxx)-xxx-xxxx.
The regex pattern supported should conform to the browser's Javascript engine and may vary slightly depending on the browser version.
Custom Tooltips
Use Custom Tooltip allows you to enter useful tooltip text when defining all Input Value parameters (except for the Boolean parameter type, which does not need a tooltip). If you check Use Custom Tooltip, the text that you enter in the tooltip field is displayed in GRAT when this parameter is used in a rule condition or action. If you do not check Use Custom Tooltip, GRAT displays an automatically generated tooltip; for example, {age} is an integer between 1 and 99.
Database
Database parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Database parameter may be configured to pull a list of Order Types from a database. The list is populated by a database query. Database parameters require the Profile Name (the name of the Configuration Server Script object that contains your database connection information), Query Type (Single Value or List, depending on what you want to show up in GRAT), and the SQL Query to be executed.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example To use a Database parameter, a parameter profile must previously have been configured for the Tenant in Configuration Server. This is a Script object that specifies the JDBC driver, as well as the database url, username, and password required to perform the query. Refer to the Genesys Rules System Deployment Guide for information on configuring these profiles. The name of this Script object is used as the profile name for the database parameter.
To obtain values from the database, a valid SQL Select statement must be specified. For instance, to get all the values of a column use a select statement of the following form:
SELECT column_name FROM table_name
For dynamic Database parameters, you can configure the parameter so that both a name (an internal value that is included with a rule evaluation request) and a label (the information that is displayed to a rules author when authoring a rule that uses this parameter) can be retrieved from two different database columns.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| driver | Mandatory | The name of the jdbc driver to be used. For example, com.mysql.jdbc.Driver |
| url | Mandatory | The url for the database in the correct format for the jdbc driver to be used. |
| username | Mandatory | A valid username to connect to the database. |
| password | Mandatory | The password needed for the user to connect to the database. |
| initSize | Optional | The initial size of the connection pool. The default is 5. |
| maxSize | Optional | The maximum size of the connection pool. The default is 30. |
| waitTime | Optional | The maximum time (in milliseconds) to wait for obtaining a connection. The default is 5000. |
In general, the optional values do not need to be set or changed.
In GRDT, you can only configure database parameters with an SQL SELECT statement. Any other type of statement will fail when configured.
Operational
Operational parameters are created by users through Genesys Administrator Extension and, when deployed, are stored as options of Transaction objects of the type List in the Genesys Configuration Server Database. At rule execution time, when the Rules Engine evaluates a rule that contains an Operational parameter, it obtains the current value of the associated Transaction object option from Configuration Server. The rule developer determines from which Transaction object, and which option of that object, the value of the Operational parameter is fetched, and the rule author uses this parameter as part of a condition or action.
Example An Operational parameter called waitTimeThreshold may be defined. If a caller is waiting longer than this threshold for an available agent, some other action may be performed.
Instead of specifying a value for the threshold in the rule like the following:
When Caller’s wait time is greater than 30 seconds Then Offer a callback
the rule author could specify:
When
Caller’s wait time is greater than "{waitTimeThreshold}"
Then
Offer a callback
The value of "{waitTimeThreshold}" can be changed at any time by a user using Genesys Administrator Extension and will have an immediate effect without having to modify and redeploy a rule package.
For example, use the following condition when you define the mapping:
Queue(waitTime > "{waitTimeThreshold}" )
To configure an Operational parameter you need two IDs:
- The List ID, which corresponds to the name of the Transaction object in which the Operational parameter is stored
- The Parameter ID, which corresponds to the name of an option of that Transaction object.
The option value contains the actual value of the Operational parameter that is retrieved by the Rules Engine when the rule is evaluated. Operational parameters are always stored as Transaction objects of the type List, but the precise configuration of the options within that List object varies depending on how the Operational parameter was configured.
Refer to the Genesys Administrator Extension Help for general information about Operational parameters.
Select Enumeration
Select Enumeration parameters are linked with an Enumeration. This provides the rules author with a specific list from which to select.
Web Service
Web Service parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Web Service parameter may be configured to pull a list of stock symbols from an external web service. The list is populated by a Web Service query. Web Service parameters require the Profile Name (the name of the Configuration Server Script object that contains your web service connection information), Query Type (Single Value or List), and the XPath Query to be executed. In addition, Web Service parameters require that some Protocol Settings be entered, specifically the HTTP Method, Path, and the Message Body.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example Similar to a Database parameter, a parameter profile must also have been previously created. This profile will contain information such as the server’s address (host and port), the path to the service, and any other necessary HTTP settings. Refer to the Genesys Rules System Deployment Guide for information about configuring these profiles.
To obtain values from the service, a valid message for the service must be specified. This message must be constant. In other words, no variable substitution will occur.
Note: No message can be sent for HTTP GET requests. All the information in the request is provided through the query string and/or headers.
For instance, to obtain the weather forecast for San Francisco, the following request can be made to the Weather Underground REST service:
http://api.wunderground.com/auto/wui/geo/ForecastXML/index.xml?query=94129
However, this is the complete request. The host (api.wunderground.com) and the base path (/auto/wui/geo/ForecastXML/), must be specified in the profile.
To define a parameter to make this request, the profile name must reference the correct information described above. In addition, the Protocol Settings must specify GET as the method, along with index.xml?query=94129 as the path. No message is needed for this request.
To obtain values from the result, a valid XPath expression must be specified. The Web Service must return results in XML or JSON. Please see the XPath specification for more information on XPath expressions.
For example, to get the forecast highs from the previously described request, the following XPath expression may be used:
//high/fahrenheit/text()
In Configuration Server, Web Service Scripts must have a section called webservice. The table below lists the properties that you can specify for web service parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| host | Mandatory | The host for the service. |
| base_path | Mandatory | The base path to access the service. |
| protocol | Optional | The default is http. |
| port | Optional | The default is 80. |
| headers | Optional | Any custom HTTP headers that are needed for the service. |
| parameters | Optional | Any custom HTTP settings that are needed to tune the connection. |
In general, the parameters values do not need to be set or changed. Headers and parameters are lists in the following format:
key:value[,key:value]
You cannot specify headers or parameters that contain "," in the value. If you are sending a message to the service, it is expected that Content-Type is specified in the header since it defines the overall message interaction with the server. An optional charset can be included. For example, Content-Type:applicaton/json;charset=UTF-8.
In GRDT, the path for the parameter is added to the base_path in the script. For example, if the Script contains:
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
and the GRDT specifies:
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
then the message that is sent is:
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
This will return the week's highs in Fahrenheit:
81 77 81 81 83 85
Workforce Management
Workforce Management (WFM) parameters enable the rules author to select a value from a drop-down list of activities (a WFM database object that represents contact center tasks in which agents can be engaged) and multi-site activities (a collection of activities performed at multiple physical sites) that is dynamically retrieved from the Genesys Workforce Management Server. Workforce Management parameters require the WFM Profile (the Configuration Server Script object of type Data Collection).
Example: An activity is the main planning object that is used when building forecasts and schedules. An activity can be associated with an individual WFM Site object, or multi-site activities can be created at the WFM Business Unit level, which aggregates information from multiple "child" activities across multiple WFM Sites. So, when providing the rules author a list of WFM activities that are dynamically fetched from the WFM Server, the name of the WFM activity or multi-site activity is prefixed with the name of the WFM Site or the WFM Business Unit, respectively.
For example, if the WFM configuration has the following structure:
Business Unit with the name ‘ACME’
– Site with the name ‘San Francisco’ – Activity with the name ‘Disputes’ – Activity with the name ‘Billing Inquiries’ – Site with the name ‘Chicago’ – Activity with the name ‘Disputes’ – Activity with the name ‘Address Changes’ – Multi-Site Activity with the name ‘Billing’ (comprised of ‘Billing Inquiries’ from the San Francisco site and ‘Address Changes’' from the Chicago site) – Multi-Site Activity with the name ‘Disputes’ (comprised of ‘Disputes’ from the San Francisco site and ‘Disputes’ from the Chicago site)
The rules author will see the following items in the drop-down list when using the rule action Assign WFM Activity in a rule:
B.U. ACME: Billing B.U. ACME: Disputes Site Chicago: Address Changes Site Chicago: Disputes Site San Francisco: Billing Inquiries Site San Francisco: Disputes
In Configuration Server, Workforce Management Scripts must have a section called wfm. The table below lists the properties that you can specify for Workforce Management parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| wfmCfgServerApplName | Mandatory | Configuration Server application name for the WFM server. |
| wfmCfgServerUserName | Mandatory | Configuration Server user name. |
| wfmCfgServerPassword | Mandatory | Configuration Server password. |
| wfmServerUrl | Mandatory | URL of WFM Server. |
When configuring a new parameter of type “Workforce Management” under the Genesys Rules Development Tool, simply name the parameter and choose the WFM profile (script object just created) from the drop-down list. When the author is using this parameter, the GRAT will fetch the current list of WFM Activities from the WFM Server and display them to the rule author.
Calendar
Calendar parameters indicate to the GRAT that it should display a drop-down list of business calendars associated with the rule package being edited. The rule author can then choose one of the calendars.
Example: Calendar parameters can be used in a rule to dynamically assign a calendar as follows:
Assign business calendar "{businessCalendar}"
When defining a Calendar parameter, the template designer only needs to provide the parameter name and select a type of Calendar. There is no other configuration required.
Parameters Editor
The Parameters Editor allows you to create rule parameters, which are optionally used in rule conditions and actions. You can also map a parameter to a fact model by using the button. See Mapping Parameters to a Fact Model.
Each parameter contains the same fields in the Details section:
Name: A name for the parameter.
Description: A brief description of the parameter.
Parameter Names
The underscore (_) character in parameter names has a special meaning when building rule templates. It is used to specify an index of the parameter in circumstances where the rule expression requires additional instances of the parameter. The most common example is a range definition.
For example, suppose you need to create a condition which has to check if the task’s due date is in either the date1 to date2 range, or in the date3 to date4 range. You could create a condition such as:
Due is in "{dueDT1}" to "{dueDT2}" or in "{dueDT3}" to "{dueDT4}")
But this requires the definition of 4 parameters with type InputDate in the Parameters section. This approach can become inefficient, especially if there is more than one occurrence of the condition/action.
A better solution is to use the underscore and index approach:
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.
Categories of Parameter
The Configuration section contains information that is dependent on the parameter type. When a type is selected from the drop-down list, different fields are displayed that relate to that type.
There are eight main categories of parameters:
- Configuration Server
- Input Value
- Database
- Operational
- Select Enumeration
- Web Service
- Workforce Management
- Calendar
Configuration Server
Configuration Server parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Configuration Server parameter may be configured to pull a list of Agent Groups from the Configuration Server database. The list is populated from Configuration Server. Configuration Server parameters require you to select the Object type—Business Attribute, Business Context, List Object, or List— as described below:
Selecting Business Attribute prompts you to select the name of the Business Attribute from a list defined in Configuration Manager.
Selecting Business Context prompts you to enter the level of the Business Context that is of interest for this parameter. Here, Business Context refers to the level of the hierarchy under the Business Structure folder in Configuration Server.
Selecting List Object prompts you to select the List and Section values for the List Object from a user-defined set of List objects.
Selecting List prompts you to select from a predefined set of lists as shown below:
- Agent Groups
- Agent Skills
- Agents
- Extensions
- External Route Points
- Interaction Queue
- Media Types
- Place Groups
- Places
- Route Points
- Switch
- T-Server
- Virtual Route Points
Input Value
Input Value parameters are simply parameters for which the rules author can provide a value based on the defined parameter type (Boolean, Integer, Numeric, String, Date, or Time). These parameters can also be constrained. For instance, an integer value can be constrained to be within a defined range.
Matching Patterns
For Input Value parameters of type String, you can enter a matching pattern that must be followed. Enter a Javascript regular expression to define the matching pattern. For example, a Zip Code parameter might have the matching pattern:
>^\d{5}$|^\d{5}-\d{4}$
which represents a 5-digit zip code. A Phone Number parameter might have the matching pattern:
^\(?(\d{3})\)?[- ]?(\d{3})[- ]?(\d{4})$
which represents a 10-digit phone number in the format (xxx)-xxx-xxxx.
The regex pattern supported should conform to the browser's Javascript engine and may vary slightly depending on the browser version.
Custom Tooltips
Use Custom Tooltip allows you to enter useful tooltip text when defining all Input Value parameters (except for the Boolean parameter type, which does not need a tooltip). If you check Use Custom Tooltip, the text that you enter in the tooltip field is displayed in GRAT when this parameter is used in a rule condition or action. If you do not check Use Custom Tooltip, GRAT displays an automatically generated tooltip; for example, {age} is an integer between 1 and 99.
Database
Database parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Database parameter may be configured to pull a list of Order Types from a database. The list is populated by a database query. Database parameters require the Profile Name (the name of the Configuration Server Script object that contains your database connection information), Query Type (Single Value or List, depending on what you want to show up in GRAT), and the SQL Query to be executed.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example To use a Database parameter, a parameter profile must previously have been configured for the Tenant in Configuration Server. This is a Script object that specifies the JDBC driver, as well as the database url, username, and password required to perform the query. Refer to the Genesys Rules System Deployment Guide for information on configuring these profiles. The name of this Script object is used as the profile name for the database parameter.
To obtain values from the database, a valid SQL Select statement must be specified. For instance, to get all the values of a column use a select statement of the following form:
SELECT column_name FROM table_name
For dynamic Database parameters, you can configure the parameter so that both a name (an internal value that is included with a rule evaluation request) and a label (the information that is displayed to a rules author when authoring a rule that uses this parameter) can be retrieved from two different database columns.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| driver | Mandatory | The name of the jdbc driver to be used. For example, com.mysql.jdbc.Driver |
| url | Mandatory | The url for the database in the correct format for the jdbc driver to be used. |
| username | Mandatory | A valid username to connect to the database. |
| password | Mandatory | The password needed for the user to connect to the database. |
| initSize | Optional | The initial size of the connection pool. The default is 5. |
| maxSize | Optional | The maximum size of the connection pool. The default is 30. |
| waitTime | Optional | The maximum time (in milliseconds) to wait for obtaining a connection. The default is 5000. |
In general, the optional values do not need to be set or changed.
In GRDT, you can only configure database parameters with an SQL SELECT statement. Any other type of statement will fail when configured.
Operational
Operational parameters are created by users through Genesys Administrator Extension and, when deployed, are stored as options of Transaction objects of the type List in the Genesys Configuration Server Database. At rule execution time, when the Rules Engine evaluates a rule that contains an Operational parameter, it obtains the current value of the associated Transaction object option from Configuration Server. The rule developer determines from which Transaction object, and which option of that object, the value of the Operational parameter is fetched, and the rule author uses this parameter as part of a condition or action.
Example An Operational parameter called waitTimeThreshold may be defined. If a caller is waiting longer than this threshold for an available agent, some other action may be performed.
Instead of specifying a value for the threshold in the rule like the following:
When Caller’s wait time is greater than 30 seconds Then Offer a callback
the rule author could specify:
When
Caller’s wait time is greater than "{waitTimeThreshold}"
Then
Offer a callback
The value of "{waitTimeThreshold}" can be changed at any time by a user using Genesys Administrator Extension and will have an immediate effect without having to modify and redeploy a rule package.
For example, use the following condition when you define the mapping:
Queue(waitTime > "{waitTimeThreshold}" )
To configure an Operational parameter you need two IDs:
- The List ID, which corresponds to the name of the Transaction object in which the Operational parameter is stored
- The Parameter ID, which corresponds to the name of an option of that Transaction object.
The option value contains the actual value of the Operational parameter that is retrieved by the Rules Engine when the rule is evaluated. Operational parameters are always stored as Transaction objects of the type List, but the precise configuration of the options within that List object varies depending on how the Operational parameter was configured.
Refer to the Genesys Administrator Extension Help for general information about Operational parameters.
Select Enumeration
Select Enumeration parameters are linked with an Enumeration. This provides the rules author with a specific list from which to select.
Web Service
Web Service parameters give the rule author the ability to choose a single value from a drop-down list of values. For example, a Web Service parameter may be configured to pull a list of stock symbols from an external web service. The list is populated by a Web Service query. Web Service parameters require the Profile Name (the name of the Configuration Server Script object that contains your web service connection information), Query Type (Single Value or List), and the XPath Query to be executed. In addition, Web Service parameters require that some Protocol Settings be entered, specifically the HTTP Method, Path, and the Message Body.
Note: The list of values is fetched at the time the rules author logs into GRAT. If any values are updated from the external system after the user has logged into GRAT, the user must click the Logoff button and then log back in again to see any changes.
Example Similar to a Database parameter, a parameter profile must also have been previously created. This profile will contain information such as the server’s address (host and port), the path to the service, and any other necessary HTTP settings. Refer to the Genesys Rules System Deployment Guide for information about configuring these profiles.
To obtain values from the service, a valid message for the service must be specified. This message must be constant. In other words, no variable substitution will occur.
Note: No message can be sent for HTTP GET requests. All the information in the request is provided through the query string and/or headers.
For instance, to obtain the weather forecast for San Francisco, the following request can be made to the Weather Underground REST service:
http://api.wunderground.com/auto/wui/geo/ForecastXML/index.xml?query=94129
However, this is the complete request. The host (api.wunderground.com) and the base path (/auto/wui/geo/ForecastXML/), must be specified in the profile.
To define a parameter to make this request, the profile name must reference the correct information described above. In addition, the Protocol Settings must specify GET as the method, along with index.xml?query=94129 as the path. No message is needed for this request.
To obtain values from the result, a valid XPath expression must be specified. The Web Service must return results in XML or JSON. Please see the XPath specification for more information on XPath expressions.
For example, to get the forecast highs from the previously described request, the following XPath expression may be used:
//high/fahrenheit/text()
In Configuration Server, Web Service Scripts must have a section called webservice. The table below lists the properties that you can specify for web service parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| host | Mandatory | The host for the service. |
| base_path | Mandatory | The base path to access the service. |
| protocol | Optional | The default is http. |
| port | Optional | The default is 80. |
| headers | Optional | Any custom HTTP headers that are needed for the service. |
| parameters | Optional | Any custom HTTP settings that are needed to tune the connection. |
In general, the parameters values do not need to be set or changed. Headers and parameters are lists in the following format:
key:value[,key:value]
You cannot specify headers or parameters that contain "," in the value. If you are sending a message to the service, it is expected that Content-Type is specified in the header since it defines the overall message interaction with the server. An optional charset can be included. For example, Content-Type:applicaton/json;charset=UTF-8.
In GRDT, the path for the parameter is added to the base_path in the script. For example, if the Script contains:
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
and the GRDT specifies:
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
then the message that is sent is:
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
This will return the week's highs in Fahrenheit:
81 77 81 81 83 85
Workforce Management
Workforce Management (WFM) parameters enable the rules author to select a value from a drop-down list of activities (a WFM database object that represents contact center tasks in which agents can be engaged) and multi-site activities (a collection of activities performed at multiple physical sites) that is dynamically retrieved from the Genesys Workforce Management Server. Workforce Management parameters require the WFM Profile (the Configuration Server Script object of type Data Collection).
Example: An activity is the main planning object that is used when building forecasts and schedules. An activity can be associated with an individual WFM Site object, or multi-site activities can be created at the WFM Business Unit level, which aggregates information from multiple "child" activities across multiple WFM Sites. So, when providing the rules author a list of WFM activities that are dynamically fetched from the WFM Server, the name of the WFM activity or multi-site activity is prefixed with the name of the WFM Site or the WFM Business Unit, respectively.
For example, if the WFM configuration has the following structure:
Business Unit with the name ‘ACME’
– Site with the name ‘San Francisco’ – Activity with the name ‘Disputes’ – Activity with the name ‘Billing Inquiries’ – Site with the name ‘Chicago’ – Activity with the name ‘Disputes’ – Activity with the name ‘Address Changes’ – Multi-Site Activity with the name ‘Billing’ (comprised of ‘Billing Inquiries’ from the San Francisco site and ‘Address Changes’' from the Chicago site) – Multi-Site Activity with the name ‘Disputes’ (comprised of ‘Disputes’ from the San Francisco site and ‘Disputes’ from the Chicago site)
The rules author will see the following items in the drop-down list when using the rule action Assign WFM Activity in a rule:
B.U. ACME: Billing B.U. ACME: Disputes Site Chicago: Address Changes Site Chicago: Disputes Site San Francisco: Billing Inquiries Site San Francisco: Disputes
In Configuration Server, Workforce Management Scripts must have a section called wfm. The table below lists the properties that you can specify for Workforce Management parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| wfmCfgServerApplName | Mandatory | Configuration Server application name for the WFM server. |
| wfmCfgServerUserName | Mandatory | Configuration Server user name. |
| wfmCfgServerPassword | Mandatory | Configuration Server password. |
| wfmServerUrl | Mandatory | URL of WFM Server. |
When configuring a new parameter of type “Workforce Management” under the Genesys Rules Development Tool, simply name the parameter and choose the WFM profile (script object just created) from the drop-down list. When the author is using this parameter, the GRAT will fetch the current list of WFM Activities from the WFM Server and display them to the rule author.
Calendar
Calendar parameters indicate to the GRAT that it should display a drop-down list of business calendars associated with the rule package being edited. The rule author can then choose one of the calendars.
Example: Calendar parameters can be used in a rule to dynamically assign a calendar as follows:
Assign business calendar "{businessCalendar}"
When defining a Calendar parameter, the template designer only needs to provide the parameter name and select a type of Calendar. There is no other configuration required.
Functions Editor
Use the Functions Editor to develop Java methods that can be called from rule actions and conditions.
Each function contains the same fields:
Function Name—A name for the function.
Description—A brief description of the function.
Implementation—Either Java or Groovy.
Example
This function is used to compare dates. It would be configured as follows:
Name: compareDates
Description: This function is required to compare dates.
Implementation:
import java.util.Date;
import java.text.SimpleDateFormat;
function int _GRS_compareDate(String a, String b) {
// Compare two dates and returns:
// -99 : invalid/bogus input
// -1 : if a < b
// 0 : if a = b
// 1 : if a > b
SimpleDateFormat dtFormat = new SimpleDateFormat(“dd-MMM-yyyy”);
try {
Date dt1= dtFormat.parse(a);
Date dt2= dtFormat.parse(b);
return dt1.compareTo(dt2);
} catch (Exception e) {
return -99;
}
}
For user-supplied classes, the .jar file must be in the CLASSPATH for both the GRAT and the GRE.
Fact Model Editor
Contents
Use the Fact Model Editor to create and edit Fact Models and Events for the template. The Fact Model Editor is arranged as a standard master/details view. The master component displays defined facts and child properties for each fact and event.
Facts
To create a new fact, click in the Facts/Events pane of the Fact Model Editor. Each fact that is created in the editor contains the following fields:
- Name—A name for the fact.
- Description—A brief description of the fact.
- Sensitive—Determines whether the fact is logged when the Rules Engine evaluates facts. If this field is selected, the fact is not logged. If this field is cleared, the fact is logged.
- Properties—A list of properties values. Click Add, Edit, and Remove to update the list. Clicking Add or Edit opens a dialog box. This dialog box contains the following fields:
- Name—A name for the property.
- Type—The type of property. The property types are presented in a drop-down list. Each property type has an icon to indicate the type. This icon is displayed in the properties list beside the property name.
- Description—A description of the property.
- Sensitive—Determines whether the fact property is logged when the Rules Engine evaluates the fact. If selected, the fact property is not logged. If cleared, the fact property is logged.
Events
Event support is available for templates of type CEP where event support is declared when the template is created. Event support is not available for iWD-type templates.
To create a new event, click in the Facts/Events pane of the Fact Model Editor.
Each event that is created in the editor contains the following fields:
- Name—A name for the event.
- Description—A brief description of the event
- Sensitive—Determines whether the event is logged when the Rules Engine evaluates events. If this field is selected, the event is not logged. If this field is cleared, the event is logged.
- Properties—A list of properties values. Click Add, Edit, and Remove to update the list. Clicking Add or Edit opens a dialog box. This dialog box contains the following fields:
- Name—A name for the property
- Type—The type of property. The property types are presented in a drop-down list. Each property type has an icon to indicate the type. This icon is displayed in the properties list beside the property name.
- Description—A description of the property.
- Metadata—Determines the expiry date of the event
Fact Model Editor
Contents
Use the Fact Model Editor to create and edit Fact Models and Events for the template. The Fact Model Editor is arranged as a standard master/details view. The master component displays defined facts and child properties for each fact and event.
Facts
To create a new fact, click in the Facts/Events pane of the Fact Model Editor. Each fact that is created in the editor contains the following fields:
- Name—A name for the fact.
- Description—A brief description of the fact.
- Sensitive—Determines whether the fact is logged when the Rules Engine evaluates facts. If this field is selected, the fact is not logged. If this field is cleared, the fact is logged.
- Properties—A list of properties values. Click Add, Edit, and Remove to update the list. Clicking Add or Edit opens a dialog box. This dialog box contains the following fields:
- Name—A name for the property.
- Type—The type of property. The property types are presented in a drop-down list. Each property type has an icon to indicate the type. This icon is displayed in the properties list beside the property name.
- Description—A description of the property.
- Sensitive—Determines whether the fact property is logged when the Rules Engine evaluates the fact. If selected, the fact property is not logged. If cleared, the fact property is logged.
Events
Event support is available for templates of type CEP where event support is declared when the template is created. Event support is not available for iWD-type templates.
To create a new event, click in the Facts/Events pane of the Fact Model Editor.
Each event that is created in the editor contains the following fields:
- Name—A name for the event.
- Description—A brief description of the event
- Sensitive—Determines whether the event is logged when the Rules Engine evaluates events. If this field is selected, the event is not logged. If this field is cleared, the event is logged.
- Properties—A list of properties values. Click Add, Edit, and Remove to update the list. Clicking Add or Edit opens a dialog box. This dialog box contains the following fields:
- Name—A name for the property
- Type—The type of property. The property types are presented in a drop-down list. Each property type has an icon to indicate the type. This icon is displayed in the properties list beside the property name.
- Description—A description of the property.
- Metadata—Determines the expiry date of the event
Enumerations Editor
The Enumerations (Enums) Editor allows you to create and edit enumerations. An enumeration is a data type that consists of a set of named values that represent constants. Enumerations are useful for parameters that have a small number of possible values. For example, an enumeration of CustomerValue might be gold, silver, or bronze.
Each enumeration contains the same fields:
- Name—A name for the enumeration.
- Description—A brief description of the enumeration.
- Values—A list of possible values. Click Add, Edit, and Remove to update the list.
The value provided for the Name property corresponds to the value of the Fact property that must be provided in the Rules Engine as part of a rules evaluation request. The Name is case-sensitive.
The value provided for the Label property corresponds to what the rule author will see in GRAT, when they use a rule condition or action that includes a parameter of type Input Value, with an enumerated list of values.
For example, an enumerated list called CustomerSegment could be defined as follows:
| Name | Label |
|---|---|
| 101 | Bronze |
| 102 | Silver |
| 103 | Gold |
In this example the Name consists of digits only, so case-sensitivity is not an issue. For example, if the Name properties were bronze, silver, and gold then you must ensure that you enter in the exact value bronze as the Fact property in order for the rule to be evaluated as expected. If you enter in bronze, the rule will not return the result you are expecting.
Conditions Editor
The Conditions Editor allows you to create and edit rule conditions. Each condition contains the same fields:
- Name—The name of the condition. This is what will appear in the Project Explorer to identify the condition.
- Language Expression—The plain language expression of the condition that the rule author sees when constructing a business rule in the Rules Authoring Tool.
- Rule Language Mapping—The condition expressed in code. See Rule Language Mapping for more information.
When configuring conditions, parameters can be used in the Rule Language Mapping and Language Expression. For example, the Condition Age Range may be configured as follows:
- Name—Age Range
- Language Expression—Customer's age is between "{ageLow}" and "{ageHigh}"
- Rule Language Mapping—Customer(age >= '{ageLow}' && age <= '{ageHigh}')
In this example, {ageLow} and {ageHigh} are parameters.
Conditions in Linear Rules
For a linear rule, there is a maximum limit 6 columns of parameter data (including static text labels). So, for example, if your expression is:
Set customer data to: {parm1} and {parm2} and {parm3} and {parm4}
In this case, {parm4}, as the 7th parameter, will not be displayed. Reword your conditions to fit within these boundaries.
Actions Editor
The Actions Editor allows you to create and edit rule actions. Each action contains the same fields:
- Name—The name of the action. This is what appears in the Project Explorer to identify the action.
- Language Expression—The plain language description of the action that the rule author sees when constructing a business rule in the Rules Authoring Tool.
- Rule Language Mapping—The action expressed in code. See Rule Language Mapping for more information.
When configuring actions, parameters can be used in the Rule Language Mapping and Language Expression.
For example, the action Target Agent may be configured as follows:
- Name—Target Agent
- Language Expression—Target specific agent "{agent}"
- Rule Language Mapping— $Caller.targetAgent='{agent}'
In this example, {agent} is a parameter.
Actions in Linear Rules
For a linear rule, there is a maximum limit 6 columns of parameter data (including static text labels). So, for example, if your expression is:
Set customer data to: {parm1} and {parm2} and
{parm3} and {parm4}
In this case, {parm4}, as the 7th parameter, will not be displayed. Reword your actions to fit within these boundaries.
Rule Templates
Contents
There are a number of components that can be created in a rule template.
Actions and Conditions
Actions and conditions define WHEN/THEN scenarios, such as WHEN a customer is a Gold customer, THEN target the GoldAgentGroup. The WHEN statement is the condition, and the THEN statement is the action. A rule may have zero or more conditions, and one or more actions. This example also includes parameters: the status of the customer (Gold) and the name of the Agent Group (GoldAgentGroup).
Whenever a condition contains a rule language mapping that begins with eval(...), you must enclose the entire expression in parenthesis, as follows:
( eval(.... ) )
This will ensure it will compile properly when used with the NOT operator.
Enumerations
Enumerations are used to define lists of possible choices that will be displayed to the business rule author, when the author is creating rules that are based on the rule template. In some cases, the list of possible choices will be selected dynamically from Genesys Configuration Server objects or from external data sources. For WFM Activities and Multi-Site Activities, the list of possible choices is retrieved dynamically from the Genesys WFM Server. Thus, enumerations are used during definition of a discrete list of choices that will not change dynamically.
|+ DETAIL Enumerations Editor|
Fact Models
A fact model structures basic knowledge about business operations from a business perspective. A fact model focuses on logical connections (called facts) between core concepts of the business. It indicates what you need to know about the business operations in order to support (or actually do) those operations.
A good fact model tells you how to structure your basic thinking (or knowledge) about the business process based on a standard vocabulary. By using standard, business-focused vocabulary, it ensures that the business rules themselves can be well-understood by key stakeholders such as business analysts. For example, in your business you may have a Fact that represents a Customer, and another Fact that represents an Order.
The Customer could have fields such as name, age, location, credit rating, and preferred language. The Order may have fields such as order amount and order date. A rule could be constructed using these values such as:
When Customer is at least 21 years old and his order is > 100.00 then invite customer to participate in survey. |+ DETAIL Fact Model Editor|
Events
In release 8.1.2, in order to support Complex Event Processing, template developers need to be able to designate certain facts as events, and rules authors need to change the way that the DRL is generated when a fact is designated as an event.
So the fact model was enhanced to include events, and the fact model dialog now includes a Create Event button. An event has the following fields:
- Name
- Description
- An optional list of Properties.
- User-defined expiration metadata for the event
In GRAT, the @role meta-data tag determines whether we are dealing with a fact or an event. The @role meta-data tag can accept two possible values:
- fact—Assigning the fact role declares the type is to be handled as a regular fact. Fact is the default role.
- event—Assigning the event role declares the type is to be handled as an event.
Functions
Functions are used to define elements other than Conditions and Actions. The Functions editor enables you to write specific Java functions for different purposes for use in rule templates. The specified functions may then be used in the rule language mappings (see Rule Language Mapping).
When the rule templates are created, the rule developer publishes them to the Rule Repository, making them available in the GRAT for business users to create rules.
Actions and conditions can contain parameters. Various types of parameters are supported. Refer to the Genesys Rules Development Tool Help for detailed information about creating parameters in the Genesys Rules Development Tool, including examples of parameters.
Certain dynamic parameter types that refer to external data sources require a Profile to be selected. The Profile is defined as a Script object of Data Collection type, and it provides connection information that enables the GRAT to retrieve this dynamic data from the external data source. The next sections describe how to configure Profiles for database, Web Service, and Workforce Management parameters. |+ DETAIL Functions Editor|
Database Parameters
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| driver | Mandatory | The name of the jdbc driver to be used. For example, com.mysql.jdbc.Driver |
| url | Mandatory | The url for the database in the correct format for the jdbc driver to be used. |
| username | Mandatory | A valid username to connect to the database. |
| password | Mandatory | The password needed for the user to connect to the database. |
| initSize | Optional | The initial size of the connection pool. The default is 5. |
| maxSize | Optional | The maximum size of the connection pool. The default is 30. |
| waitTime | Optional | The maximum time (in milliseconds) to wait for obtaining a connection. The default is 5000. |
In general, the optional values do not need to be set or changed.
In the Genesys Rules Development Tool, you can only configure database parameters with an SQL SELECT statement. Any other type of statement will fail when configured. |+ DETAIL Parameters Editor|
Web Service Parameters
In Configuration Server, Web Service Scripts must have a section called webservice. The table below lists the properties that you can specify for web service parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| host | Mandatory | The host for the service. |
| base-path | Mandatory | The base path to access the service. |
| protocol | Optional | The default is http. |
| port | Optional | The default is 80. |
| headers | Optional | Any custom HTTP headers that are needed for the service. |
| parameters | Optional | Any custom HTTP settings that are needed to tune the connection. |
In general, the parameters values do not need to be set or changed. Headers and parameters are lists in the following format:
key:value[,key:value]
| Warning: | You cannot specify headers or parameters that contain "," in the value.
Warning: If you are sending a message to the service, it is expected that Content-Type is specified in the header since it defines the overall message interaction with the server. An optional charset can be included. For example, Content-Type:applicaton/json;charset=UTF-8. |
In the Genesys Rules Development Tool, you have to completely define the message to be sent and it must be constant. No variable substitution is done. The XPath Query is used to pull values out of the response from the server. The response must be in XML or JSON, otherwise this will not work. A valid XPath query for the response must be specified. This depends entirely on the service you interface with.
| Note: | The message is sent to the server only once per session. This is done both for performance reasons and because the values in the response are expected to be relatively constant. |
In the Genesys Rules Development Tool, the path for the parameter is added to the base_path in the script.
For example:
If the Script contains:
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
and the GRDT specifies:
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
then the message that is sent is:
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
This will return the week's highs in Fahrenheit:
81 77 81 81 83 85
Workforce Management Parameters
In Configuration Server, Workforce Management Scripts must have a section called wfm. Table 4 lists the properties that you can specify for Workforce Management parameters.
|
Property |
Mandatory/optional |
Description |
|---|---|---|
| wfmCfgServerApplName | Mandatory | Configuration Server application name for the WFM server. |
| wfmCfgServerUserName | Mandatory | Configuration Server user name. |
| wfmCfgServerPassword | Mandatory | Configuration Server password. |
| wfmServerUrl | Mandatory | URL of WFM Server. |
When configuring a new parameter of type “Workforce Management” under the Genesys Rules Development Tool, simply name the parameter and choose the WFM profile (script object just created) from the drop-down list. When the author is using this parameter, the GRAT will fetch the current list of WFM Activities from the WFM Server and display them to the rule author. |+ DETAIL Parameters Editor|