meta data for this page
Common reasons of synchronisation failures
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 errors1). 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 Backoffice > 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 HAC > Platform > PK Analyser to get its type
- Now the cause of the error in the synchronisation must be found:
- 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 synchronize 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 CMS2) Items (same UID in the a Catalogue Version)||Unknown||- Creation of unique indexes in the tables with CMS items. Please read the detailed explanation below.||No|
|Mandatory field with a null value or an invalid PK||- Unlink of the CMS Navigation Entries from the navigation nodes |
- Bugs in the Impex Scripts which lead to null values in the items
- Removal of CMS Items, which where changed after the last synchronization, in the WCMS like the removal of a page after working with its content slots.
| - To synchronize the catalogue before an user removes a page, a navigation node or another CMS item. This reduces the possibility of a sync error. |
- Use of removal interceptors to prevent usual cases when it is possible
- Impex Scripts: Be more careful when removing CMS Items which may be referenced be another one, for example, content slots are referenced by content slots for pages or for templates
|Edition mistakes|| |
- Reference to an object which is in a wrong catalogue
- Circular References between catalogues
| - Limit the access to the catalogues. If the user can't see other catalogues, he can't choose the wrong one |
- Training of the users to identify this error before calling the developers
|Type change of an existent CMS Item||- The same UID points to a CMS components of different types in the source and target catalogues. For example: The carousel components where created and synchronized. Then the same UIDs was used by the new carousels with popularity components. The synchronization will fail because the UID points to components with two different types.|| - Remove the components in the target version and synchronize again|
- Don't reuse the UID. A new component type means new UIDs
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 off3), 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 SAP Hybris 5.6