Best practices for keeping your Qlik framework under version control

I’ve worked with multiple Qlik environments where  Qlik Deployment Framework (QDF) is combined with a version control system during the past years. This hands on experience from multiple environments combined with several interesting discussions with colleagues, clients and Qlik have given me an insight on dos and do nots. The following post is a part of my best practice when working with version control in a QlikView environment. Continue reading “Best practices for keeping your Qlik framework under version control”

Upgrading from Qlik Sense 1.1 to Qlik Sense 2.0

Qlik Sense 2.0 is  finally available.  A lot of installs and upgrades will be done in the coming weeks. Here is a guide on how I do my single node upgrades.


Stop all Qlik services except the Qlik Sense Repository before starting your backup. Turn them back on again when the backup is done.

I want to have the following backups before installing anything new.

  • Repository

  • Certificate

  • Logs

  • Qlik Sense Application files

  • Qlik Sense Repository files

  • The QDF file structure


You should always have a backup of the certificates. Without it you’re smoked.

  • SSL certificat

  • Client certificate

  • Certificate Authority (CA)

Details on how to do it I find on the Sense Help site: Backing up certificates

Postgree database

cd “C:\Program Files\Qlik\Sense\Repository\PostgreSQL\<database version>\bin”

pg_dump.exe -h localhost -p 4432 -U postgres -b -F t -f “c:\QSR_backup.tar” QSR

Log files

The Qlik Sense log files are located at  ´´%ProgramData%\Qlik\Sense\Log´´

Qlik Sense applications

%ProgramData%\Qlik\Sense\Apps\ (Which is  C:\ProgramData\Qlik\Sense\Apps\ on a  Windows Server 2008)

Qlik Sense repository – content and extensions



The QDF root

I prefer to use the QDF structure both in QlikView and Sense. Backup the whole root catalog. If you are not using it then just backup the folder/folders containing files used by your qlik sense scripts etc. Eg. standarized scripts, variable files and QlikView components.

Install Sense 2.0

Installation is the easy part of upgrading. Download the installation file from Qliks download site. Run the setup file. Click throug the welcome and license dialogs.

Choose “Quick upgrade”.  You’ll be prompted for Postgree SQL password and the password for the account running the services.  Make sure you have them in hand.

Upgrade complete

Hopefully you’ll see the same upgrade summary as in the picture above and you’re ready to go.



Sense it from your browser

A couple of months ago I discovered a neat Chrome Plugin for Qlik Sense. It allow me to drag and drop table data from my browser into a Qlik Sense application.  I haven’t used it a lot, but it is quite handy when you run upon a small dataset on internet that you want to capture into Sense. It is also quite sweet to use when demoing Qlik Sense.

Fetching the final premier league table into Sense.

premierleague.wikipediaI found the final Premier League standings on the 2014-15 Premier League page on wikipedia. I want to pull this data into a Qlik Sense application.


If you’ve installed the SenseIt extension you’ll notice a Qlik green barcart icon in top of your browser. When visiting the webpage holding data, click the SenseIt icon and you’ll a pop-up window where you should drag and drop your table.


The table will be preview in the extension window where you will be able to do configuration of the import by specifying column headers, decimal separator, thousand separator and whether you should transpose the table in question or not.

  • Click the “Create App” button.
  • Click the “Open App” button.

Viola! Your Qlik Sense application is created and loaded with your data and you are ready to start designing your application.


SenseIt is created for the Chrome browser, but I managed to install it on Opera as well without any problems using the Download Chrome Extension for Opera. SenseIt is also available as an open source project on Qlik Branch.


QlikView Server Super Agent

My latest Qlik re-discovery is the QlikView Server Super Agent, a power tool that monitor and log  QlikView services. It do also alert me or the IT administration by email  if one of the a services goes down.

Power tools

The QlikView Server Super Agent is one of the many small smart tools that are bundled into the QlikView Power Tools. The Power tool package is created by people at Qlik and may be used free of charge,  but it is not an official Qlik product and therby not supported by Qlik.

As far as I understand does the Power Tools only support QlikView 10, 11 and 11.20. Qlik Sense is not supported at the moment.


There application is simpel to set up. In the left pane you have a root node and to that node you add groups that you attach services to.


I see three main directions for structuring these groups and which one you choose all depends on the complexity level of your QlikView environment.

1. By machine

Create one group per machine and add the services in question.

2. By environment

