Qlik Architecture Deep Dive Blog

[Levi_Turner]

How to persist a user's session in Qlik Sense

[Levi_Turner]

What is “time-to-live”? To have the answer make sense, we need to take a step back and outline how a connection to the Qlik Sense Engine occurs.

At a high level, when a user opens an app, the Engine processes the user’s identity (for use if Section Access is applied) and constructs a ‘session’ for that user. The most valuable information that the session’s cache contains is the selection state of the user:

 in this example, the user has selected the value A for the dimension Alpha

When the user closes the browser (or otherwise ends the connection to the Qlik Sense Engine), the default behavior is that this session cache is destroyed:

In Qlik Sense November 2017 or newer, there is a configuration change which can allow this session to persist after the user has closed the browser. As background, this option was a result of the work that Qlik undertook to be able to have a native iOS app. In the iOS app there is the need to retain the ability to reopen a session quickly as there is no multi-tasking available on that platform. So for example, a user may be doing analytics inside of a Qlik Sense app, need to check their email for the name of a company, customer, sales rep to allow them to drill into that data point in the Qlik sense app. The practical work-flow would be to minimize the Qlik app, load the email app, search, find the detail, reopen the Qlik app.

There is a more exhaustive write-up available on Qlik’s Support Portal (link), so do review it on how to configure this setting in the Qlik Sense Engine. For this post, the key insight is that there is an ability to retain that selection state for a configurable duration:

The scenarios where this configuration can prove useful include, but are not limited to:

• High concurrency environments where the computational overhead of Opening an app (OpenDoc) creates bottlenecks
  • Example: heavy use of section access
• Environments where it is desirable or required to have embedded Qlik apps which render extremely quickly
  • Example: Mashup in an internal intranet site

The obvious next question is how long should I persist the session? The direct answer will be, it depends. The primary dependency here is what is the user behavior. If users generally open the app at time 0, do analytics, then come back in an hour, then persisting the session for 1 hour + some flex time makes sense. For more specific guidance, use the session sheets on the Operations Monitor app and trace a user who has multiple sessions per day.

[colinodonnel]

Hello Levi,

How would this work for folks to log into a company system remotely.

For home worker developers, the remote access link here is a little frail and can cause access to be temporarily disconnected.

This means that during a load script , when executed remotely, also fails due to the error "connection failure". Same applies when writing code that hasn't been saved regularly.

Cheers,

Colin

[Levi_Turner]

I don't have a particular reason to believe that TTL would address either of those issues. For the reload aspect of things, the persist connection seems integral to the reload completing. On my end, I tested things out with a SLEEP command followed by a data load. The script log goes as follows:

Sleep 10000
Execution Failed
Execution finished.

For the load script saving aspect, I would doubt it would help there. The rationale for that variant is that when writing script in the Data Load Editor, the changes are made locally and stored in the browser's cache until they are written. The Engine's state at the time isn't involved. But this one I am less sure about. You're certainly welcome to test and report back. Cheers