Integration Server 10.5 | Integration Server Administrator's Guide | Environment Variables for Use with Docker | Environment Variables
 
Environment Variables
Integration Server and Microservices Runtime use environment variables (ENV variable) to support performing tasks while Integration Server or Microservices Runtime runs in a Docker container. Environment variables are included in the docker run command immediately before the image name. You can also use these environment variables when starting Integration Server or Microservices Runtime from the command line.
Note:
Unless otherwise specified, an environment variable for use with Microservices Runtime can be used with an Integration Server equipped with an Microservices Runtime license.
The following table identifies the environment variables supported with Integration Server or Microservices Runtime.
Environment Variable
Description
EXTERNALIZE_PACKAGES
When set to true, instructs the Integration Server running in the Docker container to load the packages located in one of the following directories at startup:
*<HOST_DIR>/<SERVICE_NAME>/packages
*<HOST_DIR>/<INSTANCE_NAME>/packages
Where HOST_DIR SERVICE_NAME, and INSTANCE_NAME are the values set for the ENV variables of the same name.
If SERVICE_NAME is supplied,Integration Server looks in <HOST_DIR>/<SERVICE_NAME>/packages. Only if SERVICE_NAME is not supplied, does Integration Server look in <HOST_DIR>/<INSTANCE_NAME>/packages.
The default value of EXTERNALIZE_PACKAGES is false.
The content of the packages directory must be a folder where the folder name is the package name. The contents of the packageName folder must match the structure of Integration Server packages. That is the packages located in the packages directory cannot be an archive file, such as *.zip or *.7z. For information about the structure of an Integration Server package, see How the Server Stores Package Information.
HOST_DIR
The path to the mounted directory on the HOST machine to which to write the files. Passing the HOST_DIR parameter and value or setting it as an ENV variable with the docker run command externalizes the logs and configuration artifacts of Integration Server.
JAVA_MAX_MEM
The maximum heap size. The default value is 1024 MB. Use the JAVA_MAX_MEM environment variable to override the value set forMicroservices Runtime in Integration Server_directory /bin/setenv.bat|sh file without having to edit the file itself.
Note:
The JAVA_MAX_MEM environment variable is for use with Microservices Runtime only.
JAVA_MIN_MEM
The minimum heap size. The default value is 256 MB. Use the JAVA_MIN_MEM environment variable to override the value set forMicroservices Runtime in Integration Server_directory /bin/setenv.bat|sh file without having to edit the file itself.
Note:
The JAVA_MIN_MEM environment variable is for use with Microservices Runtime only.
PERSIST_LOGS
If set to true, the Integration Server running inside the Docker container persists the log files to HOST_DIR/SERVICE_NAME/logs where SERVICE_NAME is replaced by INSTANCE_NAME if the SERVICE_NAME environment variable is not specified. Integration Server externalizes the logs located in the Integration Server_directory /instances/<instanceName>/logs and profiles/IS_<instanceName>/logs directories. If set to false, the Integration Server running inside the Docker container does not externalize the log files. The default is true.
PERSIST_CONFIGS
If set to true, the Integration Server running inside the Docker container persists the configuration files to the HOST_DIR/SERVICE_NAME/config directory where SERVICE_NAMEis replaced by INSTANCE_NAME> if the SERVICE_NAME environment variable is not specified. If set to false, the Integration Server running inside the Docker container does not externalize the config files. The default is true.
SAG_IS_AUDIT_STDOUT_LOGGERS
Specifies the audit loggers to write to the console (STDOUT). When an audit logger writes to STDOUT it is considered an auxiliary output which means the logger will still write to the specified log destination of file or database. Set to one of the following:
*A comma-separated list of the audit loggers that you want to write to STDOUT. For example: WMSESSION,WMERROR
The audit logger name is the first portion of the audit log file name. For a list of audit log files names, see File Names and Locations webMethods Audit Logging Guide.
*A comma-separated list of the logger names as they appear in the Settings > Logging page in Integration Server Administrator. For example: Session Logger,Error Logger
*ALL to write all log entries for all file-based audit loggers to STDOUT.
*NONE to indicate that none of the file-based audit loggers will write to STDOUT. This is the default value.
The variable content is case-insensitive.
When writing audit log entries to STDOUT, Integration Server includes the logger name in the entry to identity the source of the entry.
For information about using the SAG_IS_AUDIT_STDOUT_LOGGERS environment variable with Integration Server running in Docker container, see Writing Audit Logs to the Console.
You can configure the delimiters used for fields and records in the audit log entries written to STDOUT using the watt.server.audit.stdout.fieldDelimiter and watt.server.audit.stdout.recordDelimiter server configuration parameters, respectively.
SAG_IS_CONFIG_PROPERTIES
Specifies the location and name of the configuration variables template for use with Microservices Runtime or an Integration Server with licensed Microservices Runtime functionality.
SAG_IS_CONFIG_VARIABLES_DEBUG
When set to true, instructs Microservices Runtime to include debug level messages in the log generated during configuration variable initialization. When set to false, configuration log messages of severity Information and higher are included in the configuration variables log. The default is false.
For more information about configuration variables logging, see Developing Microservices with webMethods Microservices Runtime Configuration Variables Logging .
SAG_IS_LICENSE_FILE
Supplies a license file to use with Integration Server in place of the licenseKey.xml located in the Integration Server_directory /instances/instanceName/config. The specified license key must be a valid license file and in a location accessible by Integration Server. For an Integration Server running in a Docker container, the provided license key must be available on a mounted directory on the host file system. At start up, if a file exists at the location specified by SAG_IS_LICENSE_FILE, Integration Server copies the file from the specified location to Integration Server_directory /instances/instanceName/config and saves the file as licenseKey.xml
Supplying the license file at start up can be useful when a Docker image for an Integration Server contains an expired license file or you want it specify an alternative license file for use with an existing Docker image. By using SAG_IS_LICENSE_FILE to supply the license file, you can change the license file without recreating a Docker image.
SERVICE_NAME
Name of a unique directory under HOST_DIR for persisting Integration Server artifacts. When supplied, the logs and config directories are created under the HOST_DIR/SERVICE_NAME directory and all artifacts of logs and config directories are persisted in the respective directories. If SERVICE_NAME is not supplied, Integration Server instance name will be used for the name of the unique directory that gets created under the HOST_DIR directory. Software AG recommends specifying a unique directory for each Docker container.