When handling multiple environments  (test, acceptance test and production)  I suggest to create a nodes for each environment.

3 By environment and product

In non clustered environments where you have only one machine per product you do not gain much by expanding the structure with a prioduct dimension. In (larger) clustered environments I would considered creating groups based on environment and product such as “Test – Servers” and “Production – Publishers”.

Adding email notification


Entering the settings menu it is also possible to setup e-mail notification and adjust monitoring frequency and other settings such as log path and frequency.

When and how to use is

I use this tool locally when installing new  or upgrading old QlikView  environments. It gives me an status overview for all QlikView services. It does also work as a short-cut for launching another power tool QlikView Server Agent that allow me to start and stop services efficiently.

The notification feature is important  for an system administrator or someone who are to monitor the QlikView environment. For monitoring you will have to make sure that the application is running constantly. Normally you need to be logged in to a machine to run a application, but triggering the application from Windows Task Scheduler is an alternative. If you do that then make sure you set up the tool correctly for that user, you do not share  setting between user per default. To get rid of the logged-in or task manager requirement I would love to see the QlikView Server Super Agent as a service in the future.

Header image: Spy by Dan Hetteix from The Noun Project

QlikView 11.2 SR10ß

Technical Bulletin – QlikView 11.20 Service Release 10 Beta is now available

Qlik announced yesterday that they are opening the beta program for QlikView 11.20 SR 10. The main feature in this release is a change in the color handling of pie charts.

Follow the link if you want to know more or join the beta program. Note that the beta program ends December 3th.

The 9 folders of QlikView Deployment Framework

qdf-structureThe main building block of the QlikView deployment framework (qdf) is the resource container.  Every environment using QDF will be build using only one to many instances of this homogeneous structured entity.

When first introduced to the QDF the first thing you’ll notice is the container folder and it’s 9 folders structure. I’ll explain which they are and what their purpose in the section below.

The 9 folders

The folder names in a QDF container give you a good indication on what they contain. They are sense quite self-explanatory and after reading the section below you’ll be ready to start working with them.


You will place all your QlikView (.qvw) or Qlik Sense (.qvf) applications in the root or in sub folders of  1. Application. Only these two file types you should be kept in this folder. Prj-folders and version control files are exceptions that will reside inside 1.Application.


The path for QlikView data files. This folder will work as the source path where your application reads qvd files and/or the folder where you store qvds into.


The folder where all .qvs files that is to be included into your QlikView or Qlik Sense script resides. This could be qvs files you create yourself or the pre-made scripts that are bundled with the framework.

The key to QDF initiation is found in a sub folders of 3.Include It is called init.qvs and  is absolutely necessary to start using and take advantage of the QDF framework. I recommend all developers to click through these folders to get an impression of all shipped features that comes with the QDF.

Variable files and connections strings are typically placed in another sub folder to 3.Include. If you are using QlikView Components (QVC) then the Qvc.qvs file would be placed within this folder.


If you want to create a data mart to use in further data discovery or as the base in a power user sandbox then you store mart files in the 4.Mart. I would recommend to pre-model your mart in a qvw file for this folder. A set of carefully modelled qvd files could also do the trick, if a Select * From $(4.Mart)*  would give me a correct data model.


The 5.Configis the home of custom configuration files such as language setups and control documents. The Local config.qvs of QVC is a good candidate for this folder.


The place to store script files. It could be script files used by the QlikView publisher or by Windows scheduled tasks. This is also a good place for scripts that you manually run for making adjustments or manipulations to you container content.


The 7.Export path is where you put files generated by QlikView but is to be consumed by another system. Ex. csv or xml files for export to a web service.


The 8.Import folder like the 7.Exportintended for data transfer between QlikView and other system. This folder is used by the other systems to store their output files. Eg. the response of a web service.


The path for miscellaneous files that you do not fit into one of the above. I could be documentation, document and object extensions used by applications in the container.

All folders and sub folders in the QDF contain a Info.txt file. This file contains a short description of the purpose of the folder and the global path variable that will be available while scripting.

Getting started

Lets say you got your empty container. How do you start?

The key for initiating the QDF is to include the mandatory init.qvs file into your script. in the 3.Include\BaseVariable folder with relative paths like this.


Depending on which sub folder level your application is located within the 1.Application folder it is considered a good practice to expand the include statement to cover multiple alternative relative paths such as this.


By running this script you will initiate the QDF and you will have a set of variables generated into your application. Some of these applications are essential for the framework.

