CentraSite enables you to export registry objects from a registry to an archive file on the file system, and import them from the archive file into the same registry or to another instance of CentraSite.
Please note that the import/export feature is designed specifically for exporting selected objects from the registry. If you want to make a copy of an entire instance of the CentraSite registry/repository in order to move it to another machine or for disaster recovery purposes, see the section Backing up the Database in the document Maintaining CentraSite's Internal Database.
Important:
Registry objects should only be imported and exported between
CentraSite versions of the same release level; the import/export feature is
not intended for migration
purposes.
The following native CentraSite objects are objects that you can select for export:
Organizations
Note:
By exporting an organization, it is possible to export and import
the associated users, groups, roles and permissions.
Users, including the groups that contain the users
Asset Types (definitions) and Virtual Types
Taxonomies
Lifecycle Models
Design-Time Policies
Assets (instances)
Run-Time Policies
Report Templates
In addition, you can select the following asset types belonging to other components of the webMethods Suite for export:
BPM Process Project
IS Package (from the Integration Server).
Exporting/importing registry objects and repository items is done in two steps; the exported objects are first copied to an archive file (a zip file that contains the exported registry objects and repository items) and at a later stage the contents of the archive file are imported into a target registry (which may be the registry from which the objects were exported or a different one).
You can export an object using the CentraSite Control user interface, as described in Exporting and Importing Objects Using CentraSite Control, or from the command line, as described in Exporting and Importing Objects from the Command Line.
Be aware that when you export an object, CentraSite generally exports a number of additional objects besides the one you select. The specific set of objects that CentraSite exports with an object varies by object type (this topic is discussed in more detail below).
To export an object successfully, you must have view permission on the object that you select for export and all of the additional objects that CentraSite will export with that object.
After CentraSite completes the export process, it generates a report that identifies each of the objects that it attempted to export and indicates whether or not the object was exported successfully. The export report also identifies all referenced objects that were omitted from the archive file.
The following sections describe how the export process handles various aspects of an object. Review this information before exporting an object to ensure that you create an archive that can be imported successfully.
Important:
The following information reflects the behavior of the
predefined export handlers that are installed with CentraSite. If your site
uses custom export handlers, consult your administrator for information about
their behavior.
An object's ownership attributes are included with the exported object. However, this data is imported with an object only if the Keep current owner and Keep current organization options are enabled at import time. For more information about these options, see How the Import Process Assigns the Ownership of an Imported Object.
The export process does not export the instance-level permissions that are assigned to an object.
The additional objects that CentraSite includes in the archive file are determined by the specific export handler that is associated with the exported object's type. Generally speaking, CentraSite includes the following objects with any object that you export:
The supporting documents that are attached to the object.
The type definition of the object, if the object type is a custom object type or a modified predefined object type.
The taxonomy associated with the object type, if the taxonomy is a custom taxonomy or a modified predefined taxonomy.
Additionally, if the object is an instance of a composite type, CentraSite also exports the object's components (shared and non-shared) and required objects. See the document Object Type Management for a description of composite types.
For the exact set of objects that CentraSite exports for a given type of object, see Exporting and Importing Specific Object Types.
Normally, the export set for an object contains all of the objects referenced by the object (referenced standard objects such as predefined asset types are not included, since these can be expected to exist on the target machine). Nevertheless, you might want to examine the export report for warnings. If there are warnings and they identify objects that will not be present in the target registry at import time (usually indicated by a INMIEW0038 warning in the report), you must do one of the following:
Export the referenced objects separately and import them into the target registry before you import the archive file that you just created.
—OR—
Use the Add to List command to build a list that includes the object that you want to export and all of the objects that are identified by the INMIEW0038 warnings. Then, export the list. Doing this will produce an archive file that contains the object that you want to export plus all of the objects that it references. See the section "Using the CentraSite Control User Interface " in the document Logging On and Using the CentraSite UIs and APIs for information about working with lists.
CentraSite does not automatically export the custom association type definitions for objects that contain custom associations. If you export an object that is related to another object through a custom association, CentraSite will export the related object, but will not export the type object that defines the custom association. If that type definition does not exist on the target registry, you must import it beforehand or include it in the archive file with the object that contains the custom association. For ways to do this, see Objects that CentraSite Does Not Include when it Exports an Object.
When you export an asset, all of the asset's supporting documents are exported with the asset.
Note:
The export feature does not provide a way to export supporting
documents or other repository items directly. However you can use the
Download button on the Supporting Document Library page to
download documents from one instance of CentraSite and then upload them to
another.
If you export an asset that is versioned, the exported asset will include a reference to the previous version of the asset. However, the referenced version itself will not be included in the archive. Unless the referenced version exists on the target machine or you create an archive that includes the referenced version of the asset, the reference is removed on import.
CentraSite does not restrict the transfer of objects between different product versions. However, if for example a user-defined type is exported and already exists on the target machine, the import will fail if the existing type already has instances and the modification of the type due to the different product version is such that the existing instances do not validate with the type any longer. Typically, enhancements of the type with additional fields do not cause any problems, but modification of existing fields may lead to unexpected results.
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.
For more information about permissions, see the document Users, Groups, Roles, and Permissions.
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; for more information on UUIDs see Understanding Object Identity.
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. For more information see What Happens When an Imported Object Already Exists in the Target Registry?.
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.
Each registry object is identified by its own unique Universally Unique Identifier (UUID). CentraSite assigns a UUID to an object when it adds the object to the registry. After an object is created, its UUID cannot be changed.
You will sometimes see an object's UUID displayed in the user
interface. When the UUID is shown for an object, it appears in the object's
Key attribute, and it looks something like this:
uddi:2d621948-89f3-11df-851c-a3fb7c9c098e.
During an import/export process the importer uses the UUID to determine whether an imported object already exists in the target registry. If an identical object (i.e., 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. For more information, see What Happens When an Imported Object Already Exists in the Target Registry?.
When the user attempts to import an archive and the importer determines that an object in the archive file already exists in the registry, there are different ways for the importer to react, depending on the timestamps of the objects:
The imported object has a newer timestamp than the existing one. The existing object is replaced and the import executes successfully.
The timestamps are identical. The object is ignored and the import executes successfully.
The imported object has an older timestamp than the existing one. The object is rejected, but this does not cause the import process to fail.
If the Allow replace of registry objects option has been set in the import dialog, the existing object will be overwritten automatically even if the imported object is older than the object in the target registry. This may be a potential source of problems, because all objects in the registry depending on it will be affected as well.
If you intend to use this functionality to transfer objects between instances of CentraSite, make sure that the system clocks on all of the involved servers are synchronized.
The organizational and user ownership information for an exported object is present in the archive file. However, how ownership is assigned to the imported object is determined by 1) whether the object is added to the target registry as a new object or replaces an existing object and 2) whether the Keep current owner option is set.
If the imported object replaces an existing object in the registry, the existing object is replaced, but its Owner and Organization attributes remain unchanged (i.e., the updated object belongs to the same organization and user as it did before it was replaced by the copy from the archive file).
If the imported object is added to the registry as a new object, its organizational and user ownership is determined by the following parameters:
If Keep current owner is set in the import dialog, and the original owner exists with the same UUID on the target, the objects will belong to that user after import; if the user with the same UUID does not exist on the target, the import fails.
If Keep current owner is not set in the import dialog, the importing user will be the owner of the object.
If Keep current organization is set in the import dialog, the original associations of the objects are maintained if the organization exists with the same UUID on the target; if the organization with the same UUID does not exist on the target, the import will fail.
If an object to be imported contains a reference to another object, the importer determines whether the referenced object is contained in the archive file or present in the registry. If the referenced object is present in the archive file, the importer will import it as necessary to resolve the reference.
If the referenced object is not present 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 checks 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 you mark the checkbox, the lifecycle state of each imported asset will be 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 will be 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.
Important:
If the object you are importing was exported from an instance
of CentraSite that has assigned a "stage" to the object's lifecycle state,
the object can only be imported to the registry whose address is specified in
that stage. For more information about stages, see
Promotion.
When the import process adds a new object to the registry, CentraSite will apply relevant PreCreate and PostCreate policies in the same way as if you had created the object manually.
If the import process replaces an existing object in the registry, CentraSite will likewise trigger the applicable PreUpdate and PostUpdate policies.
Note, however, that these policies are not activated when a complete organization is imported.
For more information on Policies, see the document Working with Design/Change-Time Policies.
CentraSite supports configurations where different CentraSite instances are used to represent lifecycle stages or usages. So CentraSite could for example be set up with two instances 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. For more information on lifecycle models, see the section Choosing a Deployment Strategy in the document CentraSite Implementation Concepts.
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 (and optionally deleted) 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; attempting to import it into any other target will subsequently fail.
On import, the registry object keeps its lifecycle state if its lifecycle model is available in the target registry; if the model does not exist, the object is set to the initial state in the default lifecycle model.
