New Features by Release

New in 8.5.303

---

Undeploy a Rules Package

You can now undeploy a specific rules package from a single GRE or cluster.

A new Undeploy button has been added to the Outstanding Deployments tab for users with the PACKAGE_UNDEPLOY role privilege. Such users can now select a target GRE or cluster and undeploy a package from that location/cluster. Deployment history will display the undeployment.

Flow summary

Partial undeployment

Partial undeployment—the mirror of partial deployment—is also supported. A new configuration option—allow-partial-cluster-undeployment—which is a mirror to the existing allow-partial-cluster-deployment has been introduced.

If this option is set to true, the undeployment request is applied to "active" nodes and the rule package is undeployed. When the inactive GRE node(s) come back online or are re-connected and auto-synchronization is enabled, they will auto-synchronize and undeploy the rule packages automatically. If one or more (but not all) nodes are inactive, the status is set to Partial.

If this option is set to false, then GRAT undeploys the rule package only if all nodes of the cluster are active. If not, it is reported as a Failed status and the rule package is not undeployed from any node.

Changes to GRAT Help

See Deploying a Rules Package for more details.

Limitation

Important

The Undeploy feature is not available for the Genesys Web Engagement rules engine or for rules packages that are based on the Complex Event Processing (CEP) template.

---

Automated snapshots on deployment

GRAT can now be configured to take snapshots automatically at deployment. In the Deploy and Schedule Deployment dialogs, a Create snapshot to deploy check box is now displayed for the LATEST version only of a rules package, for users with DEPLOY and CREATE_SNAPSHOT permissions.

There are some changes to the operation of the configuration option force-snapshot-on-deployment as a result:

• If the value of this option is false, the Create snapshot to deploy checkbox is displayed unchecked and enabled and users with the above permissions can select it.
• If the value of this option is true, the Create snapshot to deploy checkbox is displayed checked and disabled and the snapshot is created and deployed automatically. In the case of scheduled deployments, the snapshot is created immediately and deployed at the scheduled time.

---

Business Calendar Rule Priority

Calendar exceptions can now be assigned a priority order to ensure that no clashes occur between exceptions. Now, for any exception that affects the same day as another exception, the topmost exception takes precedence. User can now also move calendar exceptions up or down in priority order, and copy and paste an exception. A new column in the exceptions panel has features for moving exceptions up and down, adding new ones and copying exiting ones.

---

GRAT Database Connection Monitor

GRAT now detects any loss of connectivity to the repository database and reports the issue via status.jsp for load balancers.

Previously, GRS only reported the SYSTEM_STATUS_DB_NOT_CONNECTED status when there a problem with the database connection was encountered during GRAT initialization, but during the rest of the lifetime of GRAT only reported SYSTEM_STATUS_OK even when the connection failed.

Now, GRAT continuously monitors the database connection status at a regular configurable interval. If the database connection fails, the monitor now sets the status to SYSTEM_STATUS_DB_NOT_CONNECTED. Later when the database connection is detected to be normal, the monitor reset the status to normal.

Additionally, if the GRAT repository could not be initialized at GRAT startup because of incorrect settings or because the repository was unavailable, the connection monitor now initializes the repository when the database connection is re-instated without requiring a restart of GRAT.

Two new configuration options control the monitor:

• enable-repository-connection-monitor
• repository-connection-monitor-interval

---

GRE Memory Monitor Enhancements

The Memory Monitor in GRE has been enhanced as follows:

• The maximum value of the memory-monitor-threshold option has been changed from 80 to 99 and the minimum to 1.
• New option enable-memory-monitor-over-threshold-memory-cleanup (default=true) has been implemented. With value true, Java garbage collection is requested when memory goes above threshold.
• New option enable-memory-monitor-update-status (default=true). With value false, memory monitor is decoupled from the status.jsp function and the LCA status update function.

---

Package History Enhancements

The Package History tab now includes the following enhancements:

Business Hierarchy Column

A new Business Hierarchy column is introduced that can now calculate and identify where the affected rule package or rule package item sits in the business hierarchy. For example: CM Samples > Sales > Closing.

The new column shows values only for actions performed from this release onwards—older action (prior to release 8.5.303) do not appear.