Container paths

The initiation will generate variables for all your container folders and standard sub folders mentioned above. If you use these variables instead of hard-coded paths in the script you won’t need to be concerned about where your container is located at the moment you run your applications.

Shared and custom variables

If you or someone else have defined shared and/or container specific variables then these will be loaded automatically.

Using the folder structure within a container

If you have initiated the QDF and are ready to go. What’s different when scripting?

Developing in a QDF environment doesn’t need much change in your scripting methods. To get started you should learn to use the path variables instead of absolute or releative paths.

LOAD   *
FROM C:/QlikViewFiles/MyContainer/2.QVD/MyData.qvd; 

FROM ../2.QVD/MyData.qvd;

FROM $(vG.QVDPath)MyData.qvd;

The QDF also supports fetching variables form other containers. You will notice that per default you will have variables for the Shared container defined for you. You may also import variables from other containers using the following function.

Call LoadContainerGlobalVariables('TransformContainer');

Details on how to set this up is not covered here but is well documented in the QDF documentation.

Summing up

The main difference between QDF and traditional deployment is in the structure. All containers in a QDF environment have the same folder structure and consists of folders with designated functions. This structure does not have to affect the way you script.  You are safe within the QDF as long you

  1. remember to initiate it with `init.qvs` in every application using relative paths and
  2. use the generated container variables instead of absolute and relative paths in the rest of your script.

Following these directions will not make you a better QlikView or Qlik Sense developer it will make you survive in the QDF while familiarising yourself with the structures and the functionality that the QDF has to offer.

I’m convinced that the QDF can make improve you and your organization’s  QlikView and Qlik Sense developer and administration capabilities. Start of simple by

  1. Following my two points above.
  2. Start exploring the folder structure and its content.
  3. Read the QDF developer guide that is included in the QDF.
  4. Join and participate in the Qlik Community Group: QlikView Deployment Framework

I believe that you will come a long way with these measures. If you need more help or support  contact an QDF expert. If you don’t have one in your organisation then your Qlik Partner.

Blogroll week 46

Medium – Responsive design: it’s an ethos, not simply a technique

A post by Qlik’s design strategist about responsive design and why pixel perfect design is not the way to for a business tool that is to be consumed on multiple kind of units.

Qlik Community –  Tree visualization

It’s not a blog, but could have been posted in one. Sven Uhlig have posted an advanced tree visualisation using the standard QlikView scatter chart on the Qlik Community. It is worth paying attention to.

BI-Review – Meet EasyMorph

Dmitry Gudkov the creator of QViewer are revealing more details about his latest project. EasyMorph, a datamanipulation tool that target end power users rather than developers.

Tool for extracting qvw variables into InQlik Tool syntax

I got great response for my blogpost about Powerful variable editing with Sublime and inQlik toolsfrom earlier this week. I tought I should complement it with a simple but useful tool for extracting qvw expressions into InQlik YAML-like syntax.

It can be useful when you want to start working with external variables on applications that you already have developed with normal expressions.

The expression extraction tool

The tool is an qvw that read out and format your expressions into the syntax used by the InQlik Tool for Sublime.
Screenshot of the Export variable to InQlik Tool syntax application
I extract the expressions using the following script:

‘vL.Expression_’ & AutoNumberHash256(Definition,Label,Comment) as Expression,
FROM [your.qvw] (XmlSimple, Table is [DocumentSummary/Expression]);

Feel free to download and use this tool. Please drop me a comment if you find it handy. Download the application: the expression extract tool

Powerful variable editing with Sublime and inQlik tools

Swedish version::   Kraftfull variabel-hantering med InQlik Tools

Centralized expression handling is a topic that rise in an organization when their QlikView environment matures. There are many reasons why one wants to move expressions and variables from individual QlikView documents into a centralized location. Often it’s about ensuring that a single kpi is calculated in the same manner for all graphs and tables in all QlikView applications. When its time to edit a kpi calculation then the  change will only need to be done at a central location and not in every object that uses it. The objects refers to this variable instead of using the hard coded expression. This increases quality and reduces time needed to implement the changes. In other scenarios it is the need to let other parts of the organization take ownership and responsibility for the kpi and calculation logic, not IT.

The use of external variables may also speed up your environment  by increasing the use of the QlikView and Qlik Sense cache. The cache will only be reused when two identical written expressions are used, but with small diffrences between expressions the cache breaks. Read the Qlik DesignBlog – The QlikView Cache to get better insights.

