CentraSite Documentation : CentraSite Administrator’s Guide : Importing/Exporting Registry Objects : Introduction : Overview of the Export/Import Process : Importing an Object
Importing an Object
 
Understanding Object Identity
What Happens When an Imported Object Already Exists in the Target Registry?
How the Import Process Assigns the Ownership of an Imported Object
How Referenced Objects Are Handled During Import
How Lifecycle State Is Handled During Import
What Policies Are Triggered During an Import
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.
Note:  
If the archive contains a registry object with references which cannot be satisfied during import, the import process will continue but this object is not imported.
To import an object, you must have permissions to create that type of 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 import process will fail.
To import object types, you should have the role Asset Type Administrator. To import organizations or users, you must have the role CentraSite Administrator. Without that role, the importing of user-defined types will fail.
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 checks the object's 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 but the object to be imported has an older timestamp than the one in the registry, the import is rejected.
In the import dialog you can use the option Assign new organization to select a new organization into which the objects will be imported, or you can retain the original organization, in which case the original associations of the assets are maintained if the organization is available on the target; if the organization does not exist on the target, the import will fail and the importer log will record this fact.
In some cases, the original organization will be preserved during import even if you have selected a specific organization in this field. This happens if the object to be imported is any of the following:
*an organization
*a system-wide lifecycle model
*a system-wide policy
Asset types are not owned by any organization, so selecting an organization for such objects has no effect.
If you set the Allow replace of registry objects option in the import dialog, the imported object will overwrite the existing object even if it is older than the object in the target registry.
If you set the option Keep current owner in the import dialog and the original owner exists on the target machine, the assets will belong 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 will fail and the importer log will record this fact. The Keep current owner option will be disregarded if a conflicting user is ignored at import; in that case the import will succeed and the objects will belong to the importing user.
Copyright © Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback