Alfresco Migration Target Learnings. - tsgrp/OpenMigrate GitHub Wiki

Versioning, Webscripts, Behaviour Suppression and Dynamic Object Model Descriptions

Alfresco Version Findings

The object id on a document is maintained every time a doc is versioned, but only the most recent version has the ID
Ex: workspace://SpacesStore/12345abcde;1.0 gets checked out and versioned. The new version becomes workspace://SpacesStore/12345abcde;2.0 and version 1 becomes version://version2Store/09876zxmcb

Alfresco stores nodes in two version stores the version/version2Store and the workspace/version2Store
CMIS pulls from the version/version2Store, Alfresco stores frozen values in the workspace/version2Store
Different values for properties such as modified date can appear in the different version stores
Alfresco stores "frozen" values for some properties that represent the true value of that property for the given version. These frozen values are stored in the workspace/version2Store
CMIS grabs the node out of the version store that does not hold the frozen values (version/version2Store) so in this case it is important to leverage the alfresco APIs to grab the correct value
A method was added to the MigrationSourceAlfrescoCMIS called setVersionSpecificPropsOnNodeUsingAlfrescoApi. This method uses the alfresco APIs to grab the correct "frozen" value

No object type/aspect/property updates applied to an Alfresco document after its original creation actually matter once a newer version is created
In other words, the records of previous versions only contain the properties that were on the node when it was first created
Ex: version 1.0 is created as a cm:content document with a cm:title and cm:description, then it's type is specialized to demo:doc and some additional properties are added. Then it gets checked out and a 2.0 version is created. When reverting back to older versions, Alfresco provides only the properties that were stored originally (title and description), which we call the "snapshot" on creation.
Updating properties on the working copy (before checkout or while checked out, but NOT after check in) - this paradigm is best practice as it allows the snapshots to contain an accurate record of the document after it is versioned again

If we throw a WebScriptException from a webscript then we cant parse the error message from the response in OM. Rather than throwing this error, it is best to use logger.error in the script and then add the error message to the model. That way OM can get the error message from the web script and log it out in the OM logs so that you dont need to look in the alfresco logs to see why a webscript failed.
If a node already exists with the passed in id we need to error right away to prevent the webscript from retrying until it times out.
Added the ability to add aspects during the creation process and to disable some/all behaviors while creating the node so that behaviors that modify prop values didn't run during creation
We also ran into issues with the createcustomnoderef webscript documentProperties map. Props with values that contained commas were throwing off the process of parsing the map from a string param in the webscript. We ended up encoding the values within the map before we send it so that when we split the map on commas in the webscript, our encoded commas remain. Then we added a url decode in the webscript to decode the values after they have been parsed into pairs.

Can be utilized to make certain updates for the next version that require Alfresco
Object type specialization
Adding/updating non-cmis properties
Another benefit of using this webscript is it allows certain behaviors to be disabled if necessary

Disabled behaviors as well as the subclasses of those behaviors. We found that if you don't run disable behaviors with disableSubclasses set to true the behavior often times would not actually get disabled. So we hard coded this to true.

A client prefers dynamic object model parsing over configuration of typeProperties/aspectProperties/aspectConditions in the project xml.
Alfresco to Alfresco Migration migration
This functionality can also likely be used for like-to-like migrations with identical object models from a different source

See AlfrescoModelParserListener - configuration instructions included in the javadocs
Note that this listener loads the entire Alfresco data dictionary (all type properties and aspect properties). Limit the properties that get applied through manual aspect condition configuration or use of applyAspectsFromSource in the MigrationTargetAlfrescoCMIS to apply only the aspects set on the node's "source_aspects" attribute.