KM Cache for portal application files

When developing a portal application (PAR) you may want to use some custom Javascript, CSS, images and other files. To make sure that the user doesn’t has to load all the files with every access to the application again, the portal provides a generic cache. This cache is configured in Visual Administrator (HTTP Provider Service) and is valid for all portal applications. This means that your application’s file will automatically be cached by the portal and by the browser.

To give you more controll over the cache behaviour, the cache can be defined by the iView that encapsulates the application. This won’t work when accessing the component directly (URL) or the referenced CSS, Javascript and images.

When the browser is accessing these files for the 1st time, the server will send back some cache meta-data

• Last-Modified and
• Cache-Control

Cache-Control defines the cache time of the file. This value is controlled by Visual Administrator and is valid for all applications deployed on the AS Java

The detailed cache (image taken from Firebug) information reveals when the file on the browser was last modified, last loaded and when the file will expire; that is, when the browser will request it again from the server.

This generic cache results in non-optimized cache values for some use cases:

• You don’t want to use the cache
• Longer cache time for static files (like jquery) is needed

The easiest way is to extend the “Expires” parameter. The portal offers a client side cache for files stored inside the KM. This cache can be given a free chosen expiration time: from no cache to several weeks. Storing the additional files in the KM also means that you have a greater freedom in making minor changes to your application without the need to compile and deploy the whole application.

For the additional PAR files this means:

• Store them in the KM
• Create the cache
• Reference them in the application as /irj/go/km/docs/<path to cache folder>/<filename>

Let’s focus on step 2.:

Saving a document in the KM normally results in a no cache:

The server is not sending back a max-age, instead a private -this means that the document must not be cached by a shared cache (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) Problem with private cache: A private cache may cache the response. In case of the portal: the document won’t be cached. As this is good for KM documents, it’s not good when you want to use the KM to cache documents.

But: The KM offers the capability to define a cache time for documents stored in the KM. This is the client cache. The client cache configuration can be access by navigating to:<br />System Administration -> System Configuration -> KM

It is important to notice that you Mime Type has to match the mime type configured in the portal’s KM. This also means that you can activate the KM client cache (KM CC) only for a specific file type or have a different KM CC for different mimes. How to find out the Mime Types value? Go to:

The MIME types for the most used files are :

CSS: text/css0.1.

Javascript: application/x-javascript0.1.

Images0.1. JPG: image/jpeg

0.2. PNG: image/png

0.3. GIF: image/gif

After the KM CC is created, the portal serves the files with the new cache data. Acessing the files via Firefox, the HTTP response from the server looks now like:

In the Cache tab of Firebug:

*oh, to many images lost, THANK YOU JIVE