- Check the MSM FAQ page in order to see with your problems or questions are not already adressed there
- Check the new MSM best practices Documentation page
- Make sure the issue is reproducible with the latest Service Pack installed
MSM registers several servlets that can be requested with selectors on the resource URLs.
They are used by the UI but can also be requested directly to see directly additional advanced computed MSM statuses for your pages :
Use on a Blueprint page to retrieve the list of all livecopies linked to it , with advanced LC status.
Use on Livecopy pages to get advanced information on their connection with their Blueprint page.
If the page is not a Livecopy , nothing is returned.
Those servlets generate DEBUG Log messages through the com.day.cq.wcm.msm logger that are worth checking as well.
The servlets above returned computed information based on the MSM specific nodes and mixins .
The information is stored the following way .
- cq:LiveSync mixin type
This is set on jcr:content nodes and define root Livecopy pages .
Those pages will have a cq:LiveSyncConfig child node of type cq:LiveCopy that will contain basic and mandatory information on the Livecopy through the following properties:
cq:master : points to the Blueprint page of the Livecopy
cq:rolloutConfigs : indicates active Rollout Configurations applied on the Livecopy
cq:isDeep : is true if the child pages of this root Livecopy page are included in the Livecopy.
- cq:LiveRelationship mixin type
Any livecopy page has such a mixin type on its jcr:content node.
If not, the page has been at some point detached, or manually created via the authoring interface outside of a Livecopy action (create or rollout)
- cq:LiveSyncCancelled mixin type
Added on jcr:content nodes of Livecopy pages that were suspended.
If the suspension if effective for child pages as well : a cq:isCancelledForChildren=true property is added on the same node.
The information present there should be reflected in the UI of course, however in abnormal situations you might encounter where you can question the UI or MSM Behavior, superusers can verify directly those nodes to understand the status of their MSM Pages .
Knowing those properties can be also useful in order to query your repository and find out sets of pages that are in particular states.
Example : select * from cq:LiveSync will return all Livecopy root pages.
You might eventually require AEM Support assistance .
For MSM issues those additional precisions should be added ideally :
- Before attaching logs : enable DEBUG level for the logger com.day.cq.wcm.msm in /system/console/slinglog , and repeat the problematic MSM Action .
- Attach the output of config http://<host>:<port>/libs/wcm/msm/content/commands/rolloutconfigs.json .
- Communicate the rollout configurations attached to the Livecopies
- If the problem seems to come from the UI (browser console error or UI error popup appears) : Generate a har file to capture the complete flow from the user perspective when performing the problematic MSM action : see this link for details on HAR file generation
- Reproducing the issue is the easiest way for support to quickly analyze and determine if the behavior is normal or not, and act accordingly.
For this purpose , try to :
1) Reproduce your problem on a similar setup based on We-Retail Pages
2) If not possible, try to build a content package that includes sample content of yours, in order for a support engineer to install it on a blank AEM instance with same patch level as yours, and reproduce the issue.