The trouble with data…

Having been working with QlikView for some time now, I thought it was worth writing a few posts about some of the slightly more interesting things we have been doing with it.

One of the requirements of a recent project was to develop a way of allowing users to:

• reload applications without being Document Administrators (and therefore having limited QEMC access)
• supply external parameters to the reload task (effectively specifying filters to limit data in a database extraction)
• specify security groups that would have access to the loaded application (or reload for “All Authenticated Users”)

The final result was a web application (screenshot below), running in IIS, that allowed user to do just that. It uses the QV Publisher API and was written in ASP.Net 4 using Visual Studio 2010.

What the web application does is to search the root QV documents folder and display those that already have a reload task associated with them. Documents with no tasks will not be displayed in the “documents” grid. It also recognises the User’s Active Directory credentials and searches the relevant LDAP to look for memberships of Security Groups containing the word “QlikView”.

Within our app, there was a requirement to allow the user to enter externally supplied parameters to the reload task, but this is purely optional – the application will work without them being supplied, due to flags we place in our QV script.

Effectively, what the code does in the background is to create a clone of the existing reload task that is attached to the document, replacing any existing supplied values with those supplied from the web form, run the reload task, and then delete the “clone”. It would be better if the code created a task from scratch, but we haven’t quite managed to to that yet with the QV Publisher API.

If people are interested in this application, we may well be able to package it up, make it a little more generic and release the source code.