Managing Environment-Specific Configuration Settings¶
A typical organization uses multiple DataPower devices, and multiple domains in each device. Usually, at least one device is used for development and testing; multiple devices could be used in production.
Different devices have different IPs, ports and potentially other parameters (environment settings). DPBuddy provides an extensible and flexible mechanism for managing environment settings. This mechanism can be used instead of or in addition to any traditional approach for managing environment settings, such as specifying all settings for a given environment in a separate file.
DPBuddy supports two different formats for defining environment settings: HOCON and name=value properties. HOCON/JSON is much more powerful and expressive than properties and thus recommended for complex configurations.
env/device Attribute/Option and environment Task¶
The environment name is specified using the env attribute/option or the dp.env property. The env attribute/option is supported by all DPBuddy tasks/commands. DPBuddy also supports device attribute/option and dp.device aliases. env and device can be used interchangeably; it’s up to the user to decide which name to use.
DPBuddy also comes with the environment task described below. This task should be used if environment settings are used for non-DPBuddy tasks (e.g., if you want to “echo” the value of a property). In all other cases env/dp.env is sufficient.
dp.env globally defaults the environment name to its value for all DPBuddy tasks and commands.
The environment name can contain one or multiple elements separated by “.”. The trailing dot is not needed.
Once the environment name is set, DPBuddy provider will use this name for locating HOCON objects and for dealing with property prefixes.
The environment task can be called multiple times within a build file. Each invocation will override the name defined earlier.
The environment name defined using env attribute will only apply to the task where it was specified. In this case, the environment won’t be set globally.
You can also undefine the environment name using the environment task by specifying an empty string as the value: name="".
Note that the DPBuddy’s environment settings resolution mechanism does not propagate to Ant sub-projects. If you invoke another Ant file or target using Ant or AntCall, make sure to invoke environment in this sub-project.
Attributes of the environment Task¶
Name |
Description |
Required |
|---|---|---|
name
prefix
|
Name of the target environment. An empty value (name=””) will disable the DPBuddy’s environment settings resolution mechanism. |
Yes |
providerClass |
Property provider implementation. The class has to implement the Defaults to DPBuddy’s property provider. |
No |
Examples¶
Using environment with HOCON configuration:
<dp:confText>
dev: {proxy.port: 8080}
test: {proxy.port: 7070}
</dp:confText>
<dp:environment name="test" />
<!-- Will print 7070 -->
<echo>{proxy.port}</echo>
Using environment with properties:
<!-- DataPower url is defined at the device level -->
<property name="devtestdevice.dp.url" value="https://devtest.dp" />
<!-- Each WS proxy has its own port in each of the domains -->
<property name="devtestdevice.devdomain.wsproxy.port" value="8082" />
<property name="devtestdevice.testdomain.wsproxy.port" value="9082" />
<!--Provide our name to DPBuddy's provider for property resolution-->
<dp:environment name="devtestdevice.devdomain" />
<!-- dp.url should point to devtest.dp url -->
<echo message="dp.url value: ${dp.url}"/>
<!-- the value of the port should be the one for the devdomain -->
<echo message="wsproxy.port value: ${wsproxy.port}"/>