Qlik Deployment Framework: Qlik Sense Development Guide
Qlik Deployment Framework: Qlik Sense Development Guide
February, 2017
qlik.com
Table of Contents
Include files 8
Sub Functions 8
QlikView Components (QVC) 8
Pre-Defined Functions 9
Data models 11
Optimization strategy 14
Using development best practices and guidelines is part of the Build and Validation phase in the Qlik
Application Development process, read more in Qlik Deployment Framework-Qlik Product Delivery
process.pdf
The Developer Guide is a reference manual for Qlik developers. Qlik developers are individuals who design
and implement applications and their areas of expertise range from data modeling to scripting to UI design.
This document is designed to facilitate much clearer understanding of the methodologies and practices that
are optimal for producing highly usable, highly optimized and highly configurable Qlik applications, whether
used by small departments or by large enterprises.
It’s important to have and use standards during Qlik development. There are many ways of getting the
same result, but not all of them are efficient and understandable. Utilizing Qlik Deployment Framework in
combination with development guide lines we create consistent multi development environment. Standards
are needed for:
Reuse of data
Reuse of code
Reuse of expressions and variables
Multiple development
Governance
Creating and collecting understandable metadata
Using standards will result in lower cost of ownership by making governance easier and TCO lower.
Qlik Deployment framework is based on the concept of resource containers. Containers are security
boundaries, isolated file structures placed side by side. A container can be moved and/or renamed without
changing any Qlik script logic. Each container has identical file structures and contains predefined script
functions.
Qlik Sense Only Here we have removed everything related to QlikView, for example Application
and mart folders. Extract, Transform, Load folders have also been added under the QVD structure.
Slimmed Down is intended for smaller deployments and several folders have been removed.
Extract, Transform, Load folders have also been added under the QVD structure.
Administration container it’s from here additional containers are created and managed.
Shared folders. A fresh QDF installation always contains a shared container, this is a repository to
store scripts, configuration and data files that are shared and reusable by all applications.
Example This is a container containing some examples and QVD files, this is used during the
exercise documentation.
Container Variables
Each preinstalled folder in a container has corresponding environmental variable (Global Variable).
Scripting using these variables makes it possible to move code and applications between containers without
any script modifications, it also makes it possible to seamlessly share scripts between QlikView and Qlik
Sense. To initiate QDF and create the global variables an initiation script (InitLink.qvs) need to be added in
the beginning of the Qlik Sense load script.
Global Variables
Global variables are auto-generated by QDF during the initiation script, these variables are named Global
because they and reused between applications across a container. The name standard is vG.xxx (Variable
Global).
Custom Global Variables are framework variables created manually by the developers. These
variables are also auto-generated during initiation using the CustomVariables.csv , that file exists within
each container under 3.Include\1.BaseVariable. Adding name and value in this csv file makes variables
available for the Qlik Sense applications that is using the home folder where the csv is resided.
o Global variables should only be used when variables are shared by several applications in a
Container.
Universal Variables is similar to Custom but used across multiple containers. Universal are stored in
the Shared Folders Container creating a “single point of truth” across all containers. Universal Variables
are stored in $(SharedBaseVariablePath)\CustomVariables.csv file and loaded during the framework
initiation process.
o Universal variables should be used when variables are shared by several applications across
all Containers.
Example: call LCGV('AcmeTravel') Will create all Global Variables linking to 2.AcmeTravel container.
Variables created will have similar name as home container but with the additional AcmeTravel prefix, like
vG.AcmeTravelQVDPath for QVD path to AcmeTravel container
call LCGV('Oracle','QVD;Include'); Will create two Global Variable links to different resources in
Oracle container, by using an additional switch and ‘;’ separator creates Global Variables
vG.OracleQVDPath and vG.OracleIncludePath (instead of linking all folders as in the first example).
For easier manageability and faster development, it’s recommended to reuse script code as much as
possible. By using Deployment Frameworks predefined structures and variables it’s easy to reuse script
code. There are two ways of reusing code in Qlik Script:
Include files
Use of functions
Include files
An include file is just a Qlik script (text file) that is included into the main script during execution. Qlik include
scripts use the prefix qvs. The entire or parts of the script can thus be put in a file for reuse.
All Include files are stored in 6.Custom folder, the global variable for 6.Custom folder is vG.CustomPath and
should always be used when accessing a custom script, meaning that it’s not a part of the Deployment
Framework initiation process. Example: $(Include=$(vG.CustomPath)\1.xyz_Calculations.qvs);
Sub Functions
Qlik have the possibility of reusing scripts and functions by using the Sub and Call commands. As
presented above with the LCGV function. The Framework contains library of nice to have functions. All sub
functions are stored under the 3.Include\4.Sub folder and are initiated during QDF initiation.
Use Call function_name(‘Input parameters or variables’) command to execute the preloaded function.
Another function example, vL.FileExist will return true of false depending on if the file exists
Call vL.FileExist ('$(vG.QVDPath)\SOE.qvd')
Hint. Add additional sub functions, Qlik Community is a good place to look, instead of coding everything
from scratch.
If no Shared container exists, as a backup the local container sub function library will be used. Meaning as
long as a Shared folder exists all sub function additions should be stored under the Shared container
The preinstalled Sub functions that exist under 3.Include/4.Sub folder should not be deleted or
modified, this library is used by Qlik Deployment Framework initiation process.
Understanding
Synthetic key
Another characteristic with the associative database is that the number of distinct (unique) values in a table
is more important than the number records. By delimit the number of distinct values in a table the
performance of an application can be significantly improved.
Example: Let´s say you have a fact table with 1 billion recs, one of the fields is a timestamp field containing
date and time (measured down to fraction of seconds) with almost 800 million distinct values. Two
alternative actions will both improve the performance:
If you don’t need to analyze on time level, simply transfer the field to a date field (use CalendarGen
function) and there will not be more than 365 distinct values for one year.
If you need to analyze on time level, determine on what time level you need to analyze (hour,
minute) and create a new field, Time. Depending on what level you decide to analyze, hour will give
you 24 distinct values and minute will give maximum 1440 distinct values)
To show how this could be accomplished, the section below takes us through a scenario of two facts tables
to be combined into one fact table.
The use of preceding load statements can simplify your script and make it easier to understand.
See the code below for an example of this.
Table1:
LOAD CustNbr as [Customer Number],
ProdID as [Product ID],
floor(EventTime) as [Event Date],
month(EventTime) as [Event Month],
year(EventTime) as [Event Year],
hour(EventTime) as [Event Hour];
SQL SELECT
CustNbr,
ProdID,
EventTime
FROM MyDB;
This will simplify the SQL SELECT statement so that the developer can continue to test/augment the
statement using other tools, without the complexity of the Qlik transformations embedded in the same SQL
statement.
For more information on the Preceding LOAD feature, see the help.qlik.com.
Qlik is known for its wide user adoption. One of the main reasons for this is its capability to manage large
data sets with short response time. Although a Qlik application most often is easy and fast to develop it’s a
very good idea to establish an optimization strategy as part of your development platform. For long term
success it is strongly recommended that you have an optimization focus in your application development,
especially when you know that the application should hold a large data set and be distributed to a large
number of users. A good idea is to have an optimization step connected to the validation/approval phase in
your development process, this of course both for new applications as well as for changed/ improved
applications.
Use Autonumber only after development debugging is done. It’s easier to debug values with a
number in it instead of only being able to use surrogates. See Reference Manual if you are not sure
how/when to use Autonumber.
Put subject areas on different tabs so you don’t confuse the developers with too much complexity
Name the concatenate/join statements
Use HidePrefix=%; to allow the enterprise developer to hide key fields and other fields which are
seldom used by the designer (this is only relevant when co-development is being done).
When using the Applymap() function, fill in the default value with something standard like ‘Unknown’
& Value which is unknown so users know which value is unknown and can go fill it in on the source
system without the administrators having to get involved. See Reference Manual if you are not sure
how/when to use Applymap().
Never user Underscores or slashes (or anything ‘techie’) in the field names. Instead code user
friendly names, with spaces.
Instead of:“mnth_end_tx_ct”use:“Month End Transaction Count”
Only use Qualify * when absolutely necessary. Some developers use Qualify * at the beginning of
the script, and only unqualify the keys. This causes a lot of trouble scripting with left join statements,
etc. It’s more work than it’s worth in the long run. See Reference Manual if you are not sure
how/when to use Qualify and Unqualify.
Use variables for path name instead of hard-coding them throughout your script. This reduces
maintenance and also provides a simple way to find paths (assuming you put them in the first tab to
make it easy to find).
All file references should use Container naming convention.
Always have the Log file option turned on if you need to capture load-time information for
debugging purpose
Comment script headings for each tab. See example below:
Comment script sections within a tab with short descriptions. See example below: