Thursday, 14 April 2011

Your call...Qlikview Server and AccessPoint

kaushik said...

I would like to learn more about Qlikview Server and AccessPoint.

A brief guide to QlikView Server (QVS).  It is worth noting that the QVS Reference Manual is really good now and explains the specifics of this subject really well.

So, QlikView Server is a version of QlikView that runs on a server!  Simple, eh?  QVS will load documents into memory on the server.  When a client connects, QVS will send enough information to that clients so that they can display the information on their screens.  When the client makes a selection, QVS uses the memory and CPU power of the server to process that selection and then sends the screen updates to the client.  This means that the client doesn't require to have enough memory and CPU to handle large volumes of data and complex calculations - hence why simple clients such as iPhone and iPad work so well.  The client just needs enough CPU and memory to render the screens.

QVS only loads each document once.  As each client connects, QVS will apportion them a separate area of memory to handle their data requirements (mostly cache of charts).  A "rule of thumb" is that each client will require and additional 10% of the document's memory requirement.  So if the document loads into 1GB of memory on the server, each client will require approx. 100Mb of additional memory.  As each version of QlikView has been released, their memory handling technology has got better and better and v10 will handle many more clients in the same memory than, say, v8.5.

There are now just 3 main client types (previous versions supported a Java client also).  First, QlikView Desktop can be used as a client to access documents from a server.  When used as a client, you would notice that buttons such as "Save" and "Reload" are disabled because they make no sense for a client - the server will handle all of that.

The second client is the QlikView plugin for IE.  This is an ActiveX plugin that sits inside Internet Explorer.  It shares the same code base as QlikView Desktop so the experience is very similar.  It is still a "thick" client so does require installation - although it comes with an MSI for automated installation.

The third, an easiest to deploy, is the AJAX client.  This doesn't require any installation because it works within a browser such as IE, Firefox, Chrome, etc.  As of QlikView 10 SR2, it is also supported in mobile devices such as Safari for iPad using HTML5.

The majority of Plugin or AJAX end users will access their documents via AccessPoint.  AccessPoint, by default, takes a user's Windows Authentication information and will be able to present to them all of the documents that they have access to.  This means users won't be confused by seeing documents that they won't be able to open.  Users can also set "favorites" in AccessPoint so that they can default to seeing their most used documents.

Windows security is the default for QlikView server but not the only method available.  By turning on QlikView's DMS authentication (not available in Small Business Server), the task of authenticating the users can be given to any other type of directory service or even a completely custom form.

Stephen Redmond is CTO of CapricornVentis a QlikView Elite Partner


  1. Very good summary of the back-end technology.

  2. I am trying to confirm that Qlikview Mobile will work offline if a user downloads the documents locally via AccessPoint. Is this true?

  3. QlikView "mobile" is a connected technology. All clients will need to have an active connection to the server.

    The only disconnected client available is an installation of QlikView Desktop on Windows with a local QVW - which may have been distributed from QlikView publisher.

  4. Nice document.. helped me a lot.

  5. This is a very good document about the basics of the QVS. I have a question for you Stephen.

    Have you ever encountered a problem where the QVS scheduler stops updating QlikView documents on the server? I am currently having an issue where some documents are loading on the scheduler as normal and some fail to load and update on the server. I think this is due to the documents use of large volumes of data in the load. Am I correct in saying that or is it something entirely different?

  6. Turn on the Create Logfile option in the document properties.

  7. This comment has been removed by a blog administrator.