You import an object by importing the archive file to which it was previously exported. You can import an object into the same CentraSite registry from which it was originally exported or to a different CentraSite registry. The Import dialog displays the contents of the archive to be imported and you can select either the entire archive or just a subset of the objects to import.

To import an object, you must have permissions to create that object in the target registry. If the object that is to be imported already exists in the target registry, you must have permission to edit the existing object. If you attempt to import an object but do not have the proper permissions, the particular objects is ignored during the import process.

To import object types, you must have the Asset Type Administrator role. To import organizations or users, you must have the CentraSite Administrator role. When an archive is imported, the importer reads the contents of the archive file and either adds its contents to the target registry (if the object does not already exist) or replaces existing objects with the objects from the archive. The importer verifies the object's Universally Unique Identifier (UUID) to determine whether it already exists. An object is ignored when the same object with an identical timestamp already exists. If objects are identical and the object to be imported has an older timestamp than the one in the registry, the import is rejected unless the Allow replace of registry objects option is used.

If you set the Keep current owner option in the Import dialog and the original owner exists on the target machine, the assets belongs to that user after import. As a further requirement, this user on the target machine must have the same UUID as the original owner. If this user does not exist on the target, the import fails. The Keep current owner option is disregarded if a conflicting user is ignored at import. In this case, the import succeeds and the objects belongs to the importing user.

If you set the Allow replace of registry objects option in the Import dialog, the imported object overwrites the existing object even if it is older than the object in the target registry.

If you set the Import groups that the user belongs to option in the Import dialog, the importer contains the user to be imported and the groups that the user belongs to. This applies only to user-defined groups. The system-defined groups are not imported.

Each registry object is identified by its unique UUID. CentraSite assigns UUID to an object when it adds the object to the registry. After an object is created, its UUID cannot be changed. You may see an object's UUID displayed in the user interface. When the UUID is displayed for an object, it appears in the object's Key attribute. Example of UUID: uddi:2d621948-89f3-11df-851c-a3fb7c9c098e.

During an export or import process the importer uses the UUID to determine whether an imported object already exists in the target registry. If an identical object (an object with an identical UUID) already exists in the target registry, the timestamps of both the existing object and that to be imported determine whether and in which way the importing process continues.

When a user imports an archive and determines that an object in the archive file already exists in the registry, then depending on the timestamps of the objects:

If an object to be imported contains a reference to another object, the importer determines whether the referenced object is available in the archive file or in the registry. If the referenced object is available in the archive file, the importer imports it as necessary to resolve the reference. If the referenced object is not available in the archive file or the target registry, the object containing the reference is not imported.

If an object to be imported includes state information, the importer verifies whether a lifecycle model containing the specified state exists on the target registry. The option Keep lifecycle state in the Import dialog determines whether the lifecycle state of assets in the archive should be preserved during the import. If this checkbox is marked, the lifecycle state of each imported asset is set to the same value as the asset's lifecycle state in the archive being imported. This operation is available when the lifecycle model itself is in the productive or retired state.

This operation is only possible for any given asset if the lifecycle model governing the imported asset contains the same lifecycle state as the state in which the asset was originally exported to the archive. If the lifecycle model for the imported asset does not contain the same state as the state of the asset in the archive, the state of the imported asset is set to the initial state of the lifecycle model that governs the imported asset.

If the target registry has no lifecycle model for the type of object that you are importing, the imported object's lifecycle state information, if present in the archive file, is ignored.

If the target registry uses a different lifecycle model than the one used by the imported object, the object's lifecycle state information, if present in the archive file, is ignored and the object enters the initial state of the lifecycle model that is in effect for its type on the target registry.

When the import process adds a new object to the registry, CentraSite applies relevant PreCreate and PostCreate policies. If the import process replaces an existing object in the registry, CentraSite triggers the applicable PreUpdate and PostUpdate policies.

If an object has multiple versions, on export only the selected objects are exported and not the entire version path. On import of a versioned object CentraSite checks whether a next lower version number is present in the target registry. If there is a lower version number, the version relationship is retained. Otherwise the object is imported but does not take part of a version path.

CentraSite supports configurations where different CentraSite instances are used to represent lifecycle stages or usages. For example, CentraSite can be set up with two instances such as development and production to represent the different phases in a software development lifecycle. It could also be set up with instances differentiating between asset creation and asset consumption aspects.

Promotion refers to the capability to copy an asset, a lifecycle model, or a policy from one lifecycle stage to another. This is done by exporting the object from its current registry and importing it into the registry that hosts the next phase of its lifecycle.

A stage definition in CentraSite is managed by a lifecycle stage object which describes a CentraSite instance by name and configuration information. Those stages are assigned to lifecycle model states to define the allowed promotion paths for objects in a certain lifecycle state. To promote an object from one lifecycle stage to another, the object is exported from the source registry and then imported in the target registry.

When any object from the source registry is in an end state, one or more registries can be defined to which the object can be imported. An attempt to import it into any other target subsequently fails. While importing, the registry object retains its lifecycle state if its lifecycle model is available in the target registry. If the model is unavailable, the object is set to the initial state in the default lifecycle model.