• Scotchy

Data governance in QlikSense (Part 4)

QlikSense Implementation


Charts and Tables within QlikSense will surface metrics (measures) and KPI’s providing actionable insight to the user.

Typically these metrics and KPI’s are constructed using the inbuilt scripting language and Set Analysis for more complex calculations across the associative model.

There is always a propensity for the re-use of calculations within 1 or more apps.

The Business Dictionary solves this propensity for the reasons listed in Part 2 of this series

Master Items

QlikSense implements a basic form of object reuse via the master items repository , where objects defined here can be reused across an app, however the caveat is that the master items are not available to other apps and they are not easily maintained should changes be required.

Master items are created very easily via the <Create New> option where the developer is then prompted for the expression and other attributes that make up the item, in the case of the Business Dictionary the majority of the items will be Measures, we can also create calculated dimensions here too for example the “Top 5 ranked claim cause categories” is a calculated dimension held in the dictionary.

Below (msi_1) is a screenshot of a KPI object with a master item measure mapped to it.

The master item definition is shown in the below screenshot (msi_2)


The expression is a $expanded variable name, the variable is predefined in the Business Dictionary with the expression that performs the calculation; the expression for this variable is …

Count (distinct {$<claim_notify_year={"$(vMaxClaimNotifyYear)"}>} CLAIMNO)

If the business dictionary was not in use, then the master item definition would appear thus…

If the calculation were to be changed as a result of the business defining a new rule, then the development process to modify and test the app after the calc has been updated will take some time, largely based on the developer group schedule.

Hence where the business dictionary is used the process is simply to modify the calc for the master item variable (do this in your UAT version of the dictionary) execute a test re-load for the app and validate, when the test has passed, simply replicate the updated measure in the PROD business dictionary and the changes will be applied at next scheduled reload time (or before if required).

Responsive change management is achieved using this method.


Initially there is developer overhead for new apps to create the required master items that will be used in the app, it is recommended where apps are going to be common such as CID, then create a template app in advance, along with template measures that can be replicated across to a client version when required.

Unfortunately we cannot completely automate the apps, for example where a new metric or KPI is required for an existing app, the developer will need to be involved to execute the modification(s).

Scripted Interface to the business dictionary repository

The variables that have been defined for the app will need to be loaded; this is achieved by a script module that must be included in every app (another reason for app templates). The below screenshot shows the module header for the app…


There are 2 predefined variables set in the loader for the client app; these are the predicate for querying the dictionary for the client app calculations.

vClientID Denotes the client, the variable name is based on the Client Master table

vAppName Denotes the app that relates to the fund e.g. CID

Note: The dictionary is able to facilitate multiple apps for a single client if required

Next week we will explore the workflow for loading a dictionary into an app, have a great week.

If you would like to know more about this level of governance for QlikSense and QlikView, don't hesitate to get in touch here.

#App #Load #variable #script

279 views0 comments

© 2017 by awari.com.au

  • Black Twitter Icon
  • Black LinkedIn Icon