Command Central 10.5 | Using Composite Templates | Understanding the Composite Template Definition | Migration
 
Migration
You can define an optional migration section in which you specify custom options and migration details for an environment. When you do not include a migration section in a composite template that you intend to use to migrate an environment, Command Central uses the default migration settings as described in How Command Central Processes a Composite Template for Installations of Release 10.3 or Higher. However, when you want to use a composite template for migration, you must always include the Provision section.
The migration section can include one or more of the following sections:
sourceType
Specifies whether to migrate an environment from an existing archive of the source nodes or directly from the source nodes included in the migration/nodes section. If you do not include this parameter or set the value to NODES, Command Central ignores the migration/archives section. If you set the value to ARCHIVES, Command Central ignores the migration/nodes section. The default is NODES.
Syntax:
sourceType: [ARCHIVES|NODES]
archives
Specifies the location of an existing archive of the source nodes. Note that Command Central ignores this section when sourceType: NODES and uses the node details in the migration/nodes section instead. By default, Command Central searches for the source archive on the Command Central host, in CommandCentral_directory/profiles/CCE/data/migration/source/nodeAlias.zip. If Command Central does not find the archive on its own host, it searches on the target host, in user.home/migration_source_nodeAlias.zip.
Syntax:
sourceType: ARCHIVES
archives:
targetPath: path/to/source_archive.zip
options
Migration options to prepare the source nodes for migration. Following is a list of the options that you can customize:
*snapshot
Creates a template with products, fixes, configuration, and files from each source node. The template does not include product instances. The product instances are created by the product migration utilities. The default is false.
Syntax:
snapshot:
  execute: {true | false}
*pause
Pauses all source run-time components. The default value is true.
Syntax:
pause:
  execute: {true | false}
Note:
Command Central requests of all run-time components to pause, but a component processes this request only when it supports the pause operation. For example, Integration Server goes into Quiesce mode, instead of pausing.
*shutdown
Stops all source run-time components. This option also shuts down Platform Manager by running the shutdown.sh/bat script remotely through the remoteAccess service. 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, the default value is true.
Important:
To execute the shut-down operation successfully, Command Central must access the remote operating system through an SSH connection.
Syntax:
shutdown:
  execute: {true | false}
*backup
Creates a backup of the source installation directory on the same host machine and transfers the backup archive to Command Central. Note that this step is skipped automatically when migrating on the same host. The backup operation is executed only when you set execute=true, which is the default value. The output of the backup operation is an archive.
Important:
To execute the back-up operation successfully, Command Central must access the remote operating system through an SSH connection.
When migrating to a different host, in the sourcePath parameter you specify the location in which to create an archive of the installation on the source node and in the targetPath parameter - the location to which to transfer the archive on the target node.
If you do not specify a value for sourcePath or targetPath, Command Central uses as default location:
user.home/nodeAlias
where user.home is the home directory of the user on the source or target machine respectively and nodeAlias is the alias of the source installation.
To specify which files to exclude from the backup, use the excludes option.
You can select which file types and file directories to exclude from the source archive in a more granular way, using the optional patterns and except parameters. For example, you can use these parameters when you want to reduce the size of the source archive, but still include required files when migrating to a new host. The patterns parameter specifies which file types and file directories to exclude from the source archive. The default value for patterns is [“*.log”], which means that by default only log files are excluded from the source archive. The except parameter includes a list of file names that are exceptions. The files listed in this parameter are included in the source archive, even when their file type is listed in the patterns parameter. For example, in the following template snippet, all jar files will get excluded from the source archive, except for the "wm-caf-server.jar" file:
migration:
options:
backup:

excludes:
patterns: ["*.log", "*.jar", "*.zip"]
except: ["wm-caf-server.jar"]
Syntax:
backup:
  execute: {true | false}
sourcePath: user.home/nodeAlias
targetPath: user.home/nodeAlias
  excludes:
