As described on the parent Repository Restructuring in AEM 6.5 page, customers upgrading to AEM 6.5 should use this page to assess the work effort associated with repository changes potentially impacting all solutions. Some changes require work effort during the AEM 6.5 upgrade process, while others can be deferred until a future upgrade.
From AEM 6.4 onwards, there is no default ContextHub configuration. Therefore on the root level of the site a cq:contextHubPathproperty should be set to indicate which configuration should be used.
Navigate to the root of the site.
Open the page properties of the root page and select the Personalization tab.
In the Contexthub Path field enter your own ContextHub configuration path.
Additionally on the ContextHub configuration, the sling:resourceType needs to be updated to be relative and not absolute.
Open the properties of ContextHub configuration node in CRX DE Lite, e.g. /apps/settings/cloudsettings/legacy/contexthub
Change sling:resourceType from /libs/granite/contexthub/cloudsettings/components/baseconfiguration to granite/contexthub/cloudsettings/components/baseconfiguration
I.e. the sling:resourceType of the ContextHub configuration must be relative rather than absolute.
Any new or modified Workflow Models must be migrated to /conf/global/workflow/models.
Deploy the modified Workflow Models into a local AEM 6.5 development instance, such that they exist in the Previous location.
Edit the Workflow Model using AEM's Workflow Model Editor at AEM > Tools > Workflow > Models.
When migrating modified AEM-provided Workflow Models
With the Workflow Model Editor open, modify the browser's address URL, and replace the path segment /libs/settings/workflow/models with /etc/workflow/models.
For example, change: http://localhost:4502/editor.html/libs/settings/workflow/models/dam/update_asset.html to http://localhost:4502/editor.html/etc/workflow/models/dam/update_asset.html
Enable Edit mode in the Workflow Model Editor which will copy the Workflow Model definition to /conf/global/workflow/models.
Tap the Sync button to sync the changes to the Runtime Workflow Model under /var/workflow/models.
Export both the Workflow Model (/conf/global/workflow/models/<workflow-model>?lang=en) and Runtime Workflow Model (/var/workflow/models/<workflow-model>?lang=en) and integrate into the AEM project.
For example, export:
Workflow Model resolution occurs in the following order:
Thus, any customizations of AEM-provided Workflow Models persisted in the Previous location must be moved to /conf/global/settings/workflow/models if they are to be retained, otherwise they will be superseded by the AEM-provided Workflow Model definition in /libs/settings/workflow/models.
No action is required to align with the New Location.
Historical Workflow Instances can safely continue residing in the Previous Location, and new Workflow Instances will be created in the New Location.
Any explicit path references in
code to the Previous Location should also take into account the New Location. It is recommended that this code is refactored to use the AEM Workflow APIs.
Any new or modified Workflow Launchers must be migrated to /conf/global/workflow/launcher/config.
Copy any new or modified Workflow Launcher configurations from the Previous Location to New Location (/conf/global).
Workflow Launcher resolution occurs in the following order:
Thus, any customizations of AEM-provided Workflow Launcher persisted in the Previous location must be moved to the New Location (/conf/global/settings/workflow/launcher if they are to be retained, otherwise they will be superseded by the AEM-provided Workflow Launcher definition in /libs/settings/workflow/launcher.
Any new or modified Workflow Scripts must be migrated to the New Location and the referencing Workflow Models updated to reflect the New Location.
Copy any new or modified Workflow Scripts from the Previous Location to the New Location.
/apps/workflow/scripts should be maintained in SCM.
Update any references to the Workflow Scripts at the Previous Location in Workflow Models to point to the New Locations.
AEM 6.4 SP1, when it is released, makes it so this restructuring can be deferred until 6.5
If upgrading to AEM 6.4 prior to AEM 6.4 SP1 being released, this restructuring should be performed as part of the upgrade project. Without doing so, editing and saving Workflow Steps referencing scripts in the Previous Location will remove the Workflow Script reference from the Workflow Step entirely, and only Workflow Scripts in New Locations will be available in the script selection drop-down.
Prior to Future Upgrade
Any new or modified ContextHub Configurations must be migrated to the new location and the referencing AEM Sites pages must be updated to reflect the new location.
Copy any new or modified ContextHub Configurations from the previous location to the new location.
Associate the applicable AEM configurations with the AEM content hierarchies.
Copy all Tags from the Previous Location to the New Location.
Remove all Tags from the Previous Location.
Via the AEM Web Console, restart the Day Communique 5 Tagging OSGi bundle at https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging for AEM to recognize the New Location contains content and should be used.
Restarting the Day Communique Tagging OSGi bundle will only register the New Location as the tag root if the Previous Location is empty.
References to the Previous Location will continue to work after migrating to New Location for all functionality that leverages AEM's TagManager API for tag resolution.
Any custom code that explicitly references the path /etc/tags must be updated to /content/
, or preferably rewritten to leverage the TagManager Java API, in tandem with this migration.