Skip to Content

You probably already heard of the new exciting features provided in the Portal for SAP Enhancement Package 1 for SAP NetWeaver 7.0, if not – I recommend you read this blog post  (What’s New in the Portal for SAP Enhancement Package 1 for SAP NetWeaver 7.0).

 One cool new feature is the Navigation Cache Preloader, it allows you to automatically load certain predefined user roles without waiting for the user to actually login into the portal and initiate the load of the roles himself.

What is it good for? If your user has many roles, his initial login will be rather long since the roles are not cached yet and need to be fetched from the database. In addition, multiple users logging into the system right after restart while the system is “cold” may put some extra stress on your system, causing “peaks” in CPU and high response time. Using the preloader makes it possible to automatically load roles on server startup, making them available on cache when the user asks for them (think of “push” vs. “pull”). Since the preloading is usually done when the users are not using the system, it “smoothes” the load on the system and eliminates possible peaks.

A common scenario would be, for example, if your boss has something like 50 roles and it takes him ~2 minutes to login – preloading his roles may reduce the login time to only 2-3 seconds. Not kidding, actual real-life case! So if you want to become an IT super-hero and really save the day (or at least a considerable time of it) and you think yourself as brave enough – keep on reading! It may be worthwhile for you.

How does it work?<br />One important prerequisite is that the navigation cache will be activated; otherwise there will be no point in preloading the roles. Some readings about navigation cache activation and configuration can be found here  (

By using the Preloader the portal fetches the user roles and stores them into the navigation cache. The roles in the cache are being reused and are not user-specific, so every user that tries to access the same role will benefit from it being already in cache.

Other possible configurations – you can specify how deep this fetch should be – for example, fetch 3 levels deep into the navigation hierarchy (will include also the detailed navigation structure).  You can even define which Locales to preload, so you can preload the roles with the German and English translations for your users’ convenience (or any Locale that is relevant).

Who is it for?<br />I don’t recommend activating it automatically, you better think if this can actually help. There is no need to preload roles to cache if they are rarely being used – it just takes up heap space. I think that if you have a problem that requires the Preloader, by now it will be obvious to you.

Activation and configuration<br />Login to the portal as Administrator, navigate to “System Administration” -> “System Configuration” -> “Service Configuration”, on the list of services look for “”. Navigate into the tree and click the “CachePreloaderService” to open the configuration screen.

Preloader configuration screen

Now you have two text fields:

Run on startup – true means that the preloader will automatically run with the configuration after the server is started. False means it will not be activated.

Users to preload – here it get a little tricky. From the name you already understand that you can define more than one user, the format is as follows:

[<user name>:<navigation levels depth to preload>:<leave this as false, reserved for future use>:< comma separated list of Locales>]<br />you can add additional user configurations by using semicolon, for example

myUser1:2:false:en;[myUser2:4:false:en,de]… and so on

So which users should you use? You can specify existing users, or create a new user for the preloading and assign it with all the roles you want to preload.

How many roles to preload? How deep?<br />This is the big question, and sadly there is no easy answer. Basically it will require trial and error until you get the best configuration for your need. What I can provide is some insights that will help you with this process.

First and most important, as I mentioned earlier the Navigation Cache should be activated and running  (*. The navigation cache has a configurable capacity of how many objects it should store and for how long. So, for how long? If you have a production system and the content is not changed during the week, you can safely define the navigation cache expiration to 1 week. Anyway, you can always manually flush the cache when needed. <br />How many objects? The default configuration is set for 5000 entry-point objects and 5000 navigation nodes, it should be enough for most cases. What you should do is to check how many objects are there in the cache (both parts) after preloading – if you are way below the limit it is OK (users will probably use a few additional roles for their normal portal activity), if you are close to the limit then you should either set it to higher number or play with the number of roles and level depth that you are preloading.</p><p> </p><p>Testing for success

*As always testing is key for success, and here there are additional things you should know. Be careful, it is going to be a bit techi.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Daniel Rothmund

    I think the preload function is a good idea.
    Is it right that I must refresh the preload cache every navigationcache refresh / delete ?


    1. Yoni Mizrachi Post author
      Hello Daniel,

      If you refer to clearing the cache/cache expiration then yes, you are right.
      I will elaborate a little, so you won’t think that we simply ignored this use-case :).

      We had some discussions about this issue; basically there is an option that someone will only want to run the Preloader once after restart to prevent the initial peak when everybody connects to the server at the same time. We were also afraid that having it automatically run after every clear/expiration may add overhead to the system instead of helping (for example in case the system is configured for very short cache validity period, or frequent refreshes). So we didn’t want to bind together these two actions.

      However, In the next EHP this is solved (sorry, enhanced!) by adding configuration option, so you can configure it to automatically run after cache expiration or at constant intervals to refresh the cache. I think this may be quite useful.



Leave a Reply