Attachment Migration is supported only for certain source ->target server combinations. The table below shows the current support for Attachment Migration:
Notes on specific attachment migration functionally (see entries in table above):
| (1) |
Enable in Form Mapping Options. All attachments associated with the source record will be migrated to the target record. Note for Database Sources, where the Precision Bridge Attachment archive table is present (sn_sys_attachment) the option available will be 'All from Archive' |
| (2) |
For Database or Service Now Targets You can define where the attachment data should be written to. The options are; the target server (or database), the file system or an S3 bucket. For database targets, the target server option will write the attachments to a Precision Bridge defined attachment table on the database. Other database tables are not supported. For ServiceNow data, the target server option will write the attachment to the sys_attachment table. Attachment data can also be redirected to a file/S3 bucket. In this case, where the target is a database, a record will still be created in the Precision Bridge defined attachment table and this entry will give the location of the actual data file. Where the target is ServiceNow, a custom table u_pb_linked_file will be created, and an entry added to this table. The entry will again include the location of the attachment file. More information can be found in the article Defining Attachment Options |
| (3) |
Supported by explicitly mapping Attachment Fields using a simple mapping. |
| (4) | Enable in Form Mapping Options: Supported by explicitly selecting the source attachment fields that should be migrated to the target records. |
|
To ensure that 'duplicate' source attachments (same size and same filename) are migrated when multiple source records are being merged into a single target, the option below in FeildMapping Options-Advanced can be used to append the id of the source record to the filename to make it unique: |
|
| (5) |
Enable in Form Mapping Options: By default, a Server->Server Attachment migration is used with the target server pulling attachment data directly from the source using a scripted web service, which is the most efficient method. If the two servers do not have network connectivity to each other, this can be unchecked in the Execution Options (Attachment tab) to use the standard (less efficient) Server->PB->Server method. |
| (6) | Enable in Form Mapping Options: Support for migrating previously archived attachments back to the Server. Available for Oracle, ServiceNow and Postgres Databases but NOT for Hana DB |
| (7) |
For CSV Source attachment migration. Enable in Form Mapping options, selecting the Attachments from URL option (or Attachments from URL fill Selected Attachment Fields option for a Remedy target). An attachment csv file containing the parent table, id, filename, download url and optionally size and type of each attachment will need to be configured as source forms, and the fields that represent each field must be configured in the CSV Attachment Configuration options. Optionally, you can use advanced options to construct the full URL and to extract the file name from a URL (or other containing string). You can also configure Basic Authentication of the URL here. If this option is selected, then you will need to enter the username/password in the execution settings when you execute the migration. A specific authentication option for Manage Engine attachment download is also available if the attachment URLs point to a manage engine instance. See the article CSV To Service Now Attachment Migration - Overview for more information.
|
| (8) |
For Migrations into a Remedy target server, the attachment migration option will be 'Fill Attachment Fields'. For a database source where the 'Attachments from Archive fill selected attachment fields'. You must select the attachment fields that are to be populated using the attachments retrieved from the source. You must select at least one field. Note that for a CSV source, the option will be 'Attachments from URL fill Selected Attachment Fields'. In addition to defining the attachment fields to fill, you will also need to configure the CSV Attachment Source (see 7 above). If, while migrating attachments, no available field can be found for an incoming attachment, an error will be reported relating to the migration of this attachment. |
| (9) |
For attachment migration from a database table identifying the download URL and other attachment metadata. Enable in Form Mapping options, selecting the Attachments from URL/binary option (or Attachments from URL/Binary fill Selected Attachment Fields option for a Remedy target). The table containing the URL/binary field that will provide the attachment content must be selected. This table must have a foreign key association with the source table and a single field primary key. The field containing the URL/Binary data must be selected as a minimum. Optionally, you can use advanced options to construct the full URL and to extract the file name from a URL (or other containing string). The file name may be set using a field on the attachment table. The file name value can be further processed by setting a file name regex (to extract part of the value) or a file name format (to prepend/append other characters to the filename). If the size and mime type are recorded in the attachment table, you can select these fields as well. For URL upload, you can also configure Authentication of the URL here. If this option is selected, then you will need to enter the required authentication details (e.g. username/password) in the execution settings when you execute the migration. A specific authentication option for Manage Engine attachment download is also available if the attachment URLs point to a manage engine instance.
|
Comments
0 comments
Please sign in to leave a comment.