I have seen several creative ways to lift out QlikView expressions from documents into a central place.  I’m guilty of several of those solutions. I get the feeling that each developer or development team have their own method for handling this issue. The main principle and the desired result is always the same, expressions and variables are stored centrally and used by QlikView on across multiple applications.

The Qlik Variable Standard

In QlikView Deployment Framework (QDF), there is a, by Qlik, recommended standard for variable handeling. It contains both a suggested name standards together with a methodology and support for external variable handling. By using the Deployment Framework Editor you can create and manage variablefiles that by easy means can be imported into a QlikView document using the sub ‘LoadVariableCSV’ that is included in the framework.


Management and manipulation of the QDF variable files are a feature in the Deployment Framework Editor interface. This interface is sufficient during maintainance and overview, but for my frequent use ande edits use during the development phase I’ve found a better alternative.

InQlik expression editor for Sublime

InQlik expression editor is part of the open source project InQlik Tools, an add-on package to Sublime Text.

Using InQlik tools variables are written with a simplified YAML-like syntax in the Sublime Text editor.  In addition to saving the YAML-like document  InQlik Tools also saves a copy of the expressions into a QDF compatible variable file.

comment:Total income. 

This syntax feels natural and easy, compared to a csv-file. I feel more effective in my work working this way compared to editing the csv directly or using the QlikView Framework Editor. The output of the YAML-like syntax above will result in a csv  like the text below:

Variable Name, Variable Value, Comments, Priority 
SET vIncome, sum (income) ,, 
SET vIncome.Comment, total income. ,, 
SET vIncome.Label, Income ,,

It is possible to change output from csv to native QlikView script code (qvs), for those who are not using the QDF but want a centralized variable handling. The native qvs-file can be inluded into the script either by include or just copy-paste of thest,  as the qvs result looks like this:

SET vIncome = sum(income);
SET vIncome.Comment = Total income.;
SET vIncome.Label = Income;

Dollar expansion


In my own previous attempts in handling external variables i often wrestled with expressions using dollar expansions. QDF-handles this great, but also the inQlik tools qvs exports handles this with seemingly without any problems.


The  expression declaration above will result in the native qvs variable declaration as written below. Notice how it handles the dollar ($) problem.

 let vL.sumDynExp= replace(replace('sum([@(=DynExp)])','~~~', 'chr(39)'), '@(', chr(36) & '(');

Reference to other variables

InQlik expression editor are able to do something that  neither QlikView Framework editor, notepad or excel can do without carrying out a small development projects in advance. When using InQlik variable declaration you are able to refere to other variables and during export to qdf-csv or qvs expand thes references such that the referenced declarations is exported.

In the example below, I let the third expression be declared with references to the two prior.

Set: vL.income 
definition: sum ([income]) 
sets: vL.expense 
definition: sum ([Expense]) 
sets: vL.profit 
definition: $ (vL.income) - $ (vL.expense) 

By letting InQlik tool expand the variables during export I get  vL.Profit saved as sum ([income]) - sum ([Expense]) . No more manual tracing down multiple layers of referenced variables when tracking down a bug!


Centralized expression handling has several advantages, both in terms of management, accountability. It can also be benificial in terms of system speed and utalization of the QlikView global cache.

Qlik are pointing all developers in the same direction with the introduction of a standard variable naming and handling. I think that this standard will fill the needs found in many scenarios when it comes to variable handling and expression centralization. I see no reason not to start using the QDF standard format for handling variables unless you already have invested in other methologies. It is an easy and open standard.

I prefer creating variable files using InQlik on Sublime, but you could easily use another system or stick to the Deployment Framework Editor that is shipped with the QDF. The reason I enjoy inQlik variable editor is the possibility to in a efficient way build and reuse expressions. The declaration syntax is easy to write and read and I use the same syntax whether I choose to export to qdf format or plain qvs script.


Kraftfull variabel-hantering med InQlik Tools

English version: Powerful variable editing with Sublime and InQli Tools.

Sentraliserad uttryckshantering är ett tema som ofta dyker upp allt efter som en QlikView mognar. Det finns många skäl till varför man önskar att lyfta ut uttryck och variabler ut från enskilda QlikView-dokument och till en central plats. Ofta handlar det om att säkerställa att man beräknar samma nyckeltal på samma sätt i alla grafer och tabeller i alla applikationer. När beräkningen ska justeras behövs den ändringen endast göras på en central plats och inte inne i varje objekt som använder det. Detta höjer kvaliteten och minskar förvaltningstid. Andra gånger handlar det om att lyfta ansvaret för affärslogiken från utvecklarna och ut till verksamheten.

