The migration process is the phase in which for the entries selected (via the selection screen) in the migration table, content is READ from the source type (ArchiveLink content server, Gimmal Link Enterprise ECM endpoint, data file, or SAP DB) and created in the target system (ArchiveLink content server, Gimmal Link ECM endpoint, or SAP DB).

This process uses all the input criteria available for selection parameters.

Below is a description of your migration options.

This option allows you preserver the source SAPDocID (ie: <link table>-arc_doc_id. This should only be done if required by another 3rd party or other dependency.

This option is only available for ECM target endpoints.

This option will check if a other migration entries exist for the the same:

This is only valid if you have an artifact assigned to more than 1 SAP record.

If you know or are unsure if you have 1 to many linkages, this option is safe to choose. There is no harm in choosing this option however it comes with decreased performance as each entry, before it migrated, reads the entire migration table to see if an entry with the same source repository ID/document ID has been migrated.

If it finds an entry that is migrated, it does not "re-migrate" the document. Instead, it preserves the 1 to <n> multiple link entries and simply creates the appropriate ArchiveLink link and marks the entry as migrated.

Additional note: if you have or suspect multiple links, it is safest to choose single stream processing (For more information on these consideration, refer to the section/node "Migration Concepts and Strategies - Box" below). In theory, if parallel batches contain entries of the same source repository ID/document ID combination, and if they are attempted to be migrated at the same time, duplicate documents in your document repository could occur. This is the worst case. The migration will still be valid.

This option allows you to override the RFC that the DocManager rule for the target entry will determine. If this is shared with day-to-day Gimmal Link Enterprise processing, it is highly recommended to have a dedicated RFC (and migration Gimmal Link connector) to migration only. For more information on these considerations, refer to the section/node "Migration Concepts and Strategies - Box" below.

This option allows you to force a source repository ID different than the source repository ID in the load table.

Should be used for unique testing in non-production systems only and should only be used if required.

This option allows you to force a unique filename in the target content repository, and in some cases (such as Box), this is mandatory to prevent versioning.

The target filename will have the format <original filename>_<unique SAP UUID>.<original file extension>

This option allows you to identify a list of special characters all in a sequence (eg: %, or %`@) and have them replaced by a space.

Get/Map Source Metadata to Target Metadata

If the source is a Gimmal Link Enterprise ECM endpoint - metadata can be read from the source and moved along with the content to the migrated. This requires the DocMigrator configuration described above "Source Metadata Mapping". Only properties configured will be transferred.

You can make source metadata mandatory, in which case the entry will be flagged with an error if not found.

Enhance/Compile New Target Metadata

If the source does not support metadata, metadata can still be added to the content being migrated via DocManager, OR in addition to. This metadata can come from any available dataset since you can create an ABAP class-method to compile that metadata, thus you have full control. Of course, you can also add SAP metadata code free using the metadata map option in DocManager.

You can make New Target metadata mandatory, in which case the entry will be flagged with an error if not found or compiled via the found DocManager rule.

*If both sources of metadata are leveraged, the metadata compiled by DocManager will override any metadata with duplicate target property names.

Validate Only / Store Content

You can choose to run a validation run only to ensure your configuration and metadata options are correct. A validation run will read data from the source, compile metadata if applicable, but will NOT create the content in the source system nor an ArchiveLink link. In a validation run, the following flags are set:

Store content WILL create migrate the content (with metadata if applicable) and if successful, will also create an ArchiveLink link entry and set the following flags:

Note that if you migrate an entry twice, the DocMigrator will skip that entry and place a message in the status table.

The results of the Load phase are displayed on the screen according to the option "Display Results in ALV" checkbox. If this option is chosen, all entries are displayed in the ALV report format, else a simple message indicating the number of entries loaded successfully, with info message, or errors is displayed.

If ALV is chosen, the header will display information as to the breakdown of entries loaded successfully, with info message, or errors.

Be careful when choosing "Display Results in ALV" as for large datasets this will significantly increase runtime and potential SAP system memory usage and timeouts. It is therefore suggested to use the "Display" mode of the migrator afterwards instead of displaying the results in ALV format.

Clicking on the source or target hotspot/hyperlink in the ALV allows you to view the image.