Important

If a business structure node name change is required, this should be done only when there is no active user session (GUI or API) in GRAT or when GRAT is shut down.

Snaphot Name Column

The Snapshot Name column now shows the name of the snapshot in which a change was made.

Access to Business Structure History

Package history now shows only changes in the business structure nodes to which the user has access. Thi access eck can be overridden by a new role privilege—PACKAGE_HISTORY_ADMIN_VIEW. This allows you to view complete package history for a rule package without checking access to the business hierarchy subnodes used inside the rule package. Even with this role privilege enabled, the package history is only shown for packages that the user can view.

Change By Column Changes

The Change By column is visible only to users with relevant role privileges. This is controlled by new role privilege PACKAGE_HISTORY_VIEW_CHANGED_BY.

---

Rule Export Enhancements

When exporting Rule Templates as XML, users now can choose which rule packages to export. Previously, all rule packages from the repository were exported.

---

Test Scenario Enhancements

Tooltips in the Add Given and Add Expectation drop-down menus in Test Scenarios now display the Fact field description as defined in the template.

---

Linear Rule Segments

The maximum limit of 6 segments (text plus variables) on Conditions or Actions in linear rules has been increased to 9 in release 8.5.303. An error message is displayed if this limit is breached.

---

Platform Support

Tomcat 8 and 8.5 are supported in this release of GRS.

---

Configuration Options Reference Guide

Configuration options are documented from 8.5.303 onwards in the Configuration Options Reference Guide.

---

New in 8.5.302

Support for Role-Based Access Control at the Rules Package Level

Important

GRS requires Genesys Administrator 8.1.305.04 (minimum) for configuring package level permissions.

You can expand the graphics by clicking on them.

---

Background

Previously, GRAT used Configuration Server Roles to provide only global access control to all packages in a given node of the business hierarchy. The privileges, like Modify Rule Package, Delete Rule Package, Modify Rule, Delete Rule and so on, are granted to users via roles. With this approach, if a user is granted the Modify Rule Package (for example) privilege, then they can modify all the rule packages defined in a node of the GRAT business hierarchy.

Release 8.5.302 now provides package-level overrides to these global roles—role privileges can be restricted to specific rule packages by applying Role-Based Access Control at the rule package level. The new Rule Package Level Roles (roles created specifically for use with rule packages only) can be mapped to rule packages to override the global-level roles. These Rule Package Level Roles will have no effect if not mapped to a rule package.

New Role Permission—View Rule Package

View access for specific rule packages can now be controlled by using the new role permission View Rule Package. The new permission is applicable to only the rule package level.

Existing Role Permissions

All of the existing role permissions except Create Rule Package and template-related permissions are applicable at the rule package level too.

Example

In 8.5.302 you can now assign role permissions at both global/node level and at rule-package level to achieve the following outcome:

• Department A
  • Rule package 1
  • Rule package 2
  • Sales
    • Rule package 3
• Department B
  • Rule package 4

• User A—Can see Department A but not Department B
• User B—Can see Department B but not Department A
• User C—Can see rule package 1, but rule package 2 is hidden

---

Location

To distinguish these new roles from global-level roles, they are placed in a new folder:

[Tenant] > Roles > GRS Rule Package Level Roles

---

Package-Level Overrides

Where package-level roles are mapped to a rule package, they override global-level roles.

---

Managing the Mapping of Roles

The mapping of the rule packages to Rule Package Level Roles is managed in Genesys Administrator or Genesys Administrator Extensions, in the options under section Rule Package Level of the \Scripts\GRS Access Control\GRS Role Mappings script. The example below is from Genesys Administrator.

Important

Because the delimiter in the list of roles is a comma, you can't use commas in the names of any role.

---

Viewing GRAT User Permissions

To enable GRAT users to view their current list of permissions, a Check My Permissions button is now also available at the rule-package level and shows the permissions at selected package level.

Support for Deployment to GWE Clusters

[+] DETAILS

In the case of GRE (Genesys Rules Engine) cluster deployment, GRAT gets the GRE nodes' information from the cluster and deploys the rule package individually to each of the cluster nodes.