Du kan också reducera cpu belastningen i en QlikView server med hjälp av central uttryckshantering. QlikViews globala cache gör så att två identiska utryck kan återanvända varandras resultat genom att resultat sparas ned temporärt. Kravet är att uttrycken måste vara identiskt skrivna, bö den minsta skillnad bryter återanvändningen. Du kan läsa mer om QlikView Global Cache i Qlik DesignBlog – The QlikView Cache.

Jag har sett flera kreativa sätt att lyfta ut uttrycken på, jag är skyldig till flera av de. Känslan är att varje utvecklare eller utvecklargrupp har sin egen metod. Principen och önskar resultat är dock alltid det samma, uttryck och variabler sparas centralt och används av QlikView på tvärrs av applikationer.

Ny standard för variabler

I QlikView Deployment Framework (QDF) så finns en, av Qlik, rekommenderad standard för variabler. Den innehåller både förslag på namnstandarder samt metod och stöd för extern variabelhantering. Med hjälp av Deployment Framework Editor kan man skapa och hantera variabelfiler som kan på ett enkelt sätt används av QlikView med hjälp av en sub ´LoadVariableCSV´ som ingår i ramverket.


Gränssnittet i Deployment Framework Editor erbjuder stöd för hantering och manipulering av QDF-variabelfiler (som är kommaseparerade csv-filer). Det gränssnittet fungerar bra för enkla justeringar och förvaltning, men för daglig använding tycker jag det finns ett bättre alternativ.

InQlik expression editor

InQlik expression editor är en del av det öppna källkodsprojektet InQlik Tools, ett tilläggspaket till Sublime Text.

Variabler skrivs med en förenklad YAML-lik syntax i Sublime text och paketeras sedan av InQlik Tools till en QDF kompatibel variabelfil.

comment:Total income. 

Jag tycker detta sättet att skriva uttryck på blir mer översiktligt än om jag skulle jobba direkt i en QDF-csv fil som ser ut som nedan.

 SET vIncome,sum(income),,
 SET vIncome.Comment,Total income.,,
 SET vIncome.Label,Income,,

Den som inte önskar att använda QDF-funktionen för att hantera variabler finns även möjligheten att spara ned filen som qvs-kod. Då ser resultatet ut såhär:

SET vIncome = sum(income);
SET vIncome.Comment = Total income.;
SET vIncome.Label = Income;

Dollar expansion


I mina egna tidigare lösningar på extern variabelhantering så brottades jag ofta brottats dollar-expansioner. QDF-hanterar detta jättebra, men även qvs-exporten hanterar detta med glans.


Resulterar i en qvs-definition som ser ut som följande

 let vL.sumDynExp= replace(replace('sum([@(=DynExp)])','~~~', 'chr(39)'), '@(', chr(36) & '(');

Definitionen ovan genererar utan $-tolkningsproblem en variabel som ser ut precis som jag har angav i YAML-uttrycket.

Referens till andra variabler

InQlik expression editor kan något som värken QlikView Framework Editor, notepad eller excel kan göra utan att genomföra ett mindre utvecklingsprojekt innan. I variabeldeklareringen kan du referera till andra variabler.

I exemplet nedan låter jag det tredje uttrycket referera till de två första.

set: vL.profit

Jag kan nu välja om jag vill spara vL.profit som


eller låta InQlik tool expandera variablerna så att vL.Profit sparas som


Jag upplever att detta ökar transparansen i variablerna som laddas in i QlikView samtidigt som jag inter behöver återkskapa samma uttryck flera gånger manuellt.


Central uttrykshantering har flera fördelar, båda när det gäller förvaltning, ansvar och även rent teknsik då indentisk skrivna uttryck kan återanvända QlikViews cache på ätt bättre sätt an uttryck som inte är helt identiska.

Qlik frontar nu en standard via QDF, en standard som jag tycker fungerar bra. Variabel-editorn som följer med får dock se sig slagen av möjligheterna som erbjuds i InQlik Tool for Sublime Text. Med InQlik Tools kan man dessutom skriva samma syntax för att använda central variabelhantering i miljöer som inte använder QDF.