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.
...
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.