Integration Server 10.15 | Microservices Runtime Guide | Using Configuration Variables Templates with Microservices Runtime | When Is the Template Applied?
 
When Is the Template Applied?
 
Using Multiple Templates
Microservices Runtime applies a configuration variables template during startup before the initialization sequence begins. When Microservices Runtime starts, either in a Docker container or on-premises, Microservices Runtime looks for a configuration variables template in the following locations in the specified order.
1. The locations identified by the SAG_IS_CONFIG_PROPERTIES environment variable.
The value of SAG_IS_CONFIG_PROPERTIES can be a comma-separated list of files and/or directories. Microservices Runtime applies the templates in the order the templates are listed for the SAG_IS_CONFIG_PROPERTIES value. In the case of a directory, Microservices Runtime applies the templates in alphabetical order. For more information about using multiple templates, see Using Multiple Templates.
2. Integration Server_directory /instances/instanceName/application.properties
3. Integration Server_directory /application.properties
Once Microservices Runtime locates a template in one of the above locations, Microservices Runtime does not look in any remaining locations.
Note:
If Microservices Runtime does not find a configuration variables template at any of the above locations, Microservices Runtime proceeds with startup and does not apply a template.
Microservices Runtime processes the template or templates, updating the configuration information in Microservices Runtime with the information in the template. While processing the template, Microservices Runtime writes log messages to the logs/configurationvariables.log to reflect the progress of the variable substitution. When updating is complete, Microservices Runtime proceeds with initialization. For information about how Microservices Runtime processes multiple templates, see Using Multiple Templates.
If Microservices Runtime cannot apply an application.properties file because the file is malformed, Microservices Runtime logs errors about the malformed file to the server log and error log.Microservices Runtime writes the following to the error log: Dynamic variables processor has encountered an error. Please refer to configuraitonvariables.log for details. Microservices Runtime logs the actual exception to the error log.
If the Microservices Runtime license file cannot be read during start up and a configuration variables file is present, Microservices Runtime does not proceed with start up and logs the following error: [ISS.0028.9999C] com.softwareag.is.dynamicvariables.DynamicVariablesCriticalException: The license provided is invalid or cannot be read. Remove application.properties file or provide a valid MSR license
When updating the configuration, if Microservices Runtime encounters an asset that does not exist, one of the following happens:
*If the asset is one of the types that can be created through a configuration variables template, Microservices Runtime creates it using the supplied key-value pairs. Only a subset of all the properties for an asset can be set in a configuration variables template. Microservices Runtime uses default values for all other asset properties. For a list of assets that can be created via application of a configuration variables templates, see Creating New Assets with the Configurations Variable Template.
*If an asset type cannot be created through a configuration variables template, Microservices Runtime ignores properties and values that do not correspond to existing assets on the Microservices Runtime.
During substitution or asset creation, Microservices Runtime sets values for properties that are specified in the template but not set on the Microservices Runtime. For example, suppose the configuration variables template file specifies the following for a JMS connection alias named myAlias:
jms.myAlias.clientID=abc
jms.myAlias.password=encryptedValue
jms.myAlias.user= userA
If the Microservices Runtime contains a JMS connection alias named “myAlias” and that alias specifies a Connection Client ID value of “xyz”, at startup, Microservices Runtime substitutes “abc” for “xyz”. If the myAlias connection alias does not specify values for Username or Password, Microservices Runtime substitutes the values set in jms.myAlias.password and jms.myAlias.user in the application properties template for the JMS connection alias Username and Password fields.