DFS 9.0.0 - The auto synchronization between Digizuite and Sitecore

This article is an overview of the auto synchronization process and it provides some tools to troubleshooting if the auto synchronization process fails.

Understanding the architecture

The auto synchronization process is a Sitecore pipeline that synchronizes metadata, assets and configuration from Digizuite to Sitecore. The purpose of it is keeping the two systems in sync.

The pipeline is defined in the config file <Sitecore root>\Website\App_Config\Include\damforsitecore\DFS.Connect.config with the following configuration:

<Configuration>
  <Sitecore>    
    <hooks>
      <hook type="DFS.Connect.Hooks.DetectDamChangesLoader, DFS.Connect">
        <param name="agent" type="DFS.Connect.DetectDamChangesAgent, DFS.Connect">
          <param name="repository" ref="DFS.Connect/assetSiloRepository" />
        </param>
        <param name="interval">00:01:00</param>
      </hook>
    </hooks>

    <pipelines>
      <DFS.Connect.DetectDamChanges>
        <processor type="DFS.Connect.Pipelines.DetectDamChanges.RunGetModifiedAssets, DFS.Connect" />
        <processor type="DFS.Connect.Pipelines.DetectDamChanges.RunGetModifiedMetafields, DFS.Connect" />
        <processor type="DFS.Connect.Pipelines.DetectDamChanges.RunSyncDeletedAssets, DFS.Connect" />
        <processor type="DFS.Connect.Pipelines.DetectDamChanges.RunSyncMetagroups, DFS.Connect" />
        <processor type="DFS.Connect.Pipelines.DetectDamChanges.RunSyncDeletedMetafields, DFS.Connect" />
      </DFS.Connect.DetectDamChanges>
	</pipelines>
  </Sitecore>
</Configuration>

The hook configuration is what starts the pipeline and it contains information on how often it should be run. For this configuration it is run 1 minute after it last ended. The pipeline itself is called DetectDamChanges and it contains multiple other pipelines what will synchronize metadata, assets and configuration from Digizuite to Sitecore.

How does it work?

In Digizuite we have a timestamp on everything which indicates when it was last updated. The API can be queried for a list of assets/metadata/configuration that was changed between two dates. Using this idea, Sitecore keeps track of when it was last synchronized and then the pipeline queries the Digizuite API for a list of changes within the last synchronization time and the current time. This timestamp is found on the Silo under Content → Configuration → LastRunDateTime.

Using this response from the Digizuite API each Sitecore item is updated.

Troubleshooting if it does not work

This section goes through some of the common miss-configurations and provides some tools for troubleshooting if the auto synchronization process does not work.

Does it run?

The first thing to always check is to verify that the pipeline actually runs.  This can be verified by going into the DFS.log where the following log lines should be present:

ManagedPoolThread #14 00:05:06 INFO Start Detect DAM Changes 
ManagedPoolThread #14 00:05:06 INFO Asset change date range: 2017-10-11T00:02:04 to 2017-10-11T00:05:06 
ManagedPoolThread #14 00:05:08 INFO End Detect DAM Changes

If it does not run then there typically would be some errors in the log file. Most of the time it is related to configuration. Either the configuration for the pipeline is wrong or the configuration which specifies Digizuite URLS, users and passwords is wrong.

Is the timestamps correct?

The above log lines contains two timestamps. These are the range for which changes from Digizuite is requested. It is important that these timestamps match the time of the Digizuite SQL Server.

Sitecore always uses UTC time, however, Digizuite uses the timezone of the SQL Server. Therefore the UTC timezones are translated into whichever timezone Digizuite is using. If the configuration for this is off, then the request for changes will yield wrong responses. This is configured in the Digizuite DAM Center doing the following:

1. Navigate to System tools → Config Manager → Digizuite DAM For Sitecore → Default → Config parameters
2. Locate field DateTime CultureInfo (See screenshot)
3. The important part here is what is appended after the pipe sign ( | ).
4. Set what is appended after the pipe sign to be which ever timezone the Digizuite SQL Server is in. See Microsoft Documentation. (PS: If the SQL server is in UTC time zone, use Greenwich Standard Time after the pipe)

Does it find changes in Digizuite?

In order to verify that the synchronization it self is actually working, then try changing something on an asset that is published to the Sitecore channel in Digizuite (i.e. Title) and check log files. When the pipeline is run again, then it should contain something similar to this:

ManagedPoolThread #9 12:30:52 INFO  Start Detect DAM Changes
ManagedPoolThread #9 12:30:52 INFO  Asset change date range: 2017-10-13T12:27:46 to 2017-10-13T12:30:52
ManagedPoolThread #9 12:30:54 INFO  Modified AssetIds: 85 Language:en
ManagedPoolThread #9 12:30:54 INFO  End Detect DAM Changes

If the log does not contain something similar to this (Note earlier versions of DFS does not include this without having the log level set to DEBUG), then most likely the time zone is not correct. If the the times matches the timezone of the Digizuite SQL server and no assets are synchronized, then check the base url to see if it is hooked on to the correct Digizuite.

If DFS is an early version (pre 8.0.2), then the logs are a bit different. In this case, one can also locate the asset in the Asset silo in Sitecore and check that the change made in Digizuite is actually synchronized into Sitecore and stamped on the Sitecore item (Title and description is stamped directly on the asset, so changing these are a good idea).

If none of this works, then contact the Digizuite team for resolution.

Is the Sitecore index up to date?

If the log shows that the pipeline has catched the asset changes correctly and the values are stamped directly onto the Sitecore item in the asset silo, then most likely the cause of the problem is that the dfs_asset_master_index is not being updated correctly. To verify this, rebuild the dfs_asset_master_index and check if it resolves the issue.

If the index is not being updated correctly, then most likely it is due to miss-configuration of Sitecore. The DFS indexes are being updated by Sitecore, not DFS. DFS registers a save event for each update and this is being picked up by Sitecore that then does the update. So double check the index configuration (DFS) and the Sitecore default index configuration. Furthermore, it is a known bug in Sitecore 8.0.2 update 2 and earlier that indexes sometimes are not updated correctly. One can verify this by checking the Crawling.log and see if anything regarding the index updating is being skipped.