A common complain of the users which edit content using the CMS Cockpit is that the synchronisation stops working quite often. During the last two months I solved around thirty seven cases and found sixteen different causes of sync errors. This is a summary of the categories of errors and tips or measures to prevent them.
Procedure to find out why the synchronization isn't working
- Check the log files. The synchronisation code logs little information but by reading the log you get how the synchronization was triggered.
- Go to HMC > System > Types
- Look for the type CatalogVersionSyncCronJob
- Open the type
- Click two times on the arrow on the upper right corner to search instances
- In the field Job select the catalogue which is failing
- Open the last cronjob with has last result error or system error.
- Click on the log tab
- Download and check the last log file if it exists.
- Click on the administration tab
- Download the dump medias
- The first one contains the list of items which were schedule for the synchronisation
- The second and last ones have the same information. It is the list of PKs of the items which couldn't be synchronized with the following columns: PK of the source object, PK of the target object and PK of the synctimestamp.
- For each source PK use HMC > Platform > PK Analyser to get its type
- Now the cause of the error in the synchronisation must be found:
- HMC or SQL queries may show rows with nulls on mandatory fields or pks to objects which doesn't exist any more.
- With SQL you can also check if two components, medias or content slots share the same uid and are on the same catalogue version.
- The catalogue version of the objects referenced by these items may be wrong
- There is an old object with the same UID in the online catalog version and they have different types.
- The SyncJob will only synchronized objects of the types which are in his configuration.
Disadvantages of the legacy mode
- It can synchronized components with errors like missing values in mandatory fields. It allows the developers to ignore data errors in the CMS catalogue.
- It can end successfully without synchronizing the navigation nodes and entries. The cause of this bug is still unknown.
- The legacy mode is deactivated by default. The setting is called synchronization.legacy.mode
|Category||Causes||Countermeasures||Will happen again?|
|Duplicate CMS Items* (same UID in the a Catalogue Version)||
|Mandatory field with a null value or an invalid PK||
|Type change of an existent CMS Item||
* CMS Items are pages, components, content slots for page or for template, content slots, navigation nodes, navigation nodes and links.
Examples of edition mistakes and empty mandatory fields
The main causes are mandatory fields with null or invalid PKs values and CMS items using with a wrong catalogue version. These errors may be originated on these cases:
- Removal of a page, a CMS link component or media linked to a CMS Navigation Entry. A remove interceptor can be written to prevent the removal of the item if it is associated to a navigation entry.
- Unlink a CMS Navigation Entry from a Navigation Node. The WCMS doesn't delete the navigation entry.
- Removal of a page without removing the contentSlotForPages after editing them. A remove interceptor can prevent this situation.
- Add a reference in CMS component to a product within a CMS catalogue version and the sync job of it is configured to synchronize only CMS medias, relations and items.
- Add a reference to a item in another catalogue which has references to the actual one. This will generate a circular reference between the catalogues. For example: A restrictions in an old catalogue is used by CMS components in the new catalogue.
- Remove a page and create a new page with the same ID without synchronising. After the removal of the page, the catalogue must be synchronized.
- A CMS component or a navigation entry references a media in the same catalogue but the sync job isn't configured to synchronized this type.
- Impex Errors
- Removal of a contentslot without removing all the associated contentSlotForTemplate and contentSlotForPage. An sync error will only be triggered if the second objects were modified or a full synchronisation of the catalogue is done.
In every case the item with the error must have been modified after the last synchronization. If it isn't, the sync process is going to ignore it unless you select "force update" on the synchronisation wizard in hMC. To teach the WCMS users to synchronize any change before removing a component, page or navigation node and to remove access to other catalogues reduces the occurrence of the above cases.
Duplicate CMS Items
In one project the synchronisation created duplicate -same code or uid- medias, contentslots and navigation nodes. Although the multi-threading in the synchronization was turned off -property catalog.sync.workers-, the system kept generating duplicate medias. The cause of the error is still unknown but unique indexes for the column catalogVersion and code/uid on the tables medias, contentslot, cmscomponent, cmsnavigationnode, cmsnavigationentry, slotsfortemplate and slotsforpage solved the issue. After the creation of the index no error message or stack trace is shown in the logs, so further investigation of the issue couldn't be done.
Tested on 5.6