Import Options

The following import options are available in the build.properties file located in the root directory of exported archive. You can edit these import options before running the import.

import.treatment.for.existing.objects

During import if import process finds an object with the same name on the target ActiveMatrix Administrator, the action to be taken is decided by this property. This option applies to all data objects which are being imported. Possible values are skip, merge, and overwrite. Default value is 'skip'.

  • skip — If object already exists in target system, the existing object is NOT be updated. But if it does not exist in the target system, the exported object is created in the target system.
  • merge — If object already exists in the target system, the existing object is updated in a non-destructive fashion (that is, the export script only handles objects in the data file). If it does not exist in the target system, the exported object is created in the target system.

    For example, if there are three enterprises level substitution variables named 'datacenter_jdbc_port', 'datacenter_jdbc_host', and 'datacenter_jdbc_type' in target system. The data file has two enterprise level substitution variables named ‘datacenter_jdbc_port ' and ‘datacenter_jdbc_user’. The 'merge' import option:

    1. Updates value of 'datacenter_jdbc_port'

    2. Adds the new substitution variable ‘datacenter_jdbc_user’

    3. Remaining substitution variables ‘datacenter_jdbc_host’ and ‘datacenter_jdbc_type’ are not touched.

  • overwrite — For most types of objects, the 'overwrite' import option behaves the same as 'merge' import option. For a few objects such as SVARs, Loggers, and so on, this option behaves differently and is explained in the following example:

    If there are three enterprise level substitution variables named 'datacenter_jdbc_port', 'datacenter_jdbc_host', and 'datacenter_jdbc_type' in the target system. The data file has three enterprise level substitution variables named 'datacenter_jdbc_port', 'datacenter_jdbc_host', and 'datacenter_jdbc_user '.

    The 'overwrite' import option:

    1. Updates values of 'datacenter_jdbc_port' and 'datacenter_jdbc_host'
    2. Deletes 'datacenter_jdbc_type’ from target system, as it is not there is data file.
    3. Adds the new 'datacenter_jdbc_user ' to target system.

import.upgrade.apps

This option, if specified, applies to all applications. Possible values are true and false. Default is false.

During application creation, if the same application (same name and same application template version) is found on target ActiveMatrix Administrator, the action to be taken is decided by this option.

By default, since the value of this property is set to false, import does not try to upgrade application. In case application name and template version are different, creation errors out. In that case, you have two choices - either handle the error manually (log-in to ActiveMatrix Administrator and pick the correct version application and so on) or re-run import by setting this property to true. If you set this property to true, the value of import.treatment.for.existing.objects needs be ‘merge’.

Note: Both the above import options apply only to “create” target.

import.use.force

This option is standard AMXAdminTask attribute "force". You should exercise extreme caution when using this option as it may leave your system in a non-working state). Possible values are true and false. Default is false.

Setting value to true forces an action even if the object has dependent objects or is not in the appropriate state. Applies to the following actions and objects:

  • delete - Node, Application, Environment, ResourceTemplate, ResourceInstance
  • undeploy - Application
  • stop - Application, Component, Binding
  • uninstall - Node, ResourceInstance
For example:
  • A node must be in the uninstalled state before it can be deleted and it must be stopped before it can be uninstalled. If any problems occur moving the node to one of these states, and force is true, the node is deleted even if it is not in the uninstalled state or uninstalled even if it is not stopped.
  • An application must be in the undeployed state before it can be deleted and it must be stopped before it can be undeployed. If any problems occur moving the application to one of these states, and force is true, the application is deleted even if it is not in the undeployed state.