In a recent article I described a new feature introduced in IP15.3 called ‘white listing’ where one could define invocations which would not lead to a reset of the SessionTimeout timer. Particularly interesting, because one could ‘white list’ the Message bar (or better call it ‘Notifications’), so that your session would nicely time-out after the configured time. Regardless whether or not you are pulling broadcast messages from the server at the fixed interval at which it is configured.
On the other side of the medal, there are these scenario’s where one would like to prevent a session time-out to occur. Typically a session time-out is configured at say 30 minutes or so. But there are always use-cases where 30 minutes in general would apply, but not in 100% of the cases.
Working with a financial services customer, an important group of their end-users complained that while writing call reports, they quite often lost their work due time-outs. How frustrating that would be, is clear. Pulling the cables and throwing your laptop of desktop out of the window (especially if it happens on Friday COB). You could try to train, and tell them to commit once and a while. But that will take a way only a percentage of the pain. And the behavior simply is damaging to the overall UX!
Trying out a simple approach, which would work in both HI and OUI – I came to the following rough-edged solution.
- On the Applet_Load (= browser script) call a function “keepAlive()”
- This keepAlive() function would, well, keep the session alive.
But how? The bare minimum would be just these few lines of code:
There is no magic, just a recursive function call every 5000 milliseconds. During this recursive call, the call to theApplication().GetProfileAttr() forces a server-rountrip. And it keeps your session alive. Of course, 5000 is just a sample figure. Reality, this should be a bit less than the SessionTimeout configured the eapps.cfg.
The beauty of this tiny solution, you can make it very selective. Add some little logic such that the code. Simple as that.
The same would work for both HI and OUI clients. If you have to be in an OpenUI-only environment, I would re-write it as a physical renderer instead. Leading practice: prevent leveraging traditional browser scripts. At some point in time these will be deprecated.