Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
Downloads

Import Content

Content exchange is an experimental feature: it is currently available only in selected environments and might change in future releases.

Import a content package that another environment has published to this environment. This is the final stage of content exchange: the import creates or updates the promoted assets in the target environment.

How the import applies assets

Assets are matched by their identifiers, not by their names or values. This applies to metadata, such as table and attribute definitions, and to the records themselves. Because a content package carries the identifiers of everything it contains, they are preserved across environments. See How assets are matched.

If an asset fails, the import continues but reports as Failed. The other assets are still applied, except the ones that depend on the failed asset. Fix the cause and run the import again: assets that were already applied are recognized on the next run, so re-importing a Published package doesn’t duplicate them.

Re-importing a package in the Draft mode

In the Draft mode, a package can be imported only once per table. The first import leaves its changes staged for review. A second run finds those staged changes pending and fails.

Publish or discard the staged result of the first import before you run the import again.

Target environment permissions for reference data assets

The import applies changes under your user account, so the same reference data permissions apply:

  • To change a table’s structure, you need the Owner role for that table.

  • To publish data, you need the Approver role or higher.

Roles are assigned per table, so they apply only to tables that already exist in the target environment. Tables that the package creates are new and have no role assignments yet.

See Roles.

Prerequisites

  • Review how content exchange works.

  • You have the contentorchestrator-import-promotion-operator identity provider role.

  • You have sufficient permissions for the imported assets in the target environment. See Target environment permissions for reference data assets.

  • In the target environment, the source environment is added with its domain and API client credentials, which are needed to download the package. See Add environments.

  • You have exported and published the content package you want to import. See Export and Publish Content.

  • The tables whose structure the package changes have no pending schema changes in the target environment: publish or discard them first. The import stages its own changes in the same schema editor, so any pending change there, including a reordered column, makes the table fail.

  • The records that the package adds are not already pending in the target table. Other pending records don’t block the import.

  • Tables and relationships the exported assets depend on but that are not present in the package (for example, tables referenced by the imported data or used by an imported hierarchy) exist and are published in the target environment.

Import a package

To import a published package:

  1. Go to Global settings > Content exchange > Imports.

    To access Global settings, select the Ataccama logo.

  2. Select New import > Another environment.

  3. In Available packages, select the package to import. Packages not yet imported into this environment are marked as Pending.

    Each package shows its source environment and when and by whom it was published.

  4. Select Next.

    The package is downloaded from the source environment, and a read-only preview opens, showing the included assets and apply settings.

  5. Review the import and select Import to apply the assets to this environment.

Track the progress on the Recent imports tab. For details about what each status means, see Import statuses.

Import statuses

The Recent imports tab shows each import with its current status:

  • Importing: The assets from the package are being applied to this environment.

  • Finishing: The import succeeded and its temporary data is being cleaned up.

  • Imported: The import finished and no asset failed.

  • Failed: At least one asset failed. See Troubleshoot reference data imports.

A failed import is not undone. Assets are applied one by one as the import runs, and published data can’t be withdrawn. To recover, fix the cause and run the import again.

Troubleshoot reference data imports

Expand a failed import on the Recent imports tab to see which assets failed and why. Some problems don’t fail the import and only show up in the data afterwards, so this section covers those too.

Before you run any import again in the Draft mode, publish or discard what the previous run staged. See Re-importing a package in the Draft mode.

Table fails because of pending changes

The table has pending changes in the target environment that the import can’t work around:

  • A pending schema change, such as an added, renamed, or reordered column. The import stages its own structure changes in the same schema editor, and publishing them would publish the pending change as well.

  • A pending record that the package also adds.

Publish or discard these changes and then run the import again. Other pending records in the table are not a problem: the import publishes only the records it wrote itself.

Referenced table is missing or unpublished

The package relies on a table that is not part of the package and either doesn’t exist in the target environment or exists only as a draft.

Create or publish the missing table (or import it first in a separate promotion), then run the import again.

Reference values are empty after the import

Referencing columns are resolved against the referenced table by value, and the values have to match exactly. Matching is case sensitive and doesn’t trim spaces, so a value in the referenced table of the target environment isn’t matched if it was entered with different capitalization or extra spaces. Records whose values have no match are imported with an empty reference cell instead of failing the import.

Check the referenced table for missing records, add them, and re-import or correct the affected records.

Reference values point to the wrong record

A referencing value is matched against the referenced column, and that column isn’t required to hold unique values. If the same value appears in several records of the referenced table, the incoming record is linked to one of them, and there is no guarantee which one.

Make sure the values in the referenced column are unique before you promote data that points to it.

Records are duplicated after the import

Records are matched by their internal identifiers, not by their values. A record gets its identifier from the environment that creates it, so records created in the target environment, for example by uploading the same file in each environment, have different identifiers than the ones in the package. The incoming records then match none of the existing ones, so the import adds them as duplicates.

Remove the duplicates from the target table and keep subsequent promotions one-directional: change and promote data only in the source environment.

Effective dates configuration doesn’t match

Once effective dates are enabled on a table, their structural settings (that is, the grouping key and the validity attributes) cannot be changed. If the incoming table structure defines them differently, the effective dates of that table fail to import. The structure and records of the table can still be applied, so the table ends up partially updated.

Align the effective dates configuration of the two environments manually before promoting the table again.

Records with effective dates are rejected

The records the import adds are checked against the effective dates of the target table. The check fails if a record has an empty validity date, or if it overlaps with another record that has the same grouping key. The effective dates of the table then fail to import.

This happens when the package doesn’t reflect the state of the target table:

  • Effective dates are enabled on the table in the target environment but not in the source environment, so the package carries no validity dates.

  • The incoming records overlap with records that are already in the target table and are not part of the package.

Enable effective dates in both environments or correct the overlapping records, then import the package again.

An asset was not applied although the import succeeded

An asset that can’t be applied but doesn’t fail the import is left out of the import result. The import reports as Imported and the asset is silently missing. This happens when:

  • The package carries data for a table whose structure it doesn’t include, and the table doesn’t exist in the target environment. Promote the structure of the table first.

  • The package carries data for a column that doesn’t exist in the target environment. Promote the structure of the table first.

  • In the Draft mode, a relationship points to a column that the same import only staged. Publish the referenced table, then import the package again.

  • The same relationship already exists in the target environment between the same two columns. There is nothing to apply, but the relationship in the target environment keeps its own identifier, so the same result repeats on every import.

  • A hierarchy depends on a table that the import didn’t apply. Fix the table first, then import the package again.

Compare the imported tables against the source environment to confirm what was applied.

Was this page useful?