settings Section
- allow-legacy-template-import
- allow-partial-cluster-deployment
- allow-partial-cluster-undeployment
- auto-fix-corruptions
- clear-repository-cache
- context-services-rest-api-base-path
- context-services-rest-api-host
- context-services-rest-api-port
- context-services-rest-api-protocol
- decision-table-enable-wildcards
- deploy-method
- deploy-port
- display-n-template-versions
- enable-cep-calendars
- enable-dynamic-loading
- enable-nested-solutions
- enable-pending-rule-count
- enable-repository-connection-monitor
- evaluate-decision-table-rows-top-down
- force-snapshot-on-deployment
- group-by-level
- help-file-url
- link-to-hub
- list-object-use-name
- max-connections
- max-undo-revisions
- repository-connection-monitor-interval
- require-checkin-comment
- rest-api
- session-timeout
- session-timeout-alert-interval
- single-sign-on
- strict-mode
- verify-deploy-address
allow-legacy-template-import
Default Value: false
Valid Values:
Changes Take Effect: immediately
This option must be set to true if importing templates from GRAT 8.1.1 or earlier. For security reasons, it should be immediately set to false after the migration is complete.
allow-partial-cluster-deployment
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.
allow-partial-cluster-undeployment
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.
auto-fix-corruptions
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.304.14, 9.0.000.25
Modified: 9.0.000.31 — default value changed from false to true
Allows enabling (true) or disabling (false) of the automatic cleanup of repository inconsistencies that might occur where a rule package has been deleted but doesn't get fully cleaned up. When there is a repository inconsistency, an attempt to add another package with the same name would generate an exception and a message indicating that a package with this name already existed. It is recommended to keep this option enabled.
clear-repository-cache
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
If true, the server will clear the repository cache during startup. If false, the current repository cache will remain.
The GRAT server builds and maintains a cache of the rules repository database (for example, index files, and so on), and stores this on the file system under WEB-INF/classes/repository. The cache improves performance when accessing frequently used rules, calendars, and so on. However, this cache must stay synchronized with the rules repository database.
Normally, if GRAT is restarted, it re-uses the existing cache, which is synchronized with the rules repository database. In this case, the clear-repository-option should be set to false (default).
However, if you are configuring a second GRAT for cold standby (see High Availability Support), this option should be set to true for both the primary and the standby instances of GRAT. Since either GRAT could be brought online in the event of a failure, this option forces GRAT always to rebuild the cache and re-synchronize it with the rules repository database. Setting this option to true can delay the startup of GRAT, since the cache must be rebuilt, but it ensures that it is properly synchronized with the rules repository database.
When a GRAT is part of a cluster, you should in general set the value of its clear-repository-cache option to true. For GRATs in a cluster, setting this value to true can help avoid the repository corruption errors that can occur if you forget to clear the cache when a node is re-added to the cluster or moved from a different cluster. However if there is a specific reason to avoid the possible slower startup of GRAT server that might ensue, then set the option to false.
If the GRAT startup delay is irrelevant or if GRAT startup is quick enough with the clear-repository-cache option set to true, then set it to true.
context-services-rest-api-base-path
Default Value: /
Valid Values: Any string
Changes Take Effect: Immediately
Introduced: 8.5.001
The base path of the Context Services REST API.
context-services-rest-api-host
Default Value:
Valid Values: Any string
Changes Take Effect: Immediately
Introduced: 8.5.001
The hostname of the Context Services that GRAT connects to.
context-services-rest-api-port
Default Value: 9080
Valid Values: Any positive integer
Changes Take Effect: Immediately
Introduced: 8.5.001
The port number of the Context Services REST API.
context-services-rest-api-protocol
Default Value: http
Valid Values: http, https
Changes Take Effect: Immediately
Introduced: 8.5.001
The protocol used to connect to Context Services REST API.
decision-table-enable-wildcards
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.001
Controls whether the wild card feature is enabled in decision tables.
deploy-method
Default Value: auto
Valid Values: auto, http, https
Changes Take Effect: Immediately
Introduced: 8.5.100.21
Enables users to override the automatic detection of the protocol to construct the "callback" URL used by GRE to fetch the DRL. GRE will use the selected method to connect with the GRAT server during deployment.
deploy-port
Default Value: Uses the listening port of the application server
Valid Values: Any positive numbers
Changes Take Effect: Immediately
Used to override the automatic detection of deployment port.
display-n-template-versions
Default Value: 3
Valid Values: Any positive integer
Changes Take Effect: Immediately
Specifies the number of versions of each published rule template to display to the Rules Author when they are creating or changing a rule package.
f the current rule package is using an older version that is not included in the last "n" versions, it will also be shown, in order to allow the user to upgrade to a more recent template. For example, if "n" is 3, and there are 10 versions of a template, GRAT will show only version 10, 9, and 8. If the rule package is currently associated with an older version, for example, version "5", then that will also be shown, and the checkbox will be selected.
The minimum valid value is 1.
enable-cep-calendars
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.200
Controls whether users can create business calendars for rule packages which support Complex Event Processing (CEP).
enable-dynamic-loading
Default Value: True
Valid Values: True, False
Changes Take Effect: Immediately
Introduced: 8.5.303.12
With value true, GRAT loads the business hierarchy and related rule packages on demand when the user opens folders. With value false, the entire hierarchy is loaded at user login.
When this feature is enabled, nodes and rule packages are loaded dynamically when the user expands the folders (on the left-hand side), rather than the entire hierarchy being loaded up-front when the user first logs in. In addition, this feature improves performance of creating, updating, and deleting rule packages.
enable-nested-solutions
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.100.21
Controls whether users can create new rule packages under any node of the hierarchy. For iWD users, this option should be set to false—iWD does not support nested solutions.
enable-pending-rule-count
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 9.0.000.22
Allows the user to disable the calculation of the number of rules that have a pending snapshot. This number is displayed for each rule package in parentheses in the Deploy Rules node (for example, Deploy Rules (2)). This is an expensive and frequently accessed function, and can slow down the overall responsiveness of the GRAT UI.
With value false, GRAT will no longer show a count in the parenthesis, but just show an asterisk, indicating that rules have changed since the last snapshot. Users can still view which rules were updated in the rule summary page (Pending Snapshot column), or can search the entire rule package for pending rules using the Search function.
With value true (default), GRAT works as before, showing the number of rules.
For better performance, Genesys recommends setting this to value false if this count does not provide business value.
enable-repository-connection-monitor
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).
evaluate-decision-table-rows-top-down
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.0
This option effectively determines the order of execution for rows within a decision table whose conditions match. The pre-8.5.0 default has been that they are evaluated from the bottom-up. To preserve compatibility with previous releases of GRS, the default setting is false, which maintains this same behavior. You can override the default by setting this option to true. If you change this default value, you will see a change in behavior immediately when using GRAT's Test Scenario feature, but will need to re-deploy the rule package in order for the change to be observed in GRE, since this option affects how the DRL is encoded.
force-snapshot-on-deployment
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.
From release 8.5.303 and later, this option also determines whether a user has the choice to automatically create a snapshot on deployment of the LATEST package. If true, then a snapshot will always be created when the user selects the LATEST package. If false, then the user can select by using a checkbox whether or not to automatically create a snapshot prior to deploying the LATEST package.
group-by-level
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
if true, rules are grouped by business level. All global rules belong to agenda group "level0". Department rules belong to agenda group "level1". Process rules belong to agenda group "level2". When a rule package is executed, "level0" rules are executed first, facts are marked as updated, and "level1" rules are executed. This is repeated for each level. Note: The GRE option "sequential-mode" must be false when "group-by-level" is true.
There are three levels of rules: global, department, and process.
With value true, rules are grouped by business level:
- All global rules belong to agenda group level0.
- Department rules belong to agenda group level1.
- Process rules belong to agenda group level2.
When a rule package is executed, level0 rules are executed first. Updates from this first pass then influence the department (level1) rules which are executed in the second pass. Updates from this second pass then influence any process rules (level2), which are executed in a third pass.
Note: The GRE option 'sequential-mode' must be false when group-by-level is set to true.
When group-by-level is set to false, all rules are executed in a single pass. Changes made by a rule do not influence which other rules are executed (unless a Drools “update” or “insert” command is used).
CEP functionality
Genesys Web Engagement's CEP functionality strips out the rule attribute that indicates which level a rule is associated with. So, the setting of the group-by-level has no influence on rule execution.
help-file-url
Default Value: http://docs.genesys.com/Special:HelpLink/GRATHelp?context=8.5.3.index
Valid Values: Any valid URL
Changes Take Effect: immediately
Introduced: 8.5.001
Discontinued: 8.5.1
This option specifies the URL for the online GRAT help, which is normally hosted on docs.genesys.com. If you wish to host the help locally, you can change the default base URL using this configuration option.
link-to-hub
Default Value:
Valid Values: Any valid URL
Changes Take Effect: Immediately
Introduced: 8.5.0
The URL to which the browser will be redirected on exit from the rules authoring tool. Used only when single-sign-on = true.
Note: This configuration option should only be used when deploying in a Genesys Engage cloud single-sign on environment, and does not apply for Genesys on-premise customers deploying GRS.
This option specifies the URL to which GRAT should redirect once the GRAT SSO session completes. This URL is used in two situations:
- First, when the user clicks the log out button in GRAT, the browser will be redirected to this URL.
- Second, if an SSO login is successful but the subsequent login to Configuration Server fails, then an error box is displayed to the user. Once the error box is dismissed, the browser will be redirected to the specified URL.
Note: The user must have logged in via SSO for this to occur.
list-object-use-name
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.001.21
When parameters are used that reference Configuration Server list objects, this option controls whether the name or display name is encoded in the rule file. Specify true to use the name field or false (default) to use the display name.
max-connections
Default Value: 99
Valid Values: Any positive integer
Changes Take Effect: Immediately
Specifies the maximum number of different users that may be connected to the server. Multiple connections from the same user ID are only counted once.
max-undo-revisions
Default Value: 10
Valid Values: Any positive integer
Changes Take Effect: Immediately
Modified: 9.0.000.13
The maximum number of undo/re-do revisions that can be made.
repository-connection-monitor-interval
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.
require-checkin-comment
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
If true, users must specify a check-in comment when committing changes to rules. These comments show up when viewing package history. If false, users can save changes to rules without specifying a comment.
rest-api
Default Value: disabled
Valid Values: disabled, enabled, requireSSL
Changes Take Effect: Immediately
Introduced: 8.5.200
Controls whether GRAT's REST API is enabled for rule authoring and deployment.
- disabled—The REST API is disabled and will not accept any requests
- enabled—The REST API is enabled and will accept both secure (https) and non-secure (http) requests
- requireSSL—The REST API is enabled and will only accept secure (https) requests.
In addition, this configuration option enable users to determine whether or not to force only SSL communications. Genesys recommends running over SSL in order to protect the authentication tokens that flow on each request from compromise. SSL can be disable where appropriate (for example, testing labs, positioning server behind firewalls, and so on).
session-timeout
Default Value: 30
Valid Values: Any positive integer
Changes Take Effect: Immediately
Specifies the amount of time (in minutes) a client session can have no communication with the Rules Authoring Server before timing out. If no value is specified, the timeout (if any) defined by the application server applies. If the value is less than or equal to 0, the session will not timeout
session-timeout-alert-interval
Default Value: 1
Valid Values: Any positive integer
Changes Take Effect: Immediately
Virtual Agent (VAGs) Groups are used to group website visitors by the service they need from agents.
The VirtualAgentGroup name value must match the LivePerson RSI skill names.
The amount of time (in minutes), prior to an expected timeout, for a user to be warned of a pending timeout. If no value is specified, or if the value is less than or equal to 0, the default warning period of 1 minute will be used. For example, if you set the value of this option to 3, the user will be warned 3 minutes prior to an expected timeout. This warning dialog box will prompt the user to extend the session. If the session is not extended, the user will be logged out and the login dialog box will be displayed. Any unsaved changes that the user made during their session will be lost.
single-sign-on
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.0
Note: This configuration option should only be used when deploying in a Genesys Engage cloud single-sign on environment, and does not apply for Genesys on-premise customers deploying GRS. Indicates the login method: either single sign-on, or legacy login. With value false, the /index.jsp page will redirect to /login.jsp for legacy user login. If the value is true, then /index.jsp will redirect to /singlesignon.
strict-mode
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
This option controls whether or not the rules authoring tool enables strict mode in the DROOLS rule compiler. Strict mode will cause the compiler to catch common mistakes when the rule author attempts to validate or save a rule. Genesys recommends leaving this option set to its default value true.
verify-deploy-address
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Indicates whether to verify the TCP address of the application deploying rules to be that of a valid associated Genesys Rules Engine (one in the valid list of application connections). With its default value of true, this option protects against illegal attempts to deploy packages from any other application.