You can import all of the assets in an export file or select the assets that you want to import.
When you import assets, you specify the following information:
•The assets in the export file that you want to import and the projects in which to import them.
•Whether to overwrite assets in the target project with the assets in the export file when there is a name conflict.
•Whether to merge tags when you overwrite assets in the target project.
To import an asset, you need the following privileges and permissions:
•Your user role must have privileges to import assets.
•If you import an asset into the target project as a new asset, you must have create, update, and read permissions on the asset.
•If you overwrite an asset in the target project, you must have update and read permissions on the asset.
The Import Assets page lists the assets that are in the export file. You can select which assets you want to import, and then specify which project to import the assets to. You can accept the default project, which is the same project name as the source project, or you can select a different project. If the project does not exist in the target organization, IDMC creates it.
Importing assets
Import assets from an IDMC export file.
When you import a project, you can import the entire project or import the assets that you select.
Note:
When you import a Data Quality design API, you must create a deployment with the same name as in the source system by logging into the Data Quality service.
1 Log in to the target organization.
2On the Explore page, click Import.
The Import Assets page appears.
3On the Select Import File section, navigate to the export file and click Open, or drag and drop the zip file from your saved location.
The Import Assets page lists the assets in the file.
4Optionally, change the import job name.
5Choose whether to overwrite existing assets with the assets in the import.
- If you choose to overwrite existing assets, when an asset has the same name as an asset in the target project, the asset replaces the existing asset in the target project.
- If you do not choose this option and an asset with the same name exists in the target project, the existing asset is retained.
6Select the assets to import.
If the export file contains a project and you want to import the entire project, select all of the assets. IDMC creates the project in the target organization.
7Select the target project or accept the default.
8Click Test to see the potential results of the import.
In the Select Assets area, the status for each asset shows the action that the service performs when you import the files.
9If necessary, revise your selections to resolve any issues in the test results.
10Click Import.
You can see the progress of the import on the Import tab of the My Import/Export Logs page. When the import process is complete, a message appears in Notifications. Click the link in the message to open the log details page and see the results of the import.
Note:
You can't import a policy into a different folder if a policy with the same name already exists in another folder in the target system. The policy import fails due to a naming conflict.
Asset name conflicts
You can specify how API Center handles asset name conflicts when the export file contains assets with the same name as assets in the target project. You can choose whether to overwrite the assets in the target project or use the existing assets in the target project.
To see how the import handles any asset name conflict before you start the import job, you can test the import on the Import Assets page. The import action displays in the Status column for each asset. You can filter the list of assets by asset name, asset type, or status.
Rules and guidelines for importing designed APIs
Consider the following rules and guidelines when import designed APIs:
•When you import a designed API, it is always imported in the draft state, regardless of its state in the source system. The imported designed API appears as draft in the target system.
Rules and guidelines for importing published APIs
Consider the following rules and guidelines when import published APIs:
•When you import a published API without its corresponding designed API, and the designed API is in the published state, the import fails.
You can't have a published API without a designed API, and you can't create or update a published API that is linked to a designed API in the published state. If you have updated your published API, the designed API and published API can become out of sync. API Center prevents such import to avoid showing a designed API in the published state while its corresponding published API has been updated.
•Even if your designed API and published API are in sync, you must still publish the API for the designed API to return to the published state.
Rules and guidelines for importing managed APIs
Consider the following rules and guidelines when you import managed APIs:
•After you import a managed API, you might see the Updates Available icon next to the published API name on the Managed API tab in the API Console page.
This symbol indicates that an update is available. Since API Center considers the import of a managed API to be an update, this symbol will always appear after you import a managed API.
Additionally, the update available notification can also indicate that the source published API has a new version, while the corresponding managed API is on an older version.
Click on the Actions menu of the managed API and click View Updates. You can then review the changes, if any, and click Accept to finalize the import and clear the notification.
•You can't import a managed API if its target asset is in an active, shared, or deprecated state. Any import attempt on an API in these states might cause accidental updates to a live API that customers might be using. To successfully import the managed API, you must first change its status to inactive or create. After importing the changes, you can test the API, and then set its status back to active.
•When you import a managed API, the import fails if the URL context of the managed API already exists in the target organization, even if it belongs to a different managed API. The URL context must be unique within an organization. To resolve this issue, you must change the URL context either in the source system before you export or in the target system before you import.