patterns:  [“*.log”,“*.jar”,“*.zip”,“path/to/directory/to/exclude/*”]
except: [list-of-file-names-excepted-from-patterns]
*rename
Renames the source installation directory to migration_source_installDir, where installDir is the name of the source installation directory. The rename operation is executed only when migrating on the same host and installation directory (overinstall) or if you set execute=true.
Syntax:
rename:
  execute: {true | false}
  targetPath: <the path goes here>
  migration_source_installDir
source
A list of the source nodes that host each layer. The source nodes are defined in source/environment.type/layerAlias sections. For example, the source nodes for an “is” layer in a “cluster” environment are defined in the migration/source/cluster/is section.
nodes
Details about the source nodes, such as host, port, and bootstrap information. Note that Command Central ignores this section when sourceType: ARCHIVES and uses the source node archive specified in the migration/archives section instead.
Example
In the following composite template snippet, the “cluster” environment has a single “is” layer. The target migration nodes are identified from the “provision/cluster/is” section and the source migration nodes from the “migration/source/cluster/is” section. The source and target nodes use the same “is1” and “is2” hosts. Because the “migration/nodes” section does not have any properties, the source nodes map to the Platform Manager port “8093” and the “/opt/sag/test” installation directory, defined in the nodes/default section. The migrate operation creates a template with the products, fixes, configuration, and files for each source node, but does not create a backup archive. All run-time components, including Platform Manager are shut down before starting the migration process and the source installation directory is renamed to “migration_source_cc910”.
environments:
    default:
      cc.installer: ${}
install.dir: /opt/sag/test
      db.url: “jdbc:wm:sqlserver://dbhost1:1433;databaseName=db1”
      db.username: user1
      db.password: pass1
    cluster:
      is.hosts: [is1,is2]
     
layers:
    default:
      productRepo: webMethods-9.10-mirror
      fixRepo: Empower-9.10-mirror
    is:
      templates: [spm-tuneup,is-server]
    
templates:
    spm-tuneup:
      fixes: [wMFix.SPM.Core,wMFix.PIEspm]
    is-server:
      fixes: [wMFix.integrationServer.Core]
      products:
        integrationServer:
          is_inst1:
           primary.port: 5555
           db.url: ${db.url}
           db-username: ${db.username}
           db-password: ${db.password}
    
migration:
    options:
      snapshot:
        execute: true
      pause:
        execute: true
      backup:
        execute: true
        excludes: [“*.jar”,“*.log”]
      shutdown:
        execute: true
      rename:
        targetPath: /opt/sag/cc910
    source:
      cluster:
        is: [is1,is2]
    nodes:
    
provision:
    cluster:
      is: [is1,is2]
    
nodes:
    default:
      default:
        port: 8093
        secure: true
        bootstrapInfo:
          installer: ${cc.installer}
          installDir: ${install.dir}
Specifying Product Migration Settings In a Properties File
You can also include the migration settings in a properties file, named in the following format:
migrate_srcVersion-destVersion_sbs.dat
for example, migrate_9.12.0-10.1.0_sbs.dat
Add the .dat files in the composite template archive in the migration/productId directory.
If an inline template defined in the composite template includes only the product, but does not define any instances for that product, the settings in the .dat file under the directory with this product ID are applied for the product, but not for specific instances of the product. If the inline template includes the product and its instances, the settings in the .dat file for this product ID are applied for all instances defined for that product in the inline template.
Important:
Note that on the Platform Manager side, the custom migration settings will be ignored if the migration source and target versions are different from the versions specified in the name of the custom migration settings file.
Example
In the following example, the product with ID “MwsProgramFiles” has a single instance with name “mws_inst1”. To use custom migration settings for “mws_inst1”, create a properties file with name “migrate_9.12.0-10.1.0_sbs.dat” in the migration/MwsProgramFiles directory. When applying the composite template, the custom migration settings from the file are applied for the “mws_inst1”.
templates
    mws-server:
      fixes:
      products:
        MwsProgramFiles:
         mws_inst1:
          http.port: 8585
          db.url: ${db.url}
          db.username: ${db.username}
          db.password: ${db.password}