Forever on Display – DataOnThe.Rocks

Addicted to your KPIs?

Are you one of those FOMO’s who have their smartphone glued to their hand?

Do you have a team who needs to be in control of your business, every single minute of the day?

There are many business scenarios for which it makes sense to have Qlik Sense on display all day long.

Sales desk dashboard
Trading floor dashboard
Manufacturing assembly line monitoring dashboard
Freight office dashboard
Screen display in a no-mouse no-keyboard laboratory
Presentation screen at a business fair

And many other use cases you can think of.

In short, it is typically useful to have a dashboard on display without human interactions when there is a need for near-real-time analytics and you don’t have to interact with the dashboard.

So, what’s the challenge here?

By default, your Qlik Sense session will end after 30 minutes of inactivity.

What are the options to make this work?

There are server-side and client-side approaches.

By server, I mean the Qlik Sense server and its many services: proxy, repository, engine, scheduler, printing…

By client, I mean what you load in your browser when you open a dashboard, the user interface that lets you make selections and build new charts.

1. Server-side: how can you extend the session timeout and what are the implications?

There is a timeout value in the virtual proxy configuration settings. However, since that is a global setting, increasing its value for a day/a week will influence the overall site performance. If sessions last longer for ALL users, the memory won’t be released, ever, it will instead pile up, so over time, the site performance will decline drastically.

This is a no-go.

2. Client-side: how can we emulate user interactions?

User interactions are made of selections, which generate browser events, HTTP requests and Web Socket messages.

Browser events can help maintain a session active in the browser. However, without client-server interactions, the Qlik Sense server will close the server session and disconnect the client.

HTTP requests are initiated from the client, each request expects a server response. HTTP requests happen mostly when we load an app or a sheet.

A solution based on HTTP requests would move through a list of sheets, like this automated Sheet Scroll extension. This works, as long as you are ok to move to a different sheet or reload the active sheet.

Web-socket messages are bi-directional. The same web-socket channel lets the client pull data and the server push new data sets. Let’s see how we can trigger additional web-socket messages from the client.

How can we maintain the web socket connection active?

We need any engine API request that won’t make the Qlik Sense server spend too much CPU on it. We have no intention to use the results, we only want to fake that we are active in the client.

We also want to be able to use that solution in every application where we need that feature, therefore building an extension will serve that purpose of reusability.

A simple API method is the getList-method from the capability API. The method can return a list of Fields, Measures, Dimensions, Bookmarks, SelectionObjects, Snapshots, MediaLists, sheets, MasterObjects, Variables and stories.

These objects can have many properties and attributes. One of the simplest object types is probably the variables.

For that example, we will use the list of variables, below is a code snippet.

// Connect to the current app:
var app = qlik.currApp();

// Fetch the list of variables:
app.getList('VariableList');

Simple, isn’t it?

If your applications happen to have, for some reason, thousands of variables, feel free to fake the activity with another object type – bookmarks can be a fair choice too.

Since we won’t use the response, the smaller number of objects in the response the better.

The second and last key piece of that extension is the frequency of requests: we need to repeat that operation before the session would timeout.

The extension is initialized to run every 25 minutes.

This value can be changed in our example with any value above 14 minutes, 14 minutes was set as a low limit in order to avoid any potential server impact with too frequent requests.