Attachment migration

Attachments are documents that are linked to an instance of an object. A document can be attached to a given user, a given item, a given sales orders, etc. For example: the table AOBJTXT stores the link between the key of the instance ( (ITM,CD100) for the item CD100) and the path (C:\documents_items\my_item_CD100.docx).

Changes in attachment management

In version 9, the attachment management has been changed to use volumes. For every file, the path of an attachment is now expressed with the following mandatory syntax:

[VOL]/path

Previously, the 'path' could be directly expressed as a windows or unix path:

• From the current application server (for example, C:\my_attachments\contracts\contract01.docx, or /user/doc/mydoc.txt).
• From another server available from an application server (for example \\my_server\attachments\erp\figures\my_figures.xls).
• From the current workstation of the server (for instance #@:\Documents\my_docs\map.jpg). This last type of "local" attachment is no longer possible.

You must replace all the operating system paths with a normalized path based on a volume to re-link the documents. This change applies to all the paths stored in the attachment table (AOBJTXT).

The recodification tool was created to help with this process.

What does the tool do?

This tool performs the following operations:

• Check the paths found in AOBJTXT.
• Identify the directories not yet assigned to a volume and allow the user to create volumes.
• Replace the path with volumes.

Additional operations

When replacing the path, you can adjust the way the path is created.

Grouping paths

If, for example, you want to regroup several paths, you can map them to the same volume. For example, the system finds two "old" attachments, C:\documents\old\myold_doc.docx, C:\contracts\2003\distribution.docx. If no volumes exist for them, the system suggests creating two volumes: one assigned to C:\documents\old\, the other to C:\contracts\2003\. Instead, you can choose to assign the first path to a volume called [olddoc], and assign the second path to a volume of the same name.

Warning: Using this tool creates a volume olddoc assigned to one of the paths, and just renames the second document in the attachment table. However, the second document will not be moved to the first location; you need to do this manually.

Using shorter paths

If, for example, you have documents in directories that are C:documents\mails\2013\, C:documents\mails\2014\, C:documents\mails\2015\... The system suggests creating three directories, which are, by default, the longest paths possible. But if you create a unique directory C:documents\mails\ called [mails], the path of the different documents will be defined as [mails]/2015/mail1.doc, [mails]/2013/mail25.doc... In this case, you do not need to move the documents.

Redefining paths

For local documents (#@C:\path), you need to redefine a volume and manually move the documents to the corresponding volume path from every local PC.

How to use the tool

When the tool is launched the first time, it runs a check on the attachment tables. When this analysis is done, a screen with two grids displays:

Files

This first grid lists the results of the analysis in the AOBJTXT analysis:

• The first column displays one of the three results:

  • Anomalies: The message displays the reason for the error. The most common is "path starting with #". This means that local attachments have been encountered and the number of files concerned is displayed.
  • Valid : The message displays the number of files already assigned to volumes.
  • Volume doesn't exist : The directory path that is not assigned to a volume is displayed; the number of attachments is also displayed.

The total number of attachments is displayed at the bottom of the grid.

Clicking the Detail link on the line next to a result creates a log that gives you details on all corresponding results. The log file is displayed on a separate page.

Volumes

This second grid allows you to define actions for each result. In this grid, two kinds of lines are present:

• The first part of the grid displays the list of directories that are not yet assigned to a volume. The path #... is suggested for all local attachments on a line. You have the following options for each line:

  • Create (Yes/No):
  • If set to Yes, a volume is created with the name given and assigned to a path that can be modified if a shorter path needs to be used.
  • If set to No, no volume is created.
  • Modify (Yes/No):
  • This can be set to Yes only if the Create value was set to No. You then need to enter an existing volume name, and the corresponding attachments will be renamed with the corresponding volume, according to the document definition.
• The code corresponds to the name of the volume to be used or created.
• The path corresponds to the volume to be created and can be entered only if Create was set to Yes.

In summary, you have the following choices:
* Enter Yes for 'Create' (modification will then be set to No), and use the existing path or modify it.
* Enter No for 'Create' and Yes to 'Modify'. Enter an existing volume name to assign the files to the corresponding volume.
* Enter No to 'Create' and 'Modify' if nothing no action will take place in the corresponding run.

Click the Validation link to run the creations and modifications.

Operations present in the right panel

The following links are available in the right panel:

• Validation triggers the updates according to the date entered in the second grid. When the operation is finished, the page displays with any remaining issues in the first grid.
• Refresh re-executes the analysis for the existing attachments and displays the results. It is helpful if manual modifications have been done at attachment level.
• Log displays the log file describing the operations done after a Validation operation.
• Control files checks if the attachments can be physically found at their intended locations.

Renaming strategies

When creating modules, it could be helpful to find the right balance between the number of files and the number of volumes. For example, if you have the following volumes:

C:\Contracts\Distribution\2011 : 218 documents

C:\Contracts\Distribution\2012 : 524 documents

C:\Contracts\Distribution\2013 : 200 documents

C:\Contracts\Distribution\2014 : 753 documents

C:\Contracts\Distribution\2015 : 26 documents

C:\Contracts\Patents\2012 : 252 documents

C:\Contracts\Patents\2015 : 15 documents

C:\Contracts\Others : 46 documents

C:\Contracts\Advertisement : 18 documents

You can create one volume per year for every distribution contract directory, e.g., [DIS11], [DIS12], [DIS13], [DIS14], [DIS15], and then a volume for all patents, and finally a volume for all the other documents. In this scenario, you need to work in several passes and recodify the longest path first.

The recodification page looks like the following:

First:
* Recodify the local path as [LOCAL]/path (the LOCAL volume has been created directly).
* Create the DIS11 to DIS15 volumes and recodify the corresponding files.
* Create the PATENTS volume and recodify the files starting with C:\Contracts\Patents (this also handles the 15 files present on C:\Patent\2015 although No action has been required on them because a path that matches the beginning of the path exists).

After running, 64 files remain (C:\Contracts\Others and C:\Contracts\Advertisements), and the page looks like this:

You can now start a second pass that renames all the remaining files starting with C:\Contracts. The first pass migrated all the other files, which is why it was important to recodify the longest paths first.