Import settings for InfoSphere Metadata Asset Manager
The Common Metadata Administrator sets global polices for imports on the Administration tab. These policies include rules for running express imports and for allowing duplicates.
Import settings are designed to let you establish procedures that match the needs of your enterprise. Perhaps the most important choices are whether to allow duplicates to be imported and when to require users to preview metadata during express imports.
These settings apply to all imports. There is no way to override them except by changing the settings in the Administration tab.
By default, passwords are saved in encrypted format so that the importer does not have to specify the password again for reimports, testing connections, and filtering the source metadata. You can choose not to save passwords.
If you enable additional import debugging, additional XMI information is saved. The import log, which you can download from the Summary section of the Staged Imports tab, contains a link to the XMI information.
If users delete import areas where staged imports have been shared to the repository, the history of the import is lost. But the shared metadata is not deleted from the repository.
By default imports that contain objects with invalid identities, such as names with extra whitespace or unprintable characters, can be shared to the metadata repository. You can change the default setting if you do not want to import objects with invalid identities. You can fix invalid identities before sharing.
Allowing duplicates
If an import contains duplicate assets, the duplicate assets are saved to the metadata repository by default when the import is shared. You can change the default behavior on the Import Settings page and block the sharing of imports that contain duplicate assets.
If you allow duplicate assets to be imported into the metadata repository, you can cause confusion and create a situation that is prone to error. For example, an InfoSphere® DataStage® job developer might create a table definition from a duplicate database table and use that table definition in a job. Another suite user might assign the other duplicate database table to a term, assuming it is the same database table that was referenced in the job. In addition, every time you reimport the same source, you create more duplicates.
However, there might be circumstances when you want to allow duplicate assets to be imported. For example, you might decide that the assets in your source that are duplicates are not critical to your work flow. You can find those assets and delete them later in the Repository Management tab. The alternative to importing them would be to fix them in the source, and there might be cases where that would be time-consuming. It could be more important for you to get the import completed and deal with the duplicates later.
If you choose accept the default behavior and allow duplicates during imports, be aware that every reimport of the same content increases the number of duplicates in the repository. When you allow duplicates, any duplicates in the import file are imported as separate assets. Any existing assets in the metadata repository that match the identity of the duplicate assets are unchanged by the import. For example, if two duplicate assets in the import file have the same identity as an asset already in the metadata repository, and you allow duplicates to be imported, there will be three duplicate instances of the asset in the repository after the import.
Previewing express imports
When you run an express import, the source metadata is imported to the staging area, where it is analyzed and previewed automatically. The import settings determine whether the import is shared automatically to the metadata repository or if users are required to view a preview before you manually share the import to the metadata repository.
The freedom that you give users to perform express imports should be proportional to the confidence that you have in the source metadata and in the result of sharing it to the metadata repository.
By default, users are required to preview express imports only if assets will be deleted as a result of the import. There might be cases where your importers have such thorough knowledge of the metadata in both the source and the metadata repository that you could override this default and not require a preview if assets are deleted.
By default, previews are not required if assets will be created or merged as a result of the import. Assets are frequently created in the metadata repository during import, and creating an asset does not affect the existing assets in the metadata repository. Assets are also frequently merged during reimports, often without changing existing assets. Changing the default settings creates an import work flow that is closer to a managed import but still automates the analysis and preview steps. This ensures that the importer can preview and fully understand the results of the import before sharing it to the metadata repository.
Deleting import areas that have shared imports
If a user deletes an import area where staged imports have been shared to the repository, the history of the import is lost, and all staged imports and their assets are deleted from the staging area schema. But the shared metadata is not deleted from the metadata repository.
If your priority is to create an auditable and governed environment where you can fully understand the source of the metadata in the repository, you should avoid deleting import areas that have shared imports.