The Alfresco Importer takes care of importing the documents and folders processed in migration-center into a target Alfresco repository.
The Alfresco connectors are not included in the standard migration-center Jobserver but it is delivered packaged as Alfresco Module Package (.amp) which has to be installed in the Alfresco Repository Server. This amp file contains an entire Jobserver that will run under the Alfresco's Tomcat, and contains only the Alfresco connectors in it. For using other connectors please install the regular Server Components as it is described in the Installation Guide and use that one.
The following versions of Alfresco are supported (on Windows or Linux): 4.0, 4.1, 4.2, 5.2, 6.1.1, 6.2.0, 7.1, 7.2, 7.3.1. Java 1.8 is required for the installation of Alfresco Importer.
To use the Alfresco Importer, your importer configuration must use the Alfresco Server as a Jobserver, with port 9701 by default.
The first step of the installation is to copy mc-alfresco-adaptor-<Version>.amp file in the “amps-folder” of the Alfresco installation.
The last step is to finish the installation by installing the mc-alfresco-adaptor-<version>.amp file as described in the Alfresco documentation:
https://docs.alfresco.com/content-services/latest/install/zip/amp
Before doing this, please backup your original alfresco.war and share.war files to ensure that you can uninstall the migration-center Job Server after successful migration. This is the only way at the moment as long the Module Management Tool of Alfresco does not support to remove a module from an existing WAR-file.
The Alfresco-Server should be stopped when applying the amp-files. Please notice that Alfresco provides files for installing the amp files, e.g.:
C:\Alfresco\apply_amps.bat (Windows)
/opt/alfresco/commands/apply_amps.sh (Linux)
Due to a bug of the Alfresco installer under Windows, please be careful that the amp installer via apply_amps.sh works correctly!
The Alfresco can be uninstalled by following steps:
Stop the Alfresco Server.
Restore the original alfresco.war and share.war which have been backed up before Alfresco importer installation
Remove the file mc-alfresco-adaptor-<Version>.amp from the “amps-folder”
To create a new Alfresco Importer job, specify the respective adapter type in the properties window – from the list of available connectors “Alfresco” must be selected. Once the adapter type has been selected, the parameters list will be populated with the parameters specific to the selected adapter type, in this case the Alfresco connector’s parameters.
The properties window of an importer can be accessed by double-clicking an importer in the list or selecting the Properties button or entry from the toolbar or context menu.
The common adaptor parameters are described in Common Parameters.
The configuration parameters available for the Alfresco importer are described below:
username* User name for connecting to the target repository.
A user account with admin privileges must be used to support the full Alfresco functionality offered by migration-center.
password* The user’s password.
importLocation
The path inside the target repository where objects are to be imported. It must be a valid Alfresco path and have to start below the “company_home”-node inside the spacesStore.
Examples for valid values of importLocation:
“/sites/demosite/documentLibrary/” for import into the document library of a share site with internal name demosite
“/demofolder” for import a folder with name demofolder below the company home folder.
This path will be appended in front of each folder value (for documents and folders) before creating parent-child association for this object if both the importLocation parameter and the folder attribute values are set.
If the attributes mentioned previously already contain a full path, the importLocation parameter does not need to be filled.
Examples:
importLocation = ”sites/demosite/documentLibrary/” and folder for documents “/test” = complete path “/sites/demosite/documentLibrary/test”
autoCreateFolders This option will be used for letting the importer automatically create any missing folders (spaces) that are part of the folderpath for any object (folder or documents).
Use this option to have migration-center re-create a folder structure at the target repository during import. If the target repository already has a fixed/predefined folder structure and creating new folders is not desired, deselect this option.
defaultFolderType Specifies the default folder type when creating folders using the autoCreateFolders option described above. If the parameter is empty, “cm:folder” will be used by default.
Examples for valid values:
“cm:folder” for standard folder type
“fme:folder” for your own folder type
loggingLevel* See Common Parameters.
Parameters marked with an asterisk (*) are mandatory.
folderpath Each object in Alfresco must be created under a parent object (parent-child-association). This parent object must be a Alfresco folder or a subtype of the Alfresco folder object (cm:folder).
For defining the parent object for an object which should be imported into Alfresco, use the system attribute folder.
Currently, only one folder path is supported and the starting point for imports is the company_home-node of the Spaces store. Only imports below this path are currently possible.
The format of the value must be a valid child node path (without using prefixes for the namespace). Example: If the importLocation of the Importer Module (see section 5.2) is set to /Sites/demosite and the folderpath value is set to /documentLibrary/Alfresco Demo
The object will be created under the documentLibrary of the demosite
Full path is: /Sites/demosite/documentlibrary/Alfresco Demo
mc_content_location This rule offers the possibility to overwrite the location of the objects content.
Leave empty in case the scanned content_location should be used. Example: Initial content location: \\server\data\alfresco\testdocument.txt Set a new location in order to access it from a linux mount of the above share: /server/data/alfresco/testdocument.txt
permissions In Alfresco each object (document or folder) can have several permissions where as one permissions consists of an Authority (person or group) which have a certain right (a certain role like Consumer or a certain right like Read). The access status (Allow/Deny) allows to define if the authority has the permission or not.
User and groups can be configured via Alfresco Explorer or Alfresco Share (Admin functions). Roles can be defined via permissions.xml (look at the Alfresco wiki to find more information).
To configure permissions for an object, use the system attribute permissions.
It can be multivalue and each value must have the following format:
AUTHORITY###PERMISSION### ACCESSSTATUS (ALLOWED|DENIED)
### is used as separator.
You can leave the last part of the value, so the default access status will be ALLOWED.
You can configure the permissions for all object types (folder and documents). Example: ROLE_ADMINISTRATOR###READ
each user in the administrator role will get read permission on the object for which this permission is set
GROUP_EVERYONE###CONSUMER###ALLOWED
Each user of the system (because each user is in the group everyone) will have the permissions of the consumer role.
types / aspects Alfresco as an ECM-System provides built-in object types which can be used for documents and folders. It is also possible to define your own custom types.
Alfresco also provides the functionality to attach and detach aspects on nodes. Additionally, Alfresco has built-in aspects like a “cm:titled” or “cm:author” aspect. More information is provided here: http://wiki.alfresco.com/wiki/Aspect
To configure the object type and aspects for the object to be imported, use the systemattribute types / aspects.
The attribute is multi-value, so it is possible to define exactly one object type and zero, one or more aspects for one object to be imported.
Please note that any custom object type can be used which are derived from cm:content or cm:folder.
Important: The first value in this attribute must be the content type. Example: cm:content
cm:auditable
cm:titled
The object imported will be of type cm:content (alfresco standard document type) and will get the aspects cm:auditable and cm:titled.
folderpath Same as document system rules.
permissions Same as document system rules.
types / aspects Same as document system rules.
Compared to migrating documents and having the folder structure auto-created by the importer, migrating folder objects allows you to set detailed metadata on the folders themselves (such as permissions or aspects).
This approach involves migrating the folder structure first and then migrating the documents in that structure with the autoCreateFolders parameter unchecked.
In order to execute a folder-only migration the following steps should be performed to configure the migration process accordingly:
With the scanner you need to export folders as distinct migration-center objects. Only some scanners support this so please read the specific scanner userguide for details.
Creater a migset of type <SourceType>ToAlfresco(folder) and add the scan run containin gthe folder objects.
In the transformation rules use cm:folder for the base type and ensure to recreate the parentFolder structure in a consistent way.
The parentFolder system rule needs to also contain the current folder name in its path. “name” and “folder” are key attributes for folders in Alfresco. Example: For a folder called current folder that resides in the following structure /Root/folderOne/ the parentFolder system rule when migrating this folder needs to be /Root/folderOne/current folder
The autoCreateFolders options is not used for the folder migsets. however the parameters will still be used if document migsets are imported together with the folder migset.
To import major/minor versions in Alfresco, you need to set the cm:versionable aspect with the cm:versionLabel attribute.
If the version label ends with “.0”, a major version is created, otherwise a minor version is created. The actual version label numbers are determined automatically by Alfresco.
If you do not set the cm:versionLabel in the aspect association, the importer will create all versions as major.
If you do not assign the cm:versionable aspect in the system rule types / aspects, the importer assigns it automatically when importing the second version.
Version Comments can be assigned by setting the versionComments attribute.
Note that the first version of a version tree cannot have a comment, since it was not checked in, but created.