How Command Central Processes a Composite Template
Command Central applies a composite template based on the processing mode specified in the
environment.mode= {provision | migration} argument of the
sagcc exec templates composite apply command. When you execute the apply command without including the
environment.mode argument, the default mode is
provision. During the template application process, some steps are executed only in
migration mode.
Command Central performs the following tasks during the application of a composite template.
Step 1
Validates the composite template, as described in the
Validating a Composite Template topic.
Step 2
Processes the layers in the source environment. This step applies only when the environment.mode argument of the apply composite template command is set to environment.mode=migration. Command Central prepares the source environment for migration.
The layers are processed one at a time, starting from the first layer defined in the template and going down the list of layers. For example if the layers section defines um, is, and mws layers, the processing starts with the um layer. Command Central goes through the following processing steps for each layer in turn:
1. Identifies the target set of nodes from the provision/environment.type/layerAlias section of the template definition.
2. Identifies the source nodes from the migration/source/environment.type section. If the source nodes are not defined in this section, by default Command Central uses the same set of nodes as both source and target nodes.
Note: When the template included a migration/source/default section, but does not have migration/source/environment.type sections, if evironment.type sections exist for the target nodes, the template will again use the properties defined for the target nodes, instead of the migration/source/default properties.
3. Identifies the host, port, and installation directory of the source nodes from the migration/nodes/environment.type/node.alias section. If no properties are specified in the node.alias section, Command Central uses the values for host, port, and installation directory specified for the target nodes in the top level nodes section.
4. Prepares each source node for migration. By default, the following processing steps are executed in parallel for all source nodes:
Tip: You can customize the migration settings in the migration/options section.
Processing step | Description |
1 | Create a template with products, fixes, configuration, and files from each source node. |
2 | PAUSE all run-time components:  If the PAUSE operation is not supported, the run-time component returns an error, which is ignored. If the PAUSE operation is successful, Command Central waits for the run-time component to report PAUSED status. |
3 | Shut down all run-time components, including Platform Manager. Note that you can set the shutdown option to false only when migrating to a different host on a Unix operating system. For all other types of migration, this option is set to true. |
4 | Rename the source installation directory to migration_source_installDir when migrating on the same host and installation directory. |
At the end of the source environment processing step, each layer has a template.
Step 3
Bootstraps Platform Manager on the target nodes.
The bootstrap operation is executed for all layers and runs in parallel on all target nodes. The target set of nodes is identified from the provisioning/environment.type sections.
At the end of the bootstrap processing step, Platform Manager is installed on all target nodes.
Step 4
Provisions or migrates all layers to the target nodes.
The layers are processed one at a time, starting from the first layer defined in the template and going down the list of layers. For example if the layers section defines is, mws, and um layers, the processing starts with the is layer. Command Central goes through the following processing sub-steps for each layer in turn:
1. Applies each layer on the target nodes to which the layer maps in the provision section. The nodes get processed one node at a time. Command Central maps the source nodes to the target nodes using the node alias.
2. Applies the inline templates listed for each layer.
At the end of the layers processing step, each layer is applied on the specified target nodes.
Step 5
Installs products and fixes from the inline templates defined in the composite template as follows:
1. Install products, including the Platform Manager product plug-ins.
2. Install all current fixes for the installed products and plug-ins.
At the end of the product and fixes provisioning step, the products and fixes included in the templates are installed on the target nodes.
Step 6
Creates, updates, or migrates the product instances from the templates defined in the composite template.
When Command Central migrates the environment, each product instance is migrated using the migration utility of the product as follows:
1. The instance_name parameter from the template is passed to the product migration API as - instanceName ${instance.name} parameter.
2. The versions of the migration source and target installations are passed to the product migration API as -srcVersion and -destVersion parameters when required.
3. The db.url, db.username, and db.password parameters are passed to the product migration API as -cloneDbUrl, -cloneDbUser, and -cloneDbPassword.
If the template includes custom migrate-xxx-yyy-sbs.dat migration settings files, the files are passed to the migration utility as -importFile parameter.
For detailed information about the product migration utilities, see Upgrading Software AG Products.
Step 7
Processes files that are defined inline and applies configuration settings.
Step 8
Restarts the product instances.