But a GWE (Genesys Web Engagement) cluster is different—GWE cluster nodes are not available as connections. So the deployment must be targeted to the cluster host itself—that is, a host in the Configuration Server information of the GWE cluster.

The cluster host can be a GWE cluster node or a load balancer that randomly selects a GWE cluster node for deployment.

Streamlining of Removal of GRAT Nodes from Cluster

Removal of GRAT nodes from clusters has been streamlined.

[+] DETAILS

Removing a GRAT Node from the Cluster (pre-8.5.302)

1. Remove the GRAT node's Application ID from the list of connections in the cluster's Application object.
2. Manually remove the GRAT's entry in the LOCAL_REVISIONS table in the GRAT database (this is a single row, identified by the GRAT Application's DBID in the JOURNAL_ID column).
Warning
If this step is not performed, the clean-up thread (janitor) will not be effective.

Removing a GRAT Node from the Cluster (post-8.5.302)

In release 8.5.302, the manual cleanup of LOCAL_REVISIONS table (by the clean-up thread (janitor)) after node removal is not required. The cleaning task is now automated and controlled by the following new configuration options in the settings section of the GRAT cluster application:

• local-revisions-janitor-enabled
• local-revisions-janitor-sleep
• local-revisions-janitor-first-run-hour-of-day

Platform Support

• Support for Oracle 12c RAC implemented.
• Support for all variants of DB2 discontinued. GRAT will log a warning message if a DB2 variant is used as GRAT's database.

New in 8.5.301

---

Using GRAT Clusters for High Availability and Load Balancing

[+] DETAILS

Background

Before release 8.5.301, Genesys recommended maintaining a cold-standby backup GRAT server, connected to the same database repository as the primary, which could be initialized in the event of a primary GRAT server failure or disconnection.

A configuration option called clear-repository-cache could be set to force GRAT to clear and rebuild the local cache/search indices on startup. This allowed the backup server to synchronize with the repository, even if it had been shut down for months. Depending on the number of rule packages deployed, synchronization might be fast or slow.

What's New?

In release 8.5.301, you can now configure clusters of GRAT servers, which deliver much greater resilience and availability, enabling almost instant switchovers between GRAT nodes that are members of the cluster. All cluster members connect to the same database repository.

No single GRAT node is considered primary—they are all equal partners in the n-node cluster.

Each node maintains a journal of changes, which resides on a separate repository database table. Nodes can periodically poll the database to ensure that they mirror updates made on the other nodes. You can also add new nodes to the cluster and synchronize them with their peers.

• New GRAT Cluster Application Template

The GRAT cluster configuration object must be based on a new application template—GRAT_Rules_Authoring_Tool_Application_Cluster_<version>.apd—that is delivered with this release. GRAT instances become members of the cluster when their Application object is added to the Connections tab in the cluster's Application object.



• High Availability

An n-node cluster configuration can be used to deliver High Availability—for example, if a customer wants to use one GRAT server as the primary server and another as the secondary/backup warm-standby server, a load balancer could be configured to send all traffic to the primary server. The warm-standby instance periodically polls the journal table and keeps its cache/index files synchronized. In the event of a failure (or planned maintenance) of the primary GRAT server, the load balancer switches and sends traffic to the hot-standby secondary/backup GRAT server. The user would have to log in again, and any unsaved changes from their old session would be lost. However, they could resume in seconds instead of waiting for the cold-standby GRAT to become available.



• Load Balancing

A load balancer can evenly distribute the load across the available GRAT nodes in the cluster, or it can distribute the load based on other criteria, such as the geographic location of the browser. However, once a node has been selected, the load balancer must ensure that the same node is used for the duration of the session (session stickiness).



The load balancer must provide session stickiness for the GRAT user interface requests by sending all the requests pertaining to a session to the same GRAT node that initiated the session after successful login. Similarly, in the case of the GRAT REST API, after successful login, the load balancer must send the subsequent requests to the same GRAT node that handled the login request. More information on the GRAT REST API Authentication mechanism is available here.



• Scheduled Deployments of Rules Packages

