QlikView Reviews

After seven years with this product, our number of new reports each year is still trending up, and the number of users is trending up. QlikView is helping us to uncover and address report/analysis needs that we never knew existed before.
QlikView was a great solution for us based on our requirements: small business size (1200 users, mostly blue collar); no requirement for data warehouse, ability to do ETL within the load script (that's what eliminated Tableau for us); ability to to share interactive reports readily between users; and most important: optimized user experience, including easy to learn/use and short development cycles. We also needed integration with ESRI GIS which is (finally!) coming this year with a functional extension. As other departments come on (we are one department in a large-ish City) I think we will be able to manage the enterprise deployment through expression repositories, change management tools, and following other best practices. Our business users love it.

PART 1
---------
QlikView is a great business discovery tool that can easily generate excitement among business users. However, to build out a QlikView system that can support tens, hundreds, or even thousands of users is no easy task. As a QlikView consultant I have seen these scenarios many times:

- A business analyst is eagerly showing an IT manager the beautiful dashboards he/she builds in QlikView, and can’t wait to show the dashboards to hundreds of internal and external users;
- A business executive wants all business users to self-service their information needs through a QlikView platform.

Often times the IT managers seem to be less excited than their business counterparts. To be fair, in order to build a solid system, IT managers have a lot of questions that need to be answered. Let’s take a look at the most commonly seen ones (I have to warn you it’s a bit technical).

-- VMware for the servers? --

Nowadays most IT infrastructure professionals are in love with Virtual Machines (VMs). With its lower cost and flexibility in terms of horse power, VM seems to be the way to go for all enterprise applications. Well this is almost true for QlikView. All components of QlikView services can work fairly well on VM except for QlikView Server. This is because QlikView Server does the heavy lifting in-memory data processing, and the extra VM layer is going to slow it down, a lot. Most seasoned QlikView consultants would recommend at least using a physical machine for the production QlikView server.

-- Separate Publisher from Server? --

The two most important components in a QlikView system are the QlikView Server and Publisher (aka Distribution Service, I am a QlikView veteran so I will stick to the old name). Most people install all components on the same machine but as your data volume and user base grow, people frequently see these two components getting in the way of each other. At this point, it might be a good idea to put Publisher on a second machine (by the way, that second machine could be a VM). The good news is you can still manage both the QlikView Server and Publisher from a single QlikView Management Console (QMC).

-- QlikView Web Server or IIS? --

QlikView comes with its own web server, which is a light version of Microsoft Internet Information Service (IIS). In a perfect world, where all users are Active Directory users, and the number of users is small, QlikView’s web server works pretty well. For a large user base deployment you might want to choose to use IIS because it’s more scalable. IIS also gives you more security options.

-- Security Integration --

Security is always a big issue in an enterprise. Typically security includes authentication, which is about making sure a user is who he/she claims to be, and authorization, which is about letting the user see only what he/she is allowed to see. In the real world, we often see QlikView Publisher and Section Access can handle authorization pretty well, while the authentication is a bit more complex. This is because QlikView does not do authentication itself, it always relies on third-party authentication like NTLM, SiteMinder, WebSeal, etc. This process is also known as Single-Sign-On (SSO). This normally plays well in an enterprise because usually there is already a standard authentication product in place. The good news is, if the existing standard authentication product happens to be NTLM/Active Directory, QlikView can work with it out-of-box with no additional configuration. Otherwise, the third-party authentication product needs to inject the user id into http header and QlikView needs to be configured to read user id from http header. If the QlikView Servers are also accessed by outside people, it might be a good idea to setup a reverse proxy.

I hope by now you get a sense of the extra “behind the scenes” efforts that are necessary to make your QlikView system successful. In my follow up blog, I am going to talk more on topics such as high availability, storage, and running load tests.

PART 2
---------
In my last “QlikView Enterprise Deployment” article, I discussed VMware, the benefits of separating Publisher from QlikView Server, the choice of QlikView web server vs IIS, and security. However, there is more to consider in making your system solid.

-- High Availability --

The QlikView deployment has been so successful, people cannot live without it anymore. All of a sudden IT’s are victims of their own success. People are demanding high availability and high performance of the QlikView system, which of course will make the system more complicated. QlikView Servers need to be put on more than one machine, and a load balancer needs to be put in front of these machines. QlikView Servers also need to be clustered. By doing this, if one server is down the load balancer will stop sending users to this server. Users also enjoy a better response time because they are spread across multiple QlikView Servers.

The same concept also applies to Publisher. I have seen customers trying to get many dashboards refreshed (e.g., month-end or quarter-end) in a short timeframe. It might be a good idea to also install Publisher on multiple machines and cluster them. If one Publisher goes down, QMC will wait for it to be back to normal before sending data refreshing tasks to it again. In the meantime, QMC keeps sending tasks to the good Publishers and nothing gets interrupted.

-- Storage --

A lot of QlikView Servers objects (sessions, shared objects, bookmarks, licensing information, etc.) are stored in a set of system files. When QlikView Servers are clustered, both servers read and write from the same set of system files, which can cause contentions. Some people would use one of the QlikView server’s hard disk as the storage for these system files. This is normally fine except that when that server is down, the good servers cannot work either because the storage location is not there anymore. The best configuration we have seen is to use a SAN owned by a third windows server as the storage, and that windows server can be a VM.

-- Load Tests --

Every component of your QlikView system is properly configured and it looks like it’s ready to go. But wait, how can it be sure the system can support the desired user load and data volume? The only way to find out is to run load tests. QlikTech offers a great tool that is based on JMeter and it is relatively easy to setup. The tool can automatically generate JMeter scripts based on specified testing scenarios, and it can simulate any number of concurrent users. The testing results can be loaded into QlikView for analyzing. Of course, if the company has a strong load testing team that uses other tools like LoadRunner, you can also use your own tool to perform a load test.

These are the most common things people consider in an enterprise deployment. I hope you enjoyed reading it as much as I enjoyed writing it.