Qlik Community

QlikView Documents

QlikView documentation and resources.

Document boards are being consolidated, this board no longer allows NEW documents READ MORE

Extending AccessPoint v11 (example extension included for category pre-selection)

Showing results for 
Search instead for 
Did you mean: 

Extending AccessPoint v11 (example extension included for category pre-selection)



Many clients and QVS users have expressed a desire to customize accessPoint in one way or another. Some simply want to swap out the QlikView logo with their company's logo, some want to add functionality, and some may want to completely alter accessPoint at its core.  The main issue with customization of accessPoint, however, is that any customization of the core code makes it unsupported by QlikTech support.  This is understandable since Support can't be expected to fix something the user broke themselves while hacking through the code.

Due to this need, I've found accessPoint can easily be modified slightly to enable "extensions" of accessPoint that don't touch the core code.  By simply adding about 4 lines of code to the accessPoint JS, developers could write their own JS code to do just about anything in terms of adding/removing functionality, styling, changing layout, etc.  In terms of support, since this code is minimal, returning accessPoint to its “vanilla” supportable state will be very easy.


The method I used to allow accessPoint extensions was to add a minimal amount of code to core accessPoint js which loads in an XML file (if one exists).  In the XML file, there is a list of extensions and various information about them, including the name of the folder containing the JS code.  The code for the extension will be kept in the new extensions folder in a folder containing the extension's code.  An example extension is included which will be described below.

Implementation Instructions 

Core Javascript Changes

The modification to the core code is relatively small.  In accesspoint.js, there is the following code:

$(document).ready(function () {

After this, add this code:

$.ajax({url: "extensions.xml",complete: function(){

This code simply loads the extensions.xml file, and sets it so that, success or fail, the normal accessPoint code runs afterwards.

Now, after all of the normal core accessPoint within the $(document).ready(), the "complete" function we created above needs to be closed, and the code to load in the extensions needs to be added.  Most simply, the final lines of code in the file should look like this:

                        alert('Login Failed');






      }, success: function(data){

          $.each($(data).find("plugin"), function(){

            $("body").append("<script type=\"text/javascript\" src=\"extensions/" + $(this).find("file").text() + "\"></script>");





All this is doing is simply closing the "complete" function brace, then adding a function which runs if the AJAX call to extensions.xml is successful.  This function goes through each plugin entry found in the XML and appends the JS to the accessPoint index.htm web page.  Its placement there will ensure that any functions contained in the extensions overwrite existing functions from the core code.

  1. extensions.xml

Once the core JS is modified, the extensions.xml file needs to be updated to contain information about the extension.  The formatting for extensions.xml is shown below with XML containing text describing the function:

<?xml version="1.0" encoding="utf-8"?>



      <name>This would be the name of the extension</name>

      <author>The author/creator of the extension</author>

      <file>the location of the extension's file.  ex:      categoryPicker/script.js </file>

      <readme>location of the readme file (if one exists) containing documentation on the extension. ex: categoryPicker/readme.htm </readme>

      <description>A short description of the extension and what it does.</description>


For the purposes of the current added capabilities, the only field the code is really interested in is the <file> location.  The other fields are there to be displayed on a webpage similar to the exList.htm file that should be included with this document that simply displays a list of installed extensions.

Adding code to the extensions folder

In order to keep the core accessPoint folder organized, I've built the accessPoint extensions to read from an extensions folder.  To add an extension to it, with this customized solution, one would need to create a folder inside that matches the one referenced in the <file> field in XML. Inside, they would place the JS code which adds the extension's functionality.

After this step, the extension's code should be properly loaded into accessPoint and will overwrite any base accessPoint code it pleases.


By modifying a small amount of core accessPoint code, a powerful feature can easily be added to accessPoint, allowing a huge amount of product customization while still remaining supportable.

Example AccessPoint Extension

Hopefully this document has been accompanied by several files that will install the extensions capability into accessPoint as well as the extensions directory itself.  The extension that is added will allow the user to modify the accessPoint URL to have a certain category or attribute pre-selected when the page loads. So, for example, if you want to have the page load with apps that have a "Language" attribute of "English", the URL would be http://<<accessPoint URL>>/index.htm?Attribute=Language&AttributeValue=English

With this code you can filter using:

Category: <<web address>>/index.htm?Category=<<desired category>>

Attribute: <<web address>>/index.htm?Attribute=<<desired attribute>>

Attribute and Attribute Value: <<web address>>/index.htm?Attribute=<<desired attribute>>&AttributeValue=<<desired attribute value>>

Note: you cannot filter by an attribute value without specifying an attribute

Combination: <<web address>>/index.htm?Attribute=<<desired attribute>>&AttributeValue=<<desired attribute value>>&Category=<<desired category>>

On a final note, accessPoint remembers our selections, so that if we have done a search or chosen a filter, that choice will still be made when we return to accessPoint later (assuming our cookies haven't been wiped out).  This can cause problems (especially in search) with this customization, so in order to reset all choices, the option has been given to add a parameter of reset=true to reset all prior choices.  So for example, if you are setting a Category, you would add &reset=true to the end of the URL similar to this:

http://<<accessPoint URL>>/index.htm?Category=<<desired category>>&reset=true

Not applicable

Hi Brian,

Do you think that will be possible to configure Access Point so each user could have a different view of it?

I mean, would be possible that the Access Point detects the username of the person that is accessing it and, according to that username, selects a Category and some attributes?

Thank you in advance,


Not applicable

Hello Brian,

I have the same doubt that Josep.

Do you have any ideia about this matter?

Thank you.


Gabriel Tomaz

Version history
Last update:
‎2013-07-25 02:53 PM
Updated by: