Remote include scripts

By Barry Harmsen

Got a bunch of scripts here for you, where do you want me to put them?One of the reasons why I like QlikView so much is that there are always new functions and applications to discover. Yesterday I was at a client who is a Qlik OEM partner. During lunch we discussed various uses of include scripts. The question came up if it was possible to remotely update include scripts. At the same time they didn’t want these external scripts to be viewable (they sell a solution based on QlikView, clients get the solution but the OEM owns the code). Of course, that makes things a little more complicated. The include script sits outside of QlikView in plain text, so anyone can read it. Besides that, updating an external script that sits on the client’s local server is also not a straightforward affair.

I started wondering if it might be possible to fetch an include script from a remote website. So I just tried it, and it works!* (in QlikView, Sense requires Legacy Mode to be enabled, I will let you decide if that is a good idea)

Try this one for example:


In my opinion, this opens up some interesting use cases:

  • Remote updates of scripts: I realize this is easier said than done, a QlikView app usually has more dependencies/things that need to be updated than just the script. However, for consulting companies with a big shared library of Qlik scripts for common script tasks (and any serious consulting company has these, or uses QlikView Components) this could be an excellent way to distribute/update this library. Common script tasks usually have well-defined inputs and outputs, so are relatively isolated from the rest of the script logic.
  • Securing scripts: Using an include file makes it easy to reuse and update script across applications. On the other hand, the script is visible to everyone. While I do not find this a problem, in some cases, such as the OEM example, it might be. Placing the script in a remote location and calling the include from hidden script partly solves this issue (it’s more obfuscated than secured, and only makes it a little harder to get the script. It can definitely be improved upon, but it’s a start).
  • Deliver different/parametrized versions of script: You do not need to link to an actual text file, but to something that returns a text file. This makes it possible to deliver different versions of a script to different callers, or refuse access altogether. In the example that I showed above, the include statement references a simple PHP file that includes a ‘license key’ in the query string. This key can be checked and based on whether it is valid or not a script can be returned. You could also include a ‘version number’ in the query string to fetch a particular version of the script. IMHO, lots of opportunities for ideas there.

I realize this idea is a little rough around the edges and there are obvious downsides (what if the Internet is down?), but just wanted to share it with you because I thought it was cool. Who knows where someone else will be able to take it?

I’ve created a small example which demonstrates including remotely hosted scripts, you can download it below.

Download the example

If you have any ideas for potential applications, or if you think this is a horrible idea (the thought crossed my mind), I’d like to hear from you in the comments below.


Update: One more!

Ok, so this is not a killer use case, but fun nonetheless. Calling this URL:


will return a complete Sales data model containing random data. The sales data is fetched from Mockaroo using their API. The API calls are made using my API key, which is limited to 200 calls per day, so don’t be surprised if it doesn’t work. It’s just an example though 😉 Might be useful in the future for ad-hoc QlikView/Qlik Sense demonstrations.

Download the random data example


* In hindsight, I wonder why this never occurred to me before. Probably because the Insert | Include Script dialog always opens the local filesystem, and doesn’t offer the ‘web file’ option like the file wizard does.