Execution: Migration

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 keep original sapdocid 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 check multiple links this option will check if a other migration entries exist for the the same source repository id source document id (ie sapdocid / arc doc id) 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 force rfc (recommended) 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 force source rep id 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 force unique filename 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> replace characters with sp this option allows you to identify a list of special characters all in a sequence (eg %, or %`@) and have them replaced by a space include metadata (gimmal link enterprise ecm only) 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 source md exists (if applicable) new md exists (if applicable) source validated 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 source md exists (if applicable) new md exists (if applicable) target cont migrated metadata migrated (if applicable) target link created 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