Information for developers, analysts and administrators

Configuring Your Apps Across Environments and Servers With a Keywords File

In this post, I’ll share a technique that I’ve used for many years in my QlikView scripts and recently revised for use in Qlik Sense.


Most larger Qlik Sense development environments and many smaller ones follow a process before an App gets into a public (or production) stream. Usually, the app is developed and tested in a work stream, then published to a test stream, and finally, a public stream. All this activity might occur on the same server or it might span several servers. Even if this doesn’t describe your Qlik environment, there are probably apps on your server that exist in several stream or as copies.


If any of the above describes your Qlik Sense environment then you probably have to deal with different versions of data connections, configuration values, and other items that might change from environment to environment. If you use any third-party extensions that link apps to other apps or sheets within those apps then you have the added problem of keeping track of all the different app and sheet IDs.


What’s the best way to manage this? Qlik provides a good solution to one facet of this by providing externally defined Data Connections, but how can you keep track of, and properly define all of the other information. One simple way that I’ve seen it done is to simply code it into the script and then edit that information in the script from stream-to-stream or environment-to-environment. That works, but it’s really not a best practive. Another technique that I’ve used in both QlikView and Qlik Sense Apps is to use an external configuration file that can be modified for each app instance. If you’re an application developer who has coded in any major development language then you’re probably very familiar with this concept.


Here’s an example of the configuration approach that I’ve used with Qlik Sense. It has four major pieces; a content folder to hold the configuration files; a configuration file—I use an Excel file; a simple script; and a process for associating the configuration with a specific instance of the app.


The Content Folder

Create a Content Folder where you’ll store configuration files. In the example script that follows, I’ve called mine “Configuration Files”.


The Configuration File

Each app that requires a configuration will have its own file. This is where you specify the specific items and their values, that need to change for each version of the app. Name this file with the ID of the specific App to which it applies—you can look that up in the QMC. For example “d5a57d9b-71e2-46c7-3b2a-f8bc82a12f27.xlsx”. Upload the file to the Content Folder.


My spreadsheet usually has two columns; a Keyword and a Value. I renamed the tab name in my example to “Keywords”. For example:

File: d5a57d9b-71e2-46c7-3b2a-f8bc82a12f27.xlsx

Keywords Script

The script segment below processes the configuration file and its contents. You would place this early in your script, before the point where you need to use the values that it retrieves.

// Get the ID of the app that’s executing this script.

Let AppID = DocumentName(); 


// Make the file name of the configuration file for this App

Let KeywordFileName = ‘lib://Configuration Files/’ & ‘$(vX.App.ID)’ & ‘.xlsx’;


If FileSize(‘$(KeywordFileName)’) > 0 then   // Process the file only if it exists






    From [$(KeywordFileName)]

    (ooxml, embedded labels, table is Keywords);


    For i = 0 to (NoOfRows(‘ KeywordFileName ‘) – 1)

            Let KeywordName = Peek(‘Keyword’, i, ‘Keywords’);

            Let $(KeywordName) = Peek(‘Value’, i, ‘Keywords’);

    Next i


    Drop Table Keywords;


End If;

After this script runs, I’ll have actual variables in my App that were initialized from the spreadsheet with their respective values, equivalent to the script statements below.

1. Let myConnectionName = ‘Sales Database’;
2. Let myEnvironment = ‘TEST’;
3. Let mySomeOtherAppID = ‘e3a13f5c-82d5-47a7-9a2c-b1ce34c82f32’;

I might use #1 in a connection statement. For example:

LIB CONNECT TO ‘$(myConnectionName)’;

I can use #2 to condition some of my script logic. For example:

If ‘$(myEnvironment) = ‘TEST’ then

      … do some logic


     … do some other logic

End If

#3 could be used as a value in one of my visualization extensions that link to another App.

 In Summary

  • Create a content folder to store the Configuration files.
  • Name each configuration file as the {ID}.xlsx and store it in the content folder.
  • Use the script provided to read the configuration file into your app. You can keep the script in another content folder and “Include” it so that you don’t have to pate it into every script.
  • Reference the variables that got created wherever you need them in your App.

This is a flexible way to standardize variables from environment to environment, or server to server, and not have to modify your App script.

Leave a Reply

Your email address will not be published. Required fields are marked *