Rule Templates
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.
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.
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 has been enhanced in release 8.1.2 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.
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.
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.
Custom Templates
Creating a Custom Template
Procedure
- Start the Genesys Rules Development Tool.
- To open the Template Development perspective (if not already opened); go to Window > Open Perspective > Template Development.
- Select File > New > Rule Template Project.
- Click Next.
- On the Rule Template Project screen of the New Rule Template Project dialog, enter a name for the template project and select the Eclipse workspace where the project files will be stored.
- Click Next.
- On the Template Properties screen, for the Type property, select iWD.
- For the Tenant property, select the Configuration Server tenant to which this rule template will be associated.
- Click Finish.
The custom rule template is displayed in the Eclipse Project Explorer view.
Next Steps
After parameters, conditions, actions, and functions are created as necessary for the custom rule template, you must publish it to the Genesys Rules System rules repository. See steps 8-15 of Importing the iWD Standard Rules Template into the Genesys Rules Development tool and publishing it to the Rules repository.
Custom Rule Template Conditions and Actions
Language Expression Syntax
If a rule action Language Expression contains one or more parameters, the expression must terminate with one of those parameters. For example, the following Language Expression for a rule action generates an error:
Set Priority "{priority}" and update
whereas, the following Language Expression is valid:
Set and Update Priority "{priority}"
Using iWD Lookup Tables in Rules
The Genesys Rules System offers several ways to create rule parameters that will present an enumerated list of items to the rules author as a drop-down list. However, there are certain situations, in which you might want to use a Lookup Table that has been configured in iWD Manager, as the basis for a dynamic rule parameter. This might be valuable because Lookup Tables provide user-friendly name/label pairs that can be changed easily by a business user, while some other types of dynamic parameters, such as List Objects in Configuration Server, cannot be edited easily by a business user. If you want to use a Lookup Table in a rule parameter, it will be a parameter of type database, where the database being read is the iWD configuration database. The best way to create a new rule parameter that will look up values from an iWD Manager Lookup Table is to use an existing parameter as an example. For example, in the iWD Standard Rules Template, you can look at the taskChannels rule parameter and, in the ACME Rules Template, you can look at the ACMEproduct parameter.
Using the ACMEproduct parameter as an example, we can see that the SQL query that is executed will read data from several tables in the iWD configuration database:
SELECT cmc_lookup_attr_entry.valueKey,cmc_lookup_attr_entry.valueLabel FROM ((cmc_lookup_attr_entry INNER JOIN cmc_lookup_attr_type ON cmc_lookup_attr_entry.attributeTypeId=cmc_lookup_attr_type.id) INNER JOIN cmc_tenant ON cmc_lookup_attr_type.tenantId=cmc_tenant.id) WHERE cmc_lookup_attr_type.name='Products' AND cmc_tenant.name='ACME';
In this example, the only parts of the query that would need to change are the name of the Lookup Table, which is referenced in the query as cmc_lookup_attr_type.name, and the name of the tenant, which is referenced in the query as cmc_tenant.name. If the Lookup Table is configured under the System tenant, then the cmc_tenant.name would be set to System in the query.
Operational Parameters
Operational parameters provide another user-friendly way to make rules dynamic, enabling a business user to change a dynamic value that will be referenced in a rule, without having to change the rule itself. Operational parameters are a special type of parameter that is 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 Genesys 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 should be fetched, and the rule author uses this parameter as part of a condition or action.
For example, an operational parameter might be called waitTimeThreshold. If a caller is waiting longer than this threshold for an available agent, perhaps some other action will 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 that is using Genesys Administrator Extension and this action will have an immediate effect without the user having to modify and redeploy a rule package.