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.
If Media resilience is enabled (default, but can be switched off for performance in configuration), then that means that every time an editor published a content item in Episerver that is referencing any asset on Digizuite, a copy of the asset is stored in the Episerver blob storage, and the metadata of the asset is stored in the Episerver Dynamic Data Store. Then - if a fault/disaster scenario is detected - it will fallback to the previously stored asset. It is worth noting though, that this functionality does not apply to videos, nor does it work with dynamically fetched assets (fetched by custom developer code) - only assets that have been referenced in the regular way will be detected and made resilient.The diagram below shows the flow when loading content. First we look at the in-memory cache, then we look into the database. We have our own table (DigizuiteContentItems) where we store all the metadata for the content item. If it is not in the DB, then we fetch the data from the Digizuite API and stores the data in the DB and the cache. With this approach we make sure that the content always will be available if the connection between Digizuite and Epi is lost and off cause the data has been save to the database.
On top of that, all components of the integration has been made robust, so that even if they are in a fault scenario, they will not crash - but rather report an error (both in error logs and editor notifications) - and offer very limited functionality.Still - it is of course important to keep in mind that this is purely for disaster scenarios - and if you happen to end up in such a scenario, the main priority should be to reestablish connection! When connection is reestablished, the integration will detect it and re-initialize itself.