GRS Configuration Options

The following tables list GRS configuration options.

log

Description	Valid values	Default value	Takes effect
all
Specifies the outputs to which an application sends all log events. The log output types must be separated by a comma when more than one output is configured. For example: all = stdout, logfile	stdout—Log events are sent to the Standard output (stdout). stderr—Log events are sent to the Standard error output (stderr). network—Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database. Setting the all log level option to the network output enables an application to send log events of the Standard, Interaction, and Trace levels to Message Server. Debug-level log events are neither sent to Message Server nor stored in the Log Database. memory—Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance. [filename]—Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application's working directory.	stdout	After restart
expire
Determines how many log files will be kept on disk. If set, expire specifies the maximum number of log files kept on disk.	Any number	(blank)	After restart
segment
Determines whether a log output written to file is split in multiple segments. If it is, segment specifies the maximum size of each segment file.	Any number that represents the log size in megabyte	(blank)	After restart
standard
Specifies the outputs to which an application sends the log events of the Standard level. The log output types must be separated by a comma when more than one output is configured. For example: standard = stderr, network	stdout—Log events are sent to the Standard output (stdout). stderr—Log events are sent to the Standard error output (stderr). network— Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database. memory—Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance. [filename]—Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application's working directory.	stdout	After restart
trace (not in application template by default)
Specifies the outputs to which an application sends the log events of the Trace level and higher (that is, log events of the Standard, Interaction, and Trace levels). The log outputs must be separated by a comma when more than one output is configured. For example: trace = stderr, network	stdout—Log events are sent to the Standard output (stdout). stderr—Log events are sent to the Standard error output (stderr). network—Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database. memory—Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance. [filename]—Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application's working directory.	stdout	After restart
verbose
Determines whether a log output is created. If it is, specifies the minimum level of log events generated. The log events levels, starting with the highest priority level, are Standard, Interaction, Trace, and Debug.	all—All log events (that is, log events of the Standard, Trace, Interaction, and Debug levels) are generated. debug—The same as all. trace—Log events of the Trace level and higher (that is, log events of the Standard, Interaction, and Trace levels) are generated, but log events of the Debug level are not generated. interaction—Log events of the Interaction level and higher (that is, log events of the Standard and Interaction levels) are generated, but log events of the Trace and Debug levels are not generated. standard Log events of the Standard level are generated, but log events of the Interaction, Trace, and Debug levels are not generated. none—No output is produced.	standard	After restart

Important

Where the table below indicates that a GRAT (re-)start is required, this means the GRAT Web Application must be restarted. This can be accomplished in different ways depending upon the application server. In Tomcat, JBOSS or Websphere, GRAT can be stopped and started from the administration console. This does not require restarting the entire app server (there could be other applications deployed to the same container, not only GRAT). If GRAT is the only application deployed, you can simply restart the application server (for example, restart Tomcat server).

Settings in GRAT

Description	Valid values	Default value	Takes effect
group-by-level (group rules by business level)
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.	true/false	true	Immediately
max-connections
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.	Any positive integer	99	After GRAT (re-)start
session-timeout
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 time out.	Any positive integer	30	Immediately
session-timeout-alert-interval
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.	Any positive integer	1	Immediately
strict-mode
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.	true/false	true	Immediately
verify-deployer-address
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.	true/false	true	Immediately
display-n-template-versions
Specifies the maximum number of versions to display for any published template. Note: if 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.	Minimum value 1	3	Immediately
deploy-response-timeout (not in application template by default)
Specifies the timeout (in seconds) applied to the deployment of a rule package before an error condition is indicated. If the timeout is reached, the deployment fails (is this true?) and an error is returned.	Any positive integer	300	Immediately
require-checkin-comment
Specifies whether users must add a check-in comment when committing changes to rules. These comments show up when viewing package history. If the value is set to false (default), users can save changes to rules without specifying a comment.	true/false	false	Immediately
force-snapshot-on-deployment
Specifies whether users can deploy only a package snapshot. If the value is true, users can only deploy a package snapshot. If false (default), users can deploy either the LATEST package or a snapshot.	true/false	false	Immediately
encoding (not in application template by default)
Activates Unicode support for the conversion of data between the local character set that is used by Configuration Manager and the UTF-8 encoding that is used by the Rules Authoring Server. By default, code page conversion is disabled. To activate this functionality, set this option to the name of a converter that can translate the local character set to UTF format. The converter that is suitable for a particular deployment can be found by using the ICU Converter Explorer. There is no default value for this option. For valid values, see the ICU Home > Converter Explorer pages (http://demo.icu-project.org/icu-bin/convexp).			After GRAT restart
clear-repository-cache
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 warm 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.	true/false	false	After GRAT (re-)start
evaluate-decision-table-rows-top-down (new in 8.5.0)
Determines the order that the Decision Table rows are written out to the DRL. The default value is false, meaning that the rows are executed from the bottom up. If you change this default option, the behavior of GRAT's Test Scenario feature changes immedately, but you will need to re-deploy the rule package in order for the change to be observed in GRE.	true/false	false	Immediately
single-sign-on (new in 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. With value true, then /index.jsp will redirect to /singlesignon.	true/false	false	After GRAT (re-)start
link-to-hub (new in 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. 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.	string	No default value	After GRAT (re-)start
decision-table-enable-wildcards (new in 8.5.001)
Controls whether the wild card feature is enabled in decision tables.	true/false	true	After GRAT (re-)start
help-file-url (new in 8.5.001)
Specifies the base URL location of online help for GRAT. You can specify a local protected URL to install the wiki Help files if your organization prefers. If you change the default value, you must specify the location of your locally hosted Help files.	String	http://docs.genesys.com/Special:HelpLink/GRATHelp?context=<GRAT version>.index	Immediately
use-legacy-language-pack-webhelp (introduced in 8.5.001 and removed in release 8.5.1)
With value true, when the GRAT user clicks the Help button in non-English environments, GRAT will use the legacy WebHelp files shipped with the various language packs. These legacy files may not reflect the full set of current functionality. With value false (default), GRAT will retrieve online Help from the docs.genesys.com website in the desired language (if available). In release 8.5.1, translated online Help is available, so this option is not required.	true/false	false	After GRAT (re-)start
context-services-rest-api-protocol (new in 8.5.001)
The protocol that GRAT uses for the Context Services metadata REST API. Valid values are: http https	http, https	http	After GRAT (re-)start
context-services-rest-api-host (new in 8.5.001)
The hostname of the Context Services that GRAT connects to.	String		After GRAT (re-)start
context-services-rest-api-port (new in 8.5.001)
The port of the Context Services metadata API	String		After GRAT (re-)start
context-services-rest-api-base-path (new in 8.5.001)
The base path of the Context Services API.		/	After GRAT (re-)start
list-object-use-name (new in 8.5.001.21)
Enables users to control whether either the name or the display name of a Configuration Server list object is encoded in the DROOLS rule file.		true/false	After GRAT (re-)start
enable-nested-solutions (new in 8.5.100.21)
Controls whether users can create new rule packages under any node of the hierarchy. For iWD, it is recommended to set this option to false.	false	true/false	After GRAT (re-)start
deploy-method (new in 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.	auto	auto / http / https	After GRAT (re-)start
enable-cep-calendars (new in 8.5.200)
Enables users to enable/disable business calendars for rules that are based on the Complex Event Processing (CEP) template.	false	true/false	After GRAT (re-)start
allow-partial-cluster-deployment (new in 8.5.200)
With value true, allows GRAT to perform a partial deployment to a GRE-type application cluster, as distinct from pre-8.5.2 behavior in which cluster deployment fails if even a single node fails.	false	true/false	Immediately
rest-api (new in 8.5.200)
Defines whether the REST API is enabled. In addition, this configuration option will enable them 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).	disabled	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.	After GRAT (re-)start

Settings in GRE

Description	Valid values	Default value	Takes effect
deployed-rules-directory
Specifies the directory in which to keep the working copy of deployed rule packages. When a package is deployed, a copy of the deployed package is placed here. When the rules engine is restarted, all packages defined in this directory are loaded and made available for execution. Specifying a deployed-rules-directory is recommended. If a value is not assigned to the deployed-rules-directory option, the rule packages are placed in the WEB-INF\config sub-directory within the genesys-rules-engine web application directory. At this location the deployed rule packages may be deleted when an updated .war file is deployed. If you choose to change the default value, ensure that the path exists and that the application server can write to the specified directory. In release 8.5.2, for a clustered GRE created using the GRE-type application cluster template, where the cluster application object has the auto-synch-rules option (new in 8.5.2) set to false, the deployed rules files will continue to be stored in the deployed-rules-directory. In such cases a manual re-deployment will be required if deployment status is partial or if a new node joins the cluster. Where such a cluster application object has the auto-synch-rules option set to true, deployed rules data will be stored in a shared cluster folder defined in option shared-root-directory (new in 8.5.2). Each clustered GRE node will have its own deployment folder in the cluster shared folder. The shared folder will help synchronize the clustered GREs after either connection disruptions or when a new GRE is added to the cluster. Important If multiple GREs share the same host, the value of deployed-rules-directory must be unique for each GRE.		/GCTI/logs/GRS_Engine	After restart
max-number-rule-executions
The maximum number of rules to be executed during a request. This is used to detect unwanted recursion when sequential-mode is false. If this maximum is reached an error is reported. May be set to -1 to denote no maximum.	Any positive integer or -1	10,000	Next rules execution
sequential-mode
Indicates whether to run the rules engine in sequential mode. In sequential mode, after the initial data set, no more data can be inserted or modified. This allows for the rules engine to operate in a simplified way.	true/false	false	On rules deployment
verify-deployer-address
Indicates whether to verify the TCP address of the application deploying rules to be that of a valid associated Genesys Rules Authoring Tool (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.	true/false	true	Immediately
esp-worker-threads
Specifies the maximum number of worker threads available when using the ESP interface to execute rules.	Any positive integer	5	Immediately
load-packages-on-start
Indicates whether to load deployed rule packages at application start up. If packages are not loaded at startup (value=false), then a package is loaded on its first execution request.	true/false	true	Immediately
json-hierarchical-driver
With value true, the JsonHierarchicalStreamDriver class is used to serialize JSON responses. With value false, the JettisonMappedXmlDriver class is used. The Jettison driver is unaware of the original data type and will try to detect numerical values and omit the quotes, whereas the JsonHierarchicalStreamDriver will maintain the data type.	true/false	false	Immediately
cache-operational-parameters (new in 8.5.0)
Operational parameters are rule parameters whose value is obtained at rule execution time. They are configured in GAX as Parameter Groups, and stored in the Configuration Server database. Prior to 8.5, whenever an operational parameter was referenced during the execution of a rule, GRE would fetch the current value from Configuration Server. In high-volume environments, this could put unnecessary stress on Configuration Server. In GRS 8.5, the value of the operational parameters can be cached inside GRE, to make fetching faster. Instead of fetching the value with each reference, GRE will set up a listener to Configuration server and maintain the value in a local cache. When the administrator changes the value of the parameter using GAX, GRE will receive an event and update its local cache. If cache-operational-parameters is set to true (default), this new caching mechanism will be enabled. If cache-operational-parameters is set to false, no caching will be used and each reference will fetch the current value from Configuration Server (as was done prior to 8.5).	true/false	true	Immediately
parameter-cache-timeout (new in 8.5.0)
When cache-operational-parameters is set to true, parameter-cache-timeout defines how long (in hours) an operational “parameter group” will remain in the cache. After the timeout expires, the transaction will be removed from the cache until the next time the value is requested. This is used to clean up old subscriptions to parameter groups which are no longer being referenced. The default value for this will be 168 (168 hours = 1 week).	Integer	168	Immediately
clear-cache-on-disconnect (new in 8.5.0)
When cache-operational-parameter is set to true, the clear-cache-on-disconnect parameter defines what the behavior should be if GRE loses connection with the Configuration Server. If clear-cache-on-disconnect is set to false, GRE will continue to use the cached value for any rule evaluations, until such time as the Configuration Server is restored. With this option, there is a risk that GRE could use “stale” values for rule evaluation during the time the connection to Configuration Server is down. If clear-cache-on-disconnect is set to true, the cache will be cleared and a null (“”) value will be used in the rules. With this option, there is potential that rules will fail evaluation during the period that the Configuration Server connection is down.	true/false	false	Immediately
include-rule-evaluation-detail-in-response (new in 8.5.001)
Returns rules that did not fire, conditions that evaluated false and rule evaluation time back to the REST client invoking the rule evaluation request. Prior to 8.5.001, only the results of rules that fired were returned. Note: Currently, the rulesDisqualified and executionTime is not returned via ESP to iWD.	true/false	false	Immediately
unload-inactive-package-timeout (new in 8.5.1)
Specifies the interval (in minutes) after which, if a rule package remains unused by GRE, it is unloaded from memory. If the option is not specified, then packages are loaded in GRE with no timeout. If a request for a rule package is received after the package has been unloaded, it is automatically loaded into memory again and the timer is restarted.	Integer	No default	At GRE start/restart
iwd-set-department-from-process (new in 8.5.100.21)
Enables (value = true), GRE to determine the Department from the properties of its Process, for ESP server requests. The setting of the Department from the Process properties will only occur if the Department is not specified and the business context level 1 is not specified.	true/false	false	At GRE start/restart
shared-root-directory (new in 8.5.200)
Specifies the shared root directory. When this option is used and option deployed-rules-directory-is-relative-to-shared-root is set to true, the effective deployed rules directory used by GRE is made by prepending this string to the path specified in deployed-rules-directory. It can be used to specify the path to the shared location used for the auto-synch feature for rules. Having this option empty (or not set) effectively allows setting an absolute path in the deployed-rules-directory even when deployed-rules-directory-is-relative-to-shared-root is set to true. It may be a value in Universal Naming Convention (UNC) format or mapped/mounted folder path backed by a service like Amazon S3 or simply an OS shared folder. Examples: If shared-root-directory = C:\shared and deployed-rules-directory = \GRE1, then the effective deployed rules directory path used by GRE is C:\shared\GRE1 . If shared-root-directory = \\10.10.0.11\shared and deployed-rules-directory = \GRE1, then the effective deployed rules directory path used by GRE is \\10.10.0.11\shared\GRE1 . If the shared folder is mapped on drive Z, the shared-root-directory will be Z:, deployed-rules-directory may be \GRE1, then the effective deployed rules directory path used by GRE will be Z:\GRE1. Important Universal Naming Convention (UNC) format is not supported where GRE runs on the AIX operating system.	string		After restart
deployed-rules-directory-is-relative-to-shared-root (new in 8.5.200)
Indicates whether to use the shared root directory as the root directory for deployed-rules-directory or not. It must be set to true if GRE belongs to a cluster that has auto-synch-rules or just auto-synch-rules-at-startup enabled. This may be used even when GRE does not belong to a cluster. If this option is set to false, auto-synch will not work.	true/false	false	Immediately
enable-memory-monitor (implemented in HF 8.5.200.12)
Enables or disables the Memory Monitor feature.	true/false: Absence of this property or invalid value results in false	false	At GRE start/restart
memory-monitor-interval (implemented in HF 8.5.200.12)
The interval in seconds between periodic memory usage checks.	integer: min 1	60	At GRE start/restart
memory-monitor-threshold (implemented in HF 8.5.200.12)
The memory usage threshold expressed as a percentage. If memory usage goes above the threshold, GRE's status.jsp returns HTTP 503 status with a message SYSTEM_STATUS_MEMORY_USAGE_ABOVE_THRESHOLD. Genesys Management layer is also notified about GRE's unavailability via status set in LCA Connection. When memory usage is back below the threshold, GRE's status.jsp returns HTTP 200 status and Genesys Management Layer is notified that GRE is available.	integer: min 40, max 80	70	Immediately
memory-monitor-threshold-strategy (implemented in HF 8.5.200.12)
Allows you to change the out of memory error handling behavior of memory monitor. adaptive—At out-of-memory error, a new threshold is calculated and it is obtained by reducing the configured memory-monitor-adaptive-threshold-safety-margin amount from the percentage memory usage at the time Memory Monitor receives the out-of-memory notification. The threshold is reset only if the new calculated value is less than the configured threshold (or less than current override)—for example, if the configured threshold is 80 %, the safety margin is 10 % and if an out-of-memory error notification is retrieved when memory usage is 70 %, the new override threshold will be 70 - 10 = 60 %. In this scenario, Memory Monitor learned that out-of-memory error can happen at 70 % memory usage, so it adjusts the threshold to be 60 %. The override threshold that the "adaptive" strategy sets can be removed by temporarily setting the strategy to "forced". It must be kept as "forced" for at least the memory-monitor-interval time. The override can also be removed by reducing the configured threshold value so that the new configured value is equal to, or lower than, the override threshold. The override is removed if GRE is restarted, so it is recommended to change the configured threshold to match the override threshold before restarting the GRE. forced—At out-of-memory error, it does nothing except logging the current memory usage. It forces Memory Monitor to raise an alarm only when memory usage is above the threshold. If using this approach, the threshold must be set low enough so that no out-of-memory errors occur. Temporarily setting this strategy allows the removal of the override threshold set by the "adaptive" strategy.	adaptive/forced	adaptive	Immediately
memory-monitor-adaptive-threshold-safety-margin (implemented in HF 8.5.200.12)
The safety margin percentage used by the "adaptive" strategy, when set. The new threshold, set when application memory is exhausted, is obtained by reducing this percentage amount from the percentage memory usage at the time of memory exhaustion.	integer: min 10, max 30	10	Immediately

Settings in the GRE Application Cluster

A new template for a GRE-specific application cluster—GRE_Rules_Engine_Application_Cluster_<version>.apd— is implemented in release 8.5.2. The configuration options below are set in the new application cluster, and allow you to configure how auto-synchronization works.

Description	Valid values	Default value	Takes effect
auto-synch-rules (new in 8.5.200)
Set this to true to enable a GRE in cluster to start the periodic auto synch and auto deployment process. Clustered GRE's option deployed-rules-directory-is-relative-to-shared-root must be set to true to have them participate in rules auto synch process. Option shared-root-directory can be used to specify the directory which is shared among all the clustered GREs. See option shared-root-directory for more information. If this is true, whether auto-synch-rules-at-startup is set to true or false, the GRE always auto-synchronizes rules at startup.	true/false	false	At GRE (re-)start
auto-synch-rules-interval (new in 8.5.200)
The interval in minutes between the end of the last synchronization check/auto deployment and the start of a new synchronization check.	Integer (minutes)	5 (minimum value = 1)	At GRE (re-)start
auto-synch-rules-at-startup (new in 8.5.200)
Set this option to true to have the GREs synchronize and deploy rules at startup. This value is ignored if auto-synch-rules is set to true (that is, when auto-synch-rules is true then auto-synch is always performed at startup. This is useful if rules synchronization is required only at startup when auto-synch-rules is set to false.	true/false	false	At GRE (re-)start