Summary
In order for rules to be invoked by Genesys applications, you must deploy the rule package to one or more Genesys Rules Engines (or for Genesys Web Engagement, to the GWEB backend server). The deployment process (whether you choose to deploy immediately or to schedule the deployment for later) attempts to compile the rule package and informs you of the result via the Deployment Pending pop-up message. You can check on the status of your deployment by looking at the Deployment History tab, which shows the status Pending. When deployment is in pending status, you will not be able to cancel or undo it.
This process enables you to correct any errors before deployment. In addition, if you attempt a deployment that would duplicate either;
- An already scheduled deployment or;
- An attribute of an already scheduled deployment, such as;
- The same rule package
- For the same snapshot
- For the same destination server/cluster
an appropriate message is displayed. You can then either change the attributes of your deployment, or go to Deployment History and change/delete the scheduled deployment.
To use the deployment screen, you must have deploy permissions set up in Genesys Administrator.
To deploy a rule package:
- Select the Tenant to which the rule package belongs from the drop-down list.
- In the Explorer Tree, select the name of the rule package.
- Under the rule package, select Deploy Rules. (The number of rules as yet not included in a snapshot appears in parentheses.) The Details Panel contains two tabs:
- The Outstanding Deployments tab allows you to select from a list of snapshots of the package including the LATEST version of the package (if configured by an administrator), create a new snapshot, export a snapshot (as an XML file downloadable to the user’s local file system), delete a snapshot, deploy the rule package, schedule a deployment to occur at a future time, and show the source of the package. (Show Package Source displays the actual contents of the package snapshot you are deploying. The fact model, calendar definitions, and rule definitions will be coded into the rule language and displayed.)
Even if Run as Background Task is checked, the package will first be built and validated to ensure there are no errors. Once the validation is successful, the snapshot will be queued to a background task.
You cannot delete the LATEST snapshot, and you cannot delete a snapshot for which there is a scheduled deployment.- The Deployment History tab shows details about when the package snapshot was deployed in the past, and by whom. Failed deployments also appear in the list. In addition, the Deployment History displays scheduled deployments, and allows you to cancel or change the schedule of upcoming deployments.
To deploy the package immediately:
- Select the package snapshot, or the LATEST version (if available).
- Click Deploy Now in the Outstanding Deployments tab.
- Select the Location to which the package snapshot will be deployed. Locations can include application clusters configured in Genesys Administrator, or the GWEB backend server for Genesys Web Engagement.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Deploy.
A message will be displayed indicating whether the deployment was successful.
To deploy the package later:
- Click Schedule Deployment in the Outstanding Deployments tab.
- Select the Location (the name of the Rules Engine application or application cluster, or the GWEB backend server for Genesys Web Engagement) to which the package snapshot will be deployed.
- Enter the date and time you would like the package snapshot to be deployed.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Schedule.
A message will be displayed indicating whether the deployment was successfully scheduled.
If you wish to reschedule a previously scheduled deployment, or wish to cancel a scheduled deployment, you may do so from the Deployment History tab.
To refresh the display of a deployment history, click the Refresh button, or click in the relevant node in the Explorer Tree.
To display details of a deployment to a cluster:
If you are deploying to a cluster, you can now display a detailed report of the deployment, whether it succeeded or failed. This gives useful information on how a deployment has progressed: you can see, for example, whether a server connection was temporarily down at a critical moment, or whether a server timeout setting might need to be changed.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. Each GRE downloads the new rule package and compiles it.
- Phase 2 - (Commit) Once all GREs have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
To show the report:
- Click on the Failed/Successful link in the Status column.
- The details of each deploy action to each server in the cluster are displayed, including:
- The GRE Server Name
- The server status
- The success or error message generated by the server
- The Phase 1 (and Phase 2) deployment times in seconds
Rule packages are bundles of rules. Rule packages are used to group, manage, and deploy rules. The rules in a rule package provide a set of functionality (like an iWD solution). The Genesys Rules Authoring Tool (GRAT) allows you to create, edit, and delete rule packages.
Rule packages provide the following capabilities:
- The ability to partition rules and facts so that they are small, well-defined, and apply only to a particular application or use. This makes them easier to debug and understand. The fact model is a description of the data. It contains field names and types which are grouped into tables/classes. Facts are input/output to rule execution and are instances of the tables/classes defined in the fact model.
- The ability to isolate rule packages from one another when executing rules. This also improves performance because the Rules Engine has fewer candidates to examine during the evaluation.
- The ability to update individual rule packages without affecting other deployed packages.
- The ability to import and export an entire rule package containing the rule definitions, business calendars, and also the templates that the rule package is dependent on.
- A rule package contains one or more rules plus the fact model that is needed to support the rules. You deploy rule packages individually to the Rules Engine.
When you select an existing rule package in the Explorer Tree, four tabs are displayed in the Details Panel:
- The General tab displays the basic information for the rule package, such as name, type, and the associated templates.
- The Rules tab allows you to create, edit, and view rules. When you click the rule package node and then the Rules tab, you can create, edit and view rules at the global level for that package. Clicking on the other nodes (which represent various business contexts) enables you to modify the rules defined for that specific business context.
- The Audit Trail tab allows you to view the history of the individual rules, such as when they were updated or deployed, and by whom.
- The Package History tab allows you to view the history of a package and its versions and snapshots, including changes to rules, templates, calendars, test scenarios, imports/exports and deployments. History for all packages across one tenant can also be displayed at the tenant level.
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 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.
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.
When rule developers create the conditions or actions in a rule template, they enter the rule language mapping. Up to and including Genesys Rules System 8.1.2, the 5.1 Drools Rule Language is used. Details of this can be found here:
http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-expert/html/ch04.html
However, for use in JBOSS environments, you should reference the 5.2 version here:
http://downloads.jboss.com/drools/docs/5.2.FINAL/drools-expert/html/ch05.html
For GRS 8.1.3 and higher, use the 5.5 versions, found here:
http://downloads.jboss.com/drools/docs/5.5.FINAL/drools-expert/html/ch04.html
Because URLs change frequently, search the Drools web site for the Drools Expert User Guide, and then look at the table of contents of that guide for the information on the Drools Rule Language.
The rule language mapping is not visible to the business user when they are authoring rules in the Genesys Rules Authoring Tool. Instead, the rule authors will see the Language Expression that the rule template developer enters. The language expression is a plain-language description that uses terminology that is relevant to the business user, instead of low-level code. Rule language mapping is provided in the examples in the following section.
Language Expressions
When building a rule template in GRDT, the Language Expression cannot use the open or closed parenthesis character. For example, the expression:
More than {parCallLimit} calls within {parDayLimit} day(s)
will result in an error when you try to save the rule in GRAT. But if you want the business user to see a parenthesis in GRAT, you can use backslash characters in your Language Expression. For example:
More than {parCallLimit} calls within {parDayLimit} day\(s\).
HTML Constructs
For security reasons, GRAT does not allow any HTML commands to be entered as parameters of a rule. For example, if a condition is:
Customer requests a callback on {day}
and {day} is defined as a string, we would not allow a rule author to enter the string:
Customer requests a callback on ‹b›Tuesday‹/b›.
All HTML constructs will be removed from the string. This applies to string parameters as well as dynamic list parameters such as business attributes, database or web service.
Rule Templates are created as Projects in GRDT. The New Project Wizard is used to create new templates.
New Project Wizard
The New Project Wizard guides you through the steps to create a new Rule Template Project. This wizard can be accessed in the following ways:
- Select File > New > Rule Template Project from the menu bar.
- Right-click within the Project Explorer and select New > Project from the context-sensitive menu.
The wizard leads you through the following steps:
- The first screen prompts you to select which wizard you need that is, which type of project you wish to create. If it is not already selected, navigate to Genesys Rules System > Rule Template Project and click Next.
- Enter a name for the new template project. Template names must be unique within a tenant. Either use the default location, or clear the check-box and select a new location. Click Next.
- Verify the type of template you are creating in the drop-down list. The default template type is Stateless. To create an iWD template, select iWD. To create a template for Genesys Web Engagement, select type CEP.
- Click the Configure Types link to create new template types or maintain existing ones.
- Use the Enable event support check box to indicate whether the template will support events. In templates that support events, the Fact Model editor can be used to create both facts and events.
- Select the appropriate Tenant, and enter a description of the template.
- Click Finish. The new template project will now appear in the Project Explorer.
Editing and Configuring Rule Templates
Once it is created, the rule template appears in the Project Explorer. Expanding the template displays a list of components that can be configured. Double-click the component type in the Project Explorer to open the appropriate Editor and begin configuring components.
Renaming Rule Templates
Renaming rule templates does not change the name within the repository. When you publish the renamed rule template, it will be added to the repository as a new template, and the template with the old name will still exist.
You can rename your template by right-clicking the template in the Project Explorer and selecting Rename from the context-sensitive menu, by selecting the template and navigating to File > Rename, or by selecting the F2 key on your keyboard. Many features can be accessed in similar ways.
Copying Rule Templates
Existing rule templates can be copied to be used as a basis for a new template. Right-click the template in the Project Explorer, and select Copy. As with renaming, there are multiple ways to access the Copy functionality, such as the Ctrl + C keyboard shortcut, Edit > Copy, and so on.
Deleting Rule Templates
Rule templates can be deleted using the GRS Server Explorer, provided that:
- The user has rule template delete permissions, and;
- The rule is not used in any rule package.
GRS Overview
These pages give a high-level overview of how the Genesys Rules System operates within the Genesys eco-system. Start here for an introduction to basic components, elements and architectures of the GRS functionality.
For a worked example of creating a rule for a VXML client to send rule evaluation requests to the Genesys Rules Engine, please click here
.
GRS provides the ability to develop, author, and evaluate business rules. A business rule is a piece of logic defined by a business analyst. These rules are evaluated in a Rules Engine based upon requests received from client applications such as iWD, Conversation Manager and Genesys Proactive Engagement.
Components
GRS consists of three software components:
Genesys Rules Development Tool (GRDT) is an Eclipse plug-in that allows advanced users (business rules developers) to create templates that define the discrete rule conditions and actions that will comprise the rules. Each rule condition and action includes the plain-language label that the business rules author will see, as well as the rule language mapping that defines how the underlying data will be retrieved or updated. For each rule condition and action, the template developer decides what kind of data the rules author will be providing. Some examples include whether the input should be an integer value, a non-integer numeric value, a string, a selection from a pre-defined list, or a selection from a dynamic list.
Genesys Rules Authoring Tool (GRAT) is a browser-based application used by business analysts to create and edit packages of business rules based on the templates created in the Genesys Rules Development Tool.
Genesys Rules Engine (GRE) evaluates the rule packages (groups of rules). Rule packages are deployed to the Rules Engine by the Rules Authoring Tool. When a rule package has been deployed, Genesys applications will be able to request the Rules Engine to evaluate the logic that is defined in this rule package.