Jump to: navigation, search


Section: settings
Default Value: 2
Valid Values:
Changes Take Effect: After restart

Specifies the hour at which the clean-up task initiates its first run (default = 2, which means 2:00 at night).


Section: settings
Default Value: 15
Valid Values:
Changes Take Effect: After restart

Specifies the sleep time of the clean-up task in days (only useful when the clean-up task is enabled, default is 15 days).


Section: settings
Default Value: true
Valid Values:
Changes Take Effect: After restart

specifies whether the clean-up task for the local revisions table is enabled. At regular intervals, the clean-up task cleans the local revisions table by removing the entries for cluster nodes which are no longer part of the cluster. If this is not done then journal table Janitor will not be effective.


Section: settings
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.303.06

When this option is false, memory monitor is decoupled from the status.jsp and LCA status update code.


Section: settings
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.303.06

With value true, Java garbage collection is triggered when memory use rises above the maximum threshold limit.


Section: settings
Default Value: 70
Valid Values: Integer, min 1, max 99
Changes Take Effect: Immediately
Modified: 8.5.303.06

Threshold in percentage. If memory usage exceeds this threshold, GRE will return unavailable status. Note: Range values changed from min 40, max 80 in 8.5.303.06.


Section: settings
Default Value: 5
Valid Values: Integer, minimum 1
Changes Take Effect: Immediately
Introduced: 8.5.303.06

Specifies the sleep time of the repository connection monitor task in seconds.


Section: settings
Default Value: True
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.303.06

Specifies whether the repository connection monitor is enabled (true) or not (false).


Section: settings
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Modified: 8.5.303.06

If true, users can only deploy a package snapshot. If false, users can deploy the LATEST package or a snapshot.


Section: settings
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.200

This option must be set to true to allow partial deployment to a cluster. If it is set to false, the cluster deployment will fail even if only one of the cluster nodes fails to deploy successfully.


Section: settings
Default Value: False
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.303

With value true, GRAT can perform a partial undeployment to a GRE-type application cluster. Not applicable to GWE rules engines or to rule packages based on the CEP template.

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

Undeploy All.png

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.


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.

Autosnap all.png

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:

GRE Memory Monitor Enhancements

The Memory Monitor in GRE has been enhanced as follows:

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.

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

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

You can expand the graphics by clicking on them.


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.


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


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.

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

GA mappings1.png

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


Streamlining of Removal of GRAT Nodes from Cluster

Removal of GRAT nodes from clusters has been streamlined.


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


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


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)

This page was last edited on April 28, 2017, at 12:15.
blog comments powered by Disqus