Where is ECL data cached?

Question

Where does ECL data like folder structure, thumbnail images on the CME get cached? Is that cached on the browser of CME or on the ECL server-side?

Because when I tried to do more rnd on the same, I found that first time it called the below service when you click on any folder on ECL.

"WebUI/Models/ECL/Services/General.svc/GetList".

Next time it did not call the above service to get the ECL data.

Please let me know if any one can provide more input.

Answer 1

Folder structure and is cached in the browser the exact same way as standard Tridion Items. The first time you load them they will be retrieved, and after that you have to use Refresh to update the list. So just like you do not see any call to the ECL GetList implementation when switching to an ECL folder already loaded, you won't see any call to the TCM GetList when switching to a TCM folder already loaded.

They are cached in memory of the browser only, not on disk. You do not have to clear cache or anything else to get the latest content. You should notice that this cache can "jump between windows", so you typically have to make sure all Tridion windows are closed if you want to drop the client side cached items completely.

For example: Open the CME, then open an item, then hit F5 in the original CME window. Your client side cache will be moved to the window of the item you opened and once the main CME window is reloaded it will get it's Tridion content from the copy stored in the Item window. This is really nice when it keeps all windows in sync with changes you make, but can be a tad confusing when debugging and forgetting one or another Tridion window is open.

Thumbnails are cached in the browser (using the standard browser cache for images) and on the server hosting the Tridion UI. When the ECL Provider specifies an item has a thumbnail, it must provide an etag for the thumbnail. An etag is a string that must change if the thumbnail changes, and should stay the same if the thumbnail is not changed. For example the SDL Media Manager ECL provider use the newest "last modified" date on a distribution and all it's contained programs - it can't just use the last modified date of the distribution as changing the program included in the distribution would require a new thumbnail.

ECL includes this etag in the URL of the thumbnail. This allows ECL to specify that the browser never needs to check the validity of it's cached thumbnail. So the browser will not request any images from the server if you browse thumbnails already displayed earlier. Unlike the folder structure, this cache is persisted to disk by the browser.

The server side cache of thumbnails is handled almost like the server side thumbnail of standard Tridion multimedia components. They are even stored in the same folder. The difference is that they are stored in a zip archive. Not to compress them (they are already in a compressed format) but to associate some metadata to them. This metadata includes the etag and the ECL Provider version stored in text files inside the zip file allowing the caching service to quickly check that the thumbnail is based on the latest data before returning it to the browser. Each service you have hosting the Tridion UI will have it's own cache.

The updating of the cache basically flows as follows:

1. The item is changed on the external system
2. A user refreshes a folder containing the item in the Tridion UI (or navigates to a not previously loaded folder with the item)
3. ECL retrieves the items from the external system, including the new etag
4. The new etag results in a new URL of the thumbnail being inserted in the page, resulting in the browser making a request for the image
5. The server cache notices it's cached version does not have the same etag, so it request the latest data from the ECL Provider
6. The server cache request the ECL Provider to render the thumbnail
7. The server cache stores the thumbnail with the etag metadata
8. The server cache sends the thumbnail back to the browser

There are a few steps here where the content can be changed on the external system after the etag is returned to the client, but the "workflow" shown above will always result in the returned thumbnail to be at least the version expected or newer. So you will never have an "old" thumbnail stuck in neither the server cache nor the browser cache. They might have newer content than they "think" they have, but that is not really a problem - the thumbnail is just a refresh ahead of the item itself.

Answer 2

You are right in guessing that the CME does caching. The part in ECL which integrates with the CME is implemented via a GUI Extension using the Anguilla framework, and browser caching plays a role here. This is why when deploying new GUI extensions we increment the modification number in the System.config file to force the browsers to get all new versions of the cached assets.