Scheduled deployments of rules packages can now be viewed, edited and cancelled by GRAT users on GRAT instances that did not originally perform the scheduling—previously, only the original GRAT user/instance that performed the scheduling could do this. Any GRAT instance that modifies the scheduled deployment takes over the responsibility for handling that deployment. The deployment history, including a new Deployed From field that indicates which node last scheduled the deployment, is now available to all the nodes in the cluster (visible in the Deployment History tab).

Important

The new Deployed From field is also visible in standalone GRAT instances—it will display the ID of the standalone GRAT instance.

Deploying the GRAT Clustering Feature

1. Import the GRAT_Rules_Authoring_Tool_Application_Cluster_<version>.apd template into your Genesys configuration environment.
2. Create a GRAT cluster Application object based on the new template. Adjust the configuration options as needed.
3. For each GRAT node to be added to the cluster, add its Application ID as a connection in the cluster's Application object.
4. Add the DAP (Database Access Point) Application object to be used by the GRAT cluster as a connection in the cluster's Application object.
   Important

   An existing standalone GRAT database can be used.
5. If you are re-using an existing standalone GRAT instance in the cluster, re-deploy the GRAT application to ensure that its local cache is re-initialized.
   Important

   • Any change in the cluster configuration will only take effect upon re-start of the GRAT servers.
     
   • For high availability, GRAT instances must have a high-speed connection to the database. Slow connections may result in the type of issues commonly seen when the local repository cache is corrupted.

Removing a GRAT Node from the Cluster

1. Remove the GRAT node's Application ID from the list of connections in the cluster's Application object.
2. Manually remove the GRAT's entry in the LOCAL_REVISIONS table in the GRAT database (this is a single row, identified by the GRAT Application's DBID in the JOURNAL_ID column).
   
   Warning

   If this step is not performed, the clean-up thread (janitor) will not be effective.

New Configuration Options

Click here for details of the new configuration options that are set on the GRAT application cluster.

---

Additional Columns Support

• The previous limit of 30 columns in GRAT Decision Tables and Test Scenarios has been increased to 50 columns.

---

New in 8.5.3

---

Support for A/B/C Split Testing

[+] DETAILS

Overview

[+] DETAILS

What problem does A/B/C Split Testing solve?

If your organization has a complex set of rule packages and rules to define business decision-making, if you want to be able to compare alternative outcomes and scenarios, then rather than just changing a condition and hoping for the best you probably want to phase changes in slowly in order to measure the impact over time.

A/B/C Split Testing (hereafter, Split Testing) allows you to compare the business outcomes of alternative rule scenarios before rolling out significant changes to the way you make your business decisions. With Split Testing you can make, test and review changes incrementally to test their effects before committing to a particular change set.

For example, you might want to test several subtle changes in the way applications for credit cards are treated, in order to identify which has the best business outcome. You could split test for one income level against another, or one age range against another, or between different customer segments, or indeed any conditions in your rule package.

Flexible Approaches to Split Testing

Split Testing offers several approaches. For example, you can choose to:

• Unconditionally force either path A or B or C.
• Tie Split Testing to certain conditions (whether the customer is from a particular city, of a certain age, not a Gold customer, and so on).
• Weight the paths for A, B and C by percentage. This allows you to take a more statistical approach and use larger test data sets.
• Tie Split Testing to a business calendar (for example only do split testing on Fridays after 5 PM or Saturday morning 9 AM - 12 PM).

New Split Testing Template

A new template ships with GRS 8.5.3—GRSSplitTest_template.xml—and this provides some basic Facts (Conditions and Actions) for the Split Testing feature. To implement the feature, GRAT users must import this template (from the Samples folder) and attach it to all rules packages for which the Split Test functionality is required.

Important

The new template—GRSSplitTest_template.xml—is shipped with type samples. This means it can only be added to rule packages of type samples, because GRAT only shows templates in the list with compatible types. To use this template with other rule package types, you can import the template from GRAT into GRDT, change the name (for example, GRSSplitTestForMyType) and the type (to match your rule package type) and publish to GRAT. Then you can use with another package type.

Changes in GRAT

[+] DETAILS

New Split Test Column in Rule Packages

A new Split Test column displays at the rule package level.

