The Digizuite™ DAM for Episerver connector consists of a fairly large and advanced integration with many moving parts. The goal for this chapter is to give a bit of a basic understanding of how the parts fit together. Some concepts requires deeper explanation and examples and they are split into their own chapters, following this.
The DigizuiteClient
A central component to the integration is the DigizuiteClient. It's exposed through dependency injection using it's interface, IDigizuiteClient and is a singleton. It is the central point that all the other components of the integration use for the actual connection and configuration to the DAM Center. If you, as a developer, need to do code that for example queries the DAM for specific assets, you'll most likely find the need to use the ServiceLocator in Episerver to get an instance of IDigizuiteClient and use that as your starting point.
...
- Binary Disk Cache. Most media assets (except for videos) are lazily cached on disk in the Episerver blob storage area. When an asset is being requested from the blob provider it will always use the cached asset from the local disk before attempting to fetch it from Digizuite.
- Binary Disk Temporary Upload Cache. When an editor uploads files to Episerver that should be sent on to Digizuite, they will temporarily be stored in the "DigizuiteTemp" (configurable) folder below App_Data. Then, a background process will send them to Digizuite without slowing down the editorial experience. After successful upload to Digizuite the temporary files will be automatically removed.
- In-memory Asset Metadata Cache. The Digizuite Client that retrieves all metadata automatically caches asset metadata in memory, using the Episerver Synchronized Caching mechanism. This cache is both subject to a time-out and adheres to the Sync job.
- Sync Job. This scheduled job will call Digizuite and get changed/updated/removed assets since it was last called. Then, it will remove those assets from cache - as well as alert other Episerver front-end servers to clear their cache for those items. This is a fairly lightweight job and can easily be configured to run very frequently (every few minutes).
- WarmUp Job. This final scheduled job typically runs automatically on site initialization (configurable) and will 'warm up the cache' meaning that it will fetch and cache the first batch of assets in every folder to ensure the editorial experience is fast.
Resilience
Besides caching - which has the main purpose of improving performance - there is Resilience, which is there to improve stability in case of fault scenarios. The general philosophy behind the Digizuite/Episerver integration is that should the connection fail between the 2 systems for whatever reason, it should never result in a site crashing. Furthermore, the site should also still show main assets and it should be possible to work in edit-mode - albeit without full Digizuite functionality.
...