There are many pitfalls to beware of when upgrading your NetWeaver landscape (by installing a new SP or EHP). The preparations and logistics themselves can be exhausting, not to mention the pounding heart when you restart the server for the first time. Let’s assume everything went smooth, all those weeks of preparations paid off and you can sit back and relax (hey, did you ever have doubt?).
Well, you get the picture.
What could you do to avoid this?
Prior to the upgrade you could change the cache configuration in the server from 1 week (the most common configuration) to 1 day, and later reduce it to 2 hours. This will make sure that the old resources would be kept in the browser cache for a minimal time so you will likely to avoid this problem. This introduces additional tasks and worries – did you remember to make the change in the configuration? Did you remember to set it back to the original value after the upgrade? Is there a performance impact on your server? Did end users feel this?
Not the best solution, but unfortunately you didn’t have better option.
Introducing the “resource versioning” solution
A new feature in the portal allows you to gain better control of your static resources.
The result will be a URL that looks similar to this:
http://… Irj/portal/… /someScript.js? 1c506cf475c726e63cf9a72279a06f3f
Your code will look similar to this:
IResource myResource = request.getResource(IResource.SCRIPT, “scripts/ someScript.js “);
The browser will store this script in the cache under the full URL, including the unique string after the ‘?’.
Each time you deploy an application the unique value will be regenerated, so if this application contains static resources and they will be requested again by the PRT API the link will be created with the new identifier and the cached version will not be used.
Since you usually don’t make frequent changes in production there is no risk to performance (because of invalidated cached content). However, if you have an emergency fix, or an upgrade, you can safely assure that end users will get a fresh copy when they connect to the portal.
Not all resources in the portal are using this versioning feature, but the good news are that those who don’t usually have similar mechanism. In order to benefit from this new feature in your custom apps make sure you use this API for adding your resources to the response. Now you get this control for your custom applications for free, could it be any better?
Are there any special considerations?
One side effect is that the browser may hold redundant resources in cache, i.e. two scripts with same name but different identifiers. The browser cache has a policy for managing its storage and should quickly overcome this, when the cache threshold is reached the old resources will be deleted. No worries here.
Is it expensive to generate this identifier? The identifier is generated in the deploy process anyway so there is no additional overhead for generating it – just remember that each time you deploy an application the identifier is regenerated, even if you deploy the same application with absolutely no changes.
One more thing, if at runtime you ask for the resource without the identifier (ask for http://…/someScript.js) you will get the current version and it will be kept in cache under this name. Same with any random string you put there (ask for someScript.js?abcd) , there is no mechanism on the server side that validates this string to match the application identifier – it is just for controlling the version on the browser cache. So, if you run load test or have automated scripts that call resources you don’t have to use complex correlation rules to match the identifier – just be sure to clear the cache first.
A thought – if all applications in the portal used this method then theoretically you could cache resources forever, knowing that when a resource is changed you have full control to replace it immediately for all users. Unfortunately this is usually not the case – the cache expiration configuration in NW is applied on all resources served by the server weather they have version id or not, and some do not have it so they might get “stuck” in the cache without a way to control them.
How does it look like?
Before activating the versioning feature:
After activating the versioning feature:
How do I activate it?
Login to the portal as System Administrator, navigate to System Administration -> System Configuration, and on the detailed navigation choose Service Configuration. Browse the Portal Runtime tree -> right click Central Configuration, choose “Configure”. Look for “js.SupportVersion” (I know, not the best name) – change the value to “true” if you want to activate the feature, “false” will deactivate it. Perform a restart and you are set.
It is easily reversible and doesn’t make permanent changes (besides the resources on the browser cache), so don’t be afraid to evaluate and play with it.
Suggestions, feedback, thoughts and constructive criticism are always welcomed :-).
The feature is available in the following versions:
- NW 7.0 EHP2 SP0 – the default value is “false”
- NW 7.0 EHP2 SP2 – the default value is “true”
And an important update
my colleague Irit Okshtein collected and compiled a “Performance Best Practice Guide for NW04s”, it includes important practical and conceptual information that can really help you out. If you have NetWeaver landscape you should read it!
The guide can be found in the following link: