Software AG Products 10.11 | Administering Integration Server | Server Configuration Parameters | watt.server.
 
watt.server.
watt.server
This is an internal parameter. Do not modify.
watt.server.acl.groupScanInterval
Specifies how often, in milliseconds, Integration Server checks for the availability of the My webMethods Server database, if the database is unavailable at Integration Server startup. While the database is unavailable, group information about users that are managed by Central User Management is unavailable. As a result, users in those groups do not have the access rights granted by their associated ACLs. While the My webMethods Server database is unavailable, the Security > ACLs page displays the affected groups with the suffix @--@, for example FinanceGroup@--@. When the My webMethods Server database becomes available, the groups regain their access rights and Integration Server removes the @--@ suffix. The default setting is 10,000 milliseconds (10 seconds).
watt.server.allowDirective
Restricts the use of specified directives to specified ports. For information on directives, see Controlling the Use of Directives). The syntax for this property is:
port-string is a comma-delimited list of port numbers such as "5555,6666".
Suppose you want to allow all ports to use the default directive, but you want specific ports to use the other directives, as described below:
Restrict use of the invoke directive to ports 5555 and 7777
Restrict use of the web directive to ports 6666 and 7777
Restrict use of the SOAP directive to port 7777
To obtain the behavior described above, you would specify the following:
watt.server.allowDirective=invoke,5555,7777,web,6666,7777,soap,7777
watt.server.apiportal.url
Specifies the URL for establishing a connection to API Portal and publishing a REST API descriptor. This parameter derives the API Portal URL from the following:
*Host name and port number for the API Portal connection.
*Tenant for which the REST API descriptor is to be published.
*Specification of the REST API descriptor.
watt.server.audit.dbEncoding
Specifies the character set used by the audit logging database. The default is UTF-8. The value for this property must be a standard Internet Assigned Numbers Authority (IANA)-assigned character set name, as defined in the IANA Character Sets specification.
Important:
If you change the value of this property, you must restart Integration Server for the change to take effect.
watt.server.audit.disableInternalServerConnectionSuccessLogging
Set to true if you do not want the security log to have the entry "Internal Server successfully authenticated to the Enterprise Gateway." The default value is false.
Note:
If this property is true, it is applied even when the Generate Auditing Data on property on the Logs > Logging configuration > Edit Security Logger page of IS Administrator is set to "Success" or "Success or Failure".
watt.server.audit.displayLogs.convertTime
Specifies how dates are displayed when you view the service, error, session, guaranteed delivery, and security logs from the Integration Server Administrator. When this property is set to false, time stamps are shown as GMT/UTC. When this property is set to true (the default), time stamps are shown in the local time zone of the Integration Server, and in the format specified by watt.server.dateStampFmt.
watt.server.audit.failFastLoggers
Specifies the loggers that can enter into fail-fast mode when fail-fast mode is enabled for the ISCoreAudit functional alias.
*If watt.server.audit.failFastLoggers is empty, all synchronous audit loggers that use a database destination will have fail-fast capability.
*If watt.server.audit.failFastLoggers is not empty, only the synchronous audit loggers with a database destination listed in watt.server.audit.failFastLoggers will have fail-fast capability.
Note:
Fail-fast mode is enabled for the ISCoreAudit functional alias when the Fail-Fast Mode Enabled option is set to Yes for the alias.
If you want to identify the specific audit loggers that can enter fail-fast mode, use the watt.server.audit.failFastLoggers to specify a comma-separated list of the loggers that can enter into fail-fast mode. For example, if you want the Service Logger and Session Logger to be able to enter into fail-fast mode, set the property as follows:
watt.server.audit.failFastLoggers=Service Logger,Session Logger
You must specify the word "Logger" as part of the logger name. The property is case-sensitive. You must specify the logger name as it appears on the Logs > Logging configuration page of Integration Server Administrator. Do not include a space before or after the comma that separates logger names.
Only synchronous loggers can enter fail-fast mode. Integration Server ignores any asynchronous loggers specified in the watt.server.audit.failFastLoggers property.
The default for watt.server.audit.failFastLoggers is empty. That is, the default is that all synchronous audit loggers that use a database destination will have fail-fast capability when the ISCoreAudit functional specifies Yes for the Fail-Fast Mode Enabled option.
watt.server.audit.file.fieldDelimiter
Specifies the character sequence to use to delimit fields within a log record in a file-based audit log. A valid delimiter is any character sequence where a character is any visible (printing) character (0021-007E) from the US ASCII character set. When specifying delimiter character sequences, do not use a character sequence likely to appear in a log entry. To use delimiter characters in file-based audit logs, you must specify a valid value for the watt.server.audit.file.fieldDelimiter and watt.server.audit.file.recordDelimiter parameters. If a valid value is not specified for both parameters, Integration Server writes log entries using the fixed-length format.
There is no default value for this parameter. By default, Integration Server uses fixed-length field entries for file-based audit logs.
To revert to fixed-length field entries for file-based audit logs, delete the values of the watt.server.audit.file.fieldDelimiter and watt.server.audit.file.recordDelimiter parameters and restart Integration Server.
After switching between fixed-length format and character-delimited format, Integration Server Administrator cannot display entries from the previous format.
Important:
If you change the value of this property, you must restart Integration Server for the change to take effect.
watt.server.audit.file.recordDelimiter
Specifies the character sequence to use to delimit records in a file-based audit log. A valid delimiter is any character sequence where a character is any visible (printing) character (0021-007E) from the US ASCII character set. When specifying delimiter character sequences, do not use a character sequence likely to appear in a log entry. To use delimiter characters in file-based audit logs, you must specify a valid value for the watt.server.audit.file.fieldDelimiter and watt.server.audit.file.recordDelimiter parameters. If a valid value is not specified for both parameters, Integration Server writes log entries using the fixed-length format.
There is no default value for this parameter. By default, Integration Server uses fixed-length field entries for file-based audit logs.
To revert to fixed-length field entries for file-based audit logs, delete the values of the watt.server.audit.file.fieldDelimiter and watt.server.audit.file.recordDelimiter parameters and restart Integration Server.
After switching between fixed-length format and character-delimited format, Integration Server Administrator cannot display entries from the previous format.
Important:
If you change the value of this property, you must restart Integration Server for the change to take effect.
watt.server.audit.journal.truncated
Specifies the logging level at which the full value of a field truncated in an audit log is written to the server log. When Integration Server writes a record to an audit log and a field is too large to fit in its database column, Integration Servertruncates the value in the audit log and writes the full value of the field to the server log. This applies when the server logging facility 0095 Audit Log Manageris set to the same level as watt.server.audit.journal.truncated or a more verbose level. For example, if the 0095 Audit Log Manager log level is set to Info and watt.server.audit.journal.truncated is set to Debug, the full value of the truncated field will not appear in the server log. If 0095 Audit Log Manager log level is set to Trace and watt.server.audit.journal.truncated is set to Debug, the full value of the truncated field will appear in the server log.
Valid values are: Critical, Error, Warn, Info, Debug, Trace, and Off. The default value is Info.
watt.server.audit.logDir
Specifies the directory that contains the audit log files. You can specify the full-path name, or a relative path in relation to the Integration Server. The directory must exist on the server. The default value is logs, which indicates the Integration Server_directory \instances\instance_name\logs directory. If an invalid value is specified, Integration Server uses the default value and writes an error to the server log during startup.
Important:
If you change the value of this property, you must restart Integration Server for the change to take effect.
Note that watt.server.audit.logDir does not affect audit loggers that write to a database.
watt.server.audit.logFilesToKeep
Specifies the number of audit log files, including the current log file for the audit logger, that Integration Server keeps on the file system for an audit logger that writes to a file. When Integration Server reaches the limit for the number of log files for the audit logger, each time Integration Server rotates the audit log, Integration Server deletes the oldest archived audit log file. If you set watt.server.audit.log.filesToKeep to 1, Integration Server keeps the current audit log file and no previous audit log files for each file-system based audit logger. That is, when Integration Server rotates the audit log for a logger, Integration Server does not create an archive file for the previous audit log. If you set watt.server.audit.logFilesToKeep to 0, or any value less than 1, Integration Server keeps an unlimited number of audit log files.
The default value of watt.server.log.filesToKeep is 0, indicating that there is no limit to the number of audit log files that Integration Server maintains for audit loggers that write to a file.
The watt.server.audit.logFilesToKeep parameter affects only the audit loggers configured to write to a file. The parameter does not affect audit loggers configured to write to a database nor does it affect the FailedAuditLog.
If you reduce the number of logs that Integration Server keeps for file-based audit logs and then restart Integration Server, the existing audit logs will not be pruned until Integration Server writes to the audit log. For example, if the error logger writes to a file and you reduce the number of log files to keep from 10 to 6, Integration Server does not delete the 4 oldest error audit log files immediately after start up. Integration Server deletes the 4 oldest error audit logs after the error logger writes to the error audit log.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.audit.logRotateSize
Specifies the file size at which Integration Server rolls over the audit log for a logger that writes to a file. Set this property to N[KB|MB|GB], where N is any valid integer. The minimum size at which Integration Server rotates an audit log is 33KB. If you use KB as the unit of measure, you must set N to a value greater than or equal to 33. If you do not specify a unit of measure, Integration Server treats the supplied N value as bytes. In this case, N must be greater than or equal to 32768 to take effect. Do not include any spaces between the integer and the unit of measure.
There is no default value for this parameter. That is, by default, the parameter has no value. If no value is specified for watt.server.audit.logRotateSize, Integration Server rotates the audit logs at midnight only.
If an invalid value is specified, Integration Server proceeds as if no value was specified for the parameter. If you set the value using the Extended Settings page in Integration Server Administrator, validation prevents an invalid value from being saved.
The watt.server.audit.logRotateSize parameter affects only the audit loggers configured to write to a file. The parameter does not affect audit loggers configured to write to a database.
For more information about audit logging, see the webMethods Audit Logging Guide.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.audit.schemaName
Specifies the name of the database schema that Integration Server should use while requesting metadata for the audit logging database. There is no default. If watt.server.audit.schemaName is not set, Integration Server does not retrieve database metadata and assumes the lengths of the WMSERVICECUSTOMFLDS.STRINGVALUE and WMSERVICEACTIVITYLOG.FULLMESSAGE columns are 512 and 1024, respectively.
Note:
Some databases are case-sensitive. When specifying the value for watt.server.audit.schemaName, you should match the case of the schema name with the schema name required by the database.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.audit.stdout.fieldDelimiter
Specifies the character string to delimit audit log fields within a log entry when the audit log is written to the console (STDOUT). The default value is "||" (i.e. double pipe). The values for watt.server.audit.stdout.fieldDelimiter and watt.server.audit.stdout.recordDelimiter must be different. When specifying delimiter character sequences, do not use a character sequence likely to appear in a log entry.
You can configure an audit log to write to STDOUT using the environment variable SAG_IS_AUDIT_STDOUT_LOGGERS. For more information about environment variables, see Environment Variables.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.audit.stdout.recordDelimiter
Specifies the character string to delimit the audit log records when the audit logger is written to the console (STDOUT). The default value is "&&" (i.e. double ampersand). The values for watt.server.audit.stdout.fieldDelimiter and watt.server.audit.stdout.recordDelimiter must be different. When specifying delimiter character sequences, do not use a character sequence likely to appear in a log entry.
You can configure an audit log to write to STDOUT using the environment variable SAG_IS_AUDIT_STDOUT_LOGGERS. For more information about environment variables, see Environment Variables.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.audit.um.sessionPool.min
Specifies the minimum number of sessions in the Universal Messaging session pool. Integration Server maintains a separate session pool for each Universal Messaging connection alias used by an audit logger. The value of this parameter must be an integer value greater than 0 and less than or equal to the value of watt.server.audit.um.sessionPool.max. The default value is 2.
If you specify an invalid value, Integration Server logs a warning message at start up and then uses the default value at runtime. However, Integration Server does not persist the default value over the invalid value you specified.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.audit.um.sessionPool.max
Specifies the maximum number of sessions in the Universal Messaging session pool. Integration Server maintains a separate session pool for Universal Messaging connection alias used by an audit logger. The value of this parameter must be an integer greater than 0 and greater than or equal to the value of watt.server.audit.um.sessionPool.min. The default value is 10.
If you specify an invalid value, Integration Server logs a warning message at start up and then uses the default value at runtime. However, Integration Server does not persist the default value over the invalid value you specified.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.audit.um.sessionPool.retryInterval
Specifies the number of seconds for Integration Server to wait between attempts to re-establish a session on the Universal Messaging server after an audit logger enters queue fail-fast mode. An audit logger enters queue fail-fast mode wdrehen it cannot establish a connection to the Universal Messaging server that contains the audit logging queue. Specify an integer greater than 0 (zero). The default is 30 seconds.
If you specify an invalid value, Integration Server uses the default value at runtime. However, Integration Server does not persist the default value over the invalid value you specified.
Note:
If you change the value of this property, you must restart Integration Server for the changes to take effect.
watt.server.auditDocIdField
Specifies a custom document ID value to identify documents in a standard way and to provide uniform business context in the logging display. Some documents are logged by webMethods Broker through WmLogUtil to the document database, and some are logged by various components within the Integration Server, for example, if a service fails, or if the number of retries in a trigger are exceeded. As a result, when viewing the Document Monitor, some documents are logged with a numeric document ID, and some are logged with lengthy hexadecimal strings as the document ID. The custom document ID value that you specify will be used to create the document logging ID. This value is used in place of the BrokerEvent.getEventId() value (the original document ID behavior). The value must be in the form of a Broker unicode string, and values in excess of 128 characters will be truncated. If this extended setting is missing, the original document ID behavior applies. If this extended setting is present but undefined (null), the _env.uuid value is used if present; if no _env.uuid value is defined, the original document ID behavior applies. For more information about document logging, see Administering webMethods Broker.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.auth.cache.capacity
Specifies the number of user name and password combinations Integration Server stores in the authentication cache. The default value is 250.
watt.server.auth.cache.enabled
Specifies whether the authentication cache is enabled. When set to true, the authentication cache is enabled. The default value is true.
watt.server.auth.cache.timeout
Specifies the number of milliseconds that each cache entry can remain idle before Integration Server removes it from the authentication cache. The default is 300000 (5 minutes).
Note:
Entries removed from the authentication cache are added again the next time the credentials are authenticated successfully.
Note:
Once a user has changed the password and logged in successfully with the new password, Integration Server removes the old password from the authentication cache.
watt.server.auth.checkWithSession
When Integration Server receives an HTTP request that includes both an Authorization header and a Cookie header with a session identifier, this parameter specifies whether Integration Server should check that the user identified in the Authorization header is the owner of the session identified in the Cookie header. When set to true (the default), Integration Server confirms that the user of the Authorization header is the owner of the identified in the Cookie header. If the headers do not match, Integration Server returns an HTTP 401 status code with the following message:
The user identified in the request does not own the requested session.
Important:
If you set watt.server.auth.checkWithSession to false, Integration Server allows HTTP requests to use mismatched credentials to access the services on Integration Server and, as a result, might put your applications at risk.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.auth.oauth.accessToken.useHeaderFields
Specifies whether Integration Server performs OAuth authentication when an inbound HTTP/S request includes an access_token in the header fields. Specify true to perform OAuth authentication. Specify false to skip OAuth authentication. The default is true.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.auth.oauth.accessToken.useQueryParameters
Specifies whether Integration Server performs OAuth authentication when an inbound HTTP/S request includes an access_token in the query parameter. Specify true to perform OAuth authentication. Specify false to skip OAuth authentication. The default is true.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.auth.samlResolver
Specifies the URL to the SAML artifact resolver endpoint on the My webMethods Server that will be used to validate My webMethods Server users on Integration Server. Along with configuring central user management, the value of this property allows single-sign on for My webMethods Server users. For more information, see Configuring the MWS Single Sign-On Resource Setting.
Note:Integration Server adds this property to the server.cnf file when you specify a value for the MWS SAML Resolver URL field on the Settings > Resources page of Integration Server Administrator. .
watt.server.auth.session.retainJaasSubject
Specifies whether Integration Server should retain authentication credentials as part of a session. When set to true, Integration Server retains the authentication credentials until the session expires. If set to false (the default), Integration Server deletes the authentication credentials from the session after it handles the initial request from the client.
watt.server.auth.skipForMediator
Specifies whether Integration Server validates requests from webMethods API Gateway to the native service. When this parameter is set to true, Integration Server skips authentication for API Gateway requests. When set to false (the default) Integration Server authenticates all API Gateway requests.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.autodeploy.enabled
Specifies whether automatic deployment of packages is enabled or disabled for Microservices Runtime. Set to true to enable automatic deployment of packages. Set to false to disable automatic deployment of packages. The default is false.
Note:
The automatic deployment feature is available by default for Microservices Runtime. To use the automatic deployment feature with Integration Server , your Integration Server must have additional licensing.
Important:
If you change the setting of this parameter, you must restart Microservices Runtime for the changes to take effect.
watt.server.autodeploy.interval
Specifies the interval, measured in minutes, at which Microservices Runtime executes the autodeploy system task. The autodeploy system task monitors the autodeploy folder for packages that need to be automatically deployed. Specify a value between 1 and 1440. The default is 5.
Note:
The automatic deployment feature is available by default for Microservices Runtime. To use the automatic deployment feature with Integration Server , your Integration Server must have additional licensing.
Important:
If you change the setting of this parameter, you must restart Microservices Runtime for the changes to take effect.
watt.server.autodeploy.alwaysUseHotDeployment
Specifies whether or not Microservices Runtime always uses hot deployment for automatic deployment of packages. Set to true to use hot deployment for auto deployment of packages. Set to false if you do not want to use hot deployment for automatic deployment of packages. The default is false.
Note:
The automatic deployment feature is available by default for Microservices Runtime. To use the automatic deployment feature with Integration Server, your Integration Server must have additional licensing.
Important:
If you change the setting of this parameter, you must restart Microservices Runtime for the changes to take effect.
watt.server.broker.producer.multiclient
Specifies the number of sessions for the default client. The default client is the Broker client that the Integration Server uses to publish documents to the Broker and to retrieve documents delivered to the default client. When you set this parameter to a value greater than 1, the Integration Server creates a new multi-session, shared state Broker client named clientPrefix_DefaultClient_MultiPub, to use for publishing documents to the Broker. Using a publishing client with multiple sessions can lead to increased performance because it allows multiple threads to publish documents concurrently. The default is 1 session.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.broker.replyConsumer.fetchSize
Specifies the number of reply documents that the Integration Server retrieves from the Broker at one time. Increasing the reply documents the Integration Server retrieves for each call can reduce the number of calls the Integration Server makes to the Broker. The Integration Server maintains all reply documents in memory. You can reduce the amount of memory used for reply documents by decreasing the number of documents the Integration Server retrieves at one time. The default is 5 documents.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.broker.replyConsumer.multiclient
Specifies the number of sessions for the request/reply client. The request/reply client is the Broker client that the Integration Server uses to send request documents to the Broker and to retrieve reply documents from the Broker. Increasing the number of sessions for the request/reply client can lead to improved performance because it allows multiple requests and replies to be sent and retrieved concurrently. The default is 1 session.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.broker.replyConsumer.sweeperInterval
Specifies how often (in milliseconds) the Integration Server sweeps its internal mailbox to remove expired replies to published requests. The length of the interval should balance the amount of memory consumed by expired replies with retrieving the replies for waiting requests. The Integration Server uses one background thread to age and remove expired replies and uses multiple background threads to retrieve replies for waiting requests. When the sweeper thread removes expired replies, it blocks the threads attempting to retrieve replies. When then sweeper interval is too low, the frequent execution of the sweeper thread can degrade performance because other background threads cannot retrieve replies as often. A sweeper interval that is too high can cause an increase in memory usage because expired replies consume memory for a longer period of time. The default is 30000 milliseconds (30 seconds).
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.brokerTransport.dur
Specifies the number of seconds of idle time that the Broker waits before sending a keep-alive message to Integration Server. If Integration Server does not respond within the amount of time specified by the watt.server.brokerTransport.max property, the Broker sends another keep-alive message to Integration Server. If Integration Server continues to be unresponsive, the Broker continues sending keep-alive messages until it reaches the retry limit specified by the watt.server.brokerTransport.ret property. If the Integration Server still has not responded to the keep-alive message, the Broker explicitly disconnects the Integration Server. The watt.server.brokerTransport.dur value must be an integer greater than or equal to zero but less than 2147483647. The default is 60 seconds.
For more information about using server parameters to configure the keep-alive setting with the Broker, see Setting Server Configuration Parameters for Keep-Alive Mode.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.brokerTransport.max
Specifies the number of seconds that the Broker waits for the Integration Server to respond to a keep-alive message. This value must be an integer between 0 and 2147483647. The default is 60 seconds.
For more information about using server parameters to configure the keep-alive setting with the Broker, see Setting Server Configuration Parameters for Keep-Alive Mode.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.brokerTransport.ret
Specifies the number of times the Broker re-sends keep-alive messages before disconnecting an un-responsive Integration Server. This value must be an integer between 1 and 2147483647. The default is 3 retries.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.cache.prefetchUser
Specifies the user authorized to prefetch cache service entries. The default is Administrator.
watt.server.cache.flushMins
Specifies how often (in minutes) the server sweeps the cache to remove expired cache entries and to prefetch cache service entries. The default is 10 minutes.
Note:
This configuration parameter applies to the service-results caching feature. It does not affect the caching capabilities provided by Terracotta Ehcache.
watt.server.cache.gcMins
Specifies how often (in minutes) the server sweeps the cache to perform garbage collection. The default is 60 minutes.
Note:
This configuration parameter applies to the service-results caching feature. It does not affect the caching capabilities provided by Terracotta Ehcache.
watt.server.cache.maxEntriesInCache
Specifies the default value for the Maximum Entries in Cache property for a distributed system cache used in an Integration Server cluster. The default is -1 which indicates that Integration Server does not set a default value for the Maximum Entries in Cache property. If you want Integration Server to set a default value for the Maximum Entries in Cache property, you must specify a value greater than 0.
watt.server.cachemanager.connectTimeout
Specifies the number of milliseconds a cache manager will wait while trying to connect to a server specified in the Terracotta Server Array URLs list. The default is 60000 milliseconds (i.e. 60 seconds).
Note:
Regardless of the watt.server.cacheManager.connectTimeout value, a cache manager will wait for a maximum of 300 seconds to connect to a server in the Terracotta Server Array. For example, if this property is set to 60000, the cache manager will wait for 60000 milliseconds to connect to any of the available server. If a connection is not established to any of the servers in 60000 milliseconds, an exception is thrown and then Integration Server takes the action specified by the watt.server.cluster.action.errorOnStartup parameter.
watt.server.cachemanager.logsDirectory
Specifies the location where Terracotta Ehcache will write log files. The default value of this folder is Integration Server_directory \instances\instance_name\logs\tc-client-logs
watt.server.cachemanager.parallelThreads
Specifies the maximum number of threads that you want Integration Server to use when initializing cache managers at startup.
If the server contains a large number of cache managers, distributed cache managers, or a cache manager with a large number of caches, the registration process at start up could take a long time. To avoid this, you can increase the number of threads used to initialize cache managers by setting the watt.server.cachemanager.parallel.threads property.
If you want Integration Server to initialize cache managers sequentially, set the value to 1. If you want Integration Server to initialize cache managers in parallel, set the value to 2 or higher. Software AG recommends that you do not exceed 10. The default value is 5.
watt.server.centralUsers.shutdownOnError
Specifies whether the Central Users component shuts down when it encounters an error. When this property is set to true, the Central User component shuts down when it encounters an error. When the Central Users component shuts down, the Integration Server must be restarted. When this property is set to false, the default, the Central User component does not shut down when it encounters an error.
watt.server.cgi.cache
Specifies whether the output pipeline should display all the elements in a response when using CGI content handlers to format the responses. When this property is set to false, the output pipeline displays all the elements in the response. When this property is set to true, if the response contains multiple non-string, non-null elements with the same value, the output pipeline will display only the first occurrence of the value. For each of the subsequent occurrences, the output will contain the string, *ObjectRef(className)*. The default is false.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.cgi.unicode
Specifies whether the CGI content handler should use Unicode encoding. When this property is set to false, the CGI content handler will use the encoding specified by the watt.server.netencoding property to encode responses. When this property is set to true, the CGI content handler will use Unicode to encode responses. The default is false.
watt.server.checkAclsInternally
Specifies whether Integration Server performs ACL checking when a service is directly invoked by a client or trigger and when it is invoked from other services. When set to true, Integration Server always checks the Execute ACL for a service, regardless of the value of the Enforce Execute ACL property for the service. When set to false, the value of the Enforce Execute ACL property determines whether or not Integration Server performs ACL checking when a service executes. The default is false.
watt.server.checkPath.restorePipelineFromFile
Specifies whether Integration Server verifies that the value of the filename input parameter supplied to pub.flow:restorePipelineFromFile service is in the default pipeline directory or is in the allowedReadPaths parameter of the file access control configuration file (fileAccessControl.cnf). When this parameter is set to true, Integration Server verifies that the path or directory specified in filename is included in the default pipeline directory or in the allowedReadPaths parameter. If the file is not in the allowed list, the service ends with a ServiceException. When the watt.server.checkPath.restorePipelineFromFile parameter is set to false, Integration Server does not verify that the specified filename is in the default pipeline directory or listed in the allowedReadPaths parameter. The default is true, which is the more secure option.
watt.server.checkPath.savePipelineToFile
Specifies whether Integration Server verifies that the value of filename input parameter supplied for the pub.flow:savePipelineToFile service is in the default pipeline directory or is in the allowedWritePaths parameter of the file access control configuration file (fileAccessControl.cnf). When this parameter is set to true, Integration Server verifies that the path or directory specified in filename is in the default pipeline directory or is included in the allowedWritePaths parameter. If the file is not in the allowedWritePaths list, the service ends with a ServiceException. When the watt.server.checkPath.savePipelineToFile parameter is set to false, Integration Server does not verify that the specified filename is in the default pipeline directory or listed in the allowedWritePaths parameter. The default is true, which is the more secure option.
watt.server.checkWhitelist
Specifies whether Integration Server uses a whitelist to filter the list of classes than can be used for deserialization. When this parameter is set to true, whitelist filtering is enabled. Integration Server deserializes a Java object only if the class appears in the whitelist. If Integration Server encounters a Java object whose class does not exist in the whitelist, Integration Server throws a ClassNotFoundException. By default, watt.sever.checkWhitelist is set to true, indicating whitelist class filtering is enabled.
For more information about whitelist filtering, see Whitelist Filtering in Integration Server .
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.circuitBreaker.threadPoolMax
Specifies the maximum number of threads that the server maintains in the circuit breaker thread pool which is used to execute services with a configured circuit breaker. If this maximum number is reached, the server waits until services complete and return threads to the circuit breaker thread pool before running more services with a configured circuit breaker. You must specify a value greater than 0 and greater than or equal to the value of watt.server.circuitBreaker.threadPoolMin. The default is 75.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Note:
The circuit breaker feature is available by default for a service that resides in a Microservices Runtime. To use the circuit breaker feature with Integration Server, your Integration Server must have additional licensing.
watt.server.circuitBreaker.threadPoolMin
Specifies the minimum number of threads that the server maintains in the circuit breaker thread pool which is used to executes services with a configured circuit breaker. When the server starts, the circuit breaker thread pool initially contains this minimum number of threads. The server adds threads to the pool as needed until it reaches the maximum allowed, which is specified by the watt.server.circuitBreaker.threadPoolMax. You must specify a value greater than or equal to 0 (zero) and less than or equal to the value of watt.server.circuitBreaker.threadPoolMax. The default is 10.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Note:
The circuit breaker feature is available by default for a service that resides in a Microservices Runtime. To use the circuit breaker feature with Integration Server, your Integration Server must have additional licensing.
watt.server.classloader.pkgpriority
Specifies the order in which Integration Server scans packages when loading a class file for which no package information is available. When no order is specified, Integration Server attempts to load the class by scanning all packages in the Packages directory, one by one. This could delay class loading. For example, when a trigger contains a reference to a Java class, the trigger does not have any package information. Integration Server scans all the packages for the specific class file in random order. Specifying the packages that Integration Server should scan first may reduce the time needed for class loading.
Use the watt.server.classloader.pkgpriority property to specify a comma delimited list of the packages whose class loader should load first. The syntax for this property is:
watt.server.classloader.pkgpriority=packageName, packageName
For more information about class loading, refer to Class Loading in Integration Server .
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.clientTimeout
Specifies the amount of time (in minutes) after which an idle user session that has been reused times out. The default is 10.
The watt.net.http.clientSession.idleTimeout parameter determines how many milliseconds a newly created outbound HTTP/S session can be idle before the session times out and can be removed by the session sweeper.
watt.server.clientTimeoutRedirect
Specifies how Integration Server Administrator behaves when the browser session times out. When this parameter is set to true, Integration Server Administrator redirects you to a blank page with an option to resume, which prompts you to log in. On successful login, the home page is displayed. When set to false, which is also the default value, Integration Server Administrator prompts you to log in, while retaining the current page contents in the background. On successful login, you can resume from the same page.
watt.server.cluster.action.errorOnStartup
Specifies how Integration Server responds when an error at start up prevents Integration Server from joining the cluster. Select one of the following:
Value
Description
shutdown
If Integration Server encounters any errors that prevent it from joining the cluster at start up, Integration Server shuts down immediately. To make any changes to the clustering configuration, you must start Integration Server in safe mode, then edit the configuration, and then restart Integration Server.
shutdown corresponds to the Action on Startup Error parameter option Shut Down Integration Server on the Settings > Clustering > Edit cluster settings page.
standalone
If Integration Server encounters any errors that prevent it from joining the cluster at start up, Integration Server starts as a stand-alone, unclustered Integration Server. Integration Server continues to receive requests on inbound ports and serve requests. Integration Server does not use any distributed caches and instead uses local caches. You can use Integration Server to make changes needed to resolve the startup errors. When you restart Integration Server, Integration Server will rejoin the cluster if Integration Server does not encounter any start up errors that prevent the connection to the Terracotta Server Array.
This is the default value.
standalone corresponds to the Action on Startup Error parameter option Start as Stand-Alone Integration Server on the Settings > Clustering > Edit cluster settings page.
quiesce
If Integration Server encounters any errors that prevent it from joining the cluster at start up, Integration Server starts as a stand-alone, unclustered Integration Server in quiesce mode. When Integration Server is in quiesce mode, only the diagnostic port and quiesce port are enabled. Integration Server will not receive requests on inbound ports. However, you can use Integration Server and Integration Server Administrator to make changes needed to correct the startup errors. After correcting the errors, exit quiesce mode. When exiting quiesce mode, Integration Server starts all the cache managers and joins the cluster.
If Integration Server encounters any errors that prevent it from joining the cluster when exiting quiesce mode, Integration Server does not re-enter quiesce mode. Instead, Integration Server runs as an unclustered, stand alone server. Integration Server captures any errors that occurred while attempting to join the cluster in a report displayed in Integration Server Administrator when the server exits quiesce mode. Use the report and error logs to help correct the underlying configuration errors. Then, to rejoin the cluster, either restart Integration Server or enter and then exit quiesce mode.
To use the quiesce option, a quiesce port must be configured for Integration Server. If a quiesce port is not configured and the quiesce option is selected, when Integration Server encounters any errors that prevent it from joining the cluster at start up, Integration Server shuts down instead of entering quiesce mode.
quiesce corresponds to the Action on Startup Error parameter option Enter Quiesce Mode on Stand-Alone Integration Server on the Settings > Clustering > Edit cluster settings page.
For more information about quiesce mode, see Quiescing the Server for Maintenance.
The watt.server.cluster.action.errorOnStartup parameter displays the value specified in the Action On Startup Error parameter on the Settings > Clustering and Settings > Clustering > Edit cluster settings pages of Integration Server Administrator.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.cluster.aliasList
Specifies a comma-delimited list of aliases for remote Integration Servers in a cluster. The Integration Server uses this list when executing the remote invokes that update the other cluster nodes with trigger management changes. When this property is configured, the Messaging > webMethods triggers > Cluster View page will be visible and the Apply Change Across Cluster check box will be available when performing trigger management tasks.
This parameter is applicable only when you are using webMethods clustering. For more information, see the webMethods Integration Server Clustering Guide.
watt.server.cluster.aware
Specifies whether you want the server to participate in a cluster. A value of true indicates that clustering is enabled for the server. The default is false.
The value of the watt.server.cluster.aware parameter is tied to the value of the Clustering Status field on the Settings > Clustering page in Integration Server Administrator.
This parameter is applicable only when you are using this Integration Server in a cluster.
Important:
You must restart Integration Server for changes to take effect.
Note:
If watt.server.cluster.aware is set to true, you must also specify values for the watt.server.cluster.tsaURLs and watt.server.cluster.name parameters.
watt.server.cluster.name
Specifies the name of the cluster to which Integration Server belongs. If Integration Server does not belong to a cluster, this parameter is empty.
Keep the following in mind when specifying the cluster name:
*The cluster name cannot include any periods “.”. Integration Server converts any periods in the name to underscores when you save the cluster configuration.
*The cluster name cannot exceed 32 characters. If it does, Integration Server uses the first 20 characters of the supplied name and then a hash for the remaining characters.
The watt.server.cluster.name parameter displays the value specified in the Cluster Name parameter on the Settings > Clustering and Settings > Clustering > Edit cluster settings pages of Integration Server Administrator.
Important:
You must restart Integration Server for changes to take effect.
Note:
If watt.server.cluster.aware is set to true, you must also specify values for the watt.server.cluster.tsaURLs and watt.server.cluster.name parameters.
watt.server.cluster.SessTimeout
Specifies number of minutes that the server allows inactive session objects to remain in the cluster store before removing them. The default is 60.
This parameter is applicable only when you are using webMethods Integration Server Clustering. For more information, refer to the webMethods Integration Server Clustering Guide.
watt.server.cluster.tsaURLs
A comma-separated list of the Terracotta Server Array URLs that the cluster uses for distributed system caches. This parameter is applicable only when Integration Server belongs to a cluster.
The watt.server.cluster.tsaURLs parameter is tied to Terracotta Server Array URLs parameter on the Settings > Clustering and Settings > Clustering > Edit cluster settings page in Integration Server Administrator.
Important:
You must restart Integration Server for changes to take effect.
Note:
If watt.server.cluster.aware is set to true, you must also specify values for the watt.server.cluster.tsaURLs and watt.server.cluster.name parameters.
watt.server.coder.bincoder.trycontextloaderfirst
Specifies whether Integration Server uses the context loader before using the class loader for the currently executing thread when Integration Server encodes or decodes a pipeline. If a referenced class belongs to a particular package, it may be faster to use the context loader first. The default is false.
watt.server.coder.responseAsXML
Specifies how Integration Server receives the XML response for any REST API request. When this property is set to true, Integration Server receives the XML response for any REST API in proper XML format. When this property is set to false, Integration Server receives the XML response for any REST API in converted XML format containing IData objects. The default is true.
Important:
You must restart Integration Server for changes to take effect.
watt.server.commonmessaging.connection.retryPeriod
Specifies the length of time, in seconds, that Integration Server waits between connection attempts when a connection to the MQTT server fails. The default is 20 seconds.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.commonmessaging.trigger.monitoringInterval
Specifies the interval, measured in seconds, at which Integration Server executes resource monitoring services for MQTT triggers. A resource monitoring service is a service that you create to check the availability of resources used by an MQTT trigger service. After Integration Server stops an MQTT trigger because all retry attempts have failed, it schedules a system task to execute the resource monitoring service assigned to the MQTT trigger. The default is 60 seconds.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.commonmessaging.trigger.restartTaskRetryCount
Specifies the maximum number of retry attempts the trigger restart task makes to start MQTT triggers automatically. Integration Server makes the initial start attempt for an MQTT trigger when starting the MQTT connection alias used by the trigger. If any MQTT triggers fail to start when the alias starts, Integration Server uses a trigger restart task to retry starting the failed MQTT triggers. The restart task, which uses a separate thread from the thread used to start the alias, runs at an interval specified by the watt.server.commonmessaging.trigger.restartTaskRetryInterval parameter. Integration Server also uses a restart task when triggers fail at run time. For example, if the MQTT connection alias becomes unavailable, the MQTT trigger eventually fails.
To use a restart task, you must specify a positive integer greater than or equal to 1. The default is 6 retry attempts. Set watt.server.commonmessaging.trigger.restartTaskRetryInterval to 0 if you do not want Integration Server to attempt to restart MQTT triggers automatically.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.commonmessaging.trigger.restartTaskRetryInterval
Specifies the number of seconds that the trigger restart task waits between attempts to restart MQTT triggers. You must specify a positive integer. The default is 30 seconds.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.commonmessaging.trigger.reuseSession
Indicates whether instances of an MQTT trigger use the same session on Integration Server. When this property is set to true, the MQTT trigger uses a shared session. Each of the trigger services executed by the MQTT trigger will use the same session ID. When this property is set to false, Integration Server uses a new session for each instance of a MQTT trigger. Reusing sessions for an MQTT trigger might improve performance. The default is false.
watt.server.commonmessaging.trigger.stopRequestTimeout
Specifies the maximum amount of time, measured in seconds, that Integration Server waits after an MQTT trigger is disabled before forcing the MQTT trigger to stop processing messages. The minimum value is 0. The default is 3 seconds.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.compile
Specifies the compiler command that Integration Server uses to compile Java services that are developed using Designer, for example, javac -classpath {0} -d {1} {2}. This compiler command is also used from the jcode utility. If this property is omitted or empty, the server uses the JVM internal Java compile tool to compile Java services.
Note:
If you use the watt.server.compile property to have Integration Server use a different compiler, and that compiler returns errors and warnings to standard out rather than standard error, set watt.server.compile.readFromStdErr to false so that the compiler errors and warnings will be read and displayed to the Java developer.
watt.server.compile.exitOnError
Specifies whether the jcode utility should stop processing after it fails. If set to true, the jcode utility stops processing at the package on which it fails. If set to false (the default), the jcode utility will continue processing despite the failure.
watt.server.compile.readFromStdErr
Specifies from where Integration Server reads compiler errors and warnings. The Software AG webMethods platform includes javac, the Java tool used to compile Java services in Designer and with the jcode utility. The javac compiler returns information about any errors or warnings it encountered during compilation to standard error. If you use the watt.server.compile property to have Integration Server use a different compiler, and that compiler returns errors and warnings to standard out rather than standard error, set watt.server.compile.readFromStdErr to false so that the compiler errors and warnings will be read and displayed to the Java developer. Set watt.server.compile.readFromStdErr to true for Integration Server to read compiler errors and warnings from standard error. The default is true.
watt.server.compile.unicode
Specifies the compiler command that Integration Server uses to compile Java services that are stored in Unicode encoding, for example, javac -encoding Unicode -classpath {0} -d {1} {2}. Note that the setting “javac -encoding Unicode -classpath {0} -d {1} {2}” works with the Oracle JDK compiler. This compiler command is also used from the jcode utility. If this property is omitted or empty, the server uses the JVM internal Java compile tool to compile Java services.
watt.server.content.type.default
Specifies what content type to use for HTTP requests that do not contain a Content-Type header. The default value is application/octet-stream.
Note:
If you do not specify a value for watt.server.content.type.default and the Content-Type header is empty, Integration Server assigns the default value of application/octet-stream. In this case, you must create a content handler for application/octet-stream.
To specify that Integration Server should use a different Content-Type, change the value of watt.server.content.type.default to a different registered content type, such as text/xml or text/html. If you set the value of watt.server.content.type.default to an unregistered content type, Integration Server treats requests with a Content-Type header as if they are text/html.
Changes to this property take effect immediately.
watt.server.content.type.mappings
Specifies a one-to-one mapping of content-types, including mapping wild-carded content types to a specific content type.
One use of this parameter is for mapping wildcards found in the Accept header field of an HTTP client request to specific content types. The Accept header field specifies which content type or types the client will accept in a response. Integration Server selects an outbound content handler based on the allowed content type.
Another use of this parameter is for specifying the content handler to use for particular content type in an inbound request.
The syntax for this parameter is:
watt.server.content.type.mappings=<wildcard> <content-type>,<wildcard> <content-type>,<wildcard> <content-type> ...
Where:
*wildcard is a wild-carded content type, such as text/*, or the content type without a wildcard character
*content-type is the specific content type to use for the wild-carded content type or the specified content type without a wildcard character.
Use a space to separate the wildcarded content type from the specific content type. Use a comma to separate <wildcard> <content-type> pairs from other pairs. Consider the following examples:
To associate text/* with text/xml, specify:
watt.server.content.type.mappings=text/* text/xml
To associate text/* with text/xml, and multipart/* with multipart/related, specify:
watt.server.content.type.mappings=text/* text/xml,multipart/* multipart/related
Integration Server parses the Accept header and attempts to select a content type or types as defined in the W3C Hypertext Transfer Protocol specification.
The default setting is text/* text/xml. If this parameter is not specified, and an Accept header field specifies a wildcard, Integration Server selects a content handler based on the major content type specified, as shown below.
This Accept Header field
Results in this content handler
text/*
XML
application/*
CGI
multipart/*
Multipart
The watt.server.http.useAcceptHeader property must be set to true for the watt.server.content.type.mappings parameter to work.
To use watt.server.content.type.mappings to map the application/xml content type to the text/xml content type so that Integration Server uses the text/xml content handler for an inbound request instead of the application/xml content handler, specify the following:
watt.server.content.type.mappings=application/xml text/xml
For more information about content handlers, refer to Content Handlers in Integration Server .
watt.server.control.controlledDeliverToTriggers.delayIncrementInterval
Specifies the interval used in conjunction with watt.server.control.controlledDeliverToTrigger.delays to determine the delay that Integration Server applies to services publishing documents locally when the trigger document store reaches 90% of its capacity. The default is 2000.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.control.controlledDeliverToTriggers.delays
Specifies a comma-separated list of values specifying the number of milliseconds that Integration Server delays services publishing local documents when the trigger document store is greater than or equal to 90% of its capacity. Integration Server changes the delay based on how long the trigger document store has continuously been at 90% or higher capacity. The default value is 500,2000,3000,3500,4000,4500,5000.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.control.controlledDeliverToTriggers.pctMaxThreshold
Specifies the trigger queue threshold at which the Integration Server slows down the delivery rate of locally published documents. This threshold is expressed as a percentage of the trigger queue capacity. For example, if you specify 80, the Integration Server decreases the rate at which it delivers locally published documents to a trigger queue when that trigger queue reaches 80% capacity. Integration Server resumes delivering documents at the normal rate when the trigger queue capacity drops below the specified threshold. The default is 90.
watt.server.control.freeMemoryThreshold
Specifies the threshold (as a percentage) at which Integration Server starts to warn of insufficient free memory. When the percentage of available free memory falls below the value of this property, Integration Server generates a warning in the server log. Valid values are 0 to 100. The default is 5.
watt.server.control.maxPersist
Specifies the capacity of the outbound document store. Integration Server places published documents in the outbound document store when the configured Broker is unavailable. When the number of documents in the outbound document store equals the capacity, the Integration Server blocks any threads executing services that publish documents. The Integration Server resumes execution of blocked threads after the Broker becomes available. Set this parameter to a whole number greater than 0. The default is 500,000 documents.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.control.maxPublishOnSuccess
Specifies the maximum number of documents that the server can publish on success at one time. For example, suppose that you set the maximum to 100 documents. ServiceA publishes 10 documents on success. ServiceB publishes 90 documents on success. ServiceC publishes 5 documents on success. ServiceA and ServiceB can publish documents concurrently. However, if ServiceC begins to publish documents before ServiceA or ServiceB completes, the Integration Server throws an exception for ServiceC because the documents published by ServiceC exceed the maximum number of documents that can be published on success at one time. If ServiceD publishes 125 documents on success and the maximum is 100, ServiceD will receive an exception every time it executes. The default is 50,000 documents.
watt.server.control.memorySensorInterval
The time interval (in milliseconds) at which the Integration Server will check the available free memory. The default is 300000 (5 minutes).
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.control.serverThreadThreshold
Specifies the threshold at which Integration Server starts to warn of insufficient available threads. When the percentage of available server threads goes below the value of this property, Integration Server generates a journal log message indicating the current available thread percentage and stating "Available Thread Warning Threshold Exceeded." When you receive this message in the journal log, you can adjust the thread usage to make server threads available.
The default is 15%.
Note:
It is recommended that you use the Available Threads Warning Threshold field in the Edit Resource Settings page of the Integration Server Administrator to set the threshold value. For more information about setting an available threads warning threshold, see Managing the Server Thread Pool.
watt.server.control.threadSensorInterval
Specifies the interval, measured in milliseconds, at which Integration Server will monitor the thread usage. When the percentage of available server threads goes below the threshold value specified in the watt.server.control.serverThreadThreshold property, Integration Server will generate a journal log message to warn of insufficient available threads. The default is 2000 milliseconds.
watt.server.control.triggerInputControl.delayIncrementInterval
Specifies the interval used in conjunction with watt.server.control.triggerInputControl.delays to determine the frequency with which Integration Server polls a trigger client queue on the Broker if the queue was empty when it was last polled. The default is 10000.
Note:
If an exception occurs when parsing the supplied values for watt.server.control.triggerInputControl.delays or watt.server.control.triggerInputControl.delayIncrementInterval, Integration Server resets both configuration parameters to the default values.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
For more information about controlling the polling frequency for trigger client queues on the Broker, see Delaying Polling Requests for webMethods Messaging Triggers.
watt.server.control.triggerInputControl.delays
Specifies a comma-separated list of values specifying the number of milliseconds that Integration Server delays the polling of a trigger client queue on the Broker. Integration Server changes the delay based on how long the trigger client queues has been empty. The default value is 500,1000,1500,5000.
Note:
If an exception occurs when parsing the supplied values for watt.server.control.triggerInputControl.delays or watt.server.control.triggerInputControl.delayIncrementInterval, Integration Server resets both configuration parameters to the default values.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
For more information about controlling the polling frequency for trigger client queues on the Broker, see Delaying Polling Requests for webMethods Messaging Triggers.
watt.server.cors.allowedOrigins
Specifies the URIs from which Integration Server is to allow cross-origin requests to access resources.
As recommended by the CORS (Cross-Origin Resource Sharing) standard, Integration Server uses the values of this parameter to validate the request. Integration Server checks the URI specified in the Origin header of the CORS request. If it does not match a URI specified by this parameter, Integration Server refuses the request and returns an HTTP 403 status code with the following message:
Specified Origin is not allowed
If the URI matches a value specified by this parameter, Integration Server sends a response with the CORS Access-Control-Allow-Origin response header back to the requesting user agent.
You can set this parameter to a comma- or space-separated list of URIs or the absolute path to a file. You cannot specify a combination of these.
To define this parameter using a comma- or space- separated list of URIs, enter protocol://hostname or protocol://hostname:portnumber. You can specify the IP address or the name of the machine for hostname. The values are case-sensitive. Use a space or comma delimiter to specify multiple values.
To define this parameter using a text file set the value to:
file:pathToFile\filename
For example: watt.server.cors.allowedOrigins=file:c:\cors\allowedOriginsList.txt
The file must use the same syntax as is required for the watt.sever.cors.allowedOrigins with the difference that each line must be an allowed origin server URI or a regular expression.
You can invoke the following URL to execute the internal service that causes the referenced text file to be loaded into Integration Server: http://host:port/invoke/wm.server.admin:refreshAllowedOrigins
Note:
The IP address and host name cannot be used interchangeably. If you specify a host name, and a cross-origin request is received that uses the corresponding IP address or vice versa, Integration Server will reject the request.
You can use an asterisk (*) to indicate that any URI or origin is allowed.
Note:
You cannot use the asterisk to indicate URIs if watt.server.cors.supportsCredentials is set to true.
You can also use regular expressions in the comma-separated list of allowed origin servers which can make the list of origin servers easier to maintain. Integration Server treats any value in the comma-separated list that begins with "r:" as a regular expression. Integration Server treats any value that does not begin with "r:" as a simple string. The server configuration parameter uses the Java regular expression syntax, as documented at https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html. A regular expression value must match the entire value of the Origin header in the HTTP request for it to be considered a match.
Example:
watt.server.cors.allowedOrigins=http://test1.domain.com,r:https?://.*.test2.domain.com:[0-9]+,r:.+\.[a-zA-Z]*-int.domain.com
Integration Server treats the first value, "http://test1.domain.com", as a simple string. If an Origin header contains this value, it will be allowed.
The second value, "r:https?://.*.test2.domain.com:[0-9]+", contains a regular expression. The "r:" is not part of the regular expression. The actual regular expression used to match supplied Origin headers is "https?://.*.test2.domain.com:[0-9]+".
The third value, "r:.+\.[a-zA-Z]*-int.domain.com", contains a regular expression. The "r:" is not part of the regular expression. The actual regular expression used to match supplied Origin headers is ".+\.[a-zA-Z]*-int.domain.com".
"Origin: http://test1.domain.com" will be allowed because it is equal to the first value.
"Origin: http://my.test2.domain.com:8080" will be allowed because it matches the second value.
"Origin: https://my.test2.domain.com:8088" will be allowed because it matches the second value.
"Origin: http://my.test2.domain.com" will not be allowed. If it had a port number, it would match the second value.
"Origin: nbps://example.prod-int.domain.com" will be allowed because it matches the third value.
"Origin: example.qa.staging-int.domain.com" will be allowed because it matches the third value.
"Origin: example.dev1-int.domain.com" will not be allowed. If the second token of the host name did not include any digits, it would have matched the third value.
Regular expressions that match any host name, IP address and port (e.g. "r:.+" and "r:.*") will have the same effect as "*".
Note:
When CORS is enabled, Integration Server evaluates the list of regular expressions in watt.server.cors.allowedOrigins sequentially for every request. Integration Server performs a regular expression match operation on each regular expression until a match is found or all regular expressions in the list have been evaluated. Software AG recommends that you put the more frequently matched regular expressions at the beginning of the comma-separated list.
Note:
You must specify a value if the watt.server.cors.enabled parameter is set to true.
watt.server.cors.enabled
Specifies whether Integration Server is to support CORS. If this parameter is set to true, Integration Server allows cross-origin requests. The default value is false.
Note:
In a webMethods Enterprise Gateway configuration, enable support for CORS only on the Enterprise Gateway Server.
For more information about using CORS with Integration Server, see Using CORS with Integration Server . For instructions on how to configure Integration Server to allow cross-origin requests, see Configuring Integration Server to Accept CORS Requests.
watt.server.cors.exposedHeaders
Specifies the values Integration Server can include with the CORS Access-Control-Expose-Headers header in response to a CORS request. The CORS Access-Control-Expose-Headers header defines the headers that can be exposed to the user agent. Examine your client-side code to determine which response headers, if any, are retrieved by the client and need to be exposed.
The value for this parameter is not case-sensitive. Use a space or comma delimiter to specify multiple values. For example:
watt.server.cors.exposedHeaders=<value1,value2,value3>
As determined by the CORS (Cross-Origin Resource Sharing) standard, the following are considered simple response headers and are always exposed: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma.
watt.server.cors.host
Specifies the host and port on which clients send cross-origin requests to Integration Server. Integration Server uses this value to validate the Host header in the cross-origin request. For improved security, Software AG recommends that you define this parameter if support for CORS is enabled (that is, watt.server.cors.enabled is set to true).
To define this parameter, enter hostname:port or hostname. You can specify the IP address or the name of the machine for hostname. The value for this parameter is case-sensitive. If a value is not provided for this parameter, Integration Server does not validate the Host header in the request. If a value is provided but does not match the Host header in the request, Integration Server returns a 403 response with the message.
Note:
The IP address and host name cannot be used interchangeably. If you specify a host name, and a cross-origin request is received that uses the corresponding IP address or vice versa, Integration Server will reject the request.
watt.server.cors.maxAge
Specifies the amount of time in seconds a user agent is allowed to cache the results of a preflight request. Integration Server uses this value in the CORS Access-Control-Max-Age response header.
The default is -1, which indicates the results do not remain on the client. The value must be an integer.
watt.server.cors.supportsCredentials
Specifies whether Integration Server is to set the CORS Access-Control-Allow-Credentials header in response to all CORS requests.
When set to true, Integration Server sets the CORS Access-Control-Allow-Credentials header to true in the response. When setting this parameter to true, keep the following points in mind:
*If the user credentials are valid and the user is authorized to access the resources, Integration Server will execute a CORS simple request with credentials. The user agent will display the response to the user.
*When Integration Server responds to a CORS preflight request, the response includes the Access-Control-Allow-Credentials header set to true so the user agent will allow the request with credentials.
Note:
User credentials can be cookies, HTTP authentication, or client-side SSL certificates.
When set to false (the default), Integration Server does not set the CORS Access-Control-Allow-Credentials header in the response. When setting this parameter to false, keep the following points in mind:
*If the user credentials are valid and the user is authorized to access the resources, Integration Server will execute a CORS simple request with credentials. The user agent will not display the response to the user.
*When Integration Server responds to a CORS preflight request, the response does not include the Access-Control-Allow-Credentials header, so the user agent will not allow the request with credentials.
Note:
For security reasons, Software AG recommends using the default setting (false) for this parameter. When set to false, the user agent ignores the cookies sent in the response. When this parameter is set to true, Software AG highly recommends using CSRF protection to safe guard your resources. For a more secure approach, consider using another standard, such as OAuth, for accessing authorized resources instead of relying on credentialed requests.
watt.server.cors.supportedHeaders
Specifies the request headers Integration Server will allow in cross-origin requests. Integration Server uses the value to validate the CORS Access-Control-Request-Header request header. If the header is not an exact match of a value specified by watt.server.cors.supportedHeaders, Integration Server refuses the request and returns an HTTP 403 status code with the following message:
Header not supported
If the header matches the value specified by this parameter, Integration Server responds with the CORS header Access-Control-Allow-Headers populated with the value of this parameter.
Examine your server-side code to determine which request headers, if any, are read by your server application and need to be explicitly allowed.
The value for this parameter is case-sensitive. Use a space or comma to separate multiple request headers. For example,
watt.server.cors.supportedHeaders=<header1,header2,header3>
As determined by the CORS (Cross-Origin Resource Sharing) standard, the following are considered simple request headers and are always exposed: Accept, Accept-Language, Content-Type (when the value is application/x-www-form-urlencoded, multiplart/form-data, or text/plain).
watt.server.cors.supportedMethods
Specifies the HTTP methods Integration Server will allow in cross-origin requests. Integration Server uses this value to validate the value of the CORS Access-Control-Request-Method request header. If the header is not an exact match of a value specified by watt.server.cors.supportedMethods, Integration Server refuses the request and returns an HTTP 403 status code with the following message:
Method not supported
If the header matches a value specified by this parameter, Integration Server responds with the CORS header Access-Control-Allow-Headers populated with the value of this parameter.
Use a space or comma to separate multiple HTTP methods. Possible values are OPTIONS, HEAD, GET, POST, PUT, PATCH, and DELETE. Integration Server accepts any of these values by default.
watt.server.createPackage.ignorePattern
Specifies a semicolon delimited list of the file types you do not want Integration Server to include when publishing packages. You can use this parameter to specify the file types to exclude when publishing packages through replication and deploying packages. For example, to prevent Integration Server from publishing .svn files, you would specify the parameter as watt.server.createPackage.ignorePattern=.svn.
You can specify several file types using a semi-colon (;) as a delimiter, as follows:
watt.server.createPackage.ignorePattern=.svn;.java;.xml
watt.server.cronMaxThreads
The maximum number of threads maintained for the cronjob-based threadpool, which Integration Server uses for scheduled system tasks. If this maximum number is reached, Integration Server waits until processes complete and return threads to the pool before running more processes. The default is 5.
watt.server.cronMinThreads
The minimum number of threads maintained for the cronjob-based threadpool, which Integration Server uses for scheduled system tasks. When Integration Server starts, the thread pool initially contains this minimum number of threads. The default is 2.
watt.server.dashboard.api.responseTime.threshold
Specifies the threshold used to determine if an API execution has a slow enough response (execution) time to be flagged with a red background in the Maximum response time column on the API tab on the Dashboard.
The threshold is a percentage that is multiplied with the existing average API response time to determine if a particular execution of the service is slow enough to warrant the red background on the API tab.
Specify an integer greater than 0 and less than the maximum value for an unsigned Integer data type (4294967295). The default is 50.
If you specify a value that does not meet the requirements, Integration Server resets the parameter to the default value of 50.
Integration Server uses the threshold value in the following formula to determine if the maximum response time for a particular API execution needs to be flagged.
Maximum Response Time > Average Response Time + (Average Response Time x Threshold%)
Where:
Average Response Time is the average of all the response times for invocations of that API in the time period selected in the top right corner of the Dashboard.
Threshold is the value of watt.server.dashboard.api.responseTime.threshold.
For example, suppose that watt.server.dashboard.api.responseTime.threshold is set to 20 and the average response time for myRestAPI is 100 milliseconds.
100 ms + (100 ms x 0.20) = 120 ms
If the maximum response time for an invocation of myRestAPI exceeds 120 ms, the cell for the maximum response time of myRestAPI will have a red background on the API tab in the Dashboard.
watt.server.dashboard.diskspace.threshold
Specifies the threshold as a percentage of total disk space, which is used to determine the red portion of the Disk Space card on the Overview tab of the Dashboard. Specify an integer from 0 to 100. The default value is 20.
This parameter applies to an Integration Server without a Microservices license only. For Microservices Runtime or an Integration Server with a Microservices license, the value of the Free disk space threshold property for the Diskspace health indicator is used to calculate the red portion of the Disk Space card.
watt.server.dashboard.memory.threshold
Specifies the threshold as a percentage of total memory, which is used to determine the red portion of the Memory card on the Overview tab of the Dashboard. Specify an integer from 0 to 100. The default value is 20 for Integration Server.
This parameter applies to an Integration Server without a Microservices license only. For Microservices Runtime or an Integration Server with a Microservices license, the value of the Free memory threshold property for the Memory health indicator is used to calculate the red portion of the Memory card.
watt.server.dashboard.service.responseTime.threshold
Specifies the threshold used to determine if a specific service execution has a slow enough response (execution) time to be flagged with a red background in the Maximum response time column in the Service instances tab on the Dashboard.
The threshold is a percentage that is multiplied with the existing average service response time to determine if a particular execution of the service is slow enough to warrant the red background in the Service instances tab.
Specify an integer greater than 0 and less than the maximum value for an unsigned Integer data type (4294967295). The default is 50.
If you specify a value that does not meet the requirements, Integration Server resets the parameter to the default value of 50.
Integration Server uses the threshold value in the following formula to determine if the maximum response time for a particular service execution needs to be flagged.
Maximum Response Time > Average Response Time + (Average Response Time x Threshold%)
Where:
Average Response Time is the average of all the response times for invocations of that service in the time period selected in the top right corner of the Dashboard.
Threshold is the value of watt.server.dashboard.service.responseTime.threshold.
For example, suppose watt.server.dashboard.service.responseTime.threshold is set to 20 and the average response time for serviceA is 100 milliseconds.
100 ms + (100 ms x 0.20) = 120 ms
If the maximum response time for an invocation of serviceA exceeds 120 ms, the cell for the maximum response time of serviceA will have a red background in the Service instances tab on the Dashboard.
watt.server.dateStampFmt
Specifies the date format to use in the log files. For the server log, this parameter specifies how the date format is displayed in the server log file as well as in Integration Server Administrator. For all other logs, such as the service, error, session, guaranteed delivery, and security logs, this parameter specifies how the date format is displayed only in Integration Server Administrator.
Note:
In order to use this parameter to specify the date format for the service, error, session, guaranteed delivery, and security log files, the watt.server.audit.displayLogs.convertTime must be set to true. For usage information, see watt.server.audit.displayLogs.convertTime.
To specify the date format to use, you can use any format that is supported by the Java class java.text.SimpleDateFormat. For example, to display the date with the format 08-12-02 14:44:33:1235, specify dd-MM-yy HH:mm:ss:SSSS.
watt.server.date.SuppressPatternError
Specifies how the server should respond if no input is passed to the pub.date:dateTimeFormat service. When set to true, the server simply returns a null value for the value parameter. The default is for the server to throw an exception.
watt.server.db.blocktimeout
Specifies the maximum time in milliseconds the server is to block a request when waiting for a connection to a database. (The database must be defined by an alias in the WmDB package.) The default is to wait indefinitely. Specifying -1 also means to wait indefinitely. This property is global to all pools.
watt.server.db.connectionCache
Specifies how the server manages connections to a database.
Specifying server tells the server to maintain a pool of connections for each database that is defined to the server through an alias. If a request cannot be satisfied because the pool has reached its maximum number of connections, the server blocks the request and tries again later.
Specifying session tells the server to create a database connection per session. That is, when the server receives a service request that requires a database connection, it will create a new connection if one doesn't already exist for that session; otherwise the server will use the connection that was previously created for that session. If the attempt to create a connection for the session fails, for example because the database has no available slots for connections, the request fails. The default is session.
Although enabling database connection pooling creates a pool for each database defined to your server, you can control the characteristics of each pool individually by using the Edit Alias Information page of the Integration Server Administrator. See the WmDB User’s Guide for more information about configuring the server to connect to a database.
watt.server.db.maintainminimum
Specifies how the server handles purging inactive connections that have timed out. With the parameter set to false, the server purges all of these connections. With the parameter set to true, the server purges these connections, but stops when a minimum number of connections in the pool has been reached. You specify the minimum when you define the alias. This property is global to all pools.
watt.server.db.share.ISInternal
Indicates whether the Integration Server ISInternal Functional Alias on the Integration Server Administrator JDBC Pools page refers to the same database that other Integration Servers use, even though the Integration Servers are not clustered. Set this property to true to indicate that the Integration Server shares the same ISInternal database. Setting the property to true is necessary if you want to use guaranteed delivery on multiple Integration Servers that are not clustered but share the ISInternal database. You must set this property to true for all Integration Servers that share the ISInternal database. Set this property to false if the Integration Server does not share the ISInternal database with other Integration Servers. The default is false.
Important:
You must restart Integration Server for changes to take effect.
watt.server.db.testSQL
Specifies a SQL statement that can be used to test a database connection in a JDBC connection pool. If the watt.server.db.testSQL parameter specifies a SQL statement, when a caller requests a JDBC connection from a JDBC connection pool, Integration Server executes the specified SQL statement against the database used with the JDBC connection pool. If the SQL statement executes successfully, Integration Server considers the database connection to be valid and returns the connection to the caller. If the SQL statement does not execute successfully, Integration Server considers the database connection to be invalid and removes it from the JDBC connection pool. Integration Server than creates a new JDBC connection, places it in the JDBC connection pool, and returns the new connection to the caller. If no value is specified for watt.server.db.testSQL, Integration Server does not test database connections in the connection pool when a caller requests a JDBC connection. There is no default value for the parameter.
Note:
Testing a database connection each time a JDBC connection is requested may impact performance as each test executes a SQL statement against the database.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.debugFIPS
Specifies whether Integration Server checks the FIPS encryption provider every time a user is authenticated. When this parameter is set to true, every time a user is authenticated, Integration Server checks the FIPS encryption provider by using the provider to create a java.security.MessageDigest instance. The provider check writes the name of the provider and the generated MessageDigest to standard error. When set to false, Integration Server does not check the encryption provider every time a user is authenticated. The default is false.
Important:
You must restart Integration Server for changes to take effect.
watt.server.defaultContentHandler
Specifies to which content handlers Integration Server should register the text/html content type. If set to true (the default), then Integration Server registers the text/html content type with the ContentHandler_Default content handler. If set to false, then Integration Server registers the text/html content type with the ContentHandler_CGI content handler.
Important:
You must restart Integration Server for changes to take effect.
watt.server.defaultCountry
Specifies the default country, a component of a Java Locale, that Integration Server uses when selecting strings from ResourceBundles to return to a client. Any ISO country code is a valid value. The default value for this property is US. The default locale is en-US.
Important:
You must restart Integration Server for changes to take effect.
watt.server.defaultLanguage
The default language, a component of a Java Locale, that Integration Server uses when selecting strings from ResourceBundles to return to a client. Any ISO language code is a valid value. The default value for this property is en. The default locale is en-US.
Important:
You must restart Integration Server for changes to take effect.
watt.server.defaultPackage
Specifies the name of the default package. If this value is not set, Integration Server uses WmAdmin as the default package. If you start Integration Server in safe mode, WmAdmin becomes the default value regardless of the value of this parameter.
Note:
If you change the value of this parameter, you must restart Integration Server for the change to take effect.
watt.server.deprecatedExceptionLogging
Specifies how the Integration Server logs service exceptions to the Integration Server error log. Set this parameter to true for basic exception logging or false (the default setting) for more detailed exception logging to help pinpoint the source of the exception.
When set to
Integration Server
true
*Logs the exception for each service in a nested stack as the exception moves up the stack. If a parent service catches the exception and does not rethrow it, the Integration Server still logs the exception for each child service it passed on its way up the stack.
*Displays the stack trace for each service.
false
*Logs the exception only once, at the top-level service, even if the exception occurred at a nested service. If any service in the stack catches the exception and does not rethrow it, the Integration Server does not log the exception.
Note:
The exception may be logged more than once if a service in the call stack, or one of the core classes that the service uses, explicitly logs the exception.
*Displays, for logged exceptions, the stack trace of the innermost service where the exception first occurred. This stack trace often gets truncated from the log when watt.server.deprecatedExceptionLogging is set to true.
*Concatenates the error messages from each of the nested exceptions.
If this parameter is set to true, the cause of the exception becomes more difficult to trace. For this reason, Software AG recommends that you do not set this parameter to true unless you are executing services that catch exceptions and do not rethrow them.
For more information about interpreting the error log and using the log to help debug services, see Debugging Service Exceptions Using the Error Log.
watt.server.diagnostic.logFiles.maxMB
Specifies the maximum number of megabytes of data that Integration Server reads from the file system for an audit log while collecting diagnostic data. This parameter affects the collection of audit log files only. It does not affect audit log data read from the database, nor does it affect other log files such as the server log, stats log or terracotta-client logs. The default is 250 megabytes. You do not need to restart Integration Server for changes to this parameter to take effect.
watt.server.diagnostic.logperiod
Specifies how many hours of logs are returned when you run the diagnostic tool. The default is 6. When this property is set to 0, the diagnostic utility does not return any log files. It returns only the configurational and run-time data files.
watt.server.diagnostic.port
Specifies the diagnostic port through which you can access Integration Server when it is unresponsive. During installation, Integration Server automatically creates the diagnostic port at 9999. The default is 9999.
Note:
This setting overrides the Port setting on the on the Edit Diagnostic Port Configuration page.
If you are running multiple Integration Servers on the same host machine, the diagnostic port on each server must have a unique port number. Set this parameter for each Integration Server instance to use a unique port number. For more information about the diagnostic port and running multiple Integration Server instances, see Adding an HTTP Diagnostic Port.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect. To change the diagnostic port without restarting Integration Server, edit the default diagnostic port on the Server > Ports page of Integration Server Administrator. For more information, see Editing a Port.
watt.server.diagnostic.tabular
Specifies whether Integration Server should generate diagnostic files in tabular format. If set to false, Integration Server generates the files in non-tabular format. The default is true.
watt.server.dispatcher.comms.brokerPing
Specifies how often (in milliseconds) triggers (which are Broker clients) should ping the Broker. When there is a firewall between the Integration Server and the Broker, the firewall closes the connection between a trigger and the Broker when the connection becomes idle. To prevent connections from becoming idle, trigger Broker clients periodically ping the webMethods Broker. The default is 1800000 milliseconds (30 minutes).
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.dispatcher.comms.connectionShareLimit
Specifies the number of BrokerClient objects that Integration Server can use to communicate with Broker. Integration Server passes this value to set the following Broker API: COM.activesw.api.client.BrokerConnectionDescriptor.setConnectionShareLimit (int value).
For more information, see webMethods Broker Java Client API Reference.
Each Broker connection represents a socket open to the Broker. While decreasing the value of the property can increase throughput, it also increases the number of resources and file descriptors Integration Server uses. Set this parameter to either 0 or a value greater than 1. When set to 0, connection sharing is turned off and each Broker client uses its own Broker connection. The default is 5.
Note:Broker does not support a value of 1. If the value is set to 1, Broker issues an exception.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.dispatcher.join.reaperDelay
Specifies how often (in milliseconds) that the Integration Server removes state information for completed and expired joins. The default is 1800000 milliseconds (30 minutes).
watt.server.dispatcher.messageStore.redeliverOriginalMessage
Specifies whether Integration Server stores and redelivers the original message or a modified message for subsequent trigger service execution when retry failure occurs for a trigger service invoked by webMethods messaging trigger. When set to true, Integration Server stores and redelivers the message originally sent to the webMethods messaging trigger. When set to false, Integration Server stores the message as it is at the point at which retry failure occurs. Integration Server delivers a modified message to the webMethods messaging trigger for subsequent processing. The default is false.
watt.server.displayDirectories
Specifies whether a browser user can view directories that reside on Integration Server without using Integration Server Administrator. When this parameter is set to true (the default), users can view Integration Server directories. When this parameter is set to false, no directories are displayed.
watt.server.dumpWhitelist
When whitelist class filtering is enabled, indicates whether or not Integration Server generates a log file that lists any classes for which deserialization was attempted but are not part of a whiteslistclasses.xml file. When watt.server.dumpWhitelist is set to true, Integration Server generates a log file that lists any classes that were called but were not in a whitelist classes file. Specifically, Integration Server creates the following file during shut down:
Integration Server_directory /instances/instanceName/logs/runtimeClasslist.time.xml where time is the time in milliseconds since January 1, 1970.
The default value of watt.server.dumpWhitelist is false, which indicates that Integration Server does not generate log of classes that were called but were not part of a whitelist classes file.
watt.server.email.charset
Specifies the default character set used for encoding portions that contain non-ASCII characters in email messages. Email fields that contain non-ASCII characters are subject, MIME headers, body text, and attachments. The pub.client:smtp service uses this property. The default is utf-8. For more information about the pub.client:smtp service, see webMethods Integration Server Built-In Services Reference.
watt.server.email.from
Specifies the email address the server presents as its From address when sending emails about errors. By default, the server uses Integration-Server@localhost for the From Address, where localhost is the name of the host on which the Integration Server is running.
watt.server.email.processReplyEmails
Specifies whether Integration Server should process the reply emails that it receives in its email port if the Subject line of the email contains the prefix "Re:". Set the watt.server.email.processReplyEmails property to true if you want Integration Server to process reply emails that contain the prefix "Re:" along with a valid service name in the Subject line. If the property is set to false, Integration Server does not process the email if the Subject line contains the prefix "Re:". Instead, Integration Server generates a server log message. The default is false.
watt.server.email.waitForServiceCompletion
Specifies whether Integration Server should wait for the email port to complete the processing of a message before returning the thread used to retrieve the message to the thread pool.
When retrieving and processing messages received by an email port, Integration Server uses one thread to retrieve a message and a second thread to execute the service that processes the message. By default, after using a thread to retrieve a message, Integration Server returns it to the server thread pool, making it available to perform other processing.
If the email port receives a large number of messages in a short period of time, the email port might monopolize the server thread pool for retrieving and processing messages. In addition, if the service that processes the messages executes slowly, it is possible that the email port message processing will negatively affect the performance of Integration Server.
To avoid this issue, you can limit the number of threads used to process messages received by an email port by setting the watt.server.email.waitForServiceCompletion property.
When the property is set to true, Integration Server does not return the thread used to retrieve the message to the thread pool until after the service that processes the message executes to completion. As a result, the maximum number of threads used to retrieve and process messages for an email port is equal to 2 or twice the value of the Number of threads if multithreading is turned on field.
*If the email port is for a POP3 email server, Integration Server can use up to 2 threads for retrieving and processing messages for the port (one thread to retrieve a message received by the email port and one thread to execute the service that processes the message).
*If the email port is for an IMAP email server and multithreading is disabled, Integration Server can use up to 2 threads for retrieving and processing messages for the port (one thread to retrieve a message received by the email port and one thread to execute the service that processes the message).
*If the email port is for an IMAP email server and multithreading is enabled, Integration Server can use a number of threads equal to twice the value of the Number of threads if multithreading is turned on field for retrieving and processing messages for the port. For example, if the value of the Number of threads if multithreading is turned on field is 5, Integration Server can use a maximum of 10 threads to retrieve and process messages for the email port (5 threads to concurrently retrieve messages for the email port and another 5 threads to process those messages).
When watt.server.email.waitForServiceCompletion is set to false, Integration Server does not wait for the service that processes the message to execute to completion before returning the thread used to retrieve the message to the thread pool.
The default is false.
Note:
The watt.server.email.waitForServiceCompletion parameter applies to all email ports on an Integration Server.
watt.server.enableHotDeployment
Specifies whether hot deployment of packages is enabled on Integration Server. Set to true to enable hot deployment. Set to false to disable hot deployment. The default is false.
The value of watt.server.enableHotDeployment is tied to the Enable field on the Settings > Hot deployment > Edit settings page in Integration Server Administrator.
watt.server.enterprisegateway.ignoreXForwardedForHeader
Specifies whether Integration Server must ignore the X-Forwarded-For request header while processing the rules in Enterprise Gateway Server. If this property is set to true then Integration Server ignores the X-Forwarded-For request header and considers the proxy server's IP address as the host IP address. If the property is set to false then Integration Server obtains the actual host IP address from the X-Forwarded-For request header. Default value is true.
watt.server.errorMail
Specifies the email address to which Integration Server sends messages about critical server log entries. There is no default.
watt.server.event.audit.async
Specifies whether the event handlers for the audit event are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to audit events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to audit events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.audit.async parameter is ignored.
watt.server.event.exception.async
Specifies whether the event handlers for the exception event, error event, or journal event are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to exception events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to exception events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.exception.async parameter is ignored.
watt.server.event.gd.async
Specifies whether the event handlers for guaranteed delivery events (gdStart and gdEnd) are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to guaranteed delivery events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to guaranteed delivery events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.gd.async parameter is ignored.
watt.server.event.jmsDeliveryError.async
Specifies whether the event handlers for JMS delivery failure events are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to JMS delivery failure events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to JMS delivery failure events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.jmsDeliveryError.async parameter is ignored.
watt.server.event.jmsRetrievalError.async
Specifies whether the event handlers for JMS retrieval failure events are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to JMS retrieval failure events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to JMS retrieval failure events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.jmsRetrievalError.async parameter is ignored.
watt.server.event.replication.async
Specifies whether the event handlers for replication events are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to replication events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to the replication events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.replication.async parameter is ignored.
watt.server.event.routing.bodyAsString
When you are using the pub.event.routing:subscribe service, you receive an evt:Event document as input in the subscription service. This parameter specifies whether you want to map the evt:body element inside the evt:Event document to the expected document type. When this parameter is set to false, Integration Server maps the evt:body element inside the evt:Event document to the expected document structure. When this parameter is set to true, Integration Server does not map the evt:body element inside the evt:Event document. The default is false.
watt.server.event.routing.runAsUser
Specifies the user who will invoke the service specified in the pub.event.routing:send and pub.event.routing:subscribe built-in services. Integration Server uses the user specified in this parameter only if no user is specified in the runAsUser input parameter of the pub.event.routing:send and pub.event.routing:subscribe services. The default is Administrator.
This user can be defined either internally or in an external directory but must belong to an existing group that has appropriate ACL permissions to invoke the specified service. Integration Server does not validate this user until the service is executed.
The new value of the parameter applies to existing subscriptions as well as new subscriptions created using pub.event.routing:subscribe.
watt.server.event.security.async
Specifies whether the event handler for security events is invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to security events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to security events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.security.async parameter is ignored.
watt.server.event.session.async
Specifies whether the event handlers for session events (sessionStart, sessionEnd, and sessionExpire) are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to session events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to session events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.session.async parameter is ignored.
watt.server.event.stat.async
Specifies whether the event handlers for stat (statistics) events are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to the statistics events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to the statistics events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.stat.async parameter is ignored.
watt.server.event.tx.async
Specifies whether the event handlers for the transaction events (txStart and txEnd) are invoked asynchronously or synchronously. When this parameter is set to true, Integration Server invokes the event handlers (services) that subscribe to transaction events asynchronously. When this parameter is set to false, Integration Server invokes the event handlers that subscribe to transaction events synchronously. The default is true.
Note:
When the thread pool becomes exhausted, Integration Server processes all events synchronously to prevent a deadlock. That is, during an event storm, the value of the watt.server.event.tx.async parameter is ignored.
watt.server.eventHandlerCreateSession
Controls whether Integration Server should create a session for the service that is invoked by the Event Manager. When set to true, Integration Server creates a session and associates it with the invoked service. When set to false, Integration Server does not create a session for the service that is invoked by the Event Manager. The default is false.
Note:
When set to true, specify a timeout value for the session using the watt.server.eventHandlerSessionTimeout parameter.
watt.server.eventHandlerSessionTimeout
When watt.server.eventHandlerCreateSession is set to true, watt.server.eventHandlerSessionTimeout specifies the timeout value for sessions created by Integration Server for services that are invoked by the Event Manager. The default value is 60000 milliseconds.
watt.server.eventHandlerUser
Specifies the user account whose credentials Integration Server uses to execute an event handler service. You can specify a locally defined user account or a user account defined in a central or external directory. Make sure that the user account you specify includes the credentials required by the execute ACLs assigned to the services used as event handlers. The default is Administrator.
watt.server.eventMgr.maxThreads
Specifies the maximum number of threads that you want Integration Server to use for the Event Manager thread pool. The default is 5.
Integration Server verifies that this value is greater than watt.server.eventMgr.minThreads. If the value of watt.server.eventMgr.maxThreads is less than the value of watt.server.eventMgr.minThreads, Integration Server sets the value of watt.server.eventMgr.maxThreads to one more than watt.server.eventMgr.minThreads. For example, if watt.server.eventMgr.minThreads is set to 6 and watt.server.eventMgr.maxThreads is set to 5, Integration Server sets the value of watt.server.eventMgr.maxThreads to 7.
watt.server.eventMgr.minThreads
Specifies the minimum number of threads that you want Integration Server to use for the Event Manager thread pool. The default is 2.
Integration Server verifies that this value is 1 or greater. If set to a value less than 1, Integration Server resets it to 1.
watt.server.fileEncoding
Specifies the encoding the server is to use when reading and writing text files. This setting has no effect on files stored as Unicode. The default is your JVM's file.encoding property.
Note:
To process incoming XML files, use the watt.server.xml.encoding parameter. If you have configured Integration Server to use the character encoding specified in the watt.server.fileEncoding parameter to process incoming XML files, you must ensure that the value of watt.server.fileEncoding parameter is set to the same value specified for watt.server.xml.encoding.
watt.server.ftpConnect.message
Specifies the content of the 220 message that Integration Server returns to an FTP client when the client issues a connect request.
When this parameter is set to true (the default), Integration Server returns the following messages to the FTP client:
Connected to IS_hostname.
220 IS_hostname FTP server (webMethods Integration Server version n.n.n.n) ready.
When this parameter is set to false, Integration Server returns the following messages to the FTP client:
Connected to IS_hostname. 220
When this parameter is set to any other value, that value is returned in the 220 message. For example, if you specify Custom FTP connect message, Integration Server will return the following to the FTP client:
Connected to IS_hostname. 220 Custom FTP connect message.
watt.server.ftp.listingFileAge
Specifies the number of seconds that must elapse before a file that has been updated or created on an Integration Server functioning as an FTP server can be accessed. Files created or updated within the time specified by this parameter will not be part of the results of the FTP LIST command. The default value is 60 seconds.
watt.server.ftpLogin.message
Specifies the content of the 230 message that Integration Server returns to an FTP client when the client issues a login request.
When this parameter is set to true (the default), Integration Server returns the following message to the FTP client: 230 User userid logged in.
When this parameter is set to false, Integration Server returns the following message to the FTP client: 230
When this parameter is set to any other value, that value is returned in the 230 message. For example, if you specify Custom FTP login message, Integration Server will return the following to the FTP client:
230 Custom FTP login message.
watt.server.ftpSystem.message
Specifies the content of message 215 that Integration Server returns to an FTP client when the client issues a system request. When this parameter is set to true (the default), Integration Server returns the following message to the FTP client:
215 UNIX Type: L8 Version: webMethods IS FTP <Integration Server n.n.n.n>
When this parameter is set to false, Integration Server returns the following message to the FTP client:
215
When this parameter is set to any other value, that value is returned in the 215 message. For example, if you specify Custom FTP system message, Integration Server returns the following to the FTP client:
215 Custom FTP system message.
watt.server.ftp.usecommandip
Controls whether the pub.client:ftp service uses connection information from a NAT server when connecting to an FTP server.
When the pub.client:ftp service tries to transfer data to or from an FTP server, Integration Server first connects to the FTP server at the IP address specified by the pub.client:ftp service. In response, the FTP server sends back the IP address on the FTP server to which Integration Server should connect to perform the transfer. If the FTP server sits behind a NAT server, the NAT server intercepts this address, translates it, then sends it on to Integration Server.
This property controls whether Integration Server uses the address provided by the NAT server or the address already specified by the pub.client:ftp service.
When this parameter is set to true, Integration Server bypasses the translated address and tries the address specified by the service. If this attempt fails, Integration Server throws an exception.
When this parameter is set to false, the default, Integration Server tries the address provided by the NAT server. If that attempt fails, Integration Server tries the IP address specified on the pub.client:ftp service. If both attempts fail, Integration Server throws an exception.
watt.server.grpc.clientCertRequired
Specifies whether the gRPC server requests the use of client certificates for authentication or requires them. When set to true, the gRPC server requires client certificates for all gRPC client requests. The gRPC server rejects requests that do not include a client certificate. When set to false, the gRPC server requests client certificates for all gRPC client requests; however, if a certificate is not provided Integration Server checks for client credentials in the AuthUser and AuthPass metadata headers. If AuthUser and AuthPass are not provided, Integration Server uses the default user as the client credentials. A value of true is the more secure option. The default is false.
Set watt.server.grpc.clientCertRequired to true only when watt.server.grpc.enable.TLS is set to true.
Note:
You must restart a gRPC channel for changes to this parameter to take effect. To restart a gRPC channel, disable it and then enable it.
watt.server.grpc.enable.TLS
Specifies whether the gRPC server embedded in Integration Server uses TLS for data encryption and requires client certificates for inbound gRPC requests. When set to true, the gRPC server use TLS to encrypt data during transmission and inbound requests may require the use of client certificates for authentication. Whether the gRPC server requires certificates depends on the value of watt.server.grpc.clientCertRequired. When set to false, the gRPC server operates in “plaintext” mode in which the gRPC server does not use TLS to encrypt data and does not perform client certificate authentication on inbound requests. In plaintext mode, the gRPC server rejects any client requests containing certificate information provided in inbound requests. Using plaintext mode can be helpful during development and initial testing environment but should not be used in a production environment. Software AG recommends setting watt.server.grpc.enable.TLS to true in a production environment to ensure data encryption and client authentication. The default is true.
Note:
You must restart a gRPC channel for changes to this parameter to take effect. To restart a gRPC channel, disable it and then enable it.
watt.server.grpc.maxConcurrentCalls
Specifies the maximum number of gRPC requests that the gRPC server embedded in Integration Server can process concurrently. Each gRPC request consumes a thread from the server thread pool. The default is 100.
Note:
You must restart a gRPC channel for changes to this parameter to take effect. To restart a gRPC channel, disable it and then enable it.
watt.server.grpc.maxMessageSize
Specifies the maximum size of a message, measured in bytes, for an inbound gRPC request. The gRPC server embedded in Integration Server accepts messages less than or equal to this size limit. The gRPC server rejects messages greater than this size limit. This parameter affects incoming requests only. It does not apply to gRPC responses. The default is 4,194,304 (4MB).
Note:
You must restart a gRPC channel for changes to this parameter to take effect. To restart a gRPC channel, disable it and then enable it.
watt.server.hostAccessMode
Specifies IP access for ports that do not have a custom IP access setting. When this parameter is set to include, the server accepts requests from all IP addresses, except those specifically denied on the Integration Server Administrator interface. When this parameter is set to exclude, the server denies requests from all IP addresses except those specifically allowed on the Integration Server Administrator interface. The default is include.
watt.server.hostAllow
Specifies the name of the host that is allowed service. There is no default.
watt.server.hotDeploymentAutoRecover
Specifies whether or not automatic recover is enabled for hot deployment of packages on Integration Server. Set to true to enable automatic recovery of the previous version of a package if hot deployment of the new version of the package fails. Set to false to disable automatic recovery of packages if hot deployment fails. The default is false.
The value of watt.server.hotDepolymentAutoRecover is tied to the Auto Recover field on the Settings > Hot deployment > Edit settings page in Integration Server Administrator.
watt.server.hotDeploymentTimeout
Specifies the number of seconds that Integration Server waits for in-flight processing to complete before attempting to hot deployment of a packages. If there are any long running tasks that you want to complete before deploying the packages, make sure that you set the timeout value to a value more than the time it takes for the task to complete. The default is 60 seconds.
The value of watt.server.hotDeploymentTimeout is tied to the TImeout field on the Settings > Hot deployment > Edit settings page in Integration Server Administrator.
watt.server.http.allowOptions
Indicates whether Integration Server allows a client to use the HTTP OPTIONS method to determine the HTTP methods supported by Integration Server. When this parameter is set to true, Integration Server allows the OPTIONS method. When this parameter is set to false (or any other value), OPTIONS requests from clients receive a ”405 Method Not Allowed” response.
The default is true.
watt.server.http.authorizationEncoding
Specifies the encoding that the HTTP client (such as a browser) uses when encoding the user name and password for Integration Server. The HTTP client sends the user name and password to Integration Server in the Authorization attribute in the header of the HTTP request. Set the watt.server.http.authorizationEncoding property to the encoding that your browser uses for the Authorization attribute. Consult the browser documentation, or contact the browser manufacturer, to find what encoding is used in your environment. The default is UTF-8.
Note:
If two browsers use different encodings for the Authorization attribute, and both send non-ASCII passwords to Integration Server, only the browser whose Authorization encoding matches the value of the watt.server.http.authorizationEncoding property will work.
watt.server.http.Content-Security-Policy
Sets the HTTP security header Content-Security-Policy in the responses to requests for accessing the Integration Server Administrator. You can use this property to detect and mitigate attacks such as Cross Site Scripting (XSS) and data injection.
By default, this property is set to "none" and the Content-Security-Policy header is not included in the responses. To secure access to the Integration Server Administrator you can set this property to the value "script-src 'self' 'unsafe-inline'" as follows:
watt.server.http.Content-Security-Policy=script-src 'self' 'unsafe-inline'
For related information, see watt.server.http.X-Permitted-Cross-Domain-Policies, watt.server.http.Strict-Transport-Security, watt.server.http.X-Content-Type-Options, and watt.server.http.X-XSS-Protection.
watt.server.http.forwardableHeaders
The headers that Integration Server collects from inbound requests and includes in outbound requests. Integration Server collects and forwarded the headers only when watt.server.http.forwardHeaders is set to true. If watt.server.http.forwardableHeaders is empty, Integration Server neither collects nor forwards any headers even if watt.server.http.forwardHeaders is set to true.
The default value of watt.server.http.forwardableHeaders is: x-request-id,x-b3-traceid,x-b3-spanid,x-b3-parentspanid,x-b3-sampled,x-b3-flags,x-ot-span-context
watt.server.http.forwardHeaders
Specifies whether Integration Server supports distributed tracing by collecting the headers used by Istio Service Mesh and opentracing. When set to true, Integration Server collects the headers specified in watt.server.http.forwardableHeaders from inbound requests and includes them on outbound requests that happen as a result of an inbound request. When set to false, Integration Server does not collect or forward headers from inbound requests. The default value is true.
watt.server.http.header.sameSite
Specifies whether HTTP responses from IS include the SameSite attribute in the Set-Cookie HTTP response header or not, and the value of the SameSite attribute if it is included. Valid values for this parameter are: None, Strict, and Lax. These values and their behavior conform to the HTTP specification.
Note: 
*The HTTP standard states that when the SameSite attribute of the Set-Cookie HTTP response header is None, the Secure attribute must be specified. To include the Secure attribute in the HTTP response header, set the server configuration parameter watt.server.http.header.useSecure to true.
*If you try to set watt.server.http.header.sameSite to None in Integration Server Administrator, when the watt.server.http.header.useSecure parameter is set to false, Integration Server Administrator displays a warning message and does not allow you change the value.
*If you edit the values of the watt.server.http.header.sameSite or the watt.server.http.header.useSecure parameters directly in the server.cnf configuration file and the specified configuration is not valid, Integration Server logs a warning and the invalid configuration is ignored. See Setting Up the Server Log for more information on Integration Server logging. As the value of watt.server.http.header.sameSite is ignored, the SameSite attribute is not added to the Set-Cookie response header.
*If you set the Set-Cookie header and include the SameSite attribute using the pub.flow:setResponseHeader or pub.flow:setResponseHeaders services then Integration Server ignores the value of the watt.server.http.header.sameSite parameter.
watt.server.http.header.useHttpOnly
Specifies whether Integration Server includes the HttpOnly attribute in the Set-Cookie header in the response to an HTTP client. When this property is set to true (the default), Integration Server includes the HttpOnly attribute in the Set-Cookie header of the HTTP response to an HTTP client. Software AG recommends setting this property to true because it prevents a client side script from accessing a protected cookie. If you are working with an HTTP client that does not support the HttpOnly attribute, set this property to false.
watt.server.http.header.useSecure
Specifies whether Integration Server includes the secure attribute in the Set-Cookie header in the response to an HTTP/S client. When the watt.server.http.header.useSecure property is set to true (the default), Integration Server includes the secure attribute in the Set-Cookie header of the HTTPS response to an HTTP/S client. Software AG recommends setting this property to true because it ensures that the cookie is always encrypted while being transmitted from client to server.
Important:
The value of the watt.server.http.header.sameSite parameter impacts how Integration Server uses this parameter. See watt.server.http.header.sameSite for more information.
watt.server.http.interceptor.enabled
Specifies whether the inbound HTTP interceptor is enabled for Integration Server. When set to true, Integration Server uses the inbound HTTP interceptor implementation identified by the watt.server.http.interceptor.impl property. The default value of this property is false.
Note:
The first time you set this property to true, you must restart Integration Server for changes to the property to take effect.
watt.server.http.interceptor.impl
Specifies the fully qualified name of the Java class that implements the inbound HTTP interceptor. The provided class must implement the com.softwareag.is.interceptor.HttpInterceptorIFC interface and provide implementations of both methods in the interface (preProcess and postProcess). The compiled class must be available on the server classpath.
Important:
You must restart Integration Server for a change to this parameter to take effect.
watt.server.http.interceptor.outbound.enabled
Specifies whether an outbound HTTP interceptor is enabled for Integration Server. When set to true, Integration Server uses the outbound HTTP interceptor implementation identified by the watt.server.http.interceptor.outbound.impl property. The default value of this property is false.
Important:
The first time you set this property to true, you must restart Integration Server for changes to the property to take effect.
watt.server.http.interceptor.outbound.impl
Specifies the fully qualified name of the Java class that implements the outbound HTTP interceptor. The provided class must implement the com.softwareag.is.interceptor.HttpOutboundInterceptorIFC interface and provide implementations of both methods in the interface (preProcess and postProcess). The compiled class must be available on the server classpath.
Important:
You must restart Integration Server for a change to this parameter to take effect.
watt.server.http.interceptor.preprocess.sizeLimit
Specifies the maximum number of bytes that an inbound HTTP interceptor reads during preprocessing. If the HTTPRequest's input exceeds this value, the inbound HTTP interceptor reads up to this limit and then ignores the rest of the input stream. Set this property to N [KB|MB|GB], where N is any valid integer. Do not include any spaces between the integer and the unit of measure. If you do not specify a unit of measure, Integration Server treats the supplied N value as bytes. The default value is -1. which indicates there is no limit to the size of the request bytes that will be passed to the inbound HTTP Interceptor: The inbound HTTP interceptor will read the entire input stream.
watt.server.http.jsonFormat
Specifies how Integration Server handles JSON content in HTTP client requests. When this property is set to parsed (the default), Integration Server parses JSON content into pipeline variables automatically. Clients can then use JSON to compose pipelines and execute existing services without having to call pub.json:jsonStreamToDocument.
If watt.server.http.jsonFormat is set to stream, Integration Server places a jsonStream variable containing the JSON content in the pipeline as an InputStream. You can then use pub.json:jsonStreamToDocument to parse jsonStream into pipeline variables.
If watt.server.http.jsonFormat is set to bytes, Integration Server places the incoming stream of JSON into a byte array.
You can override the behavior specified by watt.server.http.jsonFormat in individual requests by adding the jsonFormat query parameter to the request URI. For example, if watt.server.http.jsonFormat is set to parsed, a client can override this setting and instead specify a value of stream for the request by entering a URI as follows:
/invoke/myfolder/myservice?jsonFormat=stream
This will result in the request being placed in a jsonStream variable in the pipeline as an InputStream containing the JSON content.
watt.server.http.listRequestVars
Specifies how Integration Server handles duplicate query tokens in an HTTP request.
When set to
Integration Server
always
Converts duplicate and non-duplicate tokens into lists. For example:
http://host:5555/folder/service?arg1=X&arg1=Y&arg2=Z
becomes
INVOKE folder:service {arg1=X, arg1List=[X,Y], arg2=Z,
arg2List=[Z]}
asNeeded
Converts duplicate tokens into Lists. Non-duplicate tokens are not converted. For example:
http://host:5555/folder/service?arg1=X&arg1=Y&arg2=Z
becomes
INVOKE folder:service {arg1=X, arg1List=[X,Y], arg2=Z}
This is the default setting.
error
Throws a ServiceException if duplicate tokens are found in the URL query. Non-duplicate tokens are not converted. For example:
http://host:5555/folder/service?arg1=X&arg1=Y&arg2=Z
never
Ignores duplicate tokens found in the URL query. For example:
http://host:5555/folder/service?arg1=X&arg1=Y&arg2=Z
becomes
INVOKE folder:service {arg1=X, arg2=Z}
watt.server.http.preserveUriReservedChars
Specifies whether Integration Server should decode percent-encoded URI paths in requests before evaluating URI paths. When this property is set to true (the default), Integration Server defers decoding percent-encoded reserved characters including white space, until after evaluating URI paths. When set to false, Integration Server decodes percent-encoded reserved characters including white space prior to evaluating the URI paths.
Note:
The value of watt.server.http.preserveUriReservedChars is significant only for the REST requests that use the rest directive. For requests using the rest directive, the last tokens in the path identify the instance of a resource or provide application-specific information. These tokens become the $resourceID and $path variables in the pipeline. This portion of the URI path can contain percent-encoded reserved characters with white space. When watt.server.http.preserveUriReservedChars is set to true, Integration Server decodes the percent-encoded characters after evaluating the URI path, but before invoking the service.
For requests that use the invoke directive, the entire path of the URI after "/invoke" refers to folders and services in the Integration Server namespace. Folders and services cannot contain any URI-reserved characters including white space, therefore any request that uses the invoke directive and contains a percent-encoded reserved character along with white space in its path will never identify an actual Integration Server service and will always result in an HTTP 404 response.
watt.server.http.reauth.user-agent.list
Specifies a semicolon-delimited list of HTTP clients from which you want Integration Server to request re-authentication after an HTTP session expires. By default, this parameter is set to Firefox;MSIE so that requests from the Mozilla Firefox and Microsoft Internet Explorer browsers will be asked to re-authenticate if the associated HTTP session has expired. For user agents not specified on this list, Integration Server sends a new session cookie when the session expires.
If you remove this property and restart Integration Server, the value of this property resets to Firefox;MSIE.
watt.server.http.request.supportCompression
Specifies whether Integration Server needs to support HTTP request compression. By default, this parameter is set as false. If you want Integration Server to support decompression of the payload after receiving a compressed payload in HTTP request, set this parameter as true. For more information on HTTP request compression, see webMethods Integration Server Built-In Services Reference guide.
Integration Server decompresses the payload based on the Content-Encoding request header defined in the HTTP request. The request header defines the compression scheme used to compress the payload. Integration Server uses the same compression scheme to decompress the payload. The supported compression schemes are Gzip and Deflate.
If the parameter is set as false and Integration Server receives compressed payload in HTTP request then it ignores the request.
watt.server.http.response.supportCompression
Specifies whether Integration Server needs to support HTTP response compression. By default, this parameter is set as false. If you want Integration Server to support compression of the payload before sending the HTTP response, set this parameter as true. For more information on HTTP response compression, see webMethods Integration Server Built-In Services Reference guide.
Integration Server compresses the payload based on the Accept-Encoding request header defined in the HTTP request. The request header defines the suggested compression scheme that Integration Server can use to compress the payload. The supported compression schemes are Gzip and Deflate.
If the parameter is set as false and Integration Server receives an HTTP request to compress the response payload then it sends an uncompressed response.
watt.server.http.returnException
Specifies whether Integration Server should return a stack trace in the HTTP/SOAP response it sends to the invoking client when an invoked service ends in error. You can specify one of the following:
Value
Tells Integration Server
true
To return a stack trace in the HTTP/SOAP response. This is the default.
false
Not to return a stack trace.
webMethods
Return a stack trace only if the client's HTTP user agent is set to webMethods or has the same value as the user agent specified on the watt.net.userAgent parameter.
watt.server.http.securityRealm
Specifies the name of the Integration Server security realm. This value is included in the headers of HTTP responses that Integration Server sends to clients that request authentication. The default value is Integration Server.
watt.server.http.Strict-Transport-Security
Specifies whether Integration Server includes Strict-Transport-Security header in response headers. Value specified for this parameter is set in the response headers of web requests to access theIntegration Server Administrator. Users are free to set any valid value to this parameter. If the value is set to None or left blank, then the Strict-Transport-Security header is not included in the response headers.
Example: watt.server.http.Strict-Transport-Security=max-age=300 ; includeSubDomains
For more information about valid values for this parameter, see the HTTP Strict Transport Security (HSTS) section of Internet Engineering Task Force (IETF) November 2012 specification.
Note:
The HTTP Strict-Transport-Security response header (HSTS) allows web servers to inform that web browsers should only access them using the secure HTTPS connections and not using HTTP connections.
watt.server.http.uriPath.decodePlus
Specifies whether or not the '+' character is interpreted as a ' ' when it appears in the path component of the request URI. When set to true, the default, Integration Server converts '+' to ' ' when processing the request URI. When set to false,Integration Server does not convert '+' to ' ' when processing the request URI. This parameter affects only the handling of '+' characters in the request URI's path component. Any '+' characters that appear in the request URI's query will be converted to ' ' characters regardless of the value of watt.server.htt.uriPath.decodePlus."
watt.server.http.useAcceptHeader
Specifies whether Integration Server supports the Accept header field in an HTTP request. The Accept header field specifies a content type or types the HTTP client will accept in the HTTP response. The default setting is true. This parameter must be set to true if you want to use the watt.server.content.type.mappings parameter to map wildcard content types in the Accept header field to specific content types.
watt.server.http.X-Content-Type-Options
Specifies whether Integration Server includes the X-Content-Type-Options header in response headers. Value specified for this parameter is set in the response headers of web requests to access the Integration Server Administrator. Default value is None. You can set any valid value for this parameter. If the value is set to None or left blank, then the X-Content-Type-Options header is not included in the response headers.
Example: watt.server.http.X-Content-Type-Options=nosniff
For more information about valid values for this parameter, see the X-Content-Type-Options section of https://fetch.spec.whatwg.org/#x-content-type-options-header.
Note:Integration Server includes the X-Content-Type-Options header in the response header to indicate that the MIME types advertised in the Content-Type headers are followed.
watt.server.http.x-frame-options
Controls how Integration Server is to handle the X-Frame-Options attribute in response headers. By default, this parameter is set to SAMEORIGIN which means that the client's browser is to allow Integration Server pages to be displayed in an HTML frame only if the frame is on a page from the same server.
Note:Integration Server includes the X-Frame-Options attribute in the response header to requests for webpages, as defined in the HTTP Header Field X-Frame-Options specifications. X-Frame-Options is not included in responses to requests for service invocation, such as those including the invoke, rest, restv2, or soap directives. It is only included in responses to requests for webpages, such as https://my-server/MyPackage/my-page.html.
If you do not want Integration Server to include the X-Frame-Options attribute in response headers, remove the value from the watt.server.http.x-frame-options property. For example: watt.server.http.x-frame-options= The property can be set on the Settings > Extended page of Integration Server Administrator. Changes to this property take effect immediately; the server does not need to be restarted
Note:
The value DENY is defined for the X-Frame-Options attribute but is not allowed for Integration Server. DENY means that the page can never appear in a frame, regardless of the frame's origin. This would cause Integration Server Administrator to be unusable. If watt.server.http.x-frame-options is set to DENY, that value is ignored and SAMEORIGIN is used instead.
Note:
The value of ALLOW-FROM other_origin is allowed but browsers will ignore it. Software AG does not recommend setting watt.server.http.x-frame-options to ALLOW-FROM other_origin . With ALLOW-FROM other_origin , the client's browser is to allow Integration Server pages to be displayed in an HTML frame regardless of the origin server of the framed content. Integration Server will not include an X-frame-options header in the response.
watt.server.http.X-Permitted-Cross-Domain-Policies
Sets the HTTP security header X-Permitted-Cross-Domain-Policies, which informs clients what cross-domain policies they can use for accessing the Integration Server Administrator. By default, this property is empty and the X-Permitted-Cross-Domain-Policies header is not included in the responses. To secure access to the Integration Server Administrator you can set this property to "none", which stops clients from loading data from your domain.
For related information, see watt.server.http.Content-Security-Policy, watt.server.http.Strict-Transport-Security, watt.server.http.X-Content-Type-Options, and watt.server.http.X-XSS-Protection.
watt.server.http.X-XSS-Protection
Specifies whether Integration Server includes X-XSS-Protection in the response headers. Value specified for this parameter is set in the response headers of web requests to access Integration Server Administrator. Default value is None. You can set any valid value for this parameter. If the value is set to None or left blank, then the response header does not include the X-XSS-Protection.
Example: watt.server.http.X-XSS-Protection=1; mode=block
For more information about valid values for this parameter, refer to your browser documentation.
Note: 
The HTTP X-XSS-Protection response headers stops web pages from loading when they detect reflected cross-site scripting (XSS) attacks.
watt.server.http.xmlFormat
Specifies whether Integration Server parses incoming XML documents automatically or passes them directly to the service. Use this property to set the default behavior for how Integration Server should pass XML documents via HTTP. Specify one of the following values:
Specify
To indicate that
bytes
Integration Server passes XML bytes directly to the requested service without parsing. When this parameter is set to bytes, the XML appears in the input pipeline of the service as byte array, named xmlBytes.
enhanced
Integration Server parses the XML automatically using the enhanced XML parser and passes it to the service as an enhanced node object named node that implements the org.w3c.dom.Node interface.
node
Integration Server parses the XML automatically using the legacy XML parser and passes it to the service in a parameter named node of type com.wm.lang.xml.Node. This is the default behavior.
stream
Integration Server passes XML streams directly to the requested service without parsing. When this parameter is set to stream, the XML appears in the input pipeline of the service as an InputStream, named xmlStream.
If a value for watt.server.http.xmlFormat is not specified or is invalid, the default XML parsing behavior is "node".
This feature can be used when submitting and receiving XML via HTTP of HTTPS only.
Note:
The default established by this parameter can be overridden in any individual client request that uses the xmlFormat argument in the URL. For more information about the xmlFormat argument, see webMethods Service Development Help.
Note:
Changing the default xmlFormat for all of Integration Server might cause existing services and applications to fail. Consider changing the xmlFormat on a service or application basis instead by using the Default xmlFormat property for a service. For more information about the Default xmlFormat property, see webMethods Service Development Help.
watt.server.httplog
Specifies whether Integration Server writes an HTTP log and what format is used for the log file. Set the parameter to one of the following values:
Value
Description
common
Integration Server writes HTTP log entries that conform to the Common Log format.
combined
Integration Server writes HTTP log entries that conform to the Combined Log format.
custom
Integration Server writes HTTP log entries in the legacy format.
Prior to Integration Server 10.11, the possible values for watt.server.httplog were true or false. These values can still be used. When set to true, Integration Server writes HTTP log entries in the legacy format that was used for HTTP logging prior to this fix. When set to false, Integration Server does not perform HTTP logging.
When watt.server.httplog is set to any value besides common, combined, custom, or true, or set to no value at all, Integration Server does not perform HTTP logging.
There is no default value for watt.server.httplogwhich means HTTP logging is not performed by default.
watt.server.hostDeny
Specifies the name of the host that is denied service. There is no default.
watt.server.idatacoder.legacy
Specifies whether Integration Server uses current version or the legacy version of the IDataBinCoder for encoding documents using the binary protocol. Set to true to use the legacy version. Set to false to use a newer version which may be significantly faster and slightly more memory efficient for large, complex documents. The default is false.
Note:
Any documents persisted to disk can be decoded even if the watt.server.idatacoder.legacy value changes between the time the document was encoded and the time the document needs to be decoded. That is, persisted data can be decoded regardless of the version of IDataBinCoder used to persist encode it.
watt.server.idr.reaperInterval
Specifies the interval, measured in minutes, at which the scheduled system service Message History Sweeper executes and removes expired document history entries. The default is 10 minutes.
watt.server.illegalNSChars
Specifies the characters that you cannot use when naming a package, folder or service. The default is ?`-#&@^!%*:$.\ /';,~+=)(|}{][><.
watt.server.illegalUserChars
Specifies characters that you cannot use in user names. The default is "\<&.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Important:
Do not remove characters from this property. If you remove characters and create users that contain those characters, Integration Server cannot parse users.cnf and will be unable to start.
watt.server.inetaddress
Specifies the IP address on which the server is to listen for incoming requests. By default, Integration Server listens on all available IP addresses. To limit the server to listening on a single IP address, specify the IP address as the value of this property.
watt.server.invokeDirective
Specifies an alternative word to use for the invoke directive in URLs that invoke services on Integration Server. By default, this parameter is set as watt.server.invokeDirective=invoke, which means users must specify the invoke directive as invoke (http://host:port/invoke/folder/service_name). To allow users to specify the invoke directive as either invoke or an alternative word, set this parameter to the alternative word. For example, to allow users to specify the invoke directive as either invoke or submit, (http://host:port/invoke/folder/service_name or http://host:port/submit/folder/service_name ), set this parameter as watt.server.invokeDirective=submit.
watt.server.invoke.maxRetryPeriod
Specifies the total amount of waiting time (in milliseconds) that can elapse if the Integration Server makes the maximum attempts to retry a service. The default is 15,000 milliseconds (15 seconds). When configuring retries for an individual service, the value calculated by multiplying Max attempts value by the Retry interval cannot exceed the value set by this server parameter. For more information about configuring service retry, see webMethods Service Development Help.
watt.server.java.unicode
Specifies whether the source code for Java services is stored in Unicode encoding. The default is false. Set this value to true if the source code contains characters that cannot be rendered in the server's native encoding.
watt.server.jca.connectionPool.thresholdWaitingRequest
When enabled, this property represents the percentage value that is used in addition to the configured maximum number of connections (set by the Maximum Pool Size parameter on the Connections page) for the connection pool. For example, setting the property as watt.server.jca.connectionPool.thresholdWaitingRequest=20 sets the threshold to 120% of configured maximum number of connections.
If the property is not defined or if the value is less than or equal to zero, the feature remains disabled.
When this property is enabled, the connection pool ensures that the waiting connection requests plus the busy connections in the connection pool do not exceed the threshold limit.
watt.server.jca.transaction.rollbackOnWriteFailure
If Integration Server cannot store the status of a transaction and its participating resources in the XA recovery store (for example, because the store is corrupted), specifies whether Integration Server should try to continue with the transaction anyway (false) or try to roll it back (true). Setting the parameter to false involves some risk; if Integration Server ends abnormally, no statuses will have been saved to the XA recovery store, and Integration Server will not be able to resolve the uncompleted transaction or give you the chance to resolve it manually.
watt.server.jca.transaction.writeRecoveryRecord
Specifies whether Integration Server maintains XA transaction information for use with XA transaction recovery. If Integration Server does not save XA transaction information, uncompleted XA transactions cannot be recovered using Integration Server. That is, Integration Server does not attempt to recover incomplete XA transactions automatically and you cannot use Integration Server Administrator to manually recover or resolve an incomplete transaction. Specify true to enable XA transaction recovery. Specify false to disable XA transaction recovery. The default is true.
watt.server.jdbc.datadirect.snoop.default
Specifies the default settings for the DataDirect Snoop tool for DataDirect Connect JDBC drivers. The DataDirect Snoop tool logs network packets between Integration Server and an external RDBMS. The resulting log file can be used for tracing and diagnostic purposes.
Note:
This option is for use with an external RDBMS only. It is not for use with the embedded IS internal database.
Set this parameter on each DataDirect Connect JDBC driver for which you want to log data.
Important:
To enable this feature for use with Integration Server, you must select the Snoop option on either the Edit JDBC Connection Pool Alias page or the Create JDBC Connection Pool Alias page of the Integration Server Administrator.
The default value for this parameter is:
ddtdbg.ProtocolTraceEnable=true;ddtdbg.ProtocolTraceMaxline=16;
ddtdbg.ProtocolTraceLocation=/logs/snoop/<alias_name>.log;
ddtdbg.ProtocolTraceShowTime=true
Where <alias_name> is the name of the JDBC connection pool alias.
Note:
For DB2, include the following command at the end of the value:
ddtdbg.ProtocolTraceEBCDIC=true
The default value defines the name and location of the log file and DataDirect Snoop tool attributes. Typically, you do not need to change the default value. However, you can modify the value if the attributes do not meet the needs of your system. If you change the log file location, be aware that the diagnostic tool collects data from the Integration Server_directory /instances/instance_name/logs/snoop directory. If you change the log file location, the diagnostic utility might not import the data logged by the DataDirect Snoop tool. For more information about using the diagnostic utility, see Using the Diagnostic Utility. For more information about setting the DataDirect Snoop tool attributes, consult the documentation on the DataDirect website.
Important:
If you change the value of this parameter, you must restart the connection pool for the changes to take effect.
watt.server.jdbc.datadirect.spy.default
Specifies the default settings for the DataDirect Spy diagnostic feature for DataDirect Connect JDBC drivers. DataDirect Spy logs JDBC calls and SQL statement interactions between Integration Server and an external RDBMS. The resulting log file can be used for tracing and diagnostic purposes.
Note:
This option is for use with an external RDBMS only. It is not for use with the embedded IS internal database.
Set this parameter for each DataDirect Connect JDBC driver for which you want to log data.
Important:
To enable this feature for use with Integration Server, you must select the Spy option on either the Edit JDBC Connection Pool Alias page or the Create JDBC Connection Pool Alias page of the Integration Server Administrator.
The default value for this parameter is:
SpyAttributes=(log=(file)/logs/spy/<alias_name>.log;logTName=yes;timestamp=yes)
Where <alias_name> is the name of the JDBC connection pool alias.
The default value defines the name and location of the log file and DataDirect Spy attributes. Typically, you do not need to change the default value. However, you can modify the value if the attributes do not meet the needs of your system. If you change the log file location, be aware that the diagnostic tool collects data from the Integration Server_directory /instances/instance_name/logs/spy directory. If you change the log file location, the diagnostic utility might not import the data logged by DataDirect Spy. For more information about the diagnostic utility, see Using the Diagnostic Utility. For more information about setting DataDirect Spy attributes, consult the documentation on the DataDirect website.
Important:
If you change the setting of this parameter, you must restart the connection pool for the changes to take effect.
watt.server.jdbc.datadirect.useJaasSubjectForKerberos
Specifies whetherIntegration Server use the Subject in a JAAS configuration to establish a connection to the database. When set to true, Integration Server uses the Subject in a JAAS configuration when using Kerberos with JDBC pool connections. Set to true when there are JAAS conflicts where the Integration Server JAAS configuration is wiped out by another component. When set to false, Integration Server tries to acquire the database connection in the traditional way. Set to false when there are no JAAS conflicts. The default value is false. If you encounter JAAS conflicts that result in the message “No LoginModules configured for loginConfigName from database URL and the JAAS login module is properly configured as is the JDBC connection pool, set the parameter to true.
watt.server.jdbc.defaultDriver
For use with WmDB. Specifies the name of the Java class for the driver you want to use to connect to databases when no driver name is supplied for a database alias.
watt.server.jdbc.derby.commitTolerance
Specifies the length of time, in milliseconds, that Integration Server waits for a commit to the embedded database to complete before removing the associated connection from the connection pool. Integration Server uses this property when it is configured to use the embedded database for any of the ISInternal, DocumentHistory, and Xref functions. If the commit process takes longer than the value defined by this property, Integration Server removes the associated connection from the connection pool so that a new connection can be initiated for future requests. The default value for this property is 150 milliseconds.
watt.server.jdbc.driverList
Specifies a comma-delimited list of JDBC drivers you want the server to load when it initializes. There is no default.
Note:
This parameter is for use with the WmDB package only.
watt.server.jdbcLogFile
Specifies the name of the log file that contains JDBC log activity. When the watt.server.jdbcLogging property is enabled (set to on), the server logs activity to this file. The default value is jdbc.log. It is located in the Integration Server_directory \instances\instance_name\logs folder. Note that the log file is generated after WmDB makes a connection to the database.
Note:
This parameter is for use with the WmDB package only.
watt.server.jdbc.loginTimeout
Sets the maximum time, in seconds, that the JDBC driver on Integration Server is to wait for a response while attempting to connect to a database. If Integration Server does not receive a response in the allotted time, it terminates the request, logs the error and moves on. The default value is 60 seconds.
If Integration Server is unable to connect to the audit logging database within the number of seconds specified by watt.server.jdbc.loginTimeout, Integration Server removes all connections from the ISCoreAudit JDBC connection pool and recreates them. If the connection problem is resolved quickly (such as a momentary network interruption), Integration Server reconnects to the audit logging database. If Integration Server is unable to connect to the audit logging database, such as when the database is offline, Integration Server writes an exception to the server log.
Important:
If you change the setting of this parameter, you must restart the ISCoreAudit JDBC connection pool for the changes to take effect. To restart the pool, in Integration Server Administrator, go to the Settings > JDBC pools page and click Restart for the ISCoreAudit functional alias.
watt.server.jdbcLogging
Specifies whether Integration Server is to enable logging on java.sql.DriverManager in order to log JDBC activity. When set to on, the server writes the log file data to the file specified by watt.server.jdbcLogFile. The default is off.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Note:
This parameter is for use with the WmDB package only.
watt.server.jdbc.moreResults
Specifies if the Integration Server is to process the stored procedure results from a single result set or multiple result sets. When set to true, Integration Server processes and returns information produced by multiple result sets. When set to false, Integration Server processes information produced from a single result set. The default is false.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Note:
This parameter is for use with the WmDB package only.
watt.server.jdbc.sp.mandateParams
Specifies whether the $data input parameter of the pub.db:call service expects values to invoke a stored procedure through the pub.db:call service. Set this property to false if you do not want to specify values for the $data input parameter. Set this property to true if you want the pub.db:call service to expect values for the $data input parameter. The default is true.
watt.server.jdbc.statementCache
Specifies whether Integration Server is to cache prepared statements for later use. When set to true, the server saves prepared statements in a local cache. When the server receives subsequent requests to a database, it can reuse the prepared statements in the cache instead of recreating them each time a request is made. To use Java heap space efficiently, the server removes cached statements automatically if it is not reused within 30 seconds. The default is false.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
Note:
This parameter is for use with the WmDB package only.
watt.server.jms.csq.maxRedeliveryCount
Specifies the number of attempts to redeliver a document from the client side queue. Specify a positive integer value. The default is 5. If Integration Server is unable to deliver the document in the configured number of attempts, the document is dropped from the client side queue and not delivered. In this situation, Integration Server raises a JMSDeliveryFailureEvent.
Note:
Specifying a large value for this property can impact Integration Server performance if the failure to deliver the document is not a transient error, such as the Broker being unavailable. If the reason a document cannot be delivered is because there is problem with the document itself, Integration Server performance is impacted because it will continue to attempt to redeliver the document for the number of times you configure.
Note:
This parameter applies to JMS messaging, regardless of the JMS provider. The comparable property for webMethods messaging where Broker is the messaging provider is watt.server.publish.maxCSQRedeliveryCount. The comparable parameter for webMethods messaging where Universal Messaging is the messaging provider is watt.server.messaging.csq.maxRedeliveryCount.
watt.server.jms.csq.publishDelayWhileDraining
Specifies the number of seconds that Integration Server waits before publishing a JMS message to the client side queue (CSQ) while the CSQ drains. To use the delay when the CSQ contains one or more messages, specify an integer greater than 0 but less than or equal to 60.
Specify 0 to instruct Integration Server to vary the length of the delay depending on the number of messages in the CSQ. When watt.server.jms.csq.publishDelayWhileDraining is set to 0, Integration Server waits for:
*6 seconds when the number of messages in the CSQ is greater than 0 but less than or equal to 1000
*8 seconds when the number of messages in the CSQ is greater 1000 but less than or equal to 5000
*10 seconds when the number of messages in the CSQ is greater than 5000
watt.server.jms.csq.publishDelayWhileDraining is 0.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.connection.monitorPeriod
Specifies the frequency (measured in seconds) with which Integration Server checks the state of a connection to the JMS provider. The minimum is 1 second. If this parameter is set to less than 1, Integration Server uses the default value instead. The default is 45 seconds.
watt.server.jms.connection.pingDestination
Configures Integration Server to send a keep-alive message to a destination on the JMS provider, thereby preventing the firewall from terminating the connection between Integration Server and a third-party JMS provider. A keep-alive message is a blank, non-persistent JMS message with an immediate time out.
Set this parameter to one of the following values:
Specify
To
blank
Attempt to create a JMS session using the connection between Integration Server and the JMS provider. This is the default.
temp
Create a temporary queue on the JMS provider and send a keep-alive message to the temporary queue. Temp is not case-sensitive.
<destinationName>
Send a keep-alive message to the specified destination on the JMS provider. If the specified destination does not exist on the JMS provider, Integration Server periodically attempts to create a JMS session using the connection between Integration Server and the JMS provider.
Note:
The frequency with which Integration Server sends a keep-alive message is determined by the value of watt.server.jms.connection.pingPeriod.
watt.server.jms.connection.pingPeriod
Specifies how often, measured in seconds, Integration Server should ping the JMS provider. The ping serves as a keep alive request sent to the JMS provider. The default is 300 seconds (5 minutes).
watt.server.jms.connection.retryPeriod
Specifies the length of time, in seconds, that Integration Server waits between connection attempts when a connection to the JMS provider or JNDI provider fails. The default is 20 seconds.
watt.server.jms.connection.update.blockingTime
Specifies the maximum amount of time, measured in milliseconds, that a pub.jms* service will wait for a connection while the connection used by the service is being updated. If Integration Server does not restart the connection before the blocking time elapses, Integration Server throws an ISRuntimeException and the sending service fails. A value of 0 (zero) indicates that Integration Server does not block the pub.jms* services while the JMS connection alias updates; Integration Server throws an ISRuntimeException immediately. The maximum value is 10,000 milliseconds (10 seconds). The default is 1000 milliseconds.
Integration Server resets the watt.server.jms.connection.update.blockingTime parameter to the default value if an invalid value is entered.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.connection.update.restartDelay
Specifies the length of time, measured in milliseconds, Integration Server waits for services sending JMS messages to execute to completion when the connection used by the services needs to be updated. After the restart delay elapses, Integration Server refreshes the connection using the updated connection factory object and then restarts the connection. If the restart delay elapses before the pub.jms*services execute to completion, Integration Server throws an ISRuntimeException and the sending service fails. The maximum value is 10,000 milliseconds (10 seconds). The default is 500 milliseconds.
Integration Server resets the watt.server.jms.connection.update.restartDelay parameter to the default value if an invalid value is entered.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.csq.batchProcessingSize
Specifies the maximum number of messages Integration Server retrieves from the client side queue and then sends to the JMS provider. Integration Server places sent messages in the client side queue when the connection to the JMS provider fails. Integration Server begins to drain the client side queue after the connection to the JMS provider becomes available. The default is 25.
watt.server.jms.guaranteedMultisend.alwaysUseTxLogging
Specifies whether or not Integration Server always uses XA transaction logging when sending a JMS message in accordance with a multisend guaranteed policy. In XA transaction logging, Integration Server logs the state of each transaction. The XA transaction logging allows Integration Server to recover any transactions that did not complete due to Integration Server failure. While this is the most reliable way to ensure the integrity of a transaction, it may be expensive in terms of performance and may not always be necessary. When this property is set to true, Integration Server always uses XA transaction logging and can perform XA transaction recovery for a multisend guaranteed policy regardless of the connection transaction type When set to false, Integration Server uses XA transaction logging only if the connection transaction type is XA_TRANSACTION. The default is false.
watt.server.jms.nirvana.durableSubscriber.includeClientId
Specifies whether the client ID of the JMS connection alias will be used as the prefix in the names of durable subscribers created using Designer. Set to true to use the value of the Client ID property in the JMS connection alias as a prefix in the durable subscriber name. Even if the watt.server.jms.nirvana.durableSubscriber.includeClientId is set to true, if the Client ID property is empty the durable subscriber name will not have a client ID prefix. Set to false to omit the use of the client ID as a prefix. The default is true.
watt.server.jms.producer.pooledSession.timeout
Specifies the number of milliseconds for which an inactive entry remains in the default session pool or a destination-specific pool before Integration Server removes the entry. Integration Server uses this value when -1 is specified for the Idle Timeout field for a JMS connection alias. The default is 60000.
watt.server.jms.trigger.caching.pollingInterval
Specifies the length of time, measured in milliseconds, between polling requests to Universal Messaging to retrieve messages for a JMS trigger that uses prefetch caching (which is also called consumer caching). The default is 3000 milliseconds.
For more information about configuring prefetch caching for a JMS trigger, see webMethods Service Development Help or Using webMethods Integration Server to Build a Client for JMS.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.concurrent.consecutiveMessageThreshold
Specifies the consecutive number of successful requests for more messages that a concurrent JMS trigger must make before the trigger becomes multithreaded. For example, when this property is set to 1000, Integration Serverbegins using multiple threads for a concurrent JMS trigger when the JMS trigger retrieves messages from the JMS provider in 1000 consecutive requests. The default for this property is 0, which indicates that Integration Server does not use a threshold to determine when JMS trigger become multithreaded. When threshold is not used, the concurrent JMS trigger will always be multithreaded when more than one message is available for processing. For more information about using a threshold for thread usage for a concurrent JMS trigger, see Establishing a Threshold for Using Multiple Threads with a Concurrent JMS Trigger.
Note:
The threshold for using multiple threads with concurrent JMS triggers applies to all the concurrent JMS triggers on the Integration Server. This includes standard JMS triggers, SOAP-JMS triggers, and WS-Endpoint triggers. However, the threshold does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.concurrent.primaryThread.pollingInterval
Specifies the length of time (in milliseconds) for which the primary server thread for a concurrent JMS trigger polls the JMS provider for more messages. Each concurrent JMS trigger has a server thread that retrieves messages from the JMS provider. This thread is considered to be the primary thread for the concurrent JMS trigger. A short polling interval increases the amount of CPU used by Integration Server and increases the load on the JMS provider. However, a short polling interval can improve performance under heavy load and in request-reply scenarios. The default is 500 milliseconds.
If a value of 0 is specified, Integration Server uses the javax.jms.MessageConsumer.receiveNoWait() API to retrieve messages from the JMS provider. The javax.jms.MessageConsumer.receiveNoWait() API may or may not be supported by all JMS providers. If the JMS provider from which a JMS trigger receives messages does not support this API then the JMS trigger will be disabled. If this happens, modify the value of watt.server.jms.trigger.concurrent.primaryThread.pollingInterval to be a positive integer. and enable the JMS trigger.
Note:
The default value of 500 milliseconds is not optimal when connecting to Universal Messaging. To improve performance when Universal Messaging is the JMS provider, Integration Server uses a minimum primary polling interval of 3000 milliseconds. If the watt.server.jms.trigger.concurrent.primaryThread.pollingInterval property is set to a value greater than 3000, Integration Server uses the property value for connections to Universal Messaging.
Note:
A longer polling interval may affect the performance of JMS triggers with joins because the JMS trigger must retrieve messages from multiple destinations. If one of the destinations from which a JMS trigger retrieves messages is empty, there will be a delay each time the JMS trigger requests a message from the destination. This can impact overall performance.
Note:
The watt.server.jms.trigger.concurrent.primaryThread.pollingInterval parameter does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval
Specifies the length of time (in milliseconds) with which the secondary server threads for a concurrent JMS trigger poll the JMS provider for more messages. The secondary server threads are the additional threads that can be used to retrieve messages for a concurrent JMS trigger. The number of secondary server threads for a concurrent JMS trigger corresponds to the value Max execution threads property value minus 1. A short polling interval increases the amount of CPU used by Integration Server and increases the load on the JMS provider. A long polling interval can impact the time required for Integration Server to shut down as Integration Server must wait for the polling interval to elapse for each secondary thread used by concurrent JMS triggers. The default value is 1 millisecond.
The value of watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval must be less than or equal to the value of watt.server.jms.trigger.concurrent.primaryThread.pollingInterval.
If a value of 0 is specified, Integration Server uses the javax.jms.MessageConsumer.receiveNoWait() API to retrieve messages from the JMS provider. The javax.jms.MessageConsumer.receiveNoWait() API may or may not be supported by all JMS providers. If the JMS provider from which a JMS trigger receives messages does not support this API then you may see unexpected behavior. If this happens, modify the value of watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval to be a positive integer.
Note:
The default value of 1 millisecond is not optimal when connecting to Universal Messaging. To improve performance, when Universal Messaging is the JMS provider, Integration Server uses a minimum secondary polling interval. If the JMS trigger that receives messages from Universal Messaging uses a join, Integration Server uses a minimum secondary polling interval of 10 milliseconds. If the JMS trigger does not use a join, Integration Server uses a minimum secondary polling interval of 3000 milliseconds. If the configured value is greater than the minimum, Integration Server uses the configured value instead.
Note:
A longer polling interval affects the performance of JMS triggers with joins because the JMS trigger must retrieve messages from multiple destinations. If one of the destinations from which a JMS trigger retrieves messages is empty, there will be a delay each time the JMS trigger requests a message from the destination. This can impact overall performance.
Note:
The watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval parameter does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.extendedDelay.delayIncrementInterval
Specifies the time interval, measured in milliseconds, at which Integration Server introduces the polling delay for an inactive concurrent JMS trigger. If the JMS trigger remains inactive, the same time interval determines when Integration Server increases the extended delay. The default value is 0 which indicates that Integration Server does not use an extended polling delay for inactive concurrent JMS triggers. For more information about delaying polling requests, see Delaying Polling Requests for Concurrent JMS Triggers.
Note:
The watt.server.jms.trigger.extendedDelay.delayIncrementInterval parameter does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.trigger.extendedDelay.delays
Specifies the length of the delay that an inactive concurrent JMS trigger waits before polling the JMS provider for more messages. To increase the delay while the JMS trigger remains inactive, specify a comma-separated list of increasing integers. The watt.server.jms.trigger.extendedDelay.delays parameter is measured in milliseconds and has a default value of: 0, 1000, 2000, 3000.
For more information about delaying polling requests, see Delaying Polling Requests for Concurrent JMS Triggers.
Note:
The watt.server.jms.trigger.extendedDelay.delays parameter does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.trigger.groupTag
Specifies the group tag used in the names of JMS triggers that belong to a trigger group. Integration Server treats JMS triggers with the specified group tag in the name as members of a trigger group. All triggers in a trigger group use the following format for the name: folder.subfolder:originalJmsTriggerName_groupTag_Id
The default is WMTG. If you set the parameter to null(blank), Integration Server does not use trigger groups and the methods in the com.wm.app.b2b.server.jms.consumer.JMSTriggerGroupFacade class cannot be used to create triggers.
Note:
If you change the value of the watt.server.jms.trigger.groupTag parameter and a trigger group already exists on Integration Server, the triggers that were created with the previous group tag will no longer be treated as members of a trigger group.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.trigger.maxDeliveryCount
Specifies the maximum number of times the JMS provider can deliver a message to Integration Server. The default is 100.
watt.server.jms.trigger.maxPrefetchSize
Specifies the maximum number of messages that the webMethods Broker API for JMS will retrieve and cache per request for a JMS trigger. Using pre-fetch cache can speed up the retrieval of messages from the webMethods Broker. Because messages will be placed in Integration Server memory, you may want to decrease this setting if you have JMS triggers receiving very large messages. Otherwise, memory issues can occur. This property only applies to JMS triggers receiving messages from the webMethods Broker. The default is 10 messages.
Integration Server checks this value when a JMS trigger starts. To apply a new value to all JMS triggers, use Integration Server Administrator to disable and then enable JMS triggers. For information about using Integration Server Administrator to disable and enable an individual trigger, see Managing JMS Triggers.
This property only takes effect when the trigger's prefetch property is set to -1.
When working in a cluster of Integration Servers, the behavior controlled by this property might appear at first to be misleading. For example, suppose that you have a cluster of two Integration Servers. Each Integration Server contains the same JMS trigger. Twenty messages are sent to a destination from which JMS trigger receives messages. It might be expected the JMS trigger on Integration Server 1 will receive the first message, the JMS trigger on Integration Server 1 will receive the second message, and so forth. However, what may happen is that the JMS trigger on Integration Server 1 will receive the first 10 messages and the JMS trigger on Integration Server 2 will receive the second 10 messages.
Note:
The watt.server.jms.trigger.maxPrefetchSize parameter does not apply to concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.jms.trigger.monitoringInterval
Specifies the interval, measured in seconds, at which Integration Server executes resource monitoring services for JMS triggers. A resource monitoring service is a service that you create to check the availability of resources used by a JMS trigger service. After Integration Server suspends a JMS trigger because all retry attempts have failed, it schedules a system task to execute the resource monitoring service assigned to the JMS trigger. The default is 60 seconds. Changes to this property take effect the next time Integration Server schedules a system task to execute a resource monitoring service for a JMS trigger.
For more information about building resource monitoring services for JMS triggers, see Using webMethods Integration Server to Build a Client for JMS.
watt.server.jms.trigger.pollingSession.timeout
Specifies the frequency (measured in minutes) with which Integration Server refreshes an inactive connection for a JMS trigger. A JMS trigger session is considered to be inactive when the JMS trigger does not use the session to retrieve messages. The default is 30 minutes.
watt.server.jms.trigger.pooledConsumer.timeout
Specifies the length of time, in milliseconds, that an inactive pooled consumer remains in the consumer pool before it is removed. Integration Server uses a pool of consumers to retrieve and process messages for concurrent JMS triggers. When the timeout value elapses, Integration Server deletes the inactive pooled consumer. For the Integration Server to retrieve more messages for the concurrent JMS trigger, Integration Server must create a new consumer, which entails creating a javax.jms.MessageConsumer and javax.jms.Session. For some JMS providers, this can be an expensive operation. Setting a high value for watt.server.jms.trigger.pooledConsumer.timeout server property results in the JMS session and messageConsumer remaining open for a long period of time. If the load on Integration Server is high, a long timeout value reduces the frequency with which the pooled consumers must be created. However, when the timeout value is high and the load on Integration Server is low there may be unused pooled consumers. The default is 20000 milliseconds.
watt.server.jms.trigger.raiseEventOnException
Indicates whether Integration Server generates a JMS retrieval failure event when a JMS trigger experiences a fatal exception, such as a non-transient error or a message that cannot be reprocessed, during message processing. Specify true if you want Integration Server to generate a JMS retrieval failure event. The default is true.
watt.server.jms.trigger.raiseEventOnRetryFailure
Indicates that Integration Server generates a JMS retrieval failure event when a JMS trigger experiences a retry failure. A retry failure can occur when the JMS provider has reached the max delivery count for a message or when an ISRuntimeException is thrown and the JMS trigger is not configured to recover the message (for example, if retry failure handling for a non-transacted JMS trigger is set to "Throw exception" instead of "Suspend and Retry Later".) When set to true, Integration Server generates a JMS retrieval failure event for a JMS trigger when retry failure occurs. The default is true.
watt.server.jms.trigger.retryOnConsumerError
Determines whether or not Integration Server attempts to re-enable JMS triggers automatically when an error unrelated to the connection to the JMS provider causes the JMS trigger to be disabled. Set watt.server.jms.trigger.retryOnConsumerError to true to instruct Integration Server to re-enable JMS triggers automatically. Set the property to false to instruct Integration Server to leave JMS triggers disabled when the message consumer encounters an unexpected error unrelated to the connection to the JMS provider. The default is true.
watt.server.jms.trigger.reuseJmsTxSession
Specifies whether or not sessions can be reused across multiple transactions for a transacted JMS trigger. When set to true, a transacted JMS trigger will reuse the same JMS session for receiving messages from the JMS provider. When set to false, Integration Server creates and closes a session for each message a transacted JMS trigger receives and processes. The default value is true.
Some JMS providers might not support the use of a single session across multiple transactions. When working with these JMS providers, set watt.server.jms.trigger.reuseJmsTxSession to false.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.trigger.reuseSession
Indicates whether instances of a JMS trigger use the same session on Integration Server. When this property is set to true, the JMS trigger uses a shared session. Each of the trigger services executed by the JMS trigger will use the same session ID. When this property is set to false, Integration Server uses a new session for each instance of a JMS trigger. Reusing sessions for a JMS trigger might improve performance. However, this property does not work with all adapters. If you are working with an adapter that requires the session ID to be unique, set this property to false. The default is false.
Note:
If you use the Adapter for SAP set watt.server.jms.trigger.reuseSession to false if a concurrent JMS trigger has a trigger service that executes multi-step SAP transactions that make calls to the pub.sap.client:lockSession and pub.sap.client:releaseSession services. These services require dedicated sessions.
watt.server.jms.trigger.serial.primaryThread.pollingInterval
Specifies the length of time (in milliseconds) for which the server thread for a serial JMS trigger polls the JMS provider for messages. A short polling interval increases the amount of CPU used by Integration Server and increases the load on the JMS provider. However, shorter polling intervals can improve performance under heavy load and in request-reply scenarios. The default is 500 milliseconds.
If a value of 0 is specified, Integration Server uses the javax.jms.MessageConsumer.receiveNoWait() API to retrieve messages from the JMS provider. The javax.jms.MessageConsumer.receiveNoWait() API may or may not be supported by all JMS providers. If the JMS provider from which a JMS trigger receives messages does not support this API then the JMS trigger will be disabled. If this happens, modify the value of watt.server.jms.trigger.serial.primaryThread.pollingInterval to be a positive integer and then enable the JMS trigger.
Note:
The default value of 500 milliseconds is not optimal when connecting to Universal Messaging. To improve performance when Universal Messaging is the JMS provider, Integration Server uses a minimum primary polling interval of 3000 milliseconds. If the trigger uses a join, Integration Server uses a secondary polling interval which is set to 10 milliseconds. Note that the secondary polling interval is not configurable for a serial JMS trigger
Note:
A longer polling interval affects the performance of JMS triggers with joins because the JMS trigger must retrieve messages from multiple destinations. If one of the destinations from which a JMS trigger retrieves messages is empty, there will be a delay each time the JMS trigger requests a message from the destination. This can impact overall performance.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.startupFailure.restartTaskRetryCount
Specifies the maximum number of retry attempts the trigger restart task makes to start the JMS triggers that fail to start when the JMS connection alias starts up. Integration Server makes the initial start attempt for a JMS trigger when starting the JMS connection alias used by the trigger. If any JMS triggers fail to start when the alias starts, Integration Server uses a trigger restart task to retry starting the failed JMS triggers. The restart task, which uses a separate thread from the thread used to start the alias, runs at an interval specified by the watt.server.jms.trigger.startupFailure.restartTaskRetryInterval parameter. To use a restart task, you must specify a positive integer greater than or equal to 1. The default is 6 retry attempts. Set watt.server.jms.trigger.startupFailure.restartTaskRestryCount to 0 if you do not want Integration Server to attempt to restart JMS triggers that fail to start when a JMS connection alias starts.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.startupFailure.restartTaskRetryInterval
Specifies the number of seconds that the trigger restart task waits between attempts to restart JMS triggers that failed to start when the JMS connection alias started. You must specify a positive integer. The default is 30 seconds.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.jms.trigger.startupFailure.retryCount
Determines the maximum number of retry attempts that Integration Server makes to start a JMS trigger after the trigger fails to start. After the initial trigger startup failure, Integration Server waits an interval of 1000 milliseconds and then retries starting the trigger. If startup of the trigger fails, Integration Server waits 1000 milliseconds and then makes another attempt to start the trigger. Integration Servercontinues in this way until the JMS trigger starts successfully, the JMS connection alias stops running, or the JMS trigger becomes disabled. When starting the trigger fails after Integration Server makes the maximum number of retry attempts, Integration Server can take no further action to start the trigger. Integration Server logs an exception which will be visible in the JMS Trigger Management page of Integration Server Administrator. The JMS trigger remains inactive until the problem is resolved and the trigger is manually restarted (i.e. enabled).
The watt.server.jms.trigger.startupFailure.retryCount parameter must be set to an integer greater than or equal to 0. When the parameter is set to 0, the default, Integration Server does not make any retry attempts. Excessive retry attempts may cause the JMS connection alias startup time to be delayed.
Important:
If you change the setting of this parameter, you must restart for the changes to take effect.
watt.server.jms.trigger.stopRequestTimeout
Specifies the maximum amount of time, measured in seconds that Integration Server waits after a JMS trigger is disabled before forcing the JMS trigger to stop processing messages. The minimum value is 0. The default is 3 seconds.
Note:
If you set watt.server.jms.trigger.stopRequestTimeout to 0, the JMS trigger immediately stops processing messages after a JMS trigger is disabled. In this case, Integration Server stops the trigger immediately and does not wait for any processing to complete. This can result in a javax.jms.IllegalStateException.
You can disable a JMS trigger by invoking the pub.trigger:disableJMSTrigger service or by using or via the Messaging > JMS triggers pages in Integration Server Administrator. For information about disabling JMS triggers, see About JMS Trigger Status and State.
When you save a JMS trigger in Designer, Integration Server stops and then restarts the trigger. In this situation, Integration Server waits 3 seconds before forcing the JMS trigger to stop processing messages. This value cannot be configured.
Note:
when a JMS trigger is disabled while it is processing messages,
Important:
You must restart Integration Server for the new value to take effect.
watt.server.jms.trigger.wmjms.clientIDSharing
Indicates that Integration Server attempts to receive messages from durable subscribers in a load-balanced fashion. When set to true, Integration Server does the following:
*If the durable subscriber specified by the JMS trigger does not exist, Integration Server creates the durable subscriber on the Broker and enables state sharing. Integration Server also uses the message processing mode to set the Shared State Order mode for the durable subscriber. (A message processing mode of serial maps to a shared state order mode of publisher, a message processing mode of concurrent maps to a shared state order mode of none.)
If the durable subscriber already exists, Integration Server does not make any changes to the durable subscriber when it saves the JMS trigger.
*Indicates to the Broker that client identifiers can be shared by setting the com.webmethods.jms.clientIDSharing property within Integration Server to true.
This property only applies when the JMS trigger uses a JMS connection alias that connects to the webMethods Broker using the native webMethods API.
The default is true.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
Important:
You must restart Integration Server for a new value to take effect.
watt.server.jms.wmjms.lms.readTimeout
Specifies the amount of time (measured in milliseconds) that Integration Server waits for the next portion of an input stream before throwing WmReadTimeoutException. The read timeout only applies after Integration Server retrieves the initial piece of the input stream. The default is 30000 milliseconds.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.jndi.searchresult.maxlimit
Specifies the maximum number of records that Integration Server displays when searching for users or groups in the LDAP or central directory and no search criteria are specified. The default is 0. When set to 0, Integration Server displays all available records.
watt.server.jndi.searchresult.pageSize
Specifies the batch size of user groups that Integration Server retrieves from the connected LDAP servers. Use this parameter to limit the page size of LDAP search results. Set this parameter to 0 to retrieve all user groups from the LDAP servers at once. The default value is 1000.
watt.server.json.allowUnquotedFieldNames
The JSON standard requires that field names be enclosed in double quotes. However, when parsing legacy JavaScript as JSON text it may be helpful to allow unquoted field names as JavaScript does not require field names to be enclosed in double quotes. If this parameter is set to true, the pub.json:jsonStringToDocument and pub.json:jsonStreamToDocument services allow unquoted field names in any supplied JSON text. If this parameter is set to false, the services throw a ServiceException when encountering unquoted field names. The default is false.
The watt.server.json.allowUnquotedFieldNames parameter also affects the process of creating document types from a JSON text. If watt.server.json.allowUnquotedFieldNames is set to true and a JSON text with unquoted fields is used as the source for a document type, the resulting document type contains fields that correspond to the unquoted fields as well as the quoted fields. When watt.server.json.allowUnquotedFieldNames is set to false and a JSON text with unquoted fields is used as the source for a document type, Designer throws an exception and does not create the document type.
Important:
You must restart Integration Server for a new value to take effect.
watt.server.json.decode.unescapeSpecialChars
Controls whether Integration Server unescapes the special characters '\n', '\r', '\t', '\b', '\f', '\\', '\"' while parsing JSON documents. If this parameter is set to true, then Integration Server unescapes these special characters (that is, '\n' will be replaced with new line, similarly other characters will also be replaced) in the output document. If this parameter is set to false then Integration Server keep these characters as is in the output document. The default value for this server property is true.
watt.server.json.decodeIntegerAsLong
Converts an integer that Integration Server retrieves from JSON content to either a Long or Integer Java wrapper type. If this parameter is set to true, Integration Server converts the JSON integer to a Long Java wrapper type. If this parameter is set to false, Integration Server converts the JSON integer to a Integer Java wrapper type. The default is true (Long).
watt.server.json.decodeNullRootAsEmpty
Converts a null value that Integration Server retrieves from JSON content to either IData or empty IData. If this parameter is set to false, Integration Server converts the null value to IData. If this parameter is set to true, Integration Server converts the null value to empty IData and subsequent encoding of empty IData creates a JSON text of “{}”. This JSON content is different from the original JSON content (null) as the original null value gets converted to JSON text of "{}". The default is false.
watt.server.json.decodeRealAsDouble
Converts a real number that Integration Server retrieves from JSON content to either a Float or Double Java wrapper type. If this parameter is set to true, Integration Server converts the real number to a Double Java wrapper type. If this parameter is set to false, Integration Server converts the real number to a Float Java wrapper type. The default is true (Double).
watt.server.json.decodeRealAsString
Converts a real number that Integration Server retrieves from JSON content to String. If this parameter is set to true, Integration Server converts the real number to a String. If this parameter is set to false, Integration Server does not convert the real numbers to String instead, real numbers are converted to either Float or Double Java wrapper type depending on the values specified in decodeRealAsDouble. The default is false.
Note:
Error occurs if both watt.server.json.decodeRealAsString and watt.server.json.decodeRealAsDouble parameters are set to true.
watt.server.json.encodeDateAs
Specifies how java.util.Date objects are formatted by Integration Server, including IDataJSONCoder.encode() and the pub.json:documentToJSONString service. When Integration Server responds to a client request with JSON content, the format of java.util.Dates in that response is controlled by this parameter.
*Set this parameter to long to encode Dates as timestamps, specifically the number of milliseconds since Jan 1, 1970 00:00:00. The dates are encoded as JSON numbers.
*Set this parameter to ISO8601 to encode java.util.Date instances in the standard ISO format of YYYY-MM-DD'T'HH:mm:ss.sssZ. The dates are encoded as JSON Strings.
*Set this parameter to a custom format to encode java.util.Date instances in the supplied pattern. The pattern must adhere to the date and time patterns as described in the java.text.SimpleDateFormat class in the Oracle Java API documentation. The dates are encoded as JSON Strings.
If watt.server.json.encodeDateAs is not set, java.util.Date instances are encoded in the standard ISO format of EEE MMM dd hh:mm:ss zzz yyyy, the default formatting provided by java.util.Date.toString().
You can override this setting in individual requests that use the invoke, rest, restv2 or admin directives by including a query parameter ofjsonDateEncoding= format in the URL used to invoke a service, where format is one of the values described above. You can also override this setting when invoking the pub.json:documentToJSONString service with the encodeDateAs input parameter. For more information about pub.json:documentToJSONString, see the webMethods Integration Server Built-In Services Reference.
Note:
You cannot override this setting when using other directives, such as soap or ws.
watt.server.json.iterator.maxBatchSize
Specifies the maximum number of array elements that the pub.json:getNextBatch service can retrieve. The value of this property should be greater than or equal to that of watt.server.json.iterator.minBatchSize. Otherwise, the default value is considered for this property. If the value of watt.server.json.iterator.minBatchSize is 0 (default), you can set any positive integer for this property.
The batchSize parameter in the pub.json:getNextBatch service must be lesser or equal to the value of this property. Otherwise, the service throws an error. The default value is 0, which means that there is no maximum limit on the batch size.
watt.server.json.iterator.maxConcurrentRequests
Specifies the maximum number of concurrent requests for JSON iterator that Integration Server should process. If a positive integer is set for this property, Integration Server limits concurrent iterations accordingly. This can increase the response time for some of the requests. However, it helps to avoid out of memory errors. The default value is 0, which means that there is no maximum limit on concurrent execution of JSON iterator requests.
Note:
You must restart Integration Server for the changes to take effect.
watt.server.json.iterator.minBatchSize
Specifies the minimum number of array elements that the pub.json:getNextBatch service can retrieve. The value set for this property should be less than or equal to that of watt.server.json.iterator.maxBatchSize. Otherwise, the default value is considered for this property. If the value of watt.server.json.iterator.maxBatchSize is 0 (default), you can set any positive integer for this property.
The batchSize parameter in the pub.json:getNextBatch service must be greater or equal to the value of this property. Otherwise, the service throws an error. The default value is 0, which means that there is no minimum limit on the batch size.
watt.server.json.optimizeForUniqueKeys
Controls how Integration Server parses JSON documents based on whether the documents have unique keys or duplicate keys. Integration Server can parse JSON documents faster when you set this parameter based on the nature of the documents you expect to receive. If you expect to process JSON documents that have unique keys or only a few duplicate keys, set this property to true (the default). If you expect to process JSON documents that have a lot of duplicate keys, set this property to false.
Note:
You must restart Integration Server for changes to go into effect.
watt.server.json.prettyPrint
Specifies whether the output of JSONCoder.encode() is formatted with carriage returns and indentation to make the output easier to read. When Integration Server responds to a client request with JSON content, the format of that response is controlled by this property. If this parameter is set to true, Integration Server encodes JSON with carriage returns and indentation to ease readability. The default is false. For more information about JSONCoder, see webMethods Integration Server Java API Reference.
You can override this setting in individual requests that use the invoke, admin, rest, or restv2 directives by including a query parameter of jsonPrettyPrint=true or jsonPrettyPrint=false in the URL used to invoke a service.
Note:
You cannot override this setting when using other directives, such as soap or ws.
You can also set watt.server.json.prettyPrint to specify whether the pub.json:documentToJSONString service uses pretty print formatting in the jsonString output parameter. For more information about pub.json:documentToJSONString, see the webMethods Integration Server Built-In Services Reference.
watt.server.json.quoteFieldNames
Specifies whether or not the pub.json:documentToJSONString service encloses all generated JSON field names in double quotes. The JSON standard requires that field names be enclosed in double quotes. However, you may need the service to produce unquoted field names if the generated JSON text will be processed by an older JavaScript interpreter. Set this parameter to true instruct the pub.json:documentToJSONString service to enclose field names in quotes in the output JSON text. Set this parameter to false to instruct the service to omit the double quotes around field names in the generated JSON text. The default is true.
Note:
Use caution when setting watt.server.json.quoteFieldNames to false as this causes the pub.json:documentToJSONString service to generate non-standard JSON text. This can cause interoperability issues if the JSON text is sent to other organizations.
Note:
You must restart Integration Server for changes to take effect.
watt.server.key
Specifies the license key for the server. There is no default.
watt.server.ldap.checkLocalUserInLDAP
Specifies whether Integration Server should authenticate a local user through the connected LDAP servers or not. Set this parameter to true for Integration Server to authenticate a user through the connected LDAP servers, even when the username exists in the local system. Set this parameter to false to skip LDAP-based authentication if the username exists in the local system. The default value of this parameter is false.
watt.server.ldap.cleanContext
Specifies whether Integration Server should close the TCP/IP connection and clean the LDAP context (the connectionHandle object) after processing a pub.client.ldap service request. When this property is set to true, Integration Server closes the connection and cleans the underlying LDAP context; Integration Server does not return the LDAP context to the pipeline. When this property is set to false (the default), Integration Server does not close the connection and returns the LDAP context to the pipeline.
For more information about the pub.client.ldap services, see webMethods Integration Server Built-In Services Reference.
watt.server.ldap.DNescapeChars
Specifies the characters Integration Server can escape (using the \ character) in distinguished names presented to an LDAP server. By default, this property is set to null, meaning no characters are escaped.
Use this parameter if the distinguished names you are using include special characters that Integration Server needs to escape. For example, if your LDAP server maintains userids such as abc/def, specify the following:
watt.server.ldap.DNescapeChars = /
If you need to escape the \ character, specify it twice:
watt.server.ldap.DNescapeChars = \\
watt.server.ldap.DNescapePairs
Specifies the characters in LDAP distinguished names that Integration Server should not double-escape prior to their presentation to an LDAP server. To escape special characters in a distinguished name, you must precede the character with a backslash (\). By default, the following characters are never double-escaped, and should not be specified in watt.server.ldap.DNescapePairs:
, = + < > # ; / \
If the distinguished names in your LDAP server contain special characters other than those specified above, add them to watt.server.ldap.DNescapePairs so that Integration Server does not double-escape the characters. For example, do not add an equal sign (=) to watt.server.ldap.DNescapePairs, since this is never double-escaped by default. However, if the LDAP distinguished name contains an ampersand (&) and it should be double-escaped, add an ampersand character to watt.server.ldap.DNescapePairs as follows:
watt.server.ldap.DNescapePairs=&
This property has no default value. If no value is supplied, no special characters beyond the set listed above are protected from double-escape. This property is not dynamic. Changes to its value go into effect after Integration Server is restarted.
watt.server.ldap.DNescapeURL
Indicates whether Integration Server should ignore the first three forward slashes (/) in domain names, or to treat them as escape characters. If set to false (the default), Integration Server ignores the first three slashes in a domain name. Integration Server treats the slashes as part of the domain name, not as escape characters, regardless of the escape characters defined in the watt.server.ldap.DNescapeChars and watt.server.ldap.DNescapePairs server configuration parameters.
If set to true, Integration Server treats the forward slashes as escape characters and escapes domain names in accordance to the settings of watt.server.ldap.DNescapeChars and watt.server.ldap.DNescapePairs.
Important:
You must restart Integration Server after you modify the value of this property.
watt.server.ldap.DNstripQuotes
Specifies whether Integration Server should strip leading and trailing quotes from domain names presented to an LDAP server. When set to true (the default), Integration Server strips the quotes from domain names that contain special characters.
Note:
If watt.server.ldap.DNstripQuotes is set to false, Integration Server retains the quotes in the domain names that have them. This could cause lookups to break.
Important:
You must restart Integration Server after you modify the value of this property.
watt.server.ldap.doNotBind
Specifies whether the Integration Server authenticates against the LDAP server. If your Integration Server uses a custom authentication module and you do not require users to be authenticated against the LDAP directory, set this property to true to prevent unnecessary requests to the LDAP server. The default is false.
watt.server.ldap.extendedMessages
Controls whether the Integration Server displays additional information returned from the LDAP server when an authentication error occurs. This information is available only if the LDAP server provides it. Active Directory is an LDAP server that provides this additional information. The default is false.
When set to false, an error message might look like this:
2005-03-08 15:40:33 EST [ISS.0002.0035E] Invalid credentials connecting to
ldap://10.3.33.203:389/dc=KQA,dc=webMethods,dc=com as
CN=bob,OU=ISUsers,DC=KQA,DC=WEBMETHODS,DC=COM
When set to true, the same error would be displayed like this:
2005-03-08 15:40:33 EST [ISS.0002.0035E] Invalid credentials connecting to
ldap://10.3.33.203:389/dc=KQA,dc=webMethods,dc=com as
CN=bob,OU=ISUsers,DC=KQA,DC=WEBMETHODS,DC=COM: [LDAP: error code 49 -
80090308: LdapErr: DSID-0C09030F, comment: AcceptSecurityContext error,
data 52e, vece]
For Active Directory users, the data code (data 52e above) contains the reason the authentication failed. You can convert the code to decimal and look it up on http://msdn.microsoft.com/library/en-us/debug/base/system_error_codes.asp to determine the problem.
watt.server.ldap.extendedProps
Specifies LDAP environment properties that the Integration Server will pass directly to an LDAP implementation when initializing a JNDI context. It takes this form:
For example, if you are using a specialized JNDI provider other than the default, or if your LDAP directory requires a special JNDI property to be passed into the environment when a context is created, you could set the property customProperty to customValue:
watt.server.ldap.extendedProps=java.naming.customProperty=customValue
There is no default.
watt.server.ldap.groupSearchFilter
Specifies the filter that Integration Server and SoftwareAG Platform Manager (SPM) plugin use when searching for user groups in the connected LDAP servers. This parameter helps to narrow down the search results and has no default value.
watt.server.ldap.includeOnlyActiveGroups
Specifies whether empty groups can be associated with an ACL. Set to true if only LDAP groups with at least one member can be associated with an ACL. to false if any LDAP group, even empty ones, can be associated with an ACL. The default is true.
Note:
In Integration Server Administrator. you can enter search criteria for locating the groups that you want to assign to the ACL. When watt.server.ldap.includeOnlyActiveGroups is set to false, the search results return any LDAP element (not just groups) that matches the criteria.
watt.server.ldap.memberInfoInGroups
Controls where Integration Server looks for LDAP group membership information. When set to true, the default, the Integration Server looks for group membership information in the group object. When set to false, the Integration Server looks for group membership information in the user object.
watt.server.ldap.retryCount
Specifies how many times Integration Server should automatically try to reconnect to an LDAP server after a network outage or LDAP server restart. If set to 0, Integration Server will prompt the LDAP user for credentials rather than retrying the connection. If set to a positive integer, Integration Server will retry the connection the number of times specified. The default is 5.
watt.server.ldap.retryWait
Specifies the number of milliseconds that Integration Server should wait before trying to reconnect to an LDAP server after a network outage or LDAP server restart. When set to 0, if there is a transient failure while communicating with LDAP, Integration Server will not try to reconnect to the LDAP server. If set to a positive integer, Integration Server will retry the connection the number of times specified in watt.server.ldap.retryCount and will wait the amount of time specified in watt.server.ldap.retryWait between retry attempts. The default is 2000 (milliseconds).
watt.server.licenses
Specifies the number of licenses. The default is 1.
watt.server.log.alertMaxEntries
Specifies the number of entries that you can display in the Logs > logName page beyond which Integration Server Administrator displays an alert message. If the value entered in the Number of entries to display field in the Logs > logName page is more than the value specified for watt.server.log.alertMaxEntries, Integration Server Administrator displays a message informing that the number of requested entries exceeds the threshold and that displaying more entries might affect Integration Server performance. If no value is specified for watt.server.log.alertMaxEntries, Integration Server Administrator does not display any alert message.
watt.server.log.maxEntries
Specifies the default number of log entries to be displayed in the log viewing utility. The default is 35 entries (the most recent entries). For complete information, see Changing the Display Permanently for All Logs.
watt.server.log.orphanLoggers
Specifies the orphan loggers that you want to be adopted by the IS logging hierarchy. Some Integration Server logs become filled with debug messages even though the logging level is set to be higher than debug. This can happen when Integration Server has orphan loggers (loggers that are not part of the IS logging tree hierarchy) and a custom application configures the root logger of log4j. If there is not a custom configuration of log4j, the orphan loggers will inherit the logging levels specified in the IS logging tree hierarchy. However, if a custom application reconfigures the root logger in the log4j configuration file, the orphaned loggers inherit the logging level from the root logger. Consequently, if the log4j.rootLogger is set to DEBUG, the orphaned loggers will log at the Debug level.Use this parameter to prevent orphan loggers from logging at the modified log4j.rootLogger level. Use a comma to separate multiple orphan loggers. For example:
watt.server.log.orphanLoggers=WEBMETHODS.DEFAULT,
log4j.logger.com.softwareag.wsstack,log4j.logger.com.softwareag.security,
Debug.com.webmethods.lwq,com.webmethods.portal.jms.db.DbJMSClient
This is the default value.
watt.server.log.queued
Specifies whether the server is to queue log entries written by its facilities in memory, then use a background thread to write them to the server log. The default is true (queue log entries). For complete information, see the webMethods Audit Logging Guide.
watt.server.log.refreshInterval
Specifies the length of time (in seconds) that Integration Server Administrator refreshes the displayed server log. The default is 90 seconds. For complete information, see Changing the Display Permanently for All Logs.
watt.server.logEncoding
Specifies the encoding that Integration Server uses for reading and writing text to the log files or to the console. The default is UTF-8.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.logRotateInterval
Specifies the length of the log recycle interval (in milliseconds) for log entries. Starting with Integration Server 9.7, this server configuration parameter has been renamed watt.server.statsLogRotateInterval.
The watt.server.logRotateInterval parameter was removed from Integration Server after 8.2 SP2. When it was reintroduced for the following fixes, the scope of the parameter changed so that it affected only the statistics log:
*IS_9.0_SP1_Core_Fix6
*IS_9.5_SP1_Core_Fix3
*IS_9.6_Core_Fix2
If you migrate from Integration Server 9.6 or earlier to Integration Server 9.7 or higher, Integration Server:
*Changes the name of the server configuration parameter in server.cnf from watt.server.logRotateInterval to watt.server.statsLogRotateInterval
*Converts the value of the server configuration parameter from milliseconds to minutes
*Uses watt.server.statsLogRotateInterval to set the log recycle interval for the statistics log file
watt.server.loginFailureLimit
Specifies the number of times a user can supply the wrong login credentials before Integration Server alerts the administrator and resets the count of login failures to 0. For example, if watt.server.loginFailureLimit is set to 5, when a user supplies the wrong login credentials for the sixth time, Integration Server sends an email alert to the administrator and resets the count of login failures to 0. The default value is 5.
watt.server.login.userFtpDir
Specifies whether the user who has connected to Integration Server through an FTP listener is to be placed in the default FTP root directory or the client user directory. When this property is set to false (or not specified), the user is logged into the FTP root directory. The user must then issue the cd command to access the client user directory. When this property is set to true, the user is logged into the client user directory. The default value is false.
The FTP root directory can be the default directory named userFtpRoot in your Integration Server home directory or a directory defined by the user using the watt.server.userFtpRootDir property.
Important:
You must restart Integration Server after you modify the value of this property.
watt.server.logs.dateStampFmt
Specifies the format of the date and timestamp to be used in audit log files (FailedAudit_*, WMERROR*, WMSESSION*, WMTXIN*, WMTXOUT*). The format you specify must adhere to the java.text.SimpleDateFormat class. If the watt.server.logs.dateStampFmt property is not set, Integration Server uses the default format, which is yyyy-MM-ddThh:mm:ss.SSSZ (for example, 2010-04-19T19:07:21.505Z).
watt.server.logs.dateStampTimeZone
Specifies the time zone to be used in audit log files (FailedAudit_*, WMERROR*, WMSESSION*, WMTXIN*, WMTXOUT*). The format you specify must adhere to the java.util.TimeZone class (for example, watt.server.logs.dateStampTimeZone=EST). If this property is not set, Integration Server uses local time zone hosting. For this property to take effect, the watt.server.logs.dateStampFmt must also be specified.
watt.server.math.floatOperation.mode
Specifies whether the pub.math:*Floats services return the exact result of an operation involving two floating point numbers, the result as calculated by the JVM, or the result based on a fixed number of decimal places.
Set this parameter to one of the following values:
Specify
pub.math:*Floats services to
dynamic
Return the precise result of the math operation. For example, when using pub.math:addFloats to add 62.98 and 23, the service returns a sum of 85.98.
default
Return the result of the math operation as calculated by the JVM.
For example, when using pub.math:addFloats to add 62.98 and 23, the service returns a sum of 85.97999999999999.
This is the default behavior.
fixed
Return the result rounded to a pre-determined number of decimal places. For the pub.math:addFloats and pub.math:subtractFloats services, Integration Server rounds the result to 3 decimal places.
For the pub.math:multiplyFloats service, Integration Server rounds the product to 16 decimal places.
For the pub.math:divideFloats service, Integration Server rounds the result to 17 decimal places.
Note:
If you specify a value for the precision input parameter in pub.math:*Floats services, the precision value is given precedence over the value of the property 'watt.server.math.floatOperation.mode. For more information about the pub.math:*Floats services, see webMethods Integration Server Built-In Services Reference.
Important:
You must restart Integration Server for a new value to take effect.
watt.server.mediator.directives
Specifies a comma-separated list of directives used to detect API Gateway requests. When Integration Server receives a request that uses the directives specified by the watt.server.mediator.directives server configuration parameter, Integration Server checks to see if the web service invoked by the request is a API Gateway service. If the web service is a API Gateway service, Integration Serverassigns the default user to the request. The default API Gateway directives are "'ws,mediator,gateway".
watt.server.messaging.csq.maxRedeliveryCount
Specifies the maximum redelivery attempts Integration Server makes when publishing a message from the client side queue (CSQ) to Universal Messaging. When Integration Server publishes messages and the Universal Messaging is not available, Integration Server writes guaranteed messages to the CSQ if one is configured for use with the Universal Messaging connection alias. When Universal Messaging becomes available, Integration Server drains the CSQ by publishing message from the CSQ to Universal Messaging. If the initial attempt to publish the message to Universal Messaging from the CSQ fails, Integration Server makes subsequent attempts until the message is published successfully or Integration Server makes the maximum redelivery attempts specified by this parameter. Each attempt to publish to Universal Messaging from the CSQ is considered a redelivery attempt. If Integration Server makes the maximum redelivery attempts and all attempts have failed, Integration Server discards the document. The watt.server.messaging.csq.maxDeliveryCount parameter must be set to a positive integer. The default value is 5.
Note:
This parameter applies to webMethods messaging where Universal Messaging is the messaging provider. The comparable parameter for webMethods messaging where Broker is the messaging provider is watt.server.publish.maxCSQRedeliveryCount. The comparable parameter for JMS messaging, regardless of provider, is watt.server.jms.csq.maxRedeliveryCount.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.messaging.csq.publishDelayWhileDraining
Specifies the number of seconds that Integration Server waits before publishing a message to the client side queue (CSQ) while the CSQ drains. To use the delay when the CSQ contains one or more messages, specify an integer greater than 0 but less than or equal to 60.
Specify 0 to instruct Integration Server to vary the length of the delay depending on the number of messages in the CSQ. When watt.server.messaging.csq.publishDelayWhileDraining is set to 0, Integration Server waits for:
*6 seconds when the number of messages in the CSQ is greater than 0 but less than or equal to 1000.
*8 seconds when the number of messages in the CSQ is greater 1000 but less than or equal to 5000.
*10 seconds when the number of messages in the CSQ is greater than 5000
The default value for watt.server.messaging.csq.publishDelayWhileDraining is 0.
The watt.server.messaging.csq.publishDelayWhileDraining applies to webMethods messaging for which the messaging provider can be Broker or Universal Messaging.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.messaging.debugTrace
Enables an extra level of verbose logging for webMethods messaging triggers that receive messages from Universal Messaging or through Digital Event Services. You can configure the additional logging globally or at the individual webMethods messaging trigger level.
*To enable debugTrace logging for all webMethods messaging triggers, set the watt.server.messaging.debugTrace property to true. The default value is false.
For changes to this parameter to take effect, you need to disable and then enable the messaging connection aliases used by the triggers.
*To enable debugTrace logging for a specific webMethods messaging trigger, append the fully qualified webMethods messaging trigger name to the watt.server.messaging.debugTrace property and set that property to true. For example, to enable debugTrace logging for the webMethods messaging trigger named myFolder:myMessagingTrigger, add the following parameter on the Settings > Extended page:
watt.server.messaging.debugTrace.myFolder:myMessagingTrigger=true
For this parameter or changes to this parameter to take effect, you need to disable and then enable the webMethods messaging trigger specified in the property. For information about using Integration Server Administrator to disable and enable an individual trigger, see Suspending or Resuming Document Processing for a Specific webMethods Messaging Trigger
Note:
For the increased logging to appear in the server log, you must set the logging level for server facility 0153 Dispatcher (Universal Messaging) to Trace.
watt.server.messaging.deliverNotificationErrors
Specifies whether Integration Server generates and delivers pub.publish.notifcation.error messages. When set to true, Integration Server generates and delivers pub.publish.notification:error messages when an error or exception condition during webMethods messaging trigger processing. The generation and delivery of notification error messages may result in the generation of Adapter:Error events. When set to false, Integration Server does not generate or deliver pub.publish.notification:error messages. The notification error messages are suppressed. The default value of this property is true.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.messaging.trigger.startup.useServerThread
Specifies whether the thread used to start and run a webMethods messaging trigger that receives messages from Universal Messaging counts toward the thread usage limit established by the Maximum Threads value for document processing. When set to true, the thread that runs the trigger does not count towards the usage limit set by the Maximum Threads for document processing. When set to false, the thread used to run the trigger and listen for messages counts toward the thread usage limit set by the Maximum Threads for document processing. The default is true.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.metadata.registry.timeout
The number of minutes a connection to a CentraSite registry can remain inactive before Integration Server closes it. Integration Server connects to one or more CentraSite registries to publish and retract metadata for your Integration Server assets. If no assets are published to or retracted from a CentraSite registry for a period of time, Integration Server closes the connection to that registry. The default period is 10 minutes.
watt.server.metering.simulator.enabled
Specifies whether the metering simulator is enabled. Set this parameter to true to have Integration Server gather metering data for top-level services and write metering simulation messages to the server log. Set to false to disable the metering simulator. The default is false.
For more information about the metering simulator, see Simulating Metering in Integration Server .
watt.server.meteringAgent.logInterval
Specifies the interval, in minutes, between executions of the system task Metering Agent Diagnostic Log which performs a "dry run" of sending data to the webMethods Metering Server. Specify a positive integer. The default is 60 minutes.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.mime.decodeHeaders
Determines the global default behavior for how the pub.mime:createMimeData service handles header decoding. The property can have one of the following values:
Specify
To indicate that
NONE
Specifies that by default the pub.mime:createMimeData service does not decode the MIME header or body part headers. This is the default.
ONLY_MIME_HEADER
Specifies that by default the pub.mime:createMimeData service decodes the MIME header only.

ONLY_BODY_PART _HEADERS
Specifies that by default the pub.mime:createMimeData service decodes the body part headers only.
BOTH
Specifies that by default the pub.mime:createMimeData service decodes the MIME header and the body part headers.
Note:
The values are not case sensitive.
Note:Integration Server uses the value of the watt.server.mime.decodeHeaders to determine whether or not to decode headers in a MIME message only when the pub.mime:createMimeData service specifies no value for the decodeHeaders input parameter. For information about the pub.mime:createMimeData service and the decodeHeaders input parameter, see the webMethods Integration Server Built-In Services Reference.
watt.server.mime.largeDataThreshold
Specifies the value in bytes that determines when the pub.mime services utilize the temporary space (Tspace). If data is greater than this value, pub.mime:addBodyPart stores the data in a Tspace. Further, the pub.mime:getEnvelopeStream service returns a mimeMessage instead of an envStream. The default value is 26214400 (25 MB).
watt.server.mqtt.producer.maxInflight
Specifies the maximum number of MQTT messages that can be published at one time using the same MQTT connection alias. The default is -1 which means that Integration Server relies on the Paho client to set the max inflight property. Paho uses a default value of 10 for the max inflight property. Set the watt.server.mqtt.producer.maxInflight property to a value greater than 0 to use the value set by the configuration parameter as the value of the max inflight property.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.netEncoding
Specifies the encoding the server is to use when reading and writing text to the network. This setting has no effect on text that is explicitly encoded in a particular encoding. The default is UTF-8. The encoding parameter in the pub.client:soapHTTP service, if set, overrides the watt.server.netEncoding setting. For more information about pub.client:soapHTTP, see webMethods Integration Server Built-In Services Reference.
When the pub.client:http service submits a password digest for authentication (that is, the auth/type field is set to Digest) and the HTTP server response includes the header field “Content-Type” but does not contain the charset parameter, Integration Server uses the value of the watt.server.netEncoding server configuration parameter as the default character set.
watt.server.new.http.session.context
Specifies whether Integration Server should create a new session object when executing the pub.client:http service. When this property is set to true, Integration Server ignores the values from the session object of the last invocation of pub.client:http and creates a new session object. When this property is set to false, Integration Server uses the values from the existing session object. The watt.server.new.http.session.context value can be overridden by the newSession parameter in the pub.client:http service. The default value is false.
watt.server.noObjectURL
Specifies the URL to which the server redirects a request after three attempts to log on to the Integration Server Administrator have failed because the server cannot find the document the user is requesting. The default is for the server to display an HTML page saying "No such object."
watt.server.noAccessURL
Specifies the URL to which the server is to redirect a request after three attempts to log on to the Integration Server Administrator have failed because the user does not have access to the requested document. The default is for the server to display an HTML page saying "Access denied."
watt.server.ns.backupNodes
Specifies whether services are removed completely when they are deleted. When set to true, service node.ndf files will be renamed to node.bak when they are deleted. The default is false.
watt.server.ns.dependencyManager
Specifies whether the dependency checking features are enabled or disabled. When set to true, the dependency checking features identify elements that will be affected by moving, renaming, or deleting another element. For optimization in a production environment, you might set this parameter to false. The default for this parameter is true.
watt.server.ns.decodeJavaService
Specifies whether Integration Server decodes and Designer displays non-ASCII Unicode characters in the body of a Java service. When you save Java services, Integration Server encodes non-ASCII Unicode characters as ASCII Unicode escape sequences. By default, Integration Server does not decode the escape sequences. Therefore, when Integration Server sends Java service code to Designer, escape sequences appear in Designer instead of the original Unicode characters. Set to true if you want Integration Server to decode the escape sequences so that Designer displays the original Unicode characters instead of the escape sequences. The default is false.
watt.server.ns.hideWmRoot
Indicates whether Integration Server should hide the WmRoot package from the Software AG Designer workspace. When set to true (the default), Designer does not display the WmRoot package in the workspace.
watt.server.ns.lockingMode
Specifies whether file locking is enabled on the Integration Server:
*To enable local locking on the Integration Server, set this value to full. This is the default value.
*To disable user locking and show no locks, set this value to none.
*To disable user locking but show system locks, set this value to system. This value is required to use the Local Service Development feature.
watt.server.ns.logDuplicateDocTypeRegistrationAsError
Indicates whether to suppress or continue logging of error messages related to registration of duplicate universal names for a document type.
When the same WSDL document is used to generate multiple consumer Web service descriptors and multiple WSDL first provider Web service descriptors, Integration Server creates multiple document types with the same explicit universal name. It is when loading a package containing these document types that Integration Server logs error messages specifying duplicate universal name registrations multiple times, which can clutter the log file.
Set the value of the parameter to false to suppress the logging of the error messages and true to resume the logging. The default value of this parameter is true.
Note:
Setting watt.server.ns.logErrorsOnRegisteringMultipleDocTypesForAUniversalName to false suppresses the error messages about duplicate universal names only. It does not resolve the duplicate names.
watt.server.oauth.approvalpage.footer
Specifies the footer information that Integration Server displays on the OAuth approval page. There is no default.
watt.server.oauth.approvalpage.header
Specifies the heading information that Integration Server displays on the OAuth approval page. The default is Resource access approval.
watt.server.oauth.approvalpage.logo
Specifies the URL of the image file that Integration Server displays on the OAuth approval page. Keep the following points in mind when specifying an image file:
*Image files can be of any width, but can be no larger than 92 pixels high.
*You can specify an image of any image file format (for example, .gif, .png, .jpeg, or another image file format) that your browser can display.
*The image file does not have to reside on Integration Server. If the image file is hosted on another server, provide the absolute path.
The default is /WmPublic/images/fw_logo_sag.gif, which is 234x92 pixels.
watt.server.oauth.approvalpage.title
Specifies the title that Integration Server displays on the OAuth approval page. The default is Access Approval.
watt.server.oauth.authCode.expirySeconds
Specifies the amount of time (in seconds) before the OAuth authorization code expires. A value of -1 indicates that the authorization code never expires. The maximum value is 2147483647. The default is 600.
The value of the watt.server.oauth.authCode.expirySeconds parameter is tied to the value of the Authorization code expiration interval field on the Security > OAuth > Edit OAuth global settings page in Integration Server Administrator. For more information about setting the expiration time for the OAuth authorization code, see Configuring OAuth.
watt.server.oauth.authServer.alias
Specifies the alias of the remote server that Integration Server uses as an authorization server. The value should match the Alias field on the External servers > Remote servers page of Integration Server Administrator. For example, local.
Note:
You must add the remote server on the External servers > Remote servers page of Integration Server Administrator before specifying the alias in watt.server.oauth.authServer.alias.
The value of the watt.server.oauth.authServer.alias parameter is tied to the value of the Authorization server field on the Security > OAuth > Edit OAuth Global Settings page in Integration Server Administrator. Software AG recommends that you use Integration Server Administrator to specify the remote server alias to use as an authorization server instead of using the watt.server.oauth.authServer.alias property. For more information about specifying the remote server alias, see Configuring OAuth.
watt.server.oauth.custom.responseHeader
When set to true, OAuth and OpenID errors that are returned to client applications and to end users appear in the HTTP response header with a header attribute name of X-OAuth-Error. For most OAuth and OpenID errors, Integration Server returns a status code in the range of 400 - 599 and the error message is returned in the body of the HTTP response. Some browsers do not display the response body when the status code is not successful (200 - 299). Problems with your applications that use OAuth or OpenID can be easier to troubleshoot when the error message is in the response header. When the Server logging facility "0038 HTTP Header" is set to TRACE, the response header is visible in the server log. If watt.server.oauth.custom.responseHeader is true, OAuth and OpenID error messages will appear as X-OAuth-Error response header attributes in the server log.
The default value for watt.server.oauth.custom.responseHeader is false.
watt.server.oauth.disableClient.disableTokens
Specifies whether a client access token issued to a client account that is disabled can be used to access resources. When set to true, the Integration Server introspection endpoint, thepub.oauth:introspectToken service, considers the token to be inactive if the client account to which the token was issued is disabled. The service returns a value of false for the active output parameter. The OAuth resource server, whether it's an Integration Server or another vendor, will not allow access to the requested resource. When set to false, Integration Server introspection endpoint does not consider the enabled/disabled state of the client account to which the access token was issued when evaluating an access token. The default is true.
watt.server.oauth.log.authErrors
Specifies whether Integration Server writes OAuth authorization failures to the error log. When set to true, Integration Server writes all OAuth authorization failures to the error log. When set to false, Integration Server does not write OAuth authorization errors to any log. The default is false.
watt.server.oauth.requireHTTPS
Indicates whether Integration Server requires that client applications use HTTPS to access the pub.oauth* services. If you set the value of this property to false, Integration Server allows client applications to use HTTP to access the pub.oauth* services. The default is true.
If you set the value of this property to true and the client application accesses any of the pub.oauth services over HTTP, Integration Server issues an HTTP 400 error response to the client and writes a service exception to the error log.
Note:
To conform to the OAuth 2.0 Authorization Framework, you must set this property to true.
Important:
To simplify development, you can set watt.server.oauth.requireHTTPS to false, but you should require HTTPS in production in accordance with the OAuth Framework. If you do not require HTTPS, the authorization server transmits access tokens in clear text, making them vulnerable to theft.
The value of the watt.server.oauth.requireHTTPS parameter is tied to the value of the Require HTTPS field in the Security > OAuth > Edit OAuth global settings page of the Integration Server Administrator. For more information about requiring HTTPS for accessing OAuth services, see Configuring OAuth.
For more information about the pub.oauth services, see webMethods Integration Server Built-In Services Reference.
watt.server.oauth.requirePKCE
Specifies whether PKCE is required for all public OAuth clients using the authorization code grant. When set to true, all public OAuth clients must supply a code_challenge value to the authorization endpoint (pub.oauth:authorize service) and a code_verifier value to the token endpoint (pub.oauth:getToken service). When watt.server.oauth.requirePKCE is not set to true (for example the value is false or null), public OAuth clients are not required to supply the additional inputs. However, any public client that does send a code_challenge to the authorization endpoint will be using the PKCE feature in Integration Server to mitigate the authorization code interception attack. A subsequent request by the client to the token endpoint must include the code_verifier input parameter.
The default value for watt.server.oauth.requirePKCE is false.
The value of the watt.server.oauth.requirePKCE parameter is tied to the value of the Require PKCE field in the Security > OAuth > Edit OAuth global settings page of the Integration Server Administrator. For more information about requiring PKCE, see Using PKCE with the Authorization Code Grant.
watt.server.oauth.requirePost
Indicates whether Integration Server requires that client applications use HTTP POST method to access the pub.oauth* services. If you set the value of this property to false, Integration Server allows client applications to use the HTTP GET method to access the pub.oauth* services. The default is true.
If you set the value of this property to true and the client application accesses any of the pub.oauth services using an HTTP method other than POST, Integration Server issues an HTTP 400 error response to the client and writes a service exception to the error log.
Note:
To conform to the OAuth 2.0 Authorization Framework, you must set this property to true.
Important:
To simplify development, you can set watt.server.oauth.requirePOST to false, but you should require the HTTP POST method in production in accordance with the OAuth Framework.
watt.server.oauth.token.defaultExpirySeconds
Specifies the amount of time (in seconds) that access tokens are valid before expiring. A value of -1 indicates that authorization tokens never expire. The maximum value is 2147483647. The default is 3600.
The value of the watt.server.oauth.token.defaultExpirySeconds parameter is tied to the value of the Access token expiration interval field in the Security > OAuth > Edit OAuth global settings page of the Integration Server Administrator. For more information about the Access token expiration interval field, see Configuring OAuth.
watt.server.oauth.token.endpoint.auth
Specifies whether the token endpoint accepts an existing session or requires credentials for authentication. Set to "session" to indicate that the token endpoint will accept requests from clients that have an active session on Integration Server. If these clients supply a valid session identified in the Cookie request header, the clients do not have to provide credentials to use the pub.oauth:getToken, pub.oauth:getAccessToken, and pub.oauth:refreshAccessToken services. Set to "credentials" if clients need to provide their credentials in the Authorization request header every time they request a new access token or refresh an existing access token by calling the pub.oauth:getToken, pub.oauth:getAccessToken, and pub.oauth:refreshAccessToken services. The default value is session.
The value of the watt.server.oauth.token.endpoint.auth parameter is tied to the value of the Token endpoint authentication field in the Security > OAuth > Edit OAuth global settings page of the Integration Server Administrator. . For more information about the Token endpoint authentication field, see Configuring OAuth.
watt.server.oauth.token.endpoint.internal.requireSecret
Specifies whether Integration Server ensures that authorization code provided by a confidential client invoking the OAuth token endpoint service was issued to the confidential client when the OAuth token endpoint service is invoked directly because it is on the same Integration Server acting as the OAuth authorization server. When set to true, Integration Server uses the credentials supplied by the requesting client to ensure that the authorization code provided by the client requesting the OAuth token matches the credentials of the client that requested the authorization code. The client_id and client_secret must be in the input pipeline passed to the token endpoint service. When set to false, Integration Server does not ensure that the authorization code provided by the client matches the credentials of the client that actually requested the token. The default is false, which is less secure.
Note:
The watt.server.oauth.token.endpoint.internal.requireSecret value applies when getting an initial access token and when using a refresh token to get a new access token.
Note:
Public clients doing an invoke of the token endpoint service on the same Integration Server as the redirection endpoint must continue to include their client_id in the input pipeline passed to the token endpoint service.
Clients that use HTTP or HTTPS to request an access token from the OAuth token endpoint must continue to send these requests as they have been.
*Confidential clients must use their client_id and client_secret in the HTTP Authorization header.
*Public clients must include their client_id in the body of the request.
Note:
The services that act as the OAuth token endpoint are pub.oauth:getAccessToken in Integration Server 10.1 and pub.oauth:getToken in later releases.
watt.server.package.maxSizeMB
Specifies the maximum expanded size of a package that can be installed, measured in megabytes. A package whose expanded size is larger than this parameter value cannot be installed. The default value is 10000 (10 gigabytes).
watt.server.package.parallel.threads
Specifies the maximum number of threads that you want Integration Server to use when loading IS packages at startup. The threads are from a thread pool that Integration Server uses only at startup and specifically for package loading. If you want Integration Server to load packages sequentially, set the value to 1. If you want Integration Server to load packages in parallel, set the value to 2 or higher. It is recommended that you do not exceed 10. The default value is 6.
Note:
If you set watt.server.package.parallel.threads to 0 or a negative number, Integration Server loads packages sequentially.
watt.server.package.pre82WSD.loadExternalResources
Specifies whether, at package load time, Integration Server loads the external resources for a consumer web service descriptor or a WSDL first provider web descriptor created on a pre-8.2 version of Integration Server with the Pre-8.2 compatibility mode property set to true.
When this parameter is set to true, Integration Server resolves all the import and include statements in the source WSDL document and related XML Schema definition files for consumer web service descriptors or WSDL first provider web service descriptors at the package load time.
When this parameter is set to false, Integration Server skips loading the external resources contained in the source WSDL document used to create the web service descriptor. In some environments, setting this parameter to false may speed up the loading of web service descriptors. The default is true.
Note:
This parameter is deprecated because the web services implementation introduced in Integration Server 7.1 is deprecated as of Integration Server 10.4. The web services implementation introduced in Integration Server version 7.1 handles web service descriptors that run in pre-8.2 compatibility mode.
watt.server.partner
Specifies the IP address or domain name of a hub server. This setting allows the partner server to issue a remote invoke request to a remote Integration Server. Integration Server will ignore a port number if you specify one as part of an IP address.
watt.server.password.historyLength
Specifies the maximum number of previously set passwords that Integration Server saves in the history for a user. You cannot choose a password that matches with any of the passwords stored in the memory for a user account. The default value is 0.
The watt.server.password.historyLengthdisplays the value specified in the Number of Old Passwords to Remember field on the Security > User management > Password Restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.maxIdenticalCharsInARow
Specifies the maximum number of identical characters in a row a password can contain. When a user creates or changes a password, he or she must create a password that does not exceed the limit of continuos identical characters as specified by this parameter. If the number identical characters in a row exceeds for the new password, then based on the Password Enforcement Mode Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter. The default is 3.
The watt.server.password.maxIdenticalCharsInARow identifies the value specified in the Maximum Number of Identical Characters in a Row field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.maxLength
Specifies the maximum number of characters (alphabetic characters, digits, and special characters combined) the password must contain. When a user changes a password, he or she must create a password for which the maximum number of characters cannot exceed beyond the value specified by this parameter. If the value exceeds, Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter. The default is 64 characters.
The watt.server.password.maxLength identifies the value specified in the Maximum Password Length field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.minDigits
Specifies the minimum number of digits a password must contain for non-administrator users. When a non-administrator user changes a password, he or she must create a password containing at least the number of digits specified by this parameter. If the minimum number of digits is not met, Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter. The default is 1.
The watt.server.password.minDigits identifies the value specified in the Minimum Number of Digits field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.minLength
Specifies the minimum number of characters a password must contain for non-administrator users. The character length includes upper and lower case alphabetic characters, digits (0-9), and special characters combined. When a non-administrator user changes a password, he or she must create a password containing at least the number of characters specified by this parameter. If the minimum length is not met, Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter. The default is 8.
The watt.server.password.minLength identifies the value specified in the Minimum Password Length field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.minLowerChars
Specifies the minimum number of lowercase alphabetic characters a password must contain for non-administrator users. When a non-administrator user changes a password, he or she must create a password containing at least the number of lowercase characters specified by this parameter. If the minimum is not met, Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter. The default is 2.
The watt.server.password.minLowerChars identifies the value specified in the Minimum Number of Lowercase Characters field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.minSpecialChars
Specifies the minimum number of special characters, such as asterisk (*), period(.), and question mark(?), a password must contain for non-administrator users. When a non-administrator user changes a password, he or she must create a password containing at least the number of special characters specified by this parameter. If the minimum is not met, Integration Server sends a warning message to the Administrator user. The default is 2.
Note:
A password cannot begin with an asterisk (*).
The watt.server.password.minSpecialChars identifies the value specified in the Minimum Number of Special Characters field on the Security > User management > Password restrictions > Edit password restrictions page in Integration Server Administrator.
watt.server.password.minUpperChars
Specifies the minimum number of uppercase alphabetic characters a password must contain for non-administrator users. When a non-administrator user changes a password, he or she must create a password containing at least the number of uppercase characters specified by this parameter. If the minimum is not met, Integration Server sends a warning or error message to users based on the value specified for watt.server.password.mode server configuration parameter.
watt.server.password.mode
Specifies whether or not to enforce the password restrictions when passwords are set by administrator or non-administrator users. When set to strict, the password restrictions are enforced on all users and when set to lax, the password restrictions are enforced on non-administrator users. The default is lax.
watt.server.pipeline.processor
Specifies whether to globally enable or disable the Pipeline Debug feature. When set to true, Integration Server checks the Pipeline Debug values for the service at run time. You can view and set the Pipeline Debug values in the Properties view in Designer. When set to false, Integration Server ignores the Pipeline Debug options set for the service in Designer. The default is true.
Enable this property in development environments where testing and debugging is performed. In a production environment, however, disabling this property is recommended.
Important:
You must restart Integration Server for the new value to take effect.
watt.server.ping
Specifies the number of milliseconds that the Pinger thread created for the pub.remote:invoke service waits between sending wm.sever.ping requests. The value of watt.server.ping.interval is used only if the Keep Alive Timeout field for the remote server alias is not specified. The default is 1000 milliseconds.
watt.server.port
Specifies the port number of the Integration Server's primary port. The default is 5555.
watt.server.portAccess.axis2
Specifies whether Integration Server verifies that an Axis2-based web service can be accessed through a port. Set the parameter to true if you want Integration Server to perform the access check on Axis2-based web services. Set this parameter to false to disable the access check for Axis2-based web services. The default is true.
watt.server.portQueue
Specifies the size of the port queue for HTTP and HTTPS ports. The port queue is the number of outstanding inbound connections that are queued in the TCP/IP stack. The default is 65534. If your server runs on AS/400, set this number to 511.
watt.server.ports.ipaccess.ignoreXForwardedForHeader
Specifies whether Integration Server uses or ignores the IP address in the X-Forwarded-For (XFF) header of a request when determining whether to allow or deny access to the port. This parameter applies to requests received on an Enterprise Gateway external port and API Gateway external port only.
When set to true, Integration Server does not use the IP address in the XFF header to determine if the request is from a host allowed to access the port. Instead, Integration Server uses the IP address of the proxy or load balancer.
*If a request is sent through a proxy or a load balancer from a host whose IP address is on the Deny List for the port configured to Allow by Default and the IP address of the proxy/load balancer is not blocked, the host will not be blocked either. Instead, the host will have access to the port.
*If a request is sent through a proxy or a load balancer from a host whose IP address is on the Allow List for a port configured to Deny by Default and the IP address of the proxy/load balancer is blocked, the host will not have access to the port.
When set to false, Integration Server uses the IP address in the XFF header to determine if a request originates from a host allowed to access the port.
*If a request is sent through a proxy or a load balancer from a host whose IP address is on the Deny List for a port configured to Allow by Default, the host will not have access to the port.
*If a request is sent through a proxy or a load balancer from a host whose IP address is on the Allow List for a port configured to Deny by Default, the host will have access to the port.
The default value is true.
watt.server.portStateless
Specifies a comma-separated list of the port numbers for the ports on Integration Server that are stateless. Integration Server does not provide or maintain any sessions or session IDs for requests received on the port.
You can configure any HTTP or HTTPS port on Integration Server to be stateless with the exception of the primary port and the diagnostic port. Additionally, do not configure any ports used for WebSockets or for administering Integration Server to be stateless. If you specify the primary port, diagnostic port, a port that is not an HTTP or HTTPS port, or a port that does not exist in the value for watt.server.portStateless. Integration Server logs an warning message stating that the port cannot be made stateless and that it will be skipped.
There is no default value for this parameter. That is, by default, none of the ports on Integration Server are stateless.
watt.server.pubDateTimeFormat.javaSlidingWindow
Specifies the sliding window to use when the 2-digit pattern yy is used for the year in the pub.date:dateTimeFormat service. When set to true, the pub.date:dateTimeFormat service uses 80 years before and 20 years after around the current date (as described in the Java class java.text.SimpleDateFormat). When set to false, the pub.date:dateTimeFormat service uses a 50 year sliding window around the current year. The default is false.
watt.server.publish.drainCSQInOrder
If client-side queuing is enabled, this parameter specifies whether Integration Server should empty the outbound document store in publication order or in parallel with newly published documents. When this parameter is set to true, Integration Server sends all newly published documents (guaranteed and volatile) to the outbound document store until the outbound store has been emptied. This allows the Integration Server to maintain publication order. When this parameter is set to false, the outbound store is emptied while new documents are being published to the Broker. The default is true.
Note:
This server configuration parameter applies to documents published to Broker only.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.publish.local.rejectOOS
Specifies whether Integration Server should reject locally published documents when the queue for the subscribing trigger is at maximum capacity.
When this parameter is set to true, before placing a locally published document into a subscribing trigger's queue, Integration Server first checks the trigger's queue size. If the queue already contains the maximum number of documents allowed by the trigger's Capacity property, Integration Server rejects the locally published document for that trigger queue only.
When this parameter is set to false, Integration Server continues to place locally published documents into a subscribing trigger's queue even when the queue is at capacity. This is the default.
Note:
Multiple triggers can subscribe to the same document. Integration Server places the document in any subscribing trigger queue that is not at capacity.
Note:
This parameter applies only to documents published locally using the pub.publish:publish or pub.publish.publishAndWait services.
watt.server.publish.maxCSQRedeliveryCount
Specifies the maximum redelivery attempts Integration Server makes when publishing a message from the client side queue (CSQ) to the Broker. When Integration Server publishes messages and the Broker is not available, Integration Server writes guaranteed messages to the CSQ if one is configured for use with the Broker (watt.server.publish.useCSQ = always). When the Broker becomes available,Integration Server drains the CSQ by publishing message from the CSQ to the Broker. If the initial attempt to publish the message to Broker from the CSQ fails, Integration Server makes subsequent attempts until the message is published successfully or Integration Server makes the maximum redelivery attempts specified in watt.server.publish.maxCSQRedeliveryCount. Each attempt to publish to Broker from the CSQ is considered a redelivery attempt. The watt.server.publish.maxCSQRedeliveryCount parameter must be set to a positive integer. The default value is 5.
Note:
This parameter applies to webMethods messaging where Broker is the messaging provider. The comparable parameter for webMethods messaging where Universal Messaging is the messaging provider is watt.server.messaging.csq.maxRedeliveryCount. The comparable parameter for JMS messaging, regardless of provider, is watt.server.jms.csq.maxRedeliveryCount.
Note:
This parameter is deprecated because Broker is deprecated.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.publish.useCSQ
Specifies whether Integration Server uses outbound client-side queuing if documents are published when the Broker is unavailable. Set this parameter to always to send published documents to the outbound document store when the Broker is not available. Set this parameter to never to instruct the publishing service to throw a ServiceException when the Broker is not available. The default is always.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.publish.usePipelineBrokerEvent
Specifies whether Integration Server should bypass encoding that is normally performed when documents are published to the Broker. If this property is set to true, Integration Server checks the pipeline for an object called $brokerEvent. If the object is found and is of type BrokerEvent, Integration Server sends its value to the Broker and no additional encoding is performed. Set this parameter to true if Integration Server is sending native Broker events. The default is false.
For more information about publishing native Broker events, see the Publish-Subscribe Developer’s Guide.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.publish.validateOnIS
Specifies whether Integration Server validates published documents. Set this parameter to one of the following values:
Specify
To
always
Perform document validation for all published documents. This includes instances of publishable document types for which the Validate when published property is set false.
never
Disable document validation for all publishable document types. This includes instances of publishable document types for which the Validate when published property is set true.
Some reasons for disabling document validation include the following:
*You want to improve performance.
*You want to validate the documents manually.
*You know that the system that sent Integration Server the data has already validated the data.
*You prefer to have the messaging provider, rather than Integration Server, validate the documents.
*Integration Server is sending or receiving native Broker events.
perDoc
Perform document validation only for instances of publishable document types for which document validation is enabled. That is, Integration Server validates published documents that are instances of publishable document types for which the Validate when published property is set true.
This is the default behavior.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
For information about handling native Broker events and specifying validation for an individual publishable document type, see the Publish-Subscribe Developer’s Guide.
watt.server.recordTodocument.bufferSize
Specifies the size of the buffer that Integration Server uses to write an XML string when converting a document (IData) to an XML string. Increase the buffer size if the majority of the created XML strings will be greater than 4 KB. Decrease the buffer size if the majority of the created XML strings will be small documents less than 4 KB in size. The default size is 4 KB.
watt.server.remoteInvoke.queryCSRFToken
Indicates if, during a remote service invocation, Integration Server queries the remote server for the CSRF token for the current session and then includes the token in the service request. If an Integration Server uses Cross-Site Request Forgery (CSRF) guard, requests sent to the server must include a CSRF token. If the request does not include a CSRF token, the server rejects the request. When an Integration Server performs a remote invoke to execute a service on another Integration Server that uses CSRF guard, the request needs to include the CSRF token. To ensure that the request includes a CSRF token, the requesting Integration Server obtains the CSRF token for the current session from the remote Integration Server. The requesting Integration Server then modifies the request to include the CSRF token. However, this is only necessary if the remote Integration Server uses CSRF guard. Set the watt.server.remoteInvoke.queryCSRFToken to true if remote Integration Servers use CSRF guard and you want the requesting Integration Server to query for the current CSRF token and include that token in the request. Set to false if the remote Integration Servers does not use CSRF guard. The default is true.
watt.server.removeDefaultMWSRolesInISACL
Specifies whether Integration Server removes the default MWS roles (My webMethods Administrators and My webMethods Users) from an ACL. If the property is set to true, Integration Server removes the default MWS roles from the ACL. If the property is set to false, Integration Server retains the default MWS roles in the ACL. The default value is false.
Important:
If you change the value of the property, restart Integration Server for the change to take effect.
watt.server.requestCerts
Specifies whether the Integration Server requests a digital certificate from clients that connect to it through SSL. Set this parameter to true if you want the server to request certificates. Set it to false if you do not want the server to request certificates. The default is false.
watt.server.requireV3Manifest
Specifies whether Integration Server limits the inactive package list to those packages with a manifest.v3 file. When set to true, Integration Server builds the list of inactive packages using those packages with a manifest.v3 file. If the package with the manifest.v3 file is not known to Integration Server or is not presently quiesced, Integration Server considers the package to be inactive. When set to false, Integration Server does not use the existence of the manifest.v3 file when determining if the package is inactive. Instead, Integration Server checks all packages in the Integration Server_directory /instances/instanceName/packages directory to see if they are known or quiesced and, therefore, are inactive. The default value is true.
watt.server.response.displayISErrorCode
Indicates whether the HTTP response from Integration Server to a client application in the case of an error situation includes the Integration Server error code in the header and the body of the response.
If you set the value of this parameter to false, the HTTP response during error situations includes the error message text without the Integration Server error code in both the header and the body of the response. If you set the value to true, the HTTP response during error situations includes the Integration Server error code and the corresponding error message text in the header and body of the response. The default value of the parameter is true.
watt.server.rest.addHTTPMethodToInputPipeline
Indicates whether Integration Server adds the $httpMethod variable in the input pipeline with the requested HTTP method while processing REST requests. If this property is set to true, Integration Server adds the $httpMethod input variable in the input pipeline. If this property is set to false, Integration Server does not add the $httpMethod input variable in the input pipeline. The default value is false.
watt.server.rest.removeInputVariablesFromResponse
Indicates whether Integration Server removes the input variables of a service signature from the pipeline while sending a REST API response. When this property is set to true, Integration Server retains only the output variables in the REST API response that matches the response structure as defined in the Swagger document. When this property is set to false, Integration Server retains the input variables while sending a REST API response. The default is true.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.RESTDirective
Specifies an alternative word to use for the rest directive in URLs that access resources on Integration Server. By default, this parameter is set as watt.server.RESTDirective=rest, which means users must specify the rest directive as rest (for example, GET http://host:port/rest/resource/resourceID). To allow users to specify the rest directive as either rest or an alternative word, set this parameter to the alternative word. For example, to allow users to specify the rest directive as either rest or process, (GET http://host:port/rest/resource/resourceID) or GET http://host:port/process/resource/resourceID), set this parameter as watt.server.RESTDirective=process.
Important: 
*If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
*When you restart Integration Server after changing the setting of this parameter, all the URL aliases that point to URL paths containing the previous setting of the parameter and created using the Integration Server Administrator will not work. Therefore, you must edit the URL path for each of the impacted URL aliases from the Integration Server Administrator to include the updated setting of the parameter. This restriction does not apply to the URL aliases created using Software AG Designer.
watt.server.RESTDirective.V2
Specifies an alternative word to use for the restv2 directive in URLs that access resources on Integration Server. By default, this parameter is set as watt.server.RESTDirective.V2=restv2, which means users must specify the rest directive as restv2 (for example, GET http://host:port/restv2/resource/resourceID). To allow users to specify the rest directive as either restv2 or an alternative word, set this parameter to the alternative word. For example, to allow users to specify the directive as either restv2 or process, (GET http://host:port/restv2/resource/resourceID) or GET http://host:port/process/resource/resourceID), set this parameter as watt.server.RESTDirective.V2=process.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.revInvoke.proxyMapUserCerts
For webMethods Enterprise Gateway only. Specifies whether an Enterprise Gateway Server is to perform client authentication itself in addition to passing authentication information to the Internal Server for processing. The default is false. If this property is set to true, Enterprise Gateway Server will reject all anonymous requests (no certificate and no username/password supplied), even if the request is for an unprotected service on the Internal Server. See Configuring webMethods Enterprise Gateway for more information.
watt.server.rg.internalregistration.timeout
For webMethods Enterprise Gateway configuration only. Set this value on the Internal Server to specify the time (in seconds) the Internal Server will wait before closing an unresponsive connection to the Enterprise Gateway Server. The default is 0, which means the Internal Server will not time out (a timeout period of infinity).
Important:
Set the value of watt.server.rg.internalregistration.timeout on the Internal Server to a value greater than the ping values defined by the watt.net.socketpool.sweeperInterval server configuration parameter on the Enterprise Gateway Server. Setting watt.server.rg.internalregistration.timeout to a value that is lower than watt.net.socketpool.sweeperInterval will cause the Internal Server to close the connection to the Enterprise Gateway Server and re-establish a new connection regularly.
watt.server.rg.internalsocket.timeout
Specifies the length of time, in milliseconds, that Enterprise Gateway Server allows a client request to wait for a connection to the Internal Server before terminating the request with an HTTP 500 Internal Server Error. If a connection to the Internal Server becomes available within the specified timeout period, Enterprise Gateway Server forwards the request to the Internal Server. If a connection does not become available before the timeout elapses, Enterprise Gateway Server returns a HTTP 500-Internal Server Error to the requesting client and writes the following message to the error log:
"Enterprise Gateway port {port_number} is unable to forward the request to Internal Server because there are no Internal Server connections available."
The default value of this parameter is 0 which means that the client request waits indefinitely for a connection to the Internal Server.
watt.server.scheduler.deleteCompletedTasks
Specifies whether or not scheduled tasks that have expired should be automatically deleted. When set to true, Integration Server deletes expired tasks when they expire. Set this parameter to false if you want Integration Server to wait until the next server restart to delete expired tasks. The default is true.
watt.server.scheduler.ignoreReferenceValidationErrors
Specifies whether Integration Server creates or executes a scheduled task if the scheduled service has a broken reference. Set the property to true to indicate that Integration Server ignores broken references for the scheduled service when executing a scheduled task. Set it to false to indicate that Integration Server should not execute a scheduled task if the scheduled service has one or more broken references. The default is false.
watt.server.scheduler.logical.hostname
Specifies a unique logical name to identify Integration Server instances in a cluster hosted on a single machine. By default, Integration Server uses the host name to identify itself while scheduling tasks. However, when a cluster of Integration Servers are hosted on a single machine, the host name itself cannot uniquely identify the individual Integration Server instances. In such cases, use the watt.server.scheduler.logical.hostname property to specify a unique logical name to identify individual Integration Server instances.
The default value for this parameter is the host name.
Keep the following points in mind when setting the watt.server.scheduler.logical.hostname property:
*Set this property only if you are running multiple Integration Servers in a cluster on a single machine.
*Set this property on each Integration Server instance in the cluster before scheduling any tasks.
*The logical host name you specify must be unique.
*The logical host name you specify cannot contain a semicolon (;).
This property is also useful when Integration Server is installed on a virtual server whose host name or IP address might change over time. You can use watt.server.scheduler.logical.hostname to provide a fixed value that identifies each server in a cluster.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.scheduler.maxWait
Maximum time in seconds Integration Server waits between queries of the task queue. The server periodically checks the queue for tasks that are scheduled to run. If there are no tasks waiting to run, the server waits the maxWait time before checking the queue again. If there are tasks waiting to run, the server checks again at the task's schedule execution time, or after the maxWait time, whichever is earlier. For example, if the pending task is due to execute in 30 seconds and the maxWait time is 60, the server will check the queue again in 30 seconds. The default is 60.
Note:
You must ensure that the value you specify for this parameter must be less than the minimum time interval set for a scheduled task.
If you run a cluster of Integration Servers and schedule a task to run on all servers in the cluster, you might notice tasks starting at different times on the different servers if the servers have different settings for this property. For this reason, if you are running in a clustered environment, all the servers in your cluster should have the same settings for this property. See the webMethods Integration Server Clustering Guide for more information about configuring Integration Servers in a cluster.
watt.server.scheduler.threadThrottle
Percentage of Integration Server threads the scheduler process is permitted to use. The default is 75%.
watt.server.securePort
Specifies the port number of the default secure (HTTPS) port on Integration Server. During installation, Integration Server automatically creates the diagnostic port at 5543. However you can specify a different value during installation. The default is 5543.
Important:
You must restart Integration Server for changes to this parameter to take effect. To change the default secure port without restarting Integration Server, edit the default secure port on the Server > Ports page. For more information about editing a port, see Editing a Port.
watt.server.security.createDefaultServicesOnPorts
Specifies whether Integration Server adds a default list of internal and built-in services to the allow list of a port configured to deny access. Some of the internal services have an Execute ACL set to anonymous which might be a security vulnerability in some environments. Set to true to include the predefined list of internal and built-in services in the allow list. Set to false to not add internal or built-in services to the allow list. The default is true.
watt.server.securityLog.eg.enableExternalClientIP
Specifies whether the IP address of the external client that invokes a service in Integration Server through Enterprise Gateway is recorded in the security log or not. When set to true, Integration Server records the IP address of the external client in the security log. When set to false, Integration Server records the IP address of Enterprise Gateway in the security log. The default value is false.
watt.server.securityLog.ignoreXForwardedForHeader
Specifies whether Integration Server ignores the X-Forwarded-For request header and uses the IP address of the proxy server as the client ID in the security log. When set to false, Integration Server obtains the originating client IP address from the X-Forwarded-For request header and uses that client IP address in the security log and security log message. When watt.server.securityLog.ignoreXForwardedForHeader is set to true, Integration Server ignores the X-Forwarded-For request header and uses the IP address of the proxy server as the client ID. Note that it is more beneficial for the security log entry to include the IP address of the client that originated the request, especially if the request is an anonymous one. The default is false.
watt.server.securityLog.logAnonymousRequests
Controls whether or not anonymous authentication requests are written to the security log. When watt.server.securityLog.logAnonymousRequests is set to true, the security logger will write anonymous authentication requests to the security log. In a log entry, the User Id for an anonymous request will be "local/default". The default value is false, which indicates that the security logger does not include anonymous authentication requests.
watt.server.serverlogFilesToKeep
Specifies the number of server log files that Integration Server keeps on the file system, including the current server log file. When Integration Server reaches the limit for the number of server log files, Integration Server deletes the oldest archived server log file each time Integration Server rotates the server log. If you set watt.server.log.filesToKeep to 1, Integration Server keeps the current server.log file and no previous server.log files. When Integration Server rotates the server.log, Integration Server does not create an archive file for the previous server log. If you set watt.server.log.filesToKeep to 0, or any value less than 1, Integration Server keeps an unlimited number of server log files.
The default value of watt.server.log.filesToKeep is -1, indicating that there is no limit to the number of server log files that Integration Server maintains.
For more information about setting the maximum number of server log files that Integration Server keeps, see Setting Up the Server Log.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.serverlogMaskBearerToken
Specifies whether Integration Server masks the value of a bearer token when writing to the server log. When the server log facility "0038 HTTP Header" is set to Trace and Integration Server receives a request that includes a bearer token, Integration Server writes the Authorization request header to the server log. If watt.server.serverlogMaskBearerToken is true, Integration Server writes a string of asterisks to the log rather than the actual bearer token value. If watt.server.serverlogMaskBearerToken is false, the bearer token value is written to the log. The default is true.
watt.server.serverlogRotateSize
Specifies the file size at which Integration Server rolls over the server.log file. Set this property to N[KB|MB|GB], where N is any valid integer. The minimum size at which Integration Server rotates the server.log file is 33KB. If you use KB as the unit of measure, you must set N to a value greater than or equal to 33. If you do not specify a unit of measure, Integration Server treats the supplied N value as bytes. In this case, N must be greater than or equal to 32768 to take effect. Do not include any spaces between the integer and the unit of measure.
There is no default value for this parameter. That is, by default, the parameter has no value. If no value is specified for watt.server.serverlogRotateSize, Integration Server rotates the server.log file at midnight only.
If an invalid value is specified, Integration Server resets the parameter to -1. Note that a value of -1 results in the same behavior as specifying no value for the parameter.
For more information about the server.log, see Setting Up the Server Log.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.serverlogQueueSize
Controls the number of entries allowed in the server log queue. This property is related to the watt.server.log.queued property, which controls whether the server is to write entries directly to the server log, or queue them in memory first and then use a background thread to write them to the server log. If your configuration has the watt.server.log.queued property set to true and you notice that expected server log entries are not included in the log, try increasing the queue size. For more information about the server log and the server log queue, see Specifying Whether to Queue Server Log Entries. The default queue size is 8192.
watt.server.serverclassloadername
This is an internal property. Do not modify.
watt.server.service.blacklist
Specifies, using a comma-separated list or a file, the services on the service blacklist and/or the interfaces whose services are on the service blacklist. Attempts to invoke blacklisted services or services in a blacklisted interface result in an Access Denied error. Any service can be blacklisted, including services delivered with Integration Server such as those in WmPublic and WmRoot. Make sure that a service critical to the functioning of Integration Server is not blacklisted. There is no default value for this server configuration parameter.
Integration Server does not support the use of wildcards with this parameter.
For more information about a service blacklist, see Adding Services to a Blacklist.
Important:
If you change the setting of this parameter or the contents of the file used for the service blacklist, you must restart Integration Server for the changes to take effect.
watt.server.service.lazyEval
Controls whether Integration Server initializes Java services during startup. When set to true (the default), Integration Server does not initialize Java Services until they are referenced during runtime. This can increase performance if the server initializes a lot of Java Services at start up.
watt.server.service.list.treatEmptyAsNull
Specifies whether Integration Server assigns a null value to all list data types like Document List, String List, Document Reference List, and Object list during the execution of a flow service without an input value. True indicates that the output of the service assigns a null value for the list data type. False indicates the output of the service would not assign a null value. The default is true.
watt.server.serviceMail
Specifies the email address to which Integration Server sends messages about service failures. There is no default.
When you specify an email address on this parameter, Integration Server creates a simple scheduled task to perform the notification. This task requires a thread, which Integration Server takes from the cronjob-based thread pool. See the watt.server.cron.maxThreads and watt.server.cron.minThreads parameters for more information about this thread pool.
watt.server.serviceMonitor.queryOnServerId
Specifies monitoring capabilities for the entire stateful cluster and not just for a single instance of the cluster. When set to true, then the query includes server ID, and only that server's data are available for monitoring. When set to false, the query excludes the server ID, and the entire cluster remains a single entity. The new parameter must be set to the same value on every member of the cluster, and there is no default value for this parameter.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.serviceResults.cache
Specifies the name of the public cache to use for service results caching. If no value is specified for the watt.server.serviceResults.cache parameter, Integration Server uses the ServiceResults cache in the cache manager specified in the watt.server.serviceResults.cacheManager parameter as the service results cache. If the cache manager in the watt.server.serviceResults.cacheManager parameter does not contain a cache named ServiceResults, Integration Server throws an error at start up and does not cache service results.
Note:
To use the ServiceResults system cache located in the SoftwareAG.IS.Services system cache manager as the service results cache, do not specify a value for watt.server.serviceResults.cache or watt.server.serviceResults.cacheManager.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.serviceResults.cacheManager
Specifies the name of the public cache manager that contains the public cache to use for service results caching. If no value is specified for this parameter, Integration Server uses the SoftwareAG.IS.Services system cache manager as the service results cache manager. If the SoftwareAG.IS.Services system cache does not contain a cache with a name that matches the value of the watt.server.serviceResults cache, Integration Server throws an error at startup and does not cache service results.
Note:
To use the ServiceResults system cache located in the SoftwareAG.IS.Services system cache manager as the service results cache, do not specify a value for watt.server.serviceResults.cache or watt.server.serviceResults.cacheManager.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.serviceResults.copyOnRead
Specifies how the cache should copy elements that it returns. The default value true returns the results by value, while the value false returns results by reference.
watt.server.serviceResults.copyOnWrite
Specifies how the cache should copy elements that it writes. The default value true returns the results by value, while the value false returns results by reference.
watt.server.serviceUsageDSP.RefreshInterval
Specifies the interval, measured in seconds, that elapses before Integration Server Administrator refreshes the data on the Server > Statistics page. The default is 90 seconds. The change to the parameter takes effect the next time the Server > Statistics page is reloaded.
watt.server.session.locale.ignore
Specifies whether the default locale for the pub.date* or pub.datetime* services is the server locale or the locale from the session used by the client that invoked the service. When set to true, when executing a pub.date* service for which a locale input parameter value is not specified, Integration Server uses the server locale as the value of the locale parameter. When set to false, when executing a pub.date* service or a pub.datetime* service for which a locale input parameter value is not specified, Integration Server uses the locale from the session used by the client that invoked the service. The default is false.
watt.server.session.stateful.enableLimit
Controls whether the stateful session limit feature is enabled. When this property is set to true, Integration Server allows stateful sessions to be created as needed until it reaches the maximum allowed, which is specified by the watt.server.session.stateful.max property. You can view statistics for stateful sessions on the Server > Statistics page in Integration Server Administrator.
watt.server.session.stateful.max
Specifies the number of concurrent stateful sessions allowed on the Integration Server. If a user attempts to access the server and execute a stateful service while the maximum number of stateful sessions are in use, the server rejects the request and returns an error to the user.
The value for watt.server.session.stateful.max must be a positive integer. If a value is not specified or the watt.server.session.stateful.enableLimit property is set to false, the maximum number of concurrent sessions is defined by your Integration Server license.
Note:
It is recommended that you use the Maximum Stateful Sessions field in the Edit Resource Settings page of the Integration Server Administrator to set the maximum value. For more information about setting a maximum limit for stateful sessions, see Managing Server Sessions.
watt.server.session.stateful.warning
Specifies the threshold at which Integration Server starts to warn of insufficient available stateful sessions. When the percentage of available stateful sessions is equal to or less than the value of this property, Integration Server generates a server log message stating:
The default is 25%.
Note:
It is recommended that you use the Enable Stateful Session Limit field in the Edit Resource Settings page of the Integration Server Administrator to set the threshold value. For more information about setting an available stateful sessions warning threshold, see Managing Server Sessions.
watt.server.session.sweeperInterval
Specifies the interval, measured in milliseconds, between execution or the session sweeper task. The parameter applies to all inbound and outbound sessions. The default is 120,000 ms (2 minutes).
Note:
If the watt.server.clientTimeout value is less than the watt.server.session.sweeperInterval, Integration Server uses the watt.server.clientTimeout value as the interval for the session sweeper scheduled task. That is, when scheduling the sessions sweeper system task, Integration Server uses the shorter of the time values set for watt.server.session.sweeperInterval or watt.server.clientTimeout. Keep in mind that watt.sever.clientTimeout value uses minutes as the unit of measure and watt.server.session.sweeperInterval uses milliseconds.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.setResponse.pre82Mode
Specifies the order in which the pub.flow:setResponse service looks for and uses the deprecated input parameters when neither of the input parameters responseString or responseBytes are provided.
When set to true, the pub.flow:setResponse service follows a precedence order similar to what was available in Integration Server 7.1x and 8.0x. Specifically, the service looks for the deprecated parameters in the following order and uses the value of the first parameter that it finds: response, string, bytes
When set to false, the pub.flow:setResponseservice follows a precedence order similar to what was available in Integration Server 8.2 and later. Specifically, the service looks for the deprecated parameters in the following order and uses the value of the first parameter that it finds: string, bytes, response
The default is false.
Note:
This parameter is deprecated because the web services implementation introduced in Integration Server 7.1 is deprecated as of Integration Server 10.4. The web services implementation introduced in Integration Server version 7.1 handles web service descriptors that run in pre-8.2 compatibility mode.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.sftp.dateStampFmt
Specifies the format of date to be used in the SFTP client public services, specifically the pub.client.sftp* services in the WmPublic package. To specify the date format to use, you can use any format that is supported by the Java class java.text.SimpleDateFormat. For example, to display the date with the format 08-12-02 14:44:33:1235, specify dd-MM-yy HH:mm:ss:SSSS. The default format for watt.server.sftp.dateStampFmt property is yyyy-MM-dd HH:mm:ss z.
watt.server.smtpServer
Specifies the SMTP server to use for server error logging and service error email notification. There is no default.
watt.server.smtpServerPort
Specifies the number of the listening port on the SMTP server to which the Integration Server is to send server error logging and service error email notification. The default is 25.
watt.server.smtp.userName
Specifies the username of the account that Integration Server uses to connect to the SMTP server.
watt.server.smtpTransportSecurity
Specifies the type of SSL encryption that Integration Server uses when communicating with an SMTP server.
Set this property to any one of the following values:
When set to
Integration Server
None
Uses a non-secure mode when communicating with an SMTP server.
When you specify None, the SMTP server authenticates the SMTP client using only the username and password.
Explicit
Uses explicit security when communicating with an SMTP server. With explicit security, Integration Server establishes an un-encrypted connection to the SMTP server and then upgrades to the secure mode.
Implicit
Uses implicit security when communicating with an SMTP server. With implicit security, Integration Server always establishes an encrypted connection to the SMTP server. Only clients that support SSL will be permitted access.
watt.server.smtpTrustStoreAlias
Specifies the alias for the truststore that contains the list of certificates that Integration Server uses to validate the trust relationship between Integration Server and the SMTP server. If you do not specify a truststore alias, the default truststore alias specified in the watt.security.trustStoreAlias property will be used. For more information about truststore alias, see Keystore, Truststore, and Key Aliases.
watt.server.SOAP.addEmptyHeader
Specifies whether Integration Server should create an empty header entry in the SOAP message created by executing the pub.soap.utils:createSoapData or pub.soap.utils:stringToSoapData services. When this property is set to true, Integration Server creates an empty header in the SOAP message. When this property is set to false, Integration Server does not create a header entry in the SOAP message. The default is true.
The addEmptyHeader parameter in the pub.soap.utils:createSoapData or pub.soap.utils:stringToSoapData services, if set, overrides the watt.server.SOAP.addEmptyHeader setting.
For more information about pub.soap.utils:createSoapData and pub.soap.utils:stringToSoapData services, see webMethods Integration Server Built-In Services Reference.
watt.server.SOAP.completeLoad
Specifies whether the XML node added by pub.utils:addBodyEntry, pub.utils:addHeaderEntry, pub.utils:addTrailer will be completely loaded before adding to the SOAP message. When set to true, Integration Server loads the entire XML node. When set to false, Integration Server does not completely load the XML node before adding it to the service. The default is true.
watt.server.soap.convertPlainTextHTTPResponseIntoSOAPFault
Specifies how Integration Server returns the response from a web service invocation when it is acting as a client and the web service results in a plain text HTTP response. This parameter applies only when the web service connector was created using:
*Integration Server version 8.2 or later, but the web service descriptor’s Pre-8.2 compatibility mode property is true
*A version of Integration Server prior to version 8.2
When the watt.server.soap.convertPlainTextHTTPResponseIntoSOAPFault parameter is set to true (the default), Integration Server converts the plain text HTTP response and returns the information from the HTTP response within web service connector's output parameters.
*If the web service connector was created using Integration Server version 8.2 or later and the Pre-8.2 compatibility mode property is true, Integration Server returns the converted HTTP payload in the web service connector’s fault/reasons output parameter.
*If the web service connector was creating using a version of Integration Server prior to version 8.2, Integration Server returns the converted HTTP payload in one of the following based on the SOAP protocol in use:
*SOAP-FAULT/Fault_1_1/faultstring
*SOAP-FAULT/Fault_1_2/SOAP-ENV:Reason/SOAP-ENV:Text
Having the plain text HTTP response converted and returned in the web service connector’s output parameter can be helpful because it might contain the cause of the exception.
If you set the parameter to false, when the web service results in a plain text HTTP response, Integration Server throws an exception indicating that an invalid SOAP envelope is received.
Note:
This parameter is deprecated because the web services implementation introduced in Integration Server 7.1 is deprecated as of Integration Server 10.4. The web services implementation introduced in Integration Server version 7.1 handles web service descriptors that run in pre-8.2 compatibility mode.
Important:
After updating this parameter, you must restart Integration Server for changes to this parameter to take effect.
watt.server.soap.decodeElementWithPrefix
Specifies whether Integration Server recognizes document types that have defined XML namespace URIs but do not have prefixes associated with each namespace. By default, in Integration Server version 8.2 SP2 and higher, if document types that have a defined XML namespace URI but do not have a prefix associated with each namespace are specified as inputs to services, the SOAP processor fails to recognize the document types at run time. If the watt.server.soap.decodeElementWithPrefix property is set to true, Integration Server recognizes the document types that have defined XML namespaces but do not have prefixes associated with each namespace.
The default is false.
The watt.server.soap.decodeElementWithPrefix server configuration parameter value affects how Integration Server decodes inbound SOAP messages for web service descriptors created on Integration Server version 7.1.x. Specifically, the parameter affects how Integration Server decodes SOAP response messages received by a 7.1.x web service connector and SOAP request messages received by a 7.1.x web service provider.
*When watt.server.soap.decodeElementWithPrefix is set to true, when decoding an inbound SOAP message, Integration Server does not consider namespace and/or prefix declarations when decoding the SOAP message to IData for any web service or web service connector that is part of a web service descriptor created in 7.1.x. Integration Server will map namespace qualified elements in the XML string to fields in an IS document type even if the field names do not include a prefix. That is, when the parameter is set to true Integration Server uses the decoding behavior available in version 7.1.x. for any web service or web service connector that is part of a web service descriptor created in Integration Server 7.1.x.
Note:
The Integration Server 7.1.x decoding behavior described above is invalid. However, the stricter decoding process in Integration Server 8.2 and later can result in missing or extraneous fields which, in turn, results in validation errors. Setting the watt.server.soap.decodeElementWithPrefix to true allows the 7.1.x behavior and does not require changes to the 7.1.x web service descriptors.
*When watt.server.soap.decodeElementWithPrefix is set to false, when decoding an inbound SOAP message, Integration Server considers namespace and/or prefix declarations when decoding a SOAP message to IData for any web service or web service connector that is part of a web service descriptor created in Integration Server 7.1.x. Integration Server does not map namespace qualified elements in the XML string to fields in an IS document type if the field names do not include a prefix. That is, when the parameter is set to false, Integration Server uses the decoding behavior available in version 8.2 SP2 and later for any web service or web service connector that is part of a web service descriptor created in Integration Server 7.1.x and later.
Note:
For web service descriptors created in Integration Server 8.2 SP2 onwards, you must associate a prefix with an XML namespace URI for fields in the service signature.
The watt.server.soap.decodeElementWithPrefix server configuration parameter also determines whether or not the pub.xml.xmlNodeToDocument service considers namespace and/or prefix declarations when decoding namespace qualified elements to corresponding fields in an IS document type.
*When watt.server.soap.decodeElementWithPrefix is set to true, the pub.xml:xmlNodeToDocumentservice does not consider namespace and/or prefix declarations. The service will map namespace qualified elements in the XML string to fields in an IS document type even if the field names do not include a prefix. Note that this behavior is considered invalid but is allowed to provide backward compatibility with services developed on earlier versions of Integration Server.
*When watt.server.soap.decodeElementWithPrefix is set to false, the pub.xml:xmlNodeToDocument service considers namespace and/or prefix declarations. The service does not map namespace qualified elements in the XML input to fields in an IS document type if the field names do not include a prefix. The pub.xml:xmlNodeToDocument service does not populate non-prefixed fields. Instead the service adds new fields that use the prefix:name structure and populates those fields with values from the XML instance.
Important:
After updating the watt.server.soap.decodeElementWithPrefix parameter, you must restart Integration Server for changes to the parameter to take effect.
watt.server.SOAP.default.endpointHTTP
Specifies the default provider web service endpoint alias for the HTTP protocol. If the value of this parameter is empty, there is no default provider web service endpoint alias for HTTP.
There is no default value for this parameter.
The watt.server.SOAP.default.endpointHTTP parameter displays the value specified in the HTTP parameter on the Settings > Web services > Set default provider endpoint aliases page in Integration Server Administrator. For more information about setting a default provider endpoint alias, see Setting a Default Endpoint Alias for Provider Web Service Descriptors.
watt.server.SOAP.default.endpointHTTPS
Specifies the default provider web service endpoint alias for the HTTPS protocol. If the value of this parameter is empty, there is no default provider web service endpoint alias for HTTPS.
There is no default value for this parameter.
The watt.server.SOAP.default.endpointHTTPS parameter displays the value specified in the HTTPS parameter on the Settings > Web services > Set default provider endpoint aliases page in Integration Server Administrator. For more information about setting a default provider endpoint alias, see Setting a Default Endpoint Alias for Provider Web Service Descriptors.
watt.server.SOAP.defaultProtocol
Specifies the default protocol that Integration Server uses for new SOAP messages. Specify SOAP 1.1 Protocol or SOAP 1.2 Protocol. The default is SOAP 1.1 Protocol.
watt.server.SOAP.directive
Specifies a different word to use for the SOAP directive in URLs that route requests to the Integration Server SOAP handler. By default, this parameter is set as watt.server.SOAP.directory=soap, which means users must specify the SOAP directive as soap (http://host:port/soap). To allow users to specify the SOAP directive as a different word instead, set this parameter to that word. For example, to allow users to specify the SOAP directive as endpoint, (http://host:port/endpoint), set this parameter as watt.server.SOAP.directive=endpoint.
watt.server.SOAP.encodeXSIType
Indicates where the xsi:type will appear as an attribute for an element in a SOAP message that specifies RPC/Encoded. A value of true indicates that Integration Server includes the xsi:type attribute for an element. False indicates that the xsi:type attribute will be omitted. The default is true. Software AG recommends using a value of true for this parameter.
watt.server.SOAP.encodeXSITypeValue
Indicates whether Integration Server should include the xsi:type attribute and its value for an element of xsd:anyType in SOAP requests and responses. When set to false, Integration Server omits the xsi:type attribute and its value for an element of xsd:anyType in SOAP requests and responses. When set to true, Integration Server includes the xsi:type attribute and its value for an element of xsd:anyType in SOAP requests and responses. The default is true.
Note:
The watt.server.SOAP.encodeXSITypeValue server configuration parameter affects only those SOAP requests and responses created by Integration Server.
watt.server.SOAP.generateNilTags
Specifies whether or not Integration Server generates an xsi:nil attribute for an element in a SOAP message. When set to true, Integration Server generates an xsi:nil attribute for an element that is nillable (the Allow null property for the corresponding field is set to true) and the field is null at run time. When watt.server.SOAP.generateNilTags is set to false, Integration Server omits the xsi:nil attribute for an element even if the corresponding field is nillable and the field is null at run time. The default is true.
watt.server.SOAP.generateRequiredTags
Specifies whether or not a SOAP message generated by Integration Server includes empty element tags for required parameters for which a value was not supplied at run time. When set to true, Integration Server generates empty element tags for required parameters for which a value is not specified. When watt.server.SOAP.generateRequiredTags is set to false, Integration Server omits empty element tags for required parameters for which a value is not specified. The default is true.
watt.server.SOAP.hideEPRHostInFault
Hides the endpoint reference host name and IP address details in the SOAP fault. When this parameter is set to true, Integration Server replaces the host name and IP address with *:* in the SOAP fault. When this parameter is set to false, Integration Server includes the host name and IP address details of the endpoint reference in the SOAP fault. The default is false.
Note:
This parameter applies only when the Pre-8.2 compatibility mode property of the web service descriptor is set to false.
watt.server.SOAP.hideFaultReason
This parameter enables you to remove fault details from responses to Web services requests. By default, this parameter is set to false and responses include fault details. If the responses include fault details, client applications may spoof or modify the actual content on a web page. To prevent content spoofing, set this parameter to true.
Important:
You must also set watt.server.http.returnException to false or webMethods to prevent Integration Server from returning the stack trace to clients in case a Web service returns an error.
watt.server.SOAP.identifyIsGeneratedWSDL
When creating or refreshing a web service descriptor from a WSDL document, detects whether the WSDL document was originated by Integration Server. When watt.server.SOAP.identifyISGeneratedWSDL property is set to true, Integration Server detects whether the WSDL document was generated by Integration Server and if so, removes the top-level elements in the input and output message. When set to false, Integration Server processes the WSDL document as written and does not remove the top-level elements in the input and output message when creating the web service descriptor. The default value is true.
This parameter affects WSDL first provider web service descriptors and consumer web service descriptors.
Important:
Changing the value of watt.server.SOAP.identifyISGeneratedWSDL affects the logic for creating and refreshing web service descriptors. If you change the parameter value and then refresh a web service descriptor that was created before the parameter value changed, the refreshed web service descriptor will be different from the original web service descriptor.
watt.server.SOAP.ignoreMissingResponseHeader
Determines whether missing required headers in a SOAP response, including a SOAP fault, results in an error. When set to true, a SOAP response that does not contain a required header will not result in an error. When set to false, a SOAP response that does not contain a required header results in an error. The default is false.
Note that all headers in a web service descriptor, whether generated from the original WSDL document or added to the web service descriptor, are treated as required. This is an application of the WS-I basic profile rules declaring that all headers in a WSDL be treated as required. Prior to Integration Server version 9.0, when processing a SOAP response received by a web service descriptor, Integration Server did not properly validate that all of the SOAP headers were present. As a result, Integration Server did not throw an error when a SOAP response was missing a SOAP header. Beginning in Integration Server version 9.0, Integration Server properly validates SOAP responses for required headers. If a required header is not present, Integration Server throws the following error: “[ISS.0088.9443] One or more required Headers <headerName> are not present in the SOAP response.” While failure when a required header is missing is the correct behavior, Integration Server provides a configuration property to control whether missing required headers in a SOAP response results in an error. This can be useful in migration situations.
watt.server.SOAP.inbound.CDATA.removeTags
Specifies whether Integration Server removes or preserves the CDATA delimiter tags found in an inbound SOAP request. When set to true, during inbound processing, Integration Server removes the initial CDATA tag "<![CDATA[" and the terminating tag "]]>" from the string values passed as input to the target web service. When set to false, Integration Server preserves the CDATA delimiter tags in inbound SOAP requests; the CDATA delimiter tags will remain in the text of the request and reach the target web service. The default value is true.
watt.server.SOAP.MTOMStreaming.cachedFiles.location
Specifies the absolute path to the hard disk drive space that Integration Server uses to temporarily store inbound SOAP messages when performing MTOM streaming. This parameter takes effect only when MTOM streaming is enabled (i.e., watt.server.SOAP.MTOMStreaming.enable is set to true).
You can specify a directory on the same machine as the Integration Server or in any other location accessible to Integration Server, such as a mapped logical drive or network directory. The default value is Integration Server_directory \instances\instance_name\temp\mtom\cached files.
Note:
If your Integration Server is in a clustered environment, you must set this property in all the servers in the cluster. See webMethods Integration Server Clustering Guide for more information about configuring Integration Server in a cluster.
watt.server.SOAP.MTOMStreaming.enable
Indicates whether MTOM streaming is enabled for inbound SOAP messages and whether HTTP chunking is enabled for outbound requests. Set this property to true to enable MTOM streaming for inbound SOAP messages and HTTP chunking for outbound requests. Set this property to false to disable MTOM streaming and HTTP chunking. The default is false.
watt.server.SOAP.MTOMStreaming.threshold
Specifies the maximum number of bytes for Integration Server to handle an inbound MTOM attachment field as an in-memory ByteStream. Integration Server writes an inbound MTOM attachment field exceeding this size to a temporary disk file and processes the inbound MTOM Streams as a FileStream. This parameter takes effect only when MTOM streaming is enabled (watt.server.SOAP.MTOMStreaming.enable is set to true). The default is 4000 bytes.
The watt.server.SOAP.MTOMStreaming.cachedFiles.location value determines the location of the temporary disk files.
watt.server.SOAP.MTOMThreshold
Specifies the field size, in kilobytes, that determines whether Integration Server handles base64binary encoded data in an outbound SOAP request as a MIME attachment or whether it sends it inline in the SOAP message. If the web service descriptor for the SOAP message enables attachments for the SOAP request, Integration Server passes as MIME attachments any base64 fields in a SOAP message that are larger than the threshold. The default is 0.
watt.server.SOAP.pre82WSD.ignoreVersionMismatch
For a web service provider that was created in an Integration Server release earlier than 8.2.2 and for which the Pre-8.2 compatibility mode property is set to true, specifies whether to emulate pre-8.2 behavior for process SOAP requests. In Integration Server 7.1.3, Integration Server allowed web service providers to process SOAP requests with a SOAP version that did not match the SOAP version that was declared in the WSDL binding. When set to true, this property provides backward compatibility so that consumers do not have to update their SOAP requests.
When set to false, Integration Server uses stricter validation that does not allow processing when this mismatch exists. The default value is false.
Note:
This parameter is deprecated because the web services implementation introduced in Integration Server 7.1 is deprecated as of Integration Server 10.4. The web services implementation introduced in Integration Server version 7.1 handles web service descriptors that run in pre-8.2 compatibility mode.
watt.server.SOAP.preserveCDATA
Specifies whether Integration Server encodes CDATA blocks in outbound messages. When set to true, when Integration Server encounters a CDATA in an outbound SOAP message, Integration Server will maintain it in the wire request unchanged and unencoded. When set to false, Integration Server treats the CDATA section as regular text resulting in the html encoding of the CDATA tag and illegal characters in the CDATA section. Note that encoding occurs before Integration Server places the outbound SOAP message on the wire. Outbound SOAP messages that are affected by this setting include SOAP requests sent by web service connectors and SOAP responses sent by web service providers. The default value is true, CDATA is preserved and not encoded.
watt.server.SOAP.request.timeout
Specifies the length of time, in seconds, Integration Server will wait for the SOAP response from the server hosting the remote procedure. If Integration Server does not receive a response in the allotted time, it terminates the request. The default value is -1, which indicates that Integration Server will use the value set for the watt.net.timeout property.
watt.server.SOAP.retainUndeclaredNamespace
Specifies whether Integration Server retains namespaces from an xsd:any element when decoding a SOAP request or SOAP response. Integration Server considers the namespaces from an xsd:any element to be undeclared because the possible elements and corresponding namespaces are not defined in a corresponding document type. When set to true, Integration Server preserves namespace declarations for the xsd:any element. Additionally, the corresponding field for an element that belongs to the namespace includes the prefix in the field name, When set to false, Integration Server does not retain the namespace declarations for an xsd:any element and the name of the field corresponding to an element in the declared namespace names do not include the prefix. The default is true.
When this parameter is set to true, Integration Server preserves namespace declarations by inserting the following field into the document for each namespace declaration in the xsd:any element:
@xmlns:<prefix>
Where <prefix> is the prefix defined in the SOAP message. If no prefix is defined, the variable name will be @xmlns.
Note:
Note that the watt.server.SOAP.retainUndeclaredNamespace value affects decoding of all SOAP messages for web services.
watt.server.SOAP.setNamespaceURIsToRoot
Specifies how Integration Server declares XML namespaces in a SOAP response. When the watt.server.SOAP.setNamespaceURIsToRoot property is set to true, Integration Server declares the namespace and prefix once at the root element of the SOAP response and then uses the prefix for each element in the response. When set to false, Integration Server declares the namespace the way it is defined in the original document, either defining each element explicitly with the full namespace or declaring the namespace and prefix just once at the root element. The default value for this property is false.
watt.server.SOAP.streamHandlers
Specifies the custom SOAP handlers that expect stream inputs. Enter the SOAP handlers as a semi-colon (;) separated list. There is no default.
watt.server.SOAP.treatNilAsNull
Indicates whether or not Integration Server, when decoding a SOAP message, generates an @xsi:nil field for an element for which the xsi:nil attribute is set to true. When set to true, Integration Server treats an element that carries the xsi:nil attribute as a null value and does not create an @xsi:nil attribute for the element. When this parameter is set to false, Integration Server generates an @xsi:nil field for an element that carries the xsi:nil=true attribute. This configuration parameter affects all web services running on Integration Server. The default is true.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.SOAP.useMultiReference
For elements that appear in multiple places in a SOAP message, specifies whether Integration Server serializes each occurrence of the element or serializes it in on only one place and uses the href attribute in the other locations. When set to true, Integration Server serializes one location and uses the href attribute in other locations. This parameter applies to RPC/Encoded web services only. The default is true.
watt.server.SOAP.useStringforAnyTypewithSimpleValue
Specifies how Integration Server decodes an xsd:anyType element with simple content in SOAP responses. When set to false, Integration Server decodes xsd:anyType elements with simple content into an IData with an @xsi:type field to retain the xsi:type value and a *body field to contain the element value. This is the default behavior.
When the watt.server.SOAP.useStringforAnyTypewithSimpleValue server configuration parameter is set to true, Integration Server decodes xsd:anyType elements with simple content into a String type field that contains the element value. The element's xsi:type information will be gone. You do not have to restart Integration Server for the change to take effect.
watt.server.soap.validateInput
Specifies whether or not a validation error occurs when an inbound SOAP request includes fields that are not declared in the service input signature. Set this parameter to true if Integration Server returns a validation error when the body of an inbound SOAP request includes field that are not declared in the service input signature. Set this parameter to false if Integration Server continues with processing an inbound SOAP request even if the SOAP body includes fields that do not exist in the service input signature. The default is true.
watt.server.soap.validateResponse
Enables or disables SOAP response validation. When set to true, Integration Server validates the SOAP response received by a web service connector. When set to false, Integration Server does not validate the received SOAP response. The default is true.
watt.server.SOAP.validateSOAPMessage
When Integration Server acts as the web service provider, indicates whether Integration Server validates inbound SOAP requests and outbound SOAP responses. When set to true, Integration Server validates inbound SOAP requests and outbound SOAP responses against the SOAP schema. Be aware that the validation process checks only that the message envelope is structured correctly. For example, Integration Server checks that the message has at least one body element and there is at most one header element. Integration Server does not validate any of the data carried by the message. The default is true.
If you are operating in a production environment where the validity of the messages submitted to the server is assured, you might set watt.server.SOAP.validateSOAPMessage to false to optimize performance.
watt.server.SOAP.warnOnPartValidation
When creating a web service descriptor from a WSDL document, indicates whether Integration Server should treat message parts that are defined by the type attribute instead of the element attribute as a warning and not an error. Set this parameter to true to indicate that Integration Server should return a warning and allow the web service descriptor to be created. Set this parameter to false to indicate that Integration Server should return an error and not allow the web service descriptor to be created. The default is false.
watt.server.soapJMS.defaultMessageType
Specifies the default message type for web service request messages sent using SOAP over JMS. Set this parameter to "BytesMessage" to send a message whose body contains a stream of uninterrupted bytes. Set this parameter to "TextMessage" to send a message whose body contains a Java string. BytesMessage is considered to be a more efficient way of sending JMS messages. However, you may want to set the parameter to TextMessage for debugging purposes because the resulting messages will be in a human-readable format. Keep in mind that the message type of the request message determines the message type of the response message. The default is BytesMessage.
Important:
You must restart Integration Server for changes to this parameter to take effect.
Note:
The default message type can be overwritten during web service connector execution by setting the jms.messageType property in the transportHeaders input parameter.
Note:
If you set this parameter to TextMessage, Integration Server sends all web service responses as TextMessage. If the request message is a BytesMessage and watt.server.soapJMS.defaultMessageType is set to TextMessage, Integration Server overrides the request message type and sends the response as a TextMessage. This can be useful in debugging situations.
watt.server.soapjms.request.timeout
Specifies the number of seconds that Integration Server waits for a response to a SOAP request sent using SOAP over JMS. This value must be an integer greater than or equal to zero. A value of 0 indicates that Integration Server will wait indefinitely for a response. The default is 10 seconds.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.SoapRPC.checkHeaders
Indicates whether Integration Server should check SOAP headers for SOAP RPC requests. The default is true.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.SoapRPC.distinguishDuplicateElements
Indicates whether Integration Server should differentiate identically named arrays in the SOAP response for a SOAP/RPC web service. When set to true, Integration Server appends a number to the xsi:type value to distinguish between identically named array elements in the SOAP response, for example elementName and elementName1. When set to false, Integration Server does not differentiate identically named arrays in the SOAP response. The default is true.
watt.server.SoapRPC.useSecondaryType
Instructs Integration Server to use a second type definition when creating the SOAP response for a service whose input or output signatures contain identically named variables of different types. When creating a WSDL from a provider web service descriptor that contains a service with identically named fields of different types, Integration Server renames the second instance of the field type in the WSDL. At run time, for RPC-Encoded SOAP binding, Integration Server encodes the types in the SOAP response. When this property is set to true, the SOAP response refers to the renamed type definition. When set to false, the SOAP response refers to the original type definition instead of the renamed one. The default is false. This property is applicable to RPC-Encoded SOAP binding only.
watt.server.ssl.keyStoreAlias
Name of the keystore alias for the Integration Server keystore that contains the information needed to establish an SSL connection with an SSL-enabled external server. There is no default value for this parameter. For more information about storing keystore information for an SSL connection to an external server, see Configuring SSL Information for the Integration Server JVM.
The watt.server.ssl.keyStoreAlias parameter displays the value specified in the JVM Keystore Alias field on the Security > Certificates and Security > Certificates > Edit certificates settings pages of Integration Server Administrator.
Important:
You must restart Integration Server for changes to this parameter to take effect.
Important:
You must also restart Integration Server if you modify the contents of the keystore whose alias is used as the value of the watt.server.ssl.keyStoreAlias parameter. Changes made to the keystore will take effect after the restart.
watt.server.ssl.trustStoreAlias
Name of the truststore alias for the Integration Server truststore that contains the information needed to establish an SSL connection with an SSL-enabled external server. There is no default value for this parameter. For more information about storing truststore information for an SSL connection to an external server, see Configuring SSL Information for the Integration Server JVM.
The watt.server.ssl.trustStoreAlias parameter displays the value specified in the JVM Truststore Alias field on the Security > Certificates and Security > Certificates > Edit certificates settings pages of Integration Server Administrator.
Important:
You must restart Integration Server for changes to this parameter to take effect.
Important:
You must also restart Integration Server if you modify the contents of the truststore whose alias is used as the value of the watt.server.ssl.trustStoreAlais parameter. Changes made to the truststore will take effect after the restart.
watt.server.stats.clearStatsOnLogRotate
Specifies whether Integration Server clears service error metrics and system error metrics when the server log or stats log rotates. The service error count is used by the Current Service Errors field in Requests table on Server > Statistics page and the Prometheus metric sag_is_number_service_errors. The system error count is used by the Prometheus metric sag_is_number_nonservice_errors. Set to true to reset the service error and system error metrics upon rotation of the server log or stats log. Set to false to indicate the service error and system error metrics will not be cleared upon log rotation. The default is false.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.stats.logfile
Specifies the fully qualified path or relative path and file to which you want Integration Server to write the statistics log. The file contains the data that appears on the Server > Statistics page. The specified path must already exist. If you specify a path that does not exist, Integration Server will not start. If the file does not yet exist, Integration Server creates it the first time it writes to the statistics log. The “relative path” is relative to the Integration Server home directory: Integration Server_directory \instances\instance_name
The default is: logs\stats.csv
Make sure the file type set for the statistics log file type in watt.server.stats.logfle aligns with the value of the watt.server.stats.logfile.csv server configuration parameter. For example, if watt.server.stats.logfile.csv is set to true, the statistics log file extension must be .csv. If watt.server.stats.logfile.csv is set to false, the statistics log is in hexadecimal format and the statistics log file extension must be .log.
At startup, if watt.server.stats.logfile.csv is set to true but watt.server.stats.logfile is set to logs/stats.log, Integration Server changes the value of watt.server.stats.logfile to logs/stats.csv. Similarly, if watt.server.stats.logfile.csv is set to false but watt.server.stats.logfile is set to logs/stats.csv, Integration Server change the value of watt.server.stats.logfile to logs/stats.log.
watt.server.stats.logfile.csv
Specifies the format of the statistics log. When set to true, Integration Server writes the statistics log to a comma-separated values file named stats.csv. When set to false, Integration Server write the statistics log to a hexadecimal formatted file named statistics.log. The default is true.
If you change the watt.server.stats.logfile.csv to false, make sure to change the watt.server.stats.logfile value to be a *.log file.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.stats.logFilesToKeep
Specifies the number of statistics logs files that Integration Server keeps on the file system, including the current log file. When Integration Server reaches the limit for the number of statistics log files, each time Integration Server rotates the statistics log, Integration Server deletes the oldest archived statistics log file. If you set watt.server.stats.logFilesToKeep to 1, Integration Server keeps the current statistics log file and no previous statistics logs. That is, when Integration Server rotates the statistics log, Integration Server does not create an archive file for the previous statistics log. If you set watt.server.stats.logFilesToKeep to 0, or any value less than 1, Integration Server keeps an unlimited number of statistics log files. The default value of watt.server.stats.log.filesToKeep is 0.
If you reduce the number of statistics log files that Integration Server keeps and then restart Integration Server, the existing logs will not be pruned until Integration Server rotates the statistics log.
Integration Server uses the following naming format for the archived statistics logs: statsyyyymmdd_hhmmss.csv (or statsyyyymmdd_hhmmss.log if the statistics log format is hexadecimal) where the timestamp indicates the time at which Integration Server archived the log file.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.stats.logRotateSize
Specifies the file size at which Integration Server rolls over the statistics log. Set this property to N[KB|MB|GB], where N is any valid integer. The minimum size at which Integration Server rotates a statistics log is 33KB. If you use KB as the unit of measure, you must set N to a value greater than or equal to 33. If you do not specify a unit of measure, Integration Server treats the supplied N value as bytes. In this case, N must be greater than or equal to 32768 to take effect. Do not include any spaces between the integer and the unit of measure. If an invalid value is specified, Integration Server proceeds as if no value was specified for the parameter. If you set the value using the Extended Settings page in Integration Server Administrator, validation prevents an invalid value from being saved.
There is no default value for this parameter. That is, by default, the parameter has no value. If no value is specified for watt.server.stats.logRotateSize, Integration Server rotates the statistics log at the interval specified by watt.server.statsLogRotateInterval only.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.stats.packages.exclude
Specifies a comma-separated list of packages whose services are excluded from:
*The Statistics log
*The Server > Statistics page
*The Server > Service usage page
*The Usages tab on the Dashboard
*The Cache and Prefetch Information and Circuit Breaker Information tables in the Services tab on the Dashboard.
Note:
The Service Instances tab in the Services tab on the Dashboard displays the excluded services, but the Last Ran and the Cache, Prefetch, and Circuit Breaker columns are empty.
Specify the full package name, such as WmRoot, or use the * wildcard after the first letters of the package name, such as Wm*. The default value of this parameter is Wm* which excludes all services from packages whose names begin with "Wm" from the statistics log.
The changes to this parameter take effect the next time Integration Server polls for statistics.
watt.server.stats.pollTime
Specifies the number of seconds between updates to the statistics log. For a stand-alone Integration Server, the watt.server.stats.pollTime must be an integer greater than or equal to 0 (zero). For an Integration Server in a cluster, the watt.server.stats.pollTime must be an integer greater than 0 (zero) but less than or equal to 60. The default is 60.
Integration Server Administrator displays this value as the interval of the Statistics Log task on the Server > Scheduling > View system tasks page.
watt.server.statsLogRotateInterval
Specifies the length of the log recycle interval (in minutes) for the statistics log file.The default is 1440 (24 hours).
Integration Server Administrator displays the watt.server.statsLogRotateInterval value as the interval for the Stats Log Recycle task on the Server > Scheduling > View system tasks page. Integration Server Administrator displays this value in seconds instead of minutes. For example, if you set watt.server.statsLogRotateInterval to the default value of 1440, Integration Server Administrator displays the value for the Log Recycle interval as 86400 seconds. For more information about viewing system tasks, see Viewing Scheduled User Tasks.
After Integration Server startup, Integration Server immediately begins rotating the statistics log at the time specified by the watt.server.statsLogRotateInterval. If you set watt.server.statsLogRotateInterval to 2 minutes and Integration Server started at 9:30 pm, Integration Server rotates the statistics log at 9:32, 9:34, 9:36, and so forth. An exception to this behavior is that when the log recycle time is greater than the time from Integration Server startup to midnight, Integration Server first rotates the statistics log at midnight. Thereafter, Integration Server rotates the log at the specified interval. For example, if the watt.server.statsLogRotateInterval is set to 300 minutes (5 hours) and Integration Server starts up at 9:30 pm, Integration Server rotates the statistics log file at midnight and thereafter rotates the statistics log every 5 hours
Note:
The watt.server.statsLogRotateInterval server configuration parameter was previously named the watt.server.logRotateInterval.
watt.server.storage.addKeyToStoreIfNotPresent
Specifies whether the pub.storage:lock service adds the specified key to the data store if the key does not exist in the data store at the time the service executes. Set this parameter to true to have the pub.storage:lock service add the specified key to the data store if the key does not exist at the time the service executes. The pub.storage:lock service creates the specified key, assigns it a NULL value, and then locks the entry in the data store. Set this parameter to false if you do not want the pub.storage:lock service to add the key to the data store. The pub.storage:lock service is a NOP (no operation) if the specified key value does not exist in the data store. The default value is false. For more information about the pub.storage services, see the webMethods Integration Server Built-In Services Reference.
watt.server.storage.lock.maxDuration
Specifies the maximum number of milliseconds a pub.storage service will hold a lock. The default value is 180000 milliseconds (3 minutes). For more information about the pub.storage services, see the webMethods Integration Server Built-In Services Reference.
watt.server.storage.lock.maxWait
Specifies the maximum number of milliseconds a pub.storage service will wait to obtain a lock. The default value is 240000 milliseconds (4 minutes). For more information about the pub.storage services, see the webMethods Integration Server Built-In Services Reference.
watt.server.storage.lock.sweepInterval
Specifies how often (in seconds) Integration Server deletes expired pub.storage locks. An expired pub.storage lock is one that is older than the value specified on the watt.server.storage.lock.maxDuration parameter. The default is 5 seconds. If the watt.server.storage.lock.sweepInterval parameter is set to a value less than one, Integration Server ignores the setting and uses 5 seconds instead. Integration Server does not have to be restarted for changes to this property to take effect. For more information about the pub.storage services, see the webMethods Integration Server Built-In Services Reference.
watt.server.storage.optimizeForStandalone
Specifies whether Integration Server uses the optimization for the pub.storage implementation. When set to true, Integration Server caches database keys in local memory, which may result in a small performance improvement for pub.storage. When set to false (the default), Integration Serverdoes not cache database keys in local memory for pub.storage.
Important:
Do not set watt.server.storage.optimizeForStandalone to true when in a cluster as this may lead to pub.storage database becoming inaccessible.
watt.server.storage.skipStoreExistCheck
Specifies whether Integration Server checks data store names for validity when executing a pub.storage* service. When set to true, Integration Server skips checking the data store name when executing the pub.storage* services. When set to false, when executing a pub.storage* service, Integration Server checks the data store names to ensure the data store is registered. If Integration Server does not recognize the data store name, Integration Server throws an error to indicate the data store name is invalid. Use the pub.storage:registerStore service to register data stores with Integration Server. The default value is true.
watt.server.strictAccessExceptionLogging
Specifies whether Integration Server will log HTTP 401 Access Denied as an error and trigger a notification. When this property is set to true, Integration Server will log HTTP 401 AccessDenied as an error and trigger notifications. When this property is set to false, Integration Server will not log HTTP 401 Access Denied as an error and will not trigger a notification. The default is false.
watt.server.suppresscwarn
Specifies whether, when running a C service in Designer, Integration Server should write the warning messages issued about the missing variables to the server log. When this property is set to true, Integration Server does not write these messages to the server log. When this property is set to false, Integration Server writes messages about missing variables to the server log. The default is false.
watt.server.sync.timeout
Specifies the time period that a lock object exists for a given key for which a notification has been issued. After calling a pub.sync:notify service to create the notification, a pub.sync:wait can receive the notification. Any thread that is waiting for a notification for the key, receives the notification as long as the lifespan of the wait request overlaps with the lifespan of the notification. However, if a thread with an exclusive wait is registered for the notification key before any other service is waiting, the notification ends as soon as the exclusive wait receives the notification. The default is 60 seconds.
watt.server.systemtasks.debug
Enables debug logs related to system tasks. By default its value is false. To enable the logging, change the value to true. The logs are written to server.log under the logging facility User Task Scheduler. The system task logs include information such as when a task got created, when it got terminated, and for recurring tasks, when it will run again.
watt.server.thread.aging.limit
Specifies the length of time, in minutes, a thread can remain in the thread pool. When this length of time is reached and the thread has been used the maximum number of times as specified by the watt.server.thread.usage.limit parameter, Integration Server waits until the service is complete and releases the thread from the pool. A value of -1 indicates that threads can remain indefinitely in the thread pool. The default is 60 minutes.
Note:Integration Server releases an expired thread only when the values for both watt.server.thread.aging.limit and watt.server.thread.usage.limit are reached. Both parameters must be set to a positive integer. If either or both parameters have a value of -1, both parameters will be disabled.
Important:
Use this setting with extreme care because it will affect server performance and throughput.
watt.server.thread.usage.limit
Specifies the maximum number of times a pooled thread can be used. When this maximum number is reached and the length of time specified by the watt.server.thread.aging.limit parameter is reached, Integration Server waits until the service is complete and releases the thread from the pool. A value of -1 indicates that threads can be reused indefinitely. The default is 1000.
Note:Integration Server releases a used thread only when the values for both watt.server.thread.aging.limit and watt.server.thread.usage.limit are reached. Both parameters must be set to a positive integer. If either or both parameters have a value of -1, both parameters will be disabled.
Important:
Use this setting with extreme care because it will affect server performance and throughput.
watt.server.threadKill.enabled
Controls whether the thread kill facility is enabled. This facility allows you to cancel or kill service threads in cases where a service is unresponsive. When you cancel a thread, Integration Server frees up resources that are held by the thread. When you kill a thread, Integration Server stops the thread, releases it from the thread pool, and replenishes the thread pool. The default is true. When the thread kill facility is enabled, you can cancel or kill threads by going to the Server > Statistics > System Threads page. For more information about canceling and killing threads, refer to Canceling and Killing Threads Associated with a Service.
watt.server.threadKill.interruptThread.enabled
Specifies whether Integration Server should interrupt a service for which a timeout is triggered or is cancelled. If set to true, when a timeout is triggered or the service is cancelled, Integration Server interrupts the service thread that is executing a service. The default is false.
Important:
If you change the value of this property, you must restart Integration Server for the change to take effect.
watt.server.threadKill.timeout.enabled
Controls how Integration Server handles the timeout setting of flow steps. Flow steps have a timeout property that controls how long the step can run. By default (true), when the step has exceeded the timeout period, Integration Server raises a FlowTimeoutException, and flow execution continues with the next step. When this property is set to false, it is possible for the flow step to run beyond its timeout period, in some cases. For instance, if a flow step calls another service, for example ServiceA, and ServiceA is executing when the timeout period has passed, ServiceA will continue executing past the timeout period. When ServiceA ends, it passes control back to the parent flow service, which then issues an exception.
watt.server.threadPool
Specifies the maximum number of threads that the server maintains in the thread pool that it uses to run services. If this maximum number is reached, the server waits until services complete and return threads to the pool before running more services. The default is 75.
watt.server.threadPool.cloudRequests
Specifies the maximum percentage of the server thread pool that can be used for processing Integration Cloud requests. The default is 5.
If watt.server.threadPool.cloudRequests is set to 0, the Integration Server processes requests from webMethods Cloud a time. The on-premise Integration Server blocks processing of further requests from webMethods Cloud until the current service execution completes. This delays processing of requests from webMethods Cloud
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.threadPoolMin
Specifies the minimum number of threads that the server maintains in the thread pool that it uses to run services. When the server starts, the thread pool initially contains this minimum number of threads. The server adds threads to the pool as needed until it reaches the maximum allowed, which is specified by the watt.server.threadPool setting. The default is 10.
watt.server.transaction.ignore.exception
Specifies whether Integration Server ignores exceptions that occur when committing an implicit or explicit transaction. When set to false, if an error occurs during the commit of an implicit or explicit transaction (such as during execution of the pub.art.transaction.commitTransaction service), Integration Server propagates the exception and service execution stops. When set to true, Integration Server ignores the exception and executes the next step in the flow service. The default value is false.
Propagating an exception that occurs while committing an explicit or implicit transaction and stopping service execution is the correct behavior. However, in some circumstances the proper handling of the exception for the transaction service may be undesirable. For example, if a flow service contains another local transaction, the propagation of the exception for the pub.art.transaction.commitTransaction service results in a flow service with two local transactions. A single transaction context can contain any number of XA_TRANSACTION connections but no more than one LOCAL_TRANSACTION connection. In this situation, the incorrect behavior of ignoring the exception may be preferred.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.transaction.recovery.abandonTimeout
If an error occurs while Integration Server tries to resolve an uncompleted XA transaction, specifies the maximum length of time (in minutes) during which Integration Server should make additional attempts. The default is 5 minutes.
watt.server.transaction.recovery.sleepInterval
If an error occurs while Integration Server tries to resolve an uncompleted XA transaction, specifies the length of time (in seconds) that Integration Server waits between additional attempts. The default is 30 seconds.
watt.server.transaction.xastore.maxTxnPerFile
Specifies the maximum number of unique XA transactions in an XA recovery log file. When the XA recovery log file reaches the maximum number of transactions, Integration Server creates a new file. The default is 2000 transactions.
Consider increasing the maximum number of unique XA transactions for the XA recovery log file if there are more than 2000 active XA transactions and Integration Server exhibits a performance delay due to input/output. Increasing the number of unique XA transactions allowed per file decreases the number of files used for the XA recovery log, which, in turn, may result in fewer files for Integration Server to search when performing XA recovery.
Decreasing the number of unique XA transactions stored in file may help during transaction recovery as it might decrease the time to read and consolidate open transactions.
watt.server.transaction.xastore.performXALogging
Specifies whether Integration Server writes transaction information to the XA recovery store. Set to true to instruct Integration Server to log information about the state and progress of each XA transaction. Set to false to instruct Integration Server to skip logging XA transaction information. The default is true.
Important:
If you set this property to false, Integration Server does not log any information to the XA recovery story while processing a transaction, making transaction recovery impossible. If you want Integration Server to automatically resolve incomplete transactions or you want to manually resolve incomplete transactions, Integration Server must perform XA logging.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.trigger.interruptRetryOnShutdown
Specifies whether or not a request to shut down the Integration Server interrupts the retry process for a webMethods messaging trigger service. If this parameter is set to false, Integration Server waits for the maximum retry attempts to be made before shutting down. Integration Server will also shut down if the trigger service executes successfully during a retry attempt. If this parameter is set to true, Integration Server waits for the current service retry to complete. If the webMethods messaging trigger service needs to be retried again (the service ends because of an ISRuntimeException), the Integration Server stops the retry process and shuts down. Upon restart, the transport (Broker, Universal Messaging, or, for a local publish, the transient store) redelivers the document to the trigger for processing. The default is false.
watt.server.trigger.keepAsBrokerEvent
Specifies whether Integration Server should bypass decoding that is normally performed when documents are retrieved from the Broker on behalf of a webMethods messaging trigger. If this property is set to true, Integration Server passes the value of the Broker event to the trigger service in an object called $brokerEvent and no decoding is performed. Set this parameter to true if Integration Server is receiving native Broker events. The default is false.
For more information about publishing native Broker events, see the Publish-Subscribe Developer’s Guide.
Note:
This parameter is deprecated because webMethods Broker is deprecated.
watt.server.trigger.local.checkTTL
Specifies whether Integration Server should strictly enforce a locally published document's time-to-live. When this parameter is set to true, before processing a locally published document in a trigger queue, Integration Server determines whether the document has expired. Integration Server discards the document if it has expired. The default is false.
watt.server.trigger.managementUI.excludeList
Specifies a comma-delimited list of triggers to exclude from the webMethods triggers pages in Integration Server Administrator. Integration Server also excludes these webMethods messaging triggers from trigger management changes that suspend or resume document retrieval or document processing for all triggers. Integration Server does not exclude these webMethods messaging triggers from changes to capacity, refill level, or maximum execution threads that are made using the global trigger controls (Queue Capacity Throttle and Trigger Execution Threads Throttle).
You can specify the fully qualified names of all the webMethods messaging triggers that you want to exclude. You can also use pattern matching to exclude a group of triggers by specifying the beginning portion of the fully qualified name and following it with an asterisk (*). The Integration Server excludes all triggers that begin with the supplied pattern. For example, if you want to exclude all triggers located in the pub.prt folder, specify:
watt.server.trigger.managementUI.excludeList = pub.prt*
Specifies the interval, measured in seconds, at which Integration Server executes resource monitoring services for webMethods messaging triggers. A resource monitoring service is a service that you create to check the availability of resources used by a trigger service. When it suspends a webMethods messaging trigger because all retry attempts have failed, Integration Server executes the resource monitoring service to determine if all the resources are available. The default is 60 seconds.
For more information about resource monitoring services, see the Publish-Subscribe Developer’s Guide.
watt.server.trigger.preprocess.monitorDatabaseOnConnectionException
Indicates whether Integration Server schedules a system task to monitor the document history database when a ConnectionException causes a transient error occurs during trigger preprocessing. A ConnectionException indicates that the document history database is not enabled for exactly-once processing or is not properly configured.
When this property is set to true, Integration Server schedules a system task that executes an internal service that monitors the connection to the document history database. When the document history database is enabled for exactly-once processing or is properly configured, the internal service indicates that the connection to the document history database is available. Then, Integration Server resumes the trigger and re-executes it when the connection to the document history database is available.
When this property is set to false, Integration Server does not schedule a system task to check for the database's availability and will not resume the trigger automatically. You must manually resume the trigger after configuring the document history database properly.
The default is false
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.trigger.preprocess.suspendAndRetryOnError
Indicates whether Integration Server suspends a trigger if an error occurs during the preprocessing phase of trigger execution. The preprocessing phase encompasses the time from when the trigger retrieves the document from its local queue to the time the trigger service executes. When this property is set to true, the trigger property On Retry Failure is set to Suspend and retry later, or the trigger property On Transaction Rollback is set to Suspend and recover, Integration Server suspends a trigger if one of the following occurs during preprocessing:
*A transient error occurs because the document history database is not available when Integration Server performs duplicate detection for the trigger. For more information about transient error handling during trigger preprocessing, see webMethods Service Development Help.
If the document history database is properly configured, Integration Server suspends the trigger and schedules a system task that executes a service that checks for the availability of the document history database. Integration Server resumes the trigger and re-executes it when the service indicates that the document history database is available.
If the document history database is not properly configured, Integration Server throws a ConnectionException. To determine how Integration Server handles a ConnectionException during trigger preprocessing, see watt.server.trigger.preprocess.monitorDatabaseOnConnectionException.
*The document resolver service ends because of an ISRuntimeException. Integration Server suspends the trigger and schedules a system task to execute the trigger's resource monitoring service (if one is specified). Integration Server resumes the trigger and retries trigger execution when the resource monitoring service indicates that the resources used by the trigger are available. If a resource monitoring service is not specified, you will need to resume the trigger manually (via the Integration Server Administrator or the pub.trigger* services).
When this property is set to false and the trigger property On Retry Failure is set to Throw Exception or the trigger property On Transaction Rollback is set to Recover only, Integration Server does not suspend the trigger if a trigger preprocessing error occurs. If the document history database is not available, Integration Server
*If the trigger specifies a document resolver service, Integration Server executes the document resolver service to determine the status of the document. If the document resolver service ends because of an ISRuntimeException, Integration Server assigns the document a status of In Doubt, acknowledges the document, and uses the audit subsystem to log the document.
*If a document resolver service is not specified, Integration Server assigns the document a status of In Doubt, acknowledges the document, and uses the audit subsystem to log the document.
Note:Integration Server uses the audit subsystem to log documents for webMethods messaging triggers.
The default value for watt.server.trigger.preprocess.suspendAndRetryOnError is false.
Important:
You must restart Integration Server for changes to this parameter to take effect.
For more information about building a resource monitoring service, see the Publish-Subscribe Developer’s Guide or Using webMethods Integration Server to Build a Client for JMS. For more information about transient error handling during trigger preprocessing, see webMethods Service Development Help.
watt.server.trigger.removeSubscriptionOnReloadOrReinstall
Specifies whether Integration Server deletes document type subscriptions for webMethods messaging triggers when the package containing the trigger reloads or an update of the package is installed. If this property is set to true (the default) and a package reloads or an update of the package is installed, Integration Server deletes and then recreates any document type subscriptions for webMethods messaging triggers in the package. (If Integration Server connects to a Broker, Integration Server deletes and recreates the subscriptions on the trigger client on the Broker.) This creates a small window of time during which the document type subscriptions do not exist. During this window, the trigger will not receive documents to which it normally subscribes.
If this property is set to false, Integration Server does not delete and then recreate document type subscriptions for webMethods messaging triggers when the package reloads or is updated. Although Integration Server creates new document type subscriptions for triggers, Integration Server does not modify existing subscriptions. Specifically, if a trigger deleted a document type subscription, the subscription will not be removed when the package reloads or is updated. Consequently, when this property is set to false, the trigger might receive document types to which it no longer subscribes because the deleted document type subscriptions still exist on the trigger client on the Broker. When working with a 6.5.2 version of webMethods Broker, you can use My webMethods to delete the obsolete document type subscriptions from the trigger client on the Broker. The default is true.
Note:
This property does not affect webMethods messaging triggers running in a cluster of Integration Servers.
watt.server.trigger.reuseSession
Indicates whether instances of a webMethods messaging trigger use the same session on Integration Server when the document locale is the same as the default locale of Integration Server. When this property is set to true, Integration Server checks the locale of the document before processing it. If the document locale is the same as the default locale of Integration Server, or no locale is specified, the trigger uses a shared session. If the document locale is different from the default, then Integration Server creates a new session for the trigger to use to process that document. When this property is set to false, Integration Server uses a new session for each instance of a trigger. The default is false.
Reusing sessions for a webMethods messaging trigger might improve performance. However, this property does not work with all adapters.
Note:
If you use the Adapter for SAP set watt.server.trigger.reuseSession to false if a concurrent trigger has a trigger service that executes multi-step SAP transactions that make calls to the pub.sap.client:lockSession and pub.sap.client:releaseSession services. These services require dedicated sessions.
watt.server.trigger.shutdown.timeout
Specifies the number of seconds that Integration Server waits for trigger services to finish executing after disabling a concurrent webMethods messaging trigger that retrieves messages from Broker. A webMethods messaging trigger can be disabled explicitly via the Integration Server Administrator or a built-in service or implicitly when a package containing the trigger is stopped (reloaded or Disabled). Once the trigger is disabled, if any trigger service invoked by the trigger is currently executing, Integration Server waits the length of time specified in watt.server.trigger.shutdown.timeout before gracefully shutting down the trigger. For any trigger service that executes to completion after trigger shut down occurs, Integration Server will not be able to acknowledge the message. The trigger may re-retrieve the message upon startup of the trigger. The default is 3 seconds. Integration Server uses the new value the next time a webMethods messaging trigger that retrieves messages from the Broker is disabled.
watt.server.trigger.suspendOnAuditErrorWhen
Specifies when Integration Server should suspend a webMethods messaging trigger. A trigger can be suspended when both the following occur:
*The trigger service fails.
*The trigger service cannot write audit data to the audit database because an audit exception occurs.
When Integration Server suspends a webMethods messaging trigger, it halts document processing and document retrieval for the trigger. Suspending the trigger prevents Integration Server from acknowledging the document and prevents the messaging provider from discarding the document. After suspending the trigger, Integration Server monitors the connection to the audit database and resumes the trigger (document processing and document retrieval) when the connection to the audit database is re-established. Integration Server retrieves the unacknowledged document from the messaging provider and attempts to process it again.
Set the watt.server.trigger.suspendOnAuditErrorWhen parameter to one of the following values:
Specify
To
Never
Indicate that Integration Server does not suspend a trigger if the trigger service ends because of an error and an audit exception occurs when the trigger service attempts to write data to the audit database.
Error
Indicate that Integration Server suspends a trigger if the trigger service ends because of an error and an audit exception occurs when the trigger service attempts to write data to the audit database.
ErrorPipelineEnabled
Indicate that Integration Server suspends a trigger if the trigger service ends because of an error, the trigger service is configured to include the service pipeline in the audit log, and an audit exception occurs when the trigger service attempts to write data to the audit database. The default is ErrorPipelineEnabled.
Important:
You must restart Integration Server for changes to this parameter to take effect.
The watt.server.trigger.suspendOnAuditErrorWhen configuration parameter only applies when the audit subsystem is configured to write data synchronously.
watt.server.tspace.location
Specifies the absolute directory path of the hard disk drive space in which the Integration Server is to temporarily store large documents rather than keep them in memory. Each file that the Integration Server stores in this directory is given the name DocResxxxxx.dat, where xxxxx is a value that can vary in length and character. Specify the absolute directory path to a directory on the same machine as the Integration Server. The default value is JVM's temporary directory (i.e., the value of java.io.tmpdir).
Example: If you want the Integration Server to use the LargeDocTemp directory on your D drive, specify the following:
watt.server.tspace.location=D:\LargeDocTemp
If you have a cluster of Integration Servers, each one must have its own Tspace.
Important:
You must restart Integration Server after you modify the value of this property.
watt.server.tspace.max
Specifies the maximum number of bytes that can be stored at any one time in the hard disk drive space that you defined using the watt.server.tspace.location property. If the Integration Server attempts to write a large document to the hard disk drive space that will cause the number of bytes you specify to be exceeded, an error message is displayed on the server console, and the document is not stored. Specify a positive whole number of bytes. The default value is 52,428,800 bytes (50 MB).
Example: To set the maximum number of bytes that can be stored to 30,000,000 bytes, specify the following:
watt.server.tspace.max=30000000
Tip:
The size of the hard disk drive space for temporarily saving documents will vary based on the number of documents that you process concurrently and the size of the documents that you process. For example, if your typical concurrent document load is 10, you would need a hard disk drive space that is 10 to 15 times the combined size of the documents being processed concurrently.
Important:
You must restart the Integration Server after you modify the value of this property.
watt.server.tspace.timeToLive
Specifies the amount of time in milliseconds that documents can remain in the Tspace before they are deleted. If a document remains in the Tspace longer than the value defined by this parameter, the document expires and becomes eligible for removal from the Tspace. Expired Tspace documents are removed when the Tspace begins to run low on free disk space. The default is 0.
Important:
You must restart the Integration Server after you modify the value of this property.
watt.server.tx.cluster.jobPendingWait
Specifies the number of seconds that Integration Server waits for a guaranteed delivery job to complete when retrieving the results of a job with TContext.invokeTx() or TContext.retrieveTx(). The default is 60 seconds.
Important:
For changes to this parameter to take effect, you must reinitialize guaranteed delivery as described in Reinitializing Guaranteed Delivery or restart Integration Server.
watt.server.tx.cluster.lockBreakSecs
Specifies the number of seconds a cluster server waits before breaking a lock on a job in a cluster job store. The default is 120.
watt.server.tx.cluster.lockTimeoutMillis
Specifies the number of milliseconds a cluster server sleeps between attempts to place an update lock on a job in a cluster job store. The default is 100.
watt.server.tx.heuristicFailRetry
Specifies whether the Integration Server is to re-execute services for guaranteed delivery transactions in the job store that are pending when the Integration Server is restarted after a failure. If a transaction is pending, the service began execution before the Integration Server failed.
If the setting is true, the Integration Server resets the transaction status from pending to new, and the service will be re-executed. If the setting is false, the Integration Server resets the transaction status from pending to fail to indicate the heuristic failure, and the service will not be re-executed. The default is true.
watt.server.tx.sweepTime
Specifies the number of seconds between sweeps (clean up) of the job store for inbound guaranteed delivery transactions. The server sweeps the job store to remove expired transactions. The default is 60.
watt.server.txMail
Specifies the email address of an administrator to notify when guaranteed delivery capabilities are disabled due to an error (for example, if the Integration Server encounters a disk full condition or if the audit-trail log is full). There is no default.
watt.server.typeSynchronizer.verbose
Specifies whether verbose logging is enabled during document type synchronization with the Broker. Verbose logging can be useful for debugging document type synchronization. Set to true to enable verbose logging during document type synchronization with the Broker. Integration Server writes the log messages to the wrapper.log. Set to false to disable verbose logging during synchronization with the Broker. The default is false.
watt.server.um.producer.transaction.commitRetryCount
Specifies the number of attempts made by Integration Server in publishing a guaranteed document to a Universal Messaging server, after the initial attempt at publishing fails because of a transaction failure. The maximum number of retries is nine. If you try to assign a value greater than nine, Integration Server automatically sets the value of the property to nine. The default is zero.
When setting a retry value, you must ensure that the value of the total transaction timeout does not exceed the value of the MaxTransactionTime property. The total transaction timeout value is calculated by multiplying the total number of retry attempts with the value of the EventTimeout property. For example, if the retry value is set to 9, and the EventTimeout is set to 60s, the total transaction timeout is 60(9+1)= 600s.
Note:
You can configure the values of the MaxTransactionTime and EventTimeout properties in the Universal Messaging Enterprise Manager.
watt.server.url.alias.partialMatching
Specifies whether Integration Server enables partial matching on URL aliases. If you set this server configuration parameter to true and define a URL alias in Integration Server Administrator, Integration Server enables partial matching on URL aliases. The default is false.
When partial matching is enabled Integration Server considers an alias a match if the entire alias matches all or part of the request URL, starting with the first character of the request URL path.
For information about partial matching and defining URL aliases, see Setting Up HTTP URL Aliases. For specific information about partial matching for REST resources configured using the legacy approach, see REST Developer’s Guide.
Important:
If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.
watt.server.userFtpRootDir
Specifies the FTP root directory that the Integration Server will create at startup. When any Integration Server user logs into the FTP Listener, the server creates that user's FTP home directory in this root directory, for example FtpRoot/username. You can specify any directory to be the root directory, including a mapped network directory. If this property is not defined, a default directory named userFtpRoot is created in your Integration Server home directory.
The user who connects to Integration Server through FTP listener is placed either in the default FTP root directory or the client user directory as defined in the watt.server.login.userFtpDir property.
Administrators, Replicators, and non-privileged users can perform put and get operations in the following directories:
This user
Can access
Administrator
*admin (in the Integration Server home directory)
*The Administrator's own user directory
*The entire namespace for all packages, including WmRoot
*All other user directories
Replicator
*The Integration Server_directory \instances\instance_name\replicate directory
*Any services in the namespace that have Replicator ACL or lower
*The Replicator's own user directory
Non-privileged user
*The user's own user directory
*Any services that have an ACL at or below the level of the user's ACL
When a user completes a put command in his or her own user directory (that is, when the STOR command is completed on the server side but before the server acknowledges the client with return code 226), an event is fired to notify interested parties by publishing a pub.client.ftp:putCompletedNotification document to the webMethods Broker. EDI packages will subscribe to this document and will retrieve the file just put onto the server.
Note:
The STOU command is not supported on the Integration Server. However, it is supported for clients. See the following built-in services in the webMethods Integration Server Built-In Services Reference: pub.client.ftp, pub.client.ftp:put, and pub.client.ftp:mput.
watt.server.ws.71xHandlerChainBehavior
Specifies whether Integration Server uses the 7.1x handler chain processing behavior when executing handlers for a web service descriptor created in 7.1x. When set to true, Integration Server uses the handler chain processing behavior available in Integration Server version 7.1x for a 7.1x web service descriptor. When set to false, Integration Server uses the handler chain processing behavior available in Integration Server 8.0 for a 7.1x web service descriptor. The default is false.
watt.server.ws.defaultNamespace
This is an internal property. Do not modify.
watt.server.ws.defaultPrefix
Specifies the prefix assigned to the namespace http://www.webMethods.com/2001/10/soap/encoding for use in details for SOAP faults. The default is webM.
watt.server.ws.responseTNS.from.request
For a provider web service descriptor for which thePre-8.2 compatibility mode property is set to true, specifies whether the target namespace of the top-level element in the response uses the target namespace of the top-level element in the request. When set to true, a web service response sent by the Integration Server uses the target namespace of the top-level element in the request as the top-level namespace of the response. While this is incorrect behavior, it provides backward compatibility. If existing web service clients failed because the client expected a response that used the namespace of the top-level element of the request and you want to allow existing clients to continue to process responses without any changes to the client, set watt.server.ws.responseTNS.from.request to true.
When set to false, Integration Server uses the target namespace of the provider web service descriptor as the namespace of the top-level element in the response. This is the correct behavior. The default value is false.
Note:
After upgrading to Integration Server 9.10 or later from a version of Integration Server earlier than 9.10, if you have web service providers that specify Pre-8.2 compatibility mode = true with existing web service clients that expect the namespace of the response to match the namespace of the request, they may fail due to the namespace mismatch. Software AG recommends regenerating those web service clients using a WSDL document retrieved from current provider web service descriptor. Alternatively, set watt.server.ws.responseTNS.from.request to true, which will revert to behavior of using the namespace of the request on the response rather than using the namespace as specified in the current WSDL document. While this behavior may be backward compatible, it may generate a response that does not match the current WSDL of the provider web service descriptor. For this reason, Software AG discourages setting watt.server.ws.responseTNS.from.request to true.
Note:
This parameter is deprecated because the web services implementation introduced in Integration Server 7.1 is deprecated as of Integration Server 10.4. The web services implementation introduced in Integration Server version 7.1 handles web service descriptors that run in pre-8.2 compatibility mode.
watt.server.ws.security.timestampMaximumSkew
Specifies the maximum number of seconds that the web services client and host clocks can differ so that the timestamp expiry validation does not fail. Integration Server validates the inbound SOAP message only if the creation timestamp of the message is less than the sum of the timestamp maximum skew value and the current system clock time.
You can use this parameter to set the timestamp maximum skew value when Integration Server uses WS-Security policy to implement security and if you have not set a value in the Timestamp Maximum Skew field in the Create web Service Endpoints Alias page. The value must be a positive integer or zero. The default is 300 seconds.
watt.server.ws.security.timestampPrecisionInMilliseconds
Specifies whether the timestamp placed in the Timestamp element of the security header of an outbound message is precise to seconds or milliseconds. If you set the precision to milliseconds, Integration Server uses the timestamp format yyyy-MM-dd'T'HH:mm:ss:SSS'Z'. If you set the precision to seconds, Integration Server uses the timestamp format yyyy-MM-dd'T'HH:mm:ss'Z'.
You can use this parameter to set the precision when Integration Server uses WS-Policy to implement WS-Security and if you have not set a value in the Timestamp Precision field in the Create Web Service Endpoints Alias page. Set this property to true, if you want the timestamp precision set to milliseconds. Set this property to false, if you want the timestamp precision set to seconds. The default is true.
watt.server.ws.security.timestampTimeToLive
Specifies the time-to-live value for an outbound message in seconds. Integration Server uses this value to set the expiry time in the Timestamp element of outbound messages.
You can use this parameter to set the time-to-live value when Integration Server uses WS-Policy to implement WS-Security and if you have not set a value in the Timestamp Time to Live field in the Create web Service Endpoints Alias page. The value must be an integer greater than 0. The default is 300 seconds.
watt.server.ws.security.usernameTokenTTL
Specifies the permitted time difference, in seconds, between the time when the UsernameToken was created (as provided in the wsu:Created element) and the time when it reaches the server. You can use this parameter to configure the username token TTL at the global level. The default is 300 seconds.
You can also configure this property for individual endpoint aliases using the WS Security Properties section of the Settings > Web services pages. The value set in the Settings > Web services pages overrides the value in this configuration setting.
watt.server.ws.security.usernameTokenFutureTTL
Specifies whether the permitted time difference between wsu:Created elements with a timestamp that is in the future and the Integration Server clock. Integration Server considers such requests as valid if the time at which the request was created does not exceed the time at which it reaches Integration Server by the value (in seconds) given in this setting. The default is 60 seconds.
You can also configure this property for individual endpoint aliases using the WS Security Properties section of the Settings > Web services pages. The value set in the Settings > Web services pages overrides the value in this configuration setting.
watt.server.wsdl.debug
Specifies whether Integration Server prints debug information to standard out and stack traces to standard error while generating or consuming WSDL. When set to true, Integration Server prints debug information to standard out and stack traces to standard error. The default is false.
watt.server.xml.encoding
Specifies the encoding that Integration Server must use when processing incoming XML files.
If an encoding is not defined in the XML header, Integration Server attempts to process the XML file using the charset encoding of the http or ftp request. If charset encoding is not available in the request header, then Integration Server uses the character encoding specified in the watt.server.xml.encoding server configuration parameter. There is no default value for this parameter.
Note:
If you have configured Integration Server to use the character encoding specified in the watt.server.fileEncoding parameter to process incoming XML files previously, ensure that the value of watt.server.fileEncoding parameter is set to the same value specified for watt.server.xml.encoding. If you have not configured watt.server.fileEncoding for processing XML files previously, after installing this fix or after upgrading to a higher version of Integration Server, you can configure watt.server.xml.encoding to process incoming XML files. You can use watt.server.fileEncoding to process all files other than incoming XML files.
Important:
You must restart Integration Server for changes to this parameter to take effect.
watt.server.xml.enforceEntityRef
Specifies whether the server will throw an exception when the XML parser detects a malformed entity. If the value is set to true, the server will throw an exception when it detects a malformed entity in an XML or DTD. If the value is set to false (the default), the server will allow malformed entities and does not throw an exception.
watt.server.xml.xmlNodeToDocument.keepDuplicates
Specifies whether the pub.xml:xmlNodeToDocument service keeps additional occurrences of an element in an XML node when arrays are not created (the makeArrays input parameter is set to false). This parameter also determines whether or not the pub.event.eda:eventToDocument service keeps additional occurrences of an element in the XML document passed into the service. When set to true, the document produced by the pub.xml:xmlNodeToDocument service contains multiple occurrences of the element. When set to false, the document produced by the pub.xml:xmlNodeToDocument service keeps only the last occurrence of the element. The default is true.
For example, suppose the following XML node is provided as input to the pub.xml:xmlNodeToDocument service:
<?xml version="1.0" encoding="UTF-8"?><myDoc><e1
e1Attr="attrValue1">e1Value1</e1><e2>e2Value</e2><e1
e1Attr="attrValue2">e1Value2</e1></myDoc>
When watt.server.xml.xmlNodeToDocument.keepDuplicates is set to true, the pub.xml:xmlNodeToDocumentservice produces this document:
an overview of the document
When watt.server.xml.xmlNodeToDocument.keepDuplicates is set to false, the pub.xml:xmlNodeToDocument service produces this document:
an overview of the document
Note that only the last <e1> element in the source XML is retained in the resulting document.
watt.server.xml.xmlNodeToDocument.makeArrayforWS
Specifies how Integration Server decodes duplicate elements contained in an anyType element. Set watt.server.xml.xmlNodeToDocument.makeArrayforWS to true if you want Integration Server to create an array for duplicate elements contained in an element of type anyType. Set this parameter to false if you want Integration Server to leave duplicate elements as separate, repeated elements in the element defined to be of type anyType. When set to false, Integration Server does not create an array for elements that appear more than once in the element defined to be of type anyType. The default is false.
watt.server.xmlCoder.getUndefinedDataTypeClassName
Determines whether the class name of an unsupported data type is included in the:
*XML document produced by com.wm.util.coder.XMLCoder.encode, the pub.document:documentToXMLValues service, the deprecated service pub.record:XMLValuesToRecord
*IData object returned by the pub.document:XMLValuesToDocument service and the deprecated pub.record:XMLValuesToRecord service, and the Values object returned by com.wm.util.coder.XMLCoder.decode
Set to true to include the class name of an unsupported data type in the XML document or IData object produced by the methods and services identified above. Set to false to omit the class name of an unsupported data type. The default is false.