When the Split Test template has been imported into GRAT, this drop-down field will show the values imported from the template (A, B and C are the default values in the shipped template). If the template has not been imported, only the wildcard (*) symbol will be available.

When a path is selected in this column, the rows color-code for easier viewing. The wildcard symbol (*) means that the Split Test condition is ignored, so this rule will always fire.

New Split Test Configuration Node

A new node—Split Test Configuration—appears in the left navigation tree. You can use this node to create new (and display existing) Split Test rules that will apply at the rule package level. In rules created by clicking this new node, the Split Test column is hidden to avoid confusion.

What Can I Do with Split Test Rules?

[+] Force the Split Test Path to A, B or C

Unconditionally force either path A or B or C

In rules created by clicking this new node, the splitTestValue can be selected as a Parameter for the rule. You can use this simple rule to force the Split Test path to any of the values in the template (the default shipped values in the template are A, B and C, but you can change these in the template if required).

[+] Tie a Split Test Rule to a Condition

Tie Split Testing to a Condition

To add more flexibility and precision to your use of Split Test rules, you can add to your rule any other condition available from the template(s) attached to the rule package. The example below has a lower age limit:

[+] Set Up a Weighted Distribution

Weight the paths for A, B and C by percentage

You could add a condition to perform Weighted Distribution Split Testing. In this example the Split Test rule distributes the incoming rule evaluation requests across the A, B and C paths in the percentage proportions 50/25/25. This should look something like this:

[+] Tie a Split Test Rule to a Business Calendar

Tie Split Testing to a Business Calendar

You can also tie Split Testing to a Business Calendar. For example, you might prefer to keep Split Testing outside normal business hours, or maybe run Split Testing in response to specific customer offers or other commercial events. To do this you can either use an existing Business Calendar or create a new one for your specific purpose. You then add this calendar to the rule to which you want to apply Split Testing.

So, when the parameters set for the Business Calendar apply, the weighted Split Testing begins and ends automatically.

Using Test Scenarios to Check Your Split Test Logic

[+] Using Test Scenarios to Check Your Split Test Logic

GRAT's Test Scenario feature allows you to run pre-deployment checks on the logic of any rule package that you want to deploy. Because A/B/C Split Testing enables an additional level of logic to be built into a rule package, it's advisable to run more complex Split Test logic through a Test Scenario before deploying it to a production rules engine.

For example, if you wanted to check the Weighted Distribution example above before deploying the rule package to a production engine, you could create a test scenario to have 10 rows of identical data that only qualify when running path A. Each row in the test scenario simulates a separate rule evaluation and will therefore apply the Split Test Configuration rules first. If we see a green tick, then the original A path was taken. If we see a red cross, then either the B or C path was taken.

Because we configured the A path for 50% of the time, we should see about 50% green ticks every time we hit the Run Test Scenario button. Here are the outcomes of running the test scenario twice:

After testing that the A/B/C split logic is correct, you can deploy your rule package. At this point, the A/B/C split logic will run as you have it configured during normal rule evaluation. To adjust the A/B/C configuration (for example, make the A path 25% instead of 50% and the B path 75% instead of 50% and so on), you must make the changes in GRAT and then redeploy the rule package.

Allowing an Application to Override Split Test Configuration Rules

[+] Allowing an Application to Override Split Test Configuration Rules

In addition to setting the A/B/C path in the Split Test Configuration section, it is possible for the invoking application (GVP, IVR, ORS and so on) to set the value. This can either be used as a default, or can be used to override the logic in the Split Test Configuration.

If you want the invoking application to be able to override the normal logic in Split Test Configuration, then you can simply add the new Split Test Path is not set condition to your rule.

This new condition will check whether the value has already been passed in by the invoking application. If it has been passed in, then the Split Test logic will be bypassed. If not, then the normal Split Test rule logic will apply.

---

Changes to Platform Support

• Support for Java 8. In release 8.5.3 GRAT and GRE require Java 8.
• Support for JBOSS 7.x is discontinued.
• Support for RHEL 5 32-bit is discontinued.

---

New in 8.5.2

New Features in 8.5.2 (new document)

---

New in 8.5.1

New Features in 8.5.1 (new document)

---

New in 8.5.0

New Features in 8.5.0 (new document)