Using variables for dynamic configuration

You can dynamically configure certain properties belonging to actions, agents and services configuration to cut back on your implementation time.

For example, you can provide a dynamic way of configuring network properties such as provider URLs, E-mail server, and Sender addresses. These properties can be configured as variables in one place and can be resolved at runtime when these properties are being used.

You can provide variables in place of file or directory names wherever a file name or path can be entered in the Applications Manager. This variable substitution is based on an entry in the <runtime_sandbox>/properties/customer_overrides.properties file and is resolved during runtime.

You can use variable names in the following components of the Applications Manager:

  • Service Definition Framework
    • All transport types such as JMS queue name, JMS topic name, Initial Context Factory, Connection Factory and Provider URL. File Sender and Receiver, FTP source and destination for sender and receiver directories and HTTP and Webservice transport types.
    • In the e-mail component, where you can specify, the email server, subject, listener port, and From addresses. The dynamic configuration can also be used for specifying the email protocol.
    • Actions
      • In call HTTP extension and Execute Program.
    • Agent criteria details
      • JMS Queue Name, Initial Context Factory, Connection Factory and Provider URL.
  • Printer Devices, Print Documents, and Print Components
  • Purge Criteria's log file name
  • In the System Management console:
    • You can use variables to specify installation rules such as e-mail server name, server IP address, server listener port, and e-mail protocol.
    • You can provide variables for the JMS monitoring configuration fields, which include: WebSphere® Channel name, host name, port number and queue manager name.

For the fields identified above, you can configure the values as yfs.VARIABLE_NAME in the <runtime_sandbox>/properties/customer_overrides.properties file. It is stored in the database as is and at runtime when the variables are used, a lookup is performed in the customer_overrides.properties file to decipher the value. Since the values for these variables are fetched from the customer_overrides.properties file, they are specific to a particular JVM.

Note: The value of this variable cannot be seen in the health monitor agent details, since the value depends on the JVM on which it is deployed. You have to click on the server details of the monitor agent to view the value of the variable.
For example, if you want to set the File IO Receiver's directory structure to a common variable (such as ${ffbase}) , then the incoming directory should be set to: 
${ffbase}/incoming

The value for the variable ${ffbase} that you defined in the Applications Manager must be defined in the customer_overrides.properties file with a prefix of yfs as:

  yfs.ffbase=C:/FileIODir/Receiver

This ${ffbase}/incoming value is stored in the database, and when processing the file adapter, the variable is resolved to C:/FileIODir/Receiver/incoming.

The following conditions are assumed for the usage of this variable:

  • All the variables when referenced must be in the following format:
    • ${variable_name}
  • All variables should be properly formed. If a variable is not found, no substitution takes place.
  • Variables must not contain the '}' character.
  • Variables must not begin or end with a whitespace character.
  • Templates do not support variables for filenames since they are always resolved within the classpath.