settings Section
- cache-business-calendars
- cache-operational-parameters
- check-expired-status-on-start
- clear-cache-on-disconnect
- deployed-rules-directory
- deployed-rules-directory-is-relative-to-shared-root
- enable-memory-monitor
- enable-memory-monitor-over-threshold-memory-cleanup
- enable-memory-monitor-update-status
- esp-worker-threads
- include-rule-evaluation-detail-in-response
- iwd-set-department-from-process
- json-hierarchical-driver
- load-packages-on-start
- max-number-rule-executions
- memory-monitor-adaptive-threshold-safety-margin
- memory-monitor-interval
- memory-monitor-threshold
- memory-monitor-threshold-strategy
- parameter-cache-timeout
- sequential-mode
- serialize-with-legacy-jettison-format
- shared-root-directory
- unload-inactive-package-timeout
- verify-deploy-address
- ignore-config-connection-status
- enable-package-serialization
cache-business-calendars
Default Value:
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.304.07, 9.0.000.13
When enabled, improves performance for rule packages using Business Calendars by enabling an in-memory cache.
If you are using the deprecated feature that allowed dynamic configuration of holidays, and so on, only for the duration of a rule execution, then enabling this caching feature will cause those dynamic configurations to apply across rules. Please confirm that this is acceptable behavior before enabling caching.
cache-operational-parameters
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.0
This option controls whether or not operational parameter values that are used within rules are cached. If true, the first time an operational parameter is used, GRS will get the current value from Configuration Server, and then monitor for updates to the value. The rules will use the cached value instead of making a request to Configuration Server for each rule execution. If set to false, caching will be disabled, and GRS will get the current value from Configuration Server on each rule evaluation request. The default value is true.
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).
check-expired-status-on-start
Default Value: False
Valid Values: true, false
Changes Take Effect: After restart
Introduced: 8.5.303.09
The configuration option load-packages-on-start determines whether to load all the rule packages on GRE startup. The check-expired-status-on-start option indicates whether to check if the rule package has previously expired from the cache or not. With value true, GRE loads only non-expired packages into memory. With value false, GRE loads all packages. Rule packages are marked as expired=true when the package has been unloaded from the cache because it has not been accessed for the period of time specified in option unload-inactive-package-timeout. When such packages are reloaded into memory, they are marked as expired=false. For the sake of backwards compatibility, if a rule package does not have the expired flag set, the package defaults to being expired=false.
clear-cache-on-disconnect
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.0
GRE is not dependent on an active Configuration Server connection except for evaluating operational parameters. This option defines whether the cache should return the cached value in the event that Configuration Server goes down or should be cleared in the event that the connection to Configuration Server is no longer active. The default value is false.
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.
deployed-rules-directory
Default Value: logs/GRE_DEPLOYDIR
Valid Values:
Changes Take Effect: After restart
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, packages defined in this directory are loaded when first referenced and made available for execution. When using shared deployment, this is considered as relative to the Shared root directory.
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.
If multiple GREs share the same host, the value of deployed-rules-directory must be unique for each GRE.
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
Introduced: 8.5.2
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, so that GRE can participate in the auto-synch process.
This option can be used even when GRE does not belong to a cluster. If this option is set to false, auto-synch will not work.
enable-memory-monitor
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
Introduced: 8.5.200.12
Enables (true) or disables (false) the memory monitor that keeps a watch on memory usage by GRE and sets the appropriate status if memory usage reaches the threshold value set in memory-monitor-threshold. Invalid or missing values are treated as value false.
enable-memory-monitor-over-threshold-memory-cleanup
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.
enable-memory-monitor-update-status
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.
esp-worker-threads
Default Value: 5
Valid Values: A positive integer greater than 4.
Changes Take Effect: After restart
The maximum number of worker threads available when using the ESP interface to execute rules.
include-rule-evaluation-detail-in-response
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.001
Setting this option to true will make GRE include the rule evaluation detail in response. This includes details of rules that did not fire, conditions that evaluated false and the 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.
iwd-set-department-from-process
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 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.
json-hierarchical-driver
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
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.
load-packages-on-start
Default Value: true
Valid Values: true, false
Changes Take Effect: After restart
Indicates whether to load deployed rule packages at application start up. If packages are not loaded at startup, then a package is loaded on its first execution request.
max-number-rule-executions
Default Value: 10000
Valid Values: Any positive integer or -1
Changes Take Effect: Next rules execution
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.
memory-monitor-adaptive-threshold-safety-margin
Default Value: 10
Valid Values: Integer, min. 10, max. 30
Changes Take Effect: Immediately
Introduced: 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.
memory-monitor-interval
Default Value: 60
Valid Values: Integer, min. 1
Changes Take Effect: After restart
Introduced: 8.5.200.12
The interval in seconds between periodic memory usage checks.
memory-monitor-threshold
Default Value: 70
Valid Values: Integer, min 1, max 99
Changes Take Effect: Immediately
Introduced: 8.5.200.12
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.
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 (and in 8.5.303.06,Java garbage collection is requested). Genesys Management layer is also notified about GRE's unavailability via a status set in the 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. See new 8.5.303.06 options enable-memory-monitor-update-status and enable-memory-monitor-over-threshold-memory-cleanup to alter this behavior.
memory-monitor-threshold-strategy
Default Value: adaptive
Valid Values: adaptive/forced
Changes Take Effect: Immediately
Introduced: 8.5.200.12
Sets the strategy used by memory monitor to determine the threshold.
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.
parameter-cache-timeout
Default Value: 168
Valid Values: A positive integer greater than 0 representing hours
Changes Take Effect: Immediately
Introduced: 8.5.0
Operational parameters can be cached in memory (see cache-operational-parameters option) and updated automatically from configuration server events. This parameter can be used to control how many hours we should cache all operational parameters in any parameter group (transaction). 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 subscription to transaction which are no longer being used.
sequential-mode
Default Value: false
Valid Values: true, false
Changes Take Effect: On rules deployment
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.
serialize-with-legacy-jettison-format
Default Value: true
Valid Values: true, false
Changes Take Effect: if json-hierarchical-driver=false
Setting the option json-hierarchical-driver=false ensures GRE responses with backward compatibility. No other changes is required from the customer if json-hierarchical-driver is false. This option is not applicable if json-hierarchical-driver=true.
Default Value:
Valid Values: Any string
Changes Take Effect: After restart
Introduced: 8.5.200
Specifies the shared root directory. When this option is used, and if 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 to the path specified in 'Deployed rules directory'. It can be used to specify the mapped path to the shared location used for Auto Synch Rules feature. Having this option empty (or not set), effectively allows setting an absolute path in option '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.
Universal Naming Convention (UNC) format is not supported where GRE runs on the AIX operating system.
unload-inactive-package-timeout
Default Value: -1
Valid Values: Any positive integer or -1
Changes Take Effect: After restart
Introduced: 8.5.1
Time (in minutes) for an inactive package to remain loaded in memory before it is automatically unloaded.
If the option is not specified, or if the value is set to -1 (default), then packages will stay loaded indefinitely with no timeout. If an invalid value (for example, -500) is entered, the value is ignored and the default value of -1 is used.
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.
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 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.
ignore-config-connection-status
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
When this option is set to true and the Configuration Server connection goes down, the status servlet will ignore the Configuration Server connection status and report that the server is available in the response code. However, the status servlet will show Configuration Server connection is down in the readable text of the response.
enable-package-serialization
Default Value: False
Valid Values: True, False
Changes Take Effect: Immediately
Introduced: 9.0.000.11
Enables package serialization globally for GRAT rules packages. Package serialization can be used to bring less frequently accessed rule packages back into service much faster, improve performance when unloading expired packages, improve performance when loading rule packages into memory and use less GRE memory.