Jump to: navigation, search
Important
Decision tables can have a maximum of 30 columns.

Follow these steps to create a new decision table:

  1. Navigate to the rule package to which the new decision table will belong in the Explorer Tree (verify that you have selected the correct Tenant from the Tenant drop-down list). Navigate to the correct node of the business structure under the rule package, which will define the node at which your decision table will be created. If you create the decision table at the rule package level, it will be a global rule. Select the node in the Explorer Tree and click on the Rules tab.
  2. Click New Decision Table.
  3. In the Rule Summary, the ID field is populated automatically. It cannot be edited.
  4. Enter a Name for the decision table (for example, Status).
  5. Enter a brief Description for the rule (for example, Adjust the priority, depending upon the customer's status).
  6. Select the Phase at which this rule will be applied (classification, prioritization, or archiving for iWD. Refer to the Genesys Rules System Deployment Guide for more information about phases).
  7. Select the Business Calendar to use with this rule (optional).
  8. Enter a Start Date and an End Date for the rule (optional). If the End Date is earlier than the current date, the rule is marked with a flag (Grs auth-tool flag.gif ) to indicate that the rule is out of date.
  9. Use the up and down arrows in the far right-hand column to control the ordering of the decision table rows. In some complex cases, rules can be designed so that multiple rows will evaluate as true. In this case, the order of the rows becomes important, so in release 8.5.0 you can re-order the rows when creating and editing a decision table.
    Important
    By default, up to release 8.5.0, rules were executed from the bottom up. In release 8.5.0, your system administrators can configure rule execution to be "bottom-up" or "top-down". The Rule Evaluation Order indicator at the bottom of the screen shows you which of these is selected, and a ToolTip is available when you hover your cursor over this indicator. Any changes made to this configuration will apply dynamically, but only take effect after a restart or a browser refresh.
  10. Add Conditions and Actions in the lower panel.
    Important

    In release 8.5.001, you can now use a wildcard symbol (*) in row data in a decision table (if the feature is configured by administrators). The wild card indicates that, for this row, the value for the parameter where it is used is unimportant and not to be evaluated. A wildcard selection now appears at the top of all lists, regardless of whether they are enumerations, business attributes, Configuration Server, database, and so on. In the case of numeric parameters, you must type in the wildcard value—GRAT now accepts that as a valid number field. For any condition that contains one or more wildcards, its evaluation will not be considered in the rule logic. There are some restrictions:

    • The wildcard values will work only for strings and numeric fields—fields of type date, time and Boolean are not supported.
    • Wildcard values are "all or nothing" for conditions with multiple parameters. For example:
    Customer age is between 40 and 60
    is ONE condition, and it will be excluded for that row if one or more of the fields contains a wildcard value.
    1. Select one or more Conditions from the list (for example, a condition for this scenario might be named Customer's age is ...).
    2. Select one or more Actions from the list (for example, an action for this scenario might be named Increase priority by xxx).  
    3. Insert values for the parameters into the table under the Condition and Action columns. Depending on how the parameters were configured by the rule template developer in GRDT, there may be constraints on the values that can be entered.
    4. Repeat Step c, adding more condition and action values.
    5. Re-order the rows as appropriate.
  11. Click Validate to validate the syntax of the linear rule.
  12. Click Save to save your changes.
Important
When you make any modifications to the body of a rule, you "lock" the rule, which prevents others from being able to make changes to the same rule at the same time. The unsaved icon Grs auth-tool unsaved.gif will appear on the rule summary to alert you that you need to save your changes. For any other user, the locked icon Grs auth-tool lock.gif appears on the rule summary and the Save and Cancel buttons are disabled. In addition, other users are unable to make changes to the rule because it is marked "read only".
Important
When editing rules, be careful not to clear your browsing history or cookie data, as this might cause the rule to be stuck in a locked state. Unsaved changes could be lost.
Important
The Pending Snapshot field indicates whether any snapshot of this rule has yet been created. See Deploying Rule Packages for information on snapshots.

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:

  1. Select the Tenant to which the rule package belongs from the drop-down list.
  2. In the Explorer Tree, select the name of the rule package.
  3. 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.)
Important
When you create a snapshot, you can choose to check the Run as Background Task option. For very large rule packages, it can take a long time to create a snapshot. When this option is checked, this operation will be completed in the background. This allows you to do other things or log off. When the snapshot is complete, it appears under Package Snapshots.

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:

  1. Select the package snapshot, or the LATEST version (if available).
  2. Important
    The LATEST version is available only if configured in Genesys Administrator. Your organization may choose not to make it available because its contents may vary over time, for example between scheduled deployments.
  3. Click Deploy Now in the Outstanding Deployments tab.
  4. 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.
  5. Enter some comments about the deployment (these will appear in the Deployment History).
  6. Click Deploy.

A message will be displayed indicating whether the deployment was successful.

To deploy the package later:

  1. Click Schedule Deployment in the Outstanding Deployments tab.
  2. 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.
  3. Enter the date and time you would like the package snapshot to be deployed.
  4. Enter some comments about the deployment (these will appear in the Deployment History).
  5. 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.

Important
When deploying to a cluster, GRAT uses a two-phase commit protocol to ensure that all GRE nodes running in the cluster are running the same version of the deployed rule package. If any of the nodes in the cluster fails during Phase 1, the Phase 2 is not committed.
  • 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.
The Deployment Status shows the detail of each node in the cluster and whether or not any errors occurred.

To show the report:

  1. Click on the Failed/Successful link in the Status column.
  2. 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
Important
The time zone for scheduled deployments is always the time zone of the server on which the Genesys Rules Authoring Tool is installed.

New Features by Release

New in Release 8.5.001


Support for Conversation Manager Template and Rules Package

This release contains a new Conversation Manager template and a rules package that make it much easier and quicker for Conversation Manager customers to develop and implement their own solutions. The Conversation Manager Template provides a tighter integration between the Conversation Manager objects like Customer Profile, Service, State and Task and the Genesys Rules System, allowing you to move key business decisions into rules instead of application logic.

The template can be imported directly into GRAT and requires no modification in GRDT. Please see the Conversation Rules Template Guide for more information.


Support for Wildcards in Decision Tables

You can now use a wildcard symbol (*) in row data in a decision table (if the feature is configured by administrators). The wild card indicates that, for this row, the value for the parameter where it is used is unimportant and not to be evaluated. A wildcard selection now appears at the top of all lists, regardless of whether they are enumerations, business attributes, Configuration Server, database, and so on. In the case of numeric parameters, you must type in the wildcard value—GRAT now accepts that as a valid number field. For any condition that contains one or more wildcards, its evaluation will not be considered in the rule logic.

There are some restrictions/caveats for this solution.

  • The wildcard values work only in decision tables.
  • The wildcard values will work only for strings and numeric fields—fields of type date, time and Boolean are not supported.
  • Wildcard values are "all or nothing" for conditions with multiple parameters. For example:
Customer age is between 40 and 60

This is ONE condition, and it will be excluded for that row if one or more of the fields contains a wildcard value.

The screenshot below shows the wildcard being used in a Decision Table.

  • In DTR-112, the media type is not considered in evaluating the rule.
  • In DTR-113, the Customer segment, media type and active service conditions are not considered. This rule catches any interactions not trapped by the rules above it, and directs them to the BS_General skill group.

DT3.png

See also GRAT Configuration Options.


Enhanced Rule Reporting

In this release, you can now configure a new option in GRE—include-disqualified-rules-in-response—to report disqualified rules (rules that did not fire), conditions that evaluated false and rule evaluation time back to the REST client invoking the rule evaluation request. Before 8.5.001, only the results of rules that fired were returned.

This feature is part of is part of a larger planned feature to enable Rule Simulation (what-if scenarios using real historical data).

See also GRAT Configuration Options.


iWD's Business Context Management Service (BCMS) Functionality Moves to GRE

Most of the BCMS functionality of intelligent Workload Distribution is now moved into the Genesys Rules Engine. As a result, iWD 8.5.0 users must install GRS 8.5.001 as a prerequisite.



Help Content Moves to the Cloud

The content of GRAT Help topics is now delivered into the user session directly from the Genesys documentation website at docs.genesys.com. Where such access is not possible, users can configure the location of this Help to a URL within their firewall. A new configuration option controls this. See GRAT Configuration Options.

Help for GRDT remains in WebHelp format.

New in Release 8.5.0


Deployment Enhancements

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. The Status column now displays a Failed/Successful link, which you can click to display the details of each deploy action to each server in the cluster. These details include:

  • GRE Server Name
  • Server status
  • Success or error message generated by the server
  • Phase 1 (and Phase 2) execution times in seconds

See Deploying Rules Package for more context.


Decision Table Enhancements

You can now easily reorder the rows within a decision table. By default, up to release 8.5.0, rules were executed from the bottom up. In release 8.5.0, your system administrators can configure rule execution to be "bottom-up" or "top-down". The Rule Evaluation Order indicator at the bottom of the screen shows you which of these is selected, and a ToolTip is available when you hover your cursor over this indicator. Any changes made to this configuration will apply dynamically, but only take effect after a restart or a browser refresh. A new configuration option (evaluate-decision-table-rows-top-down) allows the administrator to set the order of evaluation (top to bottom or bottom to top). See Settings in GRAT in GRS Configuration Options. See also Creating Decision Tables for more context.


Operational Parameter Performance Enhancements

A new caching mechanism is in place to enable better performance when using operational parameters within rules. Three new configuration options control this functionality:

  • cache-operational-parameters
  • parameter-cache-timeout
  • clear-cache-on-disconnect

See Settings in GRE in GRS Configuration Options.


Repository Performance Enhancement for Oracle 11 users

For Oracle users, a performance enhancement is available that is enabled only when you create a new database repository when either initially installing, or migrating to, 8.5.0. For more detail, go to the Migration to 8.5.0 page.


Java runtime changes

GRAT requires the Java JDK during installation, but no longer requires it once it is deployed and running in an application server such as Tomcat, JBOSS or IBM WebSphere.


Single Sign-On

GRAT now participates in the Genesys Single Sign-On (SSO) framework where deployment takes place to a Genesys Engage cloud SSO environment. When GRAT is deployed into this environment, GRAT users will log in once to the portal. If they choose GRAT, they will bypass the GRAT login screen if they are still authenticated. Note that this feature does not apply for Genesys on-premise customers deploying GRS. Some additional configuration options have been implemented to support this feature. Go to Deploying GRAT in Genesys Administrator for more information.


Support for Internet Explorer 10 and 11


Discontinued support

In this release the following are no longer supported:

  • Oracle 10
  • Internet Explorer 7

This page was last edited on September 18, 2020, at 13:49.
Comments or questions about this documentation? Contact us for support!