Book Image

QlikView Unlocked

By : Andrew Dove, Roger Stone
Book Image

QlikView Unlocked

By: Andrew Dove, Roger Stone

Overview of this book

QlikView Unlocked will provide you with new insights to get the very best from QlikView. This book will help you to develop skills to work with data efficiently. We will cover all the secrets of unleashing the full power of QlikView, which will enable you to make better use of the tool and create better results for future projects. In the course of this book, we will walk you through techniques and best practices that will enable you to be more productive. You will gain quick insights into the tool with the help of short steps called ”keys,” which will help you discover new features of QlikView. Moving on you will learn new techniques for data visualization, scripting, data modeling, and more. This book will then cover best practices to help you establish an efficient system with improved performance. We will also teach you some tricks that will help you speed up development processes, monitor data with dashboards, and so on. By the end of this book, you will have gained beneficial tips, tricks, and techniques to enhance the overall experience of working with QlikView.
Table of Contents (16 chapters)
QlikView Unlocked
About the Authors
About the Reviewers
Hidden Image List

Environments and architecture

The size of your QlikView deployment, budget, and future plans will directly influence the way the environment is built.


In the simplest QlikView Server installation, you have a single machine (physical or virtual), where all development, user testing, and production takes place. There's nothing that wrong with this approach, and we've seen plenty of smaller installations where this is the case. A better solution, though, is to at least keep development and production separate. However, larger deployments and those requiring more control over access to QlikView documents tend towards multiple machines: one each for development, user testing, and production. If you use QlikView Publisher, you may wish to put this on its own server. Obviously, there is a cost implication as multiple Server licenses are required if QlikView is installed on more than one machine, and the Publisher license is an additional cost as it's not included in the QlikView Server license.

A further consideration in larger deployments or for mission-critical systems is whether to go for multiple production machines, employing load balancing and clustering.

How to do it

As with all things, the way the environment is built depends on what you need to deliver and to whom. Let's consider a few example scenarios. Hopefully, one of these will help guide you toward your goal. We'll assume, in all cases, that you could have the option of carrying out all development on PCs so that you only need effectively to design test and production environments. Bear in mind that the development PCs, unless running standalone desktop licenses, need access to a server at least every 30 days to renew their licenses, which could be a problem if you spend long periods off-site. There's a further "gotcha" here, too: if you use QlikView Test Server licenses, you cannot renew the PC license from them. It has to be done from the 'full' server license. Clearly, if developers are not supposed to have access to the production server, this has a security implication.

We would normally think of having three environments: Development, Test and Production (or Live). How these are implemented will depend on the number of machines at your disposal. Ideally you would have three or more, but of course there will be a cost implication because QlikView Server is licensed on a per machine basis. Therefore it is cheaper to implement on only one or two server machines but implementing on three or more will give a more robust and clearly-defined environment. Let's consider the options, based on one, two, three or more machines:

  • Single machine: This is a simple environment. Development, testing, and production all reside on the same machine. QlikView Publisher may also be on the same machine. Take care to ensure that users know whether they're looking at test or production. You can separate these using different mounted folders in QlikView Management Console.

  • Two machines: The big question here is whether the test environment should be on the development machine or the production machine. For safety's sake, we would always keep the test environment on the development machine.

  • Three machines: These are deployed as development, test, and production. This is a nice, easy solution that keeps everything tidy and offers the greatest safety and control in terms of code versions. It is tempting to think that the test server could be used as a fallback in the event of production server failure. We would avoid this as it would require quite a lot of work, so unless you can reimage the test server as a production server quickly and cleanly, this is probably not a good strategy.

  • Multiple machines: Stepping into enterprise-level environments leads to a wide variety of options with opportunities for load balancing and clustering. In large deployments, development and test most likely stay on separate machines but production is spread across two or more machines. This allows for greater resilience in the event of the failure of a production server and gives the opportunity for horizontal scalability. As more users are added, the environment can be scaled out with more servers. It is possible to arrange a cluster in such a way that all documents can be served by any of the machines, giving great resilience. QlikView Publisher can also be clustered, providing similar resilience and scalability.

The QlikView server has the following components:

  • QlikView Directory Service Connector (DSC): This keeps track of the users.

  • QlikView Distribution Service: Publisher effectively extends this functionality if you have it. This is responsible for the reload, distribution, and reduction of QlikView documents.

  • QlikView Management Service (QMS): This is the management console, which sends settings to other services.

  • QlikView Server (QVS): This hosts the QlikView files and allows user access.

  • QlikView Web Server (QVWS): This can be replaced by IIS if required. This is the web server for Access Point and AJAX and is also responsible for load balancing the QVS.

An example of clustered, software load balanced server deployment can be seen in the following diagram:

An example of clustered, software load balanced server deployment with clustered Publisher is shown in the following diagram:

Don't underestimate the importance of this area, especially if yours is an enterprise-level deployment.

QlikView Test Server licenses are available for half the price of full licenses. These are fine for a true test server, but avoid using them for a development server because of the security implications.

Clustering servers enables the construction of very large and scalable environments, and it's straightforward to add extra servers to a cluster. So, if there's the likelihood or requirement to scale out, consider a production cluster from the start.

Bear in mind that the QlikView Server and QlikView Publisher licenses are sold on a per-machine basis. So, the more servers you have, the more licenses you need. This applies to cluster licenses, too—for instance, a three-machine QlikView Server cluster would require a three-node cluster license at three times the cost of a single server license.