Suppose System A exports an object, then System B imports it and starts using it. As time goes on, System A modifies its version of the object. You can export System A's modified version of the object, then update System B's version of the object to reflect the changes made on System A. The update process preserves references to the original version of the object on System B.
These features are not available through the BMC Server Automation Console. They are available only through the BLCLI.
See the following sections for more information about updating objects:
The BLCLI update process takes information from one object (the source), and copies it into another object (the destination). This update observes the following rules:
- Objects that exist in the source object and not the destination object are recreated in the destination object.
- Objects that exist in the destination object and not the source object are removed from the destination object.
- When the value for a field differs between an object that exists in both source and destination, the value is copied from the source object to the destination object.
By the end of the update operation, the destination object's contents and the source object's contents will be identical —-- the objects will differ only in their identities (that is, DBKeys).
You can perform updates only on two objects that currently reside in the same database. This means that you need to first import a new version of the object before running the update command. For more information, see Update order of operations.
Update order of operations
To update an object on one system (System B) based on an object exported from another system (System A), use the following scripting order:
- Export the object from System A.
- Import the object on System B under a new name and/or new folder. This might require the use of an import mapping file, depending on the contents of the object. See Mapping file for additional details about using a mapping file.
- On System B, issue an update command that is appropriate for the type of object you are working with. For example, if you are working with a component template, you might use the
Template : updateByDBKeycommand; if you are working with a smart job group, you might use the
SmartJobGroup : updateByNamecommand, and so on. Your update command should specify the newly imported object as the source, and the object to be changed as the destination.
- If the merge is successful (meaning it does not break any external dependencies), the destination object is updated. At this point you can delete the source object (the one imported from System A) if you want to.
- If the merge is not successful (meaning the new data would break an external dependency), the destination object is unchanged, and the merge command fails. This occurs if the changes made in the version of the object that was exported by System A are incompatible with the current usage of the destination object on System B.
Updating component templates
Updating a component template affects the following fields:
- Primitive fields (for example, name, description, comment)
- Allowed operations
- Compliance rule groups and compliance rules
- Local properties
- Prototype property instances
- Template parts
- Discovery signatures
- Property set instance override values
You can use the following BLCLI commands to update component templates:
Template : updateByDBKey
Template : updateByName
Template : importAndUpdateByDBKey
Template : importAndUpdateByName
For information about these commands, see the documentation for the Template name space.
Updating a BLPackage affects the following fields:
- Primitive fields (for example, name, description).
- Local properties
- BLPackage items (any kind), including payloads
- Property set instance override values
Updates and payloads
Some BLPackage items have associated payloads. For example, a patch executable is the payload associated with a patch item. When you update a BLPackage, the update process ensures that:
- After the update, all BLPackage items have access to their payloads.
- All BLPackage items refer to payload files that are unique to their BLPackage, rather than shared with another BLPackage.
The update process copies the payload directory for the source BLPackage over the payload directory for the destination BLPackage. This is done in a manner that allows for the rollback of this operation should the entire update process fail.
You can use the following BLCLI commands to update BLPackages:
BlPackage : updateByDBKey
BlPackage : updateByName
BlPackage : importAndUpdateByDBKey
BlPackage : importAndUpdateByName
For information about these commands, see the documentation for the BlPackage name space.
Updating smart groups
Updating a smart group affects the following fields:
- Primitive fields (for example, name, description)
You can use the following BLCLI commands to update smart groups:
SmartComponentGroup : updateById
SmartComponentGroup : updateByName
SmartComponentGroup : importAndUpdateById
SmartComponentGroup : importAndUpdateByName
SmartDepotGroup : updateById
SmartDepotGroup : updateByName
SSmartDepotGroup : importAndUpdateById
SSmartDepotGroup : importAndUpdateByName
SSmartJobGroup : updateById
SSmartJobGroup : updateByName
SSmartJobGroup : importAndUpdateById
SSmartJobGroup : importAndUpdateByName
SSmartServerGroup : updateById
SSmartServerGroup : updateByName
SSmartServerGroup : importAndUpdateById
SSmartServerGroup : importAndUpdateByName
SSmartTemplateGroup : updateById
SSmartTemplateGroup : updateByName
SSmartTemplateGroup : importAndUpdateById
SSmartTemplateGroup : importAndUpdateByName
For information about these commands, see the documentation for the SmartComponentGroup, SmartDepotGroup, SmartJobGroup, SmartServerGroup, and SmartTemplateGroup name spaces.