Templates
You define inline templates in the templates: section. The templates included in this section are identified by a unique template alias. In the templates:templateAlias: sections, you can specify context parameters that resolve to values specific to the context in which you apply the template. However, if you define actions: under the templates: section and use context variables in the action file names, the context variables do not resolve automatically when you apply the template.
The following table lists the context parameters supported with DSL version "1.0" or higher:
Parameter | Description |
${node.host} | Resolves to the host of the node on which the template is provisioned. |
${node.alias} | Resolves to the alias of the node on which the template is provisioned. |
${src.node.host} | When environment.mode=MIGRATION, resolves to the host of the source node for the migration. When environment.mode=PROVISION, resolves to the same value as node.host |
${migration.type} | Resolves to the type of migration (overinstall, same host, or cross-host) required for the product instance. |
The following table lists the context parameters supported with DSL version "1.1" or higher:
Parameter | Description |
${node.alias.prefix} | Use only when the mapping policy for node alias is set to INDEX. The prefix of the node alias. When policy HOSTNAME or EXISTING, the value of this parameter is empty. |
${nodes[i]} | Resolves to the node aliases of the infrastructure layer with an index number, for example ${nodes[1]} |
${hosts[i]} | Resolves to the hosts of the infrastructure layer with an index number, for example ${hosts[1]} |
${nodes.count} | Resolves to the number of nodes on which the infrastructure layer is applied. The value is 1 or higher, although 0 is also a valid value. Note that you can also use this context parameter in the layers: section. |
${node.index} | Resolves to the index number of the node in the infrastructure layer. The value starts at 1 and goes as high as ${nodes.count}. |
${myLayer.nodes[i]} | Resolves to the node alias of myLayer with a node index number, for example ${um.nodes[1]}. |
${myLayer.hosts[i]} | Resolves to the node host of myLayer with a node index number, for example ${um.hosts[1]}. |
${myLayer.nodes.count} | Resolves to the number of nodes in myLayer. The value is 1 or higher, although 0 is also a valid value. Note that you can also use this context parameter in the layers: section. |
${myLayer.node.index} | Resolves to the index number of the node in myLayer. The value starts at 1 and goes as high as ${myLayer.nodes.count}. |
In the templates:templateAlias: sections, you can include the following optional sections:
products
A list of IDs for the products that you want to install. You can list the product IDs using the
sagcc list repository products
content command or by selecting the
Show ID Column check box when viewing the contents of a product repository in the web user interface.
Example syntax
products:
productID:
instanceName:
configuration:
runtimeComponentID:
CONFIG-TYPE:
CONFIG-TYPE-instance1:
config_setting1: value
config_setting2: value
config_setting3: ${node.host}
config_setting4: ${node.alias}
config_setting5: ${src.node.host}
You can also use a reference variable for instanceName:
${instance.name}:
Note that when a product does not support multiple instances the instance name is default:
Based on the type of data that each configuration setting supports, you can specify the values in the configuration settings parameters in one of the following formats:
YAML
JSON
XML
multi-line plain text
variable
For details about the supported formats for each COMMON-* configuration type, see
Format of COMMON-* Configuration Types in the Template
Definition.
fixes and support patches
Use the
fixes: section to specify a list of fix names or Empower fix IDs for the fixes that you want to install. You can find the fix names, Empower fix IDs, or the exact version number of a fix using the
sagcc list repository fixes content or when viewing the contents of a fix repository in the web user interface. If you specify only fix names,
Command Central installs the latest available version of each fix and its dependencies from the fix repository defined in the template. For example:
fixes: [wMFix.Product1Fix, wMFix.Product2Fix]
You can include the exact version number of a fix in the following format wMFix.productFixID_major.minor.service.fix-build. For example:
fixes: [wMFix.Product1Fix_10.3.0.0001-0001, wMFix.Product2Fix_10.3.0.0003-0123]
You can include the Empower fix ID in the following format ProductCode_Version_Component_FixN. For example:
fixes: [Product1Code_10.3_Core_Fix1, Product2Code_10.3_Fix3]
You can include a combination of fix names (with or without the exact fix version) or Empower fix IDs. For example:
fixes: [wMFix.Product2Fix, wMFix.Product1Fix_10.3.0.0001-0001, Product2Code_10.3_Fix3]
If the fixes: list is empty, Command Central does not install any fixes:
fixes: []
The fixes: section functions differently, based on the version of the template DSL.
Template DSL version 1.0
With template DSL version 1.0, support patches are listed in the fixes: section, for example:
fixes: [wMFix.Product1Fix, wMFix.Product2Fix, patchKey1, patchKey2]
If you set the fixes: section to ALL, Command Central installs all the latest fixes required for the products in the installation:
fixes: ALL
If you include the patches: section, the template validation fails.
The following example shows how the fixes: section functions with template DSL version 1.0:
If "product1" and "product2" are not installed,
Command Central installs "product1" and "product2" from the "repoProducts" repository.
Command Central installs "wMFix.fix1_v1", "wMFix.fix2_v3", "cdkey1", and "cdkey2" with their dependencies, in the order in which they are listed, from the "repoFixes" repository .
Command Central uninstall automatically all support patches that prevent installing the fixes from the list.
Command Central creates "product2_Instance" for "product2 " (if the instance does not exist).
Command Central re-installs the fixes and patches required for the product2 instance (the fixes are installed before the patches). However, Command Central cannot uninstall the support patches that prevent re-installing the official fixes required for the product2 instance, which might cause the template execution to fail.
alias: sagTemplate
dslVersion: "1.0"
layers:
layer1:
productRepo: repoProducts
fixRepo: repoFixes
templates: template1
templates:
template1:
fixes: [wMFix.fix1_v1, wMFix.fix2_v3, cdkey1, cdkey2]
products:
product1:
product2:
product2_Instance:
Template DSL version 1.1
Important:
Beginning with template DSL version 1.1, you cannot list support patches in the fixes: section.
If you specify ALL, Command Central installs all the latest fixes required for the products defined in the inline template:
fixes: ALL
Use the patches: section to specify a list of support patches that you want to install in addition to the installed fixes. Software AG strongly recommends that you do not install support patches in a production environment.
patches: [patchKey1, patchKey2] #Support patches get installed
#in the order in which they are listed.
If the patches: list is empty, Command Central does not install support patches.
patches: []
Command Central automatically uninstalls all existing support patches that prevent the installation of fixes or support patches defined in the fixes: and patches: sections. Any other support patches that do not get in the way of installing the fixes and support patches listed in the inline template, remain unchanged.
If you specify a list of fixes: and a list of patches:, the fixes get installed before the support patches.
Examples:
In the following example:
If "product1" and "product2" are not installed,
Command Central installs "product1" and "product2" from the "repoProducts" repository.
Command Central installs "wMFix.fix1_v1", "wMFix.fix2_v3", "cdkey1", and "cdkey2" with their dependencies, in the order in which they are listed, from the "repoFixes" repository.
Command Central uninstall automatically all support patches that prevent installing the fixes from the list.
Command Central creates "product2_Instance" for "product2 " (if the instance does not exist).
Command Central re-installs the fixes and patches required for the product2 instance (the fixes are installed before the patches).
Command Central also automatically uninstalls all support patches that prevent re-installing the official fixes required for the product2 instance.
alias: sagTemplate
dslVersion: "1.1"
layers:
layer1:
productRepo: repoProducts
fixRepo: repoFixes
templates: template1
templates:
template1:
fixes: [wMFix.fix1_v1, wMFix.fix2_v3]
patches: [cdkey1, cdkey2]
products:
product1:
product2:
product2_Instance:
In the following example:
If "product1" and "product2" are not installed,
Command Central installs "product1" and "product2" from the "repoProducts" repository.
Command Central installs only the fixes in the "repoFixes" repository that are required for "product1" and "product2" (with all their dependencies), but does not install fixes for any other products that already exist in the same installation with "product1" and "product2".
Command Central creates "product2_Instance" for "product2 " (if the instance does not exist).
Command Central re-installs the fixes and patches required for the product2 instance (the fixes are installed before the patches).
Command Central also automatically uninstalls all support patches that prevent re-installing the official fixes required for the product2 instance.
alias: sagTemplate
dslVersion: "1.1"
layers:
layer1:
productRepo: repoProducts
fixRepo: repoFixes
templates: template1
templates:
template1:
fixes: ALL
patches: []
products:
product1:
product2:
product2_Instance:
When the template is executed for a second time with the same fix repository, if "repoFixes" does not include new fixes, the template does not make any changes to the installed support patches and leaves them as is. If "repoFixes" contains a new set of official fixes for "product1" and "product2" and their dependencies, the template installs this new set of fixes and uninstalls the support patches that prevent the installation of the fixes.
files
A map of files that Command Central will copy to the target installation. For example:
target/file1: “src/file”
where target is the path to the directory to which to copy the file and scr is the path to the source directory from which to get the file. The target path is always relative to the target installation directory and the source path is relative to the root folder of the composite template.
licenses
A map of license key aliases that Command Central uses to copy the license key file assigned to a specific license key alias to the target location. For example:
"target/licenseKey1": "${alias}"
where target is the path to the directory to which to copy the license key file and “alias” is the license key alias. The "${alias}" value is not case-sensitive and you can use wildcard characters, for example:
"target/licenseKey": "*_<productCode>_<majorVersion>.*_${os.platform}"
You refer to the license key file by an alias, which you can define in:
the Licensing view of the
Command Central web user interface
an environment properties file
the CLI license